Samsung N130 ATA exception after 5min uptime -- Phoenix FailSafe issue?
in [Kernel]
|
Prev: [PATCH] leds: fix the return value of ich7_lpc_probe.
Next: warn about shared irqs requesting IRQF_DISABLED registered with setup_irq
From: Greg KH on 28 Nov 2009 14:30 On Thu, Nov 26, 2009 at 05:42:12PM +0100, Johannes Stezenbach wrote: > Hi, > > I'm refering to > http://bugzilla.kernel.org/show_bug.cgi?id=14314 > and I still have this issue on a N130 with latest BIOS (05CM), > running kernel 2.6.32-rc8 + wireless-testing. > > BIOS Information > Vendor: Phoenix Technologies Ltd. > Version: 05CM.M011.20091013.JIP > Release Date: 10/13/2009 > Address: 0xE6300 > Runtime Size: 105728 bytes > ROM Size: 2048 kB > Characteristics: > ISA is supported > PCI is supported > PNP is supported > BIOS is upgradeable > BIOS shadowing is allowed > ESCD support is available > ACPI is supported > USB legacy is supported > Smart battery is supported > BIOS boot specification is supported > Targeted content distribution is supported > BIOS Revision: 5.0 > > Around 5min after boot or resume if generates the following error: > > [ 302.364174] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen > [ 302.364201] ata1.00: failed command: WRITE DMA > [ 302.364234] ata1.00: cmd ca/00:08:f7:01:1a/00:00:00:00:00/e0 tag 0 dma 4096 out > [ 302.364241] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) > [ 302.364257] ata1.00: status: { DRDY } > [ 307.408107] ata1: link is slow to respond, please be patient (ready=0) > [ 312.392109] ata1: device not ready (errno=-16), forcing hardreset > [ 312.392138] ata1: soft resetting link > [ 312.574482] ata1.00: configured for UDMA/133 > [ 312.574506] ata1.00: device reported invalid CHS sector 0 > [ 312.574542] ata1: EH complete This is because after 5 minutes, the BIOS implements C states in the processor, which causes a "hic-up" in userspace. Everything should be fine after this, and most importantly, the power usage drops by a few watts, which is most important. > This also happens when booting with rdinit=/bin/sh, i.e. only running busybox sh > inside initrd. The error then appears when accessing the disk after the 5min > period with dd if=/dev/sda of=/dev/null count=10000. Yup, see above for why. Samsung does this to make booting their BIOS faster. > The link in comment #14 is dead but eventually I found > http://download.opensuse.org/repositories/Moblin:/Base/openSUSE_11.1/src/kernel-source-2.6.31.6-37.1.src.rpm > which contains the attached patch with a samsung_laptop driver. > > I think it is weird that the Samsung BIOS has a special "SECLINUX" mode, > but anyway the samsung_laptop driver works (the backlight control via ACPI > also works with the 05CM BIOS, though). Yes, but Samsung does not support ACPI at this time, even though it is in their latest bios versions (experimental stuff, needed for Windows 7 mode or something...) And yes, a "special" linux mode is weird, but at least they gave us something that works :) > However, it does not prevent the ATA exception. Yup, it's not an issue though. > (Side note about backlight level 0: I noticed that in Windows when you > set the backlight to the lowest level, after a minute of inactivity > the screen would dim one level more. Stupid -- why not allow the user > to choose that level manually?) Talk to samsung about this. There is one more lower level the BIOS can go to, which is what Windows does here. Samsung doesn't want Linux to use that mode at this time. It only saves a bit less than .1W, so it's not that big of a deal. Glad it's all working for you now. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Greg KH on 28 Nov 2009 16:40 On Sat, Nov 28, 2009 at 02:30:38PM -0600, Robert Hancock wrote: > On 11/28/2009 01:19 PM, Greg KH wrote: >> On Thu, Nov 26, 2009 at 05:42:12PM +0100, Johannes Stezenbach wrote: >>> Hi, >>> >>> I'm refering to >>> http://bugzilla.kernel.org/show_bug.cgi?id=14314 >>> and I still have this issue on a N130 with latest BIOS (05CM), >>> running kernel 2.6.32-rc8 + wireless-testing. >>> >>> BIOS Information >>> Vendor: Phoenix Technologies Ltd. >>> Version: 05CM.M011.20091013.JIP >>> Release Date: 10/13/2009 >>> Address: 0xE6300 >>> Runtime Size: 105728 bytes >>> ROM Size: 2048 kB >>> Characteristics: >>> ISA is supported >>> PCI is supported >>> PNP is supported >>> BIOS is upgradeable >>> BIOS shadowing is allowed >>> ESCD support is available >>> ACPI is supported >>> USB legacy is supported >>> Smart battery is supported >>> BIOS boot specification is supported >>> Targeted content distribution is supported >>> BIOS Revision: 5.0 >>> >>> Around 5min after boot or resume if generates the following error: >>> >>> [ 302.364174] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen >>> [ 302.364201] ata1.00: failed command: WRITE DMA >>> [ 302.364234] ata1.00: cmd ca/00:08:f7:01:1a/00:00:00:00:00/e0 tag 0 dma 4096 out >>> [ 302.364241] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) >>> [ 302.364257] ata1.00: status: { DRDY } >>> [ 307.408107] ata1: link is slow to respond, please be patient (ready=0) >>> [ 312.392109] ata1: device not ready (errno=-16), forcing hardreset >>> [ 312.392138] ata1: soft resetting link >>> [ 312.574482] ata1.00: configured for UDMA/133 >>> [ 312.574506] ata1.00: device reported invalid CHS sector 0 >>> [ 312.574542] ata1: EH complete >> >> This is because after 5 minutes, the BIOS implements C states in the >> processor, which causes a "hic-up" in userspace. Everything should be >> fine after this, and most importantly, the power usage drops by a few >> watts, which is most important. > > Why does this "hiccup" seem to cause interrupts to get lost? This would > cause an up to 30-second stall in disk I/O. Yup, it does. >>> This also happens when booting with rdinit=/bin/sh, i.e. only running busybox sh >>> inside initrd. The error then appears when accessing the disk after the 5min >>> period with dd if=/dev/sda of=/dev/null count=10000. >> >> Yup, see above for why. >> >> Samsung does this to make booting their BIOS faster. > > Ugh.. Seriously? Seriously. It's a BIOS issue, and is the way that Samsung has implemented this. There is nothing that the OS can do about it. Windows has the same "issue" here. >>> The link in comment #14 is dead but eventually I found >>> http://download.opensuse.org/repositories/Moblin:/Base/openSUSE_11.1/src/kernel-source-2.6.31.6-37.1.src.rpm >>> which contains the attached patch with a samsung_laptop driver. >>> >>> I think it is weird that the Samsung BIOS has a special "SECLINUX" mode, >>> but anyway the samsung_laptop driver works (the backlight control via ACPI >>> also works with the 05CM BIOS, though). >> >> Yes, but Samsung does not support ACPI at this time, even though it is >> in their latest bios versions (experimental stuff, needed for Windows 7 >> mode or something...) > > ACPI support would seem much preferable to implementing power management > with such strange proprietary hacks.. I do not disagree with you at all about this. This has been communicated to Samsung, but at this point in time, they are not going to support ACPI and only want Linux to use this interface. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Greg KH on 28 Nov 2009 19:20
On Sat, Nov 28, 2009 at 11:22:03PM +0100, Johannes Stezenbach wrote: > > Seriously. It's a BIOS issue, and is the way that Samsung has > > implemented this. There is nothing that the OS can do about it. > > Windows has the same "issue" here. > > Um, "how does Windows handle this" would've been my next question. > I didn't do much with Windows before I wiped it, I mainly used it > to confirm the thing works and to do the BIOS update. I did go through > a few reboot cycles though and I think I would've noticed a 30 second > hang. Maybe they just lowered the ATA timeout to hide it or something. > Otherwise I guess google would turn up complaints from Windows users, too, > not just from Linux users. > > BTW, at 5min after boot it is 99% guaranteed that this ATA > exception will happen during the occasional fsck. That > doesn't feel right. Well, I've never been doing a fsck at 5 minutes into boot, and neither do most Windows users :) > > I do not disagree with you at all about this. This has been > > communicated to Samsung, but at this point in time, they are not going > > to support ACPI and only want Linux to use this interface. > > Well, at least they made the information for the SECLINUX interface > available (to you), You have as much information for the SECLINUX interface that I do at this point in time. It is all documented in the driver. Actually, it's documented better in the driver than the "hints" they originally provided me... > but it would be better they'd support ACPI. > I mean if they have to support it for Windows 7 anyway, then > what's the point of not supporting it for other OSs? Hey, no argument from me here, but I think the main issue is that they do not officially support Windows 7 on this platform yet either. Hence, no ACPI support. The ACPI support in the latest BIOS seems very rough, I think this is the first time they have ever implemented ACPI, so I would not count on it working properly just yet. > While were at it I have another question: When running on battery the > ethernet throughput drops to ~25Mbit/s. After a bit of experimenting > I found that this is connected to a BIOS entry about "CPU Power > Saving Mode". lspci shows that this changes "LnkCtl: ASPM L1 > Enabled" to "LnkCtl: ASPM L0s L1 Enabled". Having this config > option in the BIOS is inflexible. IIRC there was an app in > Windows which allows to configure it at runtime. Do you > know how to do it in Linux? I do not konw anything about this. Are you saying that Windows would allow you to turn the throughput back up at the expense of battery life through an application? Do you know what that application is called and where I could find it? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |