Re: pnp bug in 2.6.27-rc1 (ad1816a / mpu401 / parport_pc issue)
Am Wednesday 13 August 2008 18:54:05 schrieben Sie:
> On Wednesday 13 August 2008 09:47:04 am Uwe Bugla wrote:
> > Am Tuesday 12 August 2008 23:26:12 schrieben Sie:
> > > On Tuesday 12 August 2008 12:10:51 pm Bjorn Helgaas wrote:
> > > > On Tuesday 12 August 2008 05:17:26 am Uwe Bugla wrote:
> > > > > Case C:
> > > > > same preconditions as case B, but additionally:
> > > > > 1. no IRQs reserved for ISA use only (in BIOS)
> > > > > This option I would call "PNP pure"
> > > > >
> > > > > ...
> > > > > My only criticism within the desired case C (no additional screwing
> > > > > around done by user)
> > > > > consists of two points:
> > > > > 1. I'd prefer the second parport running with IRQ 5 instead of in
> > > > > polling mode.
> > > >
> > > > Yes, that would be good. But I think the only way to achieve this
> > > > reliably is to use the "pnp_reserve_irq=5" kernel parameter and the
> > > > "options parport_pc io=0x278 irq=5" module parameter.
Hi Bjorn,
> I see several things that should be fixed in ISAPNP. I'm working
> on those, but they're probably post-2.6.27 material.
OK.
>
> In the meantime, are you seeing new problems that were introduced
> between 2.6.26 and 2.6.27-rc3? If so, I should try to fix them
> right away so we can get a fix in 2.6.27.
In fact I found no new regressions, which is good.
>
> Your original report of "WARNING: at lib/vsprintf.c:609
> vsnprintf+0x36/0x43d()" has been fixed already.
Yes. Well done, Bjorn! :)
> I *think* the remaining issues about the
> parport1 IRQ and the MPU401 are related to the BIOS configuration
> and the parport_pc module parameters and are not regressions from
> 2.6.26, but please correct me if I'm wrong.
One can for sure regard that all as BIOS-related.
With one exception: The parport1 issue is resolved at least for me:
Adding "options parport_pc io=0x378,0x278 irq=7,5" to etc/modprobe.d/arch/i386
solves the problem without the necessity of freeing up an IRQ in the BIOS for
that second parport which is a non-PnP ISA card.
IT IS comprehensive that a Non-PnP card needs additional kernel parameters.
What IS NOT comprehensive is the fact that currently I need to free up IRQ 10
for ISA use only to ensure that snd-ad1816a is being loaded. And that card is
definitely a PnP sound card!
I'd be very happy about a solution that completely avoids BIOS intervention...
And there is still the issue how to get rid of those nasty MPU 401 messages.
What is a comprehensive message that shows that this device has been loaded
and registered, although it resides in an interruptless state?
>
> Thanks for your patience with all this. I'm putting together an ISA
> machine at home now, so hopefully I'll soon have a way to test this
> better without wasting your time.
Patience does not belong to my strengths - lack of patience is the main reason
why I was excluded from lkml.org.
On the other hand you never wasted my time at all - the opposite is right:
It's a pleasure to work with you, Bjorn! :)
>
> Bjorn
Regards and thanks
Uwe
Reply to: