Skip to contentSkip to conversation

Kernel panic with 2.6.15-rc7 + libata1 patch

DISCUSSION Ralf Müller 3 participants 6 messages Jan 1, 2006 – Jan 3, 2006 libata

lore
Share & tools
lore
#0 lore raw

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
#1 lore raw
Quoted 17 lines · Ralf Müller

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
Quoted 8 lines
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

#2 lore raw
Quoted 59 lines · Ralf Müller
Quoted 56 lines · Ralf Müller

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 
Quoted 1 line

stat 0x58

Quoted 5 lines

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.

Quoted 1 line

Ralf

cu
Adrian

Signature · 4 lines
       "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
#3 lore raw
Quoted 1 line · Adrian Bunk

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.

Quoted 1 line

I've put Jeff into the Cc of this email since he is the SATA maintainer.

Thanks.

Regards
Ralf

#4 lore raw
Quoted 2 lines · Ralf Müller

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

#5 lore raw

Re: hdparm -C always give drive state is standby (was: Kernel panic with 2.6.15-rc7 + libata1 patch)

Quoted 7 lines · Mark Lord
Quoted 1 line · Ralf Müller

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