>From the keyboard of Hellmuth Michaelis:
> I'm currently re-cvsupping/recompiling a completly fresh tree to reproduce
> this to make shure it is really this single printf.
Its reproducible. Different machine/location/hardware, cvsupped 3 hr's
ago, rm /usr/src, /usr/obj, make world, make kernel.
>From the keyboard of Steve O'Hara-Smith:
> On 13-Jul-00 Hellmuth Michaelis wrote:
> > I'm now completely out of ideas
>
> Try and pin down which printf really makes a difference ?
Ok, did that. Surprise: i removed all the debugging code and all changes
i made to track down what hap
>From the keyboard of John Polstra:
> > i added a printf statement to the beginning of every subroutine in
> > file /sys/dev/kbd/kbd.c and with this additions the panic disappears
> > and pcvt runs fine as ever.
> >
> > Removing the printf's from kbd.c shows the usual described panic.
> >
> >
In article <[EMAIL PROTECTED]>,
Hellmuth Michaelis <[EMAIL PROTECTED]> wrote:
>
> i added a printf statement to the beginning of every subroutine in
> file /sys/dev/kbd/kbd.c and with this additions the panic disappears
> and pcvt runs fine as ever.
>
> Removing the printf's from kbd.c shows th
On 13-Jul-00 Hellmuth Michaelis wrote:
> I'm now completely out of ideas
Try and pin down which printf really makes a difference ?
I recall a long time ago a bit of code that had calls to a function
that did nothing, the comment was that it prevented an MSC optimiser bug fr
Just for the record:
i added a printf statement to the beginning of every subroutine in
file /sys/dev/kbd/kbd.c and with this additions the panic disappears
and pcvt runs fine as ever.
Removing the printf's from kbd.c shows the usual described panic.
I'm now completely out of ideas
hell
>From the keyboard of Daniel C. Sobral:
> Hellmuth Michaelis wrote:
> >
> > Thanks for the reply - it seems indeed to be a strange problem. In the mean-
> > time i found out that the pcvt probe routine was never called until i added
> > something like DEVMETHOD(device_identify, pcvt_identify) to
Hellmuth Michaelis wrote:
>
> Thanks for the reply - it seems indeed to be a strange problem. In the mean-
> time i found out that the pcvt probe routine was never called until i added
> something like DEVMETHOD(device_identify, pcvt_identify) to the device
> methods structure.
It didn't? Please
>From the keyboard of Daniel C. Sobral:
> > After the latest config/hints changes, just commenting the syscons driver
> > "sc" line and uncommenting the pcvt "vt" line in the GENERIC kernel config
> > file, a booting kernel panics after the the message "atkbdc0: > controller (i8042)> .." with a
Hellmuth Michaelis wrote:
>
> After the latest config/hints changes, just commenting the syscons driver
> "sc" line and uncommenting the pcvt "vt" line in the GENERIC kernel config
> file, a booting kernel panics after the the message "atkbdc0: controller (i8042)> .." with a fatal trap 12, page
After the latest config/hints changes, just commenting the syscons driver
"sc" line and uncommenting the pcvt "vt" line in the GENERIC kernel config
file, a booting kernel panics after the the message "atkbdc0: .." with a fatal trap 12, page fault while in kernel mode.
This is reliably reproduc
11 matches
Mail list logo
