I'm not so sure... I looked over the code just now, and did not see any
MMIO being performed, just PIO. MMIO is where the warnings come from.
BTW, you might consider doing a search for current->state and replacing
the code around that with __set_current_state...
Does anybody know where the kernel log buffer size is kept? We can
artificially boost that value, to then find out what driver is causing
the original poster's kernel to spew warnings.
> > Since it was the last line in his included 'dmesg' output, I am guessing
> > that lp is being loaded as a module. When I do a 'modprobe lp' on my
> > system, parport*.o are not pulled in as dependencies.
>
> At least 'parport' should, or else you'd get unresolved symbols. It's
> true that parport_pc won't necessarily get pulled in though.
>
> Due to the parport_register_driver mechanism, parport_enumerate (to step
> through the list of ports) isn't really required any more. I've left it
> in for compatibility, and also left the parport_lowlevel business in for
> now.
>
> The idea is that /etc/modules.conf has a post-install for parport to pull
> in the low-level driver. This should be in Documentation/parport.txt if
> it isn't already.
Yeah, the problem can probably be attributed to my slackness here...
> > modprobe parport_pc
> > modprobe lp
> >
> > as the last line of my RH6.0 /etc/rc.d/init.d/rc.local, it fails. But
>
> In what way does it fail?
Putting the delay into rc.local fixed things. I never caught the exact
message so I couldn't get an exact diagnosis. I'm guessing modprobe is
asynchronous.
-- Jeff Garzik | Just once, I wish we would encounter Building 1024 | an alien menace that wasn't immune to MandrakeSoft, Inc. | bullets. -- The Brigadier, "Dr. Who"- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/