kernel March 2009

kernel@lists.fedoraproject.org

12 participants
9 discussions

Patch incomplete write error not returned to NFS client
by Victor 01 Apr '09

01 Apr '09

Request for integrating this patch into the next kernel update for Fedora 10. The patch fixes a bug in NFS where an error will not be returned to the NFS client when an incomplete write happens at the filesystem level on the server. http://git.linux-nfs.org/?p=bfields/linux.git;a=commitdiff;h=192a3cb6bc1f12… --Vic

2 1

early branched for F-11
by Kyle McMartin 31 Mar '09

31 Mar '09

Just a quick note, we've early branched for F-11... The 2.6.29 based tree for F-11 is located in the F-11/ subdirectory... Make sure you cvs up the common/ dir as well. devel/ has been updated for -git7 and will continue to move towards 2.6.30. regards, Kyle

1 0

Re: rpms/kernel/devel linux-2.6-net-fix-another-gro-bug.patch, NONE, 1.1 TODO, 1.59, 1.60 kernel.spec, 1.1482, 1.1483
by Mark McLoughlin 30 Mar '09

30 Mar '09

Hi, On Mon, 2009-03-30 at 08:56 +0000, Mark McLoughlin wrote: > +* linux-2.6-net-fix-another-gro-bug.patch: > + virtio_net guest->remote GSO busted with 2.6.29 host > + https://bugzilla.redhat.com/490266 > + Should be in 2.6.29.1 I took the liberty of just going ahead and building this - pretty serious bug with a fairly trivial fix from upstream. Cheers, Mark.

1 0

File conflicts between alsa-firmware and kernel-firmware
by Tim Jackson 23 Mar '09

23 Mar '09

I maintain alsa-firmware and the following bug regarding file conflicts between recent versions of kernel-firmware and alsa-firmware got raised today: https://bugzilla.redhat.com/show_bug.cgi?id=487873 I'm not really familiar with the kernel package maintenance, nor who/what governs what firmware goes into kernel-firmware (and indeed how that is related to the upstream kernel). I had a cursory look at the kernel spec in CVS but that didn't appear to have any relevant recent changes that were obvious. I did a diff between the firmware in alsa-firmware and in kernel-firmware-2.6.29-0.172.rc6.git4.fc11 and it's clear that although there are some overlaps, much of the audio firmware in alsa-firmware isn't in kernel-firmware. The current conflicting files are: ess/* korg/* sb16/* yamaha/ds1_ctrl.fw yamaha/ds1_dsp.fw yamaha/ds1e_ctrl.fw Things that are in alsa-firmware but NOT in the above version of kernel-firmware are: asihpi/* digiface* 3g* ea/* emu/* mixart/* multiface* pcxhr/* vx/* yamaha/yss225_registers.bin [usx2y, which does something funky so it's not in /lib/firmware] Either way, it looks like we need to work together on this. - I'm happy to just drop the conflicting files from alsa-firmware - is that the right thing to do? - Are the above audio firmware files in kernel-firmware there to stay? - Is there a long term goal to bring all the firmware from alsa-firmware upstream into the kernel-firmware package? Thanks Tim

3 2

Backport /sys/bus/pci/devices/*/remove_id
by Mark McLoughlin 23 Mar '09

23 Mar '09

Hey, Any objections to pulling in this patch from the linux-next PCI tree? It adds a sysfs entry which we need for KVM/libvirt PCI device assignment. See: https://bugzilla.redhat.com/487103 TODO entry would be: * linux-2.6-pci-sysfs-remove-id.patch In jbarnes linux-next tree for 2.6.30 Needed for KVM PCI device assignment https://bugzilla.redhat.com/487103 Cheers, Mark. From: Chris Wright <chrisw(a)sous-sol.org> Date: Tue, 24 Feb 2009 05:52:23 +0000 (-0800) Subject: PCI: add remove_id sysfs entry X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fjbarnes%2Fpci-2.6.git;a=com… PCI: add remove_id sysfs entry This adds a remove_id sysfs entry to allow users of new_id to later remove the added dynid. One use case is management tools that want to dynamically bind/unbind devices to pci-stub driver while devices are assigned to KVM guests. Rather than having to track which driver was originally bound to the driver, a mangement tool can simply: Guest uses device Signed-off-by: Chris Wright <chrisw(a)sous-sol.org> Signed-off-by: Jesse Barnes <jbarnes(a)virtuousgeek.org> --- diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci index e638e15..3d29793 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci +++ b/Documentation/ABI/testing/sysfs-bus-pci @@ -41,6 +41,22 @@ Description: for the device and attempt to bind to it. For example: # echo "8086 10f5" > /sys/bus/pci/drivers/foo/new_id +What: /sys/bus/pci/drivers/.../remove_id +Date: February 2009 +Contact: Chris Wright <chrisw(a)sous-sol.org> +Description: + Writing a device ID to this file will remove an ID + that was dynamically added via the new_id sysfs entry. + The format for the device ID is: + VVVV DDDD SVVV SDDD CCCC MMMM. That is Vendor ID, Device + ID, Subsystem Vendor ID, Subsystem Device ID, Class, + and Class Mask. The Vendor ID and Device ID fields are + required, the rest are optional. After successfully + removing an ID, the driver will no longer support the + device. This is useful to ensure auto probing won't + match the driver to the device. For example: + # echo "8086 10f5" > /sys/bus/pci/drivers/foo/remove_id + What: /sys/bus/pci/devices/.../vpd Date: February 2008 Contact: Ben Hutchings <bhutchings(a)solarflare.com> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c index 93eac14..87a5ddb 100644 --- a/drivers/pci/pci-driver.c +++ b/drivers/pci/pci-driver.c @@ -99,6 +99,52 @@ store_new_id(struct device_driver *driver, const char *buf, size_t count) } static DRIVER_ATTR(new_id, S_IWUSR, NULL, store_new_id); +/** + * store_remove_id - remove a PCI device ID from this driver + * @driver: target device driver + * @buf: buffer for scanning device ID data + * @count: input size + * + * Removes a dynamic pci device ID to this driver. + */ +static ssize_t +store_remove_id(struct device_driver *driver, const char *buf, size_t count) +{ + struct pci_dynid *dynid, *n; + struct pci_driver *pdrv = to_pci_driver(driver); + __u32 vendor, device, subvendor = PCI_ANY_ID, + subdevice = PCI_ANY_ID, class = 0, class_mask = 0; + int fields = 0; + int retval = -ENODEV; + + fields = sscanf(buf, "%x %x %x %x %x %x", + &vendor, &device, &subvendor, &subdevice, + &class, &class_mask); + if (fields < 2) + return -EINVAL; + + spin_lock(&pdrv->dynids.lock); + list_for_each_entry_safe(dynid, n, &pdrv->dynids.list, node) { + struct pci_device_id *id = &dynid->id; + if ((id->vendor == vendor) && + (id->device == device) && + (subvendor == PCI_ANY_ID || id->subvendor == subvendor) && + (subdevice == PCI_ANY_ID || id->subdevice == subdevice) && + !((id->class ^ class) & class_mask)) { + list_del(&dynid->node); + kfree(dynid); + retval = 0; + break; + } + } + spin_unlock(&pdrv->dynids.lock); + + if (retval) + return retval; + return count; +} +static DRIVER_ATTR(remove_id, S_IWUSR, NULL, store_remove_id); + static void pci_free_dynids(struct pci_driver *drv) { @@ -125,6 +171,20 @@ static void pci_remove_newid_file(struct pci_driver *drv) { driver_remove_file(&drv->driver, &driver_attr_new_id); } + +static int +pci_create_removeid_file(struct pci_driver *drv) +{ + int error = 0; + if (drv->probe != NULL) + error = driver_create_file(&drv->driver,&driver_attr_remove_id); + return error; +} + +static void pci_remove_removeid_file(struct pci_driver *drv) +{ + driver_remove_file(&drv->driver, &driver_attr_remove_id); +} #else /* !CONFIG_HOTPLUG */ static inline void pci_free_dynids(struct pci_driver *drv) {} static inline int pci_create_newid_file(struct pci_driver *drv) @@ -132,6 +192,11 @@ static inline int pci_create_newid_file(struct pci_driver *drv) return 0; } static inline void pci_remove_newid_file(struct pci_driver *drv) {} +static inline int pci_create_removeid_file(struct pci_driver *drv) +{ + return 0; +} +static inline void pci_remove_removeid_file(struct pci_driver *drv) {} #endif /** @@ -852,13 +917,23 @@ int __pci_register_driver(struct pci_driver *drv, struct module *owner, /* register with core */ error = driver_register(&drv->driver); if (error) - return error; + goto out; error = pci_create_newid_file(drv); if (error) - driver_unregister(&drv->driver); + goto out_newid; + error = pci_create_removeid_file(drv); + if (error) + goto out_removeid; +out: return error; + +out_removeid: + pci_remove_newid_file(drv); +out_newid: + driver_unregister(&drv->driver); + goto out; } /** @@ -874,6 +949,7 @@ int __pci_register_driver(struct pci_driver *drv, struct module *owner, void pci_unregister_driver(struct pci_driver *drv) { + pci_remove_removeid_file(drv); pci_remove_newid_file(drv); driver_unregister(&drv->driver); pci_free_dynids(drv);

1 0

Re: [pkgdb] kernel: oliver has requested commit
by Kyle McMartin 12 Mar '09

12 Mar '09

On Thu, Feb 26, 2009 at 09:51:14AM +0000, Fedora PackageDB wrote: > oliver has requested the commit acl on kernel (Fedora devel) > Uh, who are you again? regards, Kyle

5 15

[PATCH] Don't try to use agp symbols if we don't have AGP (*cough*sparc*cough*)
by Tom Callaway 11 Mar '09

11 Mar '09

The radeon_buffer.c addition that gets pulled into the DRM driver as part of Kernel Mode Setting (even if you disable KMS for the Radeon driver) was assuming that it was safe to use symbols from the AGP code, but that isn't safe on platforms where __OS_HAS_AGP is 0. Such as sparc64. :) This patch gets the code building again. It probably should go into the actual kms patch, but if you would prefer this go as a separate patch, I can apply it. With this, we can get rawhide building for sparc64, so I'm eager to see it applied in one way or another. Signed-off-by: Tom "spot" Callaway <tcallawa(a)redhat.com>

4 5

[PATCH] x86: fix DMI for EFI
by Brian Maly 09 Mar '09

09 Mar '09

resolves BZ 488579 Impact: reactivate DMI quirks on EFI hardware DMI tables are loaded by EFI, so the dmi calls must happen after efi_init() and not before. Currently Apple hardware uses DMI to determine the framebuffer mappings for efifb. Without DMI working you also have no video on MacBook Pro. This patch resolves the DMI issue for EFI hardware (DMI is now properly detected at boot), and additionally efifb now loads on Apple hardware (i.e. video works). Upstream commit: http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=commitdif… It would be helpful to have this patch included in Fedora before UEFI test day (April 9th, 2009), if possible, being that the largest percentage of UEFI hardware currently on the market is made by Apple. In that respect, this patch is somewhat important. Brian

2 2

[PATCH] EFI: fix efi_ioremap
by Brian Maly 06 Mar '09

06 Mar '09

resolves BZ 466954 efi_ioremap is currently broken in fedora, so systems that have large efi runtime regions mapped into higher mem are not able to re-map, the result being the system fails to boot. The core issue is that any region > 400K cannot currently be remapped with efi_ioremap due to size limitations within the efi_ioremap code. So when an efi runtime region is larger than 400K and in higher mem, it is not remapped. Systems most affected by this issue tend to be made by Apple. This patch was tested on MacBook Pro (Santa Rosa) and resolves the issue. Upstream commit: http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=commitdif… It would be helpful to have this patch included in Fedora before UEFI test day (April 9th, 2009), if possible, being that the largest percentage of UEFI hardware currently on the market is made by Apple. In that respect, this patch is somewhat important. Brian ------------------------------------------------------------------------

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel March 2009