fxp watchdog timeout patch
Sorry for the delay, here's the patch which should properly implement
watchdog timeout handling in the fxp driver. If you're one of the people
seeing the false watchdog timeout messages, please give this a whirl and
tell me how it worked.
Thanks,
Mike "Silby" Silbersack
--- if_fxp.cThu Jul 11 23:47:39 2002
+++ /home/silby/if_fxp.cFri Jul 19 00:36:57 2002
@@ -1251,14 +1251,14 @@
txp->mb_head = NULL;
}
sc->tx_queued--;
+ ifp->if_timer = 5;
}
sc->cbl_first = txp;
if (sc->tx_queued == 0) {
ifp->if_timer = 0;
if (sc->need_mcsetup)
fxp_mc_setup(sc);
- } else
- ifp->if_timer = 5;
+ }
/*
* Try to start more packets transmitting.
@@ -1401,7 +1401,10 @@
txp->mb_head = NULL;
}
sc->tx_queued--;
+ ifp->if_timer = 5;
}
+ if (sc->tx_queued == 0)
+ ifp->if_timer = 0;
sc->cbl_first = txp;
/*
* If we haven't received any packets in FXP_MAC_RX_IDLE seconds,
fxp0 timeouts
I'm quite certain this was discussed recently, but I can't find it in the mailing list archives. I'm getting a few "fxp0: device timeout" on my supermicro 6010H (dual 1GHz PIII with onboard fxp). Was this resolved? thanks, dave c -- Dave Cornejo @ Dogwood Media, Fremont, California (also [EMAIL PROTECTED]) "There aren't any monkeys chasing us..." - Xochi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Questions about kern_descrip.c
On 18-Jul-2002 Matthew Dillon wrote: > >:>:-- >:>: >:>:John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ >:> >:> Yes, that makes sense... and it would be fairly trivial >:> optimization to make. I suppose you could have fdalloc() >:> return EAGAIN or something like that to indicate that >:> it had to cycle the lock. >: >:But it doesn't really matter if we cycle the lock. What I described >:is the current behavior, btw. >: >:-- >: >:John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ > > Well, the original code for dup2() looped to ensure that the > source descriptor number was still a valid descriptor. Why > the dup() code doesn't do this I'm not sure, but I think it > needs to. If you cycle the locks and do not retry, someone else > could get in and close() the source descriptor and dup2() will > not return an error when it should. > > Also, do_dup() assumes that the source descriptor is non-NULL. > If dup2() (and dup()) do not retry then do_dup() can wind up > getting called with fd_ofiles[old] NULL (race against another > thread close()ing or dup2()ing over the original descriptor). > > If I remember right, a dup2()/dup2() race was one of the problems > being explicitly solved by this commit. Okies, I'll look at this some more. We might need to move the loop into do_dup(), or have do_dup() do an additional check. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current seems a little unstable tonight
On Thu, Jul 18, 2002 at 02:00:14PM -0700, Julian Elischer wrote:
> set radix 16
> and then print the trap frame again.. (#12)
#12 0xc02a0ce5 in trap (frame= {tf_fs = 0xc02a0018, tf_es = 0xc0320010,
tf_ds = 0xc0310010, tf_edi = 0xc191d094, tf_esi = 0xc0bc0f00, tf_ebp =
0xc8880c8c, tf_isp = 0xc8880c3c, tf_ebx = 0x405000, tf_edx = 0xc8ebada0,
tf_ecx = 0xc191fb40, tf_eax = 0xc191fb40, tf_trapno = 0xc, tf_err = 0x0,
tf_eip = 0xc02a0050, tf_cs = 0x8, tf_eflags = 0x10246, tf_esp =
0xc01b3da0, tf_ss = 0xb23f48e8}) at /usr/src/sys/i386/i386/trap.c:445
> then try use x/i on the contents of tf_eip to find where the actual fault
> was. Use 'disassemble' on that function to figure out where in the file
> you were.
(kgdb) x/i 0xc02a0050
0xc02a0050 : cmp0x0(%edx),%ebx
Which is i386/i386/swtch.s:182 I think.
This is where the address space is switched or not. However, this goes
above my head. Hopefully this helps you.
Thanks for the response!
Mark
--
Mark Santcroos RIPE Network Coordination Centre
http://www.ripe.net/home/mark/ New Projects Group/TTM
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Questions about kern_descrip.c
Matthew Dillon wrote: > The issue with dup2() was a race against open() or close() > I believe, where dup2() could potentially dup into a > descriptor that open() was about to use. Unfortunately, it > does appear that dup() has the same issue. > > fdalloc() does not reserve the descriptor number it > returns, it simply finds a free slot and says 'this > index is a free slot'. Even in the latest -current, > fdalloc() releases the fdp lock when it goes to > MALLOC so the race appears to still be present. The correct way to deal with this is to make the descriptor slot allocation happen at a higher layer, and pass the address of it in as an agrument to the code. This will incidently let you pass in a static or other non-FD table associated descriptor in place to all these calls, which will have the effect of permitting you to do "descriptor" based file I/O from kernel space much, much easier. If the work would be accepted as a delta against -stable, I would be willing to do it, since I need kernel file I/O, and the problem hasn't been solving itself for about six years now. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current seems a little unstable tonight
if you have ddb it would be instructive to ss what IT thinks the stack
looks like: heres' what I think is line 557 of kern_synch.c is:
554 if (td->td_wchan != NULL) {
555 p->p_stats->p_ru.ru_nvcsw++;
556 td->td_state = TDS_SLP;
557 mi_switch();
558 }
so we need to see where in mi_switch() if your file is the same as mine...
also:
do:
set radix 16
and then print the trap frame again.. (#12)
On Thu, 18 Jul 2002, Mark Santcroos wrote:
> On Thu, Jul 18, 2002 at 10:48:09AM +0200, Mark Santcroos wrote:
> > panic: vm_fault: fault on nofault entry, addr: c8856000
> >
> > (kgdb) bt
>
>
>
> > I didn't have a kernel with debugging info so I am building that now in
> > case it happens again.
>
> Catched it again and now with debugging kernel.
>
> panic: vm_fault: fault on nofault entry, addr: c8eba000
>
> #9 0xc01ae5f1 in panic () at /usr/src/sys/kern/kern_shutdown.c:493
> #10 0xc02629fb in vm_fault (map=0xc0832000, vaddr=3370885120,
> fault_type=1 '\001', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:259
> #11 0xc02a1149 in trap_pfault (frame=0xc8880c10, usermode=0, eva=3370888608)
> at /usr/src/sys/i386/i386/trap.c:747
> #12 0xc02a0ce5 in trap (frame=
> {tf_fs = -1070989288, tf_es = -1070465008, tf_ds = -1070530544,
> tf_edi = -1047408492, tf_esi = -1061417216, tf_ebp = -930607988,
> tf_isp = -930608068, tf_ebx = 4214784, tf_edx = -924078688, tf_ecx =
> -1047397568, tf_eax = -1047397568, tf_trapno = 12, tf_err = 0, tf_eip
> = -1070989232, tf_cs = 8, tf_eflags = 66118, tf_esp = -1071956576, tf_ss =
> -1304475416}) at /usr/src/sys/i386/i386/trap.c:445
then try use x/i on the contents of tf_eip to find where the actual fault
was. Use 'disassemble' on that function to figure out where in the file
you were.
theoretically addr2line(1) can give you this but in my experience it
doesn't work at the moment.
> #13 0xc0294ae8 in
> calltrap () at {standard input}:98 #14 0xc01b37ab in msleep
> (ident=0xc031708c, mtx=0x0, priority=104, wmesg=0x0,
> timo=0) at /usr/src/sys/kern/kern_synch.c:557
> #15 0xc01eea4c in sched_sync () at /usr/src/sys/kern/vfs_subr.c:1503
> #16 0xc019daad in fork_exit (callout=0xc01ee878 , arg=0x0,
> frame=0xc8880d48) at /usr/src/sys/kern/kern_fork.c:861
>
> I will try to find what's going on. Anyone any pointers?
>
> Thanks
>
> Mark
>
> --
> Mark SantcroosRIPE Network Coordination Centre
> http://www.ripe.net/home/mark/New Projects Group/TTM
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Questions about kern_descrip.c
:>:-- :>: :>:John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ :> :> Yes, that makes sense... and it would be fairly trivial :> optimization to make. I suppose you could have fdalloc() :> return EAGAIN or something like that to indicate that :> it had to cycle the lock. : :But it doesn't really matter if we cycle the lock. What I described :is the current behavior, btw. : :-- : :John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ Well, the original code for dup2() looped to ensure that the source descriptor number was still a valid descriptor. Why the dup() code doesn't do this I'm not sure, but I think it needs to. If you cycle the locks and do not retry, someone else could get in and close() the source descriptor and dup2() will not return an error when it should. Also, do_dup() assumes that the source descriptor is non-NULL. If dup2() (and dup()) do not retry then do_dup() can wind up getting called with fd_ofiles[old] NULL (race against another thread close()ing or dup2()ing over the original descriptor). If I remember right, a dup2()/dup2() race was one of the problems being explicitly solved by this commit. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current seems a little unstable tonight
On Thu, Jul 18, 2002 at 10:48:09AM +0200, Mark Santcroos wrote:
> panic: vm_fault: fault on nofault entry, addr: c8856000
>
> (kgdb) bt
> I didn't have a kernel with debugging info so I am building that now in
> case it happens again.
Catched it again and now with debugging kernel.
panic: vm_fault: fault on nofault entry, addr: c8eba000
#9 0xc01ae5f1 in panic () at /usr/src/sys/kern/kern_shutdown.c:493
#10 0xc02629fb in vm_fault (map=0xc0832000, vaddr=3370885120,
fault_type=1 '\001', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:259
#11 0xc02a1149 in trap_pfault (frame=0xc8880c10, usermode=0, eva=3370888608)
at /usr/src/sys/i386/i386/trap.c:747
#12 0xc02a0ce5 in trap (frame=
{tf_fs = -1070989288, tf_es = -1070465008, tf_ds = -1070530544, tf_edi =
-1047408492, tf_esi = -1061417216, tf_ebp = -930607988, tf_isp = -930608068, tf_ebx =
4214784, tf_edx = -924078688, tf_ecx = -1047397568, tf_eax = -1047397568, tf_trapno =
12, tf_err = 0, tf_eip = -1070989232, tf_cs = 8, tf_eflags = 66118, t---Type
to continue, or q to quit---
f_esp = -1071956576, tf_ss = -1304475416}) at /usr/src/sys/i386/i386/trap.c:445
#13 0xc0294ae8 in calltrap () at {standard input}:98
#14 0xc01b37ab in msleep (ident=0xc031708c, mtx=0x0, priority=104, wmesg=0x0,
timo=0) at /usr/src/sys/kern/kern_synch.c:557
#15 0xc01eea4c in sched_sync () at /usr/src/sys/kern/vfs_subr.c:1503
#16 0xc019daad in fork_exit (callout=0xc01ee878 , arg=0x0,
frame=0xc8880d48) at /usr/src/sys/kern/kern_fork.c:861
I will try to find what's going on. Anyone any pointers?
Thanks
Mark
--
Mark Santcroos RIPE Network Coordination Centre
http://www.ripe.net/home/mark/ New Projects Group/TTM
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Questions about kern_descrip.c
On 18-Jul-2002 Matthew Dillon wrote: > >: >:* Matthew Dillon <[EMAIL PROTECTED]> [020718 11:40] wrote: >:> >:> fdalloc() does not reserve the descriptor number it >:> returns, it simply finds a free slot and says 'this >:> index is a free slot'. Even in the latest -current, >:> fdalloc() releases the fdp lock when it goes to >:> MALLOC so the race appears to still be present. >: >:This is true. I think one way to fix this is to preallocate >:the 'struct file' you're going to put into the array and have >:fdalloc() insert the created file instead of just finding a >:slot. Problem is that it's a bunch of grunt work to do this. >: >:-- >:-Alfred Perlstein [[EMAIL PROTECTED]] >:'Instead of asking why a piece of software is using "1970s technology," > > If you do this be careful in regards to open() and close() which > might place the descriptor in a transitory state. You don't want > another thread picking the descriptor up while it is in that > state. If you really wanted to do this you could just use '(struct file *)1' or some other evil, but I really don't think it's necessary. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Questions about kern_descrip.c
On 18-Jul-2002 Matthew Dillon wrote: > >:> The issue with dup2() was a race against open() or close() >:> I believe, where dup2() could potentially dup into a >:> descriptor that open() was about to use. Unfortunately, it >:> does appear that dup() has the same issue. >:> >:> fdalloc() does not reserve the descriptor number it >:> returns, it simply finds a free slot and says 'this >:> index is a free slot'. Even in the latest -current, >:> fdalloc() releases the fdp lock when it goes to >:> MALLOC so the race appears to still be present. >: >:Well, execpt that if we malloc(), we then grab the lock and loop >:again. If we return without an error, it means we reserved a slot >:while holding a lock and returned with the lock still held. >: >:-- >: >:John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ > > Yes, that makes sense... and it would be fairly trivial > optimization to make. I suppose you could have fdalloc() > return EAGAIN or something like that to indicate that > it had to cycle the lock. But it doesn't really matter if we cycle the lock. What I described is the current behavior, btw. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
suspend bug
Try this: $ csh % su Password: % stop $$ Suspended (signal) %fg At which point you will lose you login shell. Prior to KSE one could switch between an su'ed shell and a normal shell at will by using stop $$ and fg. Is this breakage considered a bug or a feature? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Questions about kern_descrip.c
: :* Matthew Dillon <[EMAIL PROTECTED]> [020718 11:40] wrote: :> :> fdalloc() does not reserve the descriptor number it :> returns, it simply finds a free slot and says 'this :> index is a free slot'. Even in the latest -current, :> fdalloc() releases the fdp lock when it goes to :> MALLOC so the race appears to still be present. : :This is true. I think one way to fix this is to preallocate :the 'struct file' you're going to put into the array and have :fdalloc() insert the created file instead of just finding a :slot. Problem is that it's a bunch of grunt work to do this. : :-- :-Alfred Perlstein [[EMAIL PROTECTED]] :'Instead of asking why a piece of software is using "1970s technology," If you do this be careful in regards to open() and close() which might place the descriptor in a transitory state. You don't want another thread picking the descriptor up while it is in that state. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Questions about kern_descrip.c
:> The issue with dup2() was a race against open() or close() :> I believe, where dup2() could potentially dup into a :> descriptor that open() was about to use. Unfortunately, it :> does appear that dup() has the same issue. :> :> fdalloc() does not reserve the descriptor number it :> returns, it simply finds a free slot and says 'this :> index is a free slot'. Even in the latest -current, :> fdalloc() releases the fdp lock when it goes to :> MALLOC so the race appears to still be present. : :Well, execpt that if we malloc(), we then grab the lock and loop :again. If we return without an error, it means we reserved a slot :while holding a lock and returned with the lock still held. : :-- : :John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ Yes, that makes sense... and it would be fairly trivial optimization to make. I suppose you could have fdalloc() return EAGAIN or something like that to indicate that it had to cycle the lock. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with agpgart on current, XFree86-4, Matrox G400 video
At 7:53 PM -0600 7/17/02, Eric Anholt wrote: >On Wed, 2002-07-17 at 18:40, Garance A Drosihn wrote: > > > XDM generally did still seem to come up okay, although occasionally > > the system would panic right at that initial XDM startup. While > > I tried a few things to fix this (including various buildworlds > > over time), I didn't really worry about it too much because I > > could always fall back to my April 23rd snapshot of -current. > >April 27th was when the DRM went into -current. Did you ever get >a dump/backtrace of the panic? Did you have drm-kmod installed? I never got a dump of the panic, and in fact I only got the panic two or maybe three times (in about two months). The panic only happened at the initial startup of XDM, so if I got past that then I could run okay for long stretches without a problem. I was also tangled up in other problems with current the same time, and usually I would just take the easy way out and drop back to my April 23rd snapshot of -current. > > I added that line, rebooted, and now XFree86-4 has no problem > > initializing agpgart when XDM starts up. > >Can you still make it panic after adding agp? Well, I haven't yet, but then I haven't been running it this way for all that long. I would be happy with agp added to the generic kernel, but then I'm one of the people who would benefit from that... :-) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Questions about kern_descrip.c
On 18-Jul-2002 Matthew Dillon wrote: > >: >:In revision 1.94 of kern_descrip.c, in the dup2() syscall a goto >:retry loop was added so that if we did a fdalloc() we always retested >:everything. Since fd_nfiles can't shrink and new and old can't >:change, I don't see why the loop is necessary. Neither dup() or >:the F_DUPFD fcntl() were modified in this way either. Also, >:calling fdalloc() in this case is somewhat bogus, because fdalloc() >:is going to try and reserve an open slot and update variables such >:as fd_lastfile, etc. appropriately. Perhaps we should have an >:fdextend() function that both dup2() and fdalloc() call? Also, >:in do_dup() you have commented out the call to munmapfd() on an >:open file with UF_MAPPED and never turned it back on. Was that >:intentional or just an accidental oversight? >: >:-- >: >:John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ > > The issue with dup2() was a race against open() or close() > I believe, where dup2() could potentially dup into a > descriptor that open() was about to use. Unfortunately, it > does appear that dup() has the same issue. > > fdalloc() does not reserve the descriptor number it > returns, it simply finds a free slot and says 'this > index is a free slot'. Even in the latest -current, > fdalloc() releases the fdp lock when it goes to > MALLOC so the race appears to still be present. Well, execpt that if we malloc(), we then grab the lock and loop again. If we return without an error, it means we reserved a slot while holding a lock and returned with the lock still held. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Questions about kern_descrip.c
* Matthew Dillon <[EMAIL PROTECTED]> [020718 11:40] wrote: > > fdalloc() does not reserve the descriptor number it > returns, it simply finds a free slot and says 'this > index is a free slot'. Even in the latest -current, > fdalloc() releases the fdp lock when it goes to > MALLOC so the race appears to still be present. This is true. I think one way to fix this is to preallocate the 'struct file' you're going to put into the array and have fdalloc() insert the created file instead of just finding a slot. Problem is that it's a bunch of grunt work to do this. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fixed ! Re: Interesting panic very early in the boot
On Thu, Jul 18, 2002 at 01:40:48PM -0400, Bosko Milekic wrote: > As pointed out, the change was fairly bogus. There's a new change > that should be committed soon that fixes the problem in a "sort of" > less bogus way. When Peter gets around to reviewing it, it'll be > committed and you shouldn't notice a difference. Excellent. As I stated, all I wanted to report was that "the panic did not occur again". This is good news in any event, because it seemed that it did not occur very frequently, so seemed more difficult to fix. I was just fearing that it would take perhaps a very long time, eg because it does not occur so often on new hardware or somesuch. A correct fix is certainly even better. > As a point of reference, however, what hardware do you have this > running on? Specifically, what board, CPUs, how many, and how much > RAM do you have? Full specs: - Shuttle Spacewalker HOT-637/P motherboard with Intel 440 LX chipset, UP. Has ISA, PCI and AGP slots, doesn't support ACPI. (in any meaningful way) - Intel Pentium II 233 Mhz (Klamath) CPU, Slot 1 - 128 megs of SDRAM (non-DDR) in two 64 meg units - Two ATA HDDs, ATAPI CD-ROM, PCI network card (Realtek 8029), ISA PnP SB 64 AWE sound, S3 Virge GX2 AGP video card, just in case. No SCSI. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Questions about kern_descrip.c
: :In revision 1.94 of kern_descrip.c, in the dup2() syscall a goto :retry loop was added so that if we did a fdalloc() we always retested :everything. Since fd_nfiles can't shrink and new and old can't :change, I don't see why the loop is necessary. Neither dup() or :the F_DUPFD fcntl() were modified in this way either. Also, :calling fdalloc() in this case is somewhat bogus, because fdalloc() :is going to try and reserve an open slot and update variables such :as fd_lastfile, etc. appropriately. Perhaps we should have an :fdextend() function that both dup2() and fdalloc() call? Also, :in do_dup() you have commented out the call to munmapfd() on an :open file with UF_MAPPED and never turned it back on. Was that :intentional or just an accidental oversight? : :-- : :John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ The issue with dup2() was a race against open() or close() I believe, where dup2() could potentially dup into a descriptor that open() was about to use. Unfortunately, it does appear that dup() has the same issue. fdalloc() does not reserve the descriptor number it returns, it simply finds a free slot and says 'this index is a free slot'. Even in the latest -current, fdalloc() releases the fdp lock when it goes to MALLOC so the race appears to still be present. the munmap descriptor junk is obsolete and has not been used for a very long time. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NEWCARD support for Linksys Ethernet broken?
>>> On Thu, 18 Jul 2002 09:50:54 -0600 (MDT), "M. Warner Losh" <[EMAIL PROTECTED]> said: > In message: <[EMAIL PROTECTED]> > Hideyuki KURASHINA <[EMAIL PROTECTED]> writes: > : Jul 19 00:34:49 hoge pccardd[1363]: driver allocation failed for MELCO(LPC3-TX): >Inappropriate ioctl for device > > recompile pccardd. The inappropriate ioctl for device is due to a > slight mismatch between kernel and pccardd. I recerntly change the > ioctl interface in current so that I could MFC some changes in a > binary compatible way in -stable (thus breaking binary compat in > -current). When I use /usr/obj/usr/src/usr.sbin/pccard/pccardd/pccard instead of /usr/sbin/pccardd, PC Card works again. :-) ed0 at port 0x340-0x35f iomem 0xd-0xd0fff irq 3 flags 0x3 slot 1 on pccard1 ed0: address 00:40:26:xx:xx:xx, type NE2000 (16 bit) Thanks! -- rushani To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Questions about kern_descrip.c
On 18-Jul-2002 John Baldwin wrote: > In revision 1.94 of kern_descrip.c, in the dup2() syscall a goto > retry loop was added so that if we did a fdalloc() we always retested > everything. Since fd_nfiles can't shrink and new and old can't > change, I don't see why the loop is necessary. Neither dup() or > the F_DUPFD fcntl() were modified in this way either. Also, > calling fdalloc() in this case is somewhat bogus, because fdalloc() > is going to try and reserve an open slot and update variables such > as fd_lastfile, etc. appropriately. Perhaps we should have an > fdextend() function that both dup2() and fdalloc() call? Also, > in do_dup() you have commented out the call to munmapfd() on an > open file with UF_MAPPED and never turned it back on. Was that > intentional or just an accidental oversight? Nevermind about munmapfd(). -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Questions about kern_descrip.c
In revision 1.94 of kern_descrip.c, in the dup2() syscall a goto retry loop was added so that if we did a fdalloc() we always retested everything. Since fd_nfiles can't shrink and new and old can't change, I don't see why the loop is necessary. Neither dup() or the F_DUPFD fcntl() were modified in this way either. Also, calling fdalloc() in this case is somewhat bogus, because fdalloc() is going to try and reserve an open slot and update variables such as fd_lastfile, etc. appropriately. Perhaps we should have an fdextend() function that both dup2() and fdalloc() call? Also, in do_dup() you have commented out the call to munmapfd() on an open file with UF_MAPPED and never turned it back on. Was that intentional or just an accidental oversight? -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fixed ! Re: Interesting panic very early in the boot
On Thu, Jul 18, 2002 at 07:38:39PM +0200, Szilveszter Adam wrote: > Hello everybody, > > I would like to report that after incorporating today's fixes into the > kernel source and recompiling, the panic does not occur again. > > This is probably due to the commit to pmap.c (rev 1.345 by Peter Wemm). > Although the log only talks about SMP, this UP box likes it too. > > So anyway, thanks for fixing this, and anybody who used the > "DISABLE_PG_G" workaround can now switch that off. > > Happy hacking! > -- > Regards: > > Szilveszter ADAM > Szombathely Hungary As pointed out, the change was fairly bogus. There's a new change that should be committed soon that fixes the problem in a "sort of" less bogus way. When Peter gets around to reviewing it, it'll be committed and you shouldn't notice a difference. As a point of reference, however, what hardware do you have this running on? Specifically, what board, CPUs, how many, and how much RAM do you have? Thanks, -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ld hanging during build of today's -CURRENT
OK; I built today's -CURRENT (running yesterday's, as usual) on my SMP build machine without incident earlier today. And, as usual, I'm trying the same thing with my (UP) laptop. But this time, the sequence has come to a halt; here's what I see so far: >>> stage 4: populating /usr/obj/usr/src/i386/usr/include ... >>> stage 4: building libraries ... ===> gnu/lib/libobjc ... ===> gnu/lib/libg2c cc -O -pipe -DLIBC_MAJOR=5 -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -D__DBINTERFACE_PRIVATE -DINET6 -I/common/S3/obj/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -DYP -DHESIOD -c nslexer.c -o nslexer.o cc -pg -O -pipe -DLIBC_MAJOR=5 -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -D__DBINTERFACE_PRIVATE -DINET6 -I/common/S3/obj/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -DYP -DHESIOD -c nslexer.c -o nslexer.po cc -fpic -DPIC -O -pipe -DLIBC_MAJOR=5 -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -D__DBINTERFACE_PRIVATE -DINET6 -I/common/S3/obj/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -DYP -DHESIOD -c nslexer.c -o nslexer.So building profiled c library building shared library libc.so.5 building special pic c library building static c library ranlib libc_pic.a ranlib libc.a ranlib libc_p.a and at this point, ^T says: load: 0.00 cmd: ld 64393 [inode] 0.10u 0.30s 0% 1k "ps -xwwlp 64393" says: UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 64393 64391 0 96 0 12108 2925 - W+p70:00.41 (ld) and various bits and pieces of /proc/64393 say: g1-9(5.0-C)[10] sudo cat /proc/64393/map 0x8048000 0x80c8000 48 48 0xc20ca4b0 r-x 2 1 0x0 COW NC vnode 0x80c8000 0x80c9000 1 0 0xc1d7cf3c rw- 1 0 0x2180 COW NNC vnode 0x80c9000 0x80cd000 3 0 0xc1fd6af0 rw- 2 0 0x2180 NCOW NNC default 0x80cd000 0x8bf7000 2856 0 0xc1fd6af0 rwx 2 0 0x2180 NCOW NNC default 0x280cb000 0x280cf000 3 0 0xc1e58e74 rwx 1 0 0x2180 NCOW NNC default 0xbfbe 0xbfc0 6 0 0xc1afd7d0 rwx 1 0 0x2180 NCOW NNC default g1-9(5.0-C)[13] sudo cat /proc/64393/status ld 64393 64391 594 576 5,7 ctty 1027012600,166143 0,101735 0,305207 nochan 0 0 0,0,0,2,3,4,5,20,31 - g1-9(5.0-C)[15] sudo cat /proc/64393/rlimit cpu -1 -1 fsize -1 -1 data 536870912 536870912 stack 67108864 67108864 core -1 -1 rss -1 -1 memlock -1 -1 nproc 896 896 nofile 1792 1792 sbsize -1 -1 vmem -1 -1 Now, I'm running the "make buildworld" with -j4 (as usual, for the laptop). I rather suspect that were I to interrupt & restart it, this hang probably would not recur (at least, not in exactly this way). So I'm sending this out now, in the hope that someone might suggest some approach(es) that might cause the system to divulge what happened, so we can prevent a recurrence of this sort of thing. Unfortunately, I don't seem to have built this kernel with BREAK_TO_DEBUGGER. :-( So -- is this worth pursuing, or should I just muddle on through? Thanks, david -- David H. Wolfskill [EMAIL PROTECTED] My reluctance to use or support Microsoft products is a direct consequence of my desire to use tools that work properly. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Fixed ! Re: Interesting panic very early in the boot
Hello everybody, I would like to report that after incorporating today's fixes into the kernel source and recompiling, the panic does not occur again. This is probably due to the commit to pmap.c (rev 1.345 by Peter Wemm). Although the log only talks about SMP, this UP box likes it too. So anyway, thanks for fixing this, and anybody who used the "DISABLE_PG_G" workaround can now switch that off. Happy hacking! -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[patch] Re: inetd parsing broke for non IPv6 configurations
The following patch fixes this problem for me. When a tcp6 was
encountered then v6bind is set to 1 and was not being cleared
after the check to ignore IPv6. This patch may not be entirely
correct, but its simple and does fix the problem I reported
earlier. The v4bind check that should have resulted in clearing
v6bind back to 0 seems a bit questionable. I believe the flag
should be cleared always.
-Steve
-
--- inetd.c.old Mon Jul 15 14:09:33 2002
+++ inetd.c Thu Jul 18 11:53:55 2002
@@ -1726,12 +1726,9 @@
if (v6bind != 0 && no_v6bind != 0) {
syslog(LOG_INFO, "IPv6 bind is ignored for %s",
sep->se_service);
- if (v4bind && no_v4bind == 0)
- v6bind = 0;
- else {
- freeconfig(sep);
- goto more;
- }
+ v6bind = 0;
+ freeconfig(sep);
+ goto more;
}
if (v6bind != 0) {
sep->se_family = AF_INET6;
-
-Steve
On Wed, Jul 17, 2002 at 02:36:46PM -0500, Steve Ames wrote:
>
> This worked 3 days ago but I just upgraded to -CURRENT from today
> and its not quite working now. If you have tcp6 lines in your
> inetd.conf but do not have IPv6 enabled in the kernel your inetd
> will stop adding services after it encounters the first line with
> a tcp6 in it:
>
> mysystem# inetd -d
> ADD : ftp proto=tcp accept=1 max=0 user=root group=(null)class=daemon builtin=0x
> 0 server=/usr/libexec/ftpd policy=""
> inetd: ftp/tcp: ipsec initialization failed; in entrust
> inetd: ftp/tcp: ipsec initialization failed; tut entrust
> inetd: enabling ftp, fd 4
> inetd: registered /usr/libexec/ftpd on 4
> inetd[52984]: IPv6 bind is ignored for ftp
> inetd[52984]: IPv6 bind is ignored for telnet
> inetd[52984]: IPv6 bind is ignored for telnet
> inetd[52984]: IPv6 bind is ignored for comsat
> inetd[52984]: IPv6 bind is ignored for ntalk
> inetd[52984]: IPv6 bind is ignored for pop3
> inetd[52984]: IPv6 bind is ignored for imap4
> inetd[52984]: IPv6 bind is ignored for imaps
> inetd[52984]: IPv6 bind is ignored for auth
> inetd[52984]: IPv6 bind is ignored for auth
> inetd[52984]: IPv6 bind is ignored for gpsclock
>
> Here it correctly adds ftp/tcp and ignores ftp/tcp6... but then it
> appears to see all remaining entries as tcp6 and ignores them even
> when they are most certainly listed as tcp and not tcp6.
>
> I'm guessing that
>
> $FreeBSD: src/usr.sbin/inetd/inetd.c,v 1.105 2002/07/15 19:09:33
>
> is the culprit. This commit was to add support for rpc IPv6 and
> does appear to change the code block where the "IPv6 bind is
> ignored" appears..
>
> -Steve
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: NEWCARD support for Linksys Ethernet broken?
In message: <[EMAIL PROTECTED]> Hideyuki KURASHINA <[EMAIL PROTECTED]> writes: : Jul 19 00:34:49 hoge pccardd[1363]: driver allocation failed for MELCO(LPC3-TX): :Inappropriate ioctl for device recompile pccardd. The inappropriate ioctl for device is due to a slight mismatch between kernel and pccardd. I recerntly change the ioctl interface in current so that I could MFC some changes in a binary compatible way in -stable (thus breaking binary compat in -current). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NEWCARD support for Linksys Ethernet broken?
Hi,
>>> On Thu, 18 Jul 2002 02:06:15 -0600 (MDT), "M. Warner Losh" <[EMAIL PROTECTED]> said:
> In message: <[EMAIL PROTECTED]>
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> : Just upgraded my laptop to the latest -CURRENT ... everything boots fine,
> : but my ethernet no longer exists (it worked great on my June 6th kernel)
> : ...
>
> Used to work for me, but something seems to have busted it in recent
> versions of the kernel. So NEWCARD appears to be broken for ata, sio
> and ed. Wonderful. These all used to work at one point in the past.
Unfortunately, ed driver does not work here (OLDCARD), too. I cvsup'ed
and built world & kernel yesterday, and installed kernel. it worked
fine on my July 11th kernel.
I use Melco LPC3-TX and now have following error messages;
Jul 19 00:34:44 hoge pccardd[1363]: Card "MELCO"("LPC3-TX") [] [] matched
"MELCO"("LPC3-TX") [(null)] [(null)]
Jul 19 00:34:44 hoge pccardd[1363]: Ether=00:40:26:xx:xx:xx
Jul 19 00:34:49 hoge pccardd[1363]: driver allocation failed for MELCO(LPC3-TX):
Inappropriate ioctl for device
-- rushani
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: getting vmemoryuse resource limit: Invalid argument
On Thu, 18 Jul 2002, Jeroen C.van Gelderen wrote: > On Thursday, July 18, 2002, at 04:47 , Gavin Atkinson wrote: > > Jul 18 09:21:24 epsilon login: getting vmemoryuse resource limit: > > Invalid argument > > Did you run mergemaster? You should have a line like > :vmemoryuse=unlimited:\ > in your login.conf. That was it, but i'm not sure what went wrong - I have ran mergemaster at least three times since then, and other changes had indeed been merged... but not that one. Ah well, it's fixed now. thanks Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NEWCARD support for Linksys Ethernet broken?
On Thu, Jul 18, 2002 at 08:52:43AM -0600, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Ian Dowse <[EMAIL PROTECTED]> writes: > : I think the "ed" problem is that without pccardd, the 0x8 flag > : is no longer being passed to the driver, so it doesn't try probing > : it as a Linksys card (I haven't checked for sure, but that would > : be consistent with it being detected as an NE2000). > > That may be true. I thought I had flags in the table of ne2000 pcmcia > cards... Hey, this sounds like it could be my problem as well. If anyone has any patches, I would gladly test them. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. [EMAIL PROTECTED] FreeBSD Committer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NEWCARD support for Linksys Ethernet broken?
In message: <[EMAIL PROTECTED]> Ian Dowse <[EMAIL PROTECTED]> writes: : I think the "ed" problem is that without pccardd, the 0x8 flag : is no longer being passed to the driver, so it doesn't try probing : it as a Linksys card (I haven't checked for sure, but that would : be consistent with it being detected as an NE2000). That may be true. I thought I had flags in the table of ne2000 pcmcia cards... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: When will PCI_ENABLE_IO_MODES be default?
So, how much does this have to do with my laptop's sound (DSP) dumping out after about 10 seconds? (Toshiba had the great idea of hard-wiring most everything through IRQ 11, although pccardd seems to be able to use others) > Longer Answer: For some time now MS has had the notion of a Plug and > Play OS at the BIOS level. Most BIOSes had the ability to say "This OS > is a Plug and Play OS" and would refrain from assigning resources to > the pci cards that might be a pita for the PnP OS to deal with down the > road. In a Plug and Play OS, it deals with resource issues > compeletely and totally (except for devices required to boot the > system, iirc). In a non PnP OS, like FreeBSD, the OS expects the BIOS > to have assigned all the resources and activated all the cards. > > For years, this worked great. ACPI can be viewed as an even more > extensive attempt to get the OS to assign all the resources to the > cards. Now with ACPI in more and more BIOSes, they are shipping w/o > the ability to turn off PnP OS. They assume that the OS will be at > least PnP, if not fully use the ACPI paradigm[*] to do its resource > thing. FreeBSD has to cope with this better in general. > PCI_ENABLE_IO_MODES is a kludge that only kinda makes things better. > > NetBSD does a better job at this by enumerating things at boot time and > assigning resources when the big picture is being looked at. > FreeBSD should do this as well. We will have to deal with assigning > things that could need more resources later, like cardbus and cPCI > bridges, "big" chunks of space that they can later dole out as > needed. pci bridges make this problem more interesting because some of > them will only decode certain address ranges (which is the cause of > another kludge in the pci code). > > You can do a web search for the pc99 design guide (and newer ones). > They go into some of this. The ACPI standards docs also go into this > as well, although the 1.0 verion didn't do it very well (imho). There > are a number of other places to look for information too. The > mindshare books might be good. > > I'm not aware of one place the ties all of these "customs" together > into a coherent hole :-(. > > > Warner > > [*] These are wesil words for "The OS does all the resource > assignment." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
2000 CDT cvs panic
I cvsup'ed last night at and rebuild around 2000 CDT. The world and kernel portions completed, but upon rebooting I was greeted with: pccbb: unable to map IRQ... pccbb: resource_list_release: can't find resource and am then dropped to the debugger. Booting with unset acpi_load results in the same error. If I do a reset from db at that point, the system reboots, gives me the boot loader prompt and immediately powers off. If I'm fast enough, I can hit a choice and the system will boot. All this is on a Toshiba 5005-S504, an ACPI only system. Any ideas where I should start looking? Rob -- Remember: the only difference between being the champ and the chump is u. signature.asc Description: This is a digitally signed message part
Re: 5.0-DP2 coming up..
Andrew Kolchoogin wrote: > Hi! > > On Wed, Jul 17, 2002 at 07:40:47PM -0400, Garance A Drosihn wrote: > > Hey all (ab)users of -current. Please try to work on getting -current as stabilized as possible in the next few days and hold off on any large changes until after re@ creates the Perforce branch for DP2 on Friday. >>> >>>Well a working XFree86-4 would be just great to have in DP2 ;) >> >>It seems to be working for me, thanks to all the recent work from >>Eric Anholt <[EMAIL PROTECTED]>. When I built it (on the 14th) there >>was still the issue of Wraphelp.c not ending up in the right place, >>but that is being worked on. And that was trivial enough for me >>to figure out, that I was up-and-running with it. > > Yesterday I built XFree86-4-libraries port on my Alpha (-current > from July, 15) -- everything is O.K., including xc/lib/Xdmcp, where the > Wraphelp.c file is used. > > Andrew. > Well for me building the libraries has never been a problem, but the font's are since they are requireing a perl file, the perlport is installed and working but still... Shouldn't perl be a dependencie for XFree86-4? /John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NEWCARD support for Linksys Ethernet broken?
In message <[EMAIL PROTECTED]>, "M. Warner Losh" writes: >Used to work for me, but something seems to have busted it in recent >versions of the kernel. So NEWCARD appears to be broken for ata, sio >and ed. Wonderful. These all used to work at one point in the past. I think the "ed" problem is that without pccardd, the 0x8 flag is no longer being passed to the driver, so it doesn't try probing it as a Linksys card (I haven't checked for sure, but that would be consistent with it being detected as an NE2000). Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current seems a little unstable tonight
On Thu, Jul 18, 2002 at 01:28:22AM -0700, Lamont Granquist wrote: > I just cvsup'd and about 1.5h later got a crash+reboot with no dump. I > think someone else mentioned problems with fsck and I saw something like > that too -- it looked like the rc scripts errored out after the fsck and > dropped me into single user... It could have been the following which I just got. panic: vm_fault: fault on nofault entry, addr: c8856000 (kgdb) bt #0 0xc01b1900 in doadump () #1 0xc01b1d12 in boot () #2 0xc01b1ec5 in panic () #3 0xc01300cd in db_panic () #4 0xc013006c in db_command () #5 0xc013013b in db_command_loop () #6 0xc013257a in db_trap () #7 0xc02b11a0 in kdb_trap () #8 0xc02be98c in trap () #9 0xc02b2568 in calltrap () #10 0xc01b1eac in panic () #11 0xc027db53 in vm_fault () #12 0xc02beba5 in trap_pfault () #13 0xc02be741 in trap () #14 0xc02b2568 in calltrap () #15 0xc01b707f in msleep () #16 0xc01f2320 in sched_sync () #17 0xc01a1381 in fork_exit () I didn't have a kernel with debugging info so I am building that now in case it happens again. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0-DP2 coming up..
Hi! On Wed, Jul 17, 2002 at 07:40:47PM -0400, Garance A Drosihn wrote: >>>Hey all (ab)users of -current. Please try to work on getting -current >>>as stabilized as possible in the next few days and hold off on any >>>large changes until after re@ creates the Perforce branch for DP2 on >>>Friday. >>Well a working XFree86-4 would be just great to have in DP2 ;) > It seems to be working for me, thanks to all the recent work from > Eric Anholt <[EMAIL PROTECTED]>. When I built it (on the 14th) there > was still the issue of Wraphelp.c not ending up in the right place, > but that is being worked on. And that was trivial enough for me > to figure out, that I was up-and-running with it. Yesterday I built XFree86-4-libraries port on my Alpha (-current from July, 15) -- everything is O.K., including xc/lib/Xdmcp, where the Wraphelp.c file is used. Andrew. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
getting vmemoryuse resource limit: Invalid argument
Getting this since updating kernel/word to a cvsup a couple of days ago. Jul 18 09:21:24 epsilon login: getting vmemoryuse resource limit: Invalid argument Jul 18 09:22:00 epsilon /usr/sbin/cron[342]: getting vmemoryuse resource limit: Invalid argument Jul 18 09:25:00 epsilon /usr/sbin/cron[355]: getting vmemoryuse resource limit: Invalid argument Jul 18 09:30:00 epsilon /usr/sbin/cron[359]: getting vmemoryuse resource limit: Invalid argument Jul 18 09:33:00 epsilon /usr/sbin/cron[363]: getting vmemoryuse resource limit: Invalid argument Jul 18 09:34:26 epsilon sshd[367]: getting vmemoryuse resource limit: Invalid argument Jul 18 09:33:00 epsilon /usr/sbin/cron[369]: getting vmemoryuse resource limit: Invalid argument Previously working kernel was cvsupped June 23rd. Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-current seems a little unstable tonight
I just cvsup'd and about 1.5h later got a crash+reboot with no dump. I think someone else mentioned problems with fsck and I saw something like that too -- it looked like the rc scripts errored out after the fsck and dropped me into single user... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NEWCARD support for Linksys Ethernet broken?
In message: <[EMAIL PROTECTED]> "Marc G. Fournier" <[EMAIL PROTECTED]> writes: : Just upgraded my laptop to the latest -CURRENT ... everything boots fine, : but my ethernet no longer exists (it worked great on my June 6th kernel) : ... Used to work for me, but something seems to have busted it in recent versions of the kernel. So NEWCARD appears to be broken for ata, sio and ed. Wonderful. These all used to work at one point in the past. Time to try to block out a chunk of time for dealing with them. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: When will PCI_ENABLE_IO_MODES be default?
In message: <[EMAIL PROTECTED]> Ronald van der Pol <[EMAIL PROTECTED]> writes: : On Wed, Jul 17, 2002 at 23:33:13 -0600, M. Warner Losh wrote: : : > It is a tiny piece of a larger puzzle that will be fixed as we do : > proper resource allocation now that the BIOS specifications have been : > changed by MS to move that into the OS. : : Can you elaborate on that or give some pointers? Short answer: ACPI. :-) Longer Answer: For some time now MS has had the notion of a Plug and Play OS at the BIOS level. Most BIOSes had the ability to say "This OS is a Plug and Play OS" and would refrain from assigning resources to the pci cards that might be a pita for the PnP OS to deal with down the road. In a Plug and Play OS, it deals with resource issues compeletely and totally (except for devices required to boot the system, iirc). In a non PnP OS, like FreeBSD, the OS expects the BIOS to have assigned all the resources and activated all the cards. For years, this worked great. ACPI can be viewed as an even more extensive attempt to get the OS to assign all the resources to the cards. Now with ACPI in more and more BIOSes, they are shipping w/o the ability to turn off PnP OS. They assume that the OS will be at least PnP, if not fully use the ACPI paradigm[*] to do its resource thing. FreeBSD has to cope with this better in general. PCI_ENABLE_IO_MODES is a kludge that only kinda makes things better. NetBSD does a better job at this by enumerating things at boot time and assigning resources when the big picture is being looked at. FreeBSD should do this as well. We will have to deal with assigning things that could need more resources later, like cardbus and cPCI bridges, "big" chunks of space that they can later dole out as needed. pci bridges make this problem more interesting because some of them will only decode certain address ranges (which is the cause of another kludge in the pci code). You can do a web search for the pc99 design guide (and newer ones). They go into some of this. The ACPI standards docs also go into this as well, although the 1.0 verion didn't do it very well (imho). There are a number of other places to look for information too. The mindshare books might be good. I'm not aware of one place the ties all of these "customs" together into a coherent hole :-(. Warner [*] These are wesil words for "The OS does all the resource assignment." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: When will PCI_ENABLE_IO_MODES be default?
On Wed, Jul 17, 2002 at 23:33:13 -0600, M. Warner Losh wrote: > It is a tiny piece of a larger puzzle that will be fixed as we do > proper resource allocation now that the BIOS specifications have been > changed by MS to move that into the OS. Can you elaborate on that or give some pointers? rvdp To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
