| Message ID | 1314811527.1809.34.camel@adamo |
|---|---|
| State | New |
| Headers | show |
On 08/31/2011 11:25 AM, Leann Ogasawara wrote: > Hi All, > > http://bugs.launchpad.net/bugs/833705 > > It's been reported that the Dell Latitude E6520 doesn't reboot unless > using reboot=pci. The following patch resolves this issue and had been > successfully tested by the bug reporter. I additionally sent this patch > upstream but was given some push back from one of the maintainers > because "we are starting to have something close to a full Dell product > catalog in the system. I think we need to come up with something more > systematic..." > > So with Kernel Freeze looming for Oneiric, the patch being system > specific (ie low risk of regression), precedence for similar quirk > patches already existing, and having received positive test results, I > feel it should be carried as a SAUCE patch until a more systematic > approach can be found which upstream will accept. > > Thanks, > Leann > Did upstream have any suggestions ? I used to think device tree was the answer, but now I'm not as sure. Perhaps a sysfs interface and an application to send the right bits based on DMI info is whats needed. rtg
On Wed, 2011-08-31 at 12:38 -0600, Tim Gardner wrote: > On 08/31/2011 11:25 AM, Leann Ogasawara wrote: > > Hi All, > > > > http://bugs.launchpad.net/bugs/833705 > > > > It's been reported that the Dell Latitude E6520 doesn't reboot unless > > using reboot=pci. The following patch resolves this issue and had been > > successfully tested by the bug reporter. I additionally sent this patch > > upstream but was given some push back from one of the maintainers > > because "we are starting to have something close to a full Dell product > > catalog in the system. I think we need to come up with something more > > systematic..." > > > > So with Kernel Freeze looming for Oneiric, the patch being system > > specific (ie low risk of regression), precedence for similar quirk > > patches already existing, and having received positive test results, I > > feel it should be carried as a SAUCE patch until a more systematic > > approach can be found which upstream will accept. > > > > Thanks, > > Leann > > > > Did upstream have any suggestions ? I used to think device tree was the > answer, but now I'm not as sure. Perhaps a sysfs interface and an > application to send the right bits based on DMI info is whats needed. Nope, no further suggestions, only what I quoted. It has been brought to my attention that we're also starting to see this reboot=pci quirk needed in some of the Dell Optiplex systems as well, see LP bugs 800660 [1], 768039 [2], 818933 [3]. Do we have any contacts at Dell we should raise this with? Thanks, Leann [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/800660 [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/768039 [3] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/818933
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c index 9242436..6ac6e12 100644 --- a/arch/x86/kernel/reboot.c +++ b/arch/x86/kernel/reboot.c @@ -443,6 +443,14 @@ static struct dmi_system_id __initdata pci_reboot_dmi_table[] = { DMI_MATCH(DMI_PRODUCT_NAME, "Latitude E6420"), }, }, + { /* Handle problems with rebooting on the Latitude E6520. */ + .callback = set_pci_reboot, + .ident = "Dell Latitude E6520", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), + DMI_MATCH(DMI_PRODUCT_NAME, "Latitude E6520"), + }, + }, { } };