Date: Mon, 23 Jan 1995 08:03:37 -0600 (CST) From: Robert Michael Gorichanaz <wraith@csd.uwm.edu> To: wpaul@skynet.ctr.columbia.edu (Wankle Rotary Engine) Cc: questions@FreeBSD.org Subject: Re: Is this a bug?!? Message-ID: <199501231403.IAA11022@alpha2.csd.uwm.edu> In-Reply-To: <199501230653.BAA02642@skynet.ctr.columbia.edu> from "Wankle Rotary Engine" at Jan 23, 95 01:53:04 am
next in thread | previous in thread | raw e-mail | index | archive | help
>They say this Robert Michael Gorichanaz person was kidding when he wrote:
>>
>> I seem to have stumbled upon a bug (?!?) in FreeBSD
>
>What version?!?!?!
Both 1.1.5.1r and 2.0-950112-SNAP
>
>> - or maybe its a
>> hardware thing - dunno.
>>
>> I just finished upgrading one of my 'bsd boxes from a dx2-50 ISA to a dx2-66
>> VLB motherboard. Problems:
>>
>> I now seem to be unable to issue a Ctrl-Alt-Del (system
>> just beeps at me each time I hit the combo).
>>
>> 'shutdown' results in a kernel panic:
>>
>> panic: b_to_q to a clist with no reserved cblocks
>
[...]
>>
>> MoBo functions just fine under a DOS/Windows environment (ctrl-alt-del
>> works).
>
>Rrrrr... please don't say this. In reality, nothing functions just fine
>in a DOS/Windoze environment. If it did, you wouldn't be running FreeBSD.
True, but I meant to say that a software/hardware reset works under DOS.
>> Cards: Soundblaster 16
>> Buslogic BT-545 16bit busmaster SCSI
>> 'No-name' VLB IDE controller
>> Trident 9400CXI VLB video 1MB
>>
>> This is the only panic I have experienced. While this isnt a HUGE problem,
>> I really need to be able to reboot this machine remotely (have an autodial
>> script to start a point-to-point link w/outside world).
>>
>> Has anyone had similar problems with VLB boards? Do I have a piece of sh*t
>> MoBo?
>
>There may be a hardware problem involved, but I'm not sure how closely
>related it is to this panic. From what I've read, FreeBSD uses something
>of a brute force approach to reset the CPU (it actually causes the CPU
>to triple fault, which shuts it down). But that doesn't happen until
>*after* the panic: I can underatand your hardware objecting to the
>brute force CPU reset, but that doesn't account for the panic since
>that happens before cpu_reset() is called.
Hmm.. I checked out the cpu_reset code. It invalidates the entire address
space, thus forcing the CPU to crash and reset itself.
Is there any other less-brutal way to reset the CPU?
Its odd that this worked just fine with a straight ISA mobo, but the VLB
board I have locks up...
>If you're feeling really adventurous you can generate a crash
>dump and try to trace through it to see exactly what the kernel does
>that leads up to the panic. This is a little tricky, but it's the
>best way to isolate the problem.
>
>-Bill
>
>--
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~T~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>-Bill Paul (212) 854-6020 | System Manager
>Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research
>Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>The Møøse Illuminati: ignore it and be confused, or join it and be confusing!
>~~~~~~~~ FreeBSD 2.1.0-Development #1: Fri Jan 20 14:28:17 EST 1995 ~~~~~~~~~
>
--
/ /| \ O For all you ORIGIN needs,
| \`o.O' | Ack! Thptptptpt! -+- the Avatar is IN.
| =(___)= | |
\ U / wraith@alpha2.csd.uwm.edu Games, hardware, and comments.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199501231403.IAA11022>