pata_ali can't detect partitions

Hello,

yesterday I tried to install archlinux-i586 on a old computer I have.
It's a K6-3 with a ALI chipset.

I noticed that the system was able to find the disk as sda but could not
recognize the partitions on the drive. This happens with the 2.6.30-ARCH
kernel of the archlinux-i586 installer.

I noticed also that with an older kernel (2.6.28 IIRC) the system could
detect all the partitions.

So yesterday I had some spare time to try to bisect the problem with git
bisect. The result of the bisection was the following commit:

commit 1b2c357c301b76118973763e886d9f70a7f50f7e
pata_ali: force initialise a few bits

I tried to backout the commit but that didn't succeed. So I looked carefully
at the diff and I came out with the attached patch which seems to fix the
problem (at least now the kernel detects the partitions correctly).

Since I saw that the above commit is fixing some real bugs (sunblade related)
I don't know whether the attached patch is right or is backing out the
intended fix. All I know is that it works for me and for this reason I'm
reporting it.

Thanks,
Gianluca

> commit 1b2c357c301b76118973763e886d9f70a7f50f7e
> pata_ali: force initialise a few bits
> 
> I tried to backout the commit but that didn't succeed. So I looked carefully
> at the diff and I came out with the attached patch which seems to fix the
> problem (at least now the kernel detects the partitions correctly).

Thanks for doing this. Can you send me an lspci -vvxxx and a dmesg of the
machine in question.

> Since I saw that the above commit is fixing some real bugs (sunblade related)
> I don't know whether the attached patch is right or is backing out the
> intended fix. All I know is that it works for me and for this reason I'm
> reporting it.

Some of the registers involved are deep magic (even with the official
documentation its unclear what should occur in all cases). I will have
another dig - probably it depends on the chip rev what the right setting
is.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

As requested I'm attaching the output of the commands lspci -vvxxx and
dmesg. Since they were quite big I gzipped them.

You can find the uncompressed copy also here for your convenience:

http://www.sottospazio.it/lspci-k63d
http://www.sottospazio.it/dmesg-k63d

Thanks,
Gianluca

From: gianluca <gianluca@sottospazio.it>
Date: Tue, 10 Nov 2009 21:25:33 +0100

> As requested I'm attaching the output of the commands lspci -vvxxx and
> dmesg. Since they were quite big I gzipped them.
> 
> You can find the uncompressed copy also here for your convenience:
> 
> http://www.sottospazio.it/lspci-k63d
> http://www.sottospazio.it/dmesg-k63d

I want to help with this so I'm going to fire up some of my
ALI using sparc64 systems and try to give a hand.
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Tue, 10 Nov 2009 11:11:25 +0000

> Some of the registers involved are deep magic (even with the official
> documentation its unclear what should occur in all cases). I will have
> another dig - probably it depends on the chip rev what the right setting
> is.

So while getting my sunblade up and going, I took a look at the
patch in question.  The northbridge logic changed a bit and
I suspect this is part of the problem.

In the IDE layer driver, the guard is:

	if (north && north->vendor != PCI_VENDOR_ID_AL)
		goto out;

This means the programming is done iff:

1) We find no device at PCI_DEVFN(0,0)

2) We find a device and vendor is ALI

I suspect case #1 triggers on sparc64.  The guard in the PATA
driver is:

	north = pci_get_bus_and_slot(0, PCI_DEVFN(0,0));
	if (north && north->vendor == PCI_VENDOR_ID_AL && ali_isa_bridge) {

which is different.  It won't do the programming if we find no
device at PCI_DEVFN(0,0).

This might be the critical difference, I don't know, just pointing
it out.

I'll do some checks once my slow test system is up and going.

--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

> In the IDE layer driver, the guard is:
> 
> 	if (north && north->vendor != PCI_VENDOR_ID_AL)
> 		goto out;
> 
> This means the programming is done iff:
> 
> 1) We find no device at PCI_DEVFN(0,0)
> 
> 2) We find a device and vendor is ALI
> 
> I suspect case #1 triggers on sparc64.  The guard in the PATA
> driver is:
> 
> 	north = pci_get_bus_and_slot(0, PCI_DEVFN(0,0));
> 	if (north && north->vendor == PCI_VENDOR_ID_AL && ali_isa_bridge) {
> 
> which is different.  It won't do the programming if we find no
> device at PCI_DEVFN(0,0).
> 
> This might be the critical difference, I don't know, just pointing
> it out.

The logic in pata_ali is the intended logic there (and the comments in
drivers/ide match the code in pata_ali but the code doesn't)

What docs I have say you need to program the isa enable bit if you are
using an ALi north bridge (which always appears at 0,0,0). The other PC
case is the Transmeta systems, and in that case the setup is done by the
firmware and undocumented entirely.

I have exactly zero Sparc64 documentation on the subject. The only Sparc
related material I have is the C2/C3 post reset stuff. That *might* be a
relevant difference in behaviour for C2 and C3 devices but only with an
ALi bridge (ali_c2_c3_postreset)

Alan


--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Thu, 19 Nov 2009 21:10:31 +0000

> I have exactly zero Sparc64 documentation on the subject. The only Sparc
> related material I have is the C2/C3 post reset stuff. That *might* be a
> relevant difference in behaviour for C2 and C3 devices but only with an
> ALi bridge (ali_c2_c3_postreset)

So I can't even reproduce these ALI problems on my sb100, it works
perfectly fine with Linus's tree.  I'll play around on my sb1000 and
some other drives.

And yes that poking in the ISA bridge during reset is necessary to
make sure all the gates are in the proper initial state.
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html