kernel panic when accessing /dev/tap0

  Hi,

Robert Watson described a problem in this discussion: 
http://lists.freebsd.org/pipermail/freebsd-stable/2006-May/025880.html
Currently I'm experiencing a similar problem, but on amd64 and FreeBSD 
8.1 Release. Accessing /dev/tap0 instantly results in a kernel panic, so 
it's most likely if_tap related. Is this a known problem? I've started 
encountering it ever since I rebuilt my kernel with "options vimage".

Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x28

If more debugging information is required I will gladly provide it.

Frank Razenberg
_______________________________________________
freebsd-stable <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe <at> freebsd.org"

[releng_7 tinderbox] failure on amd64/amd64

TB --- 2010-09-01 05:39:04 - tinderbox 2.6 running on freebsd-stable.sentex.ca
TB --- 2010-09-01 05:39:04 - starting RELENG_7 tinderbox run for amd64/amd64
TB --- 2010-09-01 05:39:04 - cleaning the object tree
TB --- 2010-09-01 05:39:33 - cvsupping the source tree
TB --- 2010-09-01 05:39:33 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/amd64/amd64/supfile
TB --- 2010-09-01 05:39:43 - building world
TB --- 2010-09-01 05:39:43 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-09-01 05:39:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-09-01 05:39:43 - TARGET=amd64
TB --- 2010-09-01 05:39:43 - TARGET_ARCH=amd64
TB --- 2010-09-01 05:39:43 - TZ=UTC
TB --- 2010-09-01 05:39:43 - __MAKE_CONF=/dev/null
TB --- 2010-09-01 05:39:43 - cd /src
TB --- 2010-09-01 05:39:43 - /usr/bin/make -B buildworld
>>> World build started on Wed Sep  1 05:39:43 UTC 2010
>>> 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
>>> stage 5.1: building 32 bit shim libraries
>>> World build completed on Wed Sep  1 07:12:52 UTC 2010
TB --- 2010-09-01 07:12:52 - generating LINT kernel config
TB --- 2010-09-01 07:12:52 - cd /src/sys/amd64/conf

Re: [releng_7 tinderbox] failure on amd64/amd64

On Wed, Sep 01, 2010 at 03:21:48AM -0400, FreeBSD Tinderbox wrote:
> TB --- 2010-09-01 05:39:04 - tinderbox 2.6 running on freebsd-stable.sentex.ca
> TB --- 2010-09-01 05:39:04 - starting RELENG_7 tinderbox run for amd64/amd64
> TB --- 2010-09-01 05:39:04 - cleaning the object tree
> TB --- 2010-09-01 05:39:33 - cvsupping the source tree
> TB --- 2010-09-01 05:39:33 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/amd64/amd64/supfile
> TB --- 2010-09-01 05:39:43 - building world
> TB --- 2010-09-01 05:39:43 - MAKEOBJDIRPREFIX=/obj
> TB --- 2010-09-01 05:39:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
> TB --- 2010-09-01 05:39:43 - TARGET=amd64
> TB --- 2010-09-01 05:39:43 - TARGET_ARCH=amd64
> TB --- 2010-09-01 05:39:43 - TZ=UTC
> TB --- 2010-09-01 05:39:43 - __MAKE_CONF=/dev/null
> TB --- 2010-09-01 05:39:43 - cd /src
> TB --- 2010-09-01 05:39:43 - /usr/bin/make -B buildworld
> >>> World build started on Wed Sep  1 05:39:43 UTC 2010
> >>> 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
> >>> stage 5.1: building 32 bit shim libraries
> >>> World build completed on Wed Sep  1 07:12:52 UTC 2010
> TB --- 2010-09-01 07:12:52 - generating LINT kernel config

Re: Broadcom Wireless BCM4312 Rev.02 (BCM4310 UART) troubles

On Tue, Aug 31, 2010 at 10:30 AM, Michael BlackHeart <amdmiek <at> gmail.com> wrote:
> Hello
>
> I've got a problem with Broadcomm Wireless.
> I have notebook HP Compaq 6720s with BCM4312. I disassemblied book and saw
> there plugable Wireless Module but I'm lazy to do it again to werify it's
> ID.
>
> Windows XP drivers works fine and says that is's
>
> PCI\VEN_14E4&DEV_4312&SUBSYS_1371103C&REV_02\4&29E2C51B&0&00E1
> MEMORY E4000000 - E4003FFF
> IRQ 17
>
> I've tried :
> FreeBSD 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:36:49 UTC 2010
> root <at> mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
> And noting as i386 8.1 release.
>
> Now I'm running:
> FreeBSD 8.1-STABLE FreeBSD 8.1-STABLE #0 r211991: Mon Aug 30 14:58:34 MSD
> 2010
> root <at> :/usr/obj/usr/src/sys/GENERIC amd64
>
> With no driver attached "pciconf -l -cvb" says:
>
> none1 <at> pci0:16:0:0: class=0x028000 card=0x1371103c chip=0x431214e4 rev=0x02
> hdr=0x00
> vendor = 'Broadcom Corporation'
> device = 'BCM4310 UART (Wireless Ethernet Adapter)'

[releng_7 tinderbox] failure on i386/i386

TB --- 2010-09-01 06:54:06 - tinderbox 2.6 running on freebsd-stable.sentex.ca
TB --- 2010-09-01 06:54:06 - starting RELENG_7 tinderbox run for i386/i386
TB --- 2010-09-01 06:54:06 - cleaning the object tree
TB --- 2010-09-01 06:54:29 - cvsupping the source tree
TB --- 2010-09-01 06:54:29 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile
TB --- 2010-09-01 06:54:38 - building world
TB --- 2010-09-01 06:54:38 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-09-01 06:54:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-09-01 06:54:38 - TARGET=i386
TB --- 2010-09-01 06:54:38 - TARGET_ARCH=i386
TB --- 2010-09-01 06:54:38 - TZ=UTC
TB --- 2010-09-01 06:54:38 - __MAKE_CONF=/dev/null
TB --- 2010-09-01 06:54:38 - cd /src
TB --- 2010-09-01 06:54:38 - /usr/bin/make -B buildworld
>>> World build started on Wed Sep  1 06:54:39 UTC 2010
>>> 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
>>> World build completed on Wed Sep  1 08:04:41 UTC 2010
TB --- 2010-09-01 08:04:41 - generating LINT kernel config
TB --- 2010-09-01 08:04:41 - cd /src/sys/i386/conf
TB --- 2010-09-01 08:04:41 - /usr/bin/make -B LINT

[releng_7 tinderbox] failure on i386/pc98

TB --- 2010-09-01 07:21:48 - tinderbox 2.6 running on freebsd-stable.sentex.ca
TB --- 2010-09-01 07:21:48 - starting RELENG_7 tinderbox run for i386/pc98
TB --- 2010-09-01 07:21:48 - cleaning the object tree
TB --- 2010-09-01 07:22:24 - cvsupping the source tree
TB --- 2010-09-01 07:22:24 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/pc98/supfile
TB --- 2010-09-01 07:22:34 - building world
TB --- 2010-09-01 07:22:34 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-09-01 07:22:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-09-01 07:22:34 - TARGET=pc98
TB --- 2010-09-01 07:22:34 - TARGET_ARCH=i386
TB --- 2010-09-01 07:22:34 - TZ=UTC
TB --- 2010-09-01 07:22:34 - __MAKE_CONF=/dev/null
TB --- 2010-09-01 07:22:34 - cd /src
TB --- 2010-09-01 07:22:34 - /usr/bin/make -B buildworld
>>> World build started on Wed Sep  1 07:22:35 UTC 2010
>>> 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
>>> World build completed on Wed Sep  1 08:28:55 UTC 2010
TB --- 2010-09-01 08:28:55 - generating LINT kernel config
TB --- 2010-09-01 08:28:55 - cd /src/sys/pc98/conf
TB --- 2010-09-01 08:28:55 - /usr/bin/make -B LINT

Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable.

I'm running -STABLE with a kde-derived desktop. This setup (which is 
pretty standard) is providing abysmal interactive performance on an 
eight-core machine whenever I try to do anything CPU-intensive (such as 
building a port).

Basically, trying to build anything from ports rapidly renders everything 
else so "non-interactive" in the eyes of the scheduler that, for instance, 
switching between virtual desktops (I have six of them in reasonably 
frequent use) takes about a minute of painful waiting on redraws to 
complete.

Once I pay attention to any particular window, the scheduler rapidly 
(like, in 15 agonising seconds or so) decides that the processes 
associated with that particular window are "interactive" and performance 
there picks up again. But it only takes 10 seconds (not timed; ballpark 
figures) or so of inattention for a window's processes to lapse back into 
a low-priority state, with the attendant performance problems.

I don't think my desktop usage is particularly abnormal; I doubt my level 
of frustration is, either  I think the issue here is that a modern 
desktop has quite a lot of associated processes, and you can't keep them 
all sufficiently "interactive" in the eyes of sched_ule to ensure they 
stay responsive.

Are there particular tunables associated with sched_ule (the manpage says 
not) that I might look at to try to address this? Or process flags I can 
set on my desktop tasks to keep them nearer the interactive end of the 
spectrum?

Claimed is:

Re: if_rtdel: error 47

On Tue, 31 Aug 2010, Mike Tancsa wrote:

Hey Mike,

> On a RELENG_8 box from aug 25th, I started seeing a constant spew of
>
> Aug 31 00:17:46 gate8 kernel: if_rtdel: error 47
> Aug 31 00:18:29 gate8 kernel: ifa_del_loopback_route: deletion failed
> Aug 31 00:18:29 gate8 kernel: if_rtdel: error 3
> Aug 31 00:18:29 gate8 last message repeated 2 times
> Aug 31 00:18:37 gate8 kernel: ifa_del_loopback_route: deletion failed
> Aug 31 00:18:37 gate8 kernel: if_rtdel: error 3
> Aug 31 00:18:37 gate8 last message repeated 2 times
> Aug 31 00:18:38 gate8 kernel: ifa_del_loopback_route: deletion failed
> Aug 31 00:18:38 gate8 kernel: if_rtdel: error 3
> Aug 31 00:18:38 gate8 last message repeated 2 times
>
>
> What do they mean and how can I find the cause of it ? The box acts as an LNS 
> with about 700 ng interfaces with mpd5.5.  ipv6 is enabled on this server as 
> well, so I am guessing it might be related to ipv6 as I havent seen it on the 
> other LNS boxes that have the same setup, except no ipv6.  It was happily 
> running for a few days until this error started showing up ?

I thought this was fixed already but maybe only in HEAD and not
merged.  I'll go and look.

/bz

--

-- 

Why is NFSv4 so slow?

Hi everyone,

I am experiencing similar issues with newnfs:

1) I have two clients that each get around 0.5MiB/s to 2.6MiB/s reading 
from the NFS4-share on Gbit-Lan

2) Mounting with -t newnfs -o nfsv3 results in no performance gain 
whatsoever.

3) Mounting with -t nfs results in 58MiB/s ! (Netcat has similar 
performance) → not a hardware/driver issue from my pov

Is there anything I can do to help fix this?

Thank you,
--

-- 
                         ┌─────────────────────────────────────────┐
Best Regards,            │ Free Software Foundation Europe    █▉   │
Hannes Hauswedell        │           German Team            █▉█▉█▉ │
                         │ Coordinator for pdfreaders.org     ▉▉   │
                         └─────────────────────────────────────────┘

_______________________________________________
freebsd-stable <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe <at> freebsd.org"

Re: kernel panic when accessing /dev/tap0

On Wed, 1 Sep 2010, Frank Razenberg wrote:

Hey,

> Robert Watson described a problem in this discussion: 
> http://lists.freebsd.org/pipermail/freebsd-stable/2006-May/025880.html
> Currently I'm experiencing a similar problem, but on amd64 and FreeBSD 8.1 
> Release. Accessing /dev/tap0 instantly results in a kernel panic, so it's 
> most likely if_tap related. Is this a known problem? I've started 
> encountering it ever since I rebuilt my kernel with "options vimage".

this is expected.  I have a work in progress fix in perforce for
most/all cloned interfaces.  It's only a matter of extracting patches
now but it'll be anohter few days till I'll get to that.

/bz

PS: freebsd-virtualization <at>  might be the better place to post VIMAGE
problems.

--

-- 
Bjoern A. Zeeb                       This signature is about you not me.
_______________________________________________
freebsd-stable <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe <at> freebsd.org"