From: Krzysztof Halasa <khc@pm.waw.pl>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Tejun Heo <htejun@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: NV SATA breakage: jgarzik/libata-dev#upstream etc
Date: Mon, 25 Sep 2006 14:51:06 +0200 [thread overview]
Message-ID: <m3vencjeit.fsf@defiant.localdomain> (raw)
In-Reply-To: <451721F8.4060600@pobox.com> (Jeff Garzik's message of "Sun, 24 Sep 2006 20:25:28 -0400")
Jeff Garzik <jgarzik@pobox.com> writes:
>> libata-core.c
>> int ata_device_add(const struct ata_probe_ent *ent)
>> {
>> ...
>> /* register each port bound to this device */
>> for (i = 0; i < host->n_ports; i++) {
>> ...
>> /* start port */
>> rc = ap->ops->port_start(ap);
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> The problematic commit is fea63e38013ec628ab3f7fddc4c2148064b7910a:
>> "[PATCH] libata: fix non-uniform ports handling
>> Non-uniform ports handling got broken while updating libata to handle
>> those in the same host. Only separate irq for the non-uniform
>> secondary port was implemented while all other fields (host flags,
>> transfer mode...) of the secondary port simply shared those of the
>> first.
>
> What's broken, and how does it affect NV sata?
NV SATA initialization fails with NULL pointer dereference in
ata_device_add (= kernel panic).
> That's the chipset on my main dev workstation, and there are no
> problems here...
I'm a bit surprised... I'm using x86_64 with only one SATA "controller"
enabled (ports 0 and 1 only, ports 2-5 are disabled in BIOS). Only
port 0 is in use. Gcc 4.1.1.
With a64f97f2c351410dfb3099c2369eacf7154b5532 (2.6.18-rc7+, "Merge branch
'tmp' into upstream", just before the commit in question) it works fine:
libata version 2.00 loaded.
sata_nv 0000:00:05.0: version 2.0
ACPI: PCI Interrupt Link [LSA0] enabled at IRQ 23
GSI 16 sharing vector 0xE1 and IRQ 16
ACPI: PCI Interrupt 0000:00:05.0[A] -> Link [LSA0] -> GSI 23 (level, low) -> IRQ
225
PCI: Setting latency timer of device 0000:00:05.0 to 64
ata1: SATA max UDMA/133 cmd 0xC800 ctl 0xC482 bmdma 0xC000 irq 225
ata2: SATA max UDMA/133 cmd 0xC400 ctl 0xC082 bmdma 0xC008 irq 225
scsi0 : sata_nv
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-7, max UDMA/133, 488397168 sectors: LBA48 NCQ (depth 0/32)
ata1.00: ata1: dev 0 multi count 16
ata1.00: configured for UDMA/133
scsi1 : sata_nv
ata2: SATA link down (SStatus 0 SControl 300)
ATA: abnormal status 0x7F on port 0xC407
Vendor: ATA Model: ST3250823AS Rev: 3.03
Type: Direct-Access ANSI SCSI revision: 05
--
Krzysztof Halasa
next prev parent reply other threads:[~2006-09-25 12:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-24 18:57 NV SATA breakage: jgarzik/libata-dev#upstream etc Krzysztof Halasa
2006-09-25 0:25 ` Jeff Garzik
2006-09-25 12:51 ` Krzysztof Halasa [this message]
2006-09-25 17:15 ` Krzysztof Halasa
2006-09-25 22:20 ` Jeff Garzik
2006-09-25 23:50 ` Krzysztof Halasa
2006-09-25 23:52 ` Jeff Garzik
2006-09-26 0:29 ` Krzysztof Halasa
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=m3vencjeit.fsf@defiant.localdomain \
--to=khc@pm.waw.pl \
--cc=htejun@gmail.com \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
/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