HEADS UP: FreeBSD 7.1 EoL coming soon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Everyone, On February 28th, FreeBSD 7.1 will reach its End of Life and will no longer be supported by the FreeBSD Security Team. (This was initially scheduled to occur today, but in light of the imminent arrival of FreeBSD 7.4 I decided to push it back a month.) Users of FreeBSD 7.1 are strongly encouraged to upgrade to either FreeBSD 7.3, FreeBSD 8.1, or the upcoming FreeBSD 7.4 or 8.2 within the next month. The current supported branches and expected EoL dates are: +-+ | Branch | Release | Type | Release date | Estimated EoL | |---+++-+-| |RELENG_7 |n/a |n/a |n/a |last release + 2y| |---+++-+-| |RELENG_7_1 |7.1-RELEASE |Extended|January 4, 2009 |February 28, 2011| |---+++-+-| |RELENG_7_3 |7.3-RELEASE |Extended|March 23, 2010 |March 31, 2012 | |---+++-+-| |RELENG_7_4 |7.4-RELEASE |Extended|not yet |release + 2 years| |---+++-+-| |RELENG_8 |n/a |n/a |n/a |last release + 2y| |---+++-+-| |RELENG_8_1 |8.1-RELEASE |Extended|July 23, 2010|July 31, 2012| |---+++-+-| |RELENG_8_2 |8.2-RELEASE |Normal |not yet |release + 1 year | +-+ - -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk1Gg6cACgkQFdaIBMps37K69QCfZb4Xa6YEiSOtXDPLfGpi6crE fGEAnjANjSSDXolX5c9VBximNpOD/1rw =5yHH -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: RELEASE_6 -> RELEASE_8
On Mon, 31 Jan 2011, Mark Andrews wrote: I was trying to upgrade a machine from RELEASE_6 (latest) to RELEASE_8 (latest) via source. I was unable to get make buildworld to complete. You need latest N to go to N+1, so a 6.4-RELEASE or RELENG_6 after that should be able to go to 7.x but not straight to 8. Multi-Release-Hop-Updates have been working once in a while in the past with other releases but were never officially supported. Not even a say 7.1 might be able to go to straight 8.x btw. Unfortunately UPDATING wasn't really updated in that regard for a while and might still say "To upgrade in-place from 5.x-stable to current" in older branches; I know it was fixed in 9 for 8 in [1] as part of a large cleanup but I think a similar change never made it back to other stable branches. /bz [1] http://svn.freebsd.org/viewvc/base/head/UPDATING?revision=196789&view=markup -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: KERN - mfi driver for Dell raid h200 on r210 servers
On 1/30/11 11:18 PM, Ollivier Robert wrote: > According to Garrett Cooper: >> +1. PERC7 should be supported by mfi(4) (required bits may need to >> be added to mfi(4) though as you've pointed out, but additional >> details may need to be obtained from Dell). > > I've seen mention of the mps driver (in head) and of the mfi one. Which one > is the right one? > > For the OP: I may be gaining access to a test system (Dell R210 / as in new > dedibox[1]) tomorrow on which I could test my mfsboot image... > As requested, find below the output of a verbose boot. Notice how mps0 is rather unhappy here: (probe0:mps0:0:0:0): Error 22, Unretryable error (probe0:mps0:0:0:0): Down reving Protocol Version from 4 to 2? (probe1:mps0:0:1:0): Error 22, Unretryable error (probe1:mps0:0:1:0): Down reving Protocol Version from 4 to 2? (probe0:mps0:0:0:0): Error 22, Unretryable error (probe0:mps0:0:0:0): Down reving Protocol Version from 4 to 2? (probe1:mps0:0:1:0): Error 22, Unretryable error (probe1:mps0:0:1:0): Down reving Protocol Version from 4 to 2? (probe0:mps0:0:0:0): Error 22, Unretryable error (probe1:mps0:0:1:0): Error 22, Unretryable error Table 'FACP' at 0xbf6c3bb4 Table 'APIC' at 0xbf6c3478 APIC: Found table at 0xbf6c3478 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 2 ACPI ID 2: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 4 ACPI ID 3: enabled SMP: Added CPU 4 (AP) MADT: Found CPU APIC ID 6 ACPI ID 4: enabled SMP: Added CPU 6 (AP) MADT: Found CPU APIC ID 1 ACPI ID 5: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 3 ACPI ID 6: enabled SMP: Added CPU 3 (AP) MADT: Found CPU APIC ID 5 ACPI ID 7: enabled SMP: Added CPU 5 (AP) MADT: Found CPU APIC ID 7 ACPI ID 8: enabled SMP: Added CPU 7 (AP) MADT: Found CPU APIC ID 40 ACPI ID 9: disabled MADT: Found CPU APIC ID 41 ACPI ID 10: disabled MADT: Found CPU APIC ID 42 ACPI ID 11: disabled MADT: Found CPU APIC ID 43 ACPI ID 12: disabled MADT: Found CPU APIC ID 44 ACPI ID 13: disabled MADT: Found CPU APIC ID 45 ACPI ID 14: disabled MADT: Found CPU APIC ID 46 ACPI ID 15: disabled MADT: Found CPU APIC ID 47 ACPI ID 16: disabled MADT: Found CPU APIC ID 48 ACPI ID 17: disabled MADT: Found CPU APIC ID 49 ACPI ID 18: disabled MADT: Found CPU APIC ID 50 ACPI ID 19: disabled MADT: Found CPU APIC ID 51 ACPI ID 20: disabled MADT: Found CPU APIC ID 52 ACPI ID 21: disabled MADT: Found CPU APIC ID 53 ACPI ID 22: disabled MADT: Found CPU APIC ID 54 ACPI ID 23: disabled MADT: Found CPU APIC ID 55 ACPI ID 24: disabled MADT: Found CPU APIC ID 56 ACPI ID 25: disabled MADT: Found CPU APIC ID 57 ACPI ID 26: disabled MADT: Found CPU APIC ID 58 ACPI ID 27: disabled MADT: Found CPU APIC ID 59 ACPI ID 28: disabled MADT: Found CPU APIC ID 60 ACPI ID 29: disabled MADT: Found CPU APIC ID 61 ACPI ID 30: disabled MADT: Found CPU APIC ID 62 ACPI ID 31: disabled MADT: Found CPU APIC ID 63 ACPI ID 32: disabled Copyright (c) 1992-2011 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-PRERELEASE #1 r218017M: Sat Jan 29 12:23:01 CET 2011 r...@centre.keltia.net:/usr/obj/data/work/freebsd/8v28/sys/GENERIC amd64 Preloaded elf kernel "/boot/kernel/kernel" at 0x83355000. Preloaded elf obj module "/boot/kernel/zfs.ko" at 0x833551b8. Preloaded elf obj module "/boot/kernel/opensolaris.ko" at 0x83355820. Preloaded mfs_root "/mfsroot" at 0x83355e10. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1861998768 Hz CPU: Intel(R) Xeon(R) CPU L3426 @ 1.87GHz (1862.00-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106e5 Family = 6 Model = 1e Stepping = 5 Features=0xbfebfbff Features2=0x98e3fd AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant real memory = 17179869184 (16384 MB) Physical memory chunk(s): 0x1000 - 0x00097fff, 618496 bytes (151 pages) 0x0339 - 0xbf698fff, 3157299200 bytes (770825 pages) 0x0001 - 0x0004200a, 13422493696 bytes (3276976 pages) avail memory = 16476315648 (15713 MB) ACPI APIC Table: INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target INTR: Adding local APIC 4 as a target INTR: Adding local APIC 5 as a target INTR: Adding local APIC 6 as a target INTR: Adding local APIC 7 as a target FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 x86bios: IVT 0x00-0x0004ff at 0xff00 x86bios: SSEG 0x01-0x01 at
Error produced by static ip setting: ifconfig: inet: bad value
List, Hi. I use following setting for my wireless networking enviroment: ifconfig_wlan0="mode 11g bssid my:bssid wepmode on weptxkey 1 wepkey 1:0x11 DHCP" But I don't like DHCP and want to use static ip, so I tried: ifconfig_wlan0="mode 11g bssid my:bssid wepmode on weptxkey 1 wepkey 1:0x11 inet 192.168.1.144 netmask 255.255.255.0" But the setting makes BSD networking not working anymore, and when the system starts up, there's an error message: ifconfig: inet: bad value What's wrong? How to use static ip in my wireless networking? -- Regards, Yue Wu Key Laboratory of Modern Chinese Medicines Department of Traditional Chinese Medicine China Pharmaceutical University No.24, Tongjia Xiang Street, Nanjing 210009, China ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Error produced by static ip setting: ifconfig: inet: bad value
On Mon, Jan 31, 2011 at 08:57:29PM +0800, Yue Wu wrote: > List, > > Hi. > > I use following setting for my wireless networking enviroment: > > ifconfig_wlan0="mode 11g bssid my:bssid wepmode on weptxkey 1 wepkey > 1:0x11 DHCP" > > But I don't like DHCP and want to use static ip, so I tried: > > ifconfig_wlan0="mode 11g bssid my:bssid wepmode on weptxkey 1 wepkey > 1:0x11 inet 192.168.1.144 netmask 255.255.255.0" > > But the setting makes BSD networking not working anymore, and when the > system starts up, there's an error message: > > ifconfig: inet: bad value > > What's wrong? How to use static ip in my wireless networking? > The setting: ifconfig_wlan0="inet 192.168.1.111 netmask 255.255.255.0 mode 11g bssid my:ssid wepmode on weptxkey 1 wepkey 1:0x11" works for me, don't know why, maybe the inet string must be put at the head of the value? -- Regards, Yue Wu Key Laboratory of Modern Chinese Medicines Department of Traditional Chinese Medicine China Pharmaceutical University No.24, Tongjia Xiang Street, Nanjing 210009, China ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
TRIM support in UFS - any chance of it in ZFS ?
Just saw that the TRIM support for UFS has been MFC'd. Excellent stuff. I was wondering if there were any plans to do similar for ZFS at all ? thanks, -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Error produced by static ip setting: ifconfig: inet: bad value
On Monday, January 31, 2011 13:57:29 Yue Wu wrote: > List, > > Hi. > > I use following setting for my wireless networking enviroment: > > ifconfig_wlan0="mode 11g bssid my:bssid wepmode on weptxkey 1 > wepkey 1:0x11 DHCP" > > But I don't like DHCP and want to use static ip, so I tried: > > ifconfig_wlan0="mode 11g bssid my:bssid wepmode on weptxkey 1 > wepkey 1:0x11 inet 192.168.1.144 netmask 255.255.255.0" > > But the setting makes BSD networking not working anymore, and when > the system starts up, there's an error message: > > ifconfig: inet: bad value > > What's wrong? How to use static ip in my wireless networking? Remove the 'inet', it isn't required. -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: TRIM support in UFS - any chance of it in ZFS ?
On 31/01/2011 14:41, Pete French wrote: Just saw that the TRIM support for UFS has been MFC'd. Excellent stuff. I was wondering if there were any plans to do similar for ZFS at all ? AFAIK it isn't yet supported in upstream ZFS. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: nfsd hung on ufs vnode lock
On Friday, January 28, 2011 8:10:41 pm John Hickey wrote: > There was a previous thread about this, but it doesn't look like there was > any resolution: > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-May/056986.html > > I run a fileserver for an Emulab (www.emulab.net) system. As such, the > exports table is constantly modified as experiments are swapped in and out. We also get a lot of researchers using NFS for strange things. In this case, the exclusive lock was for a cache directory shared by about 36 machines running Ubuntu 8.04 and mounting with NFSv2. Eventually, all our nfsd processes get stuck since the exclusive lock for the directory is never released. I could use any and all pointers on getting this fixed. > > What I am running: > > jjh@users: ~$ uname -a > FreeBSD users.isi.deterlab.net 7.3-RELEASE-p2 FreeBSD 7.3-RELEASE-p2 #9: Tue > Sep 14 16:24:57 PDT 2010 r...@users.isi.deterlab.net:/usr/obj/usr/src/sys/USERS7 i386 > > Here are the sleepchains for my system (note that 0xd1f72678 appears twice): > > 0xce089cf0: tag syncer, type VNON > usecount 1, writecount 0, refcount 2 mountedhere 0 > flags () > lock type syncer: EXCL (count 1) by thread 0xcdb4b000 (pid 46) > > 0xd1f72678: tag ufs, type VDIR > usecount 2, writecount 0, refcount 67 mountedhere 0 > flags () > v_object 0xd1e90e80 ref 0 pages 1 > lock type ufs: EXCL (count 1) by thread 0xce1146c0 (pid 866) with 62 pending > ino 143173560, on dev mfid0s1f From the stack trace, this vnode is the directory vnode that is the parent of the new file being created. > (kgdb) bt > #0 sched_switch (td=0xce1146c0, newtd=Variable "newtd" is not available. > ) at /usr/src/sys/kern/sched_ule.c:1936 > #1 0xc080a4a6 in mi_switch (flags=Variable "flags" is not available. > ) at /usr/src/sys/kern/kern_synch.c:444 > #2 0xc0837aab in sleepq_switch (wchan=Variable "wchan" is not available. > ) at /usr/src/sys/kern/subr_sleepqueue.c:497 > #3 0xc08380f6 in sleepq_wait (wchan=0xd4176394) at > /usr/src/sys/kern/subr_sleepqueue.c:580 > #4 0xc080a92a in _sleep (ident=0xd4176394, lock=0xc0ceb498, priority=80, > wmesg=0xc0bb656e "ufs", timo=0) at /usr/src/sys/kern/kern_synch.c:230 > #5 0xc07ea9fa in acquire (lkpp=0xcd7375a0, extflags=Variable "extflags" is > not available. > ) at /usr/src/sys/kern/kern_lock.c:151 > #6 0xc07eb2ec in _lockmgr (lkp=0xd4176394, flags=8194, interlkp=0xd41763c4, > td=0xce1146c0, file=0xc0bc20c8 "/usr/src/sys/kern/vfs_subr.c", line=2062) > at /usr/src/sys/kern/kern_lock.c:384 > #7 0xc0a24765 in ffs_lock (ap=0xcd737608) at > /usr/src/sys/ufs/ffs/ffs_vnops.c:377 > #8 0xc0b26876 in VOP_LOCK1_APV (vop=0xc0ca4740, a=0xcd737608) at > vnode_if.c:1618 > #9 0xc0896d76 in _vn_lock (vp=0xd417633c, flags=8194, td=0xce1146c0, > file=0xc0bc20c8 "/usr/src/sys/kern/vfs_subr.c", line=2062) at vnode_if.h:851 Note that, this vnode (vp) doesn't show up in your list above. You can try using my gdb scripts at www.freebsd.org/~jhb/gdb (you want gdb6* and do 'source gdb6'). You can then do 'vprint vp' at this frame and should see lock details about who holds this lock. However, I would not expect the vnode lock for a new i-node to be already held. There's a chance though you are tripping over the bug fixed by these two changes: Author: jhb Date: Fri Jul 16 20:23:24 2010 New Revision: 210173 URL: http://svn.freebsd.org/changeset/base/210173 Log: When the MNTK_EXTENDED_SHARED mount option was added, some filesystems were changed to defer the setting of VN_LOCK_ASHARE() (which clears LK_NOSHARE in the vnode lock's flags) until after they had determined if the vnode was a FIFO. This occurs after the vnode has been inserted into a VFS hash or some similar table, so it is possible for another thread to find this vnode via vget() on an i-node number and block on the vnode lock. If the lockmgr interlock (vnode interlock for vnode locks) is not held when clearing the LK_NOSHARE flag, then the lk_flags field can be clobbered. As a result the thread blocked on the vnode lock may never get woken up. Fix this by holding the vnode interlock while modifying the lock flags in this case. The softupdates code also toggles LK_NOSHARE in one function to close a race with snapshots. Fix this code to grab the interlock while fiddling with lk_flags. Author: jhb Date: Fri Aug 20 20:58:57 2010 New Revision: 211533 URL: http://svn.freebsd.org/changeset/base/211533 Log: Revert 210173 as it did not properly fix the bug. It assumed that the VI_LOCK() for a given vnode was used as the internal interlock for that vnode's v_lock lockmgr lock. This is not the case. Instead, add dedicated routines to toggle the LK_NOSHARE and LK_CANRECURSE flags. These routines lock the lockmgr lock's internal interlock to synchronize the updates to the flags member with other threads attempting to acquire the lock. The VN_LOCK_A*() macros now invoke these routines, and the softupdates
Re: RELEASE_6 -> RELEASE_8
On Mon, Jan 31, 2011 at 10:45:33AM +1100, Mark Andrews wrote: > > I was trying to upgrade a machine from RELEASE_6 (latest) > to RELEASE_8 (latest) via source. I was unable to get > make buildworld to complete. ... > Sorry this report is not more complete as I blew away the > tree and restarted on RELEASE_7 as a stepping stone to > RELEASE_8. > > RELEASE_7 latest will at least compile. However it will > only run in safe mode as it dies in ar5212Detach with a > kernel fault. I suspect this will also be a problem for > RELEASE_8. I think the main problem is that neither /usr/src/UPDATING (at least as of 7.3) nor the handbook includes the advisory it should against trying to skip over a major release branch (e.g. 6.x direct to 8.x, 5.x direct to 7.x) when performing a source upgrade. I know I have read that repeatedly in the past, and have always structured my upgrades around the rule that your upgrades must, so to speak, "pass through" and stop at each major branch. However, I don't see that rule documented anywhere in the obvious places one would look for it. The latter problem with the kernel fault sounds like a driver problem in RELEASE_7 latest. That stuff does happen and I would guess it's probably a distinct issue, unless you see that it goes away if you rebuild RELEASE_7 from source while running RELEASE_7. -- Clifton -- Clifton Royston -- clift...@iandicomputing.com / clift...@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: nfsd hung on ufs vnode lock
On Mon, Jan 31, 2011 at 12:00:29PM -0500, John Baldwin wrote: > On Friday, January 28, 2011 8:10:41 pm John Hickey wrote: > > There was a previous thread about this, but it doesn't look like there was > > any resolution: > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-May/056986.html > > > > I run a fileserver for an Emulab (www.emulab.net) system. As such, the > > exports table is constantly modified as experiments are swapped in and > out. We also get a lot of researchers using NFS for strange things. In this > case, the exclusive lock was for a cache directory shared by about > 36 machines running Ubuntu 8.04 and mounting with NFSv2. Eventually, all our > nfsd processes get stuck since the exclusive lock for the directory > is never released. I could use any and all pointers on getting this fixed. > > > > What I am running: > > > > jjh@users: ~$ uname -a > > FreeBSD users.isi.deterlab.net 7.3-RELEASE-p2 FreeBSD 7.3-RELEASE-p2 #9: > > Tue Sep 14 16:24:57 PDT 2010 > r...@users.isi.deterlab.net:/usr/obj/usr/src/sys/USERS7 i386 > > > > Here are the sleepchains for my system (note that 0xd1f72678 appears twice): > > > > 0xce089cf0: tag syncer, type VNON > > usecount 1, writecount 0, refcount 2 mountedhere 0 > > flags () > > lock type syncer: EXCL (count 1) by thread 0xcdb4b000 (pid 46) > > > > 0xd1f72678: tag ufs, type VDIR > > usecount 2, writecount 0, refcount 67 mountedhere 0 > > flags () > > v_object 0xd1e90e80 ref 0 pages 1 > > lock type ufs: EXCL (count 1) by thread 0xce1146c0 (pid 866) with 62 > > pending > > ino 143173560, on dev mfid0s1f > > From the stack trace, this vnode is the directory vnode that is the parent > of the new file being created. > > > (kgdb) bt > > #0 sched_switch (td=0xce1146c0, newtd=Variable "newtd" is not available. > > ) at /usr/src/sys/kern/sched_ule.c:1936 > > #1 0xc080a4a6 in mi_switch (flags=Variable "flags" is not available. > > ) at /usr/src/sys/kern/kern_synch.c:444 > > #2 0xc0837aab in sleepq_switch (wchan=Variable "wchan" is not available. > > ) at /usr/src/sys/kern/subr_sleepqueue.c:497 > > #3 0xc08380f6 in sleepq_wait (wchan=0xd4176394) at > > /usr/src/sys/kern/subr_sleepqueue.c:580 > > #4 0xc080a92a in _sleep (ident=0xd4176394, lock=0xc0ceb498, priority=80, > > wmesg=0xc0bb656e "ufs", timo=0) at /usr/src/sys/kern/kern_synch.c:230 > > #5 0xc07ea9fa in acquire (lkpp=0xcd7375a0, extflags=Variable "extflags" is > > not available. > > ) at /usr/src/sys/kern/kern_lock.c:151 > > #6 0xc07eb2ec in _lockmgr (lkp=0xd4176394, flags=8194, > > interlkp=0xd41763c4, td=0xce1146c0, file=0xc0bc20c8 > > "/usr/src/sys/kern/vfs_subr.c", > line=2062) > > at /usr/src/sys/kern/kern_lock.c:384 > > #7 0xc0a24765 in ffs_lock (ap=0xcd737608) at > > /usr/src/sys/ufs/ffs/ffs_vnops.c:377 > > #8 0xc0b26876 in VOP_LOCK1_APV (vop=0xc0ca4740, a=0xcd737608) at > > vnode_if.c:1618 > > #9 0xc0896d76 in _vn_lock (vp=0xd417633c, flags=8194, td=0xce1146c0, > > file=0xc0bc20c8 "/usr/src/sys/kern/vfs_subr.c", line=2062) at > vnode_if.h:851 > > Note that, this vnode (vp) doesn't show up in your list above. You can try > using my gdb scripts at www.freebsd.org/~jhb/gdb (you want gdb6* and do > 'source gdb6'). You can then do 'vprint vp' at this frame and should see > lock details about who holds this lock. However, I would not expect the > vnode lock for a new i-node to be already held. jjh@users: ~$ kgdb /boot/kernel/kernel vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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-marcel-freebsd"... Unread portion of the kernel message buffer: panic: kdb_sysctl_panic cpuid = 1 Uptime: 4d3h36m42s Physical memory: 3566 MB Dumping 437 MB: 422 406 390 374 358 342 326 310 294 278 262 246 230 214 198 182 166 150 134 118 102 86 70 54 38 22 6 #0 doadump () at pcpu.h:196 196 pcpu.h: No such file or directory. in pcpu.h (kgdb) source gdb6 (kgdb) proc 866 [Switching to thread 66 (Thread 100104)]#0 sched_switch (td=0xce1146c0, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1936 1936cpuid = PCPU_GET(cpuid); (kgdb) frame 9 #9 0xc0896d76 in _vn_lock (vp=0xd417633c, flags=8194, td=0xce1146c0, file=0xc0bc20c8 "/usr/src/sys/kern/vfs_subr.c", line=2062) at vnode_if.h:851 warning: Source file is more recent than executable. 851 return (VOP_LOCK1_APV(vp->v_op, &a)); (kgdb) vprint vp 0xd417633c: tag none, type VBAD usecount 0, writecount 0, refcount 1 mountedhere 0x0 flags (VI_DOOMED) lock type ufs: UNLOCKED with 1 pending (kgdb) > There's a chance though you are tripping over the bug fixed by these two > changes: I should be
Re: Error produced by static ip setting: ifconfig: inet: bad value
On Mon, Jan 31, 2011 at 02:50:25PM +0100, Bernhard Schmidt wrote: > On Monday, January 31, 2011 13:57:29 Yue Wu wrote: > > List, > > > > Hi. > > > > I use following setting for my wireless networking enviroment: > > > > ifconfig_wlan0="mode 11g bssid my:bssid wepmode on weptxkey 1 > > wepkey 1:0x11 DHCP" > > > > But I don't like DHCP and want to use static ip, so I tried: > > > > ifconfig_wlan0="mode 11g bssid my:bssid wepmode on weptxkey 1 > > wepkey 1:0x11 inet 192.168.1.144 netmask 255.255.255.0" > > > > But the setting makes BSD networking not working anymore, and when > > the system starts up, there's an error message: > > > > ifconfig: inet: bad value > > > > What's wrong? How to use static ip in my wireless networking? > > Remove the 'inet', it isn't required. > Thanks Schmidt, I haven't tried with your advice because the issue has gone after I put the `inet' in front of the value of ifconfig_wlan0, I will take a note for your hint and try it next time ;p p.s., examples in the handbook [1] have the `inet', why? [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-wireless.html -- Regards, Yue Wu Key Laboratory of Modern Chinese Medicines Department of Traditional Chinese Medicine China Pharmaceutical University No.24, Tongjia Xiang Street, Nanjing 210009, China ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Error produced by static ip setting: ifconfig: inet: bad value
On Tue, Feb 01, 2011 at 09:55:47AM +0800, Yue Wu wrote: > On Mon, Jan 31, 2011 at 02:50:25PM +0100, Bernhard Schmidt wrote: > > On Monday, January 31, 2011 13:57:29 Yue Wu wrote: > > > List, > > > > > > Hi. > > > > > > I use following setting for my wireless networking enviroment: > > > > > > ifconfig_wlan0="mode 11g bssid my:bssid wepmode on weptxkey 1 > > > wepkey 1:0x11 DHCP" > > > > > > But I don't like DHCP and want to use static ip, so I tried: > > > > > > ifconfig_wlan0="mode 11g bssid my:bssid wepmode on weptxkey 1 > > > wepkey 1:0x11 inet 192.168.1.144 netmask 255.255.255.0" > > > > > > But the setting makes BSD networking not working anymore, and when > > > the system starts up, there's an error message: > > > > > > ifconfig: inet: bad value > > > > > > What's wrong? How to use static ip in my wireless networking? > > > > Remove the 'inet', it isn't required. > > > > Thanks Schmidt, I haven't tried with your advice because the issue has > gone after I put the `inet' in front of the value of ifconfig_wlan0, I > will take a note for your hint and try it next time ;p > > p.s., examples in the handbook [1] have the `inet', why? > > [1] > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-wireless.html The advice you were given is incorrect; you should absolutely be specifying the address family (inet). The syntax of the ifconfig(8) line matters -- meaning, you're hitting an intentional design limitation of the parser. You cannot put the "inet x.x.x.x" part at the end. Please see the ifconfig(8) man page. Here's the specific part: ifconfig [-L] [-k] [-m] [-n] interface [create] [address_family] [address [dest_address]] [parameters] address_family = something like "inet", "inet6", etc. address = something like 1.2.3.4 or, or a CIDR address like 1.2.3.4/24 (which would expand to "inet 1.2.3.4 netmask 255.255.255.0") parameters = dependent upon the interface you're configuring. Fore wireless interfaces, you'll need to see the man page section for that. Hope this helps. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Why ssid is a required parameter for wpa_supplicant?
Hi, list, As the title, I like to use bssid to specify the wireless networking I want to connect, so if ssid changed, I don't need to change the configure file. Just curious why ssid is a required parameter, it would be nice if only one of ssid and bssid is required instead. -- Regards, Yue Wu Key Laboratory of Modern Chinese Medicines Department of Traditional Chinese Medicine China Pharmaceutical University No.24, Tongjia Xiang Street, Nanjing 210009, China ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Error produced by static ip setting: ifconfig: inet: bad value
On Mon, Jan 31, 2011 at 06:05:56PM -0800, Jeremy Chadwick wrote: > On Tue, Feb 01, 2011 at 09:55:47AM +0800, Yue Wu wrote: > > On Mon, Jan 31, 2011 at 02:50:25PM +0100, Bernhard Schmidt wrote: > > > On Monday, January 31, 2011 13:57:29 Yue Wu wrote: > > > > List, > > > > > > > > Hi. > > > > > > > > I use following setting for my wireless networking enviroment: > > > > > > > > ifconfig_wlan0="mode 11g bssid my:bssid wepmode on weptxkey 1 > > > > wepkey 1:0x11 DHCP" > > > > > > > > But I don't like DHCP and want to use static ip, so I tried: > > > > > > > > ifconfig_wlan0="mode 11g bssid my:bssid wepmode on weptxkey 1 > > > > wepkey 1:0x11 inet 192.168.1.144 netmask 255.255.255.0" > > > > > > > > But the setting makes BSD networking not working anymore, and when > > > > the system starts up, there's an error message: > > > > > > > > ifconfig: inet: bad value > > > > > > > > What's wrong? How to use static ip in my wireless networking? > > > > > > Remove the 'inet', it isn't required. > > > > > > > Thanks Schmidt, I haven't tried with your advice because the issue has > > gone after I put the `inet' in front of the value of ifconfig_wlan0, I > > will take a note for your hint and try it next time ;p > > > > p.s., examples in the handbook [1] have the `inet', why? > > > > [1] > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-wireless.html > > The advice you were given is incorrect; you should absolutely be > specifying the address family (inet). The syntax of the ifconfig(8) > line matters -- meaning, you're hitting an intentional design limitation > of the parser. You cannot put the "inet x.x.x.x" part at the end. > > Please see the ifconfig(8) man page. Here's the specific part: > > ifconfig [-L] [-k] [-m] [-n] interface [create] [address_family] > [address [dest_address]] [parameters] > > address_family = something like "inet", "inet6", etc. > > address = something like 1.2.3.4 or, or a CIDR address like 1.2.3.4/24 > (which would expand to "inet 1.2.3.4 netmask 255.255.255.0") > > parameters = dependent upon the interface you're configuring. Fore > wireless interfaces, you'll need to see the man page section for that. > > Hope this helps. > It helps a lot, thank you for detailed explanation, I get it now :) -- Regards, Yue Wu Key Laboratory of Modern Chinese Medicines Department of Traditional Chinese Medicine China Pharmaceutical University No.24, Tongjia Xiang Street, Nanjing 210009, China ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
em0: Watchdog timeout -- resetting
Hello, Freebsd-stable. System is 8-STABLE (8.2-PRERELEASE) with very last e1000 driver (cvsupped 27 Jan, last commits to e1000 were done 22 Jan). NIC is: em0: port 0xdc00-0xdc1f mem 0xfea4-0xfea5,0xfea79000-0xfea79fff irq 20 at device 25.0 on pci0 em0: No MSI/MSIX using a Legacy IRQ em0: [FILTER] em0@pci0:0:25:0:class=0x02 card=0x82681043 chip=0x10bd8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82566DM Gigabit Ethernet Adapter (82566DM)' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xfea4, size 131072, enabled bar [14] = type Memory, range 32, base 0xfea79000, size 4096, enabled bar [18] = type I/O Port, range 32, base 0xdc00, size 32, enabled It is on-board LAN on ASUS P5R-VM DO MoBo (Q35 chipset). I have these tunables in "/etc/loader.conf" hw.em.rxd=4096 hw.em.txd=4096 And these non-standard sysctls: dev.em.0.rx_int_delay=200 dev.em.0.tx_int_delay=200 dev.em.0.rx_abs_int_delay=4000 dev.em.0.tx_abs_int_delay=4000 dev.em.0.rx_processing_limit=4096 Several times a day I got messages like this: em0: Watchdog timeout -- resetting em0: Queue(0) tdh = 1302, hw tdt = 1265 em0: TX(0) desc avail = 31,Next TX to Clean = 1296 em0: Watchdog timeout -- resetting em0: Queue(0) tdh = 3999, hw tdt = 3959 em0: TX(0) desc avail = 31,Next TX to Clean = 3990 em0: Watchdog timeout -- resetting em0: Queue(0) tdh = 1431, hw tdt = 1394 em0: TX(0) desc avail = 31,Next TX to Clean = 1425 And all connections are reset. Before latest commits to driver this system paniced in swi_clock. Now it works without panics, but seems, that problem is not fixed completely. -- // Black Lion AKA Lev Serebryakov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
