Re: 7.1-R to RELENG_7 upgrade breaks re nic
Hi, On Tue, Feb 24, 2009 at 08:12:18PM -0500, Steve Wills wrote: I upgraded my 7.1-RELEASE system to RELENG_7 yesterday and after booting, re0 works for only a short time, then gives re0: PHY read failed over and over. Does anyone have a suggestion on how to debug? The Patch from 20090213113955.ge12...@michelle.cdnetworks.co.kr (Thread: fun with re, Feb 13 on this list) helped for me. You may try it and could also give feedback so it gets included. - Olli -- | Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin | | Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ | | Ich bin das Internet. Sowahr ich Gott helfe. | | Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! | ___ 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: 7.1-R to RELENG_7 upgrade breaks re nic
Hi, On Wed, Feb 25, 2009 at 09:22:39AM +0100, Oliver Brandmueller wrote: On Tue, Feb 24, 2009 at 08:12:18PM -0500, Steve Wills wrote: I upgraded my 7.1-RELEASE system to RELENG_7 yesterday and after booting, re0 works for only a short time, then gives re0: PHY read failed over and over. Does anyone have a suggestion on how to debug? The Patch from 20090213113955.ge12...@michelle.cdnetworks.co.kr (Thread: fun with re, Feb 13 on this list) helped for me. You may try it and could also give feedback so it gets included. Sorry: From: Pyun YongHyeon Subject: Re: fun with if_re - Olli -- | Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin | | Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ | | Ich bin das Internet. Sowahr ich Gott helfe. | | Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! | ___ 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: Big problems with 7.1 locking up :-(
FYI, I'm currently awaiting testing results from Pete on the MFC of a number of routing table locking fixes, and once that's merged (hopefully tomorrow?) I'll start on the patches in the above PR. I've taken a crash-course in routing table locking in the last few days... :-) Just to let you know that I have had zero crashes since I out the patch live on sunday. Of course thats only three days, but it does look very much like it has fixed it. I am also running with the other routing table patch too.. At this point no news is good news, as it is just sitting there ticking away nicely to itself. I will roll it out to a few more machines over the next few days. But looking good so far, I would encourage other people to try the ptches if they are having problems... -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: Big problems with 7.1 locking up :-(
On Wed, 25 Feb 2009, Pete French wrote: FYI, I'm currently awaiting testing results from Pete on the MFC of a number of routing table locking fixes, and once that's merged (hopefully tomorrow?) I'll start on the patches in the above PR. I've taken a crash-course in routing table locking in the last few days... :-) Just to let you know that I have had zero crashes since I out the patch live on sunday. Of course thats only three days, but it does look very much like it has fixed it. I am also running with the other routing table patch too.. At this point no news is good news, as it is just sitting there ticking away nicely to itself. I will roll it out to a few more machines over the next few days. But looking good so far, I would encourage other people to try the ptches if they are having problems... Thanks -- I've gone ahead and merged the patch to 7.x (r189026) so that I can look at the PR and get that in-progress. Since the code affected by the PR is no longer in 8.x, I'll merge directly to 7.x, and probably fairly quickly since you've had it in production for a while. Robert N M Watson Computer Laboratory University of Cambridge ___ 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
Various route locking fixes merged to stable/7 (was: Re: Big problems with 7.1 locking up :-()
Just a minor heads up: I've merged both Kip Macy's lock order fixes to the kernel routing code, and the route locking and reference counting fixes from kern/130652 to stable/7. These fixes should correct a number of reported network-related hangs. We might want to release a subset of these as an errata patch to 7.1 if they shake out well in 7-stable. Thanks again, especially, to Pete for his evaluation of bugs and patches, Kip for his fixes in head, and to Dmitrij Tejblum for his submission of the fixes in the above-mentioned PR. Robert N M Watson Computer Laboratory University of Cambridge On Wed, 25 Feb 2009, Robert Watson wrote: On Wed, 25 Feb 2009, Pete French wrote: FYI, I'm currently awaiting testing results from Pete on the MFC of a number of routing table locking fixes, and once that's merged (hopefully tomorrow?) I'll start on the patches in the above PR. I've taken a crash-course in routing table locking in the last few days... :-) Just to let you know that I have had zero crashes since I out the patch live on sunday. Of course thats only three days, but it does look very much like it has fixed it. I am also running with the other routing table patch too.. At this point no news is good news, as it is just sitting there ticking away nicely to itself. I will roll it out to a few more machines over the next few days. But looking good so far, I would encourage other people to try the ptches if they are having problems... Thanks -- I've gone ahead and merged the patch to 7.x (r189026) so that I can look at the PR and get that in-progress. Since the code affected by the PR is no longer in 8.x, I'll merge directly to 7.x, and probably fairly quickly since you've had it in production for a while. Robert N M Watson Computer Laboratory University of Cambridge ___ 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 ___ 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: Recommended wireless card (or is there a chance to get either iwi or ath fixed)?
On 2/24/09, SDH Support ad...@stardothosting.com wrote: I tried using my ath based D-Link DWL G650, which still seems to have some issues in regard to interrupt handling: I've been able to get /most/ wireless cards working with ndiswrapper. *BSD doesnt have ndiswrapper. -- Paul ___ 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: 7.1 new install halts on BTX error
On Thu, 2009-01-29 at 12:13 +0900, David Adam wrote: I upgraded my 7.0 system to 7.1-RELEASE with freebsd-update only to find that it no longer boots correctly, instead crashing with a BTX backtrace. If I break to the loader prompt and use 'ls /boot', I also get a backtrace. A new install of 7.1 on this hardware using a separate SCSI card and drive array also leads to a BTX backtrace. I have copied this below as the first (most repeatable) error and also included the other problems. A fresh install of 7.0 works fine. FreeSBIE 1.0, based on FreeBSD 5.3, also boots fine and will happily list the contents of the original drive's /boot in the loader, although refuses to load the kernel. The FreeBSD 7.1 install CD also boots and allows me to install over FTP. A patch has just gone into HEAD which may fix this problem. If you want to test it, it's at http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/boot/i386/btx/btx/btx.S.diff?r1=1.47;r2=1.48 and should apply cleanly. Thanks, Gavin I have run into BTX problems on this machine before under -CURRENT (see http://lists.freebsd.org/pipermail/freebsd-current/2008-October/089460.html ). Dmesg from 7.0 in http://www.freebsd.org/cgi/query-pr.cgi?prp=125769-1-txtn=/patch.txt A new install of 7.1-RELEASE on separate disks leads to this backtrace: int=000d err=1840 efl=00010207 eip=0511 eax=04551364 ebx= ecx=00495cae edx=00495cae esi=0009 edi=0001 ebp= esp=00495cae cs=002b ds=0033 es=0033fs=0033 gs=0033 ss=0033 cs:eip=17 00 00 00 00 00 00 0c-00 00 00 00 00 00 00 b9 ae 5c 49 00 00 00 00 b9-ae 5c 49 00 00 00 00 c8 ss:esp=43 18 3c 01 74 08 3c 04-0f 85 e4 00 00 00 0f b6 43 19 88 86 94 00 00 00-c7 46 30 00 00 00 00 3c BTX error on boot with the 7.0 partition that has been upgraded to 7.1: int=000d err= efl=00010a92 eip=0430 eax=ff4c ebx=6c94 ecx=0001 edx=0080 esi=0001 edi=9416 ebp= esp=0008f8b4 cs=002b ds=0033 es=002bfs=0033 gs=0033 ss=0033 cs:eip=6c 7f 94 48 00 00 00 00-0f af c1 47 00 00 00 00 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ss:eip=2b 00 00 00 33 00 00 00-00 0c 04 00 5f ad 08 04 00 00 00 00 0f 00 00 00-00 00 00 00 24 1c 06 00 BTX halted If I break to the loader prompt and try 'ls /boot', I get this backtrace: int=0006 err= efl=00010203 eip=00040c08 eax=00c6 ebx=0008 ecx=eb00 edx=00c6 esi=0004 edi=00c2 ebp= esp=0008f8b4 cs=002b ds=0033 es=002bfs=0033 gs=0033 ss=0033 cs:eip=8f 49 40 00 94 49 00 cb-00 00 04 00 00 00 fc 07 80 00 00 00 04 00 00 00-94 49 00 00 00 00 00 00 ss:eip=00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 BTX halted Any thoughts or suggestions? I will stay on 7.0 for now but have a fairly large supply of spare drives so I can test new installs if required. Thanks, David Adam zanc...@ucc.gu.uwa.edu.au ___ 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 ___ 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: Recommended wireless card (or is there a chance to get either iwi or ath fixed)?
On Wed, Feb 25, 2009 at 8:26 AM, Paul B. Mahol one...@gmail.com wrote: On 2/24/09, SDH Support ad...@stardothosting.com wrote: I tried using my ath based D-Link DWL G650, which still seems to have some issues in regard to interrupt handling: I've been able to get /most/ wireless cards working with ndiswrapper. *BSD doesnt have ndiswrapper. Yes, it does: http://www.freebsd.org/cgi/man.cgi?query=ndismanpath=FreeBSD+7.1-RELEASE -- My preferred quotation of Robert Louis Stevenson is You cannot make an omelette without breaking eggs. Not because I like the omelettes, but because I like the sound of eggs being broken. ___ 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: Recommended wireless card (or is there a chance to get either iwi or ath fixed)?
2009/2/24 SDH Support ad...@stardothosting.com: I tried using my ath based D-Link DWL G650, which still seems to have some issues in regard to interrupt handling: I've been able to get /most/ wireless cards working with ndiswrapper. This is just my personal opinion, and I tend to make scarce use of the word hate - but in this case: I really hate ndiswrapper. It might be suitable for some people, but I rather get some piece hardware that is properly supported. Bugs are bad luck, of course, as well as a kernel module author who stops working. But at least I don't have to rely on a windows driver. ___ 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
Recommended wireless card (or is there a chance to get either iwi or ath fixed)?
2009/2/25 Paul B. Mahol one...@gmail.com: On 2/24/09, SDH Support ad...@stardothosting.com wrote: I tried using my ath based D-Link DWL G650, which still seems to have some issues in regard to interrupt handling: I've been able to get /most/ wireless cards working with ndiswrapper. *BSD doesnt have ndiswrapper. -- Paul ___ 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 Yeah it does... [ch...@amnesiac]~% ndisgen == -- Windows(r) driver converter --- == This script is designed to guide you through the process of converting a Windows(r) binary driver module and .INF specification file into a FreeBSD ELF kernel module for use with the NDIS compatibility system. The following options are available: 1] Learn about the NDIS compatibility system 2] Convert individual firmware files 3] Convert driver 4] Exit Enter your selection here and press return: -- R $h ! $- ! $+ $@ $2 @ $1 .UUCP. (sendmail.cf) ___ 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: Recommended wireless card (or is there a chance to get either iwi or ath fixed)?
2009/2/25 Christian Walther cptsa...@gmail.com: 2009/2/24 SDH Support ad...@stardothosting.com: I tried using my ath based D-Link DWL G650, which still seems to have some issues in regard to interrupt handling: I've been able to get /most/ wireless cards working with ndiswrapper. This is just my personal opinion, and I tend to make scarce use of the word hate - but in this case: I really hate ndiswrapper. It might be suitable for some people, but I rather get some piece hardware that is properly supported. Bugs are bad luck, of course, as well as a kernel module author who stops working. But at least I don't have to rely on a windows driver. ___ 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 True, but ndiswrapper for me was an epiphany of the incredible things free software can do. I found it right back in Debian Woody, where my Ralink card wasn't supported. I got sick of Linux and moved to BSD, where the ral driver was instantly recognised and loaded. -- R $h ! $- ! $+ $@ $2 @ $1 .UUCP. (sendmail.cf) ___ 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: Recommended wireless card (or is there a chance to get either iwi or ath fixed)?
On 2/24/09, SDH Support ad...@stardothosting.com wrote: I tried using my ath based D-Link DWL G650, which still seems to have some issues in regard to interrupt handling: I've been able to get /most/ wireless cards working with ndiswrapper. *BSD doesnt have ndiswrapper. There is the ndis driver in FreeBSD. I've used a lot ndis with an Intel 2200 BG card. iwi was not reliable. ___ 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: 7.1 hangs in cache_lookup mutex?
On Tuesday 24 February 2009 4:46:28 pm Guy Helmer wrote:
I think I may have found a clue regarding some of the hangs I'm seeing
on FreeBSD 7.1.
I have a program (kvoop), compiled under FreeBSD 6 and using
compatibility libraries under FreeBSD 7, that seems to be consistently
involved during these hangs. This time, I noticed that many processes
are stopped, waiting on the ufs lock. I can't tell for certain, but I
assume this kvoop process 33203 is blocking the other processes. The
kvoop process looks to me like it is waiting for a mutex, but nothing
shows up being deadlocked. Am I on the right track? Is there something
else I should be looking for?
(kgdb) proc 33203
[Switching to thread 129 (Thread 100241)]#0 sched_switch (
td=0xff0019109a50, newtd=0x0, flags=1)
at ../../../kern/sched_ule.c:1944
1944cpuid = PCPU_GET(cpuid);
(kgdb) where
#0 sched_switch (td=0xff0019109a50, newtd=0x0, flags=1)
at ../../../kern/sched_ule.c:1944
#1 0x803a573b in mi_switch (flags=1, newtd=0x0)
at ../../../kern/kern_synch.c:440
#2 0x803d1214 in turnstile_wait (ts=Variable ts is not available.
)
at ../../../kern/subr_turnstile.c:748
#3 0x80392db0 in _mtx_lock_sleep (m=0x8083c220,
tid=18446742974618442320, opts=Variable opts is not available.
) at ../../../kern/kern_mutex.c:420
#4 0x80392ea6 in _mtx_lock_flags (m=0x8083c220, opts=0,
file=0x805bd438 ../../../kern/vfs_cache.c, line=327)
at ../../../kern/kern_mutex.c:186
#5 0x80403bc6 in cache_lookup (dvp=0xff00013e0dc8,
vpp=0xa2d93a18, cnp=0xa2d93a40)
at ../../../kern/vfs_cache.c:327
#6 0x80404093 in vfs_cache_lookup (ap=Variable ap is not
available.
)
at ../../../kern/vfs_cache.c:674
#7 0x805628a0 in VOP_LOOKUP_APV (vop=0x8076e440,
a=0xa2d936b0) at vnode_if.c:99
#8 0x80409afd in lookup (ndp=0xa2d939f0) at vnode_if.h:57
#9 0x8040a824 in namei (ndp=0xa2d939f0)
at ../../../kern/vfs_lookup.c:219
#10 0x8041dc4f in vn_open_cred (ndp=0xa2d939f0,
flagp=0xa2d9393c, cmode=0, cred=0xff0001588600,
fp=0xff0001964200) at ../../../kern/vfs_vnops.c:188
#11 0x8041ccc7 in kern_open (td=0xff0019109a50,
path=0xac30 Address 0xac30 out of bounds, pathseg=Variable
pathseg is not available.
)
at ../../../kern/vfs_syscalls.c:1032
#12 0x80544660 in ia32_syscall (frame=0xa2d93c80)
at ../../../amd64/ia32/ia32_syscall.c:182
#13 0x805014d0 in Xint0x80_syscall () at ia32_exception.S:65
#14 0x28284037 in ?? ()
(kgdb) frame 4
#4 0x80392ea6 in _mtx_lock_flags (m=0x8083c220, opts=0,
file=0x805bd438 ../../../kern/vfs_cache.c, line=327)
at ../../../kern/kern_mutex.c:186
186 _get_sleep_lock(m, curthread, opts, file, line);
(kgdb) list
181 (mtx_lock() of spin mutex %s @ %s:%d,
m-lock_object.lo_name,
182 file, line));
183 WITNESS_CHECKORDER(m-lock_object, opts | LOP_NEWORDER
| LOP_EXCLUSIVE,
184 file, line);
185
186 _get_sleep_lock(m, curthread, opts, file, line);
187 LOCK_LOG_LOCK(LOCK, m-lock_object, opts,
m-mtx_recurse, file,
188 line);
189 WITNESS_LOCK(m-lock_object, opts | LOP_EXCLUSIVE,
file, line);
190 curthread-td_locks++;
(kgdb) print *m
$2 = {lock_object = {lo_name = 0x805bd5d2 Name Cache,
lo_type = 0x805bd5d2 Name Cache, lo_flags = 16973824,
lo_witness_data = {lod_list = {stqe_next = 0x807cd600},
lod_witness = 0x807cd600}}, mtx_lock = 4, mtx_recurse = 0}
Is this from a coredump or while the system is live? mtx_lock = 4 indicates
the mutex is unlocked, so there shouldn't be any threads waiting on it.
--
John Baldwin
___
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: 7.1 hangs in cache_lookup mutex?
John Baldwin wrote:
On Tuesday 24 February 2009 4:46:28 pm Guy Helmer wrote:
I think I may have found a clue regarding some of the hangs I'm seeing
on FreeBSD 7.1.
I have a program (kvoop), compiled under FreeBSD 6 and using
compatibility libraries under FreeBSD 7, that seems to be consistently
involved during these hangs. This time, I noticed that many processes
are stopped, waiting on the ufs lock. I can't tell for certain, but I
assume this kvoop process 33203 is blocking the other processes. The
kvoop process looks to me like it is waiting for a mutex, but nothing
shows up being deadlocked. Am I on the right track? Is there something
else I should be looking for?
(kgdb) proc 33203
[Switching to thread 129 (Thread 100241)]#0 sched_switch (
td=0xff0019109a50, newtd=0x0, flags=1)
at ../../../kern/sched_ule.c:1944
1944cpuid = PCPU_GET(cpuid);
(kgdb) where
#0 sched_switch (td=0xff0019109a50, newtd=0x0, flags=1)
at ../../../kern/sched_ule.c:1944
#1 0x803a573b in mi_switch (flags=1, newtd=0x0)
at ../../../kern/kern_synch.c:440
#2 0x803d1214 in turnstile_wait (ts=Variable ts is not available.
)
at ../../../kern/subr_turnstile.c:748
#3 0x80392db0 in _mtx_lock_sleep (m=0x8083c220,
tid=18446742974618442320, opts=Variable opts is not available.
) at ../../../kern/kern_mutex.c:420
#4 0x80392ea6 in _mtx_lock_flags (m=0x8083c220, opts=0,
file=0x805bd438 ../../../kern/vfs_cache.c, line=327)
at ../../../kern/kern_mutex.c:186
#5 0x80403bc6 in cache_lookup (dvp=0xff00013e0dc8,
vpp=0xa2d93a18, cnp=0xa2d93a40)
at ../../../kern/vfs_cache.c:327
#6 0x80404093 in vfs_cache_lookup (ap=Variable ap is not
available.
)
at ../../../kern/vfs_cache.c:674
#7 0x805628a0 in VOP_LOOKUP_APV (vop=0x8076e440,
a=0xa2d936b0) at vnode_if.c:99
#8 0x80409afd in lookup (ndp=0xa2d939f0) at vnode_if.h:57
#9 0x8040a824 in namei (ndp=0xa2d939f0)
at ../../../kern/vfs_lookup.c:219
#10 0x8041dc4f in vn_open_cred (ndp=0xa2d939f0,
flagp=0xa2d9393c, cmode=0, cred=0xff0001588600,
fp=0xff0001964200) at ../../../kern/vfs_vnops.c:188
#11 0x8041ccc7 in kern_open (td=0xff0019109a50,
path=0xac30 Address 0xac30 out of bounds, pathseg=Variable
pathseg is not available.
)
at ../../../kern/vfs_syscalls.c:1032
#12 0x80544660 in ia32_syscall (frame=0xa2d93c80)
at ../../../amd64/ia32/ia32_syscall.c:182
#13 0x805014d0 in Xint0x80_syscall () at ia32_exception.S:65
#14 0x28284037 in ?? ()
(kgdb) frame 4
#4 0x80392ea6 in _mtx_lock_flags (m=0x8083c220, opts=0,
file=0x805bd438 ../../../kern/vfs_cache.c, line=327)
at ../../../kern/kern_mutex.c:186
186 _get_sleep_lock(m, curthread, opts, file, line);
(kgdb) list
181 (mtx_lock() of spin mutex %s @ %s:%d,
m-lock_object.lo_name,
182 file, line));
183 WITNESS_CHECKORDER(m-lock_object, opts | LOP_NEWORDER
| LOP_EXCLUSIVE,
184 file, line);
185
186 _get_sleep_lock(m, curthread, opts, file, line);
187 LOCK_LOG_LOCK(LOCK, m-lock_object, opts,
m-mtx_recurse, file,
188 line);
189 WITNESS_LOCK(m-lock_object, opts | LOP_EXCLUSIVE,
file, line);
190 curthread-td_locks++;
(kgdb) print *m
$2 = {lock_object = {lo_name = 0x805bd5d2 Name Cache,
lo_type = 0x805bd5d2 Name Cache, lo_flags = 16973824,
lo_witness_data = {lod_list = {stqe_next = 0x807cd600},
lod_witness = 0x807cd600}}, mtx_lock = 4, mtx_recurse = 0}
Is this from a coredump or while the system is live? mtx_lock = 4 indicates
the mutex is unlocked, so there shouldn't be any threads waiting on it.
That was from running kgdb on a vmcore file. Would the state of the
mutex be different than if I was running kgdb on a live kernel?
Thanks,
Guy
___
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: Recommended wireless card (or is there a chance to get either iwi or ath fixed)?
Chris Rees wrote: 2009/2/25 Paul B. Mahol one...@gmail.com: On 2/24/09, SDH Support ad...@stardothosting.com wrote: I tried using my ath based D-Link DWL G650, which still seems to have some issues in regard to interrupt handling: I've been able to get /most/ wireless cards working with ndiswrapper. *BSD doesnt have ndiswrapper. -- Paul ___ 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 Yeah it does... [ch...@amnesiac]~% ndisgen == -- Windows(r) driver converter --- == This script is designed to guide you through the process of converting a Windows(r) binary driver module and .INF specification file into a FreeBSD ELF kernel module for use with the NDIS compatibility system. The following options are available: 1] Learn about the NDIS compatibility system 2] Convert individual firmware files 3] Convert driver 4] Exit Enter your selection here and press return: ndiswrapper refers to the linux version of the Bill Paul's project for freebsd. They are very different; though have the same goal. Sam ___ 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: Big problems with 7.1 locking up :-(
On Wed, Feb 25, 2009 at 11:04:29AM +, Robert Watson wrote: On Wed, 25 Feb 2009, Pete French wrote: FYI, I'm currently awaiting testing results from Pete on the MFC of a number of routing table locking fixes, and once that's merged (hopefully tomorrow?) I'll start on the patches in the above PR. I've taken a crash-course in routing table locking in the last few days... :-) Just to let you know that I have had zero crashes since I out the patch live on sunday. Of course thats only three days, but it does look very much like it has fixed it. I am also running with the other routing table patch too.. At this point no news is good news, as it is just sitting there ticking away nicely to itself. I will roll it out to a few more machines over the next few days. But looking good so far, I would encourage other people to try the ptches if they are having problems... Thanks -- I've gone ahead and merged the patch to 7.x (r189026) so that I can look at the PR and get that in-progress. Since the code affected by the PR is no longer in 8.x, I'll merge directly to 7.x, and probably fairly quickly since you've had it in production for a while. Great! I hope this patch will also fix the mysterious hangs I've experienced on Soekris routers since nov/dec 2008. Will try in a few days and report back any further hangs. Robert N M Watson Computer Laboratory University of Cambridge Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ 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
Possible fix to BTX boot hangs in 6.4 and 7.1
On Tuesday 24 February 2009 6:11:15 pm John Baldwin wrote: Author: jhb Date: Tue Feb 24 23:11:15 2009 New Revision: 189017 URL: http://svn.freebsd.org/changeset/base/189017 Log: Fix some more issues with the real mode BTX. The old BTX passed the general purpose registers from the 32-bit client to the routines called via virtual 86 mode. The new BTX did the same thing. However, it turns out that some instructions behave differently in virtual 86 mode and real mode (even though this is under-documented). For example, the LEAVE instruction will cause an exception in real mode if any of the upper 16-bits of %ebp are non-zero after it executes. In virtual 8086 mode the upper 16-bits are simply ignored. This could cause faults in hardware interrupt handlers that inherited an %ebp larger than 0x from the 32-bit client (loader, boot2, etc.) while running in real mode. To fix, when executing hardware interrupt handlers provide an explicit clean state where all the general purpose and segment registers are zero upon entry to the interrupt handler. While here, I attempted to simplify the control flow in the 'intusr' code that sets up the various stack frames and exits protected mode to invoke the requested routine via real mode. A huge thanks to Tor Egge (tegge@) for debugging this issue. Submitted by: tegge Reviewed by:tegge Tested by: bz MFC after: 1 week This has been confirmed to fix at least some of the boot hangs reported with the BTX changes in 6.4 and 7.1. If you had problems with the new boot code in 6.4 or 7.1 this fix is probably worth trying out. -- John Baldwin ___ 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: 7.1-R to RELENG_7 upgrade breaks re nic
On Tue, Feb 24, 2009 at 08:12:18PM -0500, Steve Wills wrote: Hi, I upgraded my 7.1-RELEASE system to RELENG_7 yesterday and after booting, re0 works for only a short time, then gives re0: PHY read failed over and over. Does anyone have a suggestion on how to debug? I need more information for your hardware revision. Would you show me dmesg output and revision number of if_re.c? ___ 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: fun with if_re
On Mon, Feb 23, 2009 at 12:54:12PM +0100, Oliver Brandmueller wrote: Hi, On Fri, Feb 13, 2009 at 08:39:55PM +0900, Pyun YongHyeon wrote: Ok, try attached patch. Index: sys/dev/re/if_re.c === --- sys/dev/re/if_re.c (revision 187352) +++ sys/dev/re/if_re.c (working copy) @@ -158,6 +158,8 @@ /* Tunables. */ [...] This seems to have fixed a regression I found after the latest re changes. While the changes lead to a situation, where the re interface (as opposed to before) seems to always attach, I had the problem that after 1-2 days it failed (sorry, was just about to investigate when I tried your patch and thus didn't write down the error message associated). With your patch my re seems to be running fine for the last days now. That's odd. The patch just revert register mapping method for RTL8169SC family as memory mapped register access seems to have problems on RTL8169SC controllers. From the output below I think your controller is RTL8168C PCIe controller so the patch has no effect on your controller. Would you tell me more details on your issue? CURRENT has more robust code for PCIe based controllers so how about giving it a try on stable/7? Just copying if_re.c/if_rl.c/if_rlreg.h from HEAD to stable/7 should work. r...@pci0:4:0:0: class=0x02 card=0x392c1462 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet re0: RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe Gigabit Ethernet port 0xd800-0xd8ff mem 0xfeaff000-0xfeaf,0xf8ff-0xf8ff irq 18 at device 0.0 on pci4 re0: Chip rev. 0x3c00 re0: MAC rev. 0x0040 miibus0: MII bus on re0 rgephy0: RTL8169S/8110S/8211B media interface PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:21:85:1e:8b:c9 re0: [FILTER] ___ 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: Various route locking fixes merged to stable/7 (was: Re: Big problems with 7.1 locking up :-()
On Wed, 25 Feb 2009, Robert Watson wrote: Just a minor heads up: I've merged both Kip Macy's lock order fixes to the kernel routing code, and the route locking and reference counting fixes from kern/130652 to stable/7. These fixes should correct a number of reported network-related hangs. We might want to release a subset of these as an errata patch to 7.1 if they shake out well in 7-stable. +1 Charles Robert N M Watson Computer Laboratory University of Cambridge On Wed, 25 Feb 2009, Robert Watson wrote: On Wed, 25 Feb 2009, Pete French wrote: FYI, I'm currently awaiting testing results from Pete on the MFC of a number of routing table locking fixes, and once that's merged (hopefully tomorrow?) I'll start on the patches in the above PR. I've taken a crash-course in routing table locking in the last few days... :-) Just to let you know that I have had zero crashes since I out the patch live on sunday. Of course thats only three days, but it does look very much like it has fixed it. I am also running with the other routing table patch too.. At this point no news is good news, as it is just sitting there ticking away nicely to itself. I will roll it out to a few more machines over the next few days. But looking good so far, I would encourage other people to try the ptches if they are having problems... Thanks -- I've gone ahead and merged the patch to 7.x (r189026) so that I can look at the PR and get that in-progress. Since the code affected by the PR is no longer in 8.x, I'll merge directly to 7.x, and probably fairly quickly since you've had it in production for a while. Robert N M Watson Computer Laboratory University of Cambridge ___ 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 ___ 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 ___ 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
7.1 reports serial ports disabled (but they work OK)
I have an amd64 7.1 install on a SuperMicro C2SBA+ and I see the following in dmesg.. sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: 16550A-compatible COM port port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] However the ports do work fine. I was under the impression that this test was bogus on !i386 and had be removed but I guess I'm wrong :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: 7.1-R to RELENG_7 upgrade breaks re nic
On Feb 25, 2009, at 7:38 PM, Pyun YongHyeon wrote: I need more information for your hardware revision. Would you show me dmesg output and revision number of if_re.c? I assume you only need the re0 related output. If you need the full dmesg, let me know. re0: RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe Gigabit Ethernet port 0x7e00-0x7eff mem 0xfd3ff000-0xfd3f, 0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 on pci8 re0: Chip rev. 0x2800 re0: MAC rev. 0x0010 re0: Ethernet address: 00:1f:d0:af:1a:4c re0: [FILTER] re0: link state changed to UP $FreeBSD: src/sys/dev/re/if_re.c,v 1.95.2.41 2009/02/09 01:38:01 yongari Exp $ I get 3 link state DOWN/UP notices when DHCP client starts. It works for exactly 60 seconds after boot, then stops. Patch from earlier fun with if_re thread didn't help, if_re.c from -CURRENT failed to build. Reverting back to rev 1.95.2.36.2.2 fixes it. Thanks, Steve ___ 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: 7.1-R to RELENG_7 upgrade breaks re nic
On Wed, Feb 25, 2009 at 10:47:07PM -0500, Steve Wills wrote: On Feb 25, 2009, at 7:38 PM, Pyun YongHyeon wrote: I need more information for your hardware revision. Would you show me dmesg output and revision number of if_re.c? I assume you only need the re0 related output. If you need the full dmesg, let me know. re0: RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe Gigabit Ethernet port 0x7e00-0x7eff mem 0xfd3ff000-0xfd3f, 0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 on pci8 re0: Chip rev. 0x2800 re0: MAC rev. 0x0010 re0: Ethernet address: 00:1f:d0:af:1a:4c re0: [FILTER] re0: link state changed to UP $FreeBSD: src/sys/dev/re/if_re.c,v 1.95.2.41 2009/02/09 01:38:01 yongari Exp $ I get 3 link state DOWN/UP notices when DHCP client starts. It works That's normal(Technically this is not correct behavior but it's the way how it was implemented in driver). for exactly 60 seconds after boot, then stops. I guess re(4) thinks it lost established link. How about unplug and then replug UTP cable? Would you show me devinfo -rv | grep phy? Patch from earlier fun with if_re thread didn't help, Your issue is completely different one. if_re.c from -CURRENT failed to build. You have to use if_re.c/if_rl.c and if_rlreg.h from CURRENT to build it on stable. Reverting back to rev 1.95.2.36.2.2 fixes it. Your controller looks like RTL8168D PCIe controller. ATM I have no idea why if_re.c 1.95.2.41 does not work. I'll let you know if I find a clue. ___ 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: 7.1-R to RELENG_7 upgrade breaks re nic
On Feb 25, 2009, at 11:10 PM, Pyun YongHyeon wrote: I get 3 link state DOWN/UP notices when DHCP client starts. It works That's normal(Technically this is not correct behavior but it's the way how it was implemented in driver). Ok. Not a huge deal, but would be nice to fix, of course. for exactly 60 seconds after boot, then stops. I guess re(4) thinks it lost established link. How about unplug and then replug UTP cable? Would you show me devinfo -rv | grep phy? rgephy0 pnpinfo oui=0x732 model=0x11 rev=0x2 at phyno=1 Patch from earlier fun with if_re thread didn't help, Your issue is completely different one. Ok, good to know. if_re.c from -CURRENT failed to build. You have to use if_re.c/if_rl.c and if_rlreg.h from CURRENT to build it on stable. Ok. I can test that if you wish. Reverting back to rev 1.95.2.36.2.2 fixes it. Your controller looks like RTL8168D PCIe controller. ATM I have no idea why if_re.c 1.95.2.41 does not work. I'll let you know if I find a clue. Ok. I'm happy to test any patches. Thanks, Steve ___ 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: 7.1-R to RELENG_7 upgrade breaks re nic
On Wed, Feb 25, 2009 at 11:15:38PM -0500, Steve Wills wrote: [...] I guess re(4) thinks it lost established link. How about unplug and then replug UTP cable? Would you show me devinfo -rv | grep phy? rgephy0 pnpinfo oui=0x732 model=0x11 rev=0x2 at phyno=1 And unpluging/repluging didn't help? You have to use if_re.c/if_rl.c and if_rlreg.h from CURRENT to build it on stable. Ok. I can test that if you wish. I guess re(4) in CURRENT may not help as rev 1.95.2.41 still has issues on your controller. ___ 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
ural driver stalls under FreeBSD7.1
I have a Buffalo WLI-U2-KG54-AI wireless USB adaptor. It has been malfunctioning for quite a while under FreeBSD7.0 and 7.1 Typically, It works for a while until eventually it stalls data transfers completely. It always seems to do this after an unspecified amount of time. I know the hardware isn't at fault because the device works fine under Linux. ___ 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: ural driver stalls under FreeBSD7.1
On Thu, Feb 26, 2009 at 01:20:36PM +0900, Nathan Butcher wrote: I have a Buffalo WLI-U2-KG54-AI wireless USB adaptor. It has been malfunctioning for quite a while under FreeBSD7.0 and 7.1 Typically, It works for a while until eventually it stalls data transfers completely. It always seems to do this after an unspecified amount of time. I know the hardware isn't at fault because the device works fine under Linux. Could you please check that `ifconfig ifname -bgscan' disabling the background scan helps your symptom? regards, Weongyo Jeong ___ 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: 7.1-R to RELENG_7 upgrade breaks re nic
On Wed, Feb 25, 2009 at 10:47:07PM -0500 I heard the voice of Steve Wills, and lo! it spake thus: re0: RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe Gigabit Ethernet port 0x7e00-0x7eff mem 0xfd3ff000-0xfd3f, 0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 on pci8 re0: Chip rev. 0x2800 re0: MAC rev. 0x0010 For a data point, I have re0: RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe Gigabit Ethernet port 0xdc00-0xdcff mem 0xfdfff000-0xfdff irq 19 at device 0.0 on pci2 re0: turning off MSI enable bit. re0: Chip rev. 0x3800 re0: MAC rev. 0x on a recent 7-STABLE (if_re.c,v 1.95.2.41) which is working OK. I have gotten a few Tx interrupt watchdog timeouts, which I don't recall seeing in any quantity before, but they don't seem to cause any problems. It was previously on a ~Dec 2007 RELENG_7 and worked fine there (and had MSI enabled, as well). -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ 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: 7.1-R to RELENG_7 upgrade breaks re nic
On Feb 25, 2009, at 11:27 PM, Pyun YongHyeon wrote: On Wed, Feb 25, 2009 at 11:15:38PM -0500, Steve Wills wrote: [...] I guess re(4) thinks it lost established link. How about unplug and then replug UTP cable? Would you show me devinfo -rv | grep phy? rgephy0 pnpinfo oui=0x732 model=0x11 rev=0x2 at phyno=1 And unpluging/repluging didn't help? No, didn't help. Steve ___ 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: 7.1 reports serial ports disabled (but they work OK)
On Thu, 26 Feb 2009, Daniel O'Connor wrote: I have an amd64 7.1 install on a SuperMicro C2SBA+ and I see the following in dmesg.. sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: 16550A-compatible COM port port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] However the ports do work fine. The last 3 lines of each show success, despite earlier prevarication. I was under the impression that this test was bogus on !i386 and had be removed but I guess I'm wrong :) As long as they work! cheers, Ian ___ 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: 7.1 reports serial ports disabled (but they work OK)
On Thursday 26 February 2009 16:29:18 Ian Smith wrote: sio1: 16550A-compatible COM port port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] However the ports do work fine. The last 3 lines of each show success, despite earlier prevarication. Yes, but the implication is that they might not work :) I was under the impression that this test was bogus on !i386 and had be removed but I guess I'm wrong :) As long as they work! Yeah, makes for annoying questions by end users though. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: 7.1-R to RELENG_7 upgrade breaks re nic
On Wed, Feb 25, 2009 at 11:06:45PM -0600, Matthew D. Fuller wrote: On Wed, Feb 25, 2009 at 10:47:07PM -0500 I heard the voice of Steve Wills, and lo! it spake thus: re0: RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe Gigabit Ethernet port 0x7e00-0x7eff mem 0xfd3ff000-0xfd3f, 0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 on pci8 re0: Chip rev. 0x2800 re0: MAC rev. 0x0010 For a data point, I have re0: RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe Gigabit Ethernet port 0xdc00-0xdcff mem 0xfdfff000-0xfdff irq 19 at device 0.0 on pci2 re0: turning off MSI enable bit. re0: Chip rev. 0x3800 re0: MAC rev. 0x on a recent 7-STABLE (if_re.c,v 1.95.2.41) which is working OK. I have gotten a few Tx interrupt watchdog timeouts, which I don't recall seeing in any quantity before, but they don't seem to cause any If the watchdog timeout message contains missed Tx interrupts you can safely ignore them. It's not real watchdog timeouts. problems. It was previously on a ~Dec 2007 RELENG_7 and worked fine there (and had MSI enabled, as well). Try re(4) in HEAD. You may not see watchdog timeouts anymore. ___ 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
