On Thu, 9 Dec 2004 23:21:09 +0000 (GMT), freebsd-current-request_at_freebsd.org <freebsd-current-request_at_freebsd.org> wrote: > Send freebsd-current mailing list submissions to > freebsd-current_at_freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-current > or, via email, send a message with subject or body 'help' to > freebsd-current-request_at_freebsd.org > > You can reach the person managing the list at > freebsd-current-owner_at_freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-current digest..." > > Today's Topics: > > 1. panic: sleeping thread (pid 13224) owns a non-sleepable lock > (Peter Holm) > 2. if_ndis is broken with recent 802.11 changes (Daniel O'Connor) > 3. Re: [TEST] ng_bridge ng_l2tp ng_lmi (Gleb Smirnoff) > 4. new TCL vs. current-6 (Mikhail Teterin) > 5. Re: FreeBSD sound distortion problems with SB Live! fixed > with PREEMPTION (Atte Peltomaki) > 6. Microsoft Wireless Intellimouse Explorer (cjohnson_at_wcug.wwu.edu) > 7. Re: new TCL vs. current-6 (trorki_at_area51.capnet.state.tx.us) > 8. Re: WEP does not work? (Hideyuki KURASHINA) > 9. Re: WEP does not work? (Hideyuki KURASHINA) > 10. Re: Microsoft Wireless Intellimouse Explorer (Gavin Atkinson) > 11. Wanted: lots of 6-CURRENT testing (Scott Long) > 12. panic: uma_zone_slab is looping (Peter Holm) > 13. Re: make(1) is broken (Steve Kargl) > 14. Re: Microsoft Wireless Intellimouse Explorer (Gavin Atkinson) > 15. Lots of ACPI warnings with recent -current (Andrey Chernov) > 16. Re: FreeBSD sound distortion problems with SB Live! fixed > with PREEMPTION (Krzysztof Kowalik) > 17. panic not going to debugger? (Andrew R. Reiter) > 18. rtentry recursion panic (fwd) (Andrew R. Reiter) > 19. Re: coredump while trying to build world > (2004.12.08.1600-0800 src) (Mike Hunter) > 20. Re: rtentry recursion panic (fwd) (gnn_at_freebsd.org) > 21. Re: coredump while trying to build world > (2004.12.08.1600-0800 src) (Steve Kargl) > 22. Re: nfs appears broken (Steve Kargl) > 23. Re: coredump while trying to build world > (2004.12.08.1600-0800 src) (Mike Hunter) > 24. Re: protocol timer running before protocol is fully > initialized (again) (was re: panic: mtx_lock() of spin mutex > ...) (Ruslan Ermilov) > 25. Re: page fault panic in > device_get_softc/acpi_pcib_route_interrupt (Pawel Worach) > 26. New kernel netgraph warning with recent -current: PPPoE > (Andrey Chernov) > 27. panic: pmap_mapdev: Couldn't alloc kernel virtual memory on > mpt_attach (Pawel Worach) > 28. Re: panic: process 839(xmms):1 holds process lock but isn't > blocked ona lock (Wilkinson, Alex) > 29. does this mean my kernel is trashed ? (Wilkinson, Alex) > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 9 Dec 2004 09:27:21 +0100 > From: Peter Holm <peter_at_holm.cc> > Subject: panic: sleeping thread (pid 13224) owns a non-sleepable lock > To: current_at_freebsd.org > Message-ID: <20041209082721.GA44545_at_peter.osted.lan> > Content-Type: text/plain; charset=us-ascii > > I can't seem to remember status of this problem? I get a > lot of these lately during stress test: > http://www.holm.cc/stress/log/cons93.html > -- > Peter Holm > > ------------------------------ > > Message: 2 > Date: Thu, 9 Dec 2004 23:06:24 +1030 > From: "Daniel O'Connor" <doconnor_at_gsoft.com.au> > Subject: if_ndis is broken with recent 802.11 changes > To: freebsd-current_at_freebsd.org > Cc: sam_at_freebsd.org > Message-ID: <200412092306.31353.doconnor_at_gsoft.com.au> > Content-Type: text/plain; charset="us-ascii" > > Hi, > The recent mega commit to the 802.11 stuff has broken if_ndis.. > > [inchoate 23:02] /usr/src/sys/modules/if_ndis >make > Warning: Object directory not changed from original /usr/src/sys/modules/if_ndis > cc -O2 -fno-strict-aliasing -pipe -D_KERNEL -DKLD_MODULE -nostdinc -I- -I. -I_at_ -I_at_/contrib/altq -I_at_/../include -finline-limit=8000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c > /usr/src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c: In function `ndis_setstate_80211': > /usr/src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c:1541: error: structure has no member named `ic_wep_mode' > /usr/src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c:1541: error: `IEEE80211_WEP_8021X' undeclared (first use in this function) > /usr/src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c:1541: error: (Each undeclared identifier is reported only once > /usr/src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c:1541: error: for each function it appears in.) > /usr/src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c:1542: error: structure has no member named `ic_wep_mode' > /usr/src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c: In function `ndis_media_status': > /usr/src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c:1708: error: `IEEE80211_MODE_TURBO' undeclared (first use in this function) > *** Error code 1 > > Stop in /usr/src/sys/modules/if_ndis. > > If it matters I am using the following driver > http://ftp.us.dell.com/network/R73206.EXE (w70n51.*) > > I have rev 1.72 of if_ndis.c. > > -- > 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 > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 187 bytes > Desc: not available > Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20041209/b805604b/attachment-0001.bin > > ------------------------------ > > Message: 3 > Date: Thu, 9 Dec 2004 15:40:15 +0300 > From: Gleb Smirnoff <glebius_at_freebsd.org> > Subject: Re: [TEST] ng_bridge ng_l2tp ng_lmi > To: current_at_freebsd.org, stable_at_freebsd.org > Message-ID: <20041209124015.GA97077_at_cell.sick.ru> > Content-Type: text/plain; charset=koi8-r > > The list of untested nodes has been narrowed down > to the following three: > > ng_bridge, ng_l2tp, ng_lmi > > Please, if you use one of these three test this patch: > > http://people.freebsd.org/~glebius/totest/netgraph_callout > > T> On Thu, Dec 02, 2004 at 06:10:48PM +0300, Gleb Smirnoff wrote: > T> T> Dear collegues, > T> T> > T> T> we are working on making netgraph ISR mpsafe. To do it we need to > T> T> fix all (ab)users of bare timeout(9) in src/sys/netgraph. These > T> T> timeout calls are running in synch with netgraph now because timeout(9) > T> T> is Giant-locked. As soon as we mark ISR mpsafe, they are going to break. > T> T> > T> T> This patch semi-mechanically changes all timeout(9) calls to ng_callout(9), > T> T> which runs scheduled callouts in netgraph context: > T> T> > T> T> http://people.freebsd.org/~glebius/totest/netgraph_callout > T> T> > T> T> It can be applied to HEAD or RELENG_5 (not 5.3-RELEASE). It patches > T> T> the following nodes: > T> T> > T> T> ng_bridge.c > T> T> ng_l2tp.c > T> T> ng_lmi.c > T> T> ng_ppp.c > T> T> ng_pppoe.c > T> T> ng_tty.c > T> T> > T> T> If you are using at least one of them, then I'm asking you to test the > T> T> patch and respond. Thanks in advance! > T> T> > T> T> P.S. Sorry for crossposting. The target users are both RELENG_5 and CURRENT. > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE > > ------------------------------ > > Message: 4 > Date: Wed, 8 Dec 2004 12:05:38 -0500 > From: Mikhail Teterin <mi+mx_at_aldan.algebra.com> > Subject: new TCL vs. current-6 > To: freebsd-current_at_FreeBSD.org, freebsd-amd64_at_FreeBSD.org > Cc: ade_at_FreeBSD.org > Message-ID: <200412081205.39354.mi+mx_at_aldan.algebra.com> > Content-Type: text/plain; charset="koi8-u" > > Three of my TCL-based ports fail now on amd64 running current-6. All failures > occur, when an attempt is made to use the TCL-interpreter -- either to run > the port's self-tests, or to generate the manual pages. The failures are > either "Floating point exceptions" or "Segmentation faults" and appear to > only happen on amd64 (may be, on ia64 as well): > > http://people.freebsd.org/~fenner/errorlogs/mi%40aldan.algebra.com.html > > Can anyone confirm being able to use freshly built TCL on amd64 _at all_? > > My ports did not change in months -- what could be wrong with TCL and/or > amd64? > > Thanks! > > -mi > > ------------------------------ > > Message: 5 > Date: Wed, 8 Dec 2004 18:20:22 +0200 > From: "Atte Peltomaki" <koston_at_iki.fi> > Subject: Re: FreeBSD sound distortion problems with SB Live! fixed > with PREEMPTION > To: current_at_freebsd.org > Message-ID: <20041208162022.GA2968_at_norsu.kameli.org> > Content-Type: text/plain; charset=us-ascii > > > > To my amazement, it worked completely. Enabling PREEMPTION in the kernel > > > completely "fixes" this problem to the fullest extent. I have not been > > > able to reproduce the problem since using any of the methods described > > > above. > > > > > > I'm hoping that with this new information someone might be able to > > > figure out what is truly causing this problem and can come up with a > > > solution (or is PREEMPTION a good solution?). It seems that only a > > > handful of drivers (emu10k1 is the one I'm having problems with) have > > > this problem. For the record, I am not the only one who has reported > > > this problem to the lists. > > > > I also experience the same problems with sound you've described. > > > > As PREEMPTION seems to stable for you, I tried to turn it on again. > > > > Unfortunately PREEMPTION remains to be completely unusable for me. The > > system freezes within 5 minutes. > > > > The problem is described here: > > http://lists.freebsd.org/pipermail/freebsd-current/2004-September/037949.html > > > > I wonder if no one else gets this kind of problem. > > Last I was running -current, PREEMPTION was just brought back, but it > remained completely unusable for me too. Complete system freeze with no > panic, in matter of minutes. > > -Atte > > ------------------------------ > > Message: 6 > Date: Wed, 8 Dec 2004 09:38:29 -0800 > From: cjohnson_at_wcug.wwu.edu > Subject: Microsoft Wireless Intellimouse Explorer > To: freebsd-current_at_freebsd.org > Message-ID: <20041208173829.GA7645_at_wcug.wwu.edu> > Content-Type: text/plain; charset=us-ascii > > I'd like to help get my Microsoft Wireless Intellimouse Explorer > working under 5.3-RELEASE. I've installed 5.3-RELEASE (x86) and > updated to about 3 AM PST with the GENERIC kernel, and the mouse > is recognized as ums0: > > ums0: Microsoft Microsoft Wireless Intellimouse Explorer\M-. 1.0A, rev 1.10/0.0e, addr 2, iclass 3/1 > ums0: 5 buttons and Z dir. > > So the driver sees it, but I can't get much output from the mouse. > moused starts and sees the device, but I'm unable to move the cursor > in X or on the console. If I kill off moused and point X at > /dev/ums0, X can't open the device and I get the message: > > usbd_setup_pipe: failed to start endpoint, TIMEOUT > > I've also tried ' moused -p /dev/ums0 -i all ' after killing off > moused and I get: > > moused: unable to open /dev/ums0: Input/output error > > I've got about two weeks to poke and prod and I'd like to work > with someone to get this mouse working. I'd rather not have to have a > separate mouse for FreeBSD than for Windows XP. (And as an odd side > note: it works in Solaris 10 (x86), though Solaris won't install > properly on this machine.) > > Any help would be appreciated. I can provide remote access if needed. > > -- > Chris Johnson > cjohnson_at_wcug.wwu.edu > Tua toga suspina est. > > ------------------------------ > > Message: 7 > Date: Wed, 8 Dec 2004 18:09:16 -0600 (CST) > From: trorki_at_area51.capnet.state.tx.us > Subject: Re: new TCL vs. current-6 > To: Mikhail Teterin <mi+mx_at_aldan.algebra.com> > Cc: freebsd-current_at_freebsd.org > Message-ID: <20041208180601.T29045_at_area51.capnet.state.tx.us> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Wed, 8 Dec 2004, Mikhail Teterin wrote: > > > Three of my TCL-based ports fail now on amd64 running current-6. All failures > > occur, when an attempt is made to use the TCL-interpreter -- either to run > > the port's self-tests, or to generate the manual pages. The failures are > > either "Floating point exceptions" or "Segmentation faults" and appear to > > only happen on amd64 (may be, on ia64 as well): > > > http://people.freebsd.org/~fenner/errorlogs/mi%40aldan.algebra.com.html > > > Can anyone confirm being able to use freshly built TCL on amd64 _at all_? > > > My ports did not change in months -- what could be wrong with TCL and/or > > amd64? > > I just build expect a few minutes ago on: > > FreeBSD rc.capnet.state.tx.us 5.3-RELEASE FreeBSD 5.3-RELEASE #1: Wed > Dec 8 11:39:15 CST 2004 stu_at_rc.capnet.state.tx.us:/usr/obj/usr/src/sys/SMP amd64 > > and it seems to work fine, though I haven't pushed it. > > Let me know if you need specific tests. I can do a -current tomorrow, > possibly. > > stu > > ------------------------------ > > Message: 8 > Date: Thu, 09 Dec 2004 22:50:41 +0900 (JST) > From: Hideyuki KURASHINA <rushani_at_bl.mmtr.or.jp> > Subject: Re: WEP does not work? > To: sam_at_errno.com > Cc: freebsd-current_at_freebsd.org > Message-ID: <20041209.225041.63112571.rushani_at_bl.mmtr.or.jp> > Content-Type: Text/Plain; charset=us-ascii > > Hi, > > >>> On Wed, 8 Dec 2004 17:44:27 -0800, Sam Leffler <sam_at_errno.com> said: > > > On Wednesday 08 December 2004 05:00 pm, Hideyuki KURASHINA wrote: > > > After rebooting, I set IPv4 and IPv6 addresses and those routes. Because > > > access point supports only 802.11b, I configured my wireless network > > > by 128bit WEP as follows > > > > > > /sbin/ifconfig ath0 nwid MY-SSID nwkey 0x01234567890123456789012345 media > > > autoselect mode 11b > > > > > > then I got following error: > > > > > > ath0: ath_chan_set: unable to reset channel 8 (2447 Mhz) > > > ath0: ath_chan_set: unable to reset channel 8 (2447 Mhz) > > > ath0: ath_chan_set: unable to reset channel 8 (2447 Mhz) > > > ath0: ath_chan_set: unable to reset channel 12 (2467 Mhz) > > > > Weird, can you send me the regdomain and country code: e.g. the output of > > sysctl dev.ath.0. > > Sure. > > # sysctl dev.ath.0 > dev.ath.0.%desc: Atheros 5212 > dev.ath.0.%driver: ath > dev.ath.0.%location: slot=2 function=0 > dev.ath.0.%pnpinfo: vendor=0x168c device=0x1014 subvendor=0x1014 subdevice=0x057e class=0x020000 > dev.ath.0.%parent: pci2 > dev.ath.0.countrycode: 395 > dev.ath.0.regdomain: 67 > dev.ath.0.debug: 0 > dev.ath.0.slottime: 20 > dev.ath.0.acktimeout: 48 > dev.ath.0.ctstimeout: 48 > dev.ath.0.softled: 1 > dev.ath.0.ledpin: 0 > dev.ath.0.txantenna: 0 > dev.ath.0.rxantenna: 1 > dev.ath.0.txintrperiod: 5 > dev.ath.0.diag: 0 > dev.ath.0.tpscale: 0 > dev.ath.0.rate_interval: 1000 > dev.ath.0.rate_raise: 10 > dev.ath.0.rate_raise_threshold: 10 > > Just curiosity, `hw' MIBs print both regdomain and countrycode are 0. > > # sysctl hw.ath > hw.ath.hal.swba_backoff: 0 > hw.ath.hal.sw_brt: 10 > hw.ath.hal.dma_brt: 2 > hw.ath.hal.version: 0.9.14.9 > hw.ath.debug: 0 > hw.ath.regdomain: 0 > hw.ath.countrycode: 0 > hw.ath.xchanmode: 1 > hw.ath.outdoor: 1 > hw.ath.calibrate: 30 > hw.ath.dwell: 200 > > > > # ifconfig ath0 list chan > > > Channel 1 : 2412* Mhz 11g Channel 11 : 2462* Mhz 11g > > > Channel 2 : 2417* Mhz 11g Channel 12 : 2467* Mhz 11a 11g > > > Channel 3 : 2422* Mhz 11g Channel 13 : 2472* Mhz 11g > > > Channel 4 : 2427* Mhz 11g Channel 14 : 2484* Mhz 11b > > > Channel 5 : 2432* Mhz 11g Channel 16 : 5080* Mhz 11a > > > Channel 6 : 2437* Mhz 11g Channel 34 : 5170* Mhz 11a > > > Channel 7 : 2442* Mhz 11g Channel 38 : 5190* Mhz 11a > > > Channel 8 : 2447* Mhz 11a 11g Channel 42 : 5210* Mhz 11a > > > Channel 9 : 2452* Mhz 11g Channel 46 : 5230* Mhz 11a > > > Channel 10 : 2457* Mhz 11g > > > > > > > So it seems channels 8 and 12 are supposedly available. > > Actually, no. I'll show you my AP side wireless network setting. > > % dmesg | grep wi0 > wi0 at pcmcia0 function 0: PLANEX, GW-NS11H Wireless LAN PC Card, > wi0: 802.11 address 00:90:cc:XX:XX:XX > wi0: using RF:PRISM3 MAC:ISL3871(PCMCIA) > wi0: Intersil Firmware: Primary (1.0.7), Station (1.3.5) > wi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > > % ifconfig wi0 > wi0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > ssid MY-SSID nwkey ***** > powersave off > bssid 00:90:cc:XX:XX:XX chan 3 > address: 00:90:cc:XX:XX:XX > media: IEEE802.11 autoselect mode 11b hostap (DS2 hostap) > status: active > inet 192.168.1.7 netmask 0xffffff00 broadcast 192.168.1.255 > inet alias 192.168.1.254 netmask 0xffffffff broadcast 192.168.1.254 > inet6 fe80::290:XXXX:XXXX:XXXX%wi0 prefixlen 64 scopeid 0x4 > inet6 2001:3e0:XXX:X::X prefixlen 64 > > % sudo wiconfig wi0 > NIC serial number: [ 99SA01XXXXXX ] > Station name: [ ] > SSID for IBSS creation: [ MY-SSID ] > Current netname (SSID): [ MY-SSID ] > Desired netname (SSID): [ MY-SSID ] > Current BSSID: [ 00:90:cc:XX:XX:XX ] > Channel list: [ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 ] > IBSS channel: [ 3 ] > Current channel: [ 3 ] > Comms quality/signal/noise: [ 0 81 27 ] > Promiscuous mode: [ Off ] > Port type: [ 6 ] > MAC address: [ 00:90:cc:XX:XX:XX ] > TX rate (selection): [ 0 ] > TX rate (actual speed): [ 2 ] > Beacon Interval (current) [msec]: [ 100 ] > Maximum data length: [ 2304 ] > RTS/CTS handshake threshold: [ 2347 ] > fragmentation threshold: [ 2346 ] > RSSI -> dBm adjustment: [ 100 ] > Create IBSS: [ Off ] > Microwave oven robustness: [ 0 ] > Roaming mode(1:firm,3:disable): [ 1 ] > Access point density: [ 1 ] > Power Mgmt (1=on, 0=off): [ 0 ] > Max sleep time (msec): [ 100 ] > Vendor info: [ Unknown ID: 31 version: 1.3 ] > WEP encryption: [ On ] > Authentication type > (1=OpenSys, 2=Shared Key): [ 1 ] > TX encryption key: [ 1 ] > Encryption keys: [ 0x01234567890123456789012345 ][ ][ ][ ] > > > > It seems that ath0 failed to reset channel. I manually specified channel, > > > then ifconfig shows: > > > > > > # ifconfig -v ath0 > > > ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > > > inet 192.168.1.11 netmask 0xffffff00 broadcast 192.168.1.255 > > > inet6 fe80::20e:XXXX:XXXX:XXXX%ath0 prefixlen 64 scopeid 0x2 > > > inet6 2001:3e0:XX:X::XX prefixlen 64 > > > ether 00:0e:9b:XX:XX:XX > > > media: IEEE 802.11 Wireless Ethernet autoselect mode 11b (DS/11Mbps) > > > status: associated > > > ssid MY-SSID channel 3 (2422) bssid 00:90:cc:XX:XX:XX > > > authmode OPEN privacy ON deftxkey 1 powersavemode OFF > > > powersavesleep 100 txpowmax 14 txpower 60 rtsthreshold 2312 protmode CTS > > > wme roaming AUTO bintval 100 > > > AC_BE cwmin 5 cwmax 10 aifs 3 txopLimit 0 -acm ack > > > cwmin 5 cwmax 10 aifs 3 txopLimit 0 -acm > > > AC_BK cwmin 5 cwmax 10 aifs 7 txopLimit 0 -acm ack > > > cwmin 5 cwmax 10 aifs 7 txopLimit 0 -acm > > > AC_VI cwmin 4 cwmax 5 aifs 2 txopLimit 188 -acm ack > > > cwmin 4 cwmax 5 aifs 2 txopLimit 188 -acm > > > AC_VO cwmin 3 cwmax 4 aifs 2 txopLimit 102 -acm ack > > > cwmin 3 cwmax 4 aifs 2 txopLimit 102 -acm > > > > This doesn't show a key installed. I don't typically use nwkey; I'll have to > > check it. > > I tried > > # /sbin/ifconfig ath0 ssid MY-SSID wepmode on weptxkey 1 wepkey 1:0x01234567890123456789012345 wepkey 2:- wepkey 3:- wepkey 4:- media autoselect mode 11b > > but nothing changed (default router is still not reachable). > > The card in question is labeled ``Atheros AR5BMB-44''. > > http://www.rushani.jp/photo/20041209/12090019.jpg > > -- rushani > > ------------------------------ > > Message: 9 > Date: Thu, 09 Dec 2004 22:59:25 +0900 (JST) > From: Hideyuki KURASHINA <rushani_at_bl.mmtr.or.jp> > Subject: Re: WEP does not work? > To: Danovitsch_at_vitsch.net > Cc: FreeBSD-current_at_FreeBSD.org > Message-ID: <20041209.225925.30166884.rushani_at_bl.mmtr.or.jp> > Content-Type: Text/Plain; charset=us-ascii > > Hi, > > >>> On Thu, 9 Dec 2004 12:41:02 +0100, "Daan Vreeken [PA4DAN]" <Danovitsch_at_vitsch.net> said: > > > Have you tried : > > ifconfig ath0 wepmode on > > after setting the wep key? > > I challenged following command lines, > > # /sbin/ifconfig ath0 ssid MY-SSID weptxkey 1 wepkey 1:0x01234567890123456789012345 wepkey 2:- wepkey 3:- wepkey 4:- media autoselect mode 11b > # /sbin/ifconfig ath0 wepmode on > > However, the behavior was not changed. > > -- rushani > > ------------------------------ > > Message: 10 > Date: Thu, 9 Dec 2004 14:23:07 +0000 (GMT) > From: Gavin Atkinson <gavin.atkinson_at_ury.york.ac.uk> > Subject: Re: Microsoft Wireless Intellimouse Explorer > To: cjohnson_at_wcug.wwu.edu > Cc: freebsd-current_at_freebsd.org > Message-ID: <20041209141745.H26445_at_ury.york.ac.uk> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Wed, 8 Dec 2004 cjohnson_at_wcug.wwu.edu wrote: > > > I'd like to help get my Microsoft Wireless Intellimouse Explorer > > working under 5.3-RELEASE. I've installed 5.3-RELEASE (x86) and > > updated to about 3 AM PST with the GENERIC kernel, and the mouse > > is recognized as ums0: > > > > ums0: Microsoft Microsoft Wireless Intellimouse Explorer\M-. 1.0A, rev 1.10/0.0e, addr 2, iclass 3/1 > > ums0: 5 buttons and Z dir. > > > > So the driver sees it, but I can't get much output from the mouse. > > moused starts and sees the device, but I'm unable to move the cursor > > in X or on the console. If I kill off moused and point X at > > /dev/ums0, X can't open the device and I get the message: > > > > usbd_setup_pipe: failed to start endpoint, TIMEOUT > > > > I've also tried ' moused -p /dev/ums0 -i all ' after killing off > > moused and I get: > > > > moused: unable to open /dev/ums0: Input/output error > > Try the patch at http://www.devrandom.co.uk/freebsd/intellimouse.diff - > and let me know if it works for you. However, from your description, I > suspect it's a different problem so you may not have any success. > > > Any help would be appreciated. I can provide remote access if needed > > If that patch doesn't work, I may take you up on this offer. It would be > nice to get them working. > > Gavin > > ------------------------------ > > Message: 11 > Date: Thu, 09 Dec 2004 07:41:01 -0700 > From: Scott Long <scottl_at_freebsd.org> > Subject: Wanted: lots of 6-CURRENT testing > To: current_at_freebsd.org > Message-ID: <41B863FD.7000007_at_freebsd.org> > Content-Type: text/plain; charset=us-ascii; format=flowed > > All, > > There has been an incredible amount of work going into 6-CURRENT in the > last 5 weeks. With the holidays quickly approaching, now seems like a > good time to step back and start really testing the system to shake out > the bugs and catch the developers before they disappear for the > holidays. In particular, the recent massive changes to the vnode layer > and the upgrade of the net80211 layer and wireless lan drivers needs a > lot of review and testing. Now is also a good time to review the recent > additions to the PR database and start seeing if there are trends > developing and/or areas that need immediate attention. > > While 6-CURRENT remains in a high state of flux I'll also ask that > people carefully consider what to merge into 5-STABLE and when to merge > it. Don't let important bugfixes that would benefit 5-STABLE and > 4-STABLE drop on the floor, but also make sure that they recieve > thorough testing before being merged back. > > Thanks, > > Scott > > ------------------------------ > > Message: 12 > Date: Thu, 9 Dec 2004 15:42:33 +0100 > From: Peter Holm <peter_at_holm.cc> > Subject: panic: uma_zone_slab is looping > To: current_at_freebsd.org > Message-ID: <20041209144233.GA46928_at_peter.osted.lan> > Content-Type: text/plain; charset=us-ascii > > I modified: > > $ cvs diff -u uma_core.c > Index: uma_core.c > =================================================================== > RCS file: /home/ncvs/src/sys/vm/uma_core.c,v > retrieving revision 1.110 > diff -u -r1.110 uma_core.c > --- uma_core.c 6 Nov 2004 11:43:30 -0000 1.110 > +++ uma_core.c 9 Dec 2004 14:38:32 -0000 > _at__at_ -1926,6 +1926,7 _at__at_ > { > uma_slab_t slab; > uma_keg_t keg; > + int i; > > keg = zone->uz_keg; > > _at__at_ -1943,7 +1944,8 _at__at_ > > slab = NULL; > > - for (;;) { > + for (i = 0;;i++) { > + KASSERT(i < 10000, ("uma_zone_slab is looping")); > /* > * Find a slab with some space. Prefer slabs that are partially > * used over those that are totally full. This helps to reduce > > and caught this one: > http://www.holm.cc/stress/log/cons94.html > -- > Peter Holm > > ------------------------------ > > Message: 13 > Date: Thu, 9 Dec 2004 08:23:05 -0800 > From: Steve Kargl <sgk_at_troutmask.apl.washington.edu> > Subject: Re: make(1) is broken > To: Harti Brandt <harti_at_freebsd.org> > Cc: freebsd-current_at_freebsd.org > Message-ID: <20041209162305.GB53640_at_troutmask.apl.washington.edu> > Content-Type: text/plain; charset=us-ascii > > On Thu, Dec 09, 2004 at 11:10:59AM +0100, Harti Brandt wrote: > > On Wed, 8 Dec 2004, Steve Kargl wrote: > > > > SK> > > SK>Stop in /usr/src. > > SK>troutmask:root[203] tail -1 /var/log/messages > > SK>Dec 8 15:58:39 troutmask kernel: pid 4794 (make), uid 0: exited on signal 11 > > SK> > > > > Thanks for the report. This has been caused by make during clean-up to > > remove a path element that was never opened as a directory from the list > > of open directories. Fixed in rev. 1.43 of dir.c. > > Thanks for the fix. > > -- > Steve > > ------------------------------ > > Message: 14 > Date: Thu, 09 Dec 2004 16:48:36 +0000 > From: Gavin Atkinson <gavin.atkinson_at_ury.york.ac.uk> > Subject: Re: Microsoft Wireless Intellimouse Explorer > To: cjohnson_at_wcug.wwu.edu > Cc: freebsd-current_at_freebsd.org > Message-ID: <1102610916.4474.5.camel_at_buffy.york.ac.uk> > Content-Type: text/plain > > On Thu, 2004-12-09 at 14:23 +0000, Gavin Atkinson wrote: > > On Wed, 8 Dec 2004 cjohnson_at_wcug.wwu.edu wrote: > > > > > I'd like to help get my Microsoft Wireless Intellimouse Explorer > > > working under 5.3-RELEASE. I've installed 5.3-RELEASE (x86) and > > > updated to about 3 AM PST with the GENERIC kernel, and the mouse > > > is recognized as ums0: > > > > > > ums0: Microsoft Microsoft Wireless Intellimouse Explorer\M-. 1.0A, rev 1.10/0.0e, addr 2, iclass 3/1 > > > ums0: 5 buttons and Z dir. > > > > > > So the driver sees it, but I can't get much output from the mouse. > > > moused starts and sees the device, but I'm unable to move the cursor > > > in X or on the console. > > > > Try the patch at http://www.devrandom.co.uk/freebsd/intellimouse.diff - > > and let me know if it works for you. However, from your description, I > > suspect it's a different problem so you may not have any success. > > Sorry, I should probably just say that it is an updated version of the > patch in PR 70607 and is not all my own work :) > > Gavin > > ------------------------------ > > Message: 15 > Date: Thu, 9 Dec 2004 20:13:55 +0300 > From: Andrey Chernov <ache_at_nagual.pp.ru> > Subject: Lots of ACPI warnings with recent -current > To: current_at_freebsd.org > Message-ID: <20041209171355.GA7967_at_nagual.pp.ru> > Content-Type: text/plain; charset=us-ascii > > acpi0: <ASUS TUSL2-C> on motherboard > ACPI-0252: *** Error: No object was returned from > [\\_SB_.PCI0.PX40.UAR2._STA] (Node 0xc1186240), AE_NOT_EXIST > > It is repeated later about 40 times. > > -- > http://ache.pp.ru/ > > ------------------------------ > > Message: 16 > Date: Thu, 9 Dec 2004 18:29:41 +0100 > From: Krzysztof Kowalik <kkowalik_at_uci.agh.edu.pl> > Subject: Re: FreeBSD sound distortion problems with SB Live! fixed > with PREEMPTION > To: current_at_freebsd.org > Message-ID: <20041209172941.GA29369_at_uci.agh.edu.pl> > Content-Type: text/plain; charset=us-ascii > > Ivan Voras [ivoras_at_fer.hr] wrote: > > [...] > > Not exactly a freeze, but PREEMPTION doesn't help me at all with SB Live > > (slowdowns, stuttering sound, etc.), especially with large amounts of > > filesystem operations (this is 5-stable). > > Exactly. I tried to use both emu10k1 and emu10kx drivers, with kernel > with and without PREEMPTION, and both 5.x and 6.0 serie did behave same. > Intensive I/O made the system quite unusable, and it was not only a > sound-related issue, but a general one -- slow, lagging mouse in X, etc. > > I asked about it on stable_at_ and somehow got no answers but "me too". > > Finally, I decided to restore my 4.9 system from the backups, where the > problem does not exist. > > Regards, > -- > Krzysztof Kowalik | () ASCII Ribbon Campaign > Computer Center, AGH UST | /\ Support plain text e-mail > > ------------------------------ > > Message: 17 > Date: Thu, 9 Dec 2004 12:45:28 -0500 (EST) > From: "Andrew R. Reiter" <arr_at_watson.org> > Subject: panic not going to debugger? > To: current_at_Freebsd.org > Message-ID: <20041209124257.X57958_at_fledge.watson.org> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > Anyone else experiencing issues when a panic, something simple like a > recursion on a non-recursable lock, occurs, it won't break to DDB? I've > got all the right bits for it (KERNCONF options etc) but seems to have > stopped working since I updated to CURRENT yesterday... after battling > through trying to figure out the do_powerstate=0 issue I was having. > > I have a easily reproducible panic but can't dump or anything b/c of this > problem. So, instead, I'll have to send an email with old information > (line #'s etc)... > > Did I miss something? :-) > > Cheers, > Andrew > > -- > Andrew R. Reiter > arr_at_watson.org > arr_at_FreeBSD.org > > ------------------------------ > > Message: 18 > Date: Thu, 9 Dec 2004 12:53:31 -0500 (EST) > From: "Andrew R. Reiter" <arr_at_watson.org> > Subject: rtentry recursion panic (fwd) > To: current_at_freebsd.org > Message-ID: <20041209124839.V57958_at_fledge.watson.org> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > Sending since I know Sam and Bruce are busy; I am busy.. not as busy.. but > busy enough to not have time to track code paths down further than I did > in the below email. > > NOTE: The line # in the panicstr is WRONG! this message was after me > doing some minor printf() additions to see what was going on a bit further > after I was unable to get a good vmcore. > > NOTE: The way I explained the way to reproduce it is a bit more difficult > than it can be done. Ie.. just do: > > ifconfig <device> 10.9.9.100 netmask 255.255.0.0 up > route add default 10.9.0.1 > route delete default > route delete 10.9/16 > route add default 10.9.0.1 > traceroute 10.9.0.1 > panic... > > I explain a bit further in the below email where the actual problem is.. I > just am not sure the exact means it got to that point. I've verified this > exists on CURRENT of yesterday. So it's still lingering.. > > ---------- Forwarded message ---------- > Date: Wed, 1 Dec 2004 03:24:36 -0500 (EST) > From: Andrew R. Reiter <arr_at_watson.org> > To: sam_at_freebsd.org, bms_at_freebsd.org > Subject: rtentry recursion panic > > Sam & Bruce, > > I am admittedly running a slightly out of date CURRENT, but am hoping to > see whether or not you all have seen this (or related) panic. > > The panic string is [ignore line #, added debug goo for own use]: > > _mtx_lock_sleep: recursed on non-recursive mutex rtentry _at_ > /usr/au_src/sys/net/route.c:1311 > > And the [long] backtrace is: > > #0 doadump () at pcpu.h:159 > #1 0xc0466dee in db_fncall (dummy1=-1065588687, dummy2=0, > dummy3=-563291948, > dummy4=0xde6cd86c "l") at /usr/au_src/sys/ddb/db_command.c:531 > #2 0xc0467184 in db_command_loop () at > /usr/au_src/sys/ddb/db_command.c:349 > #3 0xc0468b8c in db_trap (type=3, code=0) at > /usr/au_src/sys/ddb/db_main.c:221 > #4 0xc064e32e in kdb_trap (type=3, code=0, tf=0xde6cd994) > at /usr/au_src/sys/kern/subr_kdb.c:421 > #5 0xc07d977c in trap (frame= > {tf_fs = -563347432, tf_es = -1067122672, tf_ds = -1065091056, > tf_edi = 0, tf_esi = 1, tf_ebp = -563291692, tf_isp = -563291712, tf_ebx = > -563291648, tf_edx = -1065058018, tf_ecx = -1064210208, tf_eax = > -1065049367, tf_trapno = 3, tf_err = 0, tf_eip = -1067131032, tf_cs = 8, > tf_eflags = 642, tf_esp = -563291660, tf_ss = -1067222809}) at > /usr/au_src/sys/i386/i386/trap.c:577 > #6 0xc07c82aa in calltrap () at /usr/au_src/sys/i386/i386/exception.s:140 > #7 0xde6c0018 in ?? () > #8 0xc0650010 in kvprintf (fmt=0x1 <Address 0x1 out of bounds>, > func=0x100, > arg=0xc1f1aaf0, radix=-1042196716, ap=0xc1e15714 "D+\213\v\204\v\204") > at /usr/au_src/sys/kern/subr_prf.c:543 > #9 0xc06378e7 in panic (fmt=0x282 <Address 0x282 out of bounds>) > at /usr/au_src/sys/kern/kern_shutdown.c:525 > #10 0xc06301b1 in _mtx_lock_sleep (m=0xc1e15714, td=0xc1f1aaf0, opts=0, > file=0xc0852322 "/usr/au_src/sys/net/route.c", line=1311) > at /usr/au_src/sys/kern/kern_mutex.c:492 > #11 0xc063023c in _mtx_lock_flags (m=0xc1e15714, opts=0, > file=0xc0852322 "/usr/au_src/sys/net/route.c", line=1311) > at /usr/au_src/sys/kern/kern_mutex.c:273 > #12 0xc06a87ed in rt_check (lrt=0x0, lrt0=0xde6cdab4, dst=0xc1fa7a10) > at /usr/au_src/sys/net/route.c:1311 > #13 0xc06b3481 in arpresolve (ifp=0xc1cea000, rt0=0xc1e156b4, > m=0xc1e0f300, > dst=0xc1fa7a10, desten=0xde6cdad0 "") > at /usr/au_src/sys/netinet/if_ether.c:351 > #14 0xc069c392 in ether_output (ifp=0xc1cea000, m=0xc1e0f300, > dst=0xc1fa7a10, > rt0=0x0) at /usr/au_src/sys/net/if_ethersubr.c:160 > #15 0xc06bd94f in ip_output (m=0xc1e0f300, opt=0xc1cea000, ro=0xde6cdb40, > flags=34, imo=0x0, inp=0xc1faeec4) > at /usr/au_src/sys/netinet/ip_output.c:771 > #16 0xc06bdf81 in rip_output (m=0xc1e0f300, so=0x0, dst=0) > at /usr/au_src/sys/netinet/raw_ip.c:320 > #17 0xc06bea8f in rip_send (so=0xc1d78798, flags=0, m=0xc1e0f300, > nam=0xc1ba51a0, control=0x0, td=0xc1f1aaf0) > at /usr/au_src/sys/netinet/raw_ip.c:784 > #18 0xc066db10 in sosend (so=0xc1d78798, addr=0xc1ba51a0, uio=0xde6cdc54, > top=0xc1e0f300, control=0x0, flags=0, td=0xc1f1aaf0) > at /usr/au_src/sys/kern/uipc_socket.c:816 > #19 0xc06739ea in kern_sendit (td=0xc1f1aaf0, s=7, mp=0xde6cdccc, flags=0, > control=0x0) at /usr/au_src/sys/kern/uipc_syscalls.c:784 > #20 0xc067488c in sendit (td=0xc1f1aaf0, s=7, mp=0xde6cdccc, flags=0) > at /usr/au_src/sys/kern/uipc_syscalls.c:725 > #21 0xc0674b7d in sendto (td=0x0, uap=0x0) > at /usr/au_src/sys/kern/uipc_syscalls.c:841 > #22 0xc07d9bc9 in syscall (frame= > {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 0, tf_ebp > = -1077941288, tf_isp = -563290764, tf_ebx = 672388112, tf_edx = > 134553600, tf_ecx = 1, tf_eax = 133, tf_trapno = 12, tf_err = 2, tf_eip = > 671908087, tf_cs = 31, tf_eflags = 662, tf_esp = -1077941348, tf_ss = 47}) > at /usr/au_src/sys/i386/i386/trap.c:1003 > #23 0xc07c82ff in Xint0x80_syscall () > at /usr/au_src/sys/i386/i386/exception.s:201 > #24 0x0000002f in ?? () > #25 0x0000002f in ?? () > #26 0x0000002f in ?? () > #27 0x00000000 in ?? () > #28 0x00000000 in ?? () > #29 0xbfbfebd8 in ?? () > #30 0xde6cdd74 in ?? () > #31 0x2813d410 in ?? () > #32 0x08052000 in ?? () > #33 0x00000001 in ?? () > #34 0x00000085 in ?? () > #35 0x0000000c in ?? () > #36 0x00000002 in ?? () > #37 0x280c80f7 in ?? () > #38 0x0000001f in ?? () > #39 0x00000296 in ?? () > #40 0xbfbfeb9c in ?? () > #41 0x0000002f in ?? () > #42 0x00000000 in ?? () > #43 0x00000000 in ?? () > #44 0x00000000 in ?? () > #45 0x00000000 in ?? () > #46 0x1f343000 in ?? () > #47 0x00000000 in ?? () > #48 0xc1f1aaf0 in ?? () > #49 0xde6cda28 in ?? () > #50 0xde6cda10 in ?? () > #51 0xc19da640 in ?? () > #52 0xc0647643 in sched_switch (td=0x0, newtd=0x2813d410, flags=Cannot > access memory at address 0xbfbfebe8 > ) > at /usr/au_src/sys/kern/sched_4bsd.c:865 > (kgdb) > > The recursion takes place in rt_check() after rtalloc1()'ing for a > rt_gwroute since rt0's (*lrt0) rt_gwroute is NULL. The value rtentry > object allocated is pointing at the same address as rt0... and when we > return from rtalloc1() the rtentry object is locked.... so the following > occurs in rt_check() (indent python-esque format): > > rt_check(..., struct rtentry **lrt0, ...) > rt = rt0 = *lrt0 > if (rt) > RT_LOCK(rt) > ...checks to see if RTF_GATEWAY; jumps down since rt_gwroute==0 > RT_UNLOCK(rt0) // remember, rt == rt0, even now due to beginning code > // alloc new gateway rtentry > rt = rtalloc1(rt->rt_gateway, 1, 0); // is rt_gateway safe?? > RT_LOCK(rt0); // BAM! panic.. rt (after rtalloc1()) points to > same addr as rt0... hows that happening?) > > The locked is grabbed in rtalloc1() as well as a refcnt is added (not > marked RTF_CLONING at alloc time). > > I've narrowed down how to reproduce in a reasonable fashion... perhaps > could be narrowed down further, but am starting to get sleepy tonight.. > can help tomorrow. This UP laptop has a bge ethernet nic and a wi > wireless nic. Upon boot, my startup scripts are configured to ifconfig > bge to a 10.x.x.x ipaddress and set the default route (nothing exciting). > The wi device is left untouched. So, to cause the panic... > > # ifconfig wi0 192.168.0.3 netmask 255.255.255.0 ssid BLAH stationname j > # route delete default // Whacks 10.x.x.x default route > # route delete 10.5/16 > # route delete 192.168.0.1 // Shouldnt be there unless pingd or other > # route delete -net 192.168.0 > # route add default 192.168.0.1 > # traceroute 192.168.0.1 > > The traceroute command calls sendto().... and so on (as seen above). > > As you can tell, I've not gone through the code paths in the above steps > to try and determine the root of the problem; my apologies. I plan on > picking this up tomorrow when I have time at work and going from there. > Please let me know if you have any thoughts or can help and would like > more information. > > Cheers, > Andrew > > -- > Andrew R. Reiter > arr_at_watson.org > arr_at_FreeBSD.org > > ------------------------------ > > Message: 19 > Date: Thu, 9 Dec 2004 10:10:34 -0800 > From: Mike Hunter <mhunter_at_ack.Berkeley.EDU> > Subject: Re: coredump while trying to build world > (2004.12.08.1600-0800 src) > To: Steve Kargl <sgk_at_troutmask.apl.washington.edu> > Cc: freebsd-current_at_freebsd.org > Message-ID: <20041209181034.GA16160_at_ack.Berkeley.EDU> > Content-Type: text/plain; charset=us-ascii > > On Dec 08, "Steve Kargl" wrote: > > > On Wed, Dec 08, 2004 at 04:24:30PM -0800, Mike Hunter wrote: > > > Hi, > > > > > > I'm trying to go from RELENG_5 to HEAD on my new amd64, but I'm bombing > > > out here: > > > > > > cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -DMAGIC='"/usr/share/misc/magic"' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -c /usr/src/lib/libmagic/../../contrib/file/softmagic.c -o softmagic.So > > > building shared library libmagic.so.1 > > > Segmentation fault (core dumped) > > > *** Error code 139 > > > > > > > You need to back out the recent changes to make(1). > > In your supfile file that you use with cvsup, set > > > > *default date=2004.11.08.00.00.00 > > src-usrbin > > > > cd /usr/src/usr.bin/make > > make > > make install > > > > PS: surprising the broken make(1) actually works for building > > a new make(1). > > Ugh. I tried cvsupping as you suggested, but it gave the same error. This > morning I cvsup'd again after make was fixed (thanks!), and it *still* gives > the same error. I don't think my installed /usr/bin/make is being updated. > > I forgot to md5 the original make, but this is from this morning's fixed-make > sources: > > bash-2.05b# cd /usr/src/usr.sbin/make > bash-2.05b# make > ... > job.o(.text+0x2973): In function `Job_Init': > : warning: warning: mktemp() possibly used unsafely; consider using mkstemp() > gzip -cn /usr/src/usr.bin/make/make.1 > make.1.gz > bash-2.05b# md5 `which make` > MD5 (/usr/bin/make) = fbb5679f9fde6036770a13ea5d6f9373 > bash-2.05b# find /usr/obj -type f -name make | xargs -L 1 md5 > MD5 (/usr/obj/usr/src/make.amd64/usr/src/usr.bin/make/make) = 5d3d91bf4ca06d1dae5a5d0874589b2c > MD5 (/usr/obj/usr/src/make.amd64/make) = 5d3d91bf4ca06d1dae5a5d0874589b2c > MD5 (/usr/obj/usr/src/usr.bin/make/make) = 0e719846f3f245fa7aa7d3aa2dca0bfd > bash-2.05b# make install > install -s -o root -g wheel -m 555 make /usr/bin > install -o root -g wheel -m 444 make.1.gz /usr/share/man/man1 > bash-2.05b# md5 `which make` > MD5 (/usr/bin/make) = fbb5679f9fde6036770a13ea5d6f9373 > > Why doesn't /usr/bin/make change? Let me guess, there's a bug in make? :| > > I am trying again after copying /usr/obj/usr/src/usr.bin/make/make over > /usr/bin/make by hand. Am I missing something here? Also, what's the > make.amd64 directory about, and why are those make binaries also different? > > Befuddled in Berkeley > > ------------------------------ > > Message: 20 > Date: Thu, 09 Dec 2004 10:25:49 -0800 > From: gnn_at_freebsd.org > Subject: Re: rtentry recursion panic (fwd) > To: "Andrew R. Reiter" <arr_at_watson.org> > Cc: current_at_freebsd.org > Message-ID: <m2pt1jtjki.wl_at_minion.local.neville-neil.com> > Content-Type: text/plain; charset=US-ASCII > > At Thu, 9 Dec 2004 12:53:31 -0500 (EST), > Andrew R. Reiter wrote: > > > > Sending since I know Sam and Bruce are busy; I am busy.. not as busy.. but > > busy enough to not have time to track code paths down further than I did > > in the below email. > > I'll take a quick look and see if I see anything obvious. > > Later, > George > > ------------------------------ > > Message: 21 > Date: Thu, 9 Dec 2004 10:28:16 -0800 > From: Steve Kargl <sgk_at_troutmask.apl.washington.edu> > Subject: Re: coredump while trying to build world > (2004.12.08.1600-0800 src) > To: Mike Hunter <mhunter_at_ack.Berkeley.EDU> > Cc: freebsd-current_at_freebsd.org > Message-ID: <20041209182816.GA27303_at_troutmask.apl.washington.edu> > Content-Type: text/plain; charset=us-ascii > > On Thu, Dec 09, 2004 at 10:10:34AM -0800, Mike Hunter wrote: > > (snip) > > > > > Ugh. I tried cvsupping as you suggested, but it gave the same error. This > > morning I cvsup'd again after make was fixed (thanks!), and it *still* gives > > the same error. I don't think my installed /usr/bin/make is being updated. > > > > I forgot to md5 the original make, but this is from this morning's fixed-make > > sources: > > > > bash-2.05b# cd /usr/src/usr.sbin/make > > bash-2.05b# make > > ... > > job.o(.text+0x2973): In function `Job_Init': > > : warning: warning: mktemp() possibly used unsafely; consider using mkstemp() > > gzip -cn /usr/src/usr.bin/make/make.1 > make.1.gz > > bash-2.05b# md5 `which make` > > MD5 (/usr/bin/make) = fbb5679f9fde6036770a13ea5d6f9373 > > bash-2.05b# find /usr/obj -type f -name make | xargs -L 1 md5 > > MD5 (/usr/obj/usr/src/make.amd64/usr/src/usr.bin/make/make) = 5d3d91bf4ca06d1dae5a5d0874589b2c > > MD5 (/usr/obj/usr/src/make.amd64/make) = 5d3d91bf4ca06d1dae5a5d0874589b2c > > MD5 (/usr/obj/usr/src/usr.bin/make/make) = 0e719846f3f245fa7aa7d3aa2dca0bfd > > bash-2.05b# make install > > install -s -o root -g wheel -m 555 make /usr/bin > > install -o root -g wheel -m 444 make.1.gz /usr/share/man/man1 > > bash-2.05b# md5 `which make` > > MD5 (/usr/bin/make) = fbb5679f9fde6036770a13ea5d6f9373 > > > > Why doesn't /usr/bin/make change? Let me guess, there's a bug in make? :| > > > > I am trying again after copying /usr/obj/usr/src/usr.bin/make/make over > > /usr/bin/make by hand. Am I missing something here? Also, what's the > > make.amd64 directory about, and why are those make binaries also different? > > > > I'm not sure what is causing your problem, I will note that I do not > have a make.amd64 directory. This suggests to me that your src tree > may be messed up. I'm running -current while you appear to be using > RELENG_5 perhaps you need to install from make.amd64 instead of from > make. > > One other thing to do. Clean out your trees. > rm -rf /usr/obj > cd /usr/src > make cleandir && make cleandir (the 2nd cleandir my be unnecessary) > make buildworld > yada yada > > -- > Steve > > ------------------------------ > > Message: 22 > Date: Thu, 9 Dec 2004 12:04:35 -0800 > From: Steve Kargl <sgk_at_troutmask.apl.washington.edu> > Subject: Re: nfs appears broken > To: freebsd-current_at_freebsd.org > Message-ID: <20041209200435.GA697_at_troutmask.apl.washington.edu> > Content-Type: text/plain; charset=us-ascii > > On Wed, Dec 08, 2004 at 04:43:35PM -0800, Steve Kargl wrote: > > troutmask:root[201] mount /jumbo > > [udp] jumbo:/data: RPCPROG_NFS: RPC: Port mapper failure - RPC: Timed out > > [udp] jumbo:/data: RPCPROG_NFS: RPC: Port mapper failure - RPC: Timed out > > > > troutmask:root[203] grep jumbo /etc/fstab > > jumbo:/data /jumbo nfs rw,noauto 0 0 > > > > > > This is with world+kernel from about 30 minutes on amd64. I was > > able to mount /jumbo with a kernel from monday. > > > > Argh. I thought this may be related to phk's recent vfs work. > It appears the admin of the NFS server tighten his firewall > rules and locked me out. > > -- > Steve > > ------------------------------ > > Message: 23 > Date: Thu, 9 Dec 2004 12:09:01 -0800 > From: Mike Hunter <mhunter_at_ack.Berkeley.EDU> > Subject: Re: coredump while trying to build world > (2004.12.08.1600-0800 src) > To: Steve Kargl <sgk_at_troutmask.apl.washington.edu> > Cc: freebsd-current_at_freebsd.org > Message-ID: <20041209200901.GA25184_at_ack.Berkeley.EDU> > Content-Type: text/plain; charset=us-ascii > > On Dec 09, "Steve Kargl" wrote: > > > I'm not sure what is causing your problem, I will note that I do not > > have a make.amd64 directory. This suggests to me that your src tree > > may be messed up. I'm running -current while you appear to be using > > RELENG_5 perhaps you need to install from make.amd64 instead of from > > make. > > > > One other thing to do. Clean out your trees. > > rm -rf /usr/obj > > cd /usr/src > > make cleandir && make cleandir (the 2nd cleandir my be unnecessary) > > make buildworld > > yada yada > > It looks like rm -rf /usr/obj and make cleandir have gotten me past > buildworld. Thanks Steve. Have no fear that I will pipe up again if there's > more trouble :) > > Mike > > ------------------------------ > > Message: 24 > Date: Thu, 9 Dec 2004 22:33:34 +0200 > From: Ruslan Ermilov <ru_at_FreeBSD.org> > Subject: Re: protocol timer running before protocol is fully > initialized (again) (was re: panic: mtx_lock() of spin mutex ...) > To: Max Laier <max_at_love2party.net> > Cc: gnn_at_FreeBSD.org > Message-ID: <20041209203334.GB74745_at_ip.net.ua> > Content-Type: text/plain; charset="us-ascii" > > Hi Max, > > On Thu, Dec 09, 2004 at 12:34:08PM +0100, Max Laier wrote: > [...] > > in ip_input() - that's not good! Can you send me the trace? I was under the > > impression that net send and esp. reveice is off during this part of the > > initialization. Crashing ip_input() would question that assumption. > > > I don't have a serial attached to this notebook (all my > serial cables are at work), so this is hand-copied from > the screen: > > Timecounters tick every 1.000 msec > panic: mtx_lock() of spin mutex (null) _at_ /usr/src/sys/netinet/ip_input.c:1096 > KDB: enter: panic > [thread pid 27 tid 100001 ] > Stopped at kdb_enter+0x32: leal 0(%esi),%esi > db> where > Tracing pid 27 tid 100001 td 0xc1219180 > kdb_enter(...) at kdb_enter+0x32 > panic(...) at panic+0x14d > _mtx_lock_flags(...) at _mtx_lock_flags+0x114 > ip_slowtimo(...) at ip_slowtimo+0x2f > pfslowtimo(...) at pfslowtimo+0x82 > softclock(...) at softclock+0x12f > ithread_loop(...) at ithread_loop+0x210 > fork_exit(...) at fork_exit+0xa9 > fork_trampoline(...) at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xcdbbbd7c, ebp = 0 --- > > PID 27 is "[CPU 0] swi4: clock sio > > Cheers, > -- > Ruslan Ermilov > ru_at_FreeBSD.org > FreeBSD committer > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 187 bytes > Desc: not available > Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20041209/47050619/attachment-0001.bin > > ------------------------------ > > Message: 25 > Date: Thu, 9 Dec 2004 22:13:58 +0100 (MET) > From: Pawel Worach <pawel.worach_at_telia.com> > Subject: Re: page fault panic in > device_get_softc/acpi_pcib_route_interrupt > To: freebsd-current_at_freebsd.org > Message-ID: <20587818.1102626838092.JavaMail.tomcat_at_pne-ps4-sn1> > Content-Type: text/plain;charset="ISO-8859-1" > > Finally got around to fetch some more info about this. > > boot output and kgdb symbol decodes. > > FreeBSD 6.0-CURRENT #0: Wed Dec 8 17:58:20 CET 2004 > root_at_zero:/usr/obj/usr/src/sys/ZERO > Preloaded elf kernel "/boot/kernel/kernel" at 0xc07ee000. > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc07ee16c. > Calibrating clock(s) ... i8254 clock: 1193157 Hz > CLK_USE_I8254_CALIBRATION not specified - using default frequency > Timecounter "i8254" frequency 1193182 Hz quality 0 > Calibrating TSC clock ... TSC clock: 2793900608 Hz > CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.90-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 > Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR, > PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HT > T,TM,PBE> > real memory = 1073590272 (1023 MB) > Physical memory chunk(s): > 0x0000000000001000 - 0x000000000009cfff, 638976 bytes (156 pages) > 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) > 0x0000000000828000 - 0x000000003edaafff, 1045966848 bytes (255363 pages) > avail memory = 1046142976 (997 MB) > MP Configuration Table version 1.4 found at 0xc009e2a0 > Table 'FACP' at 0x3ffdff00 > Table 'APIC' at 0x3ffdfe80 > MADT: Found table at 0x3ffdfe80 > APIC: Using the MADT enumerator. > MADT: Found CPU APIC ID 0 ACPI ID 0: enabled > SMP: Added CPU 0 (AP) > MADT: Found CPU APIC ID 6 ACPI ID 1: enabled > SMP: Added CPU 6 (AP) > ACPI APIC Table: <IBM SERONYXP> > APIC ID: physical 0, logical 0:0 > APIC ID: physical 6, logical 0:1 > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 6 > bios32: Found BIOS32 Service Directory header at 0xc00fd790 > bios32: Entry = 0xfd7a1 (c00fd7a1) Rev = 0 Len = 1 > pcibios: PCI BIOS entry at 0xf0000+0xd7dc > pnpbios: Found PnP BIOS data at 0xc00fdf90 > pnpbios: Entry = f0000:444c Rev = 1.0 > Other BIOS signatures found: > APIC: CPU 0 has ACPI ID 0 > APIC: CPU 1 has ACPI ID 1 > MADT: Found IO APIC ID 14, Interrupt 0 at 0xfec00000 > ioapic0: Routing external 8259A's -> intpin 0 > ioapic0: intpin 0 -> ExtINT (edge, high) > ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) > ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) > ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) > ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) > ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) > ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) > ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) > ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) > ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) > ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) > ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) > ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) > ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) > ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) > ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) > MADT: Found IO APIC ID 13, Interrupt 16 at 0xfec01000 > ioapic1: intpin 0 -> PCI IRQ 16 (level, low) > ioapic1: intpin 1 -> PCI IRQ 17 (level, low) > ioapic1: intpin 2 -> PCI IRQ 18 (level, low) > ioapic1: intpin 3 -> PCI IRQ 19 (level, low) > ioapic1: intpin 4 -> PCI IRQ 20 (level, low) > ioapic1: intpin 5 -> PCI IRQ 21 (level, low) > ioapic1: intpin 6 -> PCI IRQ 22 (level, low) > ioapic1: intpin 7 -> PCI IRQ 23 (level, low) > ioapic1: intpin 8 -> PCI IRQ 24 (level, low) > ioapic1: intpin 9 -> PCI IRQ 25 (level, low) > ioapic1: intpin 10 -> PCI IRQ 26 (level, low) > ioapic1: intpin 11 -> PCI IRQ 27 (level, low) > ioapic1: intpin 12 -> PCI IRQ 28 (level, low) > ioapic1: intpin 13 -> PCI IRQ 29 (level, low) > ioapic1: intpin 14 -> PCI IRQ 30 (level, low) > ioapic1: intpin 15 -> PCI IRQ 31 (level, low) > MADT: Found IO APIC ID 12, Interrupt 32 at 0xfec02000 > ioapic2: intpin 0 -> PCI IRQ 32 (level, low) > ioapic2: intpin 1 -> PCI IRQ 33 (level, low) > ioapic2: intpin 2 -> PCI IRQ 34 (level, low) > ioapic2: intpin 3 -> PCI IRQ 35 (level, low) > ioapic2: intpin 4 -> PCI IRQ 36 (level, low) > ioapic2: intpin 5 -> PCI IRQ 37 (level, low) > ioapic2: intpin 6 -> PCI IRQ 38 (level, low) > ioapic2: intpin 7 -> PCI IRQ 39 (level, low) > ioapic2: intpin 8 -> PCI IRQ 40 (level, low) > ioapic2: intpin 9 -> PCI IRQ 41 (level, low) > ioapic2: intpin 10 -> PCI IRQ 42 (level, low) > ioapic2: intpin 11 -> PCI IRQ 43 (level, low) > ioapic2: intpin 12 -> PCI IRQ 44 (level, low) > ioapic2: intpin 13 -> PCI IRQ 45 (level, low) > ioapic2: intpin 14 -> PCI IRQ 46 (level, low) > ioapic2: intpin 15 -> PCI IRQ 47 (level, low) > MADT: intr override: source 0, irq 2 > ioapic0: Routing IRQ 0 -> intpin 2 > ioapic0: intpin 2 trigger: edge > ioapic0: intpin 2 polarity: high > lapic0: Routing NMI -> LINT1 > MADT: Ignoring local NMI routed to ACPI CPU 6 > MADT: Forcing active-low polarity and level trigger for SCI > ioapic0: intpin 3 polarity: low > ioapic0: intpin 3 trigger: level > ioapic2 <Version 1.1> irqs 32-47 on motherboard > ioapic1 <Version 1.1> irqs 16-31 on motherboard > ioapic0 <Version 1.1> irqs 0-15 on motherboard > cpu0 BSP: > ID: 0x00000000 VER: 0x00050014 LDR: 0x01000000 DFR: 0x0fffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > random: <entropy source, Software, Yarrow> > io: <I/O> > mem: <memory> > Pentium Pro MTRR support enabled > null: <null device, zero device> > npx0: [FAST] > npx0: <math processor> on motherboard > npx0: INT 16 interface > acpi0: <IBM SERONYXP> on motherboard > acpi0: [MPSAFE] > pci_open(1): mode 1 addr port (0x0cf8) is 0x80002800 > pci_open(1a): mode1res=0x80000000 (0x80000000) > pci_cfgcheck: device 0 [class=060000] [hdr=80] is there (id=00141166) > pcibios: BIOS version 2.10 > AcpiOsDerivePciId: bus 0 dev 15 func 2 > acpi0: Power Button (fixed) > AcpiOsDerivePciId: bus 0 dev 0 func 0 > AcpiOsDerivePciId: bus 0 dev 16 func 0 > AcpiOsDerivePciId: bus 0 dev 16 func 2 > AcpiOsDerivePciId: bus 0 dev 17 func 0 > AcpiOsDerivePciId: bus 0 dev 17 func 2 > acpi0: reservation of 460, 2 (4) failed > ACPI timer: 0/3 0/3 0/3 0/3 0/3 0/3 0/3 0/3 0/3 0/3 -> 0 > Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x488-0x48b on acpi0 > cpu0: <ACPI CPU> on acpi0 > cpu1: <ACPI CPU> on acpi0 > pcib0: <ACPI Host-PCI bridge> on acpi0 > pci0: <ACPI PCI bus> on pcib0 > pci0: physical bus=0 > found-> vendor=0x1166, dev=0x0014, revid=0x33 > bus=0, slot=0, func=0 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0000, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1166, dev=0x0014, revid=0x00 > bus=0, slot=0, func=1 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0000, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1166, dev=0x0014, revid=0x00 > bus=0, slot=0, func=2 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0000, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > map[10]: type 1, range 32, base fd000000, size 24, enabled > map[14]: type 4, range 32, base 00002400, size 8, enabled > map[18]: type 1, range 32, base febff000, size 12, enabled > pcib0: matched entry for 0.6.INTA > pcib0: slot 6 INTA hardwired to IRQ 26 > found-> vendor=0x1002, dev=0x4752, revid=0x27 > bus=0, slot=6, func=0 > class=03-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0087, statreg=0x0290, cachelnsz=8 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 > ns) > intpin=a, irq=26 > powerspec 2 supports D0 D1 D2 D3 current D0 > found-> vendor=0x1166, dev=0x0201, revid=0x93 > bus=0, slot=15, func=0 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0147, statreg=0x2200, cachelnsz=0 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > map[20]: type 4, range 32, base 00000700, size 4, enabled > found-> vendor=0x1166, dev=0x0212, revid=0x93 > bus=0, slot=15, func=1 > class=01-01-82, hdrtype=0x00, mfdev=1 > cmdreg=0x0155, statreg=0x0200, cachelnsz=8 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > map[10]: type 1, range 32, base febfe000, size 12, enabled > pcib0: matched entry for 0.15.INTA (src \LPUS:0) > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x48 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc051d7a7 > stack pointer = 0x10:0xc08208d8 > frame pointer = 0x10:0xc08208ec > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (swapper) > [thread pid 0 tid 0 ] > Stopped at device_get_softc+0x7: movl 0x48(%eax),%eax > db> tr > Tracing pid 0 tid 0 td 0xc06eda40 > device_get_softc(c07db4a0,c07d690d,35a,c0820928,c07b0e59) at device_get_softc+0x7 > acpi_pci_link_route_interrupt(0,0,c0820a28,f,41) at acpi_pci_link_route_interrupt+0x37 > acpi_pcib_route_interrupt(c1f16d00,c1f8b780,1,c1f7e214,1) at acpi_pcib_route_interrupt+0x33c > acpi_pcib_acpi_route_interrupt(c1f16d00,c1f8b780,1,c06c60d0,c1f8b808) at > acpi_pcib_acpi_route_interrupt+0x2f > pci_assign_interrupt_method(c1f16a00,c1f8b780,f,2,24) at pci_assign_interrupt_method+0x71 > pci_add_child(c1f16a00,c1f8b800,f,2,80) at pci_add_child+0x207 > pci_add_children(c1f16a00,0,80,c0820b54,c051fbaf) at pci_add_children+0x123 > acpi_pci_attach(c1f16a00,c1f5684c,c06bf6bc,c06a8919,0) at acpi_pci_attach+0x86 > device_attach(c1f16a00,c1ed5d80,c0820bdc,c07c234c,c1f16d00) at device_attach+0x2c9 > bus_generic_attach(c1f16d00,c07d61e7,0,c0820bcc,0) at bus_generic_attach+0x18 > acpi_pcib_attach(c1f16d00,c1f7e214,0,c0820c04,c07bcf57) at acpi_pcib_attach+0xec > acpi_pcib_acpi_attach(c1f16d00,c1f5584c,c06bf6bc,c06a8919,0) at acpi_pcib_acpi_attach+0xf9 > device_attach(c1f16d00,2f,c0820cbc,c07bf784,c1ed5d80) at device_attach+0x2c9 > bus_generic_attach(c1ed5d80,2e,2f,c1f7dc48,2e) at bus_generic_attach+0x18 > acpi_attach(c1ed5d80,c1f5804c,c06bf6bc,c06a8919,0) at acpi_attach+0x7b4 > device_attach(c1ed5d80,c1f15000,c0820d18,c067852a,c1f15000) at device_attach+0x2c9 > bus_generic_attach(c1f15000,c1f1504c,c0820d54,c051eb59,c1f15000) at bus_generic_attach+0x18 > nexus_attach(c1f15000,c1f4684c,c06bf6bc,c06a8919,0) at nexus_attach+0x1a > device_attach(c1f15000,c06dbb50,c0820d78,c0665758,c1f15680) at device_attach+0x2c9 > root_bus_configure(c1f15680,c06b95b7,0,c0820d98,c04d06a6) at root_bus_configure+0x19 > configure(0,0,c1e6f774,81ec00,81e000) at configure+0x28 > mi_startup() at mi_startup+0xd6 > begin() at begin+0x2c > db> > > (kgdb) l *device_get_softc+0x7 > 0xc051d7a7 is in device_get_softc (/usr/src/sys/kern/subr_bus.c:1937). > 1932 * on the size field of the driver. > 1933 */ > 1934 void * > 1935 device_get_softc(device_t dev) > 1936 { > 1937 return (dev->softc); > 1938 } > 1939 > 1940 /** > 1941 * _at_brief Set the device's softc field > (kgdb) l *acpi_pci_link_route_interrupt+0x37 > 0x35ba7 is in acpi_pci_link_route_interrupt (/usr/src/sys/modules/acpi/acpi/.. > /../../dev/acpica/acpi_pci_link.c:860). > 855 { > 856 struct link *link; > 857 > 858 ACPI_SERIAL_BEGIN(pci_link); > 859 link = acpi_pci_link_lookup(dev, index); > 860 if (link == NULL) > 861 panic("%s: apparently invalid index %d", __func__, > index); > 862 > 863 /* > 864 * If this link device is already routed to an interrupt, > just return > (kgdb) l *acpi_pcib_route_interrupt+0x33c > 0x327dc is in acpi_pcib_route_interrupt (acpivar.h:208). > 203 acpivar.h: No such file or directory. > in acpivar.h > (kgdb) l *acpi_pcib_acpi_route_interrupt+0x2f > 0x32d9f is in acpi_pcib_acpi_route_interrupt (/usr/src/sys/modules/acpi/acpi/.. > /../../dev/acpica/acpi_pcib_acpi.c:303). > 298 acpi_pcib_acpi_route_interrupt(device_t pcib, device_t dev, int > pin) > 299 { > 300 struct acpi_hpcib_softc *sc = device_get_softc(pcib); > 301 > 302 return (acpi_pcib_route_interrupt(pcib, dev, pin, &sc->ap_prt)); > 303 } > 304 > 305 static u_long acpi_host_mem_start = 0x80000000; > 306 TUNABLE_ULONG("hw.acpi.host_mem_start", &acpi_host_mem_start); > 307 > (kgdb) l *pci_assign_interrupt_method+0x71 > 0xc04b24b1 is in pci_assign_interrupt_method (/usr/src/sys/dev/pci/pci.c: > 1814). > 1809 struct pci_devinfo *dinfo = device_get_ivars(child); > 1810 pcicfgregs *cfg = &dinfo->cfg; > 1811 > 1812 return (PCIB_ROUTE_INTERRUPT(device_get_parent(dev), child, > 1813 cfg->intpin)); > 1814 } > 1815 > 1816 static int > 1817 pci_modevent(module_t mod, int what, void *arg) > 1818 { > (kgdb) l *pci_add_child+0x207 > 0xc04b0187 is in pci_add_child (/usr/src/sys/dev/pci/pci.c:940). > 935 * firmware may leave bogus values in these registers. > 936 * If the re-route fails, then just stick with > what we > 937 * have. > 938 */ > 939 irq = PCI_ASSIGN_INTERRUPT(bus, dev); > 940 if (PCI_INTERRUPT_VALID(irq)) { > 941 pci_write_config(dev, PCIR_INTLINE, irq, > 1); > 942 cfg->intline = irq; > 943 } else > 944 #endif > (kgdb) > > ps. sorry for the top-post, lost the original mail. > > -- > Pawel > > -- > Pawel > > ------------------------------ > > Message: 26 > Date: Fri, 10 Dec 2004 00:18:08 +0300 > From: Andrey Chernov <ache_at_nagual.pp.ru> > Subject: New kernel netgraph warning with recent -current: PPPoE > To: current_at_freebsd.org > Message-ID: <20041209211808.GA2477_at_nagual.pp.ru> > Content-Type: text/plain; charset=us-ascii > > Just start ppp as usual, with > set device PPPoE:fxp0 > in /etc/ppp/ppp.conf and got kernel warning now: > WARNING: attempt to net_add_domain(netgraph) after domainfinalize() > > Month old -current don't say this. > > -- > http://ache.pp.ru/ > > ------------------------------ > > Message: 27 > Date: Thu, 9 Dec 2004 22:26:23 +0100 (MET) > From: Pawel Worach <pawel.worach_at_telia.com> > Subject: panic: pmap_mapdev: Couldn't alloc kernel virtual memory on > mpt_attach > To: freebsd-current_at_freebsd.org > Message-ID: <15219186.1102627583229.JavaMail.tomcat_at_pne-ps4-sn1> > Content-Type: text/plain;charset="ISO-8859-1" > > Booting an IBM x345 box without ACPI (see other problem) generates this > panic during > the scsi controller probe. It sits on the line before the panic message > for about 1-2 minutes. > I got a similar/the same panic with ACPI before the other ACPI problem > showed up. > > FreeBSD 6.0-CURRENT #0: Wed Dec 8 17:58:20 CET 2004 > root_at_zero:/usr/obj/usr/src/sys/ZERO > MPTable: <IBM ENSW GEODE SMP > > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.90-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 > Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR, > PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PB > E> > real memory = 1073590272 (1023 MB) > avail memory = 1046147072 (997 MB) > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 6 > ioapic0: Assuming intbase of 0 > ioapic1: Assuming intbase of 16 > ioapic2: Assuming intbase of 32 > ioapic2 <Version 1.1> irqs 32-47 on motherboard > ioapic1 <Version 1.1> irqs 16-31 on motherboard > ioapic0 <Version 1.1> irqs 0-15 on motherboard > npx0: [FAST] > npx0: <math processor> on motherboard > npx0: INT 16 interface > pcib0: <MPTable Host-PCI bridge> pcibus 0 on motherboard > pci0: <PCI bus> on pcib0 > pci0: <display, VGA> at device 6.0 (no driver attached) > atapci0: <ServerWorks CSB5 UDMA100 controller> port 0x700-0x70f,0x376,0x170- > 0x177,0x3f6,0x1f0-0x1f7 at device 15.1 on pci0 > ata0: channel #0 on atapci0 > ata1: channel #1 on atapci0 > pci0: <serial bus, USB> at device 15.2 (no driver attached) > isab0: <PCI-ISA bridge> at device 15.3 on pci0 > isa0: <ISA bus> on isab0 > pcib1: <ServerWorks host to PCI bridge> pcibus 1 on motherboard > pci1: <PCI bus> on pcib1 > pcib2: <MPTable Host-PCI bridge> pcibus 2 on motherboard > pci2: <PCI bus> on pcib2 > fxp0: <Intel 82550 Pro/100 Ethernet> port 0x2500-0x253f mem 0xfbfc0000- > 0xfbfdffff,0xfbfff000-0xfbffffff irq 20 at device 3.0 on pci2 > miibus0: <MII bus> on fxp0 > inphy0: <i82555 10/100 media interface> on miibus0 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > fxp0: Ethernet address: 00:0e:0c:2e:98:88 > pcib4: <ServerWorks host to PCI bridge(unknown chipset)> pcibus 4 on motherboard > pci4: <PCI bus> on pcib4 > pcib6: <MPTable Host-PCI bridge> pcibus 6 on motherboard > pci6: <PCI bus> on pcib6 > em0: <Intel(R) PRO/1000 Network Connection, Version - 1.7.35> port 0x2540- > 0x257f mem 0xf9fe0000-0xf9ffffff irq 29 at device 8.0 on pci6 > em0: Ethernet address: 00:0d:60:1a:4f:c6 > em0: Speed:N/A Duplex:N/A > em1: <Intel(R) PRO/1000 Network Connection, Version - 1.7.35> port 0x2580- > 0x25bf mem 0xf9fc0000-0xf9fdffff irq 30 at device 8.1 on pci6 > em1: Ethernet address: 00:0d:60:1a:4f:c7 > em1: Speed:N/A Duplex:N/A > pcib8: <MPTable Host-PCI bridge> pcibus 8 on motherboard > pci8: <PCI bus> on pcib8 > mpt0: <LSILogic 1030 Ultra4 Adapter> port 0x2600-0x26ff mem 0xf7fe0000- > 0xf7feffff,0xf7ff0000-0xf7ffffff irq 27 at device 7.0 on pci8 > mpt0: [GIANT-LOCKED] > mpt1: <LSILogic 1030 Ultra4 Adapter> port 0x2700-0x27ff mem 0xf7fc0000- > 0xf7fcffff,0xf7fd0000-0xf7fdffff irq 28 at device 7.1 on pci8 > panic: pmap_mapdev: Couldn't alloc kernel virtual memory > cpuid = 0 > KDB: enter: panic > [thread pid 0 tid 0 ] > Stopped at kdb_enter+0x32: leal 0(%esi),%esi > db> tr > Tracing pid 0 tid 0 td 0xc06eda40 > kdb_enter(c06a75b3,0,c06b9a7d,c0820a20,0) at kdb_enter+0x32 > panic(c06b9a7d,10000,c1f5eb00,0,0) at panic+0x1f3 > pmap_mapdev(f7fd0000,10000,c1f5eb88,c1fcea80,c1f5eb84) at pmap_mapdev+0xd2 > nexus_activate_resource(c1ee6e00,c1f5eb00,3,14,c1f79980) at nexus_activate_resource+0xa4 > pci_alloc_resource(c1f5ed00,c1f5eb00,3,c1fdee90,0,ffffffff,0,2) at pci_alloc_resource+0x597 > bus_alloc_resource(c1f5eb00,3,c1fdee90,0,ffffffff) at bus_alloc_resource+0x7d > mpt_attach(c1f5eb00,c1f5eb00,ffffffff,c06a8919,0) at mpt_attach+0x453 > device_attach(c1f5eb00,8,c0820bdc,c04b088a,c1f5ed00) at device_attach+0x2c9 > bus_generic_attach(c1f5ed00,8,78,c0820bd0,8) at bus_generic_attach+0x18 > pci_attach(c1f5ed00,c1f5ed00,ffffffff,c06a8919,0) at pci_attach+0x8a > device_attach(c1f5ed00,c1ee6d80,c0820c4c,c0678171,c1ee6a00) at device_attach+0x2c9 > bus_generic_attach(c1ee6a00,c06b6d31,8,c0820c40,8) at bus_generic_attach+0x18 > mptable_hostb_attach(c1ee6a00,c1ee6a00,ffffffff,c06a8919,0) at mptable_hostb_attach+0x81 > device_attach(c1ee6a00,c1ee6dcc,c0820cbc,c0670bff,c1ee6d80) at device_attach+0x2c9 > bus_generic_attach(c1ee6d80,c1f373c0,c06bf6bc,c1ee6d80,c1ee6dcc) at bus_generic_attach+0x18 > legacy_attach(c1ee6d80,c1f3904c,c06bf6bc,c06a8919,0) at legacy_attach+0x1f > device_attach(c1ee6d80,c1ee6e00,c0820d18,c067852a,c1ee6e00) at device_attach+0x2c9 > bus_generic_attach(c1ee6e00,c1ee6e4c,c0820d54,c051eb59,c1ee6e00) at bus_generic_attach+0x18 > nexus_attach(c1ee6e00,c1f3f04c,c06bf6bc,c06a8919,0) at nexus_attach+0x1a > device_attach(c1ee6e00,c06dbb50,c0820d78,c0665758,c1e7f500) at device_attach+0x2c9 > root_bus_configure(c1e7f500,c06b95b7,0,c0820d98,c04d06a6) at root_bus_configure+0x19 > configure(0,0,c06bc314,81ec00,81e000) at configure+0x28 > mi_startup() at mi_startup+0xd6 > begin() at begin+0x2c > db> > > (kgdb) l *pmap_mapdev+0xd2 > 0xc067d342 is at /usr/src/sys/i386/i386/pmap.c:2877. > 2872 if (pa < KERNLOAD && pa + size <= KERNLOAD) > 2873 va = KERNBASE + pa; > 2874 else > 2875 va = kmem_alloc_nofault(kernel_map, size); > 2876 if (!va) > 2877 panic("pmap_mapdev: Couldn't alloc kernel virtual > memory"); > 2878 > 2879 for (tmpva = va; size > 0; ) { > 2880 pmap_kenter(tmpva, pa); > 2881 size -= PAGE_SIZE; > (kgdb) l *nexus_activate_resource+0xa4 > 0xc06788f4 is in nexus_activate_resource (/usr/src/sys/i386/i386/nexus. > c:419). > 414 > 415 paddr = rman_get_start(r); > 416 psize = rman_get_size(r); > 417 > 418 poffs = paddr - trunc_page(paddr); > 419 vaddr = (caddr_t) pmap_mapdev(paddr-poffs, > psize+poffs) + poffs; > 420 } > 421 rman_set_virtual(r, vaddr); > 422 #ifdef PC98 > 423 /* PC-98: the type of bus_space_handle_t is the > structure. */ > (kgdb) l *pci_alloc_resource+0x597 > 0xc04b1e87 is in pci_alloc_resource (/usr/src/sys/dev/pci/pci.c:1705). > 1700 rman_get_size(rle->res), *rid, > type, > 1701 rman_get_start(rle->res)); > 1702 if ((flags & RF_ACTIVE) && > 1703 bus_generic_activate_resource(dev, > child, type, > 1704 *rid, rle->res) != 0) > 1705 return NULL; > 1706 return (rle->res); > 1707 } > 1708 } > 1709 return (resource_list_alloc(rl, dev, child, type, rid, > (kgdb) l *bus_alloc_resource+0x7d > 0xc051c7ed is in bus_alloc_resource (/usr/src/sys/kern/subr_bus.c:3179). > 3174 { > 3175 if (dev->parent == 0) > 3176 return (0); > 3177 return (BUS_ALLOC_RESOURCE(dev->parent, dev, type, rid, > start, end, > 3178 count, flags)); > 3179 } > 3180 > 3181 /** > 3182 * _at_brief Wrapper function for BUS_ACTIVATE_RESOURCE(). > 3183 * > (kgdb) l *mpt_attach+0x453 > 0xc04aaf93 is in mpt_attach (/usr/src/sys/dev/mpt/mpt_pci.c:309). > 304 } > 305 > 306 /* Set up the memory regions */ > 307 /* Allocate kernel virtual memory for the 9x9's Mem0 region > */ > 308 mpt->pci_reg_id = MEM_MAP_REG; > 309 mpt->pci_reg = bus_alloc_resource(dev, SYS_RES_MEMORY, > 310 &mpt->pci_reg_id, 0, ~0, 0, RF_ACTIVE); > 311 if (mpt->pci_reg == NULL) { > 312 device_printf(dev, "unable to map any ports\n"); > 313 goto bad; > (kgdb) > > -- > Pawel > > ------------------------------ > > Message: 28 > Date: Fri, 10 Dec 2004 08:58:39 +1030 > From: "Wilkinson, Alex" <alex.wilkinson_at_dsto.defence.gov.au> > Subject: Re: panic: process 839(xmms):1 holds process lock but isn't > blocked ona lock > To: freebsd-current_at_freebsd.org > Message-ID: <20041209222835.GA18003_at_squash.dsto.defence.gov.au> > Content-Type: text/plain; charset="us-ascii" > > 0n Thu, Dec 09, 2004 at 01:01:55PM +1030, Kris Kennaway wrote: > > > On Thu, Dec 09, 2004 at 11:51:28AM +1030, Wilkinson, Alex wrote: > > > Another panic whilst mp3s were playing on xmms: > > > > What scheduler? > > SCHED_4BSD > > - aW > > ------------------------------ > > Message: 29 > Date: Fri, 10 Dec 2004 09:42:28 +1030 > From: "Wilkinson, Alex" <alex.wilkinson_at_dsto.defence.gov.au> > Subject: does this mean my kernel is trashed ? > To: freebsd-current_at_freebsd.org > Message-ID: <20041209231228.GD18003_at_squash.dsto.defence.gov.au> > Content-Type: text/plain; charset="us-ascii" > > # sudo indent /boot/kernel/kernel > > .... > > Warning_at_1751: Extra ) > Warning_at_1751: Extra ] > Error_at_1753: Unbalanced parens > Error_at_1753: Statement nesting error > Error_at_1770: Statement nesting error > Error_at_1772: Statement nesting error > Error_at_1774: Statement nesting error > Error_at_1776: Statement nesting error > Error_at_1776: Unbalanced parens > Warning_at_1785: Extra ) > Warning_at_1787: Extra ) > Warning_at_1788: Extra ) > 1788: Unterminated literal > Warning_at_1790: Extra ] > Warning_at_1792: Extra ] > Error_at_1793: Statement nesting error > Warning_at_1793: Extra ] > Error_at_1796: Unbalanced parens > Error_at_1796: Statement nesting error > Error_at_1799: Statement nesting error > Warning_at_1799: Extra ] > Error_at_1800: Statement nesting error > Error_at_1801: Statement nesting error > Error_at_1802: Statement nesting error > Warning_at_1802: Extra ] > Error_at_1803: Statement nesting error > Warning_at_1803: Extra ] > Warning_at_1803: Extra ] > Error_at_1804: Statement nesting error > Warning_at_1804: Extra ] > Warning_at_1804: Extra ) > Warning_at_1804: Extra ] > Warning_at_1805: Extra ] > Warning_at_1805: Extra ] > Error_at_1806: Statement nesting error > Warning_at_1807: Extra ] > Warning_at_1807: Extra ] > Error_at_1808: Statement nesting error > Warning_at_1810: Extra ] > > .... > > - aW > > ------------------------------ > > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" > > End of freebsd-current Digest, Vol 82, Issue 9 > ********************************************** >Received on Thu Dec 09 2004 - 22:31:13 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:24 UTC
