Re: PNP parallel&serial ports: module reload fails (2.6.11)?

[Michael Tokarev <mjt@tls.msk.ru>]

castet.matthieu@free.fr wrote:
> Reply-To: 429CECE3.1060904@tls.msk.ru

This looks like a Message-ID of my original email you're replied to.
Why you set up Reply-To header this way? :)

> Hi,
> 
> try pnpacpi=off in your kernel options and it should work.
> An other solution is to comment pnpacpi_disable_resources in
> drivers/pnp/pnpacpi/core.c in order to avoid that the resource are
> disable.

Both ways solves this problem for me.  Now I can insmod/rmmod
parport_pc as many times as I want:

parport: PnPBIOS parport detected.
parport0: PC-style at 0x378, irq 7 [PCSPP]
pnp: Device 00:0b disabled.
pnp: Device 00:0b activated.
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378, irq 7 [PCSPP]
pnp: Device 00:0b disabled.
pnp: Device 00:0b activated.
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378, irq 7 [PCSPP]
....

BTW, how "stable" pnpacpi=off is?  I mean, is it supposed to
work on more hardware than current default acpi-aware method?

> When booting, the parport resources are enable by your kernel, and when
> you load for the first time the module there nothing to activate.
> 
> But when you rmmod the driver, you free the resource.

Well, I figured this much ;)

> And pnpacpi have some problem to activate resource with some strange acpi implementation...

I haven't seen any probs with acpi or bios or other things on
those boxen yet -- pretty good ones.  It's HP ProLiant ML150
machine (not G2).  There are other HP machines out here which
also shows the same problem - eg HP ProLiant ML310 G1.

> There was a problem in pnp layer implementation : the resource weren't
> given in the right order, Adam Belay send me a patch, but I don't know
> if it got in main-line ?

Which patch was that?  I can try it here, but can't seem to be able
to find it...

> May be there also a bug in pnpacpi_encode_resources (with the pnp patch
> apply I didn't still work on some hardware...)
> 
> You can try to send your dsdt, but I am quit busy for the moment.
> May be some Intel guy could look at the problem...

The DSDTs are at http://www.corpit.ru/mjt/hpml150.dsdt
and http://www.corpit.ru/mjt/hpml310.dsdt (that's a
(binary) copy from /proc/acpi/dsdt -- is there a way
to decode it into some text form?)

Thank you for your time.  At least I now know I'm not
alone with this prob.. ;)

/mjt