8.1-RC2: bug in ng_ipfw (ng_ipfw doesn't return a packet back to ipfw)
After upgrading from RELENG_8_0 to RELENG_8_1 (8.1-RC2) I have noticed that ng_ipfw doesn't return a packet back to ipfw after `ipfw add ... netgraph ...` due to the bug in the sys/netgraph/ng_ipfw.c The attached patch solves the problem. -- Alexander patch-sys-netgraph-ng_ipfw.c Description: Binary data ___ 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: buildworld fails building _dtrace_tools
On Wed, Jun 30, 2010 at 04:26:53PM +0200, Claude Buisson wrote: Anton Shterenlikht wrote: HI Claude http://www.mavetju.org/mail/view_message.php?list=freebsd-currentid=3145015 Have you got a reply to your question? Have you solved it? I'm now seeing the same on i386. Any advice? many thanks anton Hi Anton, I never received any reply.. I have done a binary search and found that the problem was introduced by svn revision r204339 dated February 25 by ru@ Let's admit that the problem was uncovered, not introduced. The mentioned commit of mine is correct (try building stuff statically linked to see). Reverting this revision by hand, I have been able to build a system WITH_CDDL which could be used to rebuild from the current sources. But the original problem is always here: how to make a buildworld WITH_CDDL on a system built WITHOUT_CDDL ? I sent a message to ru@ on April 11, without success.. Sorry, still swamped with real life issues. I think there are basically two options for bootstrapping: - reinstall stuff from some release media (e.g., take the required bits from the nearby release tarballs) - manually build/install the missing stuff from sources (if you have'em) Then do a buildworld. This problem is similar to the case when you lose /usr/bin/make or some other host tool used during the build. ___ 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
deadlkres() panic
On a recent -current, I got the following panic from deadlkres:
Assertion wchan != NULL failed at /usr/src-nfs/sys/kern/subr_sleepqueue.c:680
Tracing pid 0 tid 100058 td 0xff00024bf7a0
kdb_enter() at kdb_enter+0x3d
panic() at panic+0x176
sleepq_type() at sleepq_type+0x56
deadlkres() at deadlkres+0x224
fork_exit() at fork_exit+0x12a
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff8074976d30, rbp = 0 ---
(Hand transcribed, doadump() hung)
deadlkres() came across a TD_IS_SLEEPING()'ing thread that was not a
sleepqueue (ie, td-td_wchan == NULL).
I don't think this is an invalid state for thread to be in: After adding itself
to a sleepq and setting a timeout, the thread calls sleepq_timedwait_sig().
sleepq_catch_signals() determines there is a signal pending so it removes the
thread from the sleepq via sleepq_resume_thread(). Returning to
sleepq_timedwait_sig(), in the call to sleepq_check_timeout(), the thread is
unable to cancel the timeout because it is already firing (likely waiting on
thread_lock()). So the thread calls TD_SET_SLEEPING() followed by mi_switch().
deadlkres() then picks up thread_lock(), finding td is TD_IS_SLEEPING()
!TD_ON_SLEEPQ().
The attached patch takes care of the panic for me.--- /usr/src-nfs/sys/kern/kern_clock.c 2010-06-30 03:38:25.0 -0500
+++ kern_clock.c 2010-07-01 02:19:39.048697991 -0500
@@ -232,7 +232,8 @@
panic(%s: possible deadlock detected for %p, blocked for %d ticks\n,
__func__, td, tticks);
}
-} else if (TD_IS_SLEEPING(td)) {
+} else if (TD_IS_SLEEPING(td)
+TD_ON_SLEEPQ(td)) {
/* Handle ticks wrap-up. */
if (ticks td-td_blktick) {
___
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: tstVMStructRC segfault: Cannot build virtualbox-ose on 8-STABLE amd64
On 01/07/2010 01:03, Yuri Pankov wrote: On Wed, Jun 30, 2010 at 10:58:23PM -0300, Mario Sergio Fujikawa Ferreira wrote: snip $ script gdb.log gdb work/VirtualBox-3.2.4_OSE/out/freebsd.amd64/debug/bin/tstVMStructRC work/VirtualBox-3.2.4_OSE/tstVMStructRC.core Script started on Fri Jun 11 20:00:36 2010 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 amd64-marcel-freebsd... Core was generated by `tstVMStructRC'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib32/libc.so.7...done. Loaded symbols for /usr/lib32/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x080508bc in _start () (gdb) bt #0 0x080508bc in _start () #1 0x0001 in ?? () (gdb) quit That looks like backtrace from 32 bit binary, are you sure your lib32 is up to date, i.e. you don't have WITHOUT_LIB32 in src.conf? I don't even have a /etc/src.conf. :) Furthermore, my /usr/lib32 files all have the same timestamp Jun 27 06:05 from my last installworld. Jun 27 06:05 /usr/lib32/libc.so.7 Jun 27 06:04 /libexec/ld-elf.so.1 Jun 27 06:06 /libexec/ld-elf32.so.1 Script done on Fri Jun 11 20:00:38 2010 The latest build log for 3.2.4 can be found at: http://people.freebsd.org/~lioux/virtualbox/2010061100/emulators__virtualbox-ose__build_log.txt.bz2 The port work directory of the failed 3.2.4 build can be found at: http://people.freebsd.org/~lioux/virtualbox/2010061100/emulators__virtualbox-ose__work.tar.xz Ever since my move from 8-STABLE i386 to 8-STABLE amd64, I have not been able to build emulators/virtualbox-ose successfully. From version 3.1.8 up to the latest 3.2.6. I can only build emulators/virtualbox-ose-kmod. I have tried to provide as much information as possible. Is there anything I can do to help track down this problem? Let me know if there is anything I can to do help track this down. Regards, Mario Ferreira ___ 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: Ports doesnt respect fetch environment settings
2010/6/30 Dag-Erling Smørgrav d...@des.no: Tom Evans tevans...@googlemail.com writes: Sorry to bump this again. I've diluted this issue down to the core points and raised as a pr - can someone take a look, see if my solution is correct and commit if appropriate? Sorry, fell through the cracks. Your analysis is correct, but I'm not 100% sure about the patch. Can you verify that your change does not introduce the possibility of an infinite loop in edge cases? I don't *think* it does, but like I said, I'm not 100% sure and I don't have time to reacquaint myself with the code right now, especially not that particularly nasty part of it :) DES -- Dag-Erling Smørgrav - d...@des.no Like you said, it's quite a large chunk of code to understand. I think you might be right, there could be a situation where a misbehaving proxy server could make it loop. The process is like this: http_auth_challenges_t proxy_challenges struct initialized (line 1497). The flag 'valid' on the struct is initialized to 0 (line 656) We enter the loop for the first time. We dont add proxy auth the first time through the loop, as 'valid' flag not set (line 1586) We receive the reply and switch on the response code (line 1676) If we receive HTTP_NEED_PROXY_AUTH, and the 'valid' flag is not set (implying we didn't send creds), we simply continue to execute the loop (lines 1703 - 1716). This is where the patch I supplied increments the maximum loop counter. The loop now processes the received headers, and when it receives the 'Proxy-Authenticate' header, it calls http_parse_authenticate with proxy_challenges (line 1795) This then populates the proxy_challenges struct, setting the valid flag. Having processed the headers, the loop then checks that receiving a HTTP_NEED_PROXY_AUTH response has resulted in us now having valid flag set in proxy_challenges, otherwise we goto ouch (out of the loop) (line 1806). The loop ends, and we go through again. I thought for a moment while tracing it through that if a misbehaving proxy server sent a 407 response, but did not add a Proxy-Authenticate header, then we could increase the loop counter but without adding any proxy auth, which would mean an infinite loop. However, there is already that sanity check at the end of the loop to check that if we received a proxy authentication error, and still dont have credentials to supply, then we quickly jump out of the loop. I guess that is a little strange, that we could supply proxy auth credentials, but because the server didnt ask for them correctly, we didnt give them - although that would be quite broken behaviour on the part of the proxy server. I think this does show that the patch could be made a little better. We only want to go through the loop one more time if we have credentials to send, and we have credentials to send if the rv of http_parse_authenticate is good. I also think the same bug would affect fetching from servers requiring authentication, so I've made the same fix there as well. New patch attached Cheers Tom Index: http.c === RCS file: /home/ncvs/src/lib/libfetch/http.c,v retrieving revision 1.78.2.5 diff -u -r1.78.2.5 http.c --- http.c 27 Jan 2010 14:54:48 - 1.78.2.5 +++ http.c 1 Jul 2010 13:45:06 - @@ -1786,12 +1786,14 @@ case hdr_www_authenticate: if (conn-err != HTTP_NEED_AUTH) break; - http_parse_authenticate(p, server_challenges); + if (http_parse_authenticate(p, server_challenges)) + ++n; break; case hdr_proxy_authenticate: if (conn-err != HTTP_NEED_PROXY_AUTH) break; - http_parse_authenticate(p, proxy_challenges); + if (http_parse_authenticate(p, proxy_challenges) == 0); + ++n; break; case hdr_end: /* fall through */ ___ 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: [head tinderbox] failure on i386/pc98
YAMAMOTO Shigeru shig...@iij.ad.jp writes: 'advertise' is added at r209607 and r209609. please chone one of them. I don't know what chone means. The tinderbox uses cvsup and is therefore at the mercy of the whims and idiosyncracies of the cvs exporter. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Ports doesnt respect fetch environment settings
Tom Evans tevans...@googlemail.com writes: I think this does show that the patch could be made a little better. We only want to go through the loop one more time if we have credentials to send, and we have credentials to send if the rv of http_parse_authenticate is good. I also think the same bug would affect fetching from servers requiring authentication, so I've made the same fix there as well. OK, I'll trust your analysis and commit this do head, then ask portmgr to do an exp run with the patch. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: tmpfs use of wired_count
On Wed, Jun 30, 2010 at 11:33 AM, Jeseem S jese...@gmail.com wrote:
hi,
I am a newbie on freebsd kernel. Am currently trying to debug a scenario,
where a custom driver I load uses a lot of static memory and hence lots of
wired pages.
The system still has a lot of free memory ( more than 200MB) and a free
swap
space ( 500MB).
Once I load the driver, the tmpfs loaded on /tmp shows a size of 0.
in tmpfs/tmpfs.h, I see that the free memory available is reduced by number
of wired pages ( see code below).
Is this correct logic ? why do we need to reduce wired count from free
pages available ?
No, it doesn't appear correct. Moreover, it's also incorrect that
cnt.v_cache_count isn't included in the initial calculation of size.
Regards,
Alan
/*
* Returns information about the number of available memory pages,
* including physical and virtual ones.
*
* If 'total' is TRUE, the value returned is the total amount of memory
* pages configured for the system (either in use or free).
* If it is FALSE, the value returned is the amount of free memory pages.
*
* Remember to remove TMPFS_PAGES_RESERVED from the returned value to avoid
* excessive memory usage.
*
*/
static __inline size_t
tmpfs_mem_info(void)
{
size_t size;
size = swap_pager_avail + cnt.v_free_count + cnt.v_inactive_count;
size -= size cnt.v_wire_count ? cnt.v_wire_count : size;
return size;
}
Thanks
Jeseem
___
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
___
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: Potential ressource leak in sys/dev/fb/vesa.c
Hello, while tracking down a bug in vesa.c which caused a crash a friend of mine noticed a potential ressource leak in vesa.c. In line 841 the execution is aborted via return (1); without freeing the already allocated resources. the attached patch changes the line to goto fail; which seems more correct. --- a/sys/dev/fb/vesa.c +++ b/sys/dev/fb/vesa.c @@ -836,7 +836,7 @@ vesa_bios_init(void) version 1.2 or later is required.\n, ((vers 0xf000) 12) * 10 + ((vers 0x0f00) 8), ((vers 0x00f0) 4) * 10 + (vers 0x000f)); - return (1); + goto fail; } VESA_STRCPY(vesa_oemstr, buf-v_oemstr); -- Homepage: www.yamagi.org Jabber: yam...@yamagi.org GnuPG/GPG:0xEFBCCBCB ___ 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: [OpenRD Ultimate] e1000phy(88E1149/88E1121) has a initialize issue
On Sun, Jun 20, 2010 at 09:15:00PM +0900, Norikatsu Shigemura wrote: Hi yongari. On Tue, 15 Jun 2010 11:09:23 -0700 Pyun YongHyeon pyu...@gmail.com wrote: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Jun 13 05:02:14 sidearms kernel: mge1: watchdog timeout Jun 13 05:02:14 sidearms kernel: mge1: Timeout on link-up ^ This part looks like a bug in mge(4). Driver does not know how long it would take to get a valid link. Waiting for valid link in driver initialization does not work(e.g Starting controller without UTP cable may always fail on mge(4)). I think mge(4) should implement correct link state change handling. Thanks for your pointed out. I didn't notice. I'll fix this issue like following on mge_start_locked(). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - if ((ifp-if_drv_flags (IFF_DRV_RUNNING | IFF_DRV_OACTIVE)) != - IFF_DRV_RUNNING) + if (IFM_SUBTYPE(sc-mii-mii_media_active) == IFM_NONE || + (ifp-if_drv_flags (IFF_DRV_RUNNING | IFF_DRV_OACTIVE)) != IFF_DRV_RUNNING) No, that change may not enough to fix a missing link state handling. mge(4) needs a miibus_statchg KOBJ handler and it requires a lot of code changes in mge(4). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I found a initialize issue in e1000phy.c. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --- sys/dev/mii/e1000phy.c.orig 2010-05-01 10:17:15.282196000 +0900 +++ sys/dev/mii/e1000phy.c2010-06-13 16:19:46.616650536 +0900 @@ -278,6 +278,7 @@ case MII_MODEL_MARVELL_E1118: break; case MII_MODEL_MARVELL_E1116: + case MII_MODEL_MARVELL_E1149: page = PHY_READ(sc, E1000_EADR); /* Select page 3, LED control register. */ PHY_WRITE(sc, E1000_EADR, 3); - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I confirmed OK on my environment, OpenRD Ultimate has a 88E1121(I saw it, physically): Once it was there but I removed it due to some other issues seen on Yukon Ultra. That part will program LED access so I guess it wouldn't affect normal network activity. Hum..., like following? At least, by current way, second NIC doesn't link-up if link connected. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - case MII_MODEL_MARVELL_E1118: + case MII_MODEL_MARVELL_E1149: break; This change was also backed out due to 88E8072 issue on establishing 100Mbps link. e1000phy(4)'s 88E1149 PHY handling seems to require more work as some Yukon Ultra/Ultra II still have problems. ATM I have no idea whether this issue comes from MAC controller or not. case MII_MODEL_MARVELL_E1116: page = PHY_READ(sc, E1000_EADR); /* Select page 3, LED control register. */ PHY_WRITE(sc, E1000_EADR, 3); - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 88E1116R might be RGMII variant of 88E1116. Because I don't have controller that has 88E1116R I didn't treat it as 88E1116. With that change could you use straight cable without help of MDI/MDI-X converter? Sorry, I don't have 88E1116R machine, so I don't know. Ok. ___ 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
