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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
