Skip site navigation (1)Skip section navigation (2)
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>