Hi Michael,

Michael Tokarev wrote:
> castet.matthieu@free.fr wrote:
> 
>> 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?
> 
pnpacpi=off use the old PNP bios  if it is enabled. It seem to work most 
of hardware that support it
(some recent acpi-only computer don't).
There could also have conflict if you use acpi and PNPBios together.

>> 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...
> 
http://bugme.osdl.org/attachment.cgi?id=4504&action=view plus the 
attached ones.

>> 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?)
> 
there is a dissasembler call iasl on intel site.

Matthieu