Hello Tejun,

I've tested your patch yesterday, but no luck, I can't find any difference
in the resulting boot log.

Please find attached an archive containing :
- dmesg.2.6.20-rc7 : full dmesg with stock kernel
- dmesg.patch : full dmesg with your patch included.

I've also added a lspci -vvv, a cat /proc/interrupts and a cat /proc/ioports
in case this could help.

Also, please note that libata is complaining :
ATA: abnormal status 0x7F on port 0x177
and later :
ATA: abnormal status 0x7F on port 0x9807

I don't know if this is important or not.

Sorry for the bad news,
Regards,
Paul

Paul Rolland, rol(at)as2917.net
ex-AS2917 Network administrator and Peering Coordinator

--

Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur
"Some people dream of success... while others wake up and work hard at it"

"I worry about my child and the Internet all the time, even though she's too
young to have logged on yet. Here's what I worry about. I worry that 10 or 15
years from now, she will come to me and say 'Daddy, where were you when they
took freedom of the press away from the Internet?'"
--Mike Godwin, Electronic Frontier Foundation

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Paul Rolland
> Sent: Monday, February 12, 2007 12:19 PM
> To: 'Tejun Heo'
> Cc: 'Alan'; 'Robert Hancock'; 'Linux Kernel Mailing List'
> Subject: RE: AHCI - remove probing of ata2
>
> Hello Tejun,
>
> > You have a Maxtor connected to that port, right? That's caused by
>
> Waoh, you are using crystal ball ? :) You are right, this is a Maxtor
> disk, 250 MB. If you want more details about this disk, I can send you
> a complete details.
>
> > firmware bug. Future kernels will consider that condition as
> > protocol
> > violation and blacklist the drive such that NCQ is not used
> on it. I
> > think it can be dangerous on rare corner/error cases but
> there hasn't
> > been any actual report of problems caused by that, so no need
> > to worry
> > about it too much. If it bothers you, you can turn NCQ off
> > using sysfs
> > node. Take a look at FAQ section of http://linux-ata.org
>
> I'm just slightly worried about that, and because all this libata
> stuff is quite "new", I prefer to report everything I can
> see, considering
> that I can test patches on this machine if people need me to do so.
> So, consider this machine as some kind of playground if you have
> some code you want someone to test.
>
> > Slightly OT, but it's generally a good idea to use LABELs to access
> > filesystems. With so many ports and EH dynamics including
> > hotplug, it's
> > much more difficult to keep device names persistent and
> remember them.
>
> Yes, that's what I should do, but I've never really like that stuff ;(
>
> > > So, 2.6.20-rc7 results are :
> > > - ata2 probing still very long and delaying boot a lot,
> >
> > That's sil4726's config device acting weird. When reset as
> a normal
> > device (not PMP device), sil4726 acts as a normal ATA
> device which is
> > used to configure how the chip behaves. Unfortunately, the
> emulation
> > seems to contain some flaws and cause lots of delays as
> you've seen.
> > I'm attaching a patch to clear TF before IDENTIFY which
> fixes similar
> > IDENTIFY failures on buggy ATAPI devices.
>
> OK, will try this tonite (I'm sorry, this is my home comp.,
> and I'm at the
> office right now - will tell you tomorrow).
>
> > > - Jmicron PATA still not working, and doesn't even detect
> > the DVD-ROM on
> > > the port.
> >
> > This problem is likely to be fixed by clearing TF before IDENTIFY.
> >
> > So, please test the attached patch and report the result.
>
> Will do, and will test more if you more that are to be tested !
>
> BTW, maybe OT, but what about setting a list of people willing to test
> patches together with their configurations so that they can be send
> patches related to their hardware ? That could be useful to
> people developing
> drivers...
>
> Regards,
> Paul
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>

Attachments:

data.tar.bz2 (13.08 kB)

2007-02-13 20:20:41

by Tejun Heo

[permalink] [raw]

Subject: Re: AHCI - remove probing of ata2

Hello, Paul.

Paul Rolland wrote:
> Also, please note that libata is complaining :
> ATA: abnormal status 0x7F on port 0x177
> and later :
> ATA: abnormal status 0x7F on port 0x9807

You can ignore the above. The errors on ata2 are due to SIMG storage
processor and will probably fixed when PMP support is implemented. The
latter errors on pata_jmicron is probably due to lack of proper mode
programming on that driver. I'll look into that.

Thanks.

--
tejun

2007-02-14 01:26:18

by Greg Trounson

[permalink] [raw]

Subject: Re: AHCI - remove probing of ata2

At the risk of sounding like a "me too" post:

I also have an Asus P5W-DH, with the following drives connected:

SATA: ST3250820AS, connected to sata1
PATA: HL-DT-ST GSA-H12N, ATAPI DVD Writer, Primary master

On bootup of 2.6.19 and 2.6.20, the kernel stalls for 1 minute when probing sata2,
eventually giving up and continuing the boot process. There is no physical sata2
connector on the Motherboard, just solder lugs between sata1 and sata3. From other users
I understand this is really a Silicon Image SIL4723 SATA to 2-Port SATA splitter. It is
detected by the kernel as a disk, as below.

The relevant part of the boot process looks like:
...
libata version 2.00 loaded.
ahci 0000:00:1f.2: version 2.0
ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 23 (level, low) -> IRQ 22
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode
ahci 0000:00:1f.2: flags: 64bit ncq led clo pio slum part
ata1: SATA max UDMA/133 cmd 0xF882A900 ctl 0x0 bmdma 0x0 irq 219
ata2: SATA max UDMA/133 cmd 0xF882A980 ctl 0x0 bmdma 0x0 irq 219
ata3: SATA max UDMA/133 cmd 0xF882AA00 ctl 0x0 bmdma 0x0 irq 219
ata4: SATA max UDMA/133 cmd 0xF882AA80 ctl 0x0 bmdma 0x0 irq 219
scsi0 : ahci
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-7, max UDMA/133, 488397168 sectors: LBA48 NCQ (depth 31/32)
ata1.00: ata1: dev 0 multi count 16
ata1.00: configured for UDMA/133
scsi1 : ahci
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

...waits 20 seconds...

ata2.00: qc timeout (cmd 0xec)
ata2.00: failed to IDENTIFY (I/O error, err_mask=0x104)

...waits 5 seconds...

ata2: port is slow to respond, please be patient (Status 0x80)

...waits 30 seconds...

ata2: port failed to respond (30 secs, Status 0x80)
ata2: COMRESET failed (device not ready)
ata2: hardreset failed, retrying in 5 secs

...waits 5 seconds...

ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: ATA-6, max UDMA/133, 640 sectors: LBA
ata2.00: ata2: dev 0 multi count 1
ata2.00: configured for UDMA/133
scsi2 : ahci
ata3: SATA link down (SStatus 0 SControl 300)
...

A bit of poking about shows:

fdisk -l /dev/sdb
Disk /dev/sdb: 0 MB, 327680 bytes
255 heads, 63 sectors/track, 0 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk /dev/sdb doesn't contain a valid partition table

So it presents itself as a 320k disk, filled with zeroes as below:

dd if=/dev/sdb |hexdump
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0050000

640+0 records in
640+0 records out
327680 bytes (328 kB) copied, 0.0106662 seconds, 30.7 MB/s

Note that this is not a fatal error. The machine still boots eventually, but the
seemingly mandatory 60 second pause makes startup rather cumbersome for the user.

So far none of the suggested fixes have managed to stop ata2 from being detected.
(noprobe=ata2, irqpoll, etc). I understand this problem wasn't present in 2.6.16 so the
problem must lie in some patch since then. I see Tejun is working towards patches for
this and I would be happy to try them here.

thanks,
Greg

2007-02-14 17:46:11

by Bill Davidsen

[permalink] [raw]

Subject: Re: AHCI - remove probing of ata2

Greg Trounson wrote:
> At the risk of sounding like a "me too" post:
>
> I also have an Asus P5W-DH, with the following drives connected:
>
> SATA: ST3250820AS, connected to sata1
> PATA: HL-DT-ST GSA-H12N, ATAPI DVD Writer, Primary master
>
> On bootup of 2.6.19 and 2.6.20, the kernel stalls for 1 minute when
> probing sata2, eventually giving up and continuing the boot process.
> There is no physical sata2 connector on the Motherboard, just solder
> lugs between sata1 and sata3. From other users I understand this is
> really a Silicon Image SIL4723 SATA to 2-Port SATA splitter. It is
> detected by the kernel as a disk, as below.
>
> The relevant part of the boot process looks like:
> ...
> libata version 2.00 loaded.
> ahci 0000:00:1f.2: version 2.0
> ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 23 (level, low) -> IRQ 22
> PCI: Setting latency timer of device 0000:00:1f.2 to 64
> ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA
> mode
> ahci 0000:00:1f.2: flags: 64bit ncq led clo pio slum part
> ata1: SATA max UDMA/133 cmd 0xF882A900 ctl 0x0 bmdma 0x0 irq 219
> ata2: SATA max UDMA/133 cmd 0xF882A980 ctl 0x0 bmdma 0x0 irq 219
> ata3: SATA max UDMA/133 cmd 0xF882AA00 ctl 0x0 bmdma 0x0 irq 219
> ata4: SATA max UDMA/133 cmd 0xF882AA80 ctl 0x0 bmdma 0x0 irq 219
> scsi0 : ahci
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata1.00: ATA-7, max UDMA/133, 488397168 sectors: LBA48 NCQ (depth 31/32)
> ata1.00: ata1: dev 0 multi count 16
> ata1.00: configured for UDMA/133
> scsi1 : ahci
> ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
>
> ...waits 20 seconds...
>
> ata2.00: qc timeout (cmd 0xec)
> ata2.00: failed to IDENTIFY (I/O error, err_mask=0x104)
>
> ...waits 5 seconds...
>
> ata2: port is slow to respond, please be patient (Status 0x80)
>
> ...waits 30 seconds...
>
> ata2: port failed to respond (30 secs, Status 0x80)
> ata2: COMRESET failed (device not ready)
> ata2: hardreset failed, retrying in 5 secs
>
> ...waits 5 seconds...
>
> ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> ata2.00: ATA-6, max UDMA/133, 640 sectors: LBA
> ata2.00: ata2: dev 0 multi count 1
> ata2.00: configured for UDMA/133
> scsi2 : ahci
> ata3: SATA link down (SStatus 0 SControl 300)
> ...
>
> A bit of poking about shows:
>
> fdisk -l /dev/sdb
> Disk /dev/sdb: 0 MB, 327680 bytes
> 255 heads, 63 sectors/track, 0 cylinders
> Units = cylinders of 16065 * 512 = 8225280 bytes
> Disk /dev/sdb doesn't contain a valid partition table
>
> So it presents itself as a 320k disk, filled with zeroes as below:
>
> dd if=/dev/sdb |hexdump
> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
> *
> 0050000
>
> 640+0 records in
> 640+0 records out
> 327680 bytes (328 kB) copied, 0.0106662 seconds, 30.7 MB/s
>
> Note that this is not a fatal error. The machine still boots
> eventually, but the seemingly mandatory 60 second pause makes startup
> rather cumbersome for the user.
>
> So far none of the suggested fixes have managed to stop ata2 from being
> detected. (noprobe=ata2, irqpoll, etc). I understand this problem
> wasn't present in 2.6.16 so the problem must lie in some patch since
> then. I see Tejun is working towards patches for this and I would be
> happy to try them here.
>
Is this 320k of cache memory, or in any way some actual storage on the
system? Have you tried to write to it out of curiosity? Seems odd that
it would be detected if there were nothing at all present, although
obviously it could be artifact.

--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot

2007-02-14 21:44:06

by Greg Trounson

[permalink] [raw]

Subject: Re: AHCI - remove probing of ata2

Bill Davidsen wrote:
> Greg Trounson wrote:
>> At the risk of sounding like a "me too" post:
>>
>> I also have an Asus P5W-DH, with the following drives connected:
>>
>> SATA: ST3250820AS, connected to sata1
>> PATA: HL-DT-ST GSA-H12N, ATAPI DVD Writer, Primary master
>>
>> On bootup of 2.6.19 and 2.6.20, the kernel stalls for 1 minute when
>> probing sata2, eventually giving up and continuing the boot process.
>> There is no physical sata2 connector on the Motherboard, just solder
>> lugs between sata1 and sata3. From other users I understand this is
>> really a Silicon Image SIL4723 SATA to 2-Port SATA splitter. It is
>> detected by the kernel as a disk, as below.
>>
>> The relevant part of the boot process looks like:
>> ...
>> libata version 2.00 loaded.
>> ahci 0000:00:1f.2: version 2.0
>> ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 23 (level, low) -> IRQ 22
>> PCI: Setting latency timer of device 0000:00:1f.2 to 64
>> ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl
>> SATA mode
>> ahci 0000:00:1f.2: flags: 64bit ncq led clo pio slum part
>> ata1: SATA max UDMA/133 cmd 0xF882A900 ctl 0x0 bmdma 0x0 irq 219
>> ata2: SATA max UDMA/133 cmd 0xF882A980 ctl 0x0 bmdma 0x0 irq 219
>> ata3: SATA max UDMA/133 cmd 0xF882AA00 ctl 0x0 bmdma 0x0 irq 219
>> ata4: SATA max UDMA/133 cmd 0xF882AA80 ctl 0x0 bmdma 0x0 irq 219
>> scsi0 : ahci
>> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>> ata1.00: ATA-7, max UDMA/133, 488397168 sectors: LBA48 NCQ (depth 31/32)
>> ata1.00: ata1: dev 0 multi count 16
>> ata1.00: configured for UDMA/133
>> scsi1 : ahci
>> ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
>>
>> ...waits 20 seconds...
>>
>> ata2.00: qc timeout (cmd 0xec)
>> ata2.00: failed to IDENTIFY (I/O error, err_mask=0x104)
>>
>> ...waits 5 seconds...
>>
>> ata2: port is slow to respond, please be patient (Status 0x80)
>>
>> ...waits 30 seconds...
>>
>> ata2: port failed to respond (30 secs, Status 0x80)
>> ata2: COMRESET failed (device not ready)
>> ata2: hardreset failed, retrying in 5 secs
>>
>> ...waits 5 seconds...
>>
>> ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
>> ata2.00: ATA-6, max UDMA/133, 640 sectors: LBA
>> ata2.00: ata2: dev 0 multi count 1
>> ata2.00: configured for UDMA/133
>> scsi2 : ahci
>> ata3: SATA link down (SStatus 0 SControl 300)
>> ...
>>
>> A bit of poking about shows:
>>
>> fdisk -l /dev/sdb
>> Disk /dev/sdb: 0 MB, 327680 bytes
>> 255 heads, 63 sectors/track, 0 cylinders
>> Units = cylinders of 16065 * 512 = 8225280 bytes
>> Disk /dev/sdb doesn't contain a valid partition table
>>
>> So it presents itself as a 320k disk, filled with zeroes as below:
>>
>> dd if=/dev/sdb |hexdump
>> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
>> *
>> 0050000
>>
>> 640+0 records in
>> 640+0 records out
>> 327680 bytes (328 kB) copied, 0.0106662 seconds, 30.7 MB/s
>>
...
> Is this 320k of cache memory, or in any way some actual storage on the
> system? Have you tried to write to it out of curiosity? Seems odd that
> it would be detected if there were nothing at all present, although
> obviously it could be artifact.

According to the product outline at
http://www.siliconimage.com/products/product.aspx?id=64, the Silicon Image port multiplier
has an EEPROM of unspecified size.

With the drive appearing as precisely 320K I wouldn't be surprised if this EEPROM is what
it was seeing. Even though it's currently filled with zeros I dare not write to it
through fear of bricking the controller.

Greg