Re: current -r262780 explodes on wlan up
On 03/05/14 20:24, Poul-Henning Kamp wrote: Just tried a current kernel -r 262780 on my laptop. When wlan0 comes up (if_iwn) it explodes with something about witness and rtentry.c, but it clears the screen before I can get a photo... Looks trivial to reproduce. svn r262799, witness disabled, explodes much later here, also system with iwn if it's related. pid 911 was: 65 9111 0 52 0 14556 0 select Ds- 0:00.00 [dhclient] no trace with symbols because kgdb doesn't like that clang creates. Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /boot/kernel/kernel.symbols] Configuring syscons: keymap Sleeping thread (tid 100073, pid 911) owns a non-sleepable lock KDB: stack backtrace of thread 100073: sched_switch() at sched_switch+0x20a/frame 0xfe0233f31690 mi_switch() at mi_switch+0xbe/frame 0xfe0233f316d0 sleepq_catch_signals() at sleepq_catch_signals+0xab/frame 0xfe0233f31730 sleepq_timedwait_sig() at sleepq_timedwait_sig+0xf/frame 0xfe0233f31760 _cv_timedwait_sig_sbt() at _cv_timedwait_sig_sbt+0x18b/frame 0xfe0233f317c0 seltdwait() at seltdwait+0xa4/frame 0xfe0233f31800 sys_poll() at sys_poll+0x3a3/frame 0xfe0233f319a0 amd64_syscall() at amd64_syscall+0x289/frame 0xfe0233f31ab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0233f31ab0 --- syscall (209, FreeBSD ELF64, sys_poll), rip = 0x800b2972a, rsp = 0x7fffdc68, rbp = 0x7fffdca0 --- panic: sleeping thread cpuid = 3 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0234088230 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe02340882e0 panic() at panic+0x155/frame 0xfe0234088360 propagate_priority() at propagate_priority+0x192/frame 0xfe0234088390 turnstile_wait() at turnstile_wait+0x32b/frame 0xfe02340883e0 __mtx_lock_sleep() at __mtx_lock_sleep+0xfc/frame 0xfe0234088410 in_matroute() at in_matroute+0x4e/frame 0xfe0234088440 rtalloc1_fib() at rtalloc1_fib+0x6d/frame 0xfe02340884e0 in_lltable_lookup() at in_lltable_lookup+0x1f6/frame 0xfe0234088530 arpresolve() at arpresolve+0x159/frame 0xfe02340885b0 ether_output() at ether_output+0x1dd/frame 0xfe0234088620 ip_output() at ip_output+0xf50/frame 0xfe0234088710 udp_send() at udp_send+0x86f/frame 0xfe02340887d0 sosend_dgram() at sosend_dgram+0x3bd/frame 0xfe0234088850 kern_sendit() at kern_sendit+0x1c1/frame 0xfe0234088900 sendit() at sendit+0x129/frame 0xfe0234088950 sys_sendto() at sys_sendto+0x4d/frame 0xfe02340889a0 amd64_syscall() at amd64_syscall+0x289/frame 0xfe0234088ab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0234088ab0 --- syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x8013cfdfa, rsp = 0x7fffbb68, rbp = 0x7fffc430 --- KDB: enter: panic Uptime: 20s Dumping 393 out of 8063 MB:..5%..13%..21%..33%..41%..53%..61%..74%..82%..94% -- Pawel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[patch] fix duplicate case value in ichsmb_pci.c
Hi, clang trunk has yet another nice error (in this case harmless): dev/ichsmb/ichsmb_pci.c:183:7: error: duplicate case value '590381190' case ID_DH89XXCC: ^ dev/ichsmb/ichsmb_pci.c:85:23: note: expanded from: #define ID_DH89XXCC 0x23308086 ^ dev/ichsmb/ichsmb_pci.c:173:7: note: previous case defined here case ID_PCH_DH89XXCC: ^ dev/ichsmb/ichsmb_pci.c:70:27: note: expanded from: #define ID_PCH_DH89XXCC 0x23308086 ^ 1 error generated. Fix (there is a more specific device_set_desc() for the 0x23308086 controller which is also called ID_DH89XXCC in another case): Index: sys/dev/ichsmb/ichsmb_pci.c === --- sys/dev/ichsmb/ichsmb_pci.c (revision 224736) +++ sys/dev/ichsmb/ichsmb_pci.c (working copy) @@ -67,7 +67,6 @@ #include /* PCI unique identifiers */ -#define ID_PCH_DH89XXCC0x23308086 #define ID_82801AA 0x24138086 #define ID_82801AB 0x24238086 #define ID_82801BA 0x24438086 @@ -170,7 +169,6 @@ case ID_82801JI: device_set_desc(dev, "Intel 82801JI (ICH10) SMBus controller"); break; - case ID_PCH_DH89XXCC: case ID_PCH: device_set_desc(dev, "Intel PCH SMBus controller"); break; -- Pawel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [clang] (gpt)zfsboot is broken: zfs_alloc()/zfs_free() mismatch
On Aug 1, 2011, at 14:24, Test Rat wrote:
> Anyone else? I can still reproduce with trunk r136607.
> boot and gptboot seem to be unaffected.
>
> IIRC, with previous clang import it just stuck during boot
> without any error messages.
A workaround for the hang on boot and "error 1 lba X" failures is the following
patch, it would be interesting if it also makes the zfs_alloc/free error go
away too.
Index: sys/boot/i386/zfsboot/Makefile
===
--- sys/boot/i386/zfsboot/Makefile (revision 224653)
+++ sys/boot/i386/zfsboot/Makefile (working copy)
@@ -20,7 +20,6 @@
-fomit-frame-pointer \
-fno-unit-at-a-time \
-mno-align-long-strings \
- -mrtd \
-DBOOT2 \
-DSIOPRT=${BOOT_COMCONSOLE_PORT} \
-DSIOFMT=${B2SIOFMT} \
Index: sys/boot/i386/gptzfsboot/Makefile
===
--- sys/boot/i386/gptzfsboot/Makefile (revision 224653)
+++ sys/boot/i386/gptzfsboot/Makefile (working copy)
@@ -22,7 +22,6 @@
-fomit-frame-pointer \
-fno-unit-at-a-time \
-mno-align-long-strings \
- -mrtd \
-DGPT -DBOOT2 \
-DSIOPRT=${BOOT_COMCONSOLE_PORT} \
-DSIOFMT=${B2SIOFMT} \
dim@ has filed an upstream bug, http://llvm.org/bugs/show_bug.cgi?id=10591
Regards
--
Pawel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Potential sizeof vs. mem*() bugs
Hi,
clang gained a new warning for checking the sizeof argument in memset / memcpy
calls, this triggers a couple of times in the FreeBSD tree, here is a brief
summary:
kerberos5/lib/libhx509/../../../crypto/heimdal/lib/hx509/cert.c:357:28:
warning: argument to 'sizeof' in 'memset' call is the same expression as the
destination; did you mean to dereference it? [-Wsizeof-pointer-memaccess]
memset(cert, 0, sizeof(cert));
^~~~
--
kerberos5/lib/libhx509/../../../crypto/heimdal/lib/hx509/cert.c:357:28:
warning: argument to 'sizeof' in 'memset' call is the same expression as the
destination; did you mean to dereference it? [-Wsizeof-pointer-memaccess]
memset(cert, 0, sizeof(cert));
^~~~
--
kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/crypto.c:521:25:
warning: argument to 'sizeof' in 'memset' call is the same expression as the
destination; did you mean to provide an explicit length?
[-Wsizeof-pointer-memaccess]
memset(x, 0, sizeof(x));
~^
--
kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/crypto.c:521:25:
warning: argument to 'sizeof' in 'memset' call is the same expression as the
destination; did you mean to provide an explicit length?
[-Wsizeof-pointer-memaccess]
memset(x, 0, sizeof(x));
~^
--
lib/libtelnet/../../contrib/telnet/libtelnet/sra.c:306:24: warning: argument to
'sizeof' in 'memset' call is the same expression as the destination; did you
mean to provide an explicit length? [-Wsizeof-pointer-memaccess]
memset(pass,0,sizeof(pass));
^~~~
--
lib/libthread_db/arch/amd64/libpthread_md.c:95:48: warning: argument to
'sizeof' in 'memcpy' call is the same expression as the source; did you mean to
dereference it? [-Wsizeof-pointer-memaccess]
memcpy(&uc->uc_mcontext.mc_fpstate, r, sizeof(r));
~ ^
lib/libthread_db/arch/amd64/libpthread_md.c:101:48: warning: argument to
'sizeof' in 'memcpy' call is the same expression as the destination; did you
mean to dereference it? [-Wsizeof-pointer-memaccess]
memcpy(r, &uc->uc_mcontext.mc_fpstate, sizeof(r));
~ ^
--
lib/libthread_db/arch/amd64/libpthread_md.c:95:48: warning: argument to
'sizeof' in 'memcpy' call is the same expression as the source; did you mean to
dereference it? [-Wsizeof-pointer-memaccess]
memcpy(&uc->uc_mcontext.mc_fpstate, r, sizeof(r));
~ ^
lib/libthread_db/arch/amd64/libpthread_md.c:101:48: warning: argument to
'sizeof' in 'memcpy' call is the same expression as the destination; did you
mean to dereference it? [-Wsizeof-pointer-memaccess]
memcpy(r, &uc->uc_mcontext.mc_fpstate, sizeof(r));
~ ^
--
,10001:0lib/bind/isc/../../../contrib/bind9/lib/isc/hmacsha.c:228:24: warning:
argument to 'sizeof' in 'memset' call is the same expression as the
destination; did you mean to dereference it? [-Wsizeof-pointer-memaccess]
memset(ctx, 0, sizeof(ctx));
~~~^~~
lib/bind/isc/../../../contrib/bind9/lib/isc/hmacsha.c:296:24: warning: argument
to 'sizeof' in 'memset' call is the same expression as the destination; did you
mean to dereference it? [-Wsizeof-pointer-memaccess]
memset(ctx, 0, sizeof(ctx));
~~~^~~
lib/bind/isc/../../../contrib/bind9/lib/isc/hmacsha.c:363:24: warning: argument
to 'sizeof' in 'memset' call is the same expression as the destination; did you
mean to dereference it? [-Wsizeof-pointer-memaccess]
memset(ctx, 0, sizeof(ctx));
~~~^~~
lib/bind/isc/../../../contrib/bind9/lib/isc/hmacsha.c:430:24: warning: argument
to 'sizeof' in 'memset' call is the same expression as the destination; did you
mean to dereference it? [-Wsizeof-pointer-memaccess]
memset(ctx, 0, sizeof(ctx));
~~~^~~
lib/bind/isc/../../../contrib/bind9/lib/isc/hmacsha.c:497:24: warning: argument
to 'sizeof' in 'memset' call is the same expression as the destination; did you
mean to dereference it? [-Wsizeof-pointer-memaccess]
memset(ctx, 0, sizeof(ctx));
~~~^~~
--
lib/bind/isc/../../../contrib/bind9/lib/isc/sha2.c:898:28: warning: argument to
'sizeof' in 'memset' call is the same expression as the destination; did you
mean to dereference it? [-Wsizeof-pointer-memaccess]
memset(context, 0, sizeof(context));
~~~^~~
lib/bind/isc/../../../contrib/bind9/lib/isc/sha2.c:1211:28: warning: argument
to 'sizeof' in 'memset' call is the same expression as the destination; did you
mean to dereference it? [-Wsizeof-pointer-memaccess]
memset(context, 0, sizeof(context));
~~~^~~
lib/bind/isc/../.
Re: /tmp and swap space
On Jul 29, 2010, at 17:35, gahn wrote: > hi all: > > is it possible to create /tmp directory under swap space? under solaris, it > is automatically created under swap unless one specifically instructs the > system not to do so.. Why not use tmpfs ? echo "tmpfs /tmptmpfs rw 0 0" >> /etc/fstab mount /tmp -- Pawel___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[patch] Misc warnings found by clang.
Here is a patch that fixes a couple of "warning: format string is not a string literal" and a couple of unused/never read variable "len" warnings in lib/libugidfw. http://pes.vlakno.cz/~pwo/clang-warn-fix-head.diff Regards -- Pawel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Importing clang/LLVM into FreeBSD HEAD
On Jun 2, 2010, at 23:57, Steve Kargl wrote: > On Wed, Jun 02, 2010 at 11:48:11PM +0200, Pawel Worach wrote: >> On May 31, 2010, at 16:57, Steve Kargl wrote: >>> >>> Can clang/LLVM build the livefs and bootonly CD's? >>> >> >> There is a buildbot here[1] that builds a live CD for boot >> testing, so I would say it works. >> >> [1] http://amd64-clang-bot.qat.freebsd.org:8010/ >> > > Clang cannot build a FreeBSD without the help of gcc. > > http://amd64-clang-bot.qat.freebsd.org:8010/freebsd.diff > I believe this was mentioned already that boot2 overflows 512b. It is being worked on, http://llvm.org/bugs/buglist.cgi?quicksearch=6627,5039 -- Pawel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Importing clang/LLVM into FreeBSD HEAD
On May 31, 2010, at 16:57, Steve Kargl wrote: > > Can clang/LLVM build the livefs and bootonly CD's? > There is a buildbot here[1] that builds a live CD for boot testing, so I would say it works. [1] http://amd64-clang-bot.qat.freebsd.org:8010/ -- Pawel___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Importing clang/LLVM into FreeBSD HEAD
On May 31, 2010, at 21:30, Garrett Cooper wrote: > > How much time (with -j1, approximately) does it take to build clang? Numbers for -j4 are about 1100 sec to build llvm+clang with gcc and about 700 seconds to build llvm+clang with clang. -- Pawel___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
if_sk build fails
Hi! Last if_sk update broke buildkernel ===> sk rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/../include /usr/src/sys/modules/sk/../../pci/if_sk.c /usr/src/sys/pci/if_sk.c:129:26: pci/yukonreg.h: No such file or directory mkdep: compile failed missed to cvs add yukonreg.h? - Pawel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[patch] annoying newline in kernel printf
Is this blank line necessary?
-- dmesg snippet --
APIC_IO: Testing 8254 interrupt delivery
APIC_IO: routing 8254 via IOAPIC #0 intpin 2
Timecounters tick every 10.000 msec
acpi_cpu: throttling enabled, 2 steps (100% to 50.0%), currently 100.0%
GEOM: create disk ad4 dp=0xc2490870
- Pawel
sys/kern/kern_tc.c:
$FreeBSD: src/sys/kern/kern_tc.c,v 1.157 2003/09/03 08:14:16 phk Exp $
--- sys/kern/kern_tc.c.org Tue Sep 9 00:21:30 2003
+++ sys/kern/kern_tc.c Tue Sep 9 00:21:57 2003
@@ -297,12 +297,11 @@
printf(" -- Insufficient hz, needs at least
%u\n", u);
}
} else if (tc->tc_quality >= 0 || bootverbose) {
- printf("Timecounter \"%s\" frequency %ju Hz quality %d",
+ printf("Timecounter \"%s\" frequency %ju Hz quality %d\n",
tc->tc_name, (intmax_t)tc->tc_frequency,
tc->tc_quality);
}
- printf("\n");
tc->tc_next = timecounters;
timecounters = tc;
(void)tc->tc_get_timecount(tc);
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel compile problem with device wi in kernel. (GENERIC &custom kernels)
Mark Sergeant wrote: I've got the following problem when trying to compile a kernel with todays sources and the device "wi" in it. linking kernel if_wi.o: In function `wi_attach': if_wi.o(.text+0x2b4): undefined reference to `ieee80211_ieee2mhz' if_wi.o(.text+0x673): undefined reference to `ieee80211_ifattach' if_wi.o(.text+0x6a7): undefined reference to `ieee80211_media_init' device wlan? - Pawel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI errors on my desktop PC (floppy not found)
Martin wrote: Hi, I have more problems to report with the ACPI support and will submit a PR, if you want. I don't know when this got broken. Here some pieces of my dmesg: --- FreeBSD 5.1-CURRENT #0: Thu Sep 4 22:38:56 CEST 2003 [...] acpi0: on motherboard Take a look at PR kern/48494, there is a patch for the AML there for the ABIT BP6 board. I belive other ABIT boards have the similar Store(Local0, Local0) problem. That fixed the floppy problem for me. - Pawel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: swapon vs savecore dilemma
Scott Long wrote: Doug White wrote: Hey folks, It looks like we may need to rethink the way swap is mounted at boot time if we want crashdumps to work. I question the wizdom of what you're describing. If swap space needs to be made available for fsck to run, then what happens to the crashdump data that used to be on the swap partition? Doing a swapon(8) means that nothing in the swap partition is reliable or consistent anymore. Scott Yes, I have seen this too. Sep 2 02:16:30 darkstar savecore: /dev/da0s1b: Operation not permitted Sep 2 02:16:30 darkstar savecore: no dumps found Is fsck really that memory heavy so that it needs swap? Wouldn't fsck -> mount -> savecore -> swapon be a more appropriate order? - Pawel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfs tranfers hang in state getblck or nfsread
Terry Lambert wrote: I am now going to predict that your ethernet is multihomed, and that you have more than one IP address on the server, the client, or both. That is true, I de-multihomed the server but the problem persists. The client is not multihomed. The server also has INET6 in the kernel the client does not. - Pawel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfs tranfers hang in state getblck or nfsread
Pawel Worach wrote: Robert Watson wrote: On Wed, 27 Aug 2003, Pawel Worach wrote: Ok, so let me see if I have the sequence of events straight: Hope this is not as confusing as my previus mail :) Here is some more information. I realized that i had tcp and udp "blackholing" enabled on the server so i disabled that, still no dice. disabled rpc.statd and rpc.lockd, still no dice. I escaped to DDB between the "not responding" and the "ok" messages and came up with this: [SLP]nfscon ] mount_nfs [SLP]- ] nfsiod 3 [SLP]- ] nfsiod 2 [SLP]- ] nfsiod 1 [SLP]- ] nfsiod 0 I have also played with the mount options, here is the result of that: ro,nfsv3,tcp,rdirplus - broken ro,nfsv3,tcp - broken ro,tcp - broken ro - ok (defaults to nfsv2,udp according to my research) ro,nfsv3 - ok (defaults to udp) So it looks like what i said before, only tcp seems to cause this. As this is the first time i'm seriusly investigating this i also noted that a restart of the NFS daemons (or reboot) of the server is not needed, just doing a _clean_ reboot (init 6, shutdown -r now) of the client will make the server "recover". (sometimes is takes two clean reboots). - Pawel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfs tranfers hang in state getblck or nfsread
Robert Watson wrote: On Wed, 27 Aug 2003, Pawel Worach wrote: Ok, so let me see if I have the sequence of events straight: (1) Boot a 4.8-RELEASE/STABLE NFS server (2) Boot a 5.1-RELEASE/CURRENT NFS client (3) Mount a file system using TCP NFSv3 (4) Reboot the client system, reboot, and remount (5) Thrash the file system a bit with large reads/writes, and it hangs Not quite, more like this: 1) Boot the 5.1-CURRENT nfs server 2) Boot the 5.1-CURRENT diskless client (i'm using PXE/DHCP) 3) Login and run find(1) for a while on every filesystem. (e.g. find / ^C ; find /usr ^C ; find /export ^C and so on to generate some getattr(), read() and c/o calls) 4) Shut down the client in a _non-clean_ way, pull the power or enter DDB and 'reset'. 5) Boot the diskless client again. Now here are the messages i get while booting the client (step 5). (darkstar is the server, corona is the client. the one about mounttab is present at every boot and is not related to this problem) Mounting root from nfs: NFS ROOT: 192.168.1.11:/export/root start_init: trying /sbin/init Interface fxp0 IP-Address 192.168.1.20 Broadcast 192.168.1.255 Loading configuration files. Entropy harversting: interrupts ethernet point_to_point Starting file system checks: nfs: can't update /var/db/mounttab for darkstar:/export/root +++ mount_md of /var nfs server darkstar:/usr: not responding nfs server darkstar:/usr: is alive again nfs server darkstar:/usr/home: not responding nfs server darkstar:/usr/home: is alive again [tcp] darkstar:/export: nfsd: RPCPROG_NFS: RPC: Remote system error - Operation timed out nfs server darkstar:/export: not responding nfs server darkstar:/export: is alive again From here on the boot continues normally and the system works fine. I'm going to set different mount options for every filesystem now and do this again so maybe i can nail down what is causing this. Ths only filesystem that doesn't have problems is / and that is also the only one using udp. Hope this is not as confusing as my previus mail :) And whoever commented about the "magic" stuff, that was a cut-and-paste from the 'dumpfs | grep UFS' command. - Pawel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfs tranfers hang in state getblck or nfsread
Robert Watson wrote: I have a very similar configuration, but it sounds like I'm not bumping into the same problem. Are you using NFSv2 or v3, and how many file systems are you mounting? Are you generally using UFS1 or UFS2? Right now, I'm mounting a single UFS2 file system was the root, and I believe right now we always mount NFS roots at NFSv2, which could by why I'm not seeing the same problem... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories Hi Robert! This only seem to happen for nfs over tcp. fstab on the client (/conf/default/etc/fstab) looks like: server:/export/root / nfs ro 0 0 procfs /proc procfs rw 0 0 server:/usr /usrnfs ro,nfsv3,tcp0 0 server:/usr/home /home nfs rw,nfsv3,tcp0 0 server:/export/export nfs ro,nfsv3,tcp0 0 server:/export/data/swap /swap nfs rw,nfsv3,tcp0 0 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 /etc/exports on the server looks like: /export -alldirs -maproot=root -network 192.168.1.0 -mask 255.255.255.0 /export/root -ro -maproot=0 client /export/data/swap -mapall=nobody -network 192.168.1.0 -mask 255.255.255.0 /usr/home client /usr -ro -network 192.168.1.0 -mask 255.255.255.0 filesystems on the server: /magic 11954 (UFS1)timeWed Aug 27 17:34:13 2003 /usr magic 19540119 (UFS2) timeWed Aug 27 17:33:38 2003 /export magic 11954 (UFS1)timeSat Aug 23 23:51:20 2003 /export/data magic 19540119 (UFS2) timeTue Aug 26 07:48:01 2003 I get the errors every time the nfs mounts are not unmounted "cleanly", if the client (which is a laptop and i often forget to plug in the power so the battery dies) dies and the server is rebooted the client boots fine, i.e. no "nfs server not responding errors". So it looks like there is some kind of state mismatch in the nfs server code. rc.conf parameters look like this: server: rpcbind_enable="YES" nfs_server_enable="YES" mountd_enable="YES" nfs_reserved_port_only="YES" rpc_lockd_enable="YES" rpc_statd_enable="YES" client: rpcbind_enable="YES" nfs_client_enable="YES" rpc_lockd_enable="YES" rpc_statd_enable="YES" Regards Pawel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfs tranfers hang in state getblck or nfsread
Alexander Leidinger wrote: In this configuration I see a lot of "nfs server ...: is not responding" and "nfs server ...: is alive again" when I copy large files (e.g. a CD image). All of them happen in the same second. I haven't looked at the state or priority of the cp process when this happens. I have seen this too and i can reproduce it. I have a diskless client and if i unplug the power and boot it up again i see the "nfs server not responding" messages for every filesystem being mounted. Both client and server are of course FreeBSD-current, i have seen this for about four mounts now. - Pawel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Buildworld broken in gnu/usr.bin/sort
This happened after an rm -r /usr/obj/* ; make -j4 buildworld ===> gnu/usr.bin/sort cc -I/usr/local/include -march=pentiumpro -I/usr/src/gnu/usr.bin/sort -I/usr/src/gnu/usr.bin/sort/../../../contrib/gnu-sort/lib -DHAVE_CONFIG_H -c /usr/src/contrib/gnu-sort/src/sort.c /usr/src/contrib/gnu-sort/src/sort.c: In function `main': /usr/src/contrib/gnu-sort/src/sort.c:2185: error: `LOCALEDIR' undeclared (first use in this function) /usr/src/contrib/gnu-sort/src/sort.c:2185: error: (Each undeclared identifier is reported only once /usr/src/contrib/gnu-sort/src/sort.c:2185: error: for each function it appears in.) *** Error code 1 - Pawel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sockstat -6
David Hill wrote: Hello - I get a mismatch error when i run sockstat -6. kernel and userland are in sync. FreeBSD localhost 5.1-CURRENT FreeBSD 5.1-CURRENT #3: Tue Jul 22 07:49:10 EDT 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/WIND i386 (david wind:/home/david)% sockstat -6 sockstat: struct xtcpcb size mismatch USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS No problems here. darkstar$ uname -a FreeBSD darkstar 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Tue Jul 22 18:49:18 CEST 2003 [EMAIL PROTECTED]:/export/data/obj/usr/src/sys/DARKSTAR i386 darkstar$ sockstat -6 USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS root inetd 535 5 tcp6 *:21 *:* root inetd 535 7 tcp6 *:113 *:* darkstar$ ls -l `which sockstat` -r-xr-xr-x 1 root wheel 10060 Jul 22 20:00 /usr/bin/sockstat - Pawel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic on pccard insert (more debug info)
I tuned on some debug sysctls, here is the result. cbb0: card inserted: event=0x, state=3810 pccard0: chip_socket_enable cbb_pcic_socket_enable: cbb0: cbb_power: 3V pccard0: read_cis cis mem map ce6e1000 pccard0: CIS tuple chain: CISTPL_NONE 00 CISTPL_NONE 00 [] CISTPL_CHECKSUM too short 0 10 00 CISTPL_NONE 00 CISTPL_NONE 00 [and it continues like this until the panic] -Pawel Pawel Worach wrote: Whatever pccard i insert, here an unsupported 3Com OfficeConnect WiFi card or even a Intel Pro/100+ Mobile16 card it panics like seen below. This happens if booted with the card inserted and if hotplugged. The laptop is booted "diskless" so I can't produce a crashdump (the info below is typed by hand). full dmesg, kernel config and kernel.debug can be found at http://213.67.96.190/pccard/ Fatal trap 12: page fault while in kernel mode fault virtual address = 0xce6cb000 fault code = supervisor read, page not present instruction pointer = 0x8:0xc016a7b5 stack pointer = 0x10:0xcd2c4938 frame pointer = 0x10:0xcd2c4b54 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 8 (cbb0) kernel: type 12 trap, code=0 Stopped at pccard_scan_cis+0x165: movzbl 0(%eax,%edx,1),%eax db> tr pccard_scan_cis+0x165 pccard_read_cis+0xb4 pccard_attach_card+0x9b CARD_ATTACH_CARD+0x48 exca_insert+0x23 cbb_insert+0x93 cbb_event_thread+0xa4 fork_exit+0xb1 fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xcd2c4d7c, ebp = 0 --- pccard stuff from dmesg: cbb0: irq 9 at device 19.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: PCI Configuration space: 0x00: 0x69331217 0x0417 0x06070002 0x00822000 0x10: 0x8800 0x02a0 0x20010100 0xf000 0x20: 0x 0xf000 0x 0xfffd 0x30: 0x0001 0xfffd 0x0001 0x04000109 0x40: 0x10e610cf 0x0001 0x 0x 0x50: 0x 0x 0x 0x 0x60: 0x 0x 0x 0x 0x70: 0x 0x 0x 0x 0x80: 0x 0x 0x 0x 0x90: 0x0c0023bf 0x824203ea 0x1050 0x 0xa0: 0xfe020001 0x00c04000 0x 0x 0xb0: 0x 0x 0x 0x 0xc0: 0x 0x 0x 0x 0xd0: 0x 0x 0x 0x 0xe0: 0x 0x 0x 0x 0xf0: 0x 0x 0x 0x cbb1: irq 9 at device 19.1 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb1: PCI Configuration space: 0x00: 0x69331217 0x0417 0x06070002 0x00822000 0x10: 0x88001000 0x02a0 0x20020200 0xf000 0x20: 0x 0xf000 0x 0xfffd 0x30: 0x0001 0xfffd 0x0001 0x04000209 0x40: 0x10e610cf 0x0001 0x 0x 0x50: 0x 0x 0x 0x 0x60: 0x 0x 0x 0x 0x70: 0x 0x 0x 0x 0x80: 0x 0x 0x 0x 0x90: 0x0c0023bf 0x824203ea 0x1050 0x 0xa0: 0xfe020001 0x00c04000 0x 0x 0xb0: 0x 0x 0x 0x 0xc0: 0x 0x 0x 0x 0xd0: 0x 0x 0x 0x 0xe0: 0x 0x 0x 0x 0xf0: 0x 0x 0x 0x pciconf: [EMAIL PROTECTED]:19:0: class=0x060700 card=0x10e610cf chip=0x69331217 rev=0x02 hdr=0x02 vendor = 'O2 Micro Inc' device = 'OZ6933 CardBus Controller' class= bridge subclass = PCI-CardBus [EMAIL PROTECTED]:19:1: class=0x060700 card=0x10e610cf chip=0x69331217 rev=0x02 hdr=0x02 vendor = 'O2 Micro Inc' device = 'OZ6933 CardBus Controller' class= bridge subclass = PCI-CardBus ___ [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]"
panic on pccard insert
Whatever pccard i insert, here an unsupported 3Com OfficeConnect WiFi card or even a Intel Pro/100+ Mobile16 card it panics like seen below. This happens if booted with the card inserted and if hotplugged. The laptop is booted "diskless" so I can't produce a crashdump (the info below is typed by hand). full dmesg, kernel config and kernel.debug can be found at http://213.67.96.190/pccard/ Fatal trap 12: page fault while in kernel mode fault virtual address = 0xce6cb000 fault code = supervisor read, page not present instruction pointer = 0x8:0xc016a7b5 stack pointer = 0x10:0xcd2c4938 frame pointer = 0x10:0xcd2c4b54 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 8 (cbb0) kernel: type 12 trap, code=0 Stopped at pccard_scan_cis+0x165: movzbl 0(%eax,%edx,1),%eax db> tr pccard_scan_cis+0x165 pccard_read_cis+0xb4 pccard_attach_card+0x9b CARD_ATTACH_CARD+0x48 exca_insert+0x23 cbb_insert+0x93 cbb_event_thread+0xa4 fork_exit+0xb1 fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xcd2c4d7c, ebp = 0 --- pccard stuff from dmesg: cbb0: irq 9 at device 19.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: PCI Configuration space: 0x00: 0x69331217 0x0417 0x06070002 0x00822000 0x10: 0x8800 0x02a0 0x20010100 0xf000 0x20: 0x 0xf000 0x 0xfffd 0x30: 0x0001 0xfffd 0x0001 0x04000109 0x40: 0x10e610cf 0x0001 0x 0x 0x50: 0x 0x 0x 0x 0x60: 0x 0x 0x 0x 0x70: 0x 0x 0x 0x 0x80: 0x 0x 0x 0x 0x90: 0x0c0023bf 0x824203ea 0x1050 0x 0xa0: 0xfe020001 0x00c04000 0x 0x 0xb0: 0x 0x 0x 0x 0xc0: 0x 0x 0x 0x 0xd0: 0x 0x 0x 0x 0xe0: 0x 0x 0x 0x 0xf0: 0x 0x 0x 0x cbb1: irq 9 at device 19.1 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb1: PCI Configuration space: 0x00: 0x69331217 0x0417 0x06070002 0x00822000 0x10: 0x88001000 0x02a0 0x20020200 0xf000 0x20: 0x 0xf000 0x 0xfffd 0x30: 0x0001 0xfffd 0x0001 0x04000209 0x40: 0x10e610cf 0x0001 0x 0x 0x50: 0x 0x 0x 0x 0x60: 0x 0x 0x 0x 0x70: 0x 0x 0x 0x 0x80: 0x 0x 0x 0x 0x90: 0x0c0023bf 0x824203ea 0x1050 0x 0xa0: 0xfe020001 0x00c04000 0x 0x 0xb0: 0x 0x 0x 0x 0xc0: 0x 0x 0x 0x 0xd0: 0x 0x 0x 0x 0xe0: 0x 0x 0x 0x 0xf0: 0x 0x 0x 0x pciconf: [EMAIL PROTECTED]:19:0: class=0x060700 card=0x10e610cf chip=0x69331217 rev=0x02 hdr=0x02 vendor = 'O2 Micro Inc' device = 'OZ6933 CardBus Controller' class= bridge subclass = PCI-CardBus [EMAIL PROTECTED]:19:1: class=0x060700 card=0x10e610cf chip=0x69331217 rev=0x02 hdr=0x02 vendor = 'O2 Micro Inc' device = 'OZ6933 CardBus Controller' class= bridge subclass = PCI-CardBus ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rpcinfo
Danny Braniss wrote: I just run rpcinfo: # rpcinfo rpcinfo: can't contact rpcbind: RPC: Port mapper failure - RPC: Success :=) This really belongs in questions@, make sure you have rpcbind_enable="YES" in rc.conf -Pawel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
build broken by usbdivar.h 1.40
@/dev/usb/usbdivar.h:127: error: syntax error before "bus_dma_tag_t" -Pawel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
rescue breaks parallel builds
make -j4 buildworld ends up in random errors like this one. make: don't know how to make /export/data/obj/usr/src/rescue/rescue//usr/src/sbin/dhclient/client/clparse .o. Stop -- Pawel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ahc driver bug?
It looks like we are calling the ahc_chip_init() code in the ahc/aic7xxx driver on shutdown. Is that correct? -- Pawel boot() called on cpu#0 Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks, buffers remaining... 17 17 10 10 1 1 done Uptime: 4d1h31m23s ahc0: Downloading Sequencer Program... 423 instructions downloaded ahc0: Features 0x56f6, Bugs 0x6, Flags 0x20485140 Rebooting... cpu_reset called on cpu#1 cpu_reset: Stopping other CPUs cpu_reset: Restarting BSP cpu_reset_proxy: Stopped CPU 1 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
vmstat -s broken
I don't know for how long this has been broken but vmstat always reports 0 (zero) for the number of system calls executed which is virtually impossible. This is on a system built FreeBSD darkstar 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Tue Jun 3 02:48:51 CEST 2003 darkstar# vmstat -s | grep "system calls" 0 system calls darkstar# uptime 8:33PM up 17:03, 8 users, load averages: 1.93, 1.63, 1.27 -- Pawel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
kldunload related panic
During buildworld I loaded and unloaded the if_tun module and here is the result: Kernel is basically GENERIC with some drivers removed, uname: FreeBSD 5.0-RC #0: Fri Dec 27 12:40:30 GMT 2002 panic: allocbuf: buffer not busy panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x4 fault code = supervisor read, page not present instruction pointer = 0x8:0xc02e9f73 stack pointer = 0x10:0xc63e0c70 frame pointer = 0x10:0xc63e0c70 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 = 11886 (kldunload) trap number = 12 panic: page fault syncing disks, buffers remaining... panic: allocbuf: buffer not busy Uptime: 28m30s Dumping 63 MB ata0: resetting devices .. done 16 32 48 --- #0 0xc02e31cb in doadump () #1 0xc02e3651 in boot () #2 0xc02e3863 in panic () #3 0xc032454d in allocbuf () #4 0xc0324204 in getblk () #5 0xc03217fa in breadn () #6 0xc03217ac in bread () #7 0xc03edcc3 in ffs_update () #8 0xc0401d7f in ffs_fsync () #9 0xc0400f4e in ffs_sync () #10 0xc033483b in sync () #11 0xc02e32c2 in boot () #12 0xc02e3863 in panic () #13 0xc0458b8e in trap_fatal () #14 0xc04588a2 in trap_pfault () #15 0xc045846d in trap () #16 0xc0449598 in calltrap () #17 0xc02d4a4a in linker_file_unregister_sysctls () #18 0xc02d511e in linker_file_unload () #19 0xc02d57d6 in kldunload () #20 0xc0458e4e in syscall () #21 0xc04495ed in Xint0x80_syscall () Any ideas? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
xe pcmcia interface broken
Using an IBM ThinkPad 770 with the Intel EtherExpress(TM) PRO/100 PC Card Mobile Adapter16 is a no go in RELENG_5_0, this worked fine in 4.7-RELEASE also i had to use the "OLDCARD" style pcmcia driver, the new one won't work. pccard: card inserted, slot 0 xe0 at port 0x240-0x24f iomem 0xd4000-0xd4fff irq 3 slot 0 on pccard0 xe0: Intel CE3, bonding version 0x45, 100Mbps capable xe0: DingoID = 0, RevisionID = 0, VendorID = 0 xe0: Ethernet address 00:a0:c9:37:21:ef xe0: watchdog timeout; resetting card Now for the real fun, oversized frames: # ping -c 1 darkstar PING darkstar.sajd.net (192.168.1.11): 56 data bytes 64 bytes from 192.168.1.11: icmp_seq=0 ttl=64 time=0.668 ms # ping -c 1 -s 2000 darkstar PING darkstar.sajd.net (192.168.1.11): 56 data bytes xe0: discard oversize frame (ether type 800 flags 3 len 1518 > max 1514) xe0: discard oversize frame (ether type 800 flags 3 len 1518 > max 1514) # ifconfig xe0 | grep mtu xe0: flags=8843 mtu 1500 any ideas? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
