From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: n <xellos@bluebottle.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: PROBLEM: kernel 2.6.22.6 pata_pdc202xx_old.c limiting to UDMA/33 instead of UDMA/100 (UPDATED 2.6.22.6)
Date: Sat, 01 Sep 2007 18:58:29 +0400 [thread overview]
Message-ID: <46D97E15.2020005@ru.mvista.com> (raw)
In-Reply-To: <200708310904.l7V94YE4015312@mi0.bluebottle.com>
Dear n:
Please do *not* follow-up to a completely inderended thread. Start your
own, please. :-/
> Update with kernel 2.6.22.6 i am getting this error now
> ata2.00: ATA-6: ST3120026A, 3.06, max UDMA/100
Gathering courage and reply to libata bug report -- I'm more of the
drivers/ide/ guy with some SCSI background too... :-)
> here is the new error.
> ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> ata2.01: cmd ca/00:00:25:9c:fc/00:00:00:00:00/f6 tag 0 cdb 0x0 data
That was an attempt to read 1 sector from LBA 0xfc9c25 of rhe drive #1...
> 131072 out
> res 40/00:00:3f:00:00/00:00:00:00:00/f0 Emask 0x4 (timeout)
> ata2: port is slow to respond, please be patient (Status 0xfe)
> ata2: device not ready (errno=-16), forcing hardreset
> ata2: soft resetting port
> ata2.01: configured for UDMA/25
Whee! :-)
> ata2: EH complete
> here is dmseg output
[...]
> parport_pc: Current parallel port base: 0x378
> parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE]
> parport_pc: VIA parallel port: io=0x378, irq=7
> r8169 Gigabit Ethernet driver 2.2LK-NAPI loaded
> ACPI: PCI Interrupt 0000:00:0f.0[A] -> Link [LNKC] -> GSI 11 (level,
> low) -> IRQ 11
> eth0: RTL8169sb/8110sb at 0xe882c000, 00:14:d1:38:5e:25, IRQ 11
> 8139too Fast Ethernet driver 0.9.28
> ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 5
> PCI: setting IRQ 5 as level-triggered
> ACPI: PCI Interrupt 0000:00:10.0[A] -> Link [LNKD] -> GSI 5 (level, low)
> -> IRQ 5
> eth1: RealTek RTL8139 at 0x8800, 00:40:05:3a:15:c4, IRQ 5
> eth1: Identified 8139 chip type 'RTL-8100B/8139D'
RTL8139 are PoS chips (unless it's 8139D probably)... :-)
> via686a 0000:00:04.4: base address not set - upgrade BIOS or use
> force_addr=0xaddr
Hmmm, I'd assume that after that DMA wouldn't be possible but...
> Adding 390560k swap on /dev/sdc1. Priority:-1 extents:1 across:390560k
> XFS mounting filesystem sdc3
> Ending clean XFS mount for filesystem: sdc3
> XFS mounting filesystem sdc4
> Ending clean XFS mount for filesystem: sdc4
> XFS mounting filesystem sdd1
> Ending clean XFS mount for filesystem: sdd1
> XFS mounting filesystem sde1
> Ending clean XFS mount for filesystem: sde1
> XFS mounting filesystem sdf1
> Ending clean XFS mount for filesystem: sdf1
> ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
> ata2.01: (BMDMA stat 0x4)
> ata2.01: cmd ca/00:01:3f:00:00/00:00:00:00:00/f0 tag 0 cdb 0x0 data 512 out
That was an attempt to read the 1st sector from LBA 0x3f of the drive...
> res 51/84:00:3f:00:00/00:00:00:00:00/f0 Emask 0x10 (ATA bus error)
... which failed miserably, with UltraDMA CRC error. Hmmm...
> ata2: soft resetting port
> ata2.01: configured for UDMA/33
> ata2: EH complete
> ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
> ata2.01: (BMDMA stat 0x4)
> ata2.01: cmd ca/00:01:3f:00:00/00:00:00:00:00/f0 tag 0 cdb 0x0 data 512 out
> res 51/84:00:3f:00:00/00:00:00:00:00/f0 Emask 0x10 (ATA bus error)
... same sh!t happened again at UDNA/33 presumbly...
> ata2: soft resetting port
> ata2.01: configured for UDMA/33
> ata2: EH complete
> sd 1:0:1:0: [sdb] 234441648 512-byte hardware sectors (120034 MB)
> ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
> ata2.01: (BMDMA stat 0x4)
> ata2.01: cmd ca/00:01:3f:00:00/00:00:00:00:00/f0 tag 0 cdb 0x0 data 512 out
> res 51/84:00:3f:00:00/00:00:00:00:00/f0 Emask 0x10 (ATA bus error)
But the DMA write failed again with the same CRC error...
> ata2: soft resetting port
> ata2.01: configured for UDMA/33
> ata2: EH complete
> sd 1:0:1:0: [sdb] Write Protect is off
> sd 1:0:1:0: [sdb] Mode Sense: 00 3a 00 00
> ata2.01: limiting speed to UDMA/25:PIO4
> ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
> ata2.01: (BMDMA stat 0x4)
> ata2.01: cmd ca/00:01:3f:00:00/00:00:00:00:00/f0 tag 0 cdb 0x0 data 512 out
> res 51/84:00:3f:00:00/00:00:00:00:00/f0 Emask 0x10 (ATA bus error)
... and again.
> ata2: soft resetting port
> ata2.01: configured for UDMA/25
> ata2: EH complete
> ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
> ata2.01: (BMDMA stat 0x4)
> ata2.01: cmd ca/00:01:3f:00:00/00:00:00:00:00/f0 tag 0 cdb 0x0 data 512 out
> res 51/84:00:3f:00:00/00:00:00:00:00/f0 Emask 0x10 (ATA bus error)
... and again, even with UDMA 25.
> ata2: soft resetting port
> ata2.01: configured for UDMA/25
> ata2: EH complete
> sd 1:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't
> support DPO or FUA
> ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
> ata2.01: (BMDMA stat 0x4)
> ata2.01: cmd ca/00:01:3f:00:00/00:00:00:00:00/f0 tag 0 cdb 0x0 data 512 out
> res 51/84:00:3f:00:00/00:00:00:00:00/f0 Emask 0x10 (ATA bus error)
Bug is quite persistent... something's up!
> ata2: soft resetting port
> ata2.01: configured for UDMA/25
> sd 1:0:1:0: [sdb] Result: hostbyte=0x00 driverbyte=0x08
> sd 1:0:1:0: [sdb] Sense Key : 0xb [current] [descriptor]
> Descriptor sense data with sense descriptors (in hex):
> 72 0b 47 00 00 00 00 0c 00 0a 80 00 00 00 00 00
> 00 00 00 3f
> sd 1:0:1:0: [sdb] ASC=0x47 ASCQ=0x0
> end_request: I/O error, dev sdb, sector 63
Yeah, 63 == 0x3f.
> ata2: EH complete
> sd 1:0:1:0: [sdb] 234441648 512-byte hardware sectors (120034 MB)
> Filesystem "sdb1": Disabling barriers, trial barrier write failed
> sd 1:0:1:0: [sdb] Write Protect is off
> sd 1:0:1:0: [sdb] Mode Sense: 00 3a 00 00
> XFS mounting filesystem sdb1
> sd 1:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't
> support DPO or FUA
> sd 1:0:1:0: [sdb] 234441648 512-byte hardware sectors (120034 MB)
> sd 1:0:1:0: [sdb] Write Protect is off
> sd 1:0:1:0: [sdb] Mode Sense: 00 3a 00 00
> sd 1:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't
> support DPO or FUA
> ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> ata2.01: cmd ca/00:00:25:9c:fc/00:00:00:00:00/f6 tag 0 cdb 0x0 data
> 131072 out
Thrying to DMA write 0 sectors at 0xc9c25.
> res 40/00:00:3f:00:00/00:00:00:00:00/f0 Emask 0x4 (timeout)
Hm, 0x40 is not normal a status value... usually, it's 0x50. But it's
alright anyway.
> ata2: port is slow to respond, please be patient (Status 0xfe)
> ata2: device not ready (errno=-16), forcing hardreset
Hm...
> ata2: soft resetting port
> ata2.01: configured for UDMA/25
> ata2: EH complete
> ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> ata2.01: cmd ca/00:00:25:9c:fc/00:00:00:00:00/f6 tag 0 cdb 0x0 data
> 131072 out
> res 40/00:00:3f:00:00/00:00:00:00:00/f0 Emask 0x4 (timeout)
Same here.
> ata2: port is slow to respond, please be patient (Status 0xfe)
> ata2: device not ready (errno=-16), forcing hardreset
> ata2: soft resetting port
> ata2.01: configured for UDMA/25
> ata2: EH complete
> ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> ata2.01: cmd ca/00:00:25:9c:fc/00:00:00:00:00/f6 tag 0 cdb 0x0 data
> 131072 out
> res 40/00:00:3f:00:00/00:00:00:00:00/f0 Emask 0x4 (timeout)
Again strange status after writinng 0 sectors the same LBA.
[The same us repeating over and over again...]
> sd 1:0:1:0: [sdb] Result: hostbyte=0x00 driverbyte=0x08
> sd 1:0:1:0: [sdb] Sense Key : 0xb [current] [descriptor]
> Descriptor sense data with sense descriptors (in hex):
> 72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00
Hm, never seen sense format 0x72... :-)
The 2nd byte is prolly a sense key ABORTED COMMAND?
> 00 00 00 3f
Aha, 0x3f again, this time in the SCSI sense... I've looked thru the SCSI
spacs and found nought aboutthis format. :-(
> sd 1:0:1:0: [sdb] ASC=0x0 ASCQ=0x0
> end_request: I/O error, dev sdb, sector 117218341
> ata2: EH complete
> ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> ata2.01: cmd ca/00:00:25:9d:fc/00:00:00:00:00/f6 tag 0 cdb 0x0 data
> 131072 out
> res 40/00:00:3f:00:00/00:00:00:00:00/f0 Emask 0x4 (timeout)
Then everything happily continues in the same vein but t UDMA/25 mode.
[...]
> Here is my previous post
> (not sure if anyone read it im new to mailing lists also ata1 below is
> ata2 above since i changed it to port 2 so its the same seagate drive.)
> hello, with kernel 2.6.22.5 using the new pata_pdc202xx_old driver it
> doesn't
> detect the cable right on this seagate drive (i tried switching ports /
> cables ...etc)
Probably host side detecton is borked. The drived is residing alone on
that cable?
> it detects the maxtor drive fine no matter what port its on, the seagate
> doesnt detect correctly on either port
Hrm, then maybe it's indeed device side problem (but IIRC, libata used to
ignore device side reporting)./
> ata1.00: ATA-6: ST3120026A, 3.06, max UDMA/100
> ata1.00: 234441648 sectors, multi 16: LBA48
> ata1.00: limited to UDMA/33 due to 40-wire cable
> ata1.00: configured for UDMA/33
> ata2.00: ATA-7: Maxtor 6B200R0, max UDMA/133
> ata2.00: 398297088 sectors, multi 16: LBA48
> ata2.00: configured for UDMA/100
> i was searching goolge and i found other uses with the same problem and had
> seagate drives (maybe the cable detect code is differnt in seagate?)
Hardly so...
> btw only devices sda and sdb are on the pata_pdc202xx_old card.
Not on the same cable?
> i also get this error about 50 of them
> (dmsg cut top output where it had info about the cable error) anyways if
> you
> scroll down you will see errors like this
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
> ata1.00: (BMDMA stat 0x4)
> ata1.00: cmd ca/00:01:3f:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 512 out
> res 51/84:00:3f:00:00/00:00:00:00:00/e0 Emask 0x10 (ATA bus error)
Write of single sector 63 fails miserably with UltraDMA CRC... although,
if you're not using UltraDMA at this moment, 0x84 may mean something
different: bad/uncortrectable sector.
> ata1: soft resetting port
> ata1.00: configured for UDMA/33
> ata1: EH complete ..etc
>
> .... Ends up here
>
> ata1: EH complete
> ata1.00: limiting speed to PIO4
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
> ata1.00: (BMDMA stat 0x4)
> ata1.00: cmd ca/00:00:21:9d:fc/00:00:00:00:00/e6 tag 0 cdb 0x0 data 131072
> out
> res 51/84:00:21:9d:fc/00:00:00:00:00/e6 Emask 0x10 (ATA bus error)
Hmmm, the driver had just lied to you saying that it downgraded to PIO4 --
it still issues WRITE DMA command which failed as usual...
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
> ata1.00: (BMDMA stat 0x4)
> ata1.00: cmd ca/00:01:3f:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 512 out
> res 51/84:00:3f:00:00/00:00:00:00:00/e0 Emask 0x10 (ATA bus error)
> ata1: soft resetting port
> ata1.00: configured for UDMA/33
> ata1: EH complete
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
> ata1.00: (BMDMA stat 0x4)
> ata1.00: cmd ca/00:01:3f:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 512 out
> res 51/84:00:3f:00:00/00:00:00:00:00/e0 Emask 0x10 (ATA bus error)
"Then it strted all over again..."
> ata1: soft resetting port
> ata1.00: configured for UDMA/25
> sd 0:0:0:0: [sda] Result: hostbyte=0x00 driverbyte=0x08
> sd 0:0:0:0: [sda] Sense Key : 0xb [current] [descriptor]
> Descriptor sense data with sense descriptors (in hex):
> 72 0b 47 00 00 00 00 0c 00 0a 80 00 00 00 00 00
> 00 00 00 3f
> sd 0:0:0:0: [sda] ASC=0x47 ASCQ=0x0
Hh, SCSI msgs cleared the forat up for me: byte 1 is a sense key, byte 2
is ASQ (0x47 means SCSI parity error)...
> end_request: I/O error, dev sda, sector 63
> ata1: EH complete
> sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors (120034 MB)
> Filesystem "sda1": Disabling barriers, trial barrier write failed
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> XFS mounting filesystem sda1
> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
> support
> DPO or FUA
> sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors (120034 MB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
> support
> DPO or FUA
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
> ata1.00: (BMDMA stat 0x4)
> ata1.00: cmd ca/00:00:21:9c:fc/00:00:00:00:00/e6 tag 0 cdb 0x0 data 131072
> out
> res 51/84:00:21:9c:fc/00:00:00:00:00/e6 Emask 0x10 (ATA bus error)
Again failinig DMA write of 0 sectors at LBA 826401...
> ata1: soft resetting port
> ata1.00: configured for UDMA/25
> ata1: EH complete
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
> ata1.00: (BMDMA stat 0x4)
> ata1.00: cmd ca/00:00:21:9c:fc/00:00:00:00:00/e6 tag 0 cdb 0x0 data 131072
> out
> res 51/84:00:21:9c:fc/00:00:00:00:00/e6 Emask 0x10 (ATA bus error)
> ata1: soft resetting port
> ata1.00: configured for UDMA/25
> ata1: EH complete
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
> ata1.00: (BMDMA stat 0x4)
> ata1.00: cmd ca/00:00:21:9c:fc/00:00:00:00:00/e6 tag 0 cdb 0x0 data 131072
> out
> res 51/84:00:21:9c:fc/00:00:00:00:00/e6 Emask 0x10 (ATA bus error)
> ata1: soft resetting port
> ata1.00: configured for UDMA/25
> ata1: EH complete
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
> ata1.00: (BMDMA stat 0x4)
> ata1.00: cmd ca/00:00:21:9c:fc/00:00:00:00:00/e6 tag 0 cdb 0x0 data 131072
> out
> res 51/84:00:21:9c:fc/00:00:00:00:00/e6 Emask 0x10 (ATA bus error)
> ata1: soft resetting port
> ata1.00: configured for UDMA/25
> ata1: EH complete
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
> ata1.00: (BMDMA stat 0x4)
It means that IDE DMA has signalled an interrupt
> ata1.00: cmd ca/00:00:21:9c:fc/00:00:00:00:00/e6 tag 0 cdb 0x0 data 131072
> out
> res 51/84:00:21:9c:fc/00:00:00:00:00/e6 Emask 0x10 (ATA bus error)
> ata1: soft resetting port
> ata1.00: configured for UDMA/25
> ata1: EH complete
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
> ata1.00: (BMDMA stat 0x4)
> ata1.00: cmd ca/00:00:21:9c:fc/00:00:00:00:00/e6 tag 0 cdb 0x0 data 131072
> out
> res 51/84:00:21:9c:fc/00:00:00:00:00/e6 Emask 0x10 (ATA bus error)
> ata1: soft resetting port
> ata1.00: configured for UDMA/25
> sd 0:0:0:0: [sda] Result: hostbyte=0x00 driverbyte=0x08
> sd 0:0:0:0: [sda] Sense Key : 0xb [current] [descriptor]
> Descriptor sense data with sense descriptors (in hex):
> 72 0b 47 00 00 00 00 0c 00 0a 80 00 00 00 00 00
> 06 fc 9c 21
Aha, those last 4 bytes a big-endian address of a requested LBA to write to
> after the kernel finnishes booting i can mount that drive fine (also all
> the xfs_check xfs_repair ..etc say there is no errors) but i think the drive is
> in pio4 by the time its done.
From looking at the logs I got a feeling that the speed downgraded didn't
work all the way to PIO...
> the ide old driver seemed to work ok with this drive also the system
> mainboard ide ports work too.
Aha, thanks! :-)
> i tried changing the drive jumpers around and that also didnt help
> just to add i tried switching my drives around i moved a wd drive to port 2
> of the pdc controller and it worked fine so if a maxtor and a wd drive is
> hooked up it detects as udma100, this seems to be a error with seagate
> drives only, and i should also note i tried the seagate on the mainboard
> chipset (uses the pata_via.c driver) and it detected the seagate fine and
> set udma 100 on it.
Yeah, all that is very confusing...
MBR, Sergei
next prev parent reply other threads:[~2007-09-01 14:55 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-29 16:29 hda: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error } John Sigler
2007-08-29 16:46 ` Alan Cox
2007-08-30 8:17 ` John Sigler
[not found] ` <46D69E03.9080403@vc.cvut.cz>
2007-08-30 12:30 ` John Sigler
2007-08-30 15:10 ` John Sigler
2007-08-30 23:31 ` Alan Cox
2007-08-31 8:22 ` John Sigler
2007-08-31 9:04 ` PROBLEM: kernel 2.6.22.6 pata_pdc202xx_old.c limiting to UDMA/33 instead of UDMA/100 (UPDATED 2.6.22.6) n
2007-08-31 9:04 ` n
2007-09-01 14:58 ` Sergei Shtylyov [this message]
2007-08-31 11:49 ` hda: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error } Alan Cox
[not found] ` <311601c90708301534g47b2bca7t77debde058781572@mail.gmail.com>
2007-08-31 8:41 ` John Sigler
2007-09-01 15:48 ` Sergei Shtylyov
2007-08-30 14:05 ` Alan Cox
2007-08-31 20:22 ` Sergei Shtylyov
2007-09-01 15:38 ` Sergei Shtylyov
2007-09-03 13:17 ` John Sigler
2007-09-03 13:40 ` Sergei Shtylyov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46D97E15.2020005@ru.mvista.com \
--to=sshtylyov@ru.mvista.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=xellos@bluebottle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).