Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP
id AA564 ; Fri, 05 Feb 93 02:01:20 EST
Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!agate!doc.ic.ac.uk!warwick!uknet!cf-cm!myrddin.isl.cf.ac.uk!paul
From: paul@isl.cf.ac.uk (Paul)
Newsgroups: comp.unix.bsd
Subject: Re: [386BSD] kernel on fixit-0.2 and Maxtor
Keywords: n
Message-ID: <1993Feb3.160736.26695@cm.cf.ac.uk>
Date: 3 Feb 93 16:07:35 GMT
References: <9301311808.AA00866@clio.iqm.unicamp.br> <1993Feb2.021606.25706@coe.montana.edu>
Sender: news@cm.cf.ac.uk (Network News System)
Organization: Intelligent Systems Lab, ELSYM, Universiity of Wales, College of
Cardiff.
Lines: 45
In article <1993Feb2.021606.25706@coe.montana.edu> osynw@gemini.oscs.montana.edu (Nate Williams) writes:
>In article <9301311808.AA00866@clio.iqm.unicamp.br> vazquez@iqm.unicamp.br (Pedro A.M. Vazquez) writes:
>>Hello:
>>
>> When a boot my system from fixit-0.2 from agate I receive the message:
>>
>>wd0:<Maxtor 7213AT> 1:<wdgetctlr failed, assuming 0K> at 0x1f0 irq 14 on isa.
>>
>> The same ocurrs with patchkit-0.2 kernels
>
>This is because of some non-standard (?) controllers. I had hoped that
>I had fixed most of the bugs in the wd driver, but alas it appears not.
I get this message too. So far I've ignored it with no adverse affects. I
suspect the probe routine doesn't recognise the controller because it's
non-standard but it works ok anyway. I haven't actually looked at the
code to check.
At the moment I'm still trying to work out why everything gets
SIGBUS and SIGSEGV traps on my machine.
Is anyone else suffering from this problem. It's impossible to rebuild
my source tree with gcc-2.3.3 because after a few minutes the compiler
dies from a trap and it takes a reboot to fix it.
HELP!
If I reboot, the file that originally caused the trap will happily
compile and then a little later some other file will trigger a trap.
This is driving me mad. I've re-compiled the compiler, got new binaries
from ref etc. I don't think it is the compiler because occasionally
it will be make or sh or tcsh that exhibits this erratic behaviour.
I started using gdb on the 1.39 compiler (since I had source to add the
debug option) and it seems to die in do_spec1. Any ideas??
I'd like to hear from people who either do have this problem or
for that matter dont' so at least I know it's a problem of my own.
--
Paul Richards, University of Wales, College Cardiff
JANET:paul@uk.ac.cf.isl Internet:paul@isl.cf.ac.uk
UUCP: paul@cf-isl.UUCP or ...!uunet!mcsun!uknet!cf!isl!paul