> I would like to see full dump of 'vidcontrol -i adapter',
> 'vidcontrol -i mode' and dmesg after the vesa module is loaded
> (you get very verbose output from the vesa module init code
> if you boot the kernel with 'boot -v').
I think this is what you asked for, otherwise please let me know.
B
>Andrea Campi <[EMAIL PROTECTED]> writes:
>> Ok, I will try each one. At the moment, I'm using logo_saver.
>> I will let you know.
>
>Take a long hard look at vesa_set_mode() and vesa_set_origin() in
>sys/i386/isa/vesa.c. If the panic occurs while the console is still in
>text mode, the bug is in
Andrea Campi <[EMAIL PROTECTED]> writes:
> Ok, I will try each one. At the moment, I'm using logo_saver.
> I will let you know.
Take a long hard look at vesa_set_mode() and vesa_set_origin() in
sys/i386/isa/vesa.c. If the panic occurs while the console is still in
text mode, the bug is in vesa_se
Sorry, I guess I should specify that this is a desktop with APM enabled in
the BIOS, but not being used otherwise... VESA module loaded.
#uname -a
FreeBSD cae88-102-101.sc.rr.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sat Dec 2
16:07:54 EST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/RHIANNON
Just as a data point, I just tried this as well... The daemon saver was ok,
the fire saver was ok, but as soon as I loaded logo_saver and it activated,
I got a 'dc0 timeout'(?) and I was unable to access any of the vtys after
that... I could switch vtys, but could not type anything.
The fire_sa
On 05-Dec-00 Andrea Campi wrote:
>> > More details: this is an IBM Thinkpad laptop with APM enabled and in the
>> > kernel.
>> > As usual, any hint is more than welcome. This used to work...
>>
>> Which screen saver? Does it do it with all of them? Just graphical ones,
>> just
>> text ones, ju
> > More details: this is an IBM Thinkpad laptop with APM enabled and in the
> > kernel.
> > As usual, any hint is more than welcome. This used to work...
>
> Which screen saver? Does it do it with all of them? Just graphical ones, just
> text ones, just green_saver, etc.?
Rrrright... I can as
On 05-Dec-00 Andrea Campi wrote:
>> >
>> > db> x/i,10 0xc025ad3c
>> > scrn_timer: pushl %ebp
>> > [...]
>> >
>> > nm just confirmed this, so it definitely looks like scrn_timer is to blame
>> > here. Any other instructions? ;-) For the time being, vidcontrol -t off
>> > (seems to) keep the
> >
> > db> x/i,10 0xc025ad3c
> > scrn_timer: pushl %ebp
> > [...]
> >
> > nm just confirmed this, so it definitely looks like scrn_timer is to blame
> > here. Any other instructions? ;-) For the time being, vidcontrol -t off
> > (seems to) keep the machine up.
> >
> > Bye,
> > Andrea
> > Bad callout handler: c_func = 0xc025ad3c, c_arg=0xc0338460, c_flags=7
> >
> > First I tried a
> >
> > db> x/i,10 0xc025ad3c
> > scrn_timer: pushl %ebp
> > [...]
> >
> > nm just confirmed this, so it definitely looks like scrn_timer is to blame
> > here. Any other instructions? ;-) For t
On 29-Nov-00 Andrea Campi wrote:
>> Then when it panics write down the values that get printed out. Next,
>> do 'nm /sys/compile/MYKERNEL/kernel.debug | sort' and look for the function
>> whose address matches the c_func address printed out, then send this info
>> back
>> please. :)
>
> This ti
> Then when it panics write down the values that get printed out. Next,
> do 'nm /sys/compile/MYKERNEL/kernel.debug | sort' and look for the function
> whose address matches the c_func address printed out, then send this info back
> please. :)
This time it took me 1 hour to get the panic, compar
On 29-Nov-00 Andrea Campi wrote:
>>
>> We want mtxd_file and mtxd_line. If you look at the output of the last
>> command, it will probably look something like this:
>
> ../../kern/kern_timeout.c, line 139
Hmm, and the failed assertion was:
panic: mutex Giant owned at ../../kern/kern_intr.c:2
>
> We want mtxd_file and mtxd_line. If you look at the output of the last
> command, it will probably look something like this:
../../kern/kern_timeout.c, line 139
Hope it helps,
Andrea
--
Andrea Campi mailto:[EMAIL PROTECTED]
I.NET S.p.A.
14 matches
Mail list logo
