-0166: *** Error: UtAllocate: Attempt to alloc
...ate zero bytes The kernel message -0166: *** Error: UtAllocate: Attempt to allocate zero bytes -0166: *** Error: UtAllocate: Attempt to allocate zero bytes -0166: *** Error: UtAllocate: Attempt to allocate zero bytes -0166: *** Error: UtAllocate: Attempt to allocate zero bytes clobbers the screen in bursts during startup for quite some time now. I would like to ask if there is something I can do about it. Upgrading (cvsup)? Edit some config files with senseful info? AFAIK it has to do something with acpi, doesn't it? -- Chris Christoph P. U. Kukulies kuku_at_physik.rwth-aachen.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fsck: CANNOT SEEK BLK: -1 (after changing the mainboard)
Quoting Alex Wilkinson [EMAIL PROTECTED]: On Fri, Nov 07, 2003 at 09:57:00PM +0200, [EMAIL PROTECTED] wrote: For reference this is what my AWARD BIOS reads: Capacity 120GB Access Mode Auto CHS LBALarge Cylinder.57460.5746014593.3830 Head1616..255..240 Precomp..0.000 Landing Zone.57459.57459.57459...57459 Sector.255...25563.255 Did you have to manually type this or did you use a utility to gather this table of info ? By hand. It seems to me that some Gigabyte MB (with extended fetures like SATA or RAID controlers - even when they're not used) report some other HDD geometry that the normal ones. I'll try today to test this if my supplier has got a new MB shipment. IOnut ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: taskqueue patch
I wasn't involved in converting taskqueue from 4.x-style SWIs to kernel threads so I can't be sure but this does look reasonable. I've been wondering about the 'not exiting' diagnostic from init for a while myself. On Mon, 2003-11-10 at 05:10, Alfred Perlstein wrote: I noticed that init was complaining about processes not exiting when doing a transition to single user mode. It appears that the problem is that the taskqueue kernel process is started with RFNOWAIT but doesn't respect orderly shutdown signs. Diff follows: Index: subr_taskqueue.c === RCS file: /home/ncvs/src/sys/kern/subr_taskqueue.c,v retrieving revision 1.19 diff -u -r1.19 subr_taskqueue.c --- subr_taskqueue.c 6 Sep 2003 21:05:18 - 1.19 +++ subr_taskqueue.c 10 Nov 2003 05:00:00 - @@ -271,7 +271,7 @@ TASKQUEUE_DEFINE(thread, taskqueue_thread_enqueue, 0, kthread_create(taskqueue_kthread, NULL, - taskqueue_thread_proc, RFNOWAIT, 0, taskqueue)); + taskqueue_thread_proc, 0, 0, taskqueue)); int taskqueue_enqueue_fast(struct taskqueue *queue, struct task *task) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
vm_fault on umass transfers
Hello, I've had an Olympus camera which I've been able to access under -CURRENT for some time until recently. I can mount_msdosfs the device (da0s1) OK, but when I try to copy or move files from the device to my hard disk drive I get the following kernel message: panic: mv_fault: fault on nofault entry, addr: dc346000 And then the system will start to shutdown and sync disks. Unfortunately I've been unable to boot with a generic kernel at this stage to see if there would be more information spat out. Thanks in advance -Al ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New EHCI device ID
On Mon, 10 Nov 2003 00:11:37 +0100 Bernd Walter [EMAIL PROTECTED] wrote: On Sun, Nov 09, 2003 at 11:56:19PM +0100, Pav Lucistnik wrote: It's that easy? Just adding device ID? I was under impression that you need to write/modify a driver for a new chip. Adding the ID is just beautifying the boot messages. EHCI controllers are all compatible (modulo bugs) from the software point of view. We have a problem then. Normally this is a headless system, but I had a mouse attached once and it caused a hard hang. Something with int 10 or too much interrupts or something like this (the mouse works on my desktop system and it works on the machine in question in Windows). When I test the new apic code on this system, I will attache a mouse again and report back. Bye, Alexander. -- One world, one web, one program -- Microsoft promotional ad Ein Volk, ein Reich, ein Fuehrer -- Adolf Hitler http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on i386/i386
TB --- 2003-11-10 07:41:03 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-10 07:41:03 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-11-10 07:41:03 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/i386 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-10 07:42:56 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-11-10 08:44:41 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Mon Nov 10 08:44:41 GMT 2003 Kernel build for GENERIC completed on Mon Nov 10 08:59:31 GMT 2003 TB --- 2003-11-10 08:59:31 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- /usr/bin/make -B LINT TB --- 2003-11-10 08:59:31 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Mon Nov 10 08:59:31 GMT 2003 [...] cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/i4b/layer3/i4b_q932fac.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/i4b/layer4/i4b_i4bdrv.c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/i4b/layer4/i4b_i4bdrv.c: In function `i4bputqueue': /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/i4b/layer4/i4b_i4bdrv.c:823: error: `TTIPRI' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/i4b/layer4/i4b_i4bdrv.c:823: error: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/i4b/layer4/i4b_i4bdrv.c:823: error: for each function it appears in.) /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/i4b/layer4/i4b_i4bdrv.c: In function `i4bputqueue_hipri': /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/i4b/layer4/i4b_i4bdrv.c:866: error: `TTIPRI' undeclared (first use in this function) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. TB --- 2003-11-10 09:07:48 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-11-10 09:07:48 - TB --- ERROR: failed to build lint kernel TB --- 2003-11-10 09:07:48 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Really no one knows ?!
Hi, A few days ago I've asked in this message: http://www.freebsd.org/cgi/getmsg.cgi? fetch=1728586+0+/usr/local/www/db/text/2003/freebsd-current/20031109. freebsd-current about suggestions of how to recover the non-root slices from a HDD after the change of the mainbord resulted in not finding the superblock, or at least how to avoid such things in the future. DES suggested You probably switched your disk from CHS to LBA mode or vice versa in this message: http://www.freebsd.org/cgi/getmsg.cgi? fetch=1815326+0+/usr/local/www/db/text/2003/freebsd-current/20031109. freebsd-current which it is not the case. Now, leaving apart that my lest backup dated a month ago, and it's really stupid to lost all your data from a HDD without suffering any hardware or software crash, I would really apreciate some ideas, links whatever about what it is to do to avoid this to happend if the future. Mannyt thanks, IOnut ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Really no one knows ?!
Now, leaving apart that my lest backup dated a month ago, and it's really stupid to lost all your data from a HDD without suffering any hardware or software crash, I would really apreciate some ideas, links whatever about what it is to do to avoid this to happend if the future. Just an idea. This occurred to me once that the superblock and primary alternate were corrupted. Hence i was in the same unfortunate situation as you, fsck was not working. The situation was solved by running newfs with the -N flag on the slice. This printed the location of other copies of the superblock. Feeding that to fsck allowed to recover the filesystem, without losing anything. -- Michel TALON ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: -0166: *** Error: UtAllocate: Attempt to alloc
You using a dell laptop? They got the broken acpi aml code. There is a patch out to fix it, its located here: http://sandcat.nl/~stijn/freebsd/dell.php seth C. Kukulies wrote: ...ate zero bytes The kernel message -0166: *** Error: UtAllocate: Attempt to allocate zero bytes -0166: *** Error: UtAllocate: Attempt to allocate zero bytes -0166: *** Error: UtAllocate: Attempt to allocate zero bytes -0166: *** Error: UtAllocate: Attempt to allocate zero bytes clobbers the screen in bursts during startup for quite some time now. I would like to ask if there is something I can do about it. Upgrading (cvsup)? Edit some config files with senseful info? AFAIK it has to do something with acpi, doesn't it? -- Chris Christoph P. U. Kukulies kuku_at_physik.rwth-aachen.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Really no one knows ?!
Quoting Putinas Piliponis [EMAIL PROTECTED]: some bioses thinks differently about geometry layout for harddisk It seems to me that some Gigabyte MB (with extended fetures like SATA or RAID controlers - even when they're not used) report some other HDD geometry that the normal ones. btw dont trust to much what it shows you in bios ... This days I tend to not trust anything :-/ The system was istalled on a Gigabyte GA-7VAXP (KT400/8235) and moved _without_any_problem_ on a Gigabyte GA-7VT600 1394 (KT600/8237). The HDD set in BIOS on auto and no custom newfs options. But on this new Gigabyte GA-7VT600L (KT600/8237) it just not working. Now, I'll lose some money due to a dead-line ... I'll do daylly back-ups in the future... This is just my desktop ... with mail, docs and work on it. It's fruntating to see the XP booting up with no problem and loosing all your BSD data ... But what if the same thing happends on one of my servers ? That's what really scares me. if you still have old mb - try to boot from that one, and see what is says and make same with new one ... [..] I would recommend to start from cd, and in sysinstall choose fdisk and after there is option to change / view disk geometry layout ... Yeh, If I was having it probably I wouldn't bother the list so much. But I don't have it. I now the G option, but I don't understand what your suggestion is. Could you please elaborate ? Still, suposing I'll get one MB from my supplier and see what geometry that mobo reports, what should I do to get the HDD working on the new mobo ? Thanks, IOnut ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on i386/pc98
TB --- 2003-11-10 09:07:50 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-10 09:07:50 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-11-10 09:07:50 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/pc98 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-10 09:10:16 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-11-10 10:08:22 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Mon Nov 10 10:08:22 GMT 2003 Kernel build for GENERIC completed on Mon Nov 10 10:20:37 GMT 2003 TB --- 2003-11-10 10:20:37 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src/sys/pc98/conf TB --- /usr/bin/make -B LINT TB --- 2003-11-10 10:20:37 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Mon Nov 10 10:20:37 GMT 2003 [...] cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/i4b/layer3/i4b_q932fac.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/i4b/layer4/i4b_i4bdrv.c /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/i4b/layer4/i4b_i4bdrv.c: In function `i4bputqueue': /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/i4b/layer4/i4b_i4bdrv.c:823: error: `TTIPRI' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/i4b/layer4/i4b_i4bdrv.c:823: error: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/i4b/layer4/i4b_i4bdrv.c:823: error: for each function it appears in.) /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/i4b/layer4/i4b_i4bdrv.c: In function `i4bputqueue_hipri': /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/i4b/layer4/i4b_i4bdrv.c:866: error: `TTIPRI' undeclared (first use in this function) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. TB --- 2003-11-10 10:27:22 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-11-10 10:27:22 - TB --- ERROR: failed to build lint kernel TB --- 2003-11-10 10:27:22 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: the PS/2 mouse problem
On Sat, 8 Nov 2003, Morten Johansen wrote:
Scott Long wrote:
Bruce Evans wrote:
[... possibly too much trimmed]
The problem here is that the keyboard controller driver tries to be too
smart. If it detects that the hardware FIFO is full, it'll drain it into
a per-softc, per-function ring buffer. So having psm(4) just directly
read the hardware is insufficient in this scheme.
What is the per-function part? (I'm not very familar with psm, but once
understood simpler versions of the keyboard driver.) Several layers of
buffering might not be too bad for slow devices. The i/o times tend to
dominate unless you do silly things like a context switch to move each
character from one buffer to other, and even that can be fast enough
(I believe it is normal for interactive input on ptys; then there's often
a remote IPC or two per character as well).
- it sometimes calls the DELAY() function, which is not permitted in fast
interrupt handlers since apart from locking issues, fast interrupt
handlers
are not permitted to busy-wait.
Again, the keyboard controller driver is too smart for its own good. To
summarize:
read_aux_data_no_wait()
{
Does softc-aux ring buffer contain data?
return ring buffer data
Check the status register
Is the keyboard fifo full?
DELAY(7us)
read keyboard fifo into softc-kbd ring buffer
Check the status register
Is the aux fifo full?
DELAY(7us)
return aux fifo data
}
So you can wind up stalling for 14us in there, presumably because you
cannot read the status and data registers back-to-back without a delay.
I don't have the atkbd spec handy so I'm not sure how to optimize this.
Do you really need to check the status register before reading the data
register?
At least it's a bounded delay. I believe such delays are required for
some layers of the keyboard. Perhaps only for the keyboard (old hardware
only?) and not for the keyboard controller or the mouse.
Many of the complications for fast interrupt handlers shouldn't be needed
in psm. Just make psmintr() INTR_MPSAFE.
I believe that the previous poster actually tried making it INTR_MPSAFE,
but didn't see a measurable benefit because the latency of scheduling
the ithread is still unacceptable.
That is 100% correct.
In the meantime I have taken your's and Bruce's advice and rearranged
the interrupt handler to look like this:
mtx_lock(sc-input_mtx);
Er, this is reasonable for INTR_MPSAFE but not for INTR_FAST.
mtx_lock() is a sleep lock so it cannot be used in fast interrupt
handlers. mtx_lock_spin() must be used. (My version doesn't permit
use of mtx_lock_spin() either; more primitive locking must be used.)
while((c = read_aux_data_no_wait(sc-kbdc)) != -1) {
This is probably INTR_FAST-safe enough in practice.
sc-input_queue.buf[sc-input_queue.tail] = c;
if ((++ sc-input_queue.tail) = PSM_BUFSIZE)
sc-input_queue.tail = 0;
count = (++ sc-input_queue.count);
}
mtx_unlock(sc-input_mtx);
The locking for the queue seems to be correct except this should operate
on a spinlock too.
if (count = sc-mode.packetsize)
taskqueue_enqueue(taskqueue_swi_giant, sc-psm_task);
taskqueue_enqueue() can only be used in non-fast interrupt handlers.
taskqueue_enqueue_fast() must be used in fast interrupt handlers (except
in my version, it is not permitted so it shouldn't exist). Note that
the spinlock/fast versions can be used for normal interrupt handlers
too, so not much more code is needed to support handlers whose fastness
is dynamically configured.
And it works, but having it INTR_MPSAFE still does NOT help my problem.
It looks to me like data is getting lost because the interrupt handler
is unable to read it before it's gone, and the driver gets out of sync,
and has to reset itself.
However it now takes a few more tries to provoke the problem, so
something seems to have improved somewhere.
This is a bit surprising. There are still so few INTR_MPSAFE handlers
that there aren't many system activities that get in the way of running
the INTR_MPSAFE ones. Shared interrupts prevent running of a handler
while other handlers on the same interrupt are running, and the mouse
interrupt is often shared, but if it is shared then it couldn't be fast
until recently and still can't be fast unless all the other handlers on
it are fast.
Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ALTQ support
On Mon, 10 Nov 2003 13:56:19 +0800 Michael Lee [EMAIL PROTECTED] wrote: I know it depends on the way the core team members see it. It doesn't. If someone with enough knowledge in the relevant source tree parts is willing to import it, he is free to do it. Is there any plan to make it into the kernel ? AFAIK the author of ALTQ said we shouldn't import it. Search the mailing lists @FreeBSD.org for the reason. Bye, Alexander. -- The dark ages were caused by the Y1K problem. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ALTQ support
On (2003/11/10 11:35), Alexander Leidinger wrote: Is there any plan to make it into the kernel ? AFAIK the author of ALTQ said we shouldn't import it. Search the mailing lists @FreeBSD.org for the reason. If anyone finds that message in the archives, please post a URL. I can't find it in -current or -arch, and I'd really like to know what the motivation was. Thanks, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd core dumped
I will rpc.lockd with -ggdb as you said and see if it is repeatable. Unfortunately, I'm not home right now, so I'll do this in 3 o 4 days. Regards. Antoine ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd core dumped
Check to make sure that rpc.statd is running. There was an old bug that rpc.lockd would dump core if it couldn't find a statd. Ho, it is running :) Actually, all my homedir are mounted with NFS, so rpc.lockd get used a lot. That is why it is an important concern to me. I couldn't find any repeatable behaviour that would make rpc.lockd crashes. Sometimes, it will crash when I launch an application, sometime, it will just crash after 30 minutes of inactivities on my client... The server is running CURRENT and the clients are running 5.1-p10. I know it is not a very stable/secure configuration, but it is done on purpuse of testing the new functionnalities under a semi-production environment. Antoine ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Bumping netgraph name sizes
Hi all, after some discussion among people working on netgraph (julian, archie, ru, brooks, emax and harti) it was decided that we need to bump several constants that define the size of names (node, hook, command string names) in netgraph because they turn out to be too short for several applications that need longer names. This change breaks the current netgraph ABI in the sense, that user programs and the kernel must be in sync and that externally maintained netgraph nodes and programs must be recompiled. Otherwise the functioning of netgraph should be unaffected (still some testing going on). We want to have this change in the tree before 5.2 for exactly this reason. If anybody has a reason why this would be a bad idea (and break something) we would like to hear that now. Attached is the corresponding patch. Regards, harti Index: sys/netgraph/ng_message.h === RCS file: /export/cvs/freebsd/src/sys/netgraph/ng_message.h,v retrieving revision 1.18 diff -u -r1.18 ng_message.h --- sys/netgraph/ng_message.h 22 Oct 2003 07:35:05 - 1.18 +++ sys/netgraph/ng_message.h 10 Nov 2003 11:04:07 - @@ -44,11 +44,21 @@ #define _NETGRAPH_NG_MESSAGE_H_ 1 /* ASCII string size limits */ -#define NG_TYPELEN 15 /* max type name len (16 with null) */ -#define NG_HOOKLEN 15 /* max hook name len (16 with null) */ -#define NG_NODELEN 15 /* max node name len (16 with null) */ -#define NG_PATHLEN 511 /* max path len (512 with null) */ -#define NG_CMDSTRLEN 15 /* max command string (16 with null) */ +#defineNG_TYPESIZ 32 /* max type name len (including null) */ +#defineNG_HOOKSIZ 32 /* max hook name len (including null) */ +#defineNG_NODESIZ 32 /* max node name len (including null) */ +#defineNG_PATHSIZ 512 /* max path len (including null) */ +#defineNG_CMDSTRSIZ32 /* max command string (including null) */ + +/* #ifndef BURN_BRIDGES */ +/* don't use these - they will go away */ +#define NG_TYPELEN (NG_TYPESIZ - 1) +#define NG_HOOKLEN (NG_HOOKSIZ - 1) +#define NG_NODELEN (NG_NODESIZ - 1) +#define NG_PATHLEN (NG_PATHSIZ - 1) +#define NG_CMDSTRLEN (NG_CMDSTRSIZ - 1) +/* #endif */ + #define NG_TEXTRESPONSE 1024 /* allow this length for a text response */ /* A netgraph message */ Index: sys/netgraph/netgraph.h === RCS file: /export/cvs/freebsd/src/sys/netgraph/netgraph.h,v retrieving revision 1.35 diff -u -r1.35 netgraph.h --- sys/netgraph/netgraph.h 22 Aug 2002 00:30:03 - 1.35 +++ sys/netgraph/netgraph.h 10 Nov 2003 11:04:07 - @@ -62,7 +62,7 @@ * Change it for NETGRAPH_DEBUG version so we cannot mix debug and non debug * modules. */ -#define _NG_ABI_VERSION 6 +#define _NG_ABI_VERSION 7 #ifdef NETGRAPH_DEBUG /*--*/ #define NG_ABI_VERSION (_NG_ABI_VERSION + 0x1) #else /* NETGRAPH_DEBUG */ /*--*/ -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[no subject]
Quoting Michel TALON [EMAIL PROTECTED]: Just an idea. This occurred to me once that the superblock and primary alternate were corrupted. Hence i was in the same unfortunate situation as you, fsck was not working. The situation was solved by running newfs with the -N flag on the slice. This printed the location of other copies of the superblock. Feeding that to fsck allowed to recover the filesystem, without losing anything. Booted from the Fixit disk. On the /temp: Fixit# newfs -N ad0s2d /dev/ad0s2d: 512.0MB (1048576 sectors) block size 16384, fragment size 2048using 4 cylinder groups of 128.02MB, 8193 blks, 16448 inodes. super-block backups (for fsck -b #) at: 160, 262336, 524512, 786688 Fixit# fsck_ufs -b 262336 -n ad0s2d Alternate super block location: 262336 ** /dev/ad0s2d (NO WRITE) 262336 is not a system superblock. Same with 160, 262336, 524512, 786688 On the /, which when booting from the harddisk and fsck-ing is OK ???: Fixit# newfs -N ad0s2a /dev/ad0s2a: 256.0MB (524288 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 64.02MB, 4097 blks, 8256 inodes. super-block backups (for fsck -b #) at: 160, 131264, 262368, 393472 Fixit# fsck_ufs -b 160 -n ad0s2a Alternate super block location: 160 ** /dev/ad0s2a (NO WRITE) ** Last Mounted on ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups SUMMARY BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? no 2123 files, 37012 used, 126839 free (7 frags, 15854 blocks, 0.0% fragmentation) Fixit# newfs -N ad0s2 /dev/ad0s2: 84474.6MB (173003984 sectors) block size 16384, fragment size 2048 using 460 cylinder groups of 183.77MB, 11761 blks, 23552 inodes.super-block backups (for fsck -b #) at: 160, 376512, 752864, 1129216, 1505568, 1881920, 2258272, 2634624, 3010976, 3387328, 3763680, 4140032, 4516384, 4892736, 5269088, 5645440, 6021792, 6398144, 6774496, 7150848, 7527200, 7903552, 8279904, 8656256, 9032608, 9408960, 9785312, 10161664, 10538016, 10914368, 11290720, 11667072, 12043424, 12419776, 12796128, 13172480, 13548832, 13925184, 14301536, 14677888, 15054240, 15430592, 15806944, 16183296, 16559648, 16936000, 17312352, 17688704, 18065056, 18441408, 18817760, 19194112, 19570464, 19946816, 20323168, 20699520, 21075872, 21452224, 21828576, 22204928, 22581280, 22957632, 2984, 23710336, 24086688, 24463040, 24839392, 25215744, 25592096, 25968448, 26344800, 26721152, 27097504, 27473856, 27850208, 28226560, 28602912, 28979264, 29355616, 29731968, 30108320, 30484672, 30861024, 31237376, 31613728, 31990080, 32366432, 32742784, 33119136, 33495488, 33871840, 34248192, 34624544, 35000896, 35377248, 35753600, 36129952, 36506304, 36882656, 37259008, 37635360, 38011712, 38388064, 38764416, 39140768, 39517120, 39893472, 40269824, 40646176, 41022528, 41398880, 41775232, 42151584, 42527936, 42904288, 43280640, 43656992, 44033344, 44409696, 44786048, 45162400, 45538752, 45915104, 46291456, 46667808, 47044160, 47420512, 47796864, 48173216, 48549568, 48925920, 49302272, 49678624, 50054976, 50431328, 50807680, 51184032, 51560384, 51936736, 52313088, 52689440, 53065792, 53442144, 53818496, 54194848, 54571200, 54947552, 55323904, 55700256, 56076608, 56452960, 56829312, 57205664, 57582016, 57958368, 58334720, 58711072, 59087424, 59463776, 59840128, 60216480, 60592832, 60969184, 61345536, 61721888, 62098240, 62474592, 62850944, 63227296, 63603648, 6398, 64356352, 64732704, 65109056, 65485408, 65861760, 66238112, 66614464, 66990816, 67367168, 67743520, 68119872, 68496224, 68872576, 69248928, 69625280, 70001632, 70377984, 70754336, 71130688, 71507040, 71883392, 72259744, 72636096, 73012448, 73388800, 73765152, 74141504, 74517856, 74894208, 75270560, 75646912, 76023264, 76399616, 76775968, 77152320, 77528672, 77905024, 78281376, 78657728, 79034080, 79410432, 79786784, 80163136, 80539488, 80915840, 81292192, 81668544, 82044896, 82421248, 82797600, 83173952, 83550304, 83926656, 84303008, 84679360, 85055712, 85432064, 85808416, 86184768, 86561120, 86937472, 87313824, 87690176, 88066528, 88442880, 88819232, 89195584, 89571936, 89948288, 90324640, 90700992, 91077344, 91453696, 91830048, 92206400, 92582752, 92959104, 93335456, 93711808, 94088160, 94464512, 94840864, 95217216, 95593568, 95969920, 96346272, 96722624, 97098976, 97475328, 97851680, 98228032, 98604384, 98980736, 99357088, 99733440, 100109792, 100486144, 100862496, 101238848, 101615200, 101991552, 102367904, 102744256, 103120608, 103496960, 103873312, 104249664, 104626016, 105002368, 105378720, 105755072, 106131424, 106507776, 106884128, 107260480, 107636832, 108013184, 108389536, 108765888, 109142240, 109518592, 109894944, 110271296, 110647648, 111024000, 111400352, 111776704, 112153056, 112529408, 112905760, 113282112, 113658464, 114034816, 114411168, 114787520, 115163872, 115540224, 115916576, 116292928, 116669280, 117045632,
Re: Really no one knows ?!
- Forwarded message from [EMAIL PROTECTED] - Date: Mon, 10 Nov 2003 13:29:39 +0200 From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Michel TALON [EMAIL PROTECTED] Quoting Michel TALON [EMAIL PROTECTED]: Just an idea. This occurred to me once that the superblock and primary alternate were corrupted. Hence i was in the same unfortunate situation as you, fsck was not working. The situation was solved by running newfs with the -N flag on the slice. This printed the location of other copies of the superblock. Feeding that to fsck allowed to recover the filesystem, without losing anything. Booted from the Fixit disk. On the /temp: Fixit# newfs -N ad0s2d /dev/ad0s2d: 512.0MB (1048576 sectors) block size 16384, fragment size 2048using 4 cylinder groups of 128.02MB, 8193 blks, 16448 inodes. super-block backups (for fsck -b #) at: 160, 262336, 524512, 786688 Fixit# fsck_ufs -b 262336 -n ad0s2d Alternate super block location: 262336 ** /dev/ad0s2d (NO WRITE) 262336 is not a system superblock. Same with 160, 262336, 524512, 786688 On the /, which when booting from the harddisk and fsck-ing is OK ???: Fixit# newfs -N ad0s2a /dev/ad0s2a: 256.0MB (524288 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 64.02MB, 4097 blks, 8256 inodes. super-block backups (for fsck -b #) at: 160, 131264, 262368, 393472 Fixit# fsck_ufs -b 160 -n ad0s2a Alternate super block location: 160 ** /dev/ad0s2a (NO WRITE) ** Last Mounted on ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups SUMMARY BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? no 2123 files, 37012 used, 126839 free (7 frags, 15854 blocks, 0.0% fragmentation) Fixit# newfs -N ad0s2 /dev/ad0s2: 84474.6MB (173003984 sectors) block size 16384, fragment size 2048 using 460 cylinder groups of 183.77MB, 11761 blks, 23552 inodes.super-block backups (for fsck -b #) at: 160, 376512, 752864, 1129216, 1505568, 1881920, 2258272, 2634624, 3010976, 3387328, 3763680, 4140032, 4516384, 4892736, 5269088, 5645440, 6021792, 6398144, 6774496, 7150848, 7527200, 7903552, 8279904, 8656256, 9032608, 9408960, 9785312, 10161664, 10538016, 10914368, 11290720, 11667072, 12043424, 12419776, 12796128, 13172480, 13548832, 13925184, 14301536, 14677888, 15054240, 15430592, 15806944, 16183296, 16559648, 16936000, 17312352, 17688704, 18065056, 18441408, 18817760, 19194112, 19570464, 19946816, 20323168, 20699520, 21075872, 21452224, 21828576, 22204928, 22581280, 22957632, 2984, 23710336, 24086688, 24463040, 24839392, 25215744, 25592096, 25968448, 26344800, 26721152, 27097504, 27473856, 27850208, 28226560, 28602912, 28979264, 29355616, 29731968, 30108320, 30484672, 30861024, 31237376, 31613728, 31990080, 32366432, 32742784, 33119136, 33495488, 33871840, 34248192, 34624544, 35000896, 35377248, 35753600, 36129952, 36506304, 36882656, 37259008, 37635360, 38011712, 38388064, 38764416, 39140768, 39517120, 39893472, 40269824, 40646176, 41022528, 41398880, 41775232, 42151584, 42527936, 42904288, 43280640, 43656992, 44033344, 44409696, 44786048, 45162400, 45538752, 45915104, 46291456, 46667808, 47044160, 47420512, 47796864, 48173216, 48549568, 48925920, 49302272, 49678624, 50054976, 50431328, 50807680, 51184032, 51560384, 51936736, 52313088, 52689440, 53065792, 53442144, 53818496, 54194848, 54571200, 54947552, 55323904, 55700256, 56076608, 56452960, 56829312, 57205664, 57582016, 57958368, 58334720, 58711072, 59087424, 59463776, 59840128, 60216480, 60592832, 60969184, 61345536, 61721888, 62098240, 62474592, 62850944, 63227296, 63603648, 6398, 64356352, 64732704, 65109056, 65485408, 65861760, 66238112, 66614464, 66990816, 67367168, 67743520, 68119872, 68496224, 68872576, 69248928, 69625280, 70001632, 70377984, 70754336, 71130688, 71507040, 71883392, 72259744, 72636096, 73012448, 73388800, 73765152, 74141504, 74517856, 74894208, 75270560, 75646912, 76023264, 76399616, 76775968, 77152320, 77528672, 77905024, 78281376, 78657728, 79034080, 79410432, 79786784, 80163136, 80539488, 80915840, 81292192, 81668544, 82044896, 82421248, 82797600, 83173952, 83550304, 83926656, 84303008, 84679360, 85055712, 85432064, 85808416, 86184768, 86561120, 86937472, 87313824, 87690176, 88066528, 88442880, 88819232, 89195584, 89571936, 89948288, 90324640, 90700992, 91077344, 91453696, 91830048, 92206400, 92582752, 92959104, 93335456, 93711808, 94088160, 94464512, 94840864, 95217216, 95593568, 95969920, 96346272, 96722624, 97098976, 97475328, 97851680, 98228032, 98604384, 98980736, 99357088, 99733440, 100109792, 100486144, 100862496, 101238848, 101615200, 101991552, 102367904, 102744256, 103120608, 103496960, 103873312, 104249664, 104626016, 105002368, 105378720, 105755072, 106131424, 106507776, 106884128, 107260480, 107636832, 108013184, 108389536, 108765888, 109142240, 109518592, 109894944, 110271296, 110647648,
LOR message from crashdump?
Hi, I tried researching this one but couldn't find an answer in the FM... When I get panics, I end up in DDB; then I just type `call doadump' and reboot. When I load such a dump in gdb -k, I usually get the panic message, like this: This GDB was configured as i386-undermydesk-freebsd... panic: vm_page_dirty: page is free! panic messages: --- panic: vm_page_dirty: page is free! Dumping 191 MB 16 32 48 64 80 96 112 128 144 160 176 --- Reading symbols from /boot/kernel/if_wi.ko...done. Loaded symbols for /boot/kernel/if_wi.ko ... This is not happening with a LOR, i.e. I only get: This GDB was configured as i386-undermydesk-freebsd... panic messages: --- --- Reading symbols from /boot/kernel/if_wi.ko...done. Loaded symbols for /boot/kernel/if_wi.ko ... Is this normal or my fault? Is there a way to retrieve the LOR message? I thought it was a new one, but didn't write it down, so now I have a useless crashdump... :( Bye, Andrea -- One world, one web, one program -- Microsoft promotional ad Ein Volk, ein Reich, ein Fuehrer -- Adolf Hitler ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tcp hostcache and ip fastforward for review
On Sun, 9 Nov 2003, Andre Oppermann wrote: Hello all, this patch contains three things (to be separated for committing): I don't have much time free in the next week, so I cannot do a complete review. However, I just did a quick readthrough. tcp_hostcache This looks good to me, I've been waiting for you to finish it for a long time. You actually missed a point: - Ensures that a cached entry isn't added until the 3WHS is completed. This should help make synfloods with random source addresses less damaging. Would it be possible to provide a way for netstat to view the host cache table? I think that it would be useful. ip_fastforward No comment, I didn't read through this part, and I'm not familiar with the forwarding code. tcp bug fixes and MSS DoS attack prevention Generally good, but: - adds tcp_minmssoverload which disconnects a TCP session if it receives too many (1000) packets per second whose average segement size is lower than tcp_minmss - DoS attack 2: make MSS very low on local side of connection and send mny small packet to remote host. For every packet (eg. 2 bytes payload) a sowakeup is done to the listening process. Consumes a lot of CPU there. I don't think that your patch for this really solves anything. Anyone who would write such a program could just as easily make it use concurrent connections, have it auto-reconnect, and/or have it only send 900 packets per second. I think that you should remove this section of the patch, but leave a comment about this problem existing so that it will be thought more about in the future. After the rest of the code is in, we can brainstorm on other possible solutions... I think that Mini's idea of approaching it as an optimization is the correct one. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tcp hostcache and ip fastforward for review
Jonathan Mini wrote: On Nov 9, 2003, at 2:47 PM, Andre Oppermann wrote: Jonathan Mini wrote: On Nov 9, 2003, at 8:19 AM, Andre Oppermann wrote: - DoS attack 2: make MSS very low on local side of connection and send mny small packet to remote host. For every packet (eg. 2 bytes payload) a sowakeup is done to the listening process. Consumes a lot of CPU there. This sounds as if it might be worthwhile to add a delay to the TF_NODELAY case for receive processing as well. Unfortunatly it is not that easy. We can't just do that unconditionally to all connections. It would probably break or delay many things. You never know how much data is outstanding and whether it's just this packet with 2 bytes outstanding... This would be disastrous to the performance of interactive sockets, however theoretically those connections have NODELAY set. My above comment is a bit confusing: I meant the non TF_NODELAY case, that is when Nagling is enabled. In this situation, you would be delay an sowakeup until either a timeout or SO_RCVLOWAT-set value was reached. The normal SO_RCVLOWAT case delays until SO_RCVTIMEO is reached. I suppose the application could simulate this with a large SO_RCVLOWAT and a small SO_RCVTIMEO, but I was wondering about the effects of such a change as part of !TF_NODELAY. To do this we need another callout to do the eventual wakeup if no further packet arrive within whatever/HZ. In addition it probably would make FreeBSD look bad in network benchmarks since this causes the connection RTT to go up. All in all I don't think it is worth adding this complexity. Sadly, there's this PSH bit in the TCP header that's completely unreliable and could be used for scenarios like this. As an application aware of this problematic you have currently two options: use accept filters (FreeBSD only) or set SO_RCVLOWAT to some higher value than the default 1 byte. Only the first one is workable if you don't know what and how much the clients send to you. Relying on the application to activate any such option to prevent this kind of DoS is unfortunatly whishful thinking. I was not suggesting that we use this to counter an attack, only asking if it might be a worthwhile performance optimization to consider. This is an unlikely case (many small packets sent to a non-interactive application), so I can't see the improvement as being globally useful. No, I don't think it is a worthwhile opimization. If the application wants to do it, it can do so already via socket options. Normally an application needs such a delay feature to be specific to it's message types. Like with http accept filter. The code I've put in here simply caps off the extreme cases. It counts all packets and bytes in any given second and computes the average payload size per packet. If that is less than we have defined for minmss it will reset and drop the connection. However it will only start to compute the average if there are more than 1'000 packets per second on the same tcp connection. I've chosen this quite high value to never disconnect any ligitimate connection which just happens to send many small packets. In my tests I've seen telnet/ssh sending close to 100 small packets per second (some large copy-pasting and cat'ing of many small files). Probably 500 packets per second is a better cut-off value but I just want to be sure to never hit a false positive. This is actually a small value for TCP connections which are being used to forward messages, especially on gigabit links. Heavily-intensive web applications that are using small HTTP requests (pipelined inside a persistent connection) to update small manipulations of state are a good example of this. I wouldn't be surprised to see chatter between SQL servers follow similar patterns. Applications which use XML-based messaging often send several small packets per message, which is unfortunate. Do you think such applications manage to send 1000 packets per second with less than 256 bytes payload per packet? I think the network code would collect some data to form a larger packet (unless TCP_NODELAY set)? On the other hand, I'm used to looking at proxies, which are not the general case. This is why the limits are tunable, after all. =) Is there way you could monitor such connections and compile some statistics how many small packets per second are sent? I could adjust the patch to just report the fact instead of dropping the connection. Could do it for 4.9-R too, it's fairly easy. -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tcp hostcache and ip fastforward for review
Mike Silbersack wrote: On Sun, 9 Nov 2003, Andre Oppermann wrote: Hello all, this patch contains three things (to be separated for committing): I don't have much time free in the next week, so I cannot do a complete review. However, I just did a quick readthrough. tcp_hostcache This looks good to me, I've been waiting for you to finish it for a long time. You actually missed a point: - Ensures that a cached entry isn't added until the 3WHS is completed. This should help make synfloods with random source addresses less damaging. The cache will only be updated if the tcp connection is being closed. All updates are done in tcp_drop. The T/TCP updates have to be done inline during connection setup. I've converted all places which updated the T/TCP rtmetrics in routing table with updates to the hostcache. Would it be possible to provide a way for netstat to view the host cache table? I think that it would be useful. At the moment is visible via sysctl -a net.inet.tcp.hostcache.list. Syncache ain't visible via netstat either. So far you had to use route get x.x.x.x to see the rtmetrics for a (host-)route. So I'm sure whether netstat is the right place for it. But I can do that in a second step. ip_fastforward No comment, I didn't read through this part, and I'm not familiar with the forwarding code. tcp bug fixes and MSS DoS attack prevention Generally good, but: - adds tcp_minmssoverload which disconnects a TCP session if it receives too many (1000) packets per second whose average segement size is lower than tcp_minmss - DoS attack 2: make MSS very low on local side of connection and send mny small packet to remote host. For every packet (eg. 2 bytes payload) a sowakeup is done to the listening process. Consumes a lot of CPU there. I don't think that your patch for this really solves anything. Anyone who would write such a program could just as easily make it use concurrent connections, have it auto-reconnect, and/or have it only send 900 packets per second. I think that you should remove this section of the patch, but leave a comment about this problem existing so that it will be thought more about in the future. The actually solves the problem. Let me explain in more detail. When we get so many small packets per second the CPU will become pretty saturated. Depending on how much data is sent it can go on for minutes or hours. This code jumps in there and disconnects the within a second. Of course someone can immediatly reconnect and do it again. But that needs the 3WHS again and gives some delay. In the end this code is like the ICMP rate limiter code. It there to migitate a problem to manageable level, not to make it go away. After the rest of the code is in, we can brainstorm on other possible solutions... I think that Mini's idea of approaching it as an optimization is the correct one. Ok, for brainstorming. For Mini's idea see my answer to him. -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tcp hostcache and ip fastforward for review
On Nov 10, 2003, at 1:39 AM, Andre Oppermann wrote: Jonathan Mini wrote: All in all I don't think it is worth adding this complexity. I agree. This is actually a small value for TCP connections which are being used to forward messages, especially on gigabit links. Heavily-intensive web applications that are using small HTTP requests (pipelined inside a persistent connection) to update small manipulations of state are a good example of this. I wouldn't be surprised to see chatter between SQL servers follow similar patterns. Applications which use XML-based messaging often send several small packets per message, which is unfortunate. Do you think such applications manage to send 1000 packets per second with less than 256 bytes payload per packet? I think the network code would collect some data to form a larger packet (unless TCP_NODELAY set)? Traffic like that only happens when TCP_NODELAY is set. Otherwise, you get what you would expect. On the other hand, I'm used to looking at proxies, which are not the general case. This is why the limits are tunable, after all. =) Is there way you could monitor such connections and compile some statistics how many small packets per second are sent? I could adjust the patch to just report the fact instead of dropping the connection. Could do it for 4.9-R too, it's fairly easy. Alas, no. This is from anecdotal experience from our support staff at work. -- Jonathan Mini [EMAIL PROTECTED] http://www.freebsd.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: vm_page_dirty: page is free!
Hi,
my laptop just paniced with this message. I looked in the archives
but didn't find it. Here it is in case it's interesting; I don't
know if any more details are needed.
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:240
#1 0xc04604b5 in db_fncall (dummy1=0, dummy2=0, dummy3=0, dummy4=0xcc3b284c à¸jÀ)
at ../../../ddb/db_command.c:548
#2 0xc0460202 in db_command (last_cmdp=0xc06aaf80, cmd_table=0x0,
aux_cmd_tablep=0xc067df24,
aux_cmd_tablep_end=0xc067df28) at ../../../ddb/db_command.c:346
#3 0xc0460345 in db_command_loop () at ../../../ddb/db_command.c:472
#4 0xc0463345 in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:73
#5 0xc060eedc in kdb_trap (type=3, code=0, regs=0xcc3b29a0)
at ../../../i386/i386/db_interface.c:171
#6 0xc06223ea in trap (frame=
{tf_fs = 24, tf_es = -868548592, tf_ds = -103920, tf_edi = 1, tf_esi =
-1066974976, tf_ebp
= -868537876, tf_isp = -868537908, tf_ebx = 0, tf_edx = 0, tf_ecx = -1066357025,
tf_eax = 18, tf_tr
apno = 3, tf_err = 0, tf_eip = -1067388524, tf_cs = 8, tf_eflags = 658, tf_esp =
-1066962079, tf_ss
= -1067035201}) at ../../../i386/i386/trap.c:580
#7 0xc0610898 in calltrap () at {standard input}:94
#8 0xc04ff055 in panic (fmt=0xc0674100 vm_page_dirty: page is free!)
at ../../../kern/kern_shutdown.c:534
#9 0xc05d62dc in vm_page_dirty (m=0x0) at ../../../vm/vm_page.c:446
#10 0xc061e6ac in pmap_remove_pte (pmap=0xc070ede0, ptq=0x0, va=3394740224)
at ../../../i386/i386/pmap.c:1595
#11 0xc061e86c in pmap_remove (pmap=0xc070ede0, sva=3394740224, eva=3394809856)
at ../../../i386/i386/pmap.c:1696
#12 0xc05cf454 in vm_map_delete (map=0xc0c250b0, start=3233960112, end=3394809856)
at ../../../vm/vm_map.c:
#13 0xc05cc00f in kmem_free_wakeup (map=0xc0c250b0, addr=3394740224, size=0)
at ../../../vm/vm_kern.c:506
#14 0xc04e5ddd in kern_execve (td=0xc23fd3c0, fname=---Can't read userspace from dump,
or kernel pro
cess---
) at ../../../kern/kern_exec.c:632
#15 0xc04e5f70 in execve (td=0x0, uap=0x0) at ../../../kern/kern_exec.c:695
#16 0xc0622d50 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 0, tf_ebp = 0, tf_isp
= 0, tf_ebx =
0, tf_edx = 0, tf_ecx = 0, tf_eax = 0, tf_trapno = 0, tf_err = 0, tf_eip = 671453648,
tf_cs = 31, tf
_eflags = 514, tf_esp = -1077940676, tf_ss = 47}) at ../../../i386/i386/trap.c:1010
Bye,
Andrea
--
The computer revolution is over. The computers won.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ALTQ support
Monday, November 10, 2003, 5:29:34 AM, you wrote: ML I am looking for a solution to make QoS possible on my FreeBSD box. After ML searching for the internet, I found that there is a software called ALTQ ML that can do possibly what I want. However, I found that it is still not ML directly built into the kernel. Those who want to use it need to patch the ML kernel themselves. ML http://www.rofug.ro/projects/freebsd-altq/ The problem right now is the ongoing work in the network stack, which makes it really hard to produce a stable altq patchset. Hence the latest version from rofug is for 4.9 (which is/will be part of kame?). The 5.x stuff from rofug is afaik rather unstable and unmaintained. The nipsi.de stuff for 5.1R is okay, but lacks the userland parts, as it was done to give ALTQ functionality to pf, not to build a stand- alone ALTQ. On another sidenote, stand-alone ALTQ is a pain, imo. ML I wonder if any of the core team members has the plan to build it into the ML kernel since I was told that it is not a good way to patch the kernel ML myself. ( for the system stability concern. ) If you have a stable patchset against a stable release, there is no disadvantage (apart from having to patch). The problem is, that it is hard to maintain such stuff outside the source tree. From my talks with a core member, I believe that - once the netcode is a bit settled down - there will be a chance of getting ALTQ in. However, this will not happen before 5.2R. You can help by reporting your experience to the authors of the patchset you are using! -- Best regards, Maxmailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ALTQ support
On Mon, Nov 10, 2003 at 12:49:00PM +0200, Sheldon Hearn wrote: On (2003/11/10 11:35), Alexander Leidinger wrote: Is there any plan to make it into the kernel ? AFAIK the author of ALTQ said we shouldn't import it. Search the mailing lists @FreeBSD.org for the reason. If anyone finds that message in the archives, please post a URL. I can't find it in -current or -arch, and I'd really like to know what the motivation was. the author of altq itself or the author of the freebsd port? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New EHCI device ID
On Mon, Nov 10, 2003 at 10:03:20AM +0100, Alexander Leidinger wrote: On Mon, 10 Nov 2003 00:11:37 +0100 Bernd Walter [EMAIL PROTECTED] wrote: On Sun, Nov 09, 2003 at 11:56:19PM +0100, Pav Lucistnik wrote: It's that easy? Just adding device ID? I was under impression that you need to write/modify a driver for a new chip. Adding the ID is just beautifying the boot messages. EHCI controllers are all compatible (modulo bugs) from the software point of view. We have a problem then. Normally this is a headless system, but I had a mouse attached once and it caused a hard hang. Something with int 10 or too much interrupts or something like this (the mouse works on my desktop system and it works on the machine in question in Windows). When I test the new apic code on this system, I will attache a mouse again and report back. I really doubt that you have a high speed mouse. EHCI only supports high speed devices itself. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on sparc64/sparc64
TB --- 2003-11-10 12:10:59 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-10 12:10:59 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-11-10 12:10:59 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-10 12:13:27 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/bsnmp/snmp_mibII/mibII.h:57:18: asn1.h: No such file or directory /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/bsnmp/snmp_mibII/mibII.h:58:18: snmp.h: No such file or directory /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/bsnmp/snmp_mibII/mibII.h:59:21: snmpmod.h: No such file or directory In file included from /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/bsnmp/snmp_mibII/mibII_route.c:37: /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/bsnmp/snmp_mibII/mibII.h:57:18: asn1.h: No such file or directory /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/bsnmp/snmp_mibII/mibII.h:58:18: snmp.h: No such file or directory /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/bsnmp/snmp_mibII/mibII.h:59:21: snmpmod.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libbsnmp/modules/snmp_mibII. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libbsnmp/modules. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libbsnmp. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-11-10 12:37:37 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-11-10 12:37:37 - TB --- ERROR: failed to build world TB --- 2003-11-10 12:37:37 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
New interrupt code lock up hard with start of X window
Hi John and all,
After update of the new interrupt code into -current, my system
almost always lock up hard, when trying to start X Window up using
the startx command.
-current of as of Nov 4, before the new interrupt update, works
just fine.
I've included the 'dmesg -v' output, as attachement dmesg_full.txt.gz.uu,
and config-file, as attachement NEWJKPC11.
Any help appricated.
Thank you,
Haro
=--
_ _Munehiro (haro) Matsuda
-|- /_\ |_|_| Internet Solution Dept., Kubota Graphics Technologies Inc.
/|\ |_| |_|_| 2-8-8 Shinjuku Shinjuku-ku Tokyo 160-0022, Japan
Tel: +81-3-3225-0767 Fax: +81-3-3225-0740
Email: [EMAIL PROTECTED]
begin 644 dmesg_full.txt.gz
M'XL(`2#KS\``V1M97-G7V9U;PN='AT`.P\_7/;MI(_AW_%3NYCK#G)!DA*
MI'1QYF393O4:VSK+:7.OK^.A2-!B39$L23E6__K;!4B*DD5;9O.O;DJMDP
MNPOL8K$?^,@H3E9I#?/X!M`_W]8[.F`$WP'GJ1`GTU.8I/$OPLT/M=$6
ML-5OX[?-Y+AOWORVY;?LK;/Y;NOR5,W]3$/EK2B/(/8AQQ?/[EMAIL PROTECTED]
M(%]1R@)`S].H\`YA[EMAIL PROTECTED]@U1D(GT0WJ%6=JY[R#NC3]?79YW\[EMAIL PROTECTED]
MX@@[EMAIL PROTECTED]'0^8-:[EMAIL PROTECTED])X__ZY3YQ.3_,\\/[N_S0C0]_209'
[EMAIL PROTECTED],NW?DQHLD,71Y=F/?_M^,N)FZ0BC!U/!'^Y%
M[EMAIL PROTECTED]@Y,`76:[##\H0N1KECIY$-V!\;N_4'[EMAIL PROTECTED]/#0PAL
[EMAIL PROTECTED]XT8?O?M-'[^__30]NQU3_UH^'%\CV\5]=0A3GD7#?P`
M.]*!949$/$[RS`'/Q6_+D7DKK2;8'!GE(H6WLIFWZUK5E*UC4_#K$CN'
MXF;O;R9CE2W9#KMP%T^]VN95A]+KLY^32`,;81PDB$(L5!.$`PZ[5N4#2
M/;O74,GRP`!6S@,[EMAIL PROTECTED]'\/:#B)9!)3N6XQAX7L$1$`IKE($NK#,?00
MYUPX^1(UX)@]K;A]WW_W?GD4_N'B[/VZ5E[,CUK8^_:%]/K]F1XUKX8G;5'
MG^WV]S2OKBYQL(/5#ALCRZN?D(\(PNV+B\_M\\^(-)VO==2X82P$(LX
M70$V:QA=T[([EMAIL PROTECTED]:K+'#74.Y\=$H#C3VRH?CK\X*AN%?'[
M?AMZIL5[-LQ6NC@@'=M2)P[D;4V*'#YO47!\'U)P!FU](K$E9O)PE7[V^3
MX(:C]PL2O9YE,G--Q$*=*\DX#TY0L7A,P+K1M:PRH%Q*8=9$/H!S5T/
M3L974T.'*[.P!5PJ1H,0AW+GI.4T8'[/Y:S/8MR29X]^I[=9VA6$(*
M6H#FX8%J`#X*TA.N)6Y``.8C,:R/1`279*66/_!'CD76A(EE!U;1)-%+CG
MY$Z](R9;@Y8]\4E(@YEI\+('[EMAIL PROTECTED](9$R[0MN5*OI9!I#06?
M6AYH7T(GL`[F^F'G,/'(+J'C\Y*I.^U:!F6$-_,J2S-KPTZ;[EMAIL PROTECTED]
M([EMAIL PROTECTED]3:7CB94H5.986HS,O\/XZ.J]-D@[EMAIL PROTECTED]Y20,PN%
[EMAIL PROTECTED]:P+\;(#_O`?I(B869K3[EMAIL PROTECTED]
M4I#4#E/7-]N09A$W2QSXS:TA.@75++4+I2/$\KDEP5W_SIT+M)O%+\X
MSC])^W#,@3U,_PT]])CLVJ'\[EMAIL PROTECTED])[EMAIL PROTECTED](\J9:9^D
M(?S7R?@:F*_#994E0`'IAI^S^\R#36I[EMAIL PROTECTED]'](
M$4Z69RJ3D[08JE1A/'U?V:6,R$1UX`/XR^.'T-Z[EMAIL PROTECTED];(48*
M0F^.%40QDX(ZT4(N];3W1#][EMAIL PROTECTED])W]1'ES?ID:CM;9K?1$F'3
M`:3H5`$+T]G.#9PW)RV094E6AIEI0\2XRDY%BO'#Q`WWD,YI**`E_
M;[EMAIL PROTECTED].2,/M'4:HT60,.?KN%,([EMAIL PROTECTED](@CNI!.$Z.IA?.(#U8;[EMAIL
PROTECTED]
M/L?'[K?Z*\QK/\[OJM,Q_9CXV,#9-4+O9(XOZN$:.N%^U^S6PS4*%/YH
M+63?5KL-15?*AMR2;G9F05[(DVT:C8Q-#QO7(]TH'8'?EG1EY+C1%QDV6
M1`0CR_=;-?EO5(')[EMAIL PROTECTED]:-BW(6;+/([EMAIL PROTECTED]:%/D9JI:#^5V
MY1T*/V9IX-V)JF_H%#OT[:_Q.OB!(`KR`%MVX\@/[I:IBF=AH_VCW_3D]N
M#S]?C^$(/V5C/``?L+OGU!OK1#\2#=H8)GDU8([EMAIL PROTECTED]]@(.K^,
M]L31:SBG^(87XUCO0+'WI#!?OST7R,WMHTYP]:H3TUR`9AX7.S03FS0(R
MDOT+4F#.4S@:408NR208/.G0RT-\$Z#GHC([EMAIL PROTECTED],5U2`R2+3WJ3
[EMAIL PROTECTED]@482Y?MC!XLS$2KZF-U$[?0TU8Y-:73I^\+A,@/+UCA=D,D;(9P_
M5CJFU?MC64)?\,=*7#?L0DR.3RYH3RG]/Q93BFX+K3K*90\3_Y=]_\N^_R[[
MCK%(%8K(*29R4A%QBA%;5(N3V'E,6KQPDE^XNSG`2K1(#1AM2)[O`!`]9
MDPE:PY?-F3!;P)TLUTMLA%C,[[-P\B\N)4YO.TOHMQ'#Y3)H[$,#'V\(WA
MC),-([EMAIL PROTECTED]N$!*^+7Q)#L$67BKNJ)0S;3+G5R]
MZSI'.-=QYR*,LM^.1QX7^+4RUK:F]#)9R(8:6\[[.(,I:;0JR[Z)[EMAIL PROTECTED]'
M99GSB/#ULAYY,T\ETFML\IT,[EMAIL PROTECTED]'-I8;MKG-HUB9=665[)
M):^/H[[)I;6+2]XXCGR#2[;%I;T/E_4!VV\0I8KKE8J;3U2U-MW9Z6*P_XJ
MSNL*P'+AEBX20:Q\59ZS[M\2L7WE$ZODDYW?^GH+TM'KZ3C=IBQGP'X
M,Z6#D4`21,=FZSPL=[M*H'U7Q`89^9KU,EHMBEP(S:3+/WM)B,7_3%L[
M$_Y$-+YP?;%V)C1]BH7J,GXL:)@OT'`KK1LTRA'`:O%*_-C'ZS(;.?#*7
M'!+?3[QL4[R;#LG^.GTTL7B'M:X55UKIU+0RH4)VNZCY=]B3^#4P:G!H[
M3%/:F#A]XO!WR[?F\'EMOF^-39.M6(\-ZK9`=D:7?LEHY;4M#7K1K+0LG
M1\EZQ8.9:T4T(TO;X9PH/9`H!8/MDJT),ZR@*E6FQ/7U134H`?9!DTGA)
M$7LR\BK#P^!4RY2\TLHU0SFOO-:M9_HF;F_YR2\UZSZG95YJ]+A;KW6TU
MXWTXZ!7%VVK6?T[)]-?HF:CK6]%6]H+96^=OZ]G2H3)^70Z6;IM'LH?C3
M-7ZHN[91+ZW]Q%[38^N\W!GYMD/[EMAIL PROTECTED]/MMM9!UL+S.`Z5:#
M'1BV-B8ZYVJF!]GV9'_17-=K_L0TMCGL;\^MY9#/QK3Y$1TTAC[B8@
MN/[4B1A8S,T+])_3FWXCAG^=YQBBL*,VA:W;6D;+8E*7U7WF!M2TI_C;O]
MXZ*9K_*RNR3DW64CZMC+S:9FY//#B-#_YW()YG.6D=_7]`K2`0'9`?3KT
M*$]T^+3K46Z%'[(BJ2];,)0;D='=_!A',C9X.3B)3.M!AJ[EMAIL PROTECTED]LK
M!!M[%L6[EMAIL PROTECTED]0Y.-MJND?O,MKE#$41$XNBNI:Y?CHBF[=%J@
M^+!'H=BC\RYKP-+^KV'IX$8EU_,IS6`FMP2D[4`AE#18J$.[;+T).'
MHNY$+H510+2)#TY'$`*;[=`8._QA?$J'9(9GMY=7-[?G5Y\N3XDH;UIJ
MX47MQE(+W\/8HU++7L96VO(R_[JXSMK,G([PAU:%:J.6ZZ%%V7[QGJCG.
MY=XC/V-H6U]V/8.-?C7-V3?-%S#H2$)GU88?/@S?;[EMAIL PROTECTED]@CW8\:?LR
M)T:\ED9!BMQ9Q([EMAIL PROTECTED],QY]-^'1Z
M,30,6G;.TS@,15IM1M)21T?^\3:XFNKDE-3=)82#5346;9/0X?Q#0D[!C#
M0_G$CYF[2!`3IN_5([EMAIL PROTECTED]('')LIDH6Q8/R$+G0`4?H+!FC`:[EMAIL PROTECTED]
M]#^AC3^#C[_::BC6V(P7FP$H/M;H.]B+'6[W2\TK-2RTO)@F=6/OAC?#
Re: New EHCI device ID
On Mon, 10 Nov 2003 13:19:12 +0100 Bernd Walter [EMAIL PROTECTED] wrote: I really doubt that you have a high speed mouse. EHCI only supports high speed devices itself. But it shouldn't stop the entire system if I attach an USB 1.1 mouse to an ehci controlled port. Bye, Alexander. -- The dark ages were caused by the Y1K problem. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New EHCI device ID
On Mon, Nov 10, 2003 at 01:50:02PM +0100, Alexander Leidinger wrote: On Mon, 10 Nov 2003 13:19:12 +0100 Bernd Walter [EMAIL PROTECTED] wrote: I really doubt that you have a high speed mouse. EHCI only supports high speed devices itself. But it shouldn't stop the entire system if I attach an USB 1.1 mouse to an ehci controlled port. But ehci doesn't control low/full speed ports. The physical ports are multiplexed between ehci and ohci/uhci ports. The switching is done without driver interaction. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Buildworld errors out on libbsnmp
Hi, I was just building world after your recent commits of the libbsnmp stuff. This results in the following errors: - === lib/libbsnmp/modules/snmp_mibII rm -f .depend mkdep -f .depend -a-I/usr/include/bsnmp -I/usr/src/lib/libbsnmp/modules/snmp_mibII /usr/src/lib/libbsnmp/modules/snmp_mibII/mibII_tree.c /usr/src/lib/libbsnmp/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c /usr/src/lib/libbsnmp/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII_ifmib.c /usr/src/lib/libbsnmp/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII_ip.c /usr/src/lib/libbsnmp/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII_interfaces.c /usr/src/lib/libbsnmp/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII_ipaddr.c /usr/src/lib/libbsnmp/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII_ifstack.c /usr/src/lib/libbsnmp/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII_rcvaddr.c /usr/src/lib/libbsnmp/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII_nettomedia.c /usr/src/lib/libbsnmp/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII_tcp.c /usr/src/lib/libbsnmp/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII_udp.c /usr/src/lib/libbsnmp/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII_route.c /usr/src/lib/libbsnmp/modules/snmp_mibII/mibII_tree.c:5:18: asn1.h: No such file or directory /usr/src/lib/libbsnmp/modules/snmp_mibII/mibII_tree.c:6:18: snmp.h: No such file or directory /usr/src/lib/libbsnmp/modules/snmp_mibII/mibII_tree.c:7:23: snmpagent.h: No such file or directory In file included from /usr/src/contrib/bsnmp/snmp_mibII/mibII.c:37: /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:57:18: asn1.h: No such file or directory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:58:18: snmp.h: No such file or directory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:59:21: snmpmod.h: No such file or directory In file included from /usr/src/contrib/bsnmp/snmp_mibII/mibII_ifmib.c:37: /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:57:18: asn1.h: No such file or directory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:58:18: snmp.h: No such file or directory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:59:21: snmpmod.h: No such file or directory In file included from /usr/src/contrib/bsnmp/snmp_mibII/mibII_ip.c:37: /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:57:18: asn1.h: No such file or directory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:58:18: snmp.h: No such file or directory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:59:21: snmpmod.h: No such file or directory In file included from /usr/src/contrib/bsnmp/snmp_mibII/mibII_interfaces.c:37: /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:57:18: asn1.h: No such file or directory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:58:18: snmp.h: No such file or directory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:59:21: snmpmod.h: No such file or directory In file included from /usr/src/contrib/bsnmp/snmp_mibII/mibII_ipaddr.c:40: /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:57:18: asn1.h: No such file or directory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:58:18: snmp.h: No such file or directory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:59:21: snmpmod.h: No such file or directory In file included from /usr/src/contrib/bsnmp/snmp_mibII/mibII_ifstack.c:37: /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:57:18: asn1.h: No such file or directory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:58:18: snmp.h: No such file or directory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:59:21: snmpmod.h: No such file or directory In file included from /usr/src/contrib/bsnmp/snmp_mibII/mibII_rcvaddr.c:37: /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:57:18: asn1.h: No such file or directory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:58:18: snmp.h: No such file or directory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:59:21: snmpmod.h: No such file or directory In file included from /usr/src/contrib/bsnmp/snmp_mibII/mibII_nettomedia.c:42: /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:57:18: asn1.h: No such file or directory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:58:18: snmp.h: No such file or directory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:59:21: snmpmod.h: No such file or directory In file included from /usr/src/contrib/bsnmp/snmp_mibII/mibII_tcp.c:37: /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:57:18: asn1.h: No such file or directory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:58:18: snmp.h: No such file or directory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:59:21: snmpmod.h: No such file or directory In file included from /usr/src/contrib/bsnmp/snmp_mibII/mibII_udp.c:37: /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:57:18: asn1.h: No such file or directory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:58:18: snmp.h: No such file or directory /usr/src/contrib/bsnmp/snmp_mibII/mibII.h:59:21: snmpmod.h: No such file or directory In file included from
Re: Buildworld errors out on libbsnmp
On Mon, 10 Nov 2003, Dimitry Andric wrote: DAHi, DA DAI was just building world after your recent commits of the libbsnmp DAstuff. This results in the following errors: Sorry, that was my error. I have committed a fix for the library, one for the daemon follows in a couple of minutes as soon as I have verified that it builds the universe. harti ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: the PS/2 mouse problem
Bruce Evans wrote:
On Sat, 8 Nov 2003, Morten Johansen wrote:
Scott Long wrote:
Bruce Evans wrote:
[... possibly too much trimmed]
The problem here is that the keyboard controller driver tries to be too
smart. If it detects that the hardware FIFO is full, it'll drain it into
a per-softc, per-function ring buffer. So having psm(4) just directly
read the hardware is insufficient in this scheme.
What is the per-function part? (I'm not very familar with psm, but once
understood simpler versions of the keyboard driver.) Several layers of
buffering might not be too bad for slow devices. The i/o times tend to
dominate unless you do silly things like a context switch to move each
character from one buffer to other, and even that can be fast enough
(I believe it is normal for interactive input on ptys; then there's often
a remote IPC or two per character as well).
- it sometimes calls the DELAY() function, which is not permitted in fast
interrupt handlers since apart from locking issues, fast interrupt
handlers
are not permitted to busy-wait.
Again, the keyboard controller driver is too smart for its own good. To
summarize:
read_aux_data_no_wait()
{
Does softc-aux ring buffer contain data?
return ring buffer data
Check the status register
Is the keyboard fifo full?
DELAY(7us)
read keyboard fifo into softc-kbd ring buffer
Check the status register
Is the aux fifo full?
DELAY(7us)
return aux fifo data
}
So you can wind up stalling for 14us in there, presumably because you
cannot read the status and data registers back-to-back without a delay.
I don't have the atkbd spec handy so I'm not sure how to optimize this.
Do you really need to check the status register before reading the data
register?
At least it's a bounded delay. I believe such delays are required for
some layers of the keyboard. Perhaps only for the keyboard (old hardware
only?) and not for the keyboard controller or the mouse.
Many of the complications for fast interrupt handlers shouldn't be needed
in psm. Just make psmintr() INTR_MPSAFE.
I believe that the previous poster actually tried making it INTR_MPSAFE,
but didn't see a measurable benefit because the latency of scheduling
the ithread is still unacceptable.
That is 100% correct.
In the meantime I have taken your's and Bruce's advice and rearranged
the interrupt handler to look like this:
mtx_lock(sc-input_mtx);
Er, this is reasonable for INTR_MPSAFE but not for INTR_FAST.
mtx_lock() is a sleep lock so it cannot be used in fast interrupt
handlers. mtx_lock_spin() must be used. (My version doesn't permit
use of mtx_lock_spin() either; more primitive locking must be used.)
while((c = read_aux_data_no_wait(sc-kbdc)) != -1) {
This is probably INTR_FAST-safe enough in practice.
sc-input_queue.buf[sc-input_queue.tail] = c;
if ((++ sc-input_queue.tail) = PSM_BUFSIZE)
sc-input_queue.tail = 0;
count = (++ sc-input_queue.count);
}
mtx_unlock(sc-input_mtx);
The locking for the queue seems to be correct except this should operate
on a spinlock too.
if (count = sc-mode.packetsize)
taskqueue_enqueue(taskqueue_swi_giant, sc-psm_task);
taskqueue_enqueue() can only be used in non-fast interrupt handlers.
taskqueue_enqueue_fast() must be used in fast interrupt handlers (except
in my version, it is not permitted so it shouldn't exist). Note that
the spinlock/fast versions can be used for normal interrupt handlers
too, so not much more code is needed to support handlers whose fastness
is dynamically configured.
Yes, I have submitted a PR (kern/59067), with an INTR_FAST version that
uses spinlocks and taskqueue_fast.
You can find it here if you have time to look at it:
http://dsm.oslonett.no/patch-psm-fast
I would appreciate comments on it's correctness.
And it works, but having it INTR_MPSAFE still does NOT help my problem.
It looks to me like data is getting lost because the interrupt handler
is unable to read it before it's gone, and the driver gets out of sync,
and has to reset itself.
However it now takes a few more tries to provoke the problem, so
something seems to have improved somewhere.
This is a bit surprising. There are still so few INTR_MPSAFE handlers
that there aren't many system activities that get in the way of running
the INTR_MPSAFE ones. Shared interrupts prevent running of a handler
while other handlers on the same interrupt are running, and the mouse
interrupt is often shared, but if it is shared then it couldn't be fast
until recently and still can't be fast unless all the other handlers on
it are fast.
Bruce
It seems odd that it should be necessary to have it INTR_FAST.
But somehow it is, on my system.
Morten
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
named pipes memory leak?
Hi,
is there a known problem with named pipes in -CURRENT?
The following shell script freezes a machine in several minutes and needs
a power cycle. You can see the increasing memory in vmstat -z (unpcb) and
netstat -u. The kernel is FreeBSD 5.1-CURRENT Tue Nov 4 14:08:23 CET 2003.
---8---
#/bin/sh
FIFO=/tmp/foo
for i in `jot 5 1`; do
mkfifo ${FIFO}
echo blubb ${FIFO}
kill $!
rm ${FIFO}
done
---8---
regards,
le
--
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator Tel.: (+43 1) 4277-14073
Vienna University Computer Center Fax.: (+43 1) 4277-9140
University of Vienna http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Still getting NFS client locking up
With a current build from november the 9th I am still getting exactly the same NFS lockups. I assume soren is as well. NFS has basically been pretty unusable now for over a month. As only a couple of people have complained about this from what I can see I assume it is something related to something specific such as a network card? From my testing I only get this lockup when writing to the server. Reading from the server works perfectly all the time. So luckily I can still manage an NFS mounted installworld/kernel. I just got the lockup again now whilst it downloaded p5-Net-DNS to portupgrade into /usr/ports/distfiles. This is a very small file but it was enough to trigger it off. So it doesn't look like a size related issue either as I can download around 4% of mysql before it locks up. Obviously we should really try and find the cause of this before 5.2. I am willing to try any patches/debug on my systems. But I just have zero clue about what to look for myself. As a start here is the relevent parts of my dmesg to show the NIC's I'm using. I wonder if this corresponds to sorens? NFS CLIENT (xl1 would be the card it's using to talk to the server): xl0: 3Com 3c905B-TX Fast Etherlink XL port 0xe400-0xe47f mem 0xea00-0xea7f irq 12 at device 15.0 on pci0 xl0: Ethernet address: 00:a0:24:ac:e1:b4 miibus0: MII bus on xl0 xlphy0: 3Com internal media interface on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl1: 3Com 3c905-TX Fast Etherlink XL port 0xe800-0xe83f irq 11 at device 17.0 on pci0 xl1: Ethernet address: 00:60:08:6d:1e:3b miibus1: MII bus on xl1 nsphy0: DP83840 10/100 media interface on miibus1 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto NFS SERVER: xl0: 3Com 3c905C-TX Fast Etherlink XL port 0x1000-0x107f mem 0xfc304800-0xfc30487f irq 10 at device 7.0 on pci5 xl0: Ethernet address: 00:04:76:8d:c5:fd miibus0: MII bus on xl0 xlphy0: 3c905C 10/100 internal PHY on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Both connected to a 100meg full duplex switch. Any ideas? As I have said I'm happy to enable some major debugging etc. But I just need somebody to give me a step by step guide for what to do and look for. In case this thread is too old now and nobody remembers anything about it the previous email regarding it is at http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1183410+0+archive/2003/freebsd-current/20031102.freebsd-current Regards, Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New EHCI device ID
On Mon, 10 Nov 2003 13:55:39 +0100 Bernd Walter [EMAIL PROTECTED] wrote: But ehci doesn't control low/full speed ports. The physical ports are multiplexed between ehci and ohci/uhci ports. The switching is done without driver interaction. Attached to the port is a uhub1: NEC Corporation USB2.0 Hub Controller, class 9/0, rev 2.00/1.00, addr 2 uhub1: 4 ports with 4 removable, self powered on this hub is a ums0: Logitech USB Receiver, rev 1.10/9.10, addr 3, iclass 3/1 ums0: 5 buttons and Z dir. This is from the dmesg of my desktop system (USB 1.1 only). If I attach this combo to the other system ehci tells me: ---snip--- usb4: unrevoerable error, controller halted usb4: blocking intrs 0x10 ---snip-- and stopps booting further. The usb part of the dmesg without anything attached: ---snip--- # dmesg |grep -E '(usb|hci|uhub)' uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0xbc00-0xbc1f irq 16 at device 29.0 on pci0 usb0: Intel 82801EB (ICH5) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0xb000-0xb01f irq 19 at device 29.1 on pci0 usb1: Intel 82801EB (ICH5) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0xb400-0xb41f irq 18 at device 29.2 on pci0 usb2: Intel 82801EB (ICH5) USB controller USB-C on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0xb800-0xb81f irq 16 at device 29.3 on pci0 usb3: Intel 82801EB (ICH5) USB controller USB-D on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: EHCI (generic) USB 2.0 controller mem 0xfc00-0xfc0003ff irq 23 at device 29.7 on pci0 ehci0: (New EHCI DeviceId=0x24dd8086) ehci_pci_attach: companion usb0 ehci_pci_attach: companion usb1 ehci_pci_attach: companion usb2 ehci_pci_attach: companion usb3 usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: EHCI (generic) USB 2.0 controller on ehci0 usb4: USB revision 2.0 uhub4: (0x8086) EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered ---snip--- Bye, Alexander. -- To boldly go where I surely don't belong. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Still getting NFS client locking up
It seems Matt Smith wrote: With a current build from november the 9th I am still getting exactly the same NFS lockups. I assume soren is as well. NFS has basically been pretty unusable now for over a month. Yes I do, NFS is virtually useless... As only a couple of people have complained about this from what I can see I assume it is something related to something specific such as a network card? Could be, but its more than one type of card which suggests to me its more generic in origin.. From my testing I only get this lockup when writing to the server. Reading from the server works perfectly all the time. So luckily I can still manage an NFS mounted installworld/kernel. I can also lock it up with just reading, but it takes longer. Obviously we should really try and find the cause of this before 5.2. I am willing to try any patches/debug on my systems. But I just have zero clue about what to look for myself. I think its a definite showstopper for 5.2 actually.. NFS SERVER: xl0: 3Com 3c905C-TX Fast Etherlink XL port 0x1000-0x107f mem 0xfc304800-0xfc30487f irq 10 at device 7.0 on pci5 xl0: Ethernet address: 00:04:76:8d:c5:fd miibus0: MII bus on xl0 xlphy0: 3c905C 10/100 internal PHY on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto OK the worst server I've got has: re0: RealTek 8139C+ 10/100BaseTX port 0xdc00-0xdcff mem 0xe400-0xe4ff irq 12 at device 9.0 on pci0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re1: RealTek 8139C+ 10/100BaseTX port 0xe000-0xe0ff mem 0xe4001000-0xe40010ff irq 10 at device 10.0 on pci0 rlphy1: RealTek internal media interface on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re2: RealTek 8139C+ 10/100BaseTX port 0xe400-0xe4ff mem 0xe4002000-0xe40020ff irq 11 at device 11.0 on pci0 rlphy2: RealTek internal media interface on miibus2 rlphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto The clients use fxp/xl/sis cards and can all make this server hang in seconds.. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Kernel halt when connecting re0 to the lan
Problem: when connecting my laptop (Compaq evo N1020v) to the network, the kernel halts right after execution of re_diag() in the re-device driver. The loopback test fails. The interface works ok if I remove the test from the driver, or if I use another operating system. It used to work perfect with 4.8-STABLE. Any suggestions? From dmesg: re0: RealTek 8139C+ 10/100BaseTX port 0x9000-0x90ff mem 0xf0019800-0xf00198ff irq 11 at device 11.0 on pci0 re0: Ethernet address: 00:08:02:d6:bf:cd miibus0: MII bus on re0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Best reg. Nils S. Nils Segerdahl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New EHCI device ID
On Mon, Nov 10, 2003 at 03:54:23PM +0100, Alexander Leidinger wrote: On Mon, 10 Nov 2003 13:55:39 +0100 Bernd Walter [EMAIL PROTECTED] wrote: But ehci doesn't control low/full speed ports. The physical ports are multiplexed between ehci and ohci/uhci ports. The switching is done without driver interaction. Attached to the port is a uhub1: NEC Corporation USB2.0 Hub Controller, class 9/0, rev 2.00/1.00, addr 2 uhub1: 4 ports with 4 removable, self powered USB2 hubs are currently not supported with high speed uplinks. That's the reason why there is no EHCI support in GENERIC. EHCI needs interrupt transfers first to support usb2.0 hubs at high speed uplinks with high speed devices. For low and full speed downlink we additionaly need speed conversion support in uhub code. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ALTQ support
On Mon, 10 Nov 2003 13:12:42 +0100 Tobias Roth [EMAIL PROTECTED] wrote: the author of altq itself or the author of the freebsd port? I don't know the who's who, but I think it was the author of altq itself. Bye, Alexander. -- Where do you think you're going today? http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New EHCI device ID
On Mon, 10 Nov 2003 16:19:27 +0100 Bernd Walter [EMAIL PROTECTED] wrote: USB2 hubs are currently not supported with high speed uplinks. That's the reason why there is no EHCI support in GENERIC. EHCI needs interrupt transfers first to support usb2.0 hubs at high speed uplinks with high speed devices. For low and full speed downlink we additionaly need speed conversion support in uhub code. Is there an easy way of printing something like this instead of halting the system? Bye, Alexander. -- To boldly go where I surely don't belong. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
buildworld error on 5.1-REL
I am seeing the following error and no amount of cvsup will help it. http://ns2.wananchi.com/~wash/5.1-REL/WORLD.txt Advise appreciated. -Wash -- |\ _,,,---,,_ | Odhiambo Washington[EMAIL PROTECTED] Zzz /,`.-'`'-. ;-;;,_ | Wananchi Online Ltd. www.wananchi.com |,4- ) )-,_. ,\ ( `'-'| Tel: +254 20 313985-9 +254 20 313922 '---''(_/--' `-'\_) | GSM: +254 722 743223 +254 733 744121 + If time heals all wounds, how come the belly button stays the same? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel memory leak in ATAPI/CAM or ATAng?
Date: Sun, 09 Nov 2003 22:43:47 -0700 From: Scott Long [EMAIL PROTECTED] Kevin Oberman wrote: Tested. It's much better, although ATA request keeps adding more memory all the time when mplayer is playing, but it's now increasing at about 20K/minute which is a huge improvement. Still, I don't understand why it should just continue to grow all of the time. The data rate is about constant. I would expect that it should grow to a size where the data being processed can be accommodated and then stop growing. I don't see it stopping. Thanks for the quick fix. Well, it sounds like there is still a memory leak somewhere. Make sure that you have rev 1.27 of atapi-cam.c to be sure. If so, please let me know which malloc type in vmstat -m is growing. Oh, crap! I guess I pulled the new version too quickly yesterday when your message arrived. I had 1.26. And I don't have a DVD with me, so I was seeing a much slower leak because the CD transfers data so much more slowly. After a kernel rebuild I see: ATA request 0 0K 1K 7285 128 after reading some bulk data off of a CD. Thanks! -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Still getting NFS client locking up
--- Original Message --- From: Soren Schmidt [EMAIL PROTECTED] Sent: Mon, 10 Nov 2003 16:03:47 +0100 (CET) To: Matt Smith [EMAIL PROTECTED] Subject: Re: Still getting NFS client locking up It seems Matt Smith wrote: With a current build from november the 9th I am still getting exactly the same NFS lockups. I assume soren is as well. NFS has basically been pretty unusable now for over a month. Yes I do, NFS is virtually useless... As only a couple of people have complained about this from what I can see I assume it is something related to something specific such as a network card? Could be, but its more than one type of card which suggests to me its more generic in origin.. From my testing I only get this lockup when writing to the server. Reading from the server works perfectly all the time. So luckily I can still manage an NFS mounted installworld/kernel. I can also lock it up with just reading, but it takes longer. Obviously we should really try and find the cause of this before 5.2. I am willing to try any patches/debug on my systems. But I just have zero clue about what to look for myself. I think its a definite showstopper for 5.2 actually.. Just to add some more evidence to the mix, I have two 5.1 current boxes using bfe, vr, and both have ath, and I am experience all of the lockups on the server end... client has yet to lock up. Kelley ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
list
___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New interrupt stuff breaks ASUS 2 CPU system
On Thu, Nov 06, 2003 at 12:22:45PM -0500, John Baldwin wrote: On 06-Nov-2003 Harti Brandt wrote: JBI figured out what is happenning I think. You are getting a spurious JBinterrupt from the 8259A PIC (which comes in on IRQ 7). The IRR register JBlists pending interrupts still waiting to be serviced. Try using JB'options NO_MIXED_MODE' to stop using the 8259A's for the clock and see if JBthe spurious IRQ 7 interrupts go away. Ok, that seems to help. Interesting although why do these interrupts happen only with a larger HZ and when the kernel is doing printfs (this machine has a serial console). I have also not tried to disable SIO2 and the parallel port. Can you also try turning mixed mode back on and using http://www.FreeBSD.org/~jhb/patches/spurious.patch You should get some stray IRQ 7's in the vmstat -i output as well as a few printf's to the kernel console. I think I'm seeing something related here, with the old interrupt code I got: ... Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... ACPI autoload failed - no such file or directory stray irq 7 ^^^ Copyright (c) 1992-2003 The FreeBSD Project. ... With the new interrupt code I get: ... OK boot cpuid = 0; apic id = 00 instruction pointer = 0x0:0xa00 stack pointer = 0x0:0xffe frame pointer = 0x0:0x0 code segment= base 0x0, limit 0x0, type 0x0 = DPL 0, pres 0, def32 0, gran 0 processor eflags= interrupt enabled, vm86, IOPL = 0 current process = 0 () kernel: type 30 trap, code=0 Stopped at 0xa00: cli db tr (null)(0,0,0,0,0) at 0xa00 ... However, if I enter 'continue' at the DDB prompt it continues to boot and the system seems to runs fine: ... db continue SMAP type=01 base= len=0009f400 SMAP type=02 base=0009f400 len=0c00 SMAP type=02 base=000d len=0003 SMAP type=01 base=0010 len=1fdf SMAP type=03 base=1fef len=f000 SMAP type=04 base=1feff000 len=1000 SMAP type=01 base=1ff0 len=0008 SMAP type=02 base=1ff8 len=0008 SMAP type=02 base=fec0 len=4000 SMAP type=02 base=fee0 len=1000 SMAP type=02 base=fff8 len=0008 Copyright (c) 1992-2003 The FreeBSD Project. ... Neiter the spurious interrupt patch nor setting 'options NO_MIXED_MODE' makes a difference. This is on a Tyan Tiger MPX S2466N-4M board, a full verbose boot log is at: http://quad.zeist.de/newintr.log ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
diskless panic with new interrupt code
Hi, My old diskless dual Pentium I 100MHz system does not like the latest code. I use etherboot to boot it. I have tried both an UP and SMP kernel but it panic in the same way. Looking at the low address values, it looks as if it happens very early. Maybe something depends on the loader initializing things nowadays? A kernel of about 2 weeks ago did boot without a problem, even an SMP one. On bootup this is what I see: # WARNING: loader(8) metadata is missing! instruction pointer = 0x0:0xa00 stack pointer = 0x0:0xffe frame pointer = 0x0:0x0 code segment= base 0x0, limit 0x0, type 0x0 = DPL 0, pres 0, def32 0, gran 0 processor eflags= interrupt enabled, vm86, IOPL = 0 current process = 0 () kernel: type 30 trap, code=0 Stopped at 0xa00: cli db # John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Still getting NFS client locking up
On Mon, 10 Nov 2003, Matt Smith wrote: With a current build from november the 9th I am still getting exactly the same NFS lockups. I assume soren is as well. NFS has basically been pretty unusable now for over a month. As only a couple of people have complained about this from what I can see I assume it is something related to something specific such as a network card? I'm fairly baffled. I tried for many hours to reproduce the problem in two seperate sets of systems here, and completely failed. I left buildworlds, cvs updates, blah blah blah, running for 96 hours across pools of clients and servers and no hint of the problem. I also use NFS daily on my primary workstation at work, as well as in my normal development setup with diskless crashboxes. So indeed, there must be some very specific piece of the picture that I'm not reproducing, such as a specific network card, or there's a race condition that requires very specific timing, etc. How fast are your systems, speaking of which? I live in the world of 300-500 mhz machines at work, and 300-800 mhz boxes at home. If you're using multi-ghz boxes, that could well be the distinguishing factor between our configurations... From my testing I only get this lockup when writing to the server. Reading from the server works perfectly all the time. So luckily I can still manage an NFS mounted installworld/kernel. I just got the lockup again now whilst it downloaded p5-Net-DNS to portupgrade into /usr/ports/distfiles. This is a very small file but it was enough to trigger it off. So it doesn't look like a size related issue either as I can download around 4% of mysql before it locks up. Obviously we should really try and find the cause of this before 5.2. I am willing to try any patches/debug on my systems. But I just have zero clue about what to look for myself. As a start here is the relevent parts of my dmesg to show the NIC's I'm using. I wonder if this corresponds to sorens? NFS CLIENT (xl1 would be the card it's using to talk to the server): xl0: 3Com 3c905B-TX Fast Etherlink XL port 0xe400-0xe47f mem 0xea00-0xea7f irq 12 at device 15.0 on pci0 xl0: Ethernet address: 00:a0:24:ac:e1:b4 miibus0: MII bus on xl0 xlphy0: 3Com internal media interface on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl1: 3Com 3c905-TX Fast Etherlink XL port 0xe800-0xe83f irq 11 at device 17.0 on pci0 xl1: Ethernet address: 00:60:08:6d:1e:3b miibus1: MII bus on xl1 nsphy0: DP83840 10/100 media interface on miibus1 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto NFS SERVER: xl0: 3Com 3c905C-TX Fast Etherlink XL port 0x1000-0x107f mem 0xfc304800-0xfc30487f irq 10 at device 7.0 on pci5 xl0: Ethernet address: 00:04:76:8d:c5:fd miibus0: MII bus on xl0 xlphy0: 3c905C 10/100 internal PHY on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto My server: xl0: 3Com 3c905B-TX Fast Etherlink XL port 0xd880-0xd8ff mem 0xff202000-0xff20207f irq 11 at device 17.0 on pci0 xl0: Ethernet address: 00:b0:d0:29:ec:ce miibus2: MII bus on xl0 xlphy0: 3Com internal media interface on miibus2 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto My client1: xl0: 3Com 3c905B-TX Fast Etherlink XL port 0xdc00-0xdc7f mem 0xff00-0xff7f irq 11 at device 17.0 on pci0 xl0: Ethernet address: 00:c0:4f:0d:6b:bc miibus0: MII bus on xl0 xlphy0: 3Com internal media interface on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto My client2: xl0: 3Com 3c905B-TX Fast Etherlink XL port 0xd880-0xd8ff mem 0xff202000-0xff20207f irq 11 at device 17.0 on pci0 xl0: Ethernet address: 00:b0:d0:2b:76:d5 miibus2: MII bus on xl0 xlphy0: 3Com internal media interface on miibus2 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Both connected to a 100meg full duplex switch. Ditto. Any ideas? As I have said I'm happy to enable some major debugging etc. But I just need somebody to give me a step by step guide for what to do and look for. In case this thread is too old now and nobody remembers anything about it the previous email regarding it is at http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1183410+0+archive/2003/freebsd-current/20031102.freebsd-current Ok, here's the strategy I was planning to take once I could reproduce it: (1) Attempt to further narrow down responsibility to client/server. In particular, see if an apparent hang on one client affects the other clients. (2) Investigate Soren's report that killing and restarting nfsd on the server would clear the hang. (3) Look at stack traces of involved processes on both the client and server: in particular, look at traces for any client blocked in NFS, any nfsiod processes on the client, and the nfsd processes on the server. Also look at the wait channels on clients and servers for these processes. Particularly interested in whether nfsd processes
Re: Still getting NFS client locking up
Robert Watson wrote: I'm fairly baffled. I tried for many hours to reproduce the problem in two seperate sets of systems here, and completely failed. I left buildworlds, cvs updates, blah blah blah, running for 96 hours across pools of clients and servers and no hint of the problem. I also use NFS daily on my primary workstation at work, as well as in my normal development setup with diskless crashboxes. So indeed, there must be some very specific piece of the picture that I'm not reproducing, such as a specific network card, or there's a race condition that requires very specific timing, etc. How fast are your systems, speaking of which? I live in the world of 300-500 mhz machines at work, and 300-800 mhz boxes at home. If you're using multi-ghz boxes, that could well be the distinguishing factor between our configurations... snip client is an intel pentium II 300mhz with 256meg ram and 1gig of swap. server is an athlon XP 2200 with 512meg ram and 1gig of swap. I can certainly spend some time trying to get some proper debug based on what you have said in your email. I shall look into setting up a serial console etc. In the meantime another piece of information which might be helpful is this. Looking at the wtmp to see when I rebuilt my world/kernel I can see this: reboot ~ Tue Oct 21 20:44 reboot ~ Wed Oct 15 19:36 (These times are in BST which is +5 hours from east coast US). On the Oct 15th kernel NFS was working perfectly (and before that). From the Oct 21st kernel it has always locked up in this way. So something between those two dates was commited which broke this for us. Another way of me debugging this I guess is to backtrack my world to each date in between systematically and find the exact date it breaks and look at the commits. Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
erroneous message from locked-up machine
I came in to work today to find one of my -current machines unable to open a pipe. (This probably had a lot to do with the spamd that went stark raving nutters overnight, but that's a separate problem.) A power cycle fixed the problem, but /var/log/messages was filled with: Nov 10 11:05:44 bewilderbeast kernel: kern.maxpipekva exceeded, please see tuning(7). Interesting. bewilderbeast~;sysctl kern.maxpipekva sysctl: unknown oid 'kern.maxpipekva' bewilderbeast~; And tuning(7) doesn't mention this, either. Is this just work-in-progress, or did someone forget to commit something? ==ml PS: Lesson of the day: no pipe KVA, no su. Great fun on remote machines! :-) -- Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] Today's chance of throwing it all away to start a goat farm: 41.8% http://www.BlackHelicopters.org/~mwlucas/ Absolute OpenBSD: http://www.AbsoluteOpenBSD.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New EHCI device ID
On Mon, Nov 10, 2003 at 04:35:31PM +0100, Alexander Leidinger wrote: On Mon, 10 Nov 2003 16:19:27 +0100 Bernd Walter [EMAIL PROTECTED] wrote: USB2 hubs are currently not supported with high speed uplinks. That's the reason why there is no EHCI support in GENERIC. EHCI needs interrupt transfers first to support usb2.0 hubs at high speed uplinks with high speed devices. For low and full speed downlink we additionaly need speed conversion support in uhub code. Is there an easy way of printing something like this instead of halting the system? Don't know, but if I ever put time in that issue then by implementing the missing points and not by changing symptoms. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
make world
after making make buildworld,installworld mergemaster and everything that i suposed to do ( reading UPDATING) i get this error: init: can't exec getty `/usr/libexec/getty` for /dev/ttyv1: No souch file or directory init: can't exec getty `/usr/libexec/getty` for /dev/ttyv2: No souch file or directory ...and so on any help thanx Aleksandar ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: build problems
On Sun, 9 Nov 2003, Jason wrote: I have had problems finishing buildworld and the problem is the same each time the build fails. It has failed 4 times at file:///usr/src/gnu/usr.bin/cvs/doc/. I have cvsuped 3 times in 2 days. I am running 5.1. Any info you might have would be helpful. This is usually where rescue falls over. Try building with out -j and see where it des then. You may want to clear out /usr/obj. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New interrupt stuff breaks ASUS 2 CPU system
With the new interrupt code I get: ... OK boot cpuid = 0; apic id = 00 instruction pointer = 0x0:0xa00 stack pointer = 0x0:0xffe frame pointer = 0x0:0x0 code segment= base 0x0, limit 0x0, type 0x0 = DPL 0, pres 0, def32 0, gran 0 processor eflags= interrupt enabled, vm86, IOPL = 0 current process = 0 () kernel: type 30 trap, code=0 Stopped at 0xa00: cli db tr (null)(0,0,0,0,0) at 0xa00 ... However, if I enter 'continue' at the DDB prompt it continues to boot and the system seems to runs fine: ... db continue ... Copyright (c) 1992-2003 The FreeBSD Project. ... Now why didn't I think of trying 'continue'? Hey there my old dual Pentium I diskless machine is running in SMP mode. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: erroneous message from locked-up machine
On Mon, 10 Nov 2003 11:45:13 -0500 Michael W. Lucas [EMAIL PROTECTED] wrote: Nov 10 11:05:44 bewilderbeast kernel: kern.maxpipekva exceeded, please see tuning(7). Interesting. bewilderbeast~;sysctl kern.maxpipekva sysctl: unknown oid 'kern.maxpipekva' bewilderbeast~; sysctl kern.maxpipe and kva exceeded, please see tuning(7). Bye, Alexander. -- Failure is not an option. It comes bundled with your Microsoft product. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem on a laptop with current
On Sun, 9 Nov 2003, Yannick FAHAM wrote: I have recently bought a centrino laptop and tried to install current on it. the fact is my network card is only supported in this branche (broadcom 4401). Broadcom wireless cards are not supported in -CURRENT. after compiling the kernel, the boot process freeze on the hardware enumeration. I have disabled acpi and boot in verbose mode and I have many errors message like (probe0)... Error 22. Sorry for my english, i'm french. Could you post the dmesg you're getting? This isn't enough to tell... -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem on a laptop with current
On Mon, Nov 10, 2003 at 09:17:07AM -0800, Doug White wrote: (broadcom 4401). Broadcom wireless cards are not supported in -CURRENT. That's not a wireless card. It's an el cheapo 10/100 chipset. Linux supports it now, and it's found in some Athlon motherboards (such as the one powering cvsup12.freebsd.org) as well as some newer laptops. Regards, -- wca ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make world
On Mon, 10 Nov 2003, Aleksandar Simonovski wrote: after making make buildworld,installworld mergemaster and everything that i suposed to do ( reading UPDATING) i get this error: init: can't exec getty `/usr/libexec/getty` for /dev/ttyv1: No souch file or directory init: can't exec getty `/usr/libexec/getty` for /dev/ttyv2: No souch file or directory Hm, no devfs mounted? -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Still getting NFS client locking up
It seems Robert Watson wrote: How fast are your systems, speaking of which? I live in the world of 300-500 mhz machines at work, and 300-800 mhz boxes at home. If you're using multi-ghz boxes, that could well be the distinguishing factor between our configurations... Server is 533MhzVIA C3, clients everything from 300Mhz PII to 2.6G P4. Ok, here's the strategy I was planning to take once I could reproduce it: (1) Attempt to further narrow down responsibility to client/server. In particular, see if an apparent hang on one client affects the other clients. For me its just the server end that fails, I've not seen the client hang. (2) Investigate Soren's report that killing and restarting nfsd on the server would clear the hang. Yups, that works, in fact I have that in my crontab now every minute to keep NFS from hosing my setup here. NOTE: I also still need to ifconfig done/up my interfaces on some boxes or the netstack will freeze (again done every minute in crontab). However when NFS locks up it seems totatlly unrelated, ie all other network traffic works... (3) Look at stack traces of involved processes on both the client and server: in particular, look at traces for any client blocked in NFS, any nfsiod processes on the client, and the nfsd processes on the server. Also look at the wait channels on clients and servers for these processes. Particularly interested in whether nfsd processes are blocked trying to grab locks. Ok, will do.. (4) Look at netstat information for NFS sockets, in particular, if the buffers are full, or not being drained. In particular, on the server, is the input queue not being drained by nfsd worker threads? Netstat doesn't seem to give any hints or even usefull info here, any special cmdøs you want the output from ? (5) Try backing out src/sys/nfsserver/nfs_serv.c:1.137, which removed another deadlock problem, but did change locking behavior in the NFS server. No change already tried. (6) Look at packet traces between the client and server with ethereal, which has pretty good NFS decoding. Is the client retransmitting an RPC to the server and the server just isn't responding, or is the client failing to transmit? At the point of the hang, what sorts of RPCs are outstanding to the server? In the past, we've seen apparent hangs when some or another more obscure unusual error case on the NFS server fails to respond to an RPC, which causes the client to wait forever. I can try that easily, I'll get a trace to you later tonight... Things to look for: normally, idle nfsd and nfsiod processes have a WCHAN of - (ps -lax), which indicates they're blocked waiting for some event to kick them off. If you see nfsd processes hung in another state, it's a good sign we've identified a server problem. In the nfs client processes, nfsrcvlk typically indicates a process has sent out an RPC and is now waiting on a response. I see the idle '-' wchan here when things go bad IIRC... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: erroneous message from locked-up machine
On Mon, 10 Nov 2003, Michael W. Lucas wrote:
I came in to work today to find one of my -current machines unable to
open a pipe. (This probably had a lot to do with the spamd that went
stark raving nutters overnight, but that's a separate problem.) A
power cycle fixed the problem, but /var/log/messages was filled with:
Nov 10 11:05:44 bewilderbeast kernel: kern.maxpipekva exceeded, please see tuning(7).
Interesting.
bewilderbeast~;sysctl kern.maxpipekva
sysctl: unknown oid 'kern.maxpipekva'
bewilderbeast~;
The following patch fixes this and some nearby style bugs:
- source style bug: line too line
- output style bugs: comma splice, verboseness (helps make the source line
too long), and kernel message terminated with a ..
%%%
Index: sys_pipe.c
===
RCS file: /home/ncvs/src/sys/kern/sys_pipe.c,v
retrieving revision 1.158
diff -u -2 -r1.158 sys_pipe.c
--- sys_pipe.c 9 Nov 2003 09:17:24 - 1.158
+++ sys_pipe.c 10 Nov 2003 17:21:47 -
@@ -331,5 +331,5 @@
if (error != KERN_SUCCESS) {
if (ppsratecheck(lastfail, curfail, 1))
- printf(kern.maxpipekva exceeded, please see tuning(7).\n);
+ printf(kern.ipc.maxpipekva exceeded; see tuning(7)\n);
return (ENOMEM);
}
%%%
And tuning(7) doesn't mention this, either.
Is this just work-in-progress, or did someone forget to commit something?
Seems like tuning pipe kva is completely absent in tuning(7) (so the above
message can be shortened further). You can tune kva generally as documented
there, but the pipe limit is separate.
PS: Lesson of the day: no pipe KVA, no su. Great fun on remote
machines! :-)
It's interesting that su was the point of failure. It uses a pipe hack
for IPC. Otherwise it doesn't use pipes, at least direectly. It
shouldn't need to use the pipe hack. My version uses signals instead.
Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Trouble booting a SMP kernel
On Thu, Nov 06, 2003 at 11:58:46AM -0600, Josh Tolbert wrote: On Thu, Nov 06, 2003 at 09:53:58AM -0800, Scott R. Sewall wrote: I need a little help diagnosing a problem booting a 5.1-RELEASE SMP kernel. The GENERIC kernel boots just fine. When I boot a GENERIC kernel with SMP enabled the boot fails early in the boot process. The text from the console is below: Programming 16 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 Programming 16 pins in IOAPIC #1 AP #1 (PHY #1) failed! panic y/n? [y] n snip APIC_IO: Testing 8254 interrupt delivery [system is locks up at this point, no more messages] Also fails to boot a FreeBSD 4.4 SMP kernel, which leads me to beleive it's a hardware problem. Is this indicative of a failed processor or is it the motherboard? Hardware is a Tyan Thunder LE-T, BIOS v1.06, Dual Pentium III 1133 MHz, 2GB RAM. Any advise on diagnosing the problem is greatly appreciated. -- Scott No advice, but I experienced this exact problem last night. I'm running a Tyan Tiger LE motherboard, 2x PIII 733, 512M RAM and various other bits. It hangs in the exact same spot as yours does, which isn't surprising considering both motherboards use essentially the same chipset. This machine has ran with 4.x in the past, as well as an older 5-CURRENT, but I don't have timeframes for either. I'm fairly certain it's not a hardware problem. Google turns up a few other people with the same problem, so I don't think we're alone. I was going to fire off an e-mail to the lists today, but figured it would be best just to chime in with a me too since you've already got one in. Thanks, Josh To follow up, I tried the latest -CURRENT build from current.freebsd.org. The new SMP arrangement works great and the kernel boots fine on the machine, but I couldn't continue the install once I got past drive partitioning due to some missing devices related to the Promise IDE RAID array. So, as it stands, -RELEASE won't run in SMP and -CURRENT will, but -CURRENT won't install on my machine. Of course, I put all of about five minutes' worth of effort in to it... Any other ideas? Thanks, Josh ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: probing for non-PCI bus
Hi, Upgrading a Asus P2L97-DS dual Pentium II 266MHz box, I got this panic when booting: Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS drive D: is disk2 BIOS drive E: is disk3 BIOS 640kB/130036kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 ([EMAIL PROTECTED], Sun Nov 2 14:16:55 SAST 2003) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x23372c data=0x27fcc+0x47494 syms=[0x4+0x31690+0x4+0x3de08] /boot/kernel/if_vlan.ko text=0x22b0 data=0x1d8+0x5c syms=[0x4+0x620+0x4+0x573] /boot/kernel/if_fxp.ko text=0x77c0 data=0xfd4+0xc syms=[0x4+0xc50+0x4+0xceb] loading required module 'miibus' /boot/kernel/miibus.ko text=0x15940 data=0xc84+0x68 syms=[0x4+0x1a90+0x4+0x2240] /boot/kernel/usb.ko text=0x201e8 data=0xb4c+0x148 syms=[0x4+0x2ad0+0x4+0x30bb] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #50: Mon Nov 10 17:51:13 SAST 2003 [EMAIL PROTECTED]:/b/src/sys/i386/compile/BEAST Preloaded elf kernel /boot/kernel/kernel at 0xc0768000. Preloaded elf module /boot/kernel/if_vlan.ko at 0xc076821c. Preloaded elf module /boot/kernel/if_fxp.ko at 0xc07682c8. Preloaded elf module /boot/kernel/miibus.ko at 0xc0768374. Preloaded elf module /boot/kernel/usb.ko at 0xc0768420. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Pentium II/Pentium II Xeon/Celeron (267.27-MHz 686-class CPU) Origin = GenuineIntel Id = 0x633 Stepping = 3 Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,MMX real memory = 134205440 (127 MB) avail memory = 125018112 (119 MB) MPTable: OEM0 PROD FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 1 cpu1 (AP): APIC ID: 0 ioapic0: Assuming intbase of 0 ioapic0 Version 1.1 irqs 0-23 on motherboard Pentium Pro MTRR support enabled acpi0: ASUS P2L97-DS on motherboard pcibios: BIOS version 2.10 Using $PIR table, 7 entries at 0xc00f0d20 acpi0: Power Button (fixed) Timecounter ACPI-safe frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: slot 4 INTD is routed to irq 5 pcib0: slot 6 INTA is routed to irq 5 pcib0: slot 10 INTA is routed to irq 12 pcib0: slot 11 INTA is routed to irq 10 pcib0: slot 12 INTA is routed to irq 11 panic: probing for non-PCI bus cpuid = 0; Uptime: 1s Shutting down ACPI Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Still getting NFS client locking up
On Mon, 10 Nov 2003, Matt Smith wrote: I can certainly spend some time trying to get some proper debug based on what you have said in your email. I shall look into setting up a serial console etc. In the meantime another piece of information which might be helpful is this. Looking at the wtmp to see when I rebuilt my world/kernel I can see this: reboot ~ Tue Oct 21 20:44 reboot ~ Wed Oct 15 19:36 (These times are in BST which is +5 hours from east coast US). On the Oct 15th kernel NFS was working perfectly (and before that). From the Oct 21st kernel it has always locked up in this way. So something between those two dates was commited which broke this for us. Another way of me debugging this I guess is to backtrack my world to each date in between systematically and find the exact date it breaks and look at the commits. Hmm. The one other thing that might be worth trying, and this is pretty time-consuming, is attempting to narrow down the threshold kernel change that caused the failures to start. Typically, this is done using a binary search (i.e., find two dates -- one that the kernel works, the other that it doesn't -- split the difference, repeat until narrowed down to a range of commits that can be individually inspected). This way we could try to identify some suspect changes that could be backed out locally individually to narrow it down. The likely categories of commits that might be worth looking at probably include: (1) Changes specifically to the network drivers that you're using. (2) Changes to the network stack, especially relating to locking and timeouts. (3) Changes to the NFS client and server code. (4) Changes in general to VFS and buffer cache locking. We've had a lot of commits in all of these categories, so narrowing it down would be a useful way to help figure it out... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New interrupt stuff breaks ASUS 2 CPU system
On 10-Nov-2003 Marius Strobl wrote: On Thu, Nov 06, 2003 at 12:22:45PM -0500, John Baldwin wrote: On 06-Nov-2003 Harti Brandt wrote: JBI figured out what is happenning I think. You are getting a spurious JBinterrupt from the 8259A PIC (which comes in on IRQ 7). The IRR register JBlists pending interrupts still waiting to be serviced. Try using JB'options NO_MIXED_MODE' to stop using the 8259A's for the clock and see if JBthe spurious IRQ 7 interrupts go away. Ok, that seems to help. Interesting although why do these interrupts happen only with a larger HZ and when the kernel is doing printfs (this machine has a serial console). I have also not tried to disable SIO2 and the parallel port. Can you also try turning mixed mode back on and using http://www.FreeBSD.org/~jhb/patches/spurious.patch You should get some stray IRQ 7's in the vmstat -i output as well as a few printf's to the kernel console. I think I'm seeing something related here, with the old interrupt code I got: ... Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... ACPI autoload failed - no such file or directory stray irq 7 ^^^ Copyright (c) 1992-2003 The FreeBSD Project. Peter has seen this on an amd64 machine. It seems we can get an interrupt from the AT PIC before we get a chance to program the PICs to mask all their inputs. ... With the new interrupt code I get: ... OK boot cpuid = 0; apic id = 00 instruction pointer = 0x0:0xa00 stack pointer = 0x0:0xffe frame pointer = 0x0:0x0 code segment= base 0x0, limit 0x0, type 0x0 = DPL 0, pres 0, def32 0, gran 0 processor eflags= interrupt enabled, vm86, IOPL = 0 current process = 0 () kernel: type 30 trap, code=0 Stopped at 0xa00: cli db tr (null)(0,0,0,0,0) at 0xa00 ... However, if I enter 'continue' at the DDB prompt it continues to boot and the system seems to runs fine: ... db continue SMAP type=01 base= len=0009f400 SMAP type=02 base=0009f400 len=0c00 SMAP type=02 base=000d len=0003 SMAP type=01 base=0010 len=1fdf SMAP type=03 base=1fef len=f000 SMAP type=04 base=1feff000 len=1000 SMAP type=01 base=1ff0 len=0008 SMAP type=02 base=1ff8 len=0008 SMAP type=02 base=fec0 len=4000 SMAP type=02 base=fee0 len=1000 SMAP type=02 base=fff8 len=0008 Copyright (c) 1992-2003 The FreeBSD Project. ... Neiter the spurious interrupt patch nor setting 'options NO_MIXED_MODE' makes a difference. This is on a Tyan Tiger MPX S2466N-4M board, a full verbose boot log is at: http://quad.zeist.de/newintr.log -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: diskless panic with new interrupt code
On 10-Nov-2003 John Hay wrote: Hi, My old diskless dual Pentium I 100MHz system does not like the latest code. I use etherboot to boot it. I have tried both an UP and SMP kernel but it panic in the same way. Looking at the low address values, it looks as if it happens very early. Maybe something depends on the loader initializing things nowadays? A kernel of about 2 weeks ago did boot without a problem, even an SMP one. On bootup this is what I see: # WARNING: loader(8) metadata is missing! instruction pointer = 0x0:0xa00 stack pointer = 0x0:0xffe frame pointer = 0x0:0x0 code segment = base 0x0, limit 0x0, type 0x0 = DPL 0, pres 0, def32 0, gran 0 processor eflags = interrupt enabled, vm86, IOPL = 0 current process = 0 () kernel: type 30 trap, code=0 Stopped at0xa00: cli db # Just do a continue for now until I get a workaround for this done. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New interrupt stuff breaks ASUS 2 CPU system
On 10-Nov-2003 John Hay wrote: With the new interrupt code I get: ... OK boot cpuid = 0; apic id = 00 instruction pointer = 0x0:0xa00 stack pointer = 0x0:0xffe frame pointer = 0x0:0x0 code segment= base 0x0, limit 0x0, type 0x0 = DPL 0, pres 0, def32 0, gran 0 processor eflags= interrupt enabled, vm86, IOPL = 0 current process = 0 () kernel: type 30 trap, code=0 Stopped at 0xa00: cli db tr (null)(0,0,0,0,0) at 0xa00 ... However, if I enter 'continue' at the DDB prompt it continues to boot and the system seems to runs fine: ... db continue ... Copyright (c) 1992-2003 The FreeBSD Project. ... Now why didn't I think of trying 'continue'? Hey there my old dual Pentium I diskless machine is running in SMP mode. Can you try this patch: http://www.FreeBSD.org/~jhb/patches/atpic.patch -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: ALTQ support
Monday, November 10, 2003, 4:32:54 PM, you wrote: AL On Mon, 10 Nov 2003 13:12:42 +0100 AL Tobias Roth [EMAIL PROTECTED] wrote: the author of altq itself or the author of the freebsd port? AL I don't know the who's who, but I think it was the author of altq AL itself. I certainly doubt that! On his homepage he has own patchsets for early 4.x releases and gives KAME as a resource for 5.x patchsets. So prove me wrong (by finally finding that mysterious thread) or stop spreading that kind of evil half-knowledge, please! FYI: The author of altq would be Kenjiro Cho, as google tells you. -- Best regards, Maxmailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: -0166: *** Error: UtAllocate: Attempt to alloc
On Mon, Nov 10, 2003 at 04:58:51AM -0500, Seth Chandler wrote: You using a dell laptop? They got the broken acpi aml code. There is a patch out to fix it, its located here: http://sandcat.nl/~stijn/freebsd/dell.php Thanks. Applied it and it seems to cure the problem. Also xbatt shows the battery status now correctly. Nov 10 20:05:24 mybook kernel: acpi0: DELL CPi R on motherboard Nov 10 20:05:24 mybook kernel: pcibios: BIOS version 2.10 Nov 10 20:05:24 mybook kernel: Using $PIR table, 10 entries at 0xc00fbc20 Nov 10 20:05:24 mybook kernel: Timecounter ACPI-fast frequency 3579545 Hz q uality 1000 Nov 10 20:05:24 mybook kernel: acpi_timer0: 24-bit timer at 3.579545MHz por t 0x808-0x80b on acpi0 Nov 10 20:05:24 mybook kernel: acpi_cpu0: CPU on acpi0 Nov 10 20:05:24 mybook kernel: acpi_tz0: Thermal Zone on acpi0 Nov 10 20:05:24 mybook kernel: acpi_acad0: AC Adapter on acpi0 Nov 10 20:05:24 mybook kernel: acpi_cmbat0: Control Method Battery on acpi0 Nov 10 20:05:24 mybook kernel: acpi_cmbat1: Control Method Battery on acpi0 Nov 10 20:05:24 mybook kernel: acpi_lid0: Control Method Lid Switch on acpi 0 Nov 10 20:05:24 mybook kernel: acpi_button0: Power Button on acpi0 Nov 10 20:05:24 mybook kernel: acpi_button1: Sleep Button on acpi0 Nov 10 20:05:24 mybook kernel: pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 Nov 10 20:05:24 mybook kernel: pci0: ACPI PCI bus on pcib0 Nov 10 20:05:24 mybook kernel: pcib0: slot 31 INTD is routed to irq 10 Nov 10 20:05:24 mybook kernel: agp0: Intel 82815 (i815 GMCH) host to PCI bri dge mem 0xe800-0xebff at device 0.0 on pci0 Nov 10 20:05:24 mybook kernel: pcib1: ACPI PCI-PCI bridge at device 1.0 on seth C. Kukulies wrote: ...ate zero bytes The kernel message -0166: *** Error: UtAllocate: Attempt to allocate zero bytes -0166: *** Error: UtAllocate: Attempt to allocate zero bytes -0166: *** Error: UtAllocate: Attempt to allocate zero bytes -0166: *** Error: UtAllocate: Attempt to allocate zero bytes clobbers the screen in bursts during startup for quite some time now. I would like to ask if there is something I can do about it. Upgrading (cvsup)? Edit some config files with senseful info? AFAIK it has to do something with acpi, doesn't it? -- Chris Christoph P. U. Kukulies kuku_at_physik.rwth-aachen.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New interrupt stuff breaks ASUS 2 CPU system
On Mon, Nov 10, 2003 at 02:12:56PM -0500, John Baldwin wrote: On 10-Nov-2003 John Hay wrote: With the new interrupt code I get: ... OK boot cpuid = 0; apic id = 00 instruction pointer = 0x0:0xa00 stack pointer = 0x0:0xffe frame pointer = 0x0:0x0 code segment= base 0x0, limit 0x0, type 0x0 = DPL 0, pres 0, def32 0, gran 0 processor eflags= interrupt enabled, vm86, IOPL = 0 current process = 0 () kernel: type 30 trap, code=0 Stopped at 0xa00: cli db tr (null)(0,0,0,0,0) at 0xa00 ... However, if I enter 'continue' at the DDB prompt it continues to boot and the system seems to runs fine: ... db continue ... Copyright (c) 1992-2003 The FreeBSD Project. ... Now why didn't I think of trying 'continue'? Hey there my old dual Pentium I diskless machine is running in SMP mode. Can you try this patch: http://www.FreeBSD.org/~jhb/patches/atpic.patch Works here, thanks! Btw., I also get such a stray interrupt on my Sun U60, IIRC also from the printer port :) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
INPCB panic....
I removed my wi0 card (with DHCLIENT running), and got the following panic on a -CURRENT from yesterday: Script started on Mon Nov 10 13:23:10 2003 lerlaptop-red# k??[K?? lerlaptop-red# gdb -k kernel.0 vmcore.0 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... panic: from debugger panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc5157040 fault code = supervisor read, page not present instruction pointer = 0x8:0xc06165ba stack pointer = 0x10:0xe1831af4 frame pointer = 0x10:0xe1831b38 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1278 (dhclient) Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc5157040 fault code = supervisor read, page not present instruction pointer = 0x8:0xc06165ba stack pointer = 0x10:0xe1831af4 frame pointer = 0x10:0xe1831b38 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1278 (dhclient) Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc5157040 fault code = supervisor read, page not present instruction pointer = 0x8:0xc06165ba stack pointer = 0x10:0xe1831af4 frame pointer = 0x10:0xe1831b38 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1278 (dhclient) Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc5157040 fault code = supervisor read, page not present instruction pointer = 0x8:0xc06165ba stack pointer = 0x10:0xe1831af4 frame pointer = 0x10:0xe1831b38 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1278 (dhclient) Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc5157040 fault code = supervisor read, page not present instruction pointer = 0x8:0xc06165ba stack pointer = 0x10:0xe1831af4 frame pointer = 0x10:0xe1831b38 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1278 (dhclient) Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc5157040 fault code = supervisor read, page not present instruction pointer = 0x8:0xc06165ba stack pointer = 0x10:0xe1831af4 frame pointer = 0x10:0xe1831b38 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1278 (dhclient) panic: from debugger Fatal trap 3: breakpoint instruction fault while in kernel mode instruction pointer = 0x8:0xc06e4d34 stack pointer = 0x10:0xe1831874 frame pointer = 0x10:0xe1831880 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = IOPL = 0 current process = 1278 (dhclient) panic: from debugger Uptime: 4h10m1s Dumping 503 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 --- Reading symbols from /usr/obj/usr/src/sys/LERLAPTOP/modules/usr/src/sys/modules/linux/linux.ko.d ebug...done. Loaded symbols for /usr/obj/usr/src/sys/LERLAPTOP/modules/usr/src/sys/modules/linux/linux.ko.d ebug #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 240 dumping++; (kgdb) bt #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 #1 0xc0588f02 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372 #2 0xc0589237 in panic () at /usr/src/sys/kern/kern_shutdown.c:550 #3 0xc04720a2 in db_panic () at /usr/src/sys/ddb/db_command.c:450 #4 0xc0472002 in db_command (last_cmdp=0xc07ae580, cmd_table=0x0, aux_cmd_tablep=0xc075e58c, aux_cmd_tablep_end=0xc075e590) at /usr/src/sys/ddb/db_command.c:346 #5 0xc0472145 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472 #6 0xc0475145 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:73 #7 0xc06e4a7c in kdb_trap (type=12, code=0,
Re: Buildworld errors out on libbsnmp
On 2003-11-10 at 15:02:06 Harti Brandt wrote: Sorry, that was my error. I have committed a fix for the library, one for the daemon follows in a couple of minutes as soon as I have verified that it builds the universe. Builds fine here now, too. Thanks for the quick fix! pgp0.pgp Description: PGP signature
Re: New interrupt stuff breaks ASUS 2 CPU system
On Mon, Nov 10, 2003 at 02:12:56PM -0500, John Baldwin wrote: On 10-Nov-2003 John Hay wrote: With the new interrupt code I get: ... OK boot cpuid = 0; apic id = 00 instruction pointer = 0x0:0xa00 stack pointer = 0x0:0xffe frame pointer = 0x0:0x0 code segment= base 0x0, limit 0x0, type 0x0 = DPL 0, pres 0, def32 0, gran 0 processor eflags= interrupt enabled, vm86, IOPL = 0 current process = 0 () kernel: type 30 trap, code=0 Stopped at 0xa00: cli db tr (null)(0,0,0,0,0) at 0xa00 ... However, if I enter 'continue' at the DDB prompt it continues to boot and the system seems to runs fine: ... db continue ... Copyright (c) 1992-2003 The FreeBSD Project. ... Now why didn't I think of trying 'continue'? Hey there my old dual Pentium I diskless machine is running in SMP mode. Can you try this patch: http://www.FreeBSD.org/~jhb/patches/atpic.patch Ah, great, continue is not needed anymore. Now to see if someone can figure out why my dual PII get a panic: probing for non-PCI bus when booting. :-) John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: named pipes memory leak?
On 10 Nov, Lukas Ertl wrote:
Hi,
is there a known problem with named pipes in -CURRENT?
The following shell script freezes a machine in several minutes and needs
a power cycle. You can see the increasing memory in vmstat -z (unpcb) and
netstat -u. The kernel is FreeBSD 5.1-CURRENT Tue Nov 4 14:08:23 CET 2003.
---8---
#/bin/sh
FIFO=/tmp/foo
for i in `jot 5 1`; do
mkfifo ${FIFO}
echo blubb ${FIFO}
kill $!
rm ${FIFO}
done
---8---
If fifo_open() is interrupted, fifo_close() never gets called, and the
resources are not recovered. I wish doing the resource recovery in
fifo_inactive() would have worked ...
Try this patch:
Index: sys/fs/fifofs/fifo_vnops.c
===
RCS file: /home/ncvs/src/sys/fs/fifofs/fifo_vnops.c,v
retrieving revision 1.89
diff -u -r1.89 fifo_vnops.c
--- sys/fs/fifofs/fifo_vnops.c 16 Jun 2003 17:17:09 - 1.89
+++ sys/fs/fifofs/fifo_vnops.c 10 Nov 2003 19:11:00 -
@@ -154,6 +154,26 @@
}
/*
+ * Dispose of fifo resources.
+ * Should be called with vnode locked
+ */
+static void
+fifo_cleanup(struct vnode *vp)
+{
+ struct fifoinfo *fip = vp-v_fifoinfo;
+
+ VI_LOCK(vp);
+ if (vp-v_usecount == 1) {
+ vp-v_fifoinfo = NULL;
+ VI_UNLOCK(vp);
+ (void)soclose(fip-fi_readsock);
+ (void)soclose(fip-fi_writesock);
+ FREE(fip, M_VNODE);
+ } else
+ VI_UNLOCK(vp);
+}
+
+/*
* Open called to set up a new instance of a fifo or
* to find an active instance of a fifo.
*/
@@ -249,6 +269,7 @@
fip-fi_readers--;
if (fip-fi_readers == 0)
socantsendmore(fip-fi_writesock);
+ fifo_cleanup(vp);
return (error);
}
VI_LOCK(vp);
@@ -268,6 +289,7 @@
fip-fi_writers--;
if (fip-fi_writers == 0)
socantrcvmore(fip-fi_readsock);
+ fifo_cleanup(vp);
return (error);
}
/*
@@ -554,15 +576,7 @@
if (fip-fi_writers == 0)
socantrcvmore(fip-fi_readsock);
}
- VI_LOCK(vp);
- if (vp-v_usecount == 1) {
- vp-v_fifoinfo = NULL;
- VI_UNLOCK(vp);
- (void)soclose(fip-fi_readsock);
- (void)soclose(fip-fi_writesock);
- FREE(fip, M_VNODE);
- } else
- VI_UNLOCK(vp);
+ fifo_cleanup(vp);
VOP_UNLOCK(vp, 0, td);
return (0);
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: INPCB panic....
On Monday 10 November 2003 11:37 am, Larry Rosenman wrote: I removed my wi0 card (with DHCLIENT running), and got the following panic on a -CURRENT from yesterday: Thanks. Working on it... Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ddb and usb keyboard
I primarily use a usb keyboard on my PC. After an upgrade this weekend the kernel paniced and went into ddb. Unfortunately the usb keyboard does not work in ddb mode. Thus I can only pull the plug :( MB is a Supermicro P3TDDE with two PIII 800MHz CPU's. Chipset is: # dmesg |grep VIA acpi0: VIA694 AWRDACPI on motherboard agp0: VIA Generic host to PCI bridge mem 0xf000-0xf3ff at device 0.0 on pci0 uhci0: VIA 83C572 USB controller port 0xb800-0xb81f irq 11 at device 17.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhci1: VIA 83C572 USB controller port 0xbc00-0xbc1f irq 11 at device 17.3 on pci0 usb1: VIA 83C572 USB controller on uhci1 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhci2: VIA 83C572 USB controller port 0xc000-0xc01f irq 11 at device 17.4 on pci0 usb2: VIA 83C572 USB controller on uhci2 uhub3: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 keyboard is a Sun Type 6 keyboard. dmesg is attached. Sven Esbjerg Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #0: Tue Oct 28 21:33:03 CET 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/ENZO.DBG Preloaded elf kernel /boot/kernel.old/kernel at 0xc08e1000. Preloaded elf module /boot/kernel.old/acpi.ko at 0xc08e11f8. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel Pentium III (801.82-MHz 686-class CPU) Origin = GenuineIntel Id = 0x683 Stepping = 3 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 1073676288 (1023 MB) avail memory = 1033502720 (985 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00178011, at 0xfec0 Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: VIA694 AWRDACPI on motherboard pcibios: BIOS version 2.10 Using $PIR table, 8 entries at 0xc00fdef0 acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 acpi_cpu0: CPU port 0x530-0x537 on acpi0 acpi_cpu1: CPU port 0x530-0x537 on acpi0 acpi_tz0: Thermal Zone port 0x530-0x537 on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 IOAPIC #0 intpin 11 - irq 2 IOAPIC #0 intpin 10 - irq 5 IOAPIC #0 intpin 5 - irq 10 IOAPIC #0 intpin 12 - irq 11 agp0: VIA Generic host to PCI bridge mem 0xf000-0xf3ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) adv0: AdvanSys ASC3030/50 SCSI controller port 0x9000-0x90ff mem 0xfa221000-0xfa2210ff irq 2 at device 7.0 on pci0 adv0: AdvanSys SCSI Host Adapter, SCSI ID 7, queue depth 16 pcm0: Creative EMU10K1 port 0x9400-0x941f irq 5 at device 8.0 on pci0 pcm0: TriTech TR28602 AC97 Codec pci0: multimedia at device 10.0 (no driver attached) atapci0: Promise PDC20267 UDMA100 controller port 0xac00-0xac3f,0xa800-0xa803,0xa400-0xa407,0xa000-0xa003,0x9c00-0x9c07 mem 0xfa20-0xfa21 irq 5 at device 12.0 on pci0 atapci0: [MPSAFE] ata2: at 0x9c00 on atapci0 ata2: [MPSAFE] ata3: at 0xa400 on atapci0 ata3: [MPSAFE] fxp0: Intel 82559 Pro/100 Ethernet port 0xb000-0xb03f mem 0xfa10-0xfa1f,0xfa22-0xfa220fff irq 11 at device 13.0 on pci0 fxp0: Ethernet address 00:30:48:41:b9:ba miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: PCI-ISA bridge at device 17.0 on pci0 isa0: ISA bus on isab0 atapci1: VIA 8233 UDMA100 controller port 0xb400-0xb40f at device 17.1 on pci0 ata0: at 0x1f0 irq 14 on atapci1 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci1 ata1: [MPSAFE] uhci0: VIA 83C572 USB controller port 0xb800-0xb81f irq 11 at device 17.2 on pci0 uhci0: LegSup = 0x2010 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhub0: port error, restarting port 1 uhub0: port error, giving up port 1 uhub1: Texas Instruments TUSB2046 hub, class 9/0, rev 1.10/1.25, addr 2 uhub1: 4 ports with 4 removable, self powered ugen0: OmniVision OV511+ Camera, rev 1.00/1.00, addr 3 uhub0: port error, restarting port 2 uhub0: port error, giving up port 2 ums0: Logitech USB Mouse, rev 1.10/6.10, addr 4, iclass 3/1 ums0: 4 buttons and Z dir. uhci1: VIA 83C572 USB controller port 0xbc00-0xbc1f irq 11 at device 17.3 on pci0 uhci1: LegSup = 0x2010 usb1: VIA 83C572
RE: panic: probing for non-PCI bus
On 10-Nov-2003 John Hay wrote: Hi, Upgrading a Asus P2L97-DS dual Pentium II 266MHz box, I got this panic when booting: Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS drive D: is disk2 BIOS drive E: is disk3 BIOS 640kB/130036kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 ([EMAIL PROTECTED], Sun Nov 2 14:16:55 SAST 2003) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x23372c data=0x27fcc+0x47494 syms=[0x4+0x31690+0x4+0x3de08] /boot/kernel/if_vlan.ko text=0x22b0 data=0x1d8+0x5c syms=[0x4+0x620+0x4+0x573] /boot/kernel/if_fxp.ko text=0x77c0 data=0xfd4+0xc syms=[0x4+0xc50+0x4+0xceb] loading required module 'miibus' /boot/kernel/miibus.ko text=0x15940 data=0xc84+0x68 syms=[0x4+0x1a90+0x4+0x2240] /boot/kernel/usb.ko text=0x201e8 data=0xb4c+0x148 syms=[0x4+0x2ad0+0x4+0x30bb] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #50: Mon Nov 10 17:51:13 SAST 2003 [EMAIL PROTECTED]:/b/src/sys/i386/compile/BEAST Preloaded elf kernel /boot/kernel/kernel at 0xc0768000. Preloaded elf module /boot/kernel/if_vlan.ko at 0xc076821c. Preloaded elf module /boot/kernel/if_fxp.ko at 0xc07682c8. Preloaded elf module /boot/kernel/miibus.ko at 0xc0768374. Preloaded elf module /boot/kernel/usb.ko at 0xc0768420. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Pentium II/Pentium II Xeon/Celeron (267.27-MHz 686-class CPU) Origin = GenuineIntel Id = 0x633 Stepping = 3 Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,MMX real memory = 134205440 (127 MB) avail memory = 125018112 (119 MB) MPTable: OEM0 PROD FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 1 cpu1 (AP): APIC ID: 0 ioapic0: Assuming intbase of 0 ioapic0 Version 1.1 irqs 0-23 on motherboard Pentium Pro MTRR support enabled acpi0: ASUS P2L97-DS on motherboard pcibios: BIOS version 2.10 Using $PIR table, 7 entries at 0xc00f0d20 acpi0: Power Button (fixed) Timecounter ACPI-safe frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: slot 4 INTD is routed to irq 5 pcib0: slot 6 INTA is routed to irq 5 pcib0: slot 10 INTA is routed to irq 12 pcib0: slot 11 INTA is routed to irq 10 pcib0: slot 12 INTA is routed to irq 11 panic: probing for non-PCI bus cpuid = 0; Uptime: 1s Shutting down ACPI Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... Can you provide a copy of your mptable? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic on mount_cd9660
FreeBSD hood.oook.cz 5.1-CURRENT FreeBSD 5.1-CURRENT #6: Mon Nov 10
20:26:12 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PAV i386
What I did:
1) insert SVCD in the CD-ROM drive
2) play some tracks from it. note /dev/acd0t1 /dev/acd0t2 etc...
3) remove SVCD from the CD-ROM drive
4) put data CD in the CD-ROM drive
5) mount_cd9660 /dev/acd0 /mnt/cdrom
What I got:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x1c
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc05a3073
stack pointer = 0x10:0xcdce6c68
frame pointer = 0x10:0xcdce6c80
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 2 (g_event)
trap number = 12
panic: page fault
cpuid = 0;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc0585991 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc0585ddf in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc06f6e96 in trap_fatal (frame=0xcdce6c28, eva=0) at
/usr/src/sys/i386/i386/trap.c:821
#4 0xc06f6b12 in trap_pfault (frame=0xcdce6c28, usermode=0, eva=28) at
/usr/src/sys/i386/i386/trap.c:735
#5 0xc06f6665 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi = -1025300736, tf_ebp =
-842109824, tf_isp = -842109868, tf_ebx = -1008189440, tf_edx = 0, tf_ecx =
-1065601612, tf_eax = 1, tf_trapno = 12, tf_err = 0, tf_eip = -1067831181, tf_cs = 8,
tf_eflags = 66055, tf_esp = -1018716544, tf_ss = -842109800}) at
/usr/src/sys/i386/i386/trap.c:420
#6 0xc06e2548 in calltrap () at {standard input}:94
#7 0xc054bf48 in g_destroy_provider (pp=0xc3e84000) at
/usr/src/sys/geom/geom_subr.c:416
#8 0xc0548f25 in g_orphan_register (pp=0xc2e32700) at
/usr/src/sys/geom/geom_event.c:143
#9 0xc054904c in one_event () at /usr/src/sys/geom/geom_event.c:169
#10 0xc0549275 in g_run_events () at /usr/src/sys/geom/geom_event.c:202
#11 0xc054a2a5 in g_event_procbody () at /usr/src/sys/geom/geom_kern.c:134
#12 0xc056dff0 in fork_exit (callout=0xc054a280 g_event_procbody, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:793
(kgdb) up 7
#7 0xc054bf48 in g_destroy_provider (pp=0xc3e84000) at
/usr/src/sys/geom/geom_subr.c:416
416 devstat_remove_entry(pp-stat);
(kgdb) list
411 KASSERT (pp-acw == 0, (g_destroy_provider with acw));
412 KASSERT (pp-acw == 0, (g_destroy_provider with ace));
413 g_cancel_event(pp);
414 LIST_REMOVE(pp, provider);
415 gp = pp-geom;
416 devstat_remove_entry(pp-stat);
417 g_free(pp);
418 if ((gp-flags G_GEOM_WITHER))
419 g_wither_geom(gp, 0);
420 }
(kgdb) print pp
$1 = (struct g_provider *) 0xc3e84000
(kgdb) print *pp
$2 = {name = 0x0, provider = {le_next = 0x0, le_prev = 0x0}, geom = 0x0, consumers =
{lh_first = 0x0}, acr = 0, acw = 0, ace = 0, error = 0, orphan = {tqe_next = 0x0,
tqe_prev = 0x0}, index = 0,
mediasize = 0, sectorsize = 0, stripesize = 0, stripeoffset = 0, stat = 0x0, nstart
= 0, nend = 0, flags = 0}
--
Pav Lucistnik [EMAIL PROTECTED]
What do we know about love? Love is like a pear. Pear is sweet and have
a specific shape. Try to exactly define the shape of a pear.
-- Marigold: 50 Years Of Poetry
signature.asc
Description: Toto je =?iso-8859-2?Q?digit=E1ln=EC?= =?ISO-8859-1?Q?_podepsan=E1?= =?iso-8859-2?Q?_=E8=E1st?= =?ISO-8859-1?Q?_zpr=E1vy?=
Re: Problem on a laptop with current
On Mon, 2003-11-10 at 18:17, Doug White wrote: On Sun, 9 Nov 2003, Yannick FAHAM wrote: I have recently bought a centrino laptop and tried to install current on it. the fact is my network card is only supported in this branche (broadcom 4401). Broadcom wireless cards are not supported in -CURRENT. after compiling the kernel, the boot process freeze on the hardware enumeration. I have disabled acpi and boot in verbose mode and I have many errors message like (probe0)... Error 22. Sorry for my english, i'm french. Could you post the dmesg you're getting? This isn't enough to tell... Sorry, I can't save the output because of the hangs. The error on probe was about the sbp module, so I have disable when building the kernel. I have no error any more but the boot still stop after : ... ... Mounting root from ufs:/dev/ad0s1a start_init: trying /sbin/init -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic on mount_cd9660
On Mon, 10 Nov 2003, Pav Lucistnik wrote:
#7 0xc054bf48 in g_destroy_provider (pp=0xc3e84000) at
/usr/src/sys/geom/geom_subr.c:416
#8 0xc0548f25 in g_orphan_register (pp=0xc2e32700) at
/usr/src/sys/geom/geom_event.c:143
#9 0xc054904c in one_event () at /usr/src/sys/geom/geom_event.c:169
#10 0xc0549275 in g_run_events () at /usr/src/sys/geom/geom_event.c:202
#11 0xc054a2a5 in g_event_procbody () at /usr/src/sys/geom/geom_kern.c:134
#12 0xc056dff0 in fork_exit (callout=0xc054a280 g_event_procbody, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:793
(kgdb) up 7
#7 0xc054bf48 in g_destroy_provider (pp=0xc3e84000) at
/usr/src/sys/geom/geom_subr.c:416
416 devstat_remove_entry(pp-stat);
(kgdb) print pp
$1 = (struct g_provider *) 0xc3e84000
(kgdb) print *pp
$2 = {name = 0x0, provider = {le_next = 0x0, le_prev = 0x0}, geom = 0x0, consumers =
{lh_first = 0x0}, acr = 0, acw = 0, ace = 0, error = 0, orphan = {tqe_next = 0x0,
tqe_prev = 0x0}, index = 0,
mediasize = 0, sectorsize = 0, stripesize = 0, stripeoffset = 0, stat = 0x0,
nstart = 0, nend = 0, flags = 0}
What does pp look like in frame 8?
regards,
le
--
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator Tel.: (+43 1) 4277-14073
Vienna University Computer Center Fax.: (+43 1) 4277-9140
University of Vienna http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New interrupt stuff breaks ASUS 2 CPU system
On 10-Nov-2003 John Hay wrote: On Mon, Nov 10, 2003 at 02:12:56PM -0500, John Baldwin wrote: On 10-Nov-2003 John Hay wrote: With the new interrupt code I get: ... OK boot cpuid = 0; apic id = 00 instruction pointer = 0x0:0xa00 stack pointer = 0x0:0xffe frame pointer = 0x0:0x0 code segment= base 0x0, limit 0x0, type 0x0 = DPL 0, pres 0, def32 0, gran 0 processor eflags= interrupt enabled, vm86, IOPL = 0 current process = 0 () kernel: type 30 trap, code=0 Stopped at 0xa00: cli db tr (null)(0,0,0,0,0) at 0xa00 ... However, if I enter 'continue' at the DDB prompt it continues to boot and the system seems to runs fine: ... db continue ... Copyright (c) 1992-2003 The FreeBSD Project. ... Now why didn't I think of trying 'continue'? Hey there my old dual Pentium I diskless machine is running in SMP mode. Can you try this patch: http://www.FreeBSD.org/~jhb/patches/atpic.patch Ah, great, continue is not needed anymore. Now to see if someone can figure out why my dual PII get a panic: probing for non-PCI bus when booting. :-) Actually, can you try spurious.patch (same URL directory) instead and see if that is sufficient to fix it? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
-CURRENT and -STABLE fails on IBM R30 in agp_ali.c
Hello,
there is a problem in ali_agp.c (both, -CURRENT and -STABLE): If I
boot the generic kernel, it panics in agp_ali.c, when it tries to
allocate memory for the gatt. Some simlpe tests showed, that the
initial aperture size is reported as zero by the device:
static int
agp_ali_attach(device_t dev)
{
struct agp_ali_softc *sc = device_get_softc(dev);
struct agp_gatt *gatt;
int error;
error = agp_generic_attach(dev);
if (error)
return error;
sc-initial_aperture = AGP_GET_APERTURE(dev);
This is zero-^^
for (;;) {
gatt = agp_alloc_gatt(dev);
if (gatt)
break;
/*
* Probably contigmalloc failure. Try reducing the
* aperture so that the gatt size reduces.
*/
if (AGP_SET_APERTURE(dev, AGP_GET_APERTURE(dev) / 2)) {
agp_generic_detach(dev);
return ENOMEM;
}
}
sc-gatt = gatt;
/* Install the gatt. */
Since I don't have a machine ready running -CURRENT, I can't really
debug this. How can I disable agp0 on boot time?
Björn Fischer
--
-BEGIN GEEK CODE BLOCK-
GCS d--(+) s++: a- C+++(-) UBOSI$ P+++(-) L---(++) !E W- N+ o+
K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+
--END GEEK CODE BLOCK--
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: named pipes memory leak?
On Mon, 10 Nov 2003, Don Lewis wrote:
On 10 Nov, Lukas Ertl wrote:
The following shell script freezes a machine in several minutes and needs
a power cycle. You can see the increasing memory in vmstat -z (unpcb) and
netstat -u. The kernel is FreeBSD 5.1-CURRENT Tue Nov 4 14:08:23 CET 2003.
---8---
#/bin/sh
FIFO=/tmp/foo
for i in `jot 5 1`; do
mkfifo ${FIFO}
echo blubb ${FIFO}
kill $!
rm ${FIFO}
done
---8---
If fifo_open() is interrupted, fifo_close() never gets called, and the
resources are not recovered. I wish doing the resource recovery in
fifo_inactive() would have worked ...
Try this patch:
Thanks, your patch seems so solve this problem effectively.
regards,
le
--
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator Tel.: (+43 1) 4277-14073
Vienna University Computer Center Fax.: (+43 1) 4277-9140
University of Vienna http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic on mount_cd9660
V po, 10. 11. 2003 v 22:10, Pav Lucistnik pe:
It's reproducable! Just play any SVCD, then replace it with data CD and
try to access it. This time I panicked it by running
cdcontrol -f /dev/acd0 info
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x1c
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc05a3073
stack pointer = 0x10:0xcdce6c68
frame pointer = 0x10:0xcdce6c80
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 2 (g_event)
trap number = 12
panic: page fault
cpuid = 0;
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc0585991 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc0585ddf in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc06f6e96 in trap_fatal (frame=0xcdce6c28, eva=0) at
/usr/src/sys/i386/i386/trap.c:821
#4 0xc06f6b12 in trap_pfault (frame=0xcdce6c28, usermode=0, eva=28) at
/usr/src/sys/i386/i386/trap.c:735
#5 0xc06f6665 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi = -1025300736, tf_ebp =
-842109824, tf_isp = -842109868, tf_ebx = -1025232416, tf_edx = 0, tf_ecx =
-1065601612, tf_eax = 1, tf_trapno = 12, tf_err = 0, tf_eip = -1067831181, tf_cs = 8,
tf_eflags = 66051, tf_esp = -1015861888, tf_ss = -842109800}) at
/usr/src/sys/i386/i386/trap.c:420
#6 0xc06e2548 in calltrap () at {standard input}:94
#7 0xc054bf48 in g_destroy_provider (pp=0xc2e431e0) at
/usr/src/sys/geom/geom_subr.c:416
#8 0xc0548f25 in g_orphan_register (pp=0xc2e32700) at
/usr/src/sys/geom/geom_event.c:143
#9 0xc054904c in one_event () at /usr/src/sys/geom/geom_event.c:169
#10 0xc0549275 in g_run_events () at /usr/src/sys/geom/geom_event.c:202
#11 0xc054a2a5 in g_event_procbody () at /usr/src/sys/geom/geom_kern.c:134
#12 0xc056dff0 in fork_exit (callout=0xc054a280 g_event_procbody, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:793
(kgdb) up 7
#7 0xc054bf48 in g_destroy_provider (pp=0xc2e431e0) at
/usr/src/sys/geom/geom_subr.c:416
416 devstat_remove_entry(pp-stat);
(kgdb) print pp-stat
$1 = (struct devstat *) 0x0
(kgdb) print *pp
$2 = {name = 0x0, provider = {le_next = 0x0, le_prev = 0x0}, geom = 0x0, consumers =
{lh_first = 0x0}, acr = 0, acw = 0, ace = 0, error = 0, orphan = {tqe_next = 0x0,
tqe_prev = 0x0}, index = 0,
mediasize = 0, sectorsize = 0, stripesize = 0, stripeoffset = 0, stat = 0x0, nstart
= 0, nend = 0, flags = 0}
(kgdb) up
#8 0xc0548f25 in g_orphan_register (pp=0xc2e32700) at
/usr/src/sys/geom/geom_event.c:143
143 g_destroy_provider(pp);
(kgdb) print *pp
$3 = {name = 0xc2da2250 acd0, provider = {le_next = 0xc07653e0, le_prev = 0x0}, geom
= 0xc0765404, consumers = {lh_first = 0x0}, acr = -1015831040, acw = -1025385856, ace
= -1025298920, error = 1,
orphan = {tqe_next = 0xc04925a0, tqe_prev = 0x0}, index = 0, mediasize = 3226015152,
sectorsize = 3226015776, stripesize = 3268839424, stripeoffset = 0, stat = 0x0, nstart
= 0, nend = 0, flags = 0}
--
Pav Lucistnik [EMAIL PROTECTED]
What do we know about love? Love is like a pear. Pear is sweet and have
a specific shape. Try to exactly define the shape of a pear.
-- Marigold: 50 Years Of Poetry
signature.asc
Description: Toto je =?iso-8859-2?Q?digit=E1ln=EC?= =?ISO-8859-1?Q?_podepsan=E1?= =?iso-8859-2?Q?_=E8=E1st?= =?ISO-8859-1?Q?_zpr=E1vy?=
Re: panic on mount_cd9660
On Mon, 10 Nov 2003, Pav Lucistnik wrote:
V po, 10. 11. 2003 v 22:24, Lukas Ertl pí?e:
On Mon, 10 Nov 2003, Pav Lucistnik wrote:
#7 0xc054bf48 in g_destroy_provider (pp=0xc3e84000) at
/usr/src/sys/geom/geom_subr.c:416
#8 0xc0548f25 in g_orphan_register (pp=0xc2e32700) at
/usr/src/sys/geom/geom_event.c:143
#9 0xc054904c in one_event () at /usr/src/sys/geom/geom_event.c:169
#10 0xc0549275 in g_run_events () at /usr/src/sys/geom/geom_event.c:202
#11 0xc054a2a5 in g_event_procbody () at /usr/src/sys/geom/geom_kern.c:134
#12 0xc056dff0 in fork_exit (callout=0xc054a280 g_event_procbody, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:793
(kgdb) up 7
#7 0xc054bf48 in g_destroy_provider (pp=0xc3e84000) at
/usr/src/sys/geom/geom_subr.c:416
416 devstat_remove_entry(pp-stat);
(kgdb) print pp
$1 = (struct g_provider *) 0xc3e84000
(kgdb) print *pp
$2 = {name = 0x0, provider = {le_next = 0x0, le_prev = 0x0}, geom = 0x0,
consumers = {lh_first = 0x0}, acr = 0, acw = 0, ace = 0, error = 0, orphan =
{tqe_next = 0x0, tqe_prev = 0x0}, index = 0,
mediasize = 0, sectorsize = 0, stripesize = 0, stripeoffset = 0, stat = 0x0,
nstart = 0, nend = 0, flags = 0}
What does pp look like in frame 8?
$1 = {name = 0xc2da2250 acd0, provider = {le_next = 0xc07653e0, le_prev = 0x0},
geom = 0xc0765404, consumers = {lh_first = 0x0}, acr = -1017072896, acw =
-1025385856, ace = -1025380968, error = 1,
orphan = {tqe_next = 0xc04925a0, tqe_prev = 0x0}, index = 0, mediasize =
3226015152, sectorsize = 3226015776, stripesize = 3268839424, stripeoffset = 0, stat
= 0x0, nstart = 0, nend = 0, flags = 0}
There's something seriously foobared... is this panic repeatable or was it
a one timer? ATAPI CD was GEOMified just a week ago, so there might
still be some bugs in.
regards,
le
--
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator Tel.: (+43 1) 4277-14073
Vienna University Computer Center Fax.: (+43 1) 4277-9140
University of Vienna http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
LOR in route.c
New /usr/src from around 4:30PM EST: Mon Nov 10 17:16:14 EST 2003 lock order reversal 1st 0xc6761890 rtentry (rtentry) @ /opt/src/sys/net/route.c:182 2nd 0xc668687c radix node head (radix node head) @ /opt/src/sys/net/route.c:565 Stack backtrace: -Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: INPCB panic....
In message [EMAIL PROTECTED], Sam Leffler writes:
On Monday 10 November 2003 11:37 am, Larry Rosenman wrote:
I removed my wi0 card (with DHCLIENT running), and got the following panic
on a -CURRENT from yesterday:
Thanks. Working on it...
FYI, I've been using the following patch locally which seems to
trigger the printf sometimes when wi0 is ejected. Without the patch,
it used to dereference a stale struct ifnet and crash. I have an
approx 1 week old kernel, so this particular problem may have been
fixed already.
Ian
Index: in_pcb.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/netinet/in_pcb.c,v
retrieving revision 1.125
diff -u -r1.125 in_pcb.c
--- in_pcb.c1 Nov 2003 07:30:07 - 1.125
+++ in_pcb.c3 Nov 2003 00:52:41 -
@@ -564,10 +564,12 @@
* destination, in case of sharing the cache with IPv6.
*/
ro = inp-inp_route;
- if (ro-ro_rt
- (ro-ro_dst.sa_family != AF_INET ||
-satosin(ro-ro_dst)-sin_addr.s_addr != faddr.s_addr ||
-inp-inp_socket-so_options SO_DONTROUTE)) {
+ if (ro-ro_rt ((ro-ro_rt-rt_flags RTF_UP) == 0 ||
+ ro-ro_dst.sa_family != AF_INET ||
+ satosin(ro-ro_dst)-sin_addr.s_addr != faddr.s_addr ||
+ inp-inp_socket-so_options SO_DONTROUTE)) {
+ if ((ro-ro_rt-rt_flags RTF_UP) == 0)
+ printf(clearing non-RTF_UP route\n);
RTFREE(ro-ro_rt);
ro-ro_rt = (struct rtentry *)0;
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR in route.c
On Mon, Nov 10, 2003 at 05:19:06PM -0500, Steve Ames wrote: New /usr/src from around 4:30PM EST: Mon Nov 10 17:16:14 EST 2003 lock order reversal 1st 0xc6761890 rtentry (rtentry) @ /opt/src/sys/net/route.c:182 2nd 0xc668687c radix node head (radix node head) @ /opt/src/sys/net/route.c:565 Stack backtrace: Make that two: Mon Nov 10 17:16:14 EST 2003 lock order reversal 1st 0xc6761890 rtentry (rtentry) @ /opt/src/sys/net/route.c:182 2nd 0xc668687c radix node head (radix node head) @ /opt/src/sys/net/route.c:565 Stack backtrace: lock order reversal 1st 0xc695a590 rtentry (rtentry) @ /opt/src/sys/net/route.c:744 2nd 0xc06da034 route cache (route cache) @ /opt/src/sys/netinet/ip_input.c:348 3rd 0xc695a690 rtentry (rtentry) @ /opt/src/sys/netinet/ip_input.c:352 Stack backtrace: ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: named pipes memory leak?
On 10 Nov, Lukas Ertl wrote:
On Mon, 10 Nov 2003, Don Lewis wrote:
On 10 Nov, Lukas Ertl wrote:
The following shell script freezes a machine in several minutes and needs
a power cycle. You can see the increasing memory in vmstat -z (unpcb) and
netstat -u. The kernel is FreeBSD 5.1-CURRENT Tue Nov 4 14:08:23 CET 2003.
---8---
#/bin/sh
FIFO=/tmp/foo
for i in `jot 5 1`; do
mkfifo ${FIFO}
echo blubb ${FIFO}
kill $!
rm ${FIFO}
done
---8---
If fifo_open() is interrupted, fifo_close() never gets called, and the
resources are not recovered. I wish doing the resource recovery in
fifo_inactive() would have worked ...
Try this patch:
Thanks, your patch seems so solve this problem effectively.
The patch has been committed. Thanks for testing it.
BTW, I encountered a process leak when running your script. The kill
would sometimes fail to find the process, maybe about 10% of the time. I
think maybe $! hadn't yet been updated and the shell was trying to kill
the previous echo process a second time. The mkfifo would also fail
sometimes because the file already existed. I think what the background
shell didn't get around to opening the fifo until after rm had nuked it
causing a plain file to get created. Hmn, these events seemed to be
associated, so maybe the shell was creating a file and the next echo
command would write to the file and exit before the kill command was
executed. This doesn't explain all those copies of sh stuck in the
fifow state, though. Adding a sleep 1 before the kill command seems
to make things work better.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: INPCB panic....
On Monday 10 November 2003 02:19 pm, Ian Dowse wrote: In message [EMAIL PROTECTED], Sam Leffler writes: On Monday 10 November 2003 11:37 am, Larry Rosenman wrote: I removed my wi0 card (with DHCLIENT running), and got the following panic on a -CURRENT from yesterday: Thanks. Working on it... FYI, I've been using the following patch locally which seems to trigger the printf sometimes when wi0 is ejected. Without the patch, it used to dereference a stale struct ifnet and crash. I have an approx 1 week old kernel, so this particular problem may have been fixed already. Your fix looks fine; please commit. It mimics what ip_output does. But there still look to be basic races with device removal/ifnet destruction. For example, ip_output grabs an ifnet reference from the routing table entry and uses it w/o any locking for a rather long time. If the device gets yanked in the interim it seems like you could be left holding a bogus reference. Seems like the whole if_detach path needs a careful rework. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR in route.c
On Monday 10 November 2003 02:27 pm, Steve Ames wrote: On Mon, Nov 10, 2003 at 05:19:06PM -0500, Steve Ames wrote: New /usr/src from around 4:30PM EST: Mon Nov 10 17:16:14 EST 2003 lock order reversal 1st 0xc6761890 rtentry (rtentry) @ /opt/src/sys/net/route.c:182 2nd 0xc668687c radix node head (radix node head) @ /opt/src/sys/net/route.c:565 Stack backtrace: Make that two: Mon Nov 10 17:16:14 EST 2003 lock order reversal 1st 0xc6761890 rtentry (rtentry) @ /opt/src/sys/net/route.c:182 2nd 0xc668687c radix node head (radix node head) @ /opt/src/sys/net/route.c:565 Stack backtrace: lock order reversal 1st 0xc695a590 rtentry (rtentry) @ /opt/src/sys/net/route.c:744 2nd 0xc06da034 route cache (route cache) @ /opt/src/sys/netinet/ip_input.c:348 3rd 0xc695a690 rtentry (rtentry) @ /opt/src/sys/netinet/ip_input.c:352 Stack backtrace: These go away with forthcoming changes (so I've ignored them). Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR in route.c
On Mon, Nov 10, 2003 at 02:43:11PM -0800, Sam Leffler wrote: On Monday 10 November 2003 02:27 pm, Steve Ames wrote: On Mon, Nov 10, 2003 at 05:19:06PM -0500, Steve Ames wrote: New /usr/src from around 4:30PM EST: Mon Nov 10 17:16:14 EST 2003 lock order reversal 1st 0xc6761890 rtentry (rtentry) @ /opt/src/sys/net/route.c:182 2nd 0xc668687c radix node head (radix node head) @ /opt/src/sys/net/route.c:565 Stack backtrace: Make that two: Mon Nov 10 17:16:14 EST 2003 lock order reversal 1st 0xc6761890 rtentry (rtentry) @ /opt/src/sys/net/route.c:182 2nd 0xc668687c radix node head (radix node head) @ /opt/src/sys/net/route.c:565 Stack backtrace: lock order reversal 1st 0xc695a590 rtentry (rtentry) @ /opt/src/sys/net/route.c:744 2nd 0xc06da034 route cache (route cache) @ /opt/src/sys/netinet/ip_input.c:348 3rd 0xc695a690 rtentry (rtentry) @ /opt/src/sys/netinet/ip_input.c:352 Stack backtrace: These go away with forthcoming changes (so I've ignored them). Good 'nuff. Thanks for the fast response! -Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: --- trap 0x1, eip = 0, esp = 0xd77cdd7c, ebp = 0 ---
On Mon, Nov 10, 2003 at 01:08:30PM +1030, Kris Kennaway wrote: On Mon, Nov 10, 2003 at 12:51:21PM +1030, Alex Wilkinson wrote: Not sure how to interpret these errors on the console ?? Running: FreeBSD 5.1-CURRENT #4: Thu Nov 6 16:49:21 CST 2003 Part of a backtrace from an error detected by WITNESS. There was more above that that you didn't post. Kris or anyone, What can I do to deal with this errror ? From the console this is the error that appears: backtrace(c0883a21,c0971e6c,c088a4f4,c088a4f4,c088b844) at backtrace+0x17 witness_lock(c0971e6c,8,c088b844,26d,d77cda24) at witness_lock+0x672 _mtx_lock_flags(c0971e6c,0,c088b844,26d,0) at _mtx_lock_flags+0xba tcp_usr_rcvd(c4e66000,80,c0690520,c0884028,3b9aca00) at tcp_usr_rcvd+0x30 soreceive(c4e66000,d77cda98,d77cdaa4,d77cda9c,0) at soreceive+0x8ef nfsrv_rcv(c4e66000,c4e26780,4,28,60f4) at nfsrv_rcv+0x87 sowakeup(c4e66000,c4e6604c,c088af2f,446,108) at sowakeup+0x91 tcp_input(c1d32900,14,c094b5d0,c094a820,2b3) at tcp_input+0x133e ip_input(c1d32900,0,c08891b3,89,0) at ip_input+0x92a netisr_processqueue(c09700d0,0,c08891b3,e5,c46f70c0) at netisr_processqueue+0x8e swi_net(0,0,c087e536,21f,c1d211e4) at swi_net+0x98 ithread_loop(c1d18580,d77cdd48,c087e39c,311,1) at ithread_loop+0x192 fork_exit(c0656420,c1d18580,d77cdd48) at fork_exit+0xb4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd77cdd7c, ebp = 0 --- Thanks - aW ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: taskqueue patch
On Mon, Nov 10, 2003 at 09:02:03AM +, Doug Rabson wrote: I wasn't involved in converting taskqueue from 4.x-style SWIs to kernel threads so I can't be sure but this does look reasonable. I've been wondering about the 'not exiting' diagnostic from init for a while myself. Hi Doug, What are SWIs ? - aW ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: taskqueue patch
* Alex Wilkinson [EMAIL PROTECTED] [031110 15:44] wrote: On Mon, Nov 10, 2003 at 09:02:03AM +, Doug Rabson wrote: I wasn't involved in converting taskqueue from 4.x-style SWIs to kernel threads so I can't be sure but this does look reasonable. I've been wondering about the 'not exiting' diagnostic from init for a while myself. Hi Doug, What are SWIs ? software interrupts. - aW -- - Alfred Perlstein - Research Engineering Development Inc. - email: [EMAIL PROTECTED] cell: 408-480-4684 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: erroneous message from locked-up machine
Can someone please elaborate on the acronym KVA ?
$ sysctl -d kern.ipc.maxpipekva
kern.ipc.maxpipekva: Pipe KVA limit
This doesn't tell me enough.
- aW
On Tue, Nov 11, 2003 at 04:46:47AM +1100, Bruce Evans wrote:
I came in to work today to find one of my -current machines unable to
open a pipe. (This probably had a lot to do with the spamd that went
stark raving nutters overnight, but that's a separate problem.) A
power cycle fixed the problem, but /var/log/messages was filled with:
Nov 10 11:05:44 bewilderbeast kernel: kern.maxpipekva exceeded, please see
tuning(7).
Interesting.
bewilderbeast~;sysctl kern.maxpipekva
sysctl: unknown oid 'kern.maxpipekva'
bewilderbeast~;
The following patch fixes this and some nearby style bugs:
- source style bug: line too line
- output style bugs: comma splice, verboseness (helps make the source line
too long), and kernel message terminated with a ..
%%%
Index: sys_pipe.c
===
RCS file: /home/ncvs/src/sys/kern/sys_pipe.c,v
retrieving revision 1.158
diff -u -2 -r1.158 sys_pipe.c
--- sys_pipe.c9 Nov 2003 09:17:24 - 1.158
+++ sys_pipe.c10 Nov 2003 17:21:47 -
@@ -331,5 +331,5 @@
if (error != KERN_SUCCESS) {
if (ppsratecheck(lastfail, curfail, 1))
- printf(kern.maxpipekva exceeded, please see
tuning(7).\n);
+ printf(kern.ipc.maxpipekva exceeded; see
tuning(7)\n);
return (ENOMEM);
}
%%%
And tuning(7) doesn't mention this, either.
Is this just work-in-progress, or did someone forget to commit something?
Seems like tuning pipe kva is completely absent in tuning(7) (so the above
message can be shortened further). You can tune kva generally as documented
there, but the pipe limit is separate.
PS: Lesson of the day: no pipe KVA, no su. Great fun on remote
machines! :-)
It's interesting that su was the point of failure. It uses a pipe hack
for IPC. Otherwise it doesn't use pipes, at least direectly. It
shouldn't need to use the pipe hack. My version uses signals instead.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: APIC-UP related panic
On Monday 10 November 2003 19:33, John Baldwin wrote: On 08-Nov-2003 Harald Schmalzbauer wrote: On Thursday 06 November 2003 17:33, John Baldwin wrote: On 06-Nov-2003 Harald Schmalzbauer wrote: Hello, I have one reproducable panic with sources from 04. Nov when enabling device apic in the kernel. While building OpenOffice about 1 1/2 hours after start the system reboots. This is absolutely reproducable. Removing device apic from the kernel solves the problem! *SNIP* Can you try the patch at http://www.FreeBSD.org/~jhb/patches/spurious.patch Regrettably this hasn't helped. The machine crashed aigain when building OpenOffice. This time I have something different in messages: Nov 7 19:51:27 cale syslogd: kernel boot file is /boot/kernel/kernel Nov 7 19:51:27 cale kernel: panic: Couldn't get vector from ISR! Nov 7 19:51:27 cale kernel: Nov 7 19:51:27 cale kernel: syncing disks, buffers remaining... 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 Nov 7 19:51:27 cale kernel: giving up on 1109 buffers Nov 7 19:51:27 cale kernel: Uptime: 3h57m51s Nov 7 19:51:27 cale kernel: Shutting down ACPI Nov 7 19:51:27 cale kernel: Automatic reboot in 15 seconds - press a key on the console to abort Nov 7 19:51:27 cale kernel: Rebooting... Let me know if I can help. Should I build a debug-kernel? I think that doesn't help too much since the machine rebootos immediately, so I have no chance to type anything like trace. Ok. The problem is that when the spurious interrupt is triggered, it doesn't set a bit in the ISR. Hmm, can you try using 'options NO_MIXED_MODE' instead? Uhm, I don't really understand what's going on. Also I haven't found anything about NO_MIXED_MODE but I made the usual kernel (-current from Nov.09, without the spurious patch) with device apic and options NO_MIXED_MODE. Now quake2forge compiled successfully (which also crashed the machine with the last apic kernel) also OpenOffice compiles fine. I see one difference in dmesg: Timecounter shows now ACPI-fast like with a previous SMP-kernel instead of ACPI-safe like wth the UP kernel. Just for info attached the new dmesg. Do you have any enlightning link for me about apic and NO_MIXED_MODE? Thanks a lot, -Harry Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #37: Tue Nov 11 01:20:26 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CALE Preloaded elf kernel /boot/kernel/kernel at 0xc09c1000. Preloaded elf module /boot/kernel/linux.ko at 0xc09c1244. Preloaded elf module /boot/kernel/nvidia.ko at 0xc09c12f0. ACPI APIC Table: D815EA EA81510A Timecounter i8254 frequency 1183579 Hz quality 0 CPU: Intel(R) Celeron(TM) CPU1100MHz (1095.82-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6b1 Stepping = 1 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 268173312 (255 MB) avail memory = 250781696 (239 MB) ioapic0: Changing APIC ID to 1 ioapic0 Version 2.0 irqs 0-23 on motherboard Pentium Pro MTRR support enabled VESA: v3.0, 65536k memory, flags:0x1, mode table:0xc07603e2 (122) VESA: NVIDIA acpi0: D815EA D815EPFV on motherboard pcibios: BIOS version 2.10 Using $PIR table, 12 entries at 0xc00f2a10 acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 acpi_cpu0: CPU port 0x530-0x537 on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci2: PCI bus on pcib1 pcib1: slot 0 INTA is routed to irq 16 nvidia0: GeForce4 MX 440 with AGP8X mem 0xf000-0xf3ff,0xfd00-0xfdff irq 16 at device 0.0 on pci2 pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pci1: ACPI PCI bus on pcib2 fxp0: Intel 82801BA/CAM (ICH2/3) Pro/100 Ethernet port 0xdf00-0xdf3f mem 0xfc9ff000-0xfc9f irq 20 at device 8.0 on pci1 fxp0: Ethernet address 00:03:47:f0:c2:ef miibus0: MII bus on fxp0 inphy0: i82562ET 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH2 UDMA100 controller port 0xffa0-0xffaf at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] uhci0: Intel 82801BA/BAM (ICH2) USB controller USB-A port 0xef40-0xef5f irq 19 at device 31.2 on pci0 usb0: Intel 82801BA/BAM (ICH2) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ichsmb0: Intel 82801BA (ICH2) SMBus controller port
Re: build problems
Doug White wrote: On Sun, 9 Nov 2003, Jason wrote: I have had problems finishing buildworld and the problem is the same each time the build fails. It has failed 4 times at file:///usr/src/gnu/usr.bin/cvs/doc/. I have cvsuped 3 times in 2 days. I am running 5.1. Any info you might have would be helpful. This is usually where rescue falls over. Try building with out -j and see where it des then. You may want to clear out /usr/obj. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org I always rm /usr/obj, and running without -j4 may have done it because it worked. Thanks, Jason ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
mother board weirdness
I just did a buildworld and everything seems to work fine, but I have something going with the mb. I have an epox 8rda and when it boots up the lcd on the board singnals FF, meaning alls good. Then the boot manager comes up, I choose bsd and after the kenerl starts to load( or just before, its hard to tell because this is a fast booting machince) the lcd changes to 10. My manual says it is Auto detect flash type to load appropriate flash R/W codes into runtime area F000 for ESCD DMI support. It has never does this before, it has always stayed FF. Does these mean sometype type of new feature is now supported in freebsd? In win98 it stays FF and I know win98 does not support all of the board functions because it is an old os and the nvidia drivers did not help to support all the features ether. Thanks, Jason ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
