The 5th bar of ide controller at legacy mode

The 5th bar of ide controller at legacy mode

[Zhang, Yanmin]

Hi,

I am using Fedora Core 7 Test1 on my ia64 box and run into an issue
about my cd drive. FC6 works well on my machine, but FC7Test1 couldn't
recognise the cd drive.

I checked it and found FC6 uses ide-cd/piix drivers, while FC7Test1
replaces them with ata/ata_piix drivers. When drivers call pci_enable_device,
the calling will fail if the bar resource is incorrect.

The bar resource of the ide controller on my tiger machine:
[root@tigerF 0000:00:1f.1]# pwd
/sys/devices/pci0000:00/0000:00:1f.1
[root@tigerF 0000:00:1f.1]# cat resource
0x00000000000001f0 0x00000000000001f7 0x0000000000000110
0x00000000000003f6 0x00000000000003f6 0x0000000000000110
0x0000000000000170 0x0000000000000177 0x0000000000000110
0x0000000000000376 0x0000000000000376 0x0000000000000110
0x0000000000001000 0x000000000000100f 0x0000000000000101
0x0000000000000000 0x00000000000003ff 0x0000000000000200
0x0000000000000000 0x0000000000000000 0x0000000000000000

The 5th bar is incorrect. BIOS initiates ide controllers.

If pci_enable_device fails, ata/ata_piix drivers will report the probe
failure, but ide-cd/piix is smarter to recall pci_enable_device_bars
directly with parameter bars=(1<<4), so only 0~4th bar resources are checked.

Below is a copy of some comments of function ide_pci_enable:

 *      Enable the IDE PCI device. We attempt to enable the device in full
 *      but if that fails then we only need BAR4 so we will enable that.

>From the comments, I expect the bars (other than 4th) of ide controllers
are incorrectly innitiated by BIOS very often.

So my question is: should ata/ata_piix also need to recall pci_enable_device_bars
with parameter bars=(1<<4) if pci_enable_device fails like what ide-cd/piix does?

Yanmin

Re: [Fedora-ia64-list] The 5th bar of ide controller at legacy mode

[Prarit Bhargava]

Zhang, Yanmin wrote:
> Hi,
>
> I am using Fedora Core 7 Test1 on my ia64 box and run into an issue
> about my cd drive. FC6 works well on my machine, but FC7Test1 couldn't
> recognise the cd drive.
>
>   

Just an FYI for everyone on linux-ide ... F7 (not FC anymore ;) )
maps upstream. I think there is a bit of a delta ATM but it's small.

> I checked it and found FC6 uses ide-cd/piix drivers, while FC7Test1
> replaces them with ata/ata_piix drivers. When drivers call pci_enable_device,
> the calling will fail if the bar resource is incorrect.
>   

ide-cd/piix drivers are going to be deprecated some time in the future.
Fedora has already made the switch to ata/ata_piix in order to test the
"new" driver and catch any potential issues with BIOS, ACPI tables,
etc..
> The bar resource of the ide controller on my tiger machine:
> [root@tigerF 0000:00:1f.1]# pwd
> /sys/devices/pci0000:00/0000:00:1f.1
> [root@tigerF 0000:00:1f.1]# cat resource
> 0x00000000000001f0 0x00000000000001f7 0x0000000000000110
> 0x00000000000003f6 0x00000000000003f6 0x0000000000000110
> 0x0000000000000170 0x0000000000000177 0x0000000000000110
> 0x0000000000000376 0x0000000000000376 0x0000000000000110
> 0x0000000000001000 0x000000000000100f 0x0000000000000101
> 0x0000000000000000 0x00000000000003ff 0x0000000000000200
> 0x0000000000000000 0x0000000000000000 0x0000000000000000
>
> The 5th bar is incorrect. BIOS initiates ide controllers.
>   

Your BIOS is broken.

> So my question is: should ata/ata_piix also need to recall pci_enable_device_bars
> with parameter bars=(1<<4) if pci_enable_device fails like what ide-cd/piix does?
>   

No, ata/ata_piix should not call pci_enable_device, IMO.

You're hitting this issue due to a broken BIOS -- if that BIOS is fixed then
the system would boot properly.

IMO, the kernel cannot take care of EVERY single case of a broken BIOS.

Another better approach is to make a Fedora-only
drivers/pci/quirks.c patch to catch this issue ... but I'm not going to
guarantee its acceptance into the Fedora tree.

P.

Re: The 5th bar of ide controller at legacy mode

[Alan]

O> 0x0000000000000000 0x00000000000003ff 0x0000000000000200
> 0x0000000000000000 0x0000000000000000 0x0000000000000000
> 
> The 5th bar is incorrect. BIOS initiates ide controllers.

You appear to have a 5th BAR allocated at address 0 with a length of
0x400. 

> failure, but ide-cd/piix is smarter to recall pci_enable_device_bars
> directly with parameter bars=(1<<4), so only 0~4th bar resources are checked.

the old IDE code deals only with SFF interfaces in simple modes, and hand
does all the handling for BAR 0-3 because of old PCI layer flaws and
weaknesses.

> So my question is: should ata/ata_piix also need to recall pci_enable_device_bars
> with parameter bars=(1<<4) if pci_enable_device fails like what ide-cd/piix does?

Your platform code or BIOS is buggy. PPC people had a similar problem.
Zero is not currently taken as "unallocated" by the PCI layer and, while
Linus suggested it could be, Dave Woodhouse and others pointed out there
are systems which legitimately use address 0 on the PCI in this way.

Sounds like you need to fix up after your firmware in your boot code,
perhaps with an arch specific pci header quirk.

Alan

RE: [Fedora-ia64-list] Re: The 5th bar of ide controller at legacy mode

[Luck, Tony]

> Your platform code or BIOS is buggy. PPC people had a similar problem.
> Zero is not currently taken as "unallocated" by the PCI layer and, while
> Linus suggested it could be, Dave Woodhouse and others pointed out there
> are systems which legitimately use address 0 on the PCI in this way.

The claim from the BIOS team is that on this system only legacy mode is
supported (indicated by the Class Code Programming model being 0x8A) and
since drivers/utilities should not make assumptions about these BAR values
when the device is in legacy mode, they don't have to initialize them.
The BARS would only be guaranteed to be set when programming model 0x8F
(native mode) is set.

Which sounds sort of plausible ... but perhaps that's because I have
not idea what a "Class code programming model" is.  Does that make
any sense?

> Sounds like you need to fix up after your firmware in your boot code,
> perhaps with an arch specific pci header quirk.

If many other BIOS writers believe the same thing as ours, then maybe
it might be worth fixing ... otherwise it looks like we'll need a quirk
(this machine is old, there isn't much liklihood of an updated BIOS release
for just this issue).

-Tony

Re: [Fedora-ia64-list] Re: The 5th bar of ide controller at legacy mode

[Prarit Bhargava]

>
> If many other BIOS writers believe the same thing as ours, then maybe
> it might be worth fixing ... otherwise it looks like we'll need a quirk
> (this machine is old, there isn't much liklihood of an updated BIOS release
> for just this issue).
>
>   

Tony,

As Alan suggested I think Yanmin should put together an 
arch/ia64/kernel/quirks.c (similar to arch/i386/kernel/quirks.c).

Note that my worry is by opening up quirks.c to this type of fix, 
vendors will be less inclined to fix other serious BIOS issues...

P.

Re: [Fedora-ia64-list] Re: The 5th bar of ide controller at legacy mode

[Alan]

> Which sounds sort of plausible ... but perhaps that's because I have
> not idea what a "Class code programming model" is.  Does that make
> any sense?

I think they are talking about BAR0 to 3 which are special, not BAR5
which the ia64 kernel code has somehow ended up assigned at I/O address
zero. Now whether that is a BIOS/Linux confusion, a BIOS mis-setup or
something weird that happened post BIOS to OS handover I don't know.

I know a similar PPC problem was really about the firmware assigning it
to zero to mean "not assigned" and the OS interpreting that as Bus
address 0, assigned.

Alan