Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!ucsd!ucsdhub!esosun!seismo!uunet!l5comp!scotty From: scotty@l5comp.UUCP (Scott Turner) Newsgroups: comp.unix.microport Subject: Re: SysV/386: db module not cofigured ??? Summary: Easy answer to this Keywords: Not a bug Message-ID: <431@l5comp.UUCP> Date: 21 Sep 88 13:12:40 GMT References: <26061@ucbvax.BERKELEY.EDU> <835@obdient.UUCP> Reply-To: scotty@l5comp.UUCP (Scott Turner) Organization: L5 Computing, Edmonds, WA Lines: 44 In article <835@obdient.UUCP> blair@obdient.UUCP (Doug Blair) writes: >In article <26061@ucbvax.BERKELEY.EDU>, carvalho@ernie.Berkeley.EDU (Marcio de Carvalho) writes: >> >> At some apparently random accasions, my Everex 386/20 >> running uport's V/386 version 2.2 enters in a loop and fills >> screens and more screens with: >> >> *** Attention: attempting to run DEBUGGER with no db module configured >> >> And the only way I found to get out of this is to turn >> the machine OFF and reboot it. > >I suspect we may have a bug related to the AT buss's inability to >have two boards with the same IRQ even throught the devices >don't have the same port address. This isn't a bug, they just don't ship the product with a kernel debugger installed. Of course what I don't understand is why the damn thing attempts to enter the debugger when it KNOWS it ain't got one. :) I think they should supply a dummy kernel debugger that comes up and says: "Sorry to bother you, but I'm feeling a little unwell right now. So I'm going to take a nice long nap." Lord knows the damn fsck is probably going to munch yer hard drive when you reboot so you better take a nap as well so you can deal with the stress. "Oh God, tell me it isn't removing /bin/sh again!" Why does the system double panic? Right now my system double panics whenever I try to write to the floppy drive. (I'm SERIOUS folks) Something about a user mode interrupt 0x2... Weird. I'm hoping that installing the system one more time will clear that up. The AT buss can deal with two boards using the same IRQ. The problem is that the IRQ service routine must check BOTH devices before re-arming the 8259... This gets REALLY hairy if you can't guarantee that you can re-arm the 8259 before one of the damn ports drops it's IRQ line again. I hope someone out there knows why the 8259 is run edge triggered rather than level triggered, I sure can't explain it... Scott Turner scotty@l5comp -or- uunet!l5comp!scotty