2008-11-24 15:56:43

by Mel Gorman

[permalink] [raw]
Subject: Is the change to IDE probing really necessary?

Hi,

I got caught by commit 20df429dd6671804999493baf2952f82582869fa as I didn't
immediately guess that "ide_generic." was necessary on the kernel command line
when compiled in instead of as a module. While it didn't catch me for long,
my concern is that this is going to trip up other people with old machines
that need that mask. This change was introduced in 2.6.28-rc1 but I didn't
catch it till now as I hadn't used the laptop in a while.

I have a few questions on the commit.

1. Why was it necessary to disable the legacy probes like this at all?
Would it be possible to try the probe_mask in the event nothing is found
or does that have other consequences?

2. Related to one, how is a distro install using modules meant to be
fixed up? They would have to detect the probe failed, update their
modules configuration and try again. Rather than doing that, I would
imagine they add the probe_mask by default making this change somewhat
redundant.

3. It appears that the message will always appear whether the mask is
necessary or not. Why does it not get printed in the even nothing is found
at least to avoid noise? If the message is printed rarely, it should also
say what the kernel command line should be if ide_generic is compiled in.

Thanks.

--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab


2008-11-24 18:43:38

by Mel Gorman

[permalink] [raw]
Subject: Re: Is the change to IDE probing really necessary?

On Mon, Nov 24, 2008 at 03:56:32PM +0000, Mel Gorman wrote:
> Hi,
>
> I got caught by commit 20df429dd6671804999493baf2952f82582869fa as I didn't
> immediately guess that "ide_generic." was necessary on the kernel command line
> when compiled in instead of as a module. While it didn't catch me for long,
> my concern is that this is going to trip up other people with old machines
> that need that mask. This change was introduced in 2.6.28-rc1 but I didn't
> catch it till now as I hadn't used the laptop in a while.
>

It gets even more screwy. Networking was bust on the machine when
the probe_mask workaround was used. After some investigation, I saw
/proc/interrupts looks like

CPU0
0: 55495 XT-PIC-XT timer
1: 8 XT-PIC-XT i8042
2: 0 XT-PIC-XT cascade
3: 1 XT-PIC-XT
4: 1763 XT-PIC-XT serial
6: 5 XT-PIC-XT floppy
8: 0 XT-PIC-XT ide4
9: 289 XT-PIC-XT acpi
10: 0 XT-PIC-XT ide3
11: 0 XT-PIC-XT ide2
12: 0 XT-PIC-XT ide5
14: 473802 XT-PIC-XT ide0
15: 209 XT-PIC-XT ide1
NMI: 0 Non-maskable interrupts
LOC: 0 Local timer interrupts
RES: 0 Rescheduling interrupts
CAL: 0 function call interrupts
TLB: 0 TLB shootdowns
SPU: 0 Spurious interrupts
ERR: 0
MIS: 0

Note the number of "ide" devices (2, 3 and 5) even though there are only
really two in the machine for the disk and cdrom. The file in 2.6.27 looked like

CPU0
0: 9881 XT-PIC-XT timer
1: 8 XT-PIC-XT i8042
2: 0 XT-PIC-XT cascade
4: 305 XT-PIC-XT serial
6: 5 XT-PIC-XT floppy
9: 141 XT-PIC-XT acpi
11: 136 XT-PIC-XT uhci_hcd:usb1, eth0
12: 149 XT-PIC-XT i8042
14: 54276 XT-PIC-XT ide0
15: 172 XT-PIC-XT ide1

Note how interrupt 11 is the ethernet on a working kernel and an ide device
with the suggested probe_mask. Using the old probe_mask of 0x3 instead of
0.3f works as expected so very minimally, could you consider the following
patch please?

====
From: Mel Gorman <[email protected]>
Subject: [PATCH] ide_generic: Suggest 0x3 as a probe mask instead of 0x3f

On a machine requiring probing of the legacy ports, the suggested
probe_mask of 0x3f results in other devices being registered as IDE
devices. Suggest to the user they use 0x3 which is the old value of
probe_mask prior to commit 20df429dd6671804999493baf2952f82582869fa.

Signed-off-by: Mel Gorman <[email protected]>
---
drivers/ide/ide-generic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ide/ide-generic.c b/drivers/ide/ide-generic.c
index 81a5282..7d6bd99 100644
--- a/drivers/ide/ide-generic.c
+++ b/drivers/ide/ide-generic.c
@@ -144,7 +144,7 @@ static int __init ide_generic_init(void)
ide_generic_check_pci_legacy_iobases(&primary, &secondary);

if (!probe_mask) {
- printk(KERN_INFO DRV_NAME ": please use \"probe_mask=0x3f\" "
+ printk(KERN_INFO DRV_NAME ": please use \"probe_mask=0x3\" "
"module parameter for probing all legacy ISA IDE ports\n");

if (primary == 0)

2008-11-24 19:06:01

by Alan

[permalink] [raw]
Subject: Re: Is the change to IDE probing really necessary?

O> On a machine requiring probing of the legacy ports, the suggested
> probe_mask of 0x3f results in other devices being registered as IDE
> devices. Suggest to the user they use 0x3 which is the old value of
> probe_mask prior to commit 20df429dd6671804999493baf2952f82582869fa.

NAK

This makes no sense.

0x3F means probe them all.

0x03 means only peer at primary/secondary.

If you don't want them probed, don't pass arguments asking for them to be
probed!

"how is a distro install using modules meant to be fixed up?"

If the distribution supports non PCI bus boxes then pass a mask of 0x3F
on non PCI boxes. If the distribution is for PCI systems then leave the
mask alone.

If you want it to just work automatically use pata_legacy instead as that
automatically flips between probing ISA tertiary devices and leaving
things well alone according to the presence of PCI bus.

Alan

2008-11-24 22:51:41

by Borislav Petkov

[permalink] [raw]
Subject: Re: Is the change to IDE probing really necessary?

Hi,

On Mon, Nov 24, 2008 at 03:56:32PM +0000, Mel Gorman wrote:
> Hi,
>
> I got caught by commit 20df429dd6671804999493baf2952f82582869fa as I didn't
> immediately guess that "ide_generic." was necessary on the kernel command line
> when compiled in instead of as a module. While it didn't catch me for long,
> my concern is that this is going to trip up other people with old machines
> that need that mask. This change was introduced in 2.6.28-rc1 but I didn't
> catch it till now as I hadn't used the laptop in a while.
>
> I have a few questions on the commit.
>
> 1. Why was it necessary to disable the legacy probes like this at all?
> Would it be possible to try the probe_mask in the event nothing is found
> or does that have other consequences?

take a look at 0cbccbc30a60ff60dbeb203154f1f527c632de9b for background
info on the decision behind the probe_mask. Now ide-generic probes only
the legacy ports as is the case in common machine configurations and
is a sort-of fall-back option in case there's no PCI IDE controller
present. In addition, the Kconfig text explains more why ide-generic
should not be used in modern systems (not sharing IRQs, preventing
controller-specific drivers from attaching in certain cases).

And the probing _is_ done when loaded as a module so the problem is
not with the mask - in your case the probing will work just fine as
you need ide0 and ide1, AFAICT. The problem is that the probing is not
being done when ide-generic is compiled in and is the only controller
driver enabled. The only trick I can think of off the top of my head
is a Kconfig-option enabling ide-generic only when no other controller
driver is enabled and getting rid of the possibility of compiling it as
a module.

Bart, I'm sure you have a better idea :).

--
Regards/Gruss,
Boris.

2008-11-24 23:10:01

by Mel Gorman

[permalink] [raw]
Subject: Re: Is the change to IDE probing really necessary?

On Mon, Nov 24, 2008 at 06:54:53PM +0000, Alan Cox wrote:
> O> On a machine requiring probing of the legacy ports, the suggested
> > probe_mask of 0x3f results in other devices being registered as IDE
> > devices. Suggest to the user they use 0x3 which is the old value of
> > probe_mask prior to commit 20df429dd6671804999493baf2952f82582869fa.
>
> NAK
>
> This makes no sense.
>

Ok.

> 0x3F means probe them all.
>
> 0x03 means only peer at primary/secondary.
>

Then can the message outputted printed out say something along those
lines? On this particular machine, probing 0x3F resulted in a misconfigured
machine. It's not obvious to me at all that 0x3F means probe everything,
possibly with adverse results and 0x03 means peer at primary/secondary.

> If you don't want them probed, don't pass arguments asking for them to be
> probed!
>
> "how is a distro install using modules meant to be fixed up?"
>
> If the distribution supports non PCI bus boxes then pass a mask of 0x3F
> on non PCI boxes.

Which in this case would have resulted in a machine with a disk but no
networking. CONFIG_ISA is not even set on this machine and it looks like a
PCI bus box.

> If the distribution is for PCI systems then leave the
> mask alone.
>

Which in this case resulted in no disk because the mask defaults to 0
now instead of 0x3 or anything else.

What you suggest for the numbers in each case is right, but it's not
obvious. The machine might be so old that no will encounter this problem
in practice.

> If you want it to just work automatically use pata_legacy instead as that
> automatically flips between probing ISA tertiary devices and leaving
> things well alone according to the presence of PCI bus.
>

It doesn't find the disk.

--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab

2008-11-25 00:01:18

by Mel Gorman

[permalink] [raw]
Subject: Re: Is the change to IDE probing really necessary?

On Mon, Nov 24, 2008 at 11:51:39PM +0100, Borislav Petkov wrote:
> Hi,
>
> On Mon, Nov 24, 2008 at 03:56:32PM +0000, Mel Gorman wrote:
> > Hi,
> >
> > I got caught by commit 20df429dd6671804999493baf2952f82582869fa as I didn't
> > immediately guess that "ide_generic." was necessary on the kernel command line
> > when compiled in instead of as a module. While it didn't catch me for long,
> > my concern is that this is going to trip up other people with old machines
> > that need that mask. This change was introduced in 2.6.28-rc1 but I didn't
> > catch it till now as I hadn't used the laptop in a while.
> >
> > I have a few questions on the commit.
> >
> > 1. Why was it necessary to disable the legacy probes like this at all?
> > Would it be possible to try the probe_mask in the event nothing is found
> > or does that have other consequences?
>
> take a look at 0cbccbc30a60ff60dbeb203154f1f527c632de9b for background
> info on the decision behind the probe_mask. Now ide-generic probes only
> the legacy ports as is the case in common machine configurations and
> is a sort-of fall-back option in case there's no PCI IDE controller
> present.

I think this is on a PCI bus though. ioports tells me

0170-0177 : 0000:00:07.1
0170-0177 : ide_generic
01f0-01f7 : 0000:00:07.1
01f0-01f7 : ide_generic

and that appears to correspond to the following in lspci

00:07.0 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02)
Flags: bus master, medium devsel, latency 0

00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) (prog-if 80 [Master])
Flags: bus master, medium devsel, latency 64
[virtual] Memory at 000001f0 (32-bit, non-prefetchable) [disabled] [size=8]
[virtual] Memory at 000003f0 (type 3, non-prefetchable) [disabled] [size=1]
[virtual] Memory at 00000170 (32-bit, non-prefetchable) [disabled] [size=8]
[virtual] Memory at 00000370 (type 3, non-prefetchable) [disabled] [size=1]
I/O ports at 1850 [size=16]

> In addition, the Kconfig text explains more why ide-generic
> should not be used in modern systems (not sharing IRQs, preventing
> controller-specific drivers from attaching in certain cases).
>

Which is a fair comment. I should have been using PIIX (which was not compiled
at all) on this machine in the first place making it even less likely someone
is going to hit this problem in practice. Disabling ide-generic and using
the piix driver makes everything work together happily so maybe most of this
problem can just be filed under PEBKAC.

> And the probing _is_ done when loaded as a module so the problem is
> not with the mask - in your case the probing will work just fine as
> you need ide0 and ide1, AFAICT.

Out of curiousity, I loaded ide-generic as a module and tried the suggested
probe_mask. It loads after e100 which is built in and then has a crap attack
as it tries to register IO regions which are already registered, triggers
sysfs warnings for creating duplicate files and then continues along to
a state where networking doesn't work anyway. That suggestion of 0x3f may
still catch someone.

> The problem is that the probing is not
> being done when ide-generic is compiled in and is the only controller
> driver enabled. The only trick I can think of off the top of my head
> is a Kconfig-option enabling ide-generic only when no other controller
> driver is enabled and getting rid of the possibility of compiling it as
> a module.
>
> Bart, I'm sure you have a better idea :).
>

--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab

2008-11-25 00:03:19

by Alan

[permalink] [raw]
Subject: Re: Is the change to IDE probing really necessary?

> Then can the message outputted printed out say something along those
> lines? On this particular machine, probing 0x3F resulted in a misconfigured

That is exactly what it says at the moment.

> machine. It's not obvious to me at all that 0x3F means probe everything,
> possibly with adverse results and 0x03 means peer at primary/secondary.

> Which in this case resulted in no disk because the mask defaults to 0
> now instead of 0x3 or anything else.

The mask is set to 0 and then the master/slave are detected based upon
the presence of PCI IDE devices on the master/slave ports.

> What you suggest for the numbers in each case is right, but it's not
> obvious. The machine might be so old that no will encounter this problem
> in practice.

That is why pata_legacy does it automatically. Users shouldn't need to.

> > If you want it to just work automatically use pata_legacy instead as that
> > automatically flips between probing ISA tertiary devices and leaving
> > things well alone according to the presence of PCI bus.
> >
>
> It doesn't find the disk.

If pata_legacy fails to find the disk then please send me an lspci
-vvxxx, chances are you shouldn't be using pata_legacy or ide_generic in
the first place but have a PCI device and don't have the right driver
loaded (or we don't have a right driver in which case it needs the
heuristics fixing up)

2008-11-25 00:16:30

by Mel Gorman

[permalink] [raw]
Subject: Re: Is the change to IDE probing really necessary?

On Tue, Nov 25, 2008 at 12:03:06AM +0000, Alan Cox wrote:
> > Then can the message outputted printed out say something along those
> > lines? On this particular machine, probing 0x3F resulted in a misconfigured
>
> That is exactly what it says at the moment.
>
> > machine. It's not obvious to me at all that 0x3F means probe everything,
> > possibly with adverse results and 0x03 means peer at primary/secondary.
>
> > Which in this case resulted in no disk because the mask defaults to 0
> > now instead of 0x3 or anything else.
>
> The mask is set to 0 and then the master/slave are detected based upon
> the presence of PCI IDE devices on the master/slave ports.
>

This detection was not happening but then again the proper driver was not
compiled. The .config I used was very minimal and lacked most drivers.

> > What you suggest for the numbers in each case is right, but it's not
> > obvious. The machine might be so old that no will encounter this problem
> > in practice.
>
> That is why pata_legacy does it automatically. Users shouldn't need to.
>
> > > If you want it to just work automatically use pata_legacy instead as that
> > > automatically flips between probing ISA tertiary devices and leaving
> > > things well alone according to the presence of PCI bus.
> > >
> >
> > It doesn't find the disk.
>
> If pata_legacy fails to find the disk then please send me an lspci
> -vvxxx, chances are you shouldn't be using pata_legacy or ide_generic in
> the first place but have a PCI device and don't have the right driver
> loaded (or we don't have a right driver in which case it needs the
> heuristics fixing up)
>

It's included below. Earlier I said this was not on an ISA bus. This belief
was enforced by CONFIG_ISA not being necessary for ide-generic to work in
the past and the fact lspci lists the device. However, lspci does call it
"PIIX4 ISA (rev 02)" so maybe I was getting that wrong too.

It is certainly the case I was not using the correct driver. Using
CONFIG_BLK_DEV_PIIX instead of CONFIG_IDE_GENERIC makes everything work as
expected without having to pass special options.

00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
Latency: 64
Region 0: Memory at f8000000 (32-bit, prefetchable) [size=64M]
Capabilities: [a0] AGP version 1.0
Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2
Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>
Kernel driver in use: agpgart-intel
Kernel modules: intel-agp
00: 86 80 90 71 06 01 10 22 03 00 00 06 00 40 00 00
10: 08 00 00 f8 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 0c 82 00 ff 00 00 00 09 03 10 11 01 00 00 11 11
60: 10 20 20 30 40 40 40 40 00 00 00 00 00 aa 00 00
70: 20 1f 0a 78 8a 02 03 01 27 1b dc 00 10 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 04 61 00 00 00 05 00 00 00 00 00 00
a0: 02 00 10 00 03 02 00 1f 00 00 00 00 00 00 00 00
b0: 80 20 00 00 30 00 00 00 00 00 68 12 20 10 00 00
c0: 00 00 00 00 00 00 00 00 18 0c 83 cd 78 00 00 00
d0: 00 00 00 00 00 00 00 00 0c 00 00 00 00 00 00 00
e0: 4c ad ff bb 8a 3e 00 80 2c d3 f7 cf 9d 3e 00 00
f0: 40 01 00 00 00 f8 00 60 20 0f 00 00 00 00 00 00

00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 128
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
Memory behind bridge: f0000000-f7ffffff
Prefetchable memory behind bridge: 40000000-400fffff
Secondary status: 66MHz+ FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B+
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
00: 86 80 91 71 1f 00 20 02 03 00 04 06 00 80 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 40 f0 00 a0 22
20: 00 f0 f0 f7 00 40 00 40 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8c 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:02.0 CardBus bridge: Texas Instruments PCI1450 (rev 03)
Subsystem: IBM ThinkPad A21m/T20/T22
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 11
Region 0: Memory at 50000000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=02, subordinate=05, sec-latency=176
Memory window 0: 30000000-33fff000 (prefetchable)
Memory window 1: 34000000-37fff000 (prefetchable)
I/O window 0: 00001400-000014ff
I/O window 1: 00001c00-00001cff
BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite-
16-bit legacy interface ports at 0001
00: 4c 10 1b ac 07 00 10 02 03 00 07 06 08 40 82 00
10: 00 00 00 50 a0 00 00 02 00 02 05 b0 00 00 00 30
20: 00 f0 ff 33 00 00 00 34 00 f0 ff 37 00 14 00 00
30: fc 14 00 00 00 1c 00 00 fc 1c 00 00 0b 01 c0 03
40: 14 10 30 01 01 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 79 d0 64 08 00 00 00 00 80 80 01 80 00 10 00 00
90: c0 02 66 40 00 00 00 00 00 00 00 00 00 00 00 00
a0: 01 00 11 fe 00 00 c0 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:02.1 CardBus bridge: Texas Instruments PCI1450 (rev 03)
Subsystem: IBM ThinkPad A21m/T20/T22
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64, Cache Line Size: 32 bytes
Interrupt: pin B routed to IRQ 11
Region 0: Memory at 50100000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=06, subordinate=09, sec-latency=176
Memory window 0: 38000000-3bfff000 (prefetchable)
Memory window 1: 3c000000-3ffff000 (prefetchable)
I/O window 0: 00002000-000020ff
I/O window 1: 00002400-000024ff
BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite-
16-bit legacy interface ports at 0001
00: 4c 10 1b ac 07 00 10 02 03 00 07 06 08 40 82 00
10: 00 00 10 50 a0 00 00 02 00 06 09 b0 00 00 00 38
20: 00 f0 ff 3b 00 00 00 3c 00 f0 ff 3f 00 20 00 00
30: fc 20 00 00 00 24 00 00 fc 24 00 00 0b 02 c0 03
40: 14 10 30 01 01 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 79 d0 64 08 00 00 00 00 80 80 01 80 00 10 00 00
90: c0 02 66 40 00 00 00 00 00 00 00 00 00 00 00 00
a0: 01 00 11 fe 00 00 c0 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:03.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 09)
Subsystem: Intel Corporation EtherExpress PRO/100+ MiniPCI
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 66 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 11
Region 0: Memory at e8120000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at 1800 [size=64]
Region 2: Memory at e8100000 (32-bit, non-prefetchable) [size=128K]
[virtual] Expansion ROM at 40100000 [disabled] [size=1M]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
Kernel driver in use: e100
Kernel modules: e100
00: 86 80 29 12 17 00 90 02 09 00 00 02 08 42 80 00
10: 00 00 12 e8 01 18 00 00 00 00 10 e8 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 08 24
30: 00 00 00 00 dc 00 00 00 00 00 00 00 0b 01 08 38
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 01 00 22 fe
e0: 00 40 00 3c 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:03.1 Serial controller: Xircom Mini-PCI V.90 56k Modem (prog-if 02 [16550])
Subsystem: Intel Corporation Unknown device 2408
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at 1840 [size=8]
Region 1: Memory at e8121000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
Kernel driver in use: serial
00: 5d 11 0c 00 03 00 10 02 00 02 00 07 00 00 80 00
10: 41 18 00 00 00 10 12 e8 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 08 24
30: 00 00 00 00 dc 00 00 00 00 00 00 00 0b 01 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 01 00 22 fe
e0: 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:05.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24/30 [CrystalClear SoundFusion Audio Accelerator] (rev 01)
Subsystem: IBM ThinkPad A20m
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 11
Region 0: Memory at e8122000 (32-bit, non-prefetchable) [size=4K]
Region 1: Memory at e8000000 (32-bit, non-prefetchable) [size=1M]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 13 10 03 60 02 00 10 04 01 00 01 04 00 40 00 00
10: 00 20 12 e8 00 00 00 e8 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 14 10 53 01
30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 04 18
40: 01 00 22 06 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:07.0 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
00: 86 80 10 71 0f 00 80 02 02 00 80 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 4d 00 f3 04
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 0b 0b 0b 0b 92 00 00 00 00 f2 00 00 00 00 00 00
70: 00 00 00 00 00 00 0c 0c 00 00 00 00 00 00 00 00
80: 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 07 81 11 10 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 25 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 30 0f 00 00 00 00 00 00

00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) (prog-if 80 [Master])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64
Region 0: [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [disabled] [size=8]
Region 1: [virtual] Memory at 000003f0 (type 3, non-prefetchable) [disabled] [size=1]
Region 2: [virtual] Memory at 00000170 (32-bit, non-prefetchable) [disabled] [size=8]
Region 3: [virtual] Memory at 00000370 (type 3, non-prefetchable) [disabled] [size=1]
Region 4: I/O ports at 1850 [size=16]
Kernel driver in use: PIIX_IDE
00: 86 80 11 71 05 00 80 02 01 80 01 01 00 40 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 51 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 07 a3 03 a3 00 00 00 00 05 00 02 02 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 30 0f 00 00 00 00 00 00

00:07.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01) (prog-if 00 [UHCI])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64
Interrupt: pin D routed to IRQ 11
Region 4: I/O ports at 1860 [size=32]
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00: 86 80 12 71 05 00 80 02 01 00 03 0c 00 40 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 61 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 04 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 30 0f 00 00 00 00 00 00

00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin ? routed to IRQ 9
00: 86 80 13 71 03 00 80 02 03 00 80 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 01 10 00 00 0f ff bf 10 e1 00 00 00 80 00 10 00
50: 03 50 1d 00 e0 c9 7f 06 37 80 00 02 00 00 00 80
60: 00 00 00 60 e8 15 e7 98 04 10 11 00 00 00 00 00
70: 00 fe 10 00 00 00 00 00 f0 03 17 00 2e 00 11 00
80: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 41 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 30 0f 00 00 00 00 00 00

01:00.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV (rev 11) (prog-if 00 [VGA controller])
Subsystem: IBM Thinkpad T20/T22
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64 (1000ns min, 63750ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 11
Region 0: Memory at f0000000 (32-bit, non-prefetchable) [size=128M]
[virtual] Expansion ROM at 40000000 [disabled] [size=64K]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [80] AGP version 1.0
Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2
Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>
00: 33 53 12 8c 07 00 30 02 11 00 00 03 08 40 00 00
10: 00 00 00 f0 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 14 10 7f 01
30: 00 00 00 00 dc 00 00 00 00 00 00 00 0b 01 04 ff
40: 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 02 00 10 00 03 02 00 1f 00 00 00 00 40 02 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 01 80 21 06
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab

2008-11-25 00:30:11

by Alan

[permalink] [raw]
Subject: Re: Is the change to IDE probing really necessary?

> > The mask is set to 0 and then the master/slave are detected based upon
> > the presence of PCI IDE devices on the master/slave ports.
> >
>
> This detection was not happening but then again the proper driver was not
> compiled. The .config I used was very minimal and lacked most drivers.

The lspci shows the correct thing happened. You have PCI devices and
didn't load the right driver. No driver, no support, no suprise.

> It is certainly the case I was not using the correct driver. Using
> CONFIG_BLK_DEV_PIIX instead of CONFIG_IDE_GENERIC makes everything work as
> expected without having to pass special options.

It would do - and you don't want to use pata_legacy/ide-generic for PCI
devices. There are several with quirks, some even corruptors that the
legacy drivers do not know how to handle.

So I think this is a case of 'I put best steam coal in my car and it
didn't go'

Alan

2008-11-25 00:36:56

by Mel Gorman

[permalink] [raw]
Subject: Re: Is the change to IDE probing really necessary?

On Tue, Nov 25, 2008 at 12:30:02AM +0000, Alan Cox wrote:
> > > The mask is set to 0 and then the master/slave are detected based upon
> > > the presence of PCI IDE devices on the master/slave ports.
> > >
> >
> > This detection was not happening but then again the proper driver was not
> > compiled. The .config I used was very minimal and lacked most drivers.
>
> The lspci shows the correct thing happened. You have PCI devices and
> didn't load the right driver. No driver, no support, no suprise.
>

Yeah, luck seemed to have been working up until this point :/. ide-generic
has been working on the machine since at least 2.6.23 for sure and probably
longer than that which is why it had the hallmarks of a regression even though
ide-generic appears to be doing something more safe and sensible these days.

> > It is certainly the case I was not using the correct driver. Using
> > CONFIG_BLK_DEV_PIIX instead of CONFIG_IDE_GENERIC makes everything work as
> > expected without having to pass special options.
>
> It would do - and you don't want to use pata_legacy/ide-generic for PCI
> devices. There are several with quirks, some even corruptors that the
> legacy drivers do not know how to handle.
>

Understood.

> So I think this is a case of 'I put best steam coal in my car and it
> didn't go'

Using piix, I won't have to call in Fred Flintstone to push it with his
legs instead.

Thanks

--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab

2008-11-25 07:22:17

by Borislav Petkov

[permalink] [raw]
Subject: Re: Is the change to IDE probing really necessary?

[.. ]

> > And the probing _is_ done when loaded as a module so the problem is
> > not with the mask - in your case the probing will work just fine as
> > you need ide0 and ide1, AFAICT.
>
> Out of curiousity, I loaded ide-generic as a module and tried the suggested
> probe_mask. It loads after e100 which is built in and then has a crap attack
> as it tries to register IO regions which are already registered, triggers
> sysfs warnings for creating duplicate files and then continues along to
> a state where networking doesn't work anyway. That suggestion of 0x3f may
> still catch someone.

Yep, the message could be misleading wrt to the probe_mask. Is something
along the lines of

"please adjust the probe_mask module parameter for probing the rest of the
legacy ISA IDE ports"

more informative? Now it implies that the primary/secondary ports are
probed by default.

However, you still have to set it to something > 0x3 if you want to
probe ide[2-5]. Also, there's still the option of CONFIG_BLK_DEV_GENERIC
which adds support for otherwise unsupported IDE PCI controllers.

--
Regards/Gruss,
Boris.

2008-11-25 10:45:22

by Mel Gorman

[permalink] [raw]
Subject: Re: Is the change to IDE probing really necessary?

On Tue, Nov 25, 2008 at 08:21:56AM +0100, Borislav Petkov wrote:
> [.. ]
>
> > > And the probing _is_ done when loaded as a module so the problem is
> > > not with the mask - in your case the probing will work just fine as
> > > you need ide0 and ide1, AFAICT.
> >
> > Out of curiousity, I loaded ide-generic as a module and tried the suggested
> > probe_mask. It loads after e100 which is built in and then has a crap attack
> > as it tries to register IO regions which are already registered, triggers
> > sysfs warnings for creating duplicate files and then continues along to
> > a state where networking doesn't work anyway. That suggestion of 0x3f may
> > still catch someone.
>
> Yep, the message could be misleading wrt to the probe_mask. Is something
> along the lines of
>
> "please adjust the probe_mask module parameter for probing the rest of the
> legacy ISA IDE ports"
>
> more informative? Now it implies that the primary/secondary ports are
> probed by default.
>

It's slightly better as it doesn't imply 0x3F is the right value in all
cases. It would be nice that some valid values are then documented
somewhere, be it in the modinfo information or
Documentation/ide/ide-generic.txt?

However, as this was clearly a PEBKAC problem of me loading the totally
wrong driver, maybe it's not worth the time.

> However, you still have to set it to something > 0x3 if you want to
> probe ide[2-5]. Also, there's still the option of CONFIG_BLK_DEV_GENERIC
> which adds support for otherwise unsupported IDE PCI controllers.
>

--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab

2008-11-26 21:48:22

by Bodo Eggert

[permalink] [raw]
Subject: Re: Is the change to IDE probing really necessary?

Alan Cox <[email protected]> wrote:

> So I think this is a case of 'I put best steam coal in my car and it
> didn't go'

"... but I was told it would."

I think less or different information (resulting in RTFM) might be more
helpful. Looking at the 2.6.27 code, I'd

- change the default to -1 (unset) and let ide_generic_init print the
text only if it's -1 (and then set it to the default value)
- change the text to
compiled_in? "please set ide_generic.probe_mask to use the generic IDE driver"
"please set probe_mask to probe for more legacy interfaces"
- not print anything if all interfaces are probed by default (non-x86)
- document "don't use this driver if there is a more specific driver"
next to the probe_mask documentation