I do ifconfig xl0 delete
then
dhclient -cf /etc/dhclient.conf -lf /var/db/dhclient.leases xl0
and I get a kernel message every few secounds
xl0: watchdog timeout
I've not a clue what it means but I do know that dhclient never detects the
ip address from the ISP. allthough I put the same card
I've had another kernel panic, this time from a cold boot (the machine had
been powered off overnight), with a new world and kernel built yesterday:
FreeBSD rhadamanth.private.submonkey.net 4.6-PRERELEASE FreeBSD 4.6-PRERELEASE #0: Wed
May 1 21:59:38 BST 2002
[EMAIL PROTECTED]:/usr/obj/us
On Sun, May 26, 2002 at 12:26:41PM +0100, Ceri Davies wrote:
>
> I've had another kernel panic, this time from a cold boot (the machine had
> been powered off overnight), with a new world and kernel built yesterday:
>
> FreeBSD rhadamanth.private.submonkey.net 4.6-PRERELEASE FreeBSD 4.6-PRERELEA
[This is sent both to the NetBSD current list, plus the FreeBSD
hackers list, since I've had this panic on both. The debug info
is from FreeBSD, but the /NetBSD/usr/src/sys/ufs/ffs/ffs_alloc.c
source looks virtually identical. Please adjust followups as
appropriate if not relevant to both li
On Sun, May 26, 2002 at 01:48:12PM +0100, Dominic Marks wrote:
> On Sun, May 26, 2002 at 12:26:41PM +0100, Ceri Davies wrote:
> >
> > I've had another kernel panic, this time from a cold boot (the machine had
> > been powered off overnight), with a new world and kernel built yesterday:
> >
> > F
On Sun, May 26, 2002 at 04:30:24PM +0100, Ceri Davies wrote:
> On Sun, May 26, 2002 at 01:48:12PM +0100, Dominic Marks wrote:
> > On Sun, May 26, 2002 at 12:26:41PM +0100, Ceri Davies wrote:
> > >
> > > I've had another kernel panic, this time from a cold boot (the machine had
> > > been powered
On Sun, May 26, 2002 at 05:00:05PM +0100, Dominic Marks wrote:
> On Sun, May 26, 2002 at 04:30:24PM +0100, Ceri Davies wrote:
> > On Sun, May 26, 2002 at 01:48:12PM +0100, Dominic Marks wrote:
> > > I had this problem. To get good backtraces I do the following. I don't
> > > know how "good" this
I don't understand the resetpriority() function in the file
kern_synch.c in -current. I'm wondering if someone can help
me? What I don't understand is the logic for the call(s) to
maybe_resched() in resetpriority(). resetpriority() adjusts
kg->kg_user_pri, but doesn't touch td->td_priority. T
NetBSD is nuking almost all __STDC__ usages because it's always
defined. Do we want to do the same? The exception I've seen
is for assembler files where old style C is needed to avoid
conflicts.
mrouted/cfparse.y:#ifdef __STDC__
mrouted/cfparse.y:#ifdef __STDC__
mrouted/cfparse.y:#ifdef __STDC_
OK - after *many* additional printf()s, and following the
control flow through several twisty passages (all alike),
I've figured out _where_ the hang is happening but, not
why...
First - the card is inserted, and the various callbacks occur...
pccardd gets involved and reads the CIS to deter
In message: <[EMAIL PROTECTED]>
Thomas David Rivers <[EMAIL PROTECTED]> writes:
: Warner - any ideas?
: pci_write_config(..., bcr,2); hangs
Interesting
So this pretty much confirms what I'd expect. We establish the
interrupt handler, then turn on the interrupts, then hang.
11 matches
Mail list logo