From: "Jean-François Stenuit" <jfs@keytradebank.com>
To: Tejun Heo <htejun@gmail.com>
Cc: Keith Mannthey <kmannth@gmail.com>, "0602@eq.cz" <0602@eq.cz>,
Linux-ide <linux-ide@vger.kernel.org>
Subject: Re: totally random "VFS: Cannot open root device"
Date: Thu, 01 Dec 2005 13:59:34 +0100 [thread overview]
Message-ID: <438EF3B6.7020007@keytradebank.com> (raw)
In-Reply-To: <20051201112015.GA10462@htj.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 4140 bytes --]
Hi Tejun,
Thanks for taking the time to check.
Output of your trace with ata_piix.override_PCS=0
1st boot : success : combined=0 orig_mask=0x11
2nd boot : success : combined=0 orig_mask=0x11
3rd boot : failure : combined=0 orig_mask=0x0
4th boot : failure : combined=0 orig_mask=0x0
5th boot : failure : combined=0 orig_mask=0x0
6th boot : failure : combined=0 orig_mask=0x0
7th boot : success : combined=0 orig_mask=0x11
Output of your trace with ata_piix.override_PCS=1
1st boot : success : combined=0 orig_mask=0x0
2nd boot : success : combined=0 orig_mask=0x0
3rd boot : success : combined=0 orig_mask=0x0
4th boot : success : combined=0 orig_mask=0x0
5th boot : success : combined=0 orig_mask=0x0
6th boot : success : combined=0 orig_mask=0x0
7th boot : success : combined=0 orig_mask=0x0
8th boot : success : combined=0 orig_mask=0x0
Looks like you have found a fix/workaround for this bug (but it still
does not give the reason why it's failing).
Tejun Heo wrote:
>On Thu, Dec 01, 2005 at 10:40:18AM +0100, Jean-Fran?ois Stenuit wrote:
>
>
>>Hi Keith,
>>
>>I have been able to reproduce the bug (randomly - needing a few reboots
>>to make it happen) on a 2.6.15-rc3 kernel.
>>
>>System is an HP DL140G2 with following SATA controller (from lspci -vv) :
>>
>>0000:00:1f.2 IDE interface: Intel Corp. 82801EB (ICH5) Serial ATA 150
>>Storage Controller (rev 02) (prog-if 8a [Master SecP PriP])
>> Subsystem: Hewlett-Packard Company: Unknown device 3208
>> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
>>ParErr- Stepping- SERR- FastB2B-
>> Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
>><TAbort- <MAbort- >SERR- <PERR-
>> Latency: 0
>> Interrupt: pin A routed to IRQ 17
>> Region 0: I/O ports at <unassigned>
>> Region 1: I/O ports at <unassigned>
>> Region 2: I/O ports at <unassigned>
>> Region 3: I/O ports at <unassigned>
>> Region 4: I/O ports at 1470 [size=16]
>>
>>
>
>Hi,
>
>Can you try the following patch? It adds a module parameter
>override_PCS. If your piix module is built into the kernel, adding
>the following to the kernel paramter shoudl work.
>
>ata_piix.override_PCS=n
>
>Where, n is one of
>
>0: normal behavior
>1: ignore PCS and always try to probe ports
>2: overwrite PCS such that all ENABLED bits are 1
>
>First, try with override_PCS=0 and make not of the printed combined
>and orig_mask values on success and failure cases. Then, try with
>override_PCS=1, if it also fails, try with override_PCS=2.
>
>You can tell if an override option works or not by comparing the
>combined and orig_mask value to the failure case. If the machine
>boots successfully with the same combined/orig_mask values as the
>failure case, it means that the override option works.
>
>BTW, all these are based on the previous message in which you said
>that when boot failed the kernel printed the following log message.
>
>"ata1: SATA port has no device."
>
>Right?
>
>
>diff --git a/drivers/scsi/ata_piix.c b/drivers/scsi/ata_piix.c
>index 887b2b9..639da80 100644
>--- a/drivers/scsi/ata_piix.c
>+++ b/drivers/scsi/ata_piix.c
>@@ -340,6 +340,9 @@ static void piix_pata_phy_reset(struct a
> ata_bus_reset(ap);
> }
>
>+static int override_PCS;
>+module_param(override_PCS, int, 0700);
>+
> /**
> * piix_sata_probe - Probe PCI device for present SATA devices
> * @ap: Port associated with the PCI device we wish to probe
>@@ -367,6 +370,17 @@ static int piix_sata_probe (struct ata_p
>
> pci_read_config_byte(pdev, ICH5_PCS, &pcs);
> orig_mask = (int) pcs & 0xff;
>+ printk("ata%u: combined=%d orig_mask=0x%x\n", ap->id, combined, orig_mask);
>+
>+ switch (override_PCS) {
>+ case 1:
>+ printk("ata%u: ignoring PCS\n", ap->id);
>+ return 1;
>+ case 2:
>+ printk("ata%u: turning on PCS ENABLED bits\n", ap->id);
>+ pci_write_config_byte(pdev, ICH5_PCS, 0x0f);
>+ return 1;
>+ }
>
> /* TODO: this is vaguely wrong for ICH6 combined mode,
> * where only two of the four SATA ports are mapped
>
>
>
--
Jean-François "Jef" Stenuit
Network & Security manager
Keytrade Bank SA
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3182 bytes --]
next prev parent reply other threads:[~2005-12-01 12:59 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <438B6E05.8070009@eq.cz>
2005-11-30 4:35 ` totally random "VFS: Cannot open root device" Tejun Heo
2005-11-30 9:05 ` Jean-François Stenuit
2005-11-30 16:30 ` Randy.Dunlap
2005-12-01 9:42 ` Jean-François Stenuit
2005-12-01 11:20 ` Jean-François Stenuit
2005-11-30 13:07 ` 0602
2005-11-30 22:05 ` Keith Mannthey
2005-12-01 9:40 ` Jean-François Stenuit
2005-12-01 11:20 ` Tejun Heo
2005-12-01 12:59 ` Jean-François Stenuit [this message]
2005-12-01 13:29 ` Tejun Heo
2005-12-01 15:34 ` 0602
2005-12-02 1:53 ` Jeff Garzik
2005-12-02 3:00 ` Tejun Heo
2005-12-02 3:26 ` [PATCH] ata_piix: ignore all zero PCS value on ICH5's Tejun Heo
2005-12-02 12:40 ` 0602
2005-12-05 10:07 ` Jean-François Stenuit
2005-12-05 10:17 ` Tejun Heo
2006-01-29 5:22 ` Jeff Garzik
2006-02-01 2:01 ` Tejun Heo
2006-02-09 9:23 ` Jeff Garzik
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=438EF3B6.7020007@keytradebank.com \
--to=jfs@keytradebank.com \
--cc=0602@eq.cz \
--cc=htejun@gmail.com \
--cc=kmannth@gmail.com \
--cc=linux-ide@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;
as well as URLs for NNTP newsgroup(s).