Had the following kernel panic with 2.6.15-rc7 + libata1 2.6.15-rc6
patch (http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/).
Ocurred when calling "hddtemp" on a SATA device which has been in
standby. Maybe someone is interesed:
Dec 31 12:45:08 DatenGrab kernel: ATA: abnormal status 0xFF on port
0xE02A821CDec 31 12:45:11 DatenGrab kernel: ata3: unknown timeout, cmd
0xb0 stat 0xffDec 31 12:45:11 DatenGrab kernel: ata3: translated ATA
stat/err 0xff/00 to SCSI SK/ASC/ASCQ 0xb/47/00Dec 31 12:45:11 DatenGrab
kernel: ata3: status=0xff { Busy }Dec 31 12:45:11 DatenGrab kernel:
Assertion failed! qc !=
NULL,drivers/scsi/libata-core.c,ata_pio_block,line=3216Dec 31 12:45:11
DatenGrab kernel: e02d9a3e
Dec 31 12:45:11 DatenGrab kernel: Modules linked in: iptable_filter
ip_tables w83627hf hwmon_vid hwmon eeprom i2c_isa nfsd edd ipv6 button
battery ac af_packet xfs exportfs reiserfs ohci1394 ieee1394 sk98lin
generic i2c_i801 i2c_core i8xx_tco shpchp pci_hotplug intel_agp agpgart
uhci_hcd raid5 xor parport_pc lp parport sata_promise libata dm_mod sg
skge ohci_hcd ehci_hcd usb_storage usbcore fan thermal processor piix
sd_mod scsi_mod ide_disk ide_core
Dec 31 12:45:11 DatenGrab kernel: CPU: 0Dec 31 12:45:11 DatenGrab
kernel: EIP: 0060:[<e02d9a3e>] Not tainted VLI
Dec 31 12:45:11 DatenGrab kernel: EFLAGS: 00010292
(2.6.15-rc6-default) Dec 31 12:45:11 DatenGrab kernel: EIP is at
ata_pio_block+0xb9/0xfd [libata]
Dec 31 12:45:11 DatenGrab kernel: eax: 00000056 ebx: c14b5284 ecx:
00000000 edx: 00000000
Dec 31 12:45:11 DatenGrab kernel: esi: 58894f50 edi: 00000000 ebp:
c14b5284 esp: de3a7f70
Dec 31 12:45:11 DatenGrab kernel: ds: 007b es: 007b ss: 0068
Dec 31 12:45:11 DatenGrab kernel: Process ata/0 (pid: 2181,
threadinfo=de3a6000 task=de371a90)
Dec 31 12:45:11 DatenGrab kernel: Stack: c14b5284 def063c0 00000287
e02d9b00 c14b583c c01230a6 e02d9ae3 00000001
Dec 31 12:45:11 DatenGrab kernel: 00000000 00000000 00010000
00000000 00000000 de371a90 c01150bc 00100100
Dec 31 12:45:11 DatenGrab kernel: 00200200 ffffffff ffffffff
de3a6000 de0dbf54 def063c0 c0122f67 c0125c8f
Dec 31 12:45:11 DatenGrab kernel: Call Trace:
Dec 31 12:45:11 DatenGrab kernel: [<e02d9b00>] ata_pio_task+0x1d/0x54
[libata]
Dec 31 12:45:11 DatenGrab kernel: [<c01230a6>] worker_thread+0x13f/0x19d
Dec 31 12:45:11 DatenGrab kernel: [<e02d9ae3>] ata_pio_task+0x0/0x54
[libata]
Dec 31 12:45:11 DatenGrab kernel: [<c01150bc>]
default_wake_function+0x0/0xc
Dec 31 12:45:11 DatenGrab kernel: [<c0122f67>] worker_thread+0x0/0x19d
Dec 31 12:45:11 DatenGrab kernel: [<c0125c8f>] kthread+0x63/0x8f
Dec 31 12:45:11 DatenGrab kernel: [<c0125c2c>] kthread+0x0/0x8f
Dec 31 12:45:11 DatenGrab kernel: [<c0101281>] kernel_thread_helper+0x5/0xb
Dec 31 12:45:11 DatenGrab kernel: Code: 89 df 81 c7 d4 04 00 00 75 21 68
90 0c 00 00 68 fb cd 2d e0 68 ef cf 2d e0 68 b0 d5 2d e0 68 61 d0 2d e0
e8 19 e1 e3 df 83 c4 14 <8a> 47 14 83 e8 05 3c 02 77 1b 83 e6 08 75 0c
c7 83 e4 05 00 00
Dec 31 12:45:14 DatenGrab kernel: <3>ata5: unknown timeout, cmd 0xb0
stat 0x58
Ralf M?ller schrieb:
> Had the following kernel panic with 2.6.15-rc7 + libata1 2.6.15-rc6
> patch (http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/).
> Ocurred when calling "hddtemp" on a SATA device which has been in
> standby. Maybe someone is interesed:
>
> Dec 31 12:45:08 DatenGrab kernel: ATA: abnormal status 0xFF on port
> 0xE02A821CDec 31 12:45:11 DatenGrab kernel: ata3: unknown timeout, cmd
> 0xb0 stat 0xffDec 31 12:45:11 DatenGrab kernel: ata3: translated ATA
> stat/err 0xff/00 to SCSI SK/ASC/ASCQ 0xb/47/00Dec 31 12:45:11 DatenGrab
> kernel: ata3: status=0xff { Busy }Dec 31 12:45:11 DatenGrab kernel:
> Assertion failed! qc !=
> NULL,drivers/scsi/libata-core.c,ata_pio_block,line=3216Dec 31 12:45:11
> DatenGrab kernel: e02d9a3e
> Dec 31 12:45:11 DatenGrab kernel: Modules linked in: iptable_filter
> ip_tables w83627hf hwmon_vid hwmon eeprom i2c_isa nfsd edd ipv6 button
> battery ac af_packet xfs exportfs reiserfs ohci1394 ieee1394 sk98lin
> generic i2c_i801 i2c_core i8xx_tco shpchp pci_hotplug intel_agp agpgart
> uhci_hcd raid5 xor parport_pc lp parport sata_promise libata dm_mod sg
> skge ohci_hcd ehci_hcd usb_storage usbcore fan thermal processor piix
> sd_mod scsi_mod ide_disk ide_core
> Dec 31 12:45:11 DatenGrab kernel: CPU: 0Dec 31 12:45:11 DatenGrab
> kernel: EIP: 0060:[<e02d9a3e>] Not tainted VLI
> Dec 31 12:45:11 DatenGrab kernel: EFLAGS: 00010292 (2.6.15-rc6-default)
> Dec 31 12:45:11 DatenGrab kernel: EIP is at ata_pio_block+0xb9/0xfd
> [libata]
> Dec 31 12:45:11 DatenGrab kernel: eax: 00000056 ebx: c14b5284 ecx:
> 00000000 edx: 00000000
> Dec 31 12:45:11 DatenGrab kernel: esi: 58894f50 edi: 00000000 ebp:
> c14b5284 esp: de3a7f70
> Dec 31 12:45:11 DatenGrab kernel: ds: 007b es: 007b ss: 0068
> Dec 31 12:45:11 DatenGrab kernel: Process ata/0 (pid: 2181,
> threadinfo=de3a6000 task=de371a90)
> Dec 31 12:45:11 DatenGrab kernel: Stack: c14b5284 def063c0 00000287
> e02d9b00 c14b583c c01230a6 e02d9ae3 00000001
> Dec 31 12:45:11 DatenGrab kernel: 00000000 00000000 00010000
> 00000000 00000000 de371a90 c01150bc 00100100
> Dec 31 12:45:11 DatenGrab kernel: 00200200 ffffffff ffffffff
> de3a6000 de0dbf54 def063c0 c0122f67 c0125c8f
> Dec 31 12:45:11 DatenGrab kernel: Call Trace:
> Dec 31 12:45:11 DatenGrab kernel: [<e02d9b00>] ata_pio_task+0x1d/0x54
> [libata]
> Dec 31 12:45:11 DatenGrab kernel: [<c01230a6>] worker_thread+0x13f/0x19d
> Dec 31 12:45:11 DatenGrab kernel: [<e02d9ae3>] ata_pio_task+0x0/0x54
> [libata]
> Dec 31 12:45:11 DatenGrab kernel: [<c01150bc>]
> default_wake_function+0x0/0xc
> Dec 31 12:45:11 DatenGrab kernel: [<c0122f67>] worker_thread+0x0/0x19d
> Dec 31 12:45:11 DatenGrab kernel: [<c0125c8f>] kthread+0x63/0x8f
> Dec 31 12:45:11 DatenGrab kernel: [<c0125c2c>] kthread+0x0/0x8f
> Dec 31 12:45:11 DatenGrab kernel: [<c0101281>]
> kernel_thread_helper+0x5/0xb
> Dec 31 12:45:11 DatenGrab kernel: Code: 89 df 81 c7 d4 04 00 00 75 21 68
> 90 0c 00 00 68 fb cd 2d e0 68 ef cf 2d e0 68 b0 d5 2d e0 68 61 d0 2d e0
> e8 19 e1 e3 df 83 c4 14 <8a> 47 14 83 e8 05 3c 02 77 1b 83 e6 08 75 0c
> c7 83 e4 05 00 00
> Dec 31 12:45:14 DatenGrab kernel: <3>ata5: unknown timeout, cmd 0xb0
> stat 0x58
Sorry - the above oops has been with plain 2.6.15-rc7 - the libata1
patch has been applied but not yet installed at the time of this kernel
panic. With the libata1 patch installed the sata controller is still
going completly offline when calling hddtemp on a disk in standby but
there is no kernel panic anymore.
Ralf
On Sun, Jan 01, 2006 at 03:41:14PM +0100, Ralf M?ller wrote:
> Ralf M?ller schrieb:
> >Had the following kernel panic with 2.6.15-rc7 + libata1 2.6.15-rc6
> >patch (http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/).
> >Ocurred when calling "hddtemp" on a SATA device which has been in
> >standby. Maybe someone is interesed:
> >
> >Dec 31 12:45:08 DatenGrab kernel: ATA: abnormal status 0xFF on port
> >0xE02A821CDec 31 12:45:11 DatenGrab kernel: ata3: unknown timeout, cmd
> >0xb0 stat 0xffDec 31 12:45:11 DatenGrab kernel: ata3: translated ATA
> >stat/err 0xff/00 to SCSI SK/ASC/ASCQ 0xb/47/00Dec 31 12:45:11 DatenGrab
> >kernel: ata3: status=0xff { Busy }Dec 31 12:45:11 DatenGrab kernel:
> >Assertion failed! qc !=
> >NULL,drivers/scsi/libata-core.c,ata_pio_block,line=3216Dec 31 12:45:11
> >DatenGrab kernel: e02d9a3e
> >Dec 31 12:45:11 DatenGrab kernel: Modules linked in: iptable_filter
> >ip_tables w83627hf hwmon_vid hwmon eeprom i2c_isa nfsd edd ipv6 button
> >battery ac af_packet xfs exportfs reiserfs ohci1394 ieee1394 sk98lin
> >generic i2c_i801 i2c_core i8xx_tco shpchp pci_hotplug intel_agp agpgart
> >uhci_hcd raid5 xor parport_pc lp parport sata_promise libata dm_mod sg
> >skge ohci_hcd ehci_hcd usb_storage usbcore fan thermal processor piix
> >sd_mod scsi_mod ide_disk ide_core
> >Dec 31 12:45:11 DatenGrab kernel: CPU: 0Dec 31 12:45:11 DatenGrab
> >kernel: EIP: 0060:[<e02d9a3e>] Not tainted VLI
> >Dec 31 12:45:11 DatenGrab kernel: EFLAGS: 00010292 (2.6.15-rc6-default)
> >Dec 31 12:45:11 DatenGrab kernel: EIP is at ata_pio_block+0xb9/0xfd
> >[libata]
> >Dec 31 12:45:11 DatenGrab kernel: eax: 00000056 ebx: c14b5284 ecx:
> >00000000 edx: 00000000
> >Dec 31 12:45:11 DatenGrab kernel: esi: 58894f50 edi: 00000000 ebp:
> >c14b5284 esp: de3a7f70
> >Dec 31 12:45:11 DatenGrab kernel: ds: 007b es: 007b ss: 0068
> >Dec 31 12:45:11 DatenGrab kernel: Process ata/0 (pid: 2181,
> >threadinfo=de3a6000 task=de371a90)
> >Dec 31 12:45:11 DatenGrab kernel: Stack: c14b5284 def063c0 00000287
> >e02d9b00 c14b583c c01230a6 e02d9ae3 00000001
> >Dec 31 12:45:11 DatenGrab kernel: 00000000 00000000 00010000
> >00000000 00000000 de371a90 c01150bc 00100100
> >Dec 31 12:45:11 DatenGrab kernel: 00200200 ffffffff ffffffff
> >de3a6000 de0dbf54 def063c0 c0122f67 c0125c8f
> >Dec 31 12:45:11 DatenGrab kernel: Call Trace:
> >Dec 31 12:45:11 DatenGrab kernel: [<e02d9b00>] ata_pio_task+0x1d/0x54
> >[libata]
> >Dec 31 12:45:11 DatenGrab kernel: [<c01230a6>] worker_thread+0x13f/0x19d
> >Dec 31 12:45:11 DatenGrab kernel: [<e02d9ae3>] ata_pio_task+0x0/0x54
> >[libata]
> >Dec 31 12:45:11 DatenGrab kernel: [<c01150bc>]
> >default_wake_function+0x0/0xc
> >Dec 31 12:45:11 DatenGrab kernel: [<c0122f67>] worker_thread+0x0/0x19d
> >Dec 31 12:45:11 DatenGrab kernel: [<c0125c8f>] kthread+0x63/0x8f
> >Dec 31 12:45:11 DatenGrab kernel: [<c0125c2c>] kthread+0x0/0x8f
> >Dec 31 12:45:11 DatenGrab kernel: [<c0101281>]
> >kernel_thread_helper+0x5/0xb
> >Dec 31 12:45:11 DatenGrab kernel: Code: 89 df 81 c7 d4 04 00 00 75 21 68
> >90 0c 00 00 68 fb cd 2d e0 68 ef cf 2d e0 68 b0 d5 2d e0 68 61 d0 2d e0
> >e8 19 e1 e3 df 83 c4 14 <8a> 47 14 83 e8 05 3c 02 77 1b 83 e6 08 75 0c
> >c7 83 e4 05 00 00
> >Dec 31 12:45:14 DatenGrab kernel: <3>ata5: unknown timeout, cmd 0xb0
> >stat 0x58
>
> Sorry - the above oops has been with plain 2.6.15-rc7 - the libata1
> patch has been applied but not yet installed at the time of this kernel
> panic. With the libata1 patch installed the sata controller is still
> going completly offline when calling hddtemp on a disk in standby but
> there is no kernel panic anymore.
Is this problem present with older kernel (e.g. 2.6.14.x) or is it a
newly introduced bug?
I've put Jeff into the Cc of this email since he is the SATA maintainer.
> Ralf
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Adrian Bunk schrieb:
> Is this problem present with older kernel (e.g. 2.6.14.x) or is it a
> newly introduced bug?
It is a newly installed system - 2.6.15-rc6 has been the first kernel at
all on this machine - this kernel crashed too. After that I upgraded to
2.6.15-rc7 - it crashed as written in the initial mail. Next was to
apply the libata1 patch. It did not give a kernel panic but shut down
the SATA subsystem (the hardware is a Promise SATA II 300 TX4 PDC 20718
and an onboard Promise SATA II 150 PDC20579) - non of the six attached
disks has been accessible anymore after calling hddtemp on one of the
disks which have been in standby. Calling hddtemp on a spinning disk
works without a problem.
A further problem is that calling "hdparm -C" _always_ give "drive state
is: standby" - even when the disks are clearly active. Maybe this
indicates something to you.
I can try to downgrade to 2.6.14 if you like. I started with 2.6.15
because I have been told it is the first kernel which is able to deal
with "hdparm -S x" / "hdparm -y" for SATA devices.
> I've put Jeff into the Cc of this email since he is the SATA maintainer.
Thanks.
Regards
Ralf
Ralf M?ller wrote:
>
> A further problem is that calling "hdparm -C" _always_ give "drive state
> is: standby" - even when the disks are clearly active. Maybe this
> indicates something to you.
MMmm.. yes, it does that here, too.
This is probably a bug somewhere in the libata passthru code,
or in the HDIO_* translation code.
Cheers
Mark Lord schrieb:
> Ralf M?ller wrote:
>> A further problem is that calling "hdparm -C" _always_ give "drive
>> state is: standby" - even when the disks are clearly active. Maybe
>> this indicates something to you.
>
>
> MMmm.. yes, it does that here, too.
> This is probably a bug somewhere in the libata passthru code,
> or in the HDIO_* translation code.
If I'm right that this should be handled in "ata_cmd_ioctl()" then there
is no copy_to_user() at all for WIN_CHECKPOWERMODE[12] - so there is
no chance to get data back. Are there any known plans to fix this?
Ralf