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

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

[castet.matthieu]

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.


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.

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

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 ?

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...


Matthieu

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

[Michael Tokarev]

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

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

[matthieu castet]

[-- Attachment #1: Type: text/plain, Size: 1998 bytes --]

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


[-- Attachment #2: pnp.patch --]
[-- Type: text/x-patch, Size: 608 bytes --]

Index: drivers/pnp/resource.c
===================================================================
RCS file: /home/mat/dev/linux-cvs-rep/linux-cvs/drivers/pnp/resource.c,v
retrieving revision 1.21
diff -u -r1.21 resource.c
--- drivers/pnp/resource.c	10 Nov 2004 01:11:02 -0000	1.21
+++ drivers/pnp/resource.c	5 Feb 2005 22:29:34 -0000
@@ -42,7 +42,7 @@
 
 	option->priority = priority & 0xff;
 	/* make sure the priority is valid */
-	if (option->priority > PNP_RES_PRIORITY_FUNCTIONAL)
+	if (option->priority > PNP_RES_PRIORITY_INDEPENDENT)
 		option->priority = PNP_RES_PRIORITY_INVALID;
 
 	return option;

[-- Attachment #3: pnp_rsparser.patch --]
[-- Type: text/x-patch, Size: 716 bytes --]

Index: drivers/pnp/pnpacpi/rsparser.c
===================================================================
RCS file: /home/mat/dev/linux-cvs-rep/linux-cvs/drivers/pnp/pnpacpi/rsparser.c,v
retrieving revision 1.2
diff -u -r1.2 rsparser.c
--- drivers/pnp/pnpacpi/rsparser.c	10 Nov 2004 01:11:02 -0000	1.2
+++ drivers/pnp/pnpacpi/rsparser.c	5 Feb 2005 22:01:14 -0000
@@ -506,7 +506,11 @@
 			parse_data->option = option;	
 			break;
 		case ACPI_RSTYPE_END_DPF:
-			return AE_CTRL_TERMINATE;
+			option = pnp_register_independent_option(dev);
+			if (!option)
+				return AE_ERROR;
+			parse_data->option = option;
+			break;
 		default:
 			pnp_warn("PnPACPI:Option type: %d not handle", res->id);
 			return AE_ERROR;

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

[matthieu castet]

Hi,

Michael Tokarev wrote:
> castet.matthieu@free.fr wrote:
> 
> 
> Thank you for your time.  At least I now know I'm not
> alone with this prob.. ;)
> 
In your bios, which mode is your parport ?

Could you try LPPR mode (or something like that ?)

Have you try the patches ?

thanks

Matthieu

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

[matthieu castet]

Michael Tokarev wrote:
> castet.matthieu@free.fr wrote:
>> 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.
> 
hpml310.dsl acpi dsdt is strange :


             Name (CRES, ResourceTemplate ()
             {
                 IRQNoFlags () {7}
                 DMA (Compatibility, NotBusMaster, Transfer8) {3}
                 IO (Decode16, 0x0378, 0x0378, 0x08, 0x08)
                 IO (Decode16, 0x0678, 0x0678, 0x00, 0x06)
             })

[...]
Name (_PRS, ResourceTemplate ()
             {
                 StartDependentFn (0x00, 0x00)
                 {
                     IO (Decode16, 0x0378, 0x0378, 0x00, 0x08)
                 }
                 StartDependentFn (0x00, 0x00)
                 {
                     IO (Decode16, 0x03BC, 0x03BC, 0x00, 0x03)
                 }
                 StartDependentFn (0x00, 0x00)
                 {
                     IO (Decode16, 0x0278, 0x0278, 0x00, 0x08)
                 }
                 EndDependentFn ()
             })

So in the list of possible resource (_PRS) there only info about one 
ioport not about the others resource. I wonder if it is really valid ?

Matthieu

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

[Michael Tokarev]

matthieu castet wrote:
> Michael Tokarev wrote:
> 
>> castet.matthieu@free.fr wrote:
>>
>>> 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.
>>
> hpml310.dsl acpi dsdt is strange :

[ it's in http://www.corpit.ru/mjt/hpml310.dsdt - apache ships it
  as Content-Type: text/plain, for some reason.  I grabbed iasl
  and converted that stuff into .dsls, available at:
  http://www.corpit.ru/mjt/hpml310.dsl and
  http://www.corpit.ru/mjt/hpml150.dsl ]

Well, the problem is, I don't know *at all* how ACPI stuff works.
So if you're saying the DSDT (whatever it is) is strange, I have
only two choices: to believe you or not.. ;)

>             Name (CRES, ResourceTemplate ()
>             {
>                 IRQNoFlags () {7}
>                 DMA (Compatibility, NotBusMaster, Transfer8) {3}
>                 IO (Decode16, 0x0378, 0x0378, 0x08, 0x08)
>                 IO (Decode16, 0x0678, 0x0678, 0x00, 0x06)
>             })
> 
> [...]
> Name (_PRS, ResourceTemplate ()
>             {
>                 StartDependentFn (0x00, 0x00)
>                 {
>                     IO (Decode16, 0x0378, 0x0378, 0x00, 0x08)
>                 }
>                 StartDependentFn (0x00, 0x00)
>                 {
>                     IO (Decode16, 0x03BC, 0x03BC, 0x00, 0x03)
>                 }
>                 StartDependentFn (0x00, 0x00)
>                 {
>                     IO (Decode16, 0x0278, 0x0278, 0x00, 0x08)
>                 }
>                 EndDependentFn ()
>             })
> 
> So in the list of possible resource (_PRS) there only info about one
> ioport not about the others resource. I wonder if it is really valid ?

I dunno, really.  Maybe dmidecode output will help somehow?  It's at
http://www.corpit.ru/mjt/hpml310.dmi for HP Proliant 310 G1 machine,
and http://www.corpit.ru/mjt/hpml150.dmi for ProLiant 150 G1.

All the 310 machines we have are in several remote offices, it will be
a while before I will be able to get some info about them requiring
console access.  Ditto for alot of HPML 150 ones too, but we have one
of them here at office, and I can perform experiments on this box.

The machine (ML 150) has one parallel and one serial port.  2nd serial
port - there's a place on the mobo for the 2nd serial port connector,
but it isn't ironed.

In other message, you wrote:

> In your bios, which mode is your parport ?
>
> Could you try LPPR mode (or something like that ?)

Are you referring to ECP, EPP, Bi-Di etc modes?
(note there's serial port too, which has exactly the same prob
with (re)loading the driver).

> Have you try the patches ?

Yes, tried the patches you sent last friday - from
http://bugme.osdl.org/attachment.cgi?id=4504&action=view
and from your message in this thread with MSGID = 429FF17C.9080902@free.fr
(this last patch depends on the first).  Makes no (visible) difference
on HP ML 150 box, the same stuff is shown in dmesg, and on reload neither
parallel nor serial ports works.

I'll try some more experiments later today (hopefully) when my co-workers
(who are using this box right now so I can't freely reboot it as I wish)
will go home... ;)

BTW, looks like 8250_pnp module is also somewhat strange.  When loading
8250 alone, it detects (at least some) standard serial ports just fine,
and when loading 8250_pnp, the same port is being "re-detected" again.
But when unloading 8250_pnp, even when 8250 module is still loaded,
that only port is disabled.  Looks somewhat.. assimetric to me, without
counting issue with re-enabling of a pnp device.

> thanks

Thank you for your time Matthieu.

Speaking of all this as a whole.  In addition to some "niceness" --
the whole issue is a bit ugly, but non-fatal, and it'd be nice to
fix it just because of that ugliness -- we're a bit (at least!)
dependant on that stuff to work, because on alot of different
machines, configuring at least parallel ports manually is kinda
difficult when it's possible to get it to work automatically.
I did ask you about how "stable" pnpacpi=off is, because it'd be
a solution for us too, -- to switch all machines to pnpacpi=off,
and expect it all to work.  But since there are quite a few modern
machines too here, wich might not work with pnpacpi=off, ... ;)
And speaking of why it is a problem with *reloading* the module --
sometimes, probably due to some other bugs/problems, parallel or
(more often) serial ports got "stuck", and reloading module helps
with that.  Again, addon (PCI) serial cards (finally, with a
patch wich went into 2.6.12-tobe, NetMos Tech. PCI 9835 Multi-I/O
Controllers are now supported without setserial hack... ;)

/mjt

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

[castet.matthieu]

Hi,

Selon Michael Tokarev <mjt@tls.msk.ru>:

> matthieu castet wrote:
> > Michael Tokarev wrote:
> >

> In other message, you wrote:
>
> > In your bios, which mode is your parport ?
> >
> > Could you try LPPR mode (or something like that ?)
>
> Are you referring to ECP, EPP, Bi-Di etc modes?
> (note there's serial port too, which has exactly the same prob
> with (re)loading the driver).
>
Yes, but I don't know which LPPR is : there is one mode that use 1 ioport and
the other 2 ioports.
Try EPP ?

> > Have you try the patches ?
>
> Yes, tried the patches you sent last friday - from
> http://bugme.osdl.org/attachment.cgi?id=4504&action=view
> and from your message in this thread with MSGID = 429FF17C.9080902@free.fr
> (this last patch depends on the first).  Makes no (visible) difference
> on HP ML 150 box, the same stuff is shown in dmesg, and on reload neither
> parallel nor serial ports works.
>
> I'll try some more experiments later today (hopefully) when my co-workers
> (who are using this box right now so I can't freely reboot it as I wish)
> will go home... ;)
>
try to post
 cat /sys/bus/pnp/drivers/parport_pc/*/{options,resources}
and
cat /sys/bus/pnp/drivers/serial/*/{options,resources}

> BTW, looks like 8250_pnp module is also somewhat strange.  When loading
> 8250 alone, it detects (at least some) standard serial ports just fine,
> and when loading 8250_pnp, the same port is being "re-detected" again.
> But when unloading 8250_pnp, even when 8250 module is still loaded,
> that only port is disabled.  Looks somewhat.. assimetric to me, without
> counting issue with re-enabling of a pnp device.
yes there something strange...

Matthieu

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

[Adam Belay]

On Mon, Jun 06, 2005 at 07:01:37PM +0400, Michael Tokarev wrote:
> matthieu castet wrote:
> > Michael Tokarev wrote:
> > 
> >> castet.matthieu@free.fr wrote:
> >>
> >>> 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.
> >>
> > hpml310.dsl acpi dsdt is strange :
> 
> [ it's in http://www.corpit.ru/mjt/hpml310.dsdt - apache ships it
>   as Content-Type: text/plain, for some reason.  I grabbed iasl
>   and converted that stuff into .dsls, available at:
>   http://www.corpit.ru/mjt/hpml310.dsl and
>   http://www.corpit.ru/mjt/hpml150.dsl ]
> 
> Well, the problem is, I don't know *at all* how ACPI stuff works.
> So if you're saying the DSDT (whatever it is) is strange, I have
> only two choices: to believe you or not.. ;)
> 
> >             Name (CRES, ResourceTemplate ()
> >             {
> >                 IRQNoFlags () {7}
> >                 DMA (Compatibility, NotBusMaster, Transfer8) {3}
> >                 IO (Decode16, 0x0378, 0x0378, 0x08, 0x08)
> >                 IO (Decode16, 0x0678, 0x0678, 0x00, 0x06)
> >             })
> > 
> > [...]
> > Name (_PRS, ResourceTemplate ()
> >             {
> >                 StartDependentFn (0x00, 0x00)
> >                 {
> >                     IO (Decode16, 0x0378, 0x0378, 0x00, 0x08)
> >                 }
> >                 StartDependentFn (0x00, 0x00)
> >                 {
> >                     IO (Decode16, 0x03BC, 0x03BC, 0x00, 0x03)
> >                 }
> >                 StartDependentFn (0x00, 0x00)
> >                 {
> >                     IO (Decode16, 0x0278, 0x0278, 0x00, 0x08)
> >                 }
> >                 EndDependentFn ()
> >             })
> > 
> > So in the list of possible resource (_PRS) there only info about one
> > ioport not about the others resource. I wonder if it is really valid ?

Hi Michael,

I've been looking into the parport issue.

Your ACPI _PRS method does look a little unusual (and possibly broken), but
it might work if we assume that all of the other resources not mentioned are
to be disabled.

I'd like to see how the PnP layer is interpreting this, and also what your
_CRS method is giving us.

Could I see the output of:

/sys/devices/pnp0/00:XX/resources

and:

/sys/bus/pnp/devices/00:XX/options

where XX is the function number of your parport device...  In one of your
earlier emails it was "08".

> Jun  1 02:45:46 linux kernel: pnp: Device 00:08 activated.

I appreciate your help.

Thanks,
Adam

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

[Michael Tokarev]

Adam Belay wrote:

Hmm.. Strange I haven't received your email.  Looking at our
maillog, looks like your host is listed in SORBS DUHL --
cpe-24-93-172-51.neo.res.rr.com[24.93.172.51].  Is it really
dynamic IP?  I'm sorry for the noise, but it's a real PITA
to handle email and spam properly nowadays... ;)

> On Mon, Jun 06, 2005 at 07:01:37PM +0400, Michael Tokarev wrote:
> 
[]
>>[ it's in http://www.corpit.ru/mjt/hpml310.dsdt - apache ships it
>>  as Content-Type: text/plain, for some reason.  I grabbed iasl
>>  and converted that stuff into .dsls, available at:
>>  http://www.corpit.ru/mjt/hpml310.dsl and
>>  http://www.corpit.ru/mjt/hpml150.dsl ]
>>
[]
> I've been looking into the parport issue.
> 
> Your ACPI _PRS method does look a little unusual (and possibly broken), but
> it might work if we assume that all of the other resources not mentioned are
> to be disabled.

Broken - is it a broken bios (so I will ask HP for an update),
or is it just how things works? ;)

BTW, there are quite some resources mentioned at PNP init time,
like this:

pnp: 00:08: ioport range 0x680-0x6ff has been reserved
pnp: 00:0c: ioport range 0x400-0x47f could not be reserved
pnp: 00:0c: ioport range 0x680-0x6ff has been reserved
pnp: 00:0c: ioport range 0x500-0x53f has been reserved
pnp: 00:0c: ioport range 0x500-0x53f has been reserved
pnp: 00:0c: ioport range 0x400-0x47f could not be reserved
pnp: 00:0c: ioport range 0x295-0x296 has been reserved
pnp: 00:0c: ioport range 0x3e0-0x3e7 has been reserved

> I'd like to see how the PnP layer is interpreting this, and also what your
> _CRS method is giving us.
> 
> Could I see the output of:
> 
> /sys/devices/pnp0/00:XX/resources
> 
> and:
> 
> /sys/bus/pnp/devices/00:XX/options
> 
> where XX is the function number of your parport device...  In one of your
> earlier emails it was "08".

Sure.  With one exception: I can't find a machine where this is
really "08" now.  I think I grabbed all that info from our machine
here at office (HPML150), but now it is reporting id 00:07, not
00:08 (maybe after we experimented with various modes of parallel
port - ECP/EPP/Standard - in bios).  Maybe it was from another
machine (in a remote office) where I first tried to deal with
the problem.  I checked current dsdt - it's still the same as on
the URL above.

Here's all the stuff from /sys/bus/pnp/devices/*/{resources,options}
on this machine (HPML150), devices 00:06 (serial port) and 00:07
(parallel port) are on top, after first load of parport_pc and 8250_pnp
modules (for all other devices, options file is empty):

00:06
state = active
io 0x3f8-0x3ff
irq 4

irq 3,4,5,6,7,10,11,12 High-Edge
Dependent: 01 - Priority acceptable
    port 0x3f8-0x3f8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 02 - Priority acceptable
    port 0x2f8-0x2f8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 03 - Priority acceptable
    port 0x3e8-0x3e8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 04 - Priority acceptable
    port 0x2e8-0x2e8, align 0x0, size 0x8, 16-bit address decoding

00:07
state = active
io 0x378-0x37f
irq 7

Dependent: 01 - Priority acceptable
    port 0x378-0x378, align 0x0, size 0x8, 16-bit address decoding
    irq 3,4,5,6,7,10,11,12 High-Edge
Dependent: 02 - Priority acceptable
    port 0x278-0x278, align 0x0, size 0x8, 16-bit address decoding
    irq 3,4,5,6,7,10,11,12 High-Edge
Dependent: 03 - Priority acceptable
    port 0x3bc-0x3bc, align 0x0, size 0x4, 16-bit address decoding
    irq 3,4,5,6,7,10,11,12 High-Edge
Dependent: 04 - Priority acceptable
    port 0x378-0x378, align 0x0, size 0x8, 16-bit address decoding
Dependent: 05 - Priority acceptable
    port 0x278-0x278, align 0x0, size 0x8, 16-bit address decoding
Dependent: 06 - Priority acceptable
    port 0x3bc-0x3bc, align 0x0, size 0x4, 16-bit address decoding

00:00
state = active
io 0x0-0xf
io 0x81-0x83
io 0x87-0x87
io 0x89-0x8b
io 0x8f-0x8f
io 0xc0-0xdf
dma 4

00:01
state = active
io 0x70-0x71
irq 8

00:02
state = active
io 0x60-0x60
io 0x64-0x64
irq 1

00:03
state = active
irq 12

00:04
state = active
io 0x61-0x61

00:05
state = active
io 0xf0-0xff
irq 13

00:08
state = active
io disabled
io 0x680-0x6ff

00:09
state = active
io 0x10-0x1f
io 0x22-0x3f
io 0x44-0x5f
io 0x62-0x63
io 0x65-0x6f
io 0x72-0x7f
io 0x80-0x80
io 0x84-0x86

00:0a
state = active
mem 0xffb00000-0xffbfffff
mem 0xfff00000-0xffffffff

00:0b
state = active
mem 0xffc00000-0xffefffff

00:0c
state = active
io 0x400-0x47f
io disabled
io 0x680-0x6ff
io 0x500-0x53f
io 0x500-0x53f
io 0x400-0x47f
io 0x295-0x296
io 0x3e0-0x3e7
mem 0xfec00000-0xfecfffff
mem 0xfee00000-0xfee00fff

00:0d
state = active
mem 0x0-0x9ffff
mem 0xc0000-0xdffff
mem 0xe0000-0xfffff
mem 0x100000-0x7fffffff


Additionally, here's /proc/ioports after re-load of
parport_pc and 8250_pnp modules:

0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0295-0296 : pnp 00:0c
# 0378-037a : parport0 - it WAS here before parport_pc unload
03c0-03df : vga+
03e0-03e7 : pnp 00:0c
0400-047f : 0000:00:1f.0
   0400-0403 : PM1a_EVT_BLK
   0404-0405 : PM1a_CNT_BLK
   0408-040b : PM_TMR
   0420-0420 : PM2_CNT_BLK
   0428-042b : GPE0_BLK
   042c-042f : GPE1_BLK
0500-053f : 0000:00:1f.0
   0500-053f : pnp 00:0c
     0500-053f : pnp 00:0c
0540-055f : 0000:00:1f.3
0680-06ff : pnp 00:08
   0680-06ff : pnp 00:0c
0cf8-0cff : PCI conf1
8800-880f : 0000:01:00.0
9000-9007 : 0000:01:00.0
9400-9407 : 0000:01:00.0
9800-9807 : 0000:01:00.0
a000-a007 : 0000:01:00.0
a400-a407 : 0000:01:00.0
a800-a8ff : 0000:01:02.0
b000-dfff : PCI Bus #02
   b000-dfff : PCI Bus #04
     c400-c43f : 0000:04:01.0
       c400-c43f : e1000
     c800-c8ff : 0000:04:04.0
       c800-c8ff : aic79xx
     d000-d0ff : 0000:04:04.0
       d000-d0ff : aic79xx
     d400-d4ff : 0000:04:04.1
       d400-d4ff : aic79xx
     d800-d8ff : 0000:04:04.1
       d800-d8ff : aic79xx
e800-e81f : 0000:00:1d.0
ffa0-ffaf : 0000:00:1f.1
   ffa0-ffa7 : ide0
   ffa8-ffaf : ide1


And here's the same from hpml350 machine (the one Matthieu was
referring to when looking at the dsdt stuff) -- with just-loaded
(for the first time) parport_pc and 8250_pnp modules:

00:00
state = active
io 0xf50-0xf58
io 0x408-0x40f
io 0x92-0x92
io 0x900-0x903
io 0x904-0x904
io 0x910-0x911
io 0x920-0x923
io 0x930-0x937


00:01
state = active
io 0x0-0xf
io 0x80-0x8f
io 0xc0-0xdf
io 0x40b-0x40b
io 0x4d6-0x4d6
dma 7

00:02
state = active
io 0x61-0x61

00:03
state = active
io 0x60-0x60
io 0x64-0x64
irq 1

00:04
state = active
irq 12

00:05
state = active
io 0x2e-0x2f
io 0x220-0x223
io 0x240-0x25f
io 0x70-0x73

00:06
state = active
io 0x378-0x37f
io 0x778-0x77d
irq 7
dma 0

Dependent: 01 - Priority preferred
    port 0x378-0x378, align 0x0, size 0x8, 16-bit address decoding
Dependent: 02 - Priority preferred
    port 0x3bc-0x3bc, align 0x0, size 0x3, 16-bit address decoding
Dependent: 03 - Priority preferred
    port 0x278-0x278, align 0x0, size 0x8, 16-bit address decoding

00:07
state = active
io 0x3f8-0x3ff
irq 4

Dependent: 01 - Priority preferred
    port 0x3f8-0x3f8, align 0x7, size 0x8, 16-bit address decoding
    irq 4 High-Edge
Dependent: 02 - Priority acceptable
    port 0x2f8-0x2f8, align 0x7, size 0x8, 16-bit address decoding
    irq 3 High-Edge
Dependent: 03 - Priority functional
    port 0x3e8-0x3f8, align 0x7, size 0x8, 16-bit address decoding
    irq 4 High-Edge
Dependent: 04 - Priority functional
    port 0x2e8-0x2f8, align 0x7, size 0x8, 16-bit address decoding
    irq 3 High-Edge

00:08
state = active
io 0x2f8-0x2ff
irq 3

Dependent: 01 - Priority preferred
    port 0x3f8-0x3f8, align 0x7, size 0x8, 16-bit address decoding
    irq 4 High-Edge
Dependent: 02 - Priority acceptable
    port 0x2f8-0x2f8, align 0x7, size 0x8, 16-bit address decoding
    irq 3 High-Edge
Dependent: 03 - Priority functional
    port 0x3e8-0x3f8, align 0x7, size 0x8, 16-bit address decoding
    irq 4 High-Edge
Dependent: 04 - Priority functional
    port 0x2e8-0x2f8, align 0x7, size 0x8, 16-bit address decoding
    irq 3 High-Edge

00:09
state = active
io 0x3f2-0x3f5
irq 6
dma 2

port 0x3f0-0x3f0, align 0x0, size 0x6, 16-bit address decoding
port 0x3f7-0x3f7, align 0x0, size 0x1, 16-bit address decoding
irq 6 High-Edge
dma 2 8-bit compatible


/proc/ioports:

0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0220-0223 : PM1b_EVT_BLK
0230-0233 : PM1a_CNT_BLK
02f8-02ff : serial
0378-037a : parport0
03c0-03df : vga+
03f8-03ff : serial
0408-040f : pnp 00:00
0900-0903 : PM1a_EVT_BLK
0904-0904 : pnp 00:00
0910-0913 : PM1b_CNT_BLK
0920-0923 : PM_TMR
0930-0937 : pnp 00:00
0cf8-0cff : PCI conf1
0f50-0f58 : pnp 00:00
1800-18ff : 0000:00:05.0
2000-200f : 0000:00:0f.1
2400-24ff : 0000:00:01.0
2800-28ff : 0000:00:04.0

I'm sorry for alot of digits...  As I already mentioned, I know
right to nothing about acpi and pnp subsystems to know if all this
is useless or not... ;)

Thank you.

/mjt

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

[Adam Belay]

On Tue, 2005-06-07 at 02:43 +0400, Michael Tokarev wrote:
> Adam Belay wrote:
> 
> Hmm.. Strange I haven't received your email.  Looking at our
> maillog, looks like your host is listed in SORBS DUHL --
> cpe-24-93-172-51.neo.res.rr.com[24.93.172.51].  Is it really
> dynamic IP?  I'm sorry for the noise, but it's a real PITA
> to handle email and spam properly nowadays... ;)

Yeah, it was a dynamic IP :).  I'm sending from a different server this
time.

> 
> > On Mon, Jun 06, 2005 at 07:01:37PM +0400, Michael Tokarev wrote:
> > 
> []
> >>[ it's in http://www.corpit.ru/mjt/hpml310.dsdt - apache ships it
> >>  as Content-Type: text/plain, for some reason.  I grabbed iasl
> >>  and converted that stuff into .dsls, available at:
> >>  http://www.corpit.ru/mjt/hpml310.dsl and
> >>  http://www.corpit.ru/mjt/hpml150.dsl ]
> >>
> []
> > I've been looking into the parport issue.
> > 
> > Your ACPI _PRS method does look a little unusual (and possibly broken), but
> > it might work if we assume that all of the other resources not mentioned are
> > to be disabled.
> 
> Broken - is it a broken bios (so I will ask HP for an update),
> or is it just how things works? ;)

Hi,

I'm sorry for the delayed response, as this bug is very difficult to
track down.  The information you provided was helpful and I appreciate
it.  I have a theory as to what is going on, and the patch below might
solve your problem.  If not, it will at least give us some more
information.

The following would be useful:

1.) a complete dmesg after initial boot with the patch
2.) kernel message output after "rmmod parport_pc" and "modprobe
parport_pc" with the patch

I designed this patch to fix both "hpml150.dsl" and "hpml310.dsl".  If
you have time, could you test it on both platforms?  This is a hack, so
if it works, I'll give a more complete explanation and an official fix.

Thanks,
Adam

--- a/drivers/pnp/pnpacpi/rsparser.c	2005-05-27 22:06:02.000000000 -0400
+++ b/drivers/pnp/pnpacpi/rsparser.c	2005-06-08 05:36:57.410599288 -0400
@@ -178,6 +178,8 @@
 		if (res->data.dma.number_of_channels > 0)
 			pnpacpi_parse_allocated_dmaresource(res_table, 
 					res->data.dma.channels[0]);
+		else
+			printk(KERN_INFO "pnp: skipping dma from _CRS\n");
 		break;
 	case ACPI_RSTYPE_IO:
 		pnpacpi_parse_allocated_ioresource(res_table, 
@@ -242,8 +244,10 @@
 	int i;
 	struct pnp_dma * dma;
 
-	if (p->number_of_channels == 0)
+	if (p->number_of_channels == 0) {
+		printk(KERN_INFO "pnp: broken dma code, fix me\n");
 		return;
+	}
 	dma = pnpacpi_kmalloc(sizeof(struct pnp_dma), GFP_KERNEL);
 	if (!dma)
 		return;
@@ -298,8 +302,10 @@
 	int i;
 	struct pnp_irq * irq;
 	
-	if (p->number_of_interrupts == 0)
+	if (p->number_of_interrupts == 0) {
+		printk(KERN_INFO "pnp: broken irq code, fix me\n");
 		return;
+	}
 	irq = pnpacpi_kmalloc(sizeof(struct pnp_irq), GFP_KERNEL);
 	if (!irq)
 		return;
@@ -625,7 +631,12 @@
 	struct resource *p)
 {
 	int edge_level, active_high_low;
-	
+
+	if (p->flags & IORESOURCE_UNSET) {
+		printk(KERN_INFO "bug squashed - irq\n");
+		return;
+	}
+
 	decode_irq_flags(p->flags & IORESOURCE_BITS, &edge_level, 
 		&active_high_low);
 	resource->id = ACPI_RSTYPE_IRQ;
@@ -636,6 +647,18 @@
 		resource->data.irq.shared_exclusive = ACPI_EXCLUSIVE;
 	else
 		resource->data.irq.shared_exclusive = ACPI_SHARED;
+
+	if (ACPI_EDGE_SENSITIVE == resource->data.irq.edge_level &&
+		ACPI_ACTIVE_HIGH == resource->data.irq.active_high_low &&
+		ACPI_EXCLUSIVE == resource->data.irq.shared_exclusive) {
+		printk(KERN_INFO "pnp: irq flags are correct\n");
+	} else {
+		printk(KERN_INFO "pnp: attempting to fix irq flags\n");
+		resource->data.irq.edge_level = ACPI_EDGE_SENSITIVE;
+		resource->data.irq.active_high_low = ACPI_ACTIVE_HIGH;
+		resource->data.irq.shared_exclusive = ACPI_EXCLUSIVE;
+	}
+
 	resource->data.irq.number_of_interrupts = 1;
 	resource->data.irq.interrupts[0] = p->start;
 }
@@ -644,6 +667,11 @@
 	struct resource *p)
 {
 	int edge_level, active_high_low;
+
+	if (p->flags & IORESOURCE_UNSET) {
+		printk(KERN_INFO "bug squashed - irq_ext\n");
+		return;
+	}
 	
 	decode_irq_flags(p->flags & IORESOURCE_BITS, &edge_level, 
 		&active_high_low);
@@ -663,6 +691,11 @@
 static void pnpacpi_encode_dma(struct acpi_resource *resource,
 	struct resource *p)
 {
+	if (p->flags & IORESOURCE_UNSET) {
+		printk(KERN_INFO "bug squashed - dma \n");
+		return;
+	}
+
 	resource->id = ACPI_RSTYPE_DMA;
 	resource->length = sizeof(struct acpi_resource);
 	/* Note: pnp_assign_dma will copy pnp_dma->flags into p->flags */
@@ -695,7 +728,6 @@
 		ACPI_DECODE_16 : ACPI_DECODE_10; 
 	resource->data.io.min_base_address = p->start;
 	resource->data.io.max_base_address = p->end;
-	resource->data.io.alignment = 0; /* Correct? */
 	resource->data.io.range_length = p->end - p->start + 1;
 }
 
@@ -719,7 +751,6 @@
 		ACPI_READ_WRITE_MEMORY : ACPI_READ_ONLY_MEMORY;
 	resource->data.memory24.min_base_address = p->start;
 	resource->data.memory24.max_base_address = p->end;
-	resource->data.memory24.alignment = 0;
 	resource->data.memory24.range_length = p->end - p->start + 1;
 }
 
@@ -733,7 +764,6 @@
 		ACPI_READ_WRITE_MEMORY : ACPI_READ_ONLY_MEMORY;
 	resource->data.memory32.min_base_address = p->start;
 	resource->data.memory32.max_base_address = p->end;
-	resource->data.memory32.alignment = 0;
 	resource->data.memory32.range_length = p->end - p->start + 1;
 }
 

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

[Michael Tokarev]

Adam Belay wrote:
[]
>>>>[ it's in http://www.corpit.ru/mjt/hpml310.dsdt - apache ships it
>>>> as Content-Type: text/plain, for some reason.  I grabbed iasl
>>>> and converted that stuff into .dsls, available at:
>>>> http://www.corpit.ru/mjt/hpml310.dsl and
>>>> http://www.corpit.ru/mjt/hpml150.dsl ]
[]
> Hi,
> 
> I'm sorry for the delayed response, as this bug is very difficult to
> track down.  The information you provided was helpful and I appreciate
> it.  I have a theory as to what is going on, and the patch below might
> solve your problem.  If not, it will at least give us some more
> information.

Well, not much of info, really.. ;)

> The following would be useful:
> 
> 1.) a complete dmesg after initial boot with the patch
> 2.) kernel message output after "rmmod parport_pc" and "modprobe
> parport_pc" with the patch

Here it is.  From HP ML 150 box.  I compiled 2.6.11-rc6 with
the patch you've sent.

Linux version 2.6.12-i786smp-rc6-0 (mjt@paltus.tls.msk.ru) (gcc version 3.3.5 (Debian 1:3.3.5-12)) #1 SMP Wed Jun 8 18:01:05 MSD 2005
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000007fff0000 (usable)
 BIOS-e820: 000000007fff0000 - 000000007ffff000 (ACPI data)
 BIOS-e820: 000000007ffff000 - 0000000080000000 (ACPI NVS)
 BIOS-e820: 00000000fec00000 - 00000000fed00000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ffb80000 - 0000000100000000 (reserved)
1151MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 000ff780
On node 0 totalpages: 524272
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 225280 pages, LIFO batch:31
  HighMem zone: 294896 pages, LIFO batch:31
DMI 2.3 present.
ACPI: RSDP (v000 ACPIAM                                ) @ 0x000f4fa0
ACPI: RSDT (v001 A M I  OEMRSDT  0x08000311 MSFT 0x00000097) @ 0x7fff0000
ACPI: FADT (v002 A M I  OEMFACP  0x08000311 MSFT 0x00000097) @ 0x7fff0200
ACPI: MADT (v001 A M I  OEMAPIC  0x08000311 MSFT 0x00000097) @ 0x7fff0300
ACPI: OEMB (v001 A M I  OEMBIOS  0x08000311 MSFT 0x00000097) @ 0x7ffff040
ACPI: DSDT (v001  0ABBP 0ABBP001 0x00000001 MSFT 0x0100000d) @ 0x00000000
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:2 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x06] enabled)
Processor #6 15:2 APIC version 20
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] enabled)
Processor #1 15:2 APIC version 20
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x07] enabled)
Processor #7 15:2 APIC version 20
ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
ACPI: IOAPIC (id[0x09] address[0xfec80000] gsi_base[24])
IOAPIC[1]: apic_id 9, version 32, address 0xfec80000, GSI 24-47
ACPI: IOAPIC (id[0x0a] address[0xfec80400] gsi_base[48])
IOAPIC[2]: apic_id 10, version 32, address 0xfec80400, GSI 48-71
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 3 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 80000000 (gap: 80000000:7ec00000)
Built 1 zonelists
Kernel command line: auto BOOT_IMAGE=2.6.12-rc6-0 ro root=100 panic=60 elevator=
deadline
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
mapped IOAPIC to ffffb000 (fec80000)
mapped IOAPIC to ffffa000 (fec80400)
Initializing CPU#0
....
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: skipping dma from _CRS
pnp: broken dma code, fix me
pnp: broken dma code, fix me
pnp: broken dma code, fix me
pnp: broken dma code, fix me
pnp: skipping dma from _CRS
pnp: broken dma code, fix me
pnp: broken dma code, fix me
pnp: broken dma code, fix me
pnp: broken irq code, fix me
pnp: broken dma code, fix me
pnp: broken irq code, fix me
pnp: broken dma code, fix me
pnp: broken irq code, fix me
pnp: broken dma code, fix me
pnp: PnP ACPI: found 14 devices
PnPBIOS: Disabled by ACPI PNP
...
pnp: 00:08: ioport range 0x680-0x6ff has been reserved
pnp: 00:0c: ioport range 0x400-0x47f could not be reserved
pnp: 00:0c: ioport range 0x680-0x6ff has been reserved
pnp: 00:0c: ioport range 0x500-0x53f has been reserved
pnp: 00:0c: ioport range 0x500-0x53f has been reserved
pnp: 00:0c: ioport range 0x400-0x47f could not be reserved
pnp: 00:0c: ioport range 0x295-0x296 has been reserved
pnp: 00:0c: ioport range 0x3e0-0x3e7 has been reserved
....
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
PNP: PS/2 Controller [PNP0303:PS2K,PNP0f03:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
....

[modprobe parport_pc]
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378, irq 7 [PCSPP]
[rmmod parport_pc]
pnp: Device 00:07 disabled.
[modprobe parport_pc]
pnp: attempting to fix irq flags
bug squashed - dma

[at this point, modprobe is stuck, with `_stext' (it seems)
 in /proc/$modprobe_pid/wchan, eating 100% of one CPU, with
 another fair load from migration/0 and events/0 threads.
 strace on it gets stuck too.]

I can try 2.6.11 too.  I'm a bit afraid to try this on
HP ML 310 box for now - this HPML150 seems to have rebooted
nicely without any bad things, but if that HPML310 (production)
machine will not come back automatically, it'll be a bit of
a problem.. ;)

/mjt

> I designed this patch to fix both "hpml150.dsl" and "hpml310.dsl".  If
> you have time, could you test it on both platforms?  This is a hack, so
> if it works, I'll give a more complete explanation and an official fix.
> 
> Thanks,
> Adam
> 
> --- a/drivers/pnp/pnpacpi/rsparser.c	2005-05-27 22:06:02.000000000 -0400
> +++ b/drivers/pnp/pnpacpi/rsparser.c	2005-06-08 05:36:57.410599288 -0400
[]

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

[Adam Belay]

On Thu, Jun 09, 2005 at 12:29:25AM +0400, Michael Tokarev wrote:
> Adam Belay wrote:
> []
> >>>>[ it's in http://www.corpit.ru/mjt/hpml310.dsdt - apache ships it
> >>>> as Content-Type: text/plain, for some reason.  I grabbed iasl
> >>>> and converted that stuff into .dsls, available at:
> >>>> http://www.corpit.ru/mjt/hpml310.dsl and
> >>>> http://www.corpit.ru/mjt/hpml150.dsl ]
> []
> > Hi,
> > 
> > I'm sorry for the delayed response, as this bug is very difficult to
> > track down.  The information you provided was helpful and I appreciate
> > it.  I have a theory as to what is going on, and the patch below might
> > solve your problem.  If not, it will at least give us some more
> > information.
> 
> Well, not much of info, really.. ;)
> 
> > The following would be useful:
> > 
> > 1.) a complete dmesg after initial boot with the patch
> > 2.) kernel message output after "rmmod parport_pc" and "modprobe
> > parport_pc" with the patch
> 
> Here it is.  From HP ML 150 box.  I compiled 2.6.11-rc6 with
> the patch you've sent.
> 

Sorry, I forgot to set the range length, so it looped in
acpi_rs_list_to_byte_stream forever, instead of making it to _SRS.
This rediff should fix the problem.

Thanks,
Adam

--- a/drivers/pnp/pnpacpi/core.c	2005-03-02 02:38:09.000000000 -0500
+++ b/drivers/pnp/pnpacpi/core.c	2005-06-08 19:37:12.000000000 -0400
@@ -99,17 +99,21 @@
 	int ret = 0;
 	acpi_status status;
 
+	printk (KERN_INFO "pnp: building resource template\n");
 	ret = pnpacpi_build_resource_template(handle, &buffer);
 	if (ret)
 		return ret;
+	printk (KERN_INFO "pnp: encoding resources\n");
 	ret = pnpacpi_encode_resources(res, &buffer);
 	if (ret) {
 		kfree(buffer.pointer);
 		return ret;
 	}
+	printk (KERN_INFO "pnp: setting resources\n");
 	status = acpi_set_current_resources(handle, &buffer);
 	if (ACPI_FAILURE(status))
 		ret = -EINVAL;
+	printk (KERN_INFO "pnp: _SRS worked correctly\n");
 	kfree(buffer.pointer);
 	return ret;
 }
--- a/drivers/pnp/pnpacpi/rsparser.c	2005-05-27 22:06:02.000000000 -0400
+++ b/drivers/pnp/pnpacpi/rsparser.c	2005-06-08 19:38:14.802869256 -0400
@@ -178,6 +178,8 @@
 		if (res->data.dma.number_of_channels > 0)
 			pnpacpi_parse_allocated_dmaresource(res_table, 
 					res->data.dma.channels[0]);
+		else
+			printk(KERN_INFO "pnp: skipping dma from _CRS\n");
 		break;
 	case ACPI_RSTYPE_IO:
 		pnpacpi_parse_allocated_ioresource(res_table, 
@@ -242,8 +244,10 @@
 	int i;
 	struct pnp_dma * dma;
 
-	if (p->number_of_channels == 0)
+	if (p->number_of_channels == 0) {
+		printk(KERN_INFO "pnp: broken dma code, fix me\n");
 		return;
+	}
 	dma = pnpacpi_kmalloc(sizeof(struct pnp_dma), GFP_KERNEL);
 	if (!dma)
 		return;
@@ -298,8 +302,10 @@
 	int i;
 	struct pnp_irq * irq;
 	
-	if (p->number_of_interrupts == 0)
+	if (p->number_of_interrupts == 0) {
+		printk(KERN_INFO "pnp: broken irq code, fix me\n");
 		return;
+	}
 	irq = pnpacpi_kmalloc(sizeof(struct pnp_irq), GFP_KERNEL);
 	if (!irq)
 		return;
@@ -625,7 +631,15 @@
 	struct resource *p)
 {
 	int edge_level, active_high_low;
-	
+
+	if (p->flags & IORESOURCE_UNSET) {
+		printk(KERN_INFO "bug squashed - irq\n");
+		resource->id = ACPI_RSTYPE_IRQ;
+		resource->length = sizeof(struct acpi_resource);
+		resource->data.irq.number_of_interrupts = 0;
+		return;
+	}
+
 	decode_irq_flags(p->flags & IORESOURCE_BITS, &edge_level, 
 		&active_high_low);
 	resource->id = ACPI_RSTYPE_IRQ;
@@ -636,6 +650,18 @@
 		resource->data.irq.shared_exclusive = ACPI_EXCLUSIVE;
 	else
 		resource->data.irq.shared_exclusive = ACPI_SHARED;
+
+	if (ACPI_EDGE_SENSITIVE == resource->data.irq.edge_level &&
+		ACPI_ACTIVE_HIGH == resource->data.irq.active_high_low &&
+		ACPI_EXCLUSIVE == resource->data.irq.shared_exclusive) {
+		printk(KERN_INFO "pnp: irq flags are correct\n");
+	} else {
+		printk(KERN_INFO "pnp: attempting to fix irq flags\n");
+		resource->data.irq.edge_level = ACPI_EDGE_SENSITIVE;
+		resource->data.irq.active_high_low = ACPI_ACTIVE_HIGH;
+		resource->data.irq.shared_exclusive = ACPI_EXCLUSIVE;
+	}
+
 	resource->data.irq.number_of_interrupts = 1;
 	resource->data.irq.interrupts[0] = p->start;
 }
@@ -644,6 +670,14 @@
 	struct resource *p)
 {
 	int edge_level, active_high_low;
+
+	if (p->flags & IORESOURCE_UNSET) {
+		printk(KERN_INFO "bug squashed - irq_ext\n");
+		resource->id = ACPI_RSTYPE_EXT_IRQ;
+		resource->length = sizeof(struct acpi_resource);
+		resource->data.extended_irq.number_of_interrupts = 0;
+		return;
+	}
 	
 	decode_irq_flags(p->flags & IORESOURCE_BITS, &edge_level, 
 		&active_high_low);
@@ -663,6 +697,14 @@
 static void pnpacpi_encode_dma(struct acpi_resource *resource,
 	struct resource *p)
 {
+	if (p->flags & IORESOURCE_UNSET) {
+		printk(KERN_INFO "bug squashed - dma \n");
+		resource->id = ACPI_RSTYPE_DMA;
+		resource->length = sizeof(struct acpi_resource);
+		resource->data.dma.number_of_channels = 0;
+		return;
+	}
+
 	resource->id = ACPI_RSTYPE_DMA;
 	resource->length = sizeof(struct acpi_resource);
 	/* Note: pnp_assign_dma will copy pnp_dma->flags into p->flags */
@@ -695,7 +737,6 @@
 		ACPI_DECODE_16 : ACPI_DECODE_10; 
 	resource->data.io.min_base_address = p->start;
 	resource->data.io.max_base_address = p->end;
-	resource->data.io.alignment = 0; /* Correct? */
 	resource->data.io.range_length = p->end - p->start + 1;
 }
 
@@ -719,7 +760,6 @@
 		ACPI_READ_WRITE_MEMORY : ACPI_READ_ONLY_MEMORY;
 	resource->data.memory24.min_base_address = p->start;
 	resource->data.memory24.max_base_address = p->end;
-	resource->data.memory24.alignment = 0;
 	resource->data.memory24.range_length = p->end - p->start + 1;
 }
 
@@ -733,7 +773,6 @@
 		ACPI_READ_WRITE_MEMORY : ACPI_READ_ONLY_MEMORY;
 	resource->data.memory32.min_base_address = p->start;
 	resource->data.memory32.max_base_address = p->end;
-	resource->data.memory32.alignment = 0;
 	resource->data.memory32.range_length = p->end - p->start + 1;
 }
 

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

[Michael Tokarev]

Adam Belay wrote:
> On Thu, Jun 09, 2005 at 12:29:25AM +0400, Michael Tokarev wrote:
> 
>>Adam Belay wrote:
>>[]
>>
>>>>>>[ it's in http://www.corpit.ru/mjt/hpml310.dsdt - apache ships it
>>>>>>as Content-Type: text/plain, for some reason.  I grabbed iasl
>>>>>>and converted that stuff into .dsls, available at:
>>>>>>http://www.corpit.ru/mjt/hpml310.dsl and
>>>>>>http://www.corpit.ru/mjt/hpml150.dsl ]
[]
>>>1.) a complete dmesg after initial boot with the patch
>>>2.) kernel message output after "rmmod parport_pc" and "modprobe
>>>parport_pc" with the patch

Hello again.  This whole conversation seems to be a bit...
slow, probably due to $TZ differences and the fact that
I can do experiments only at evenings, because the test
machine (and non-test one too) are busy during work hours.

Adam, I built 2.6.12-rc6 with your last patch, and tried it on
both ML150 and ML310 machines.  And in both cases, the whole
thing worked.

Dmesg from HPML150:

[modprobe parport_pc]
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378, irq 7 [PCSPP]
[rmmod parport_pc]
pnp: Device 00:07 disabled.
[modprobe parport_pc]
pnp: building resource template
pnp: encoding resources
pnp: attempting to fix irq flags
bug squashed - dma
pnp: setting resources
pnp: _SRS worked correctly
pnp: Device 00:07 activated.
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378, irq 7 [PCSPP]

The same applies to 8250_pnp module:

[modprobe 8250_pnp]
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing enabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[rmmod 8250_pnp]
pnp: Device 00:06 disabled.
[modprobe 8250_pnp]
pnp: building resource template
pnp: encoding resources
pnp: attempting to fix irq flags
bug squashed - dma
pnp: setting resources
pnp: _SRS worked correctly
pnp: Device 00:06 activated.
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A


And HP ML 310 box:

[modprobe parport_pc]
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
[rmmod parport_pc]
pnp: Device 00:06 disabled.
[modprobe parport_pc]
pnp: building resource template
pnp: encoding resources
pnp: attempting to fix irq flags
pnp: setting resources
pnp: _SRS worked correctly
pnp: Device 00:06 activated.
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]

[modprobe 8250_pnp]
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing enabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[rmmod 8250_pnp]
pnp: Device 00:07 disabled.
pnp: Device 00:08 disabled.
[modprobe 8250_pnp]
pnp: building resource template
pnp: encoding resources
pnp: attempting to fix irq flags
pnp: setting resources
pnp: _SRS worked correctly
pnp: Device 00:07 activated.
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
pnp: building resource template
pnp: encoding resources
pnp: attempting to fix irq flags
pnp: setting resources
pnp: _SRS worked correctly
pnp: Device 00:08 activated.
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A

There are two questions still.

First of all, why disable the device on module unload?
If it was enabled initially, before any module has been
loaded, why it needs to be disabled, why not leave it
enabled and all, just like it has been before?

And this 8250 vs 8250_pnp (and 8250_pci etc, but
especially 8250_pnp as it is the most interesting one).
When loading 8250 alone (note that 8250_pnp depends
on 8250, so 8250 gets loaded first), it detects standard
serial port(s) just fine.  8250_pnp "redetects" them again
(see first `modprobe 8250_pnp' above: each ttySN line
gets repeated twice). But when unloading 8250_pnp, both
standard ttySNs are deactivated, even when 8250 is still
here.  More, when unloading both 8250_pnp and 8250, and
loading *only* 8250 after that, no standard ports gets
detected until 8250_pnp will be loaded (as the devices
are disabled, and 8250_pnp re-enables them).  Ie, this
whole stuff does not look right.  Probably a nitpicking,
but a bit.. strange.  Probably if 8250_pnp will stop
deactivating the devices (as per above), everything will
look ok here too.  Or, maybe it's a good idea to just
combine 8250 and 8250_pnp modules (and maybe 8250_serial
too), esp, since the latter is very small anyway ?

Thank you!

/mjt

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

[Russell King]

On Fri, Jun 10, 2005 at 01:07:49AM +0400, Michael Tokarev wrote:
> And this 8250 vs 8250_pnp (and 8250_pci etc, but
> especially 8250_pnp as it is the most interesting one).
> When loading 8250 alone (note that 8250_pnp depends
> on 8250, so 8250 gets loaded first), it detects standard
> serial port(s) just fine.  8250_pnp "redetects" them again
> (see first `modprobe 8250_pnp' above: each ttySN line
> gets repeated twice). But when unloading 8250_pnp, both
> standard ttySNs are deactivated, even when 8250 is still
> here.  More, when unloading both 8250_pnp and 8250, and
> loading *only* 8250 after that, no standard ports gets
> detected until 8250_pnp will be loaded (as the devices
> are disabled, and 8250_pnp re-enables them).  Ie, this
> whole stuff does not look right.  Probably a nitpicking,
> but a bit.. strange.  Probably if 8250_pnp will stop
> deactivating the devices (as per above), everything will
> look ok here too.  Or, maybe it's a good idea to just
> combine 8250 and 8250_pnp modules (and maybe 8250_serial
> too), esp, since the latter is very small anyway ?

The idea is that 8250 handles those serial ports.  8250_pnp, 8250_pci
and 8250_acorn etc are all probe modules which register with 8250,
know how the bus type works and tells 8250 where the ports are.

It's a cleaner design rather than stuffing multiple bus types into one
driver.

The reason that 8250 first detects your ports is that they're found
via the legacy method which is independent of PnP.  As you correctly
sumise, when you unload 8250_pnp, it disables the device so when you
re-load 8250, it's unable to detect your ports using the legacy method.

But the legacy method needs to continue to exist for systems which
don't have PnP enabled.

So, the above behaviour is completely expected and isn't a sign of
a deeper problem.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

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

[Bjorn Helgaas]

On Thursday 09 June 2005 3:16 pm, Russell King wrote:
> The reason that 8250 first detects your ports is that they're found
> via the legacy method which is independent of PnP.  As you correctly
> sumise, when you unload 8250_pnp, it disables the device so when you
> re-load 8250, it's unable to detect your ports using the legacy method.
> 
> But the legacy method needs to continue to exist for systems which
> don't have PnP enabled.

But shouldn't we someday move the legacy probing from 8250
into an 8250_platform and only do it if we don't have 8250_pnp?

I think David Woodhouse suggested something like this a while
back, but I can't find a great reference for it.  Here's a
thread (unfortunately split into sections by the archive)
that mentions it:

http://www.ussg.iu.edu/hypermail/linux/kernel/0409.3/1545.html
http://www.ussg.iu.edu/hypermail/linux/kernel/0410.0/0084.html
http://www.ussg.iu.edu/hypermail/linux/kernel/0411.0/0127.html

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

[Dmitry Torokhov]

On 6/10/05, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
> On Thursday 09 June 2005 3:16 pm, Russell King wrote:
> > The reason that 8250 first detects your ports is that they're found
> > via the legacy method which is independent of PnP.  As you correctly
> > sumise, when you unload 8250_pnp, it disables the device so when you
> > re-load 8250, it's unable to detect your ports using the legacy method.
> >
> > But the legacy method needs to continue to exist for systems which
> > don't have PnP enabled.
> 
> But shouldn't we someday move the legacy probing from 8250
> into an 8250_platform and only do it if we don't have 8250_pnp?
> 

Given how much pain PNP/ACPI probing of i8042 was causing to everyone
I'd be cautious. BIOS writers are extremely creative. Maybe ia64 only
while x86 should default to legacy probing.

-- 
Dmitry

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

[Bjorn Helgaas]

On Friday 10 June 2005 10:20 am, Dmitry Torokhov wrote:
> On 6/10/05, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
> > On Thursday 09 June 2005 3:16 pm, Russell King wrote:
> > > The reason that 8250 first detects your ports is that they're found
> > > via the legacy method which is independent of PnP.  As you correctly
> > > sumise, when you unload 8250_pnp, it disables the device so when you
> > > re-load 8250, it's unable to detect your ports using the legacy method.
> > >
> > > But the legacy method needs to continue to exist for systems which
> > > don't have PnP enabled.
> > 
> > But shouldn't we someday move the legacy probing from 8250
> > into an 8250_platform and only do it if we don't have 8250_pnp?
> 
> Given how much pain PNP/ACPI probing of i8042 was causing to everyone
> I'd be cautious. BIOS writers are extremely creative. Maybe ia64 only
> while x86 should default to legacy probing.

Yeah, probably so :-(

(ia64 already has no legacy 8250 probing.)

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

[Russell King]

On Fri, Jun 10, 2005 at 10:01:40AM -0600, Bjorn Helgaas wrote:
> On Thursday 09 June 2005 3:16 pm, Russell King wrote:
> > The reason that 8250 first detects your ports is that they're found
> > via the legacy method which is independent of PnP.  As you correctly
> > sumise, when you unload 8250_pnp, it disables the device so when you
> > re-load 8250, it's unable to detect your ports using the legacy method.
> > 
> > But the legacy method needs to continue to exist for systems which
> > don't have PnP enabled.
> 
> But shouldn't we someday move the legacy probing from 8250
> into an 8250_platform and only do it if we don't have 8250_pnp?

The structure's already there.  The biggest problem is the amount of
shere work there is to fix all the bloody architectures and drivers
which make use of random crap from asm/serial.h and friends.

I feel very much like I'm working on serial all by myself, especially
when asking arch people to do things results in silence.

So shrug - I've put in the ground work.  ARM's up to date in so much
as it doesn't use asm/serial.h at all anymore.  The other architectures
now need to follow suit.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

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

[Adam Belay]

On Fri, Jun 10, 2005 at 01:07:49AM +0400, Michael Tokarev wrote:

> 
> First of all, why disable the device on module unload?
> If it was enabled initially, before any module has been
> loaded, why it needs to be disabled, why not leave it
> enabled and all, just like it has been before?

The original idea here was to free up resources for allocation
to other devices.  The ACPI spec claims we should call _DIS
when powering down the device to _D3.  So, I'm considering not
disabling the device when the driver is unbound, especially with
PNPACPI.  I need to think about it more.

Thanks,
Adam

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

[Michael Tokarev]

I noticied that parport_pc and 8250[_pnp] modules
can't be re-loaded without rebooting when PNP is
turned on in kernel config.  Here's how it looks
like:

[boot]
May 26 07:58:41 linux kernel: pnp: PnP ACPI init
May 26 07:58:41 linux kernel: pnp: PnP ACPI: found 15 devices
May 26 07:58:41 linux kernel: pnp: 00:09: ioport range 0x680-0x6ff has been reserved
May 26 07:58:41 linux kernel: pnp: 00:0d: ioport range 0x400-0x47f could not be reserved
May 26 07:58:41 linux kernel: pnp: 00:0d: ioport range 0x680-0x6ff has been reserved
May 26 07:58:41 linux kernel: pnp: 00:0d: ioport range 0x500-0x53f has been reserved
May 26 07:58:41 linux kernel: pnp: 00:0d: ioport range 0x500-0x53f has been reserved
May 26 07:58:41 linux kernel: pnp: 00:0d: ioport range 0x400-0x47f could not be reserved
May 26 07:58:41 linux kernel: pnp: 00:0d: ioport range 0x295-0x296 has been reserved
May 26 07:58:41 linux kernel: pnp: 00:0d: ioport range 0x3e0-0x3e7 has been reserved
May 26 07:58:41 linux kernel: isapnp: Scanning for PnP cards...
May 26 07:58:41 linux kernel: isapnp: No Plug & Play device found

[modprobe parport_pc]
May 26 07:58:44 linux kernel: parport: PnPBIOS parport detected.
May 26 07:58:44 linux kernel: parport0: PC-style at 0x378, irq 7 [PCSPP]
May 26 07:58:44 linux kernel: lp0: using parport0 (interrupt-driven).

[rmmood parport_pc]
Jun  1 02:45:38 linux kernel: pnp: Device 00:08 disabled.

[modprobe parport_pc]
Jun  1 02:45:46 linux kernel: pnp: Device 00:08 activated.
Jun  1 02:45:46 linux kernel: parport: PnPBIOS parport detected.
Jun  1 02:45:46 linux kernel: pnp: Device 00:08 disabled.

[rmmod parport_pc]
Jun  1 02:45:56 linux kernel: lp: driver loaded but no devices found

[modprobe parport_pc io=0x378 irq=7]
Jun  1 02:46:31 linux kernel: parport 0x378 (WARNING): CTR: wrote 0x0c, read 0xff
Jun  1 02:46:31 linux kernel: parport 0x378 (WARNING): DATA: wrote 0xaa, read 0xff
Jun  1 02:46:31 linux kernel: parport 0x378: You gave this address, but there is probably no parallel port there!
Jun  1 02:46:31 linux kernel: parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
Jun  1 02:46:31 linux kernel: lp0: using parport0 (interrupt-driven).

Ie, for some reason, on second module loading, the device
isn't being enabled or something like that, maybe after
first "pnp: Device 00:08 disabled.".  The only way to cure
the problem is to reboot the machine.  The same is true for
8250[_pnp] module aswell, with very similar effects.

Is it just me, or is it some known issue?

And maybe somewhat related issue..  When playing with this stuff on
another machine, I got kernel OOPS on first rmmod of parport_pc:

parport_pc: VIA 686A/8231 detected
parport_pc: probing current configuration
parport_pc: Current parallel port base: 0x378
parport0: PC-style at 0x378 (0x778), irq 7, using FIFO [PCSPP,TRISTATE,COMPAT,ECP]
parport_pc: VIA parallel port: io=0x378, irq=7
Unable to handle kernel NULL pointer dereference at virtual address 00000000
  printing eip:
d027b7cf
*pde = 00000000
Oops: 0000 [#1]
Modules linked in: parport_pc parport 8139too mii crc32 ppp_deflate zlib_deflate zlib_inflate bsd_comp
ppp_async crc_ccitt md5 ipv6 supermount dm_mod sd_mod evdev tuner saa7134 video_buf v4l2_common
v4l1_compat i2c_core ir_common videodev button rtc mousedev 8250_pnp 8250 serial_core usbhid psmouse
ide_cd cdrom ppp_generic slhc usb_storage scsi_mod uhci_hcd usbcore snd_via82xx snd_ac97_codec
snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device
snd soundcore floppy ext3 jbd mbcache ide_disk via82cxxx ide_core
CPU:    0
EIP:    0060:[<d027b7cf>]    Not tainted VLI
EFLAGS: 00010286   (2.6.11-c3-6)
EIP is at parport_pc_pci_remove+0xf/0x40 [parport_pc]
eax: cf74f044   ebx: cf74f000   ecx: d0280634   edx: d027b7c0
esi: 00000000   edi: d02805e8   ebp: c5c16000   esp: c5c16f20
ds: 007b   es: 007b   ss: 0068
Process rmmod (pid: 3347, threadinfo=c5c16000 task=c4e7f5a0)
Stack: cf74f000 cf74f044 c018a324 cf74f068 c01cc8a4 d0280634 d0280634 00000000
        c01cc8c8 d02805e8 d0280780 c01ccca4 d02805e8 d0280780 c01cd178 d02805c0
        c018a4db c5c16000 d027bbdc c01290ba 00000000 70726170 5f74726f 00006370
Call Trace:
  [<c018a324>] pci_device_remove+0x34/0x40
  [<c01cc8a4>] device_release_driver+0x64/0x70
  [<c01cc8c8>] driver_detach+0x18/0x30
  [<c01ccca4>] bus_remove_driver+0x34/0x70
  [<c01cd178>] driver_unregister+0x8/0x20
  [<c018a4db>] pci_unregister_driver+0xb/0x20
  [<d027bbdc>] parport_pc_exit+0x5c/0x5e [parport_pc]
  [<c01290ba>] sys_delete_module+0x12a/0x160
  [<c013e9fa>] unmap_vma_list+0x1a/0x30
  [<c013eced>] do_munmap+0xcd/0x100
  [<c013ed55>] sys_munmap+0x35/0x50
  [<c0102d27>] syscall_call+0x7/0xb
Code: ff ff ff 89 e8 ff d6 85 c0 0f 84 88 fe ff ff eb a6 8d 74 26 00 8d bc 27 00 00 00 00 56 53 83 c0 44 8b 70 74 c7 40 74 00 00 00 00 <8b> 1e 4b 78 18 8d b6 00 00 00 00 8d bf 00 00 00 00 8b 44 9e 04

Thanks.

/mjt

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

[Andrew Morton]

Michael Tokarev <mjt@tls.msk.ru> wrote:
>
> I noticied that parport_pc and 8250[_pnp] modules
>  can't be re-loaded without rebooting when PNP is
>  turned on in kernel config.  Here's how it looks
>  like:

Please test 2.6.12-rc5

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

[Michael Tokarev]

Andrew Morton wrote:
> Michael Tokarev <mjt@tls.msk.ru> wrote:
> 
>>I noticied that parport_pc and 8250[_pnp] modules
>> can't be re-loaded without rebooting when PNP is
>> turned on in kernel config.  Here's how it looks
>> like:
> 
> Please test 2.6.12-rc5

Just did so.  The OOPS (NULL pointer dereference) when unloading
parport_pc on VIA-based mobo is now gone, but re-enabling PNP
device on E7501-based machine still does not work, with the same
effect.  Here's the dmesg output when {ins,rm}moding the parport_pc
module:

[modprobe parport_pc]
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378, irq 7 [PCSPP]

[rmmod parport_pc]
pnp: Device 00:07 disabled.

[modprobe parport_pc]
pnp: Device 00:07 activated.
parport: PnPBIOS parport detected.
pnp: Device 00:07 disabled.
[no parport is detected]

The same is with 8250_pnp:

[modprobe 8250_pnp (also loads 8250)]
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing enabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A

[rmmod 8250_pnp 8250]
pnp: Device 00:06 disabled.

[modprobe 8250]
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing enabled
pnp: Device 00:06 activated.
[note no ttyS0 is detected this time]

And here's complete (modulo various scsi and softraid stuff which isn't
relevant) dmesg before the above.

Is it worth the effort to try to compile w/o PNP support?
If memory serves me right, it worked w/o PNP, but eg for
parport, not all parameters (most notable IRQ) where
detected.

Thanks.

/mjt

Linux version 2.6.12-i786smp-rc5-0 (mjt@paltus.tls.msk.ru) (gcc version 3.3.5 (Debian 1:3.3.5-12)) #1 SMP Wed Jun 1 18:55:42 MSD 2005
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000007fff0000 (usable)
 BIOS-e820: 000000007fff0000 - 000000007ffff000 (ACPI data)
 BIOS-e820: 000000007ffff000 - 0000000080000000 (ACPI NVS)
 BIOS-e820: 00000000fec00000 - 00000000fed00000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ffb80000 - 0000000100000000 (reserved)
1151MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 000ff780
On node 0 totalpages: 524272
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 225280 pages, LIFO batch:31
  HighMem zone: 294896 pages, LIFO batch:31
DMI 2.3 present.
ACPI: RSDP (v000 ACPIAM                                ) @ 0x000f4fa0
ACPI: RSDT (v001 A M I  OEMRSDT  0x08000311 MSFT 0x00000097) @ 0x7fff0000
ACPI: FADT (v002 A M I  OEMFACP  0x08000311 MSFT 0x00000097) @ 0x7fff0200
ACPI: MADT (v001 A M I  OEMAPIC  0x08000311 MSFT 0x00000097) @ 0x7fff0300
ACPI: OEMB (v001 A M I  OEMBIOS  0x08000311 MSFT 0x00000097) @ 0x7ffff040
ACPI: DSDT (v001  0ABBP 0ABBP001 0x00000001 MSFT 0x0100000d) @ 0x00000000
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:2 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x06] enabled)
Processor #6 15:2 APIC version 20
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] enabled)
Processor #1 15:2 APIC version 20
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x07] enabled)
Processor #7 15:2 APIC version 20
ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
ACPI: IOAPIC (id[0x09] address[0xfec80000] gsi_base[24])
IOAPIC[1]: apic_id 9, version 32, address 0xfec80000, GSI 24-47
ACPI: IOAPIC (id[0x0a] address[0xfec80400] gsi_base[48])
IOAPIC[2]: apic_id 10, version 32, address 0xfec80400, GSI 48-71
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 3 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 80000000 (gap: 80000000:7ec00000)
Built 1 zonelists
Kernel command line: auto BOOT_IMAGE=2.6.12-rc5-0 ro root=100 panic=60 elevator=deadline
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
mapped IOAPIC to ffffb000 (fec80000)
mapped IOAPIC to ffffa000 (fec80400)
Initializing CPU#0
CPU 0 irqstacks, hard=c0342000 soft=c033e000
PID hash table entries: 4096 (order: 12, 65536 bytes)
Detected 2400.110 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 2075412k/2097088k available (1377k kernel code, 20532k reserved, 702k data, 188k init, 1179584k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 4734.97 BogoMIPS (lpj=2367488)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000 00004400 00000000 00000000
CPU: After vendor identify, caps: bfebfbff 00000000 00000000 00000000 00004400 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
CPU: After all inits, caps: bfebfbff 00000000 00000000 00000080 00004400 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU0: Thermal monitoring enabled
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
CPU0: Intel(R) Xeon(TM) CPU 2.40GHz stepping 09
Booting processor 1/1 eip 3000
CPU 1 irqstacks, hard=c0343000 soft=c033f000
Initializing CPU#1
Calibrating delay loop... 4784.12 BogoMIPS (lpj=2392064)
CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000 00004400 00000000 00000000
CPU: After vendor identify, caps: bfebfbff 00000000 00000000 00000000 00004400 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
CPU: After all inits, caps: bfebfbff 00000000 00000000 00000080 00004400 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel P4/Xeon Extended MCE MSRs (12) available
CPU1: Thermal monitoring enabled
CPU1: Intel(R) Xeon(TM) CPU 2.40GHz stepping 09
Booting processor 2/6 eip 3000
CPU 2 irqstacks, hard=c0344000 soft=c0340000
Initializing CPU#2
Calibrating delay loop... 4784.12 BogoMIPS (lpj=2392064)
CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000 00004400 00000000 00000000
CPU: After vendor identify, caps: bfebfbff 00000000 00000000 00000000 00004400 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 3
CPU: After all inits, caps: bfebfbff 00000000 00000000 00000080 00004400 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#2.
CPU2: Intel P4/Xeon Extended MCE MSRs (12) available
CPU2: Thermal monitoring enabled
CPU2: Intel(R) Xeon(TM) CPU 2.40GHz stepping 09
Booting processor 3/7 eip 3000
CPU 3 irqstacks, hard=c0345000 soft=c0341000
Initializing CPU#3
Calibrating delay loop... 4784.12 BogoMIPS (lpj=2392064)
CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000 00004400 00000000 00000000
CPU: After vendor identify, caps: bfebfbff 00000000 00000000 00000000 00004400 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 3
CPU: After all inits, caps: bfebfbff 00000000 00000000 00000080 00004400 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#3.
CPU3: Intel P4/Xeon Extended MCE MSRs (12) available
CPU3: Thermal monitoring enabled
CPU3: Intel(R) Xeon(TM) CPU 2.40GHz stepping 09
Total of 4 processors activated (19087.36 BogoMIPS).
ENABLING IO-APIC IRQs
...TIMER: vector=0x31 pin1=2 pin2=-1
checking TSC synchronization across 4 CPUs: passed.
Brought up 4 CPUs
CPU0 attaching sched-domain:
 domain 0: span 3
  groups: 1 2
  domain 1: span f
   groups: 3 c
CPU1 attaching sched-domain:
 domain 0: span 3
  groups: 2 1
  domain 1: span f
   groups: 3 c
CPU2 attaching sched-domain:
 domain 0: span c
  groups: 4 8
  domain 1: span f
   groups: c 3
CPU3 attaching sched-domain:
 domain 0: span c
  groups: 8 4
  domain 1: span f
   groups: c 3
checking if image is initramfs... it is
Freeing initrd memory: 599k freed
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xf0031, last bus=4
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20050309
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
Boot video device is 0000:01:02.0
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P2.P2P3._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P2.P2P4._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 14 devices
PnPBIOS: Disabled by ACPI PNP
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
TC classifier action (bugs to netdev@oss.sgi.com cc hadi@cyberus.ca)
pnp: 00:08: ioport range 0x680-0x6ff has been reserved
pnp: 00:0c: ioport range 0x400-0x47f could not be reserved
pnp: 00:0c: ioport range 0x680-0x6ff has been reserved
pnp: 00:0c: ioport range 0x500-0x53f has been reserved
pnp: 00:0c: ioport range 0x500-0x53f has been reserved
pnp: 00:0c: ioport range 0x400-0x47f could not be reserved
pnp: 00:0c: ioport range 0x295-0x296 has been reserved
pnp: 00:0c: ioport range 0x3e0-0x3e7 has been reserved
Machine check exception polling timer started.
highmem bounce pool size: 64 pages
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Initializing Cryptographic API
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
PNP: PS/2 Controller [PNP0303:PS2K,PNP0f03:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered (default)
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
input: PC Speaker
NET: Registered protocol family 2
IP: routing cache hash table of 16384 buckets, 128Kbytes
TCP established hash table entries: 524288 (order: 10, 4194304 bytes)
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 524288 bind 65536)
NET: Registered protocol family 1
NET: Registered protocol family 17
Starting balanced_irq
ACPI wakeup devices:
PS2K PS2M SMBS USB0 USB1 USB2 P0P1 P0P2 P2P3 P2P4 GNIC PWRB
ACPI: (supports S0 S1 S5)
Freeing unused kernel memory: 188k freed
SCSI subsystem initialized
ACPI: PCI Interrupt 0000:04:04.0[A] -> GSI 50 (level, low) -> IRQ 169
ACPI: PCI Interrupt 0000:04:04.1[B] -> GSI 51 (level, low) -> IRQ 177
scsi0 : Adaptec AIC79XX PCI-X SCSI HBA DRIVER, Rev 1.3.11
        <Adaptec AIC7902 Ultra320 SCSI adapter>
        aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 50-66Mhz, 512 SCBs

(scsi0:A:0): 320.000MB/s transfers (160.000MHz DT|IU|QAS, 16bit)
[...]
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
EXT3 FS on md1, internal journal
Real Time Clock Driver v1.12
Intel(R) PRO/1000 Network Driver - version 5.7.6-k2
Copyright (c) 1999-2004 Intel Corporation.
ACPI: PCI Interrupt 0000:04:01.0[A] -> GSI 48 (level, low) -> IRQ 185
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH3: IDE controller at PCI slot 0000:00:1f.1
PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 193
ICH3: chipset revision 2
ICH3: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:pio, hdb:pio
    ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
Probing IDE interface ide1...
e1000: eth0: e1000_watchdog_task: NIC Link is Up 100 Mbps Full Duplex
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).