Re: Fwd: FreeBSD 6.3 and Intel G33
On Thu, 17 Jan 2008, Daniel O'Connor wrote: > > DPMS should work with the VESA driver even, not to discourage you > > from the right solution. > > The X log file says DPMS is enabled but doing 'xset dpms force off' > doesn't do anything (although when you move the mouse or press a key > the whole display refreshes so it appears X thinks it's been off) I have found some more time & hardware to try and fix this problem.. I merged the AGP code from HEAD into my tree (and vga_pci.c) but I am still getting "Couldn't bind memory for front buffer" from the ports intel driver. I tried to build the GIT version but it wants libdrm 2.4.0 and ports only has 2.3.0. It's CoB for today so I'll try installing that tomorrow. If you have any input I'd be most appreciative :) -- 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.
Intel G33 & FreeBSD 7.x
Does anyone have a G33 chipset system working in 7.x? I have a 6.3 install here and it isn't working with that so I have been merging things from HEAD but it still doesn't work. It would be worth switching to 7.x if it worked there 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: umtxn and Apache 2.2
On Aug 13, 2008, at 5:24 PM, Tom Evans wrote: On Wed, 2008-08-13 at 16:56 +0200, Borja Marcos wrote: Personally, I find PHP far too troublesome to run threaded. These days, I use an event MPM based front-end apache 2.2, which reverse proxies to either a prefork MPM apache 2.2 with mod_, or directly connect to a fastcgi instance. Serve all your static content from the front-end, and it's all quite fast - plus you can scale out much much more simply. That's what I've done finally, using threaded Apache with mod_fcgid. I've seen that PHP is not ready to be used as a module in a multithreaded Apache. Now it's working great, and, indeed, the multithread Apache instances can serve all the static content (images, etc) blazingly fast. Thank you very much, Borja. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you
On Sun, 3 Aug 2008, Robert Watson wrote: This is an advance warning that, late next week, I will be merging a fairly large set of changes to the IPv4 and IPv6 protocols layered over the inpcb/inpcbinfo kernel infrastructure. To be specific, this affects TCP, UDP, and raw sockets on both IPv4 and IPv6. I will post a further e-mail announcement along with patch set and schedule in a day or two once it's prepared. FYI: This patch has now been committed to Subversion. I'll keep a close eye out for difficulties; if you run into issues, please send me an e-mail (and CC stable@). Thanks, Robert N M Watson Computer Laboratory University of Cambridge The thrust of this change is to replace the mutexes protecting the inpcb and inpcbinfo data structures with read-write locks (rwlocks). These structures represent, respectively, particular sockets and the global socket lists for all socket types in IPv4 and IPv6 except for SCTP. When you run netstat, inpcbinfo is the data structure referencing all connections, and each line in the nestat output reflects the contents of a specific inpcb. In the current stage of this work, the intent is to improve performance for datagram-related protocols on SMP systems by allowing concurrent acquisition of both global and connection locks during receive and transmit. This is possible because, in the common case, no connection or global state is modified during UDP/raw receive and transmit at the IP layer, so a read lock is sufficient to prevent data in those structures from unexpectedly changing. For receive, socket layer state is modified, but this is separately protected by socket layer locks. On transmit, no state is modified at any layer, so in principle we will allow fully parallel transmit from multiple threads down to about the routing and network interface layers, whereas previously they would bottleneck in UDP. The applications targeted by this change are threaded UDP server applications, such as BIND9, nsd, and UDP-based memcached. Kris Kennaway and Paul Saab have done fairly extensive testing with the changes and demonstrated significant performance improvements due to reduced contention and overhead. Perhaps they can mention some of those numbers in a follow-up to this post. The reason for the heads up is that, while carefully-tested, changes of this sort do come with risks. We've carefully structured them so as to avoid breaking the ABIs for netstat, etc, but it's not impossible that some problems will arise as the changes settle. The goal, however, is to see these performance improvements in 7.1, and since they've had a bit to shake out in 8.x and seen some heavy use, I think now is the right time to merge them. In any case, I will send out e-mail in a couple of days with a proposed merge patch and schedule for merging, and perhaps if you are in a positition where you might benefit from these improvements, or have interesting UDP or raw-socket based applications running on 7.x, you could test the candidate patch before it's merged, reporting any problems. Unless I receive negative feedback, I will plan on merging the changes late in the week, and keep a close eye on stable@ for any reports of problems. Thanks, 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 "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel G33 & FreeBSD 7.x
On Mon, 18 Aug 2008 17:16:36 +0930 "Daniel O'Connor" <[EMAIL PROTECTED]> wrote: > Does anyone have a G33 chipset system working in 7.x? I have a working Q35 chipset (which is using the same driver) under latest -STABLE. FreeBSD 7.0-STABLE #0: Sat Aug 16 17:36:46 BST 2008 > I have a 6.3 install here and it isn't working with that so I have > been merging things from HEAD but it still doesn't work. It has been in the source tree since 2007: http://en.wikipedia.org/wiki/Intel_GMA#FreeBSD http://lists.freebsd.org/pipermail/cvs-src/2007-July/080677.html ... and was finally enabled in -STABLE about two weeks ago: http://lists.freebsd.org/pipermail/cvs-src/2008-August/093604.html dmesg[1] is attached. > It would be worth switching to 7.x if it worked there though :) It is worth it anyway! :-) (zfs, zfs, zfs...) Unfortunately, the drm module does not recognize my chipset (so I don't have DRI support under X.ORG) - could be a problem with my hardware. I would like to discuss that later this week on the list with more information. Cheers. [1] Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-STABLE #0: Sat Aug 9 22:33:30 BST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz (2407.11-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 Logical CPUs per core: 4 usable memory = 4195328000 (4000 MB) avail memory = 4042981376 (3855 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x2458-0x245f mem 0xe820-0xe827,0xe000-0xe7ff,0xe810-0xe81f irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7676k stolen memory agp0: aperture size is 128M pci0: at device 3.0 (no driver attached) atapci0: port 0x2450-0x2457,0x246c-0x246f,0x2448-0x244f,0x2468-0x246b,0x2420-0x242f irq 18 at device 3.2 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pci0: at device 3.3 (no driver attached) em0: port 0x2400-0x241f mem 0xe828-0xe829,0xe82a4000-0xe82a4fff irq 20 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:19:d1:a5:03:a7 uhci0: port 0x20e0-0x20ff irq 18 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x20c0-0x20df irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x20a0-0x20bf irq 17 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xe82a6c00-0xe82a6fff irq 17 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pci0: at device 27.0 (no driver attached) pcib2: at device 28.0 on pci0 pci2: on pcib2 pcib3: at device 28.1 on pci0 pci3: on pcib3 pcib4: at device 28.2 on pci0 pci4: on pcib4 atapci1: port 0x1018-0x101f,0x1024-0x1027,0x1010-0x1017,0x1020-0x1023,0x1000-0x100f mem 0xe800-0xe80001ff irq 18 at device 0.0 on pci4 atapci1: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] pcib5: at device 28.3 on pci0 pci5: on pcib5 pcib6: at device 28.4 on pci0 pci6: on pcib6 uhci3: port 0x2080-0x209f irq 23 at device 29.0 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0x2060-0x207f irq 19 at device 29.1 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered uhci5: port 0x2040-0x205f irq 18 at device 29.2 on pci0 uhci5: [GIANT-LOCKED] uhci5: [ITHREAD] usb6: on uhci5 usb6: USB rev
Re: Intel G33 & FreeBSD 7.x
| By Daniel O'Connor <[EMAIL PROTECTED]> | [ 2008-08-18 09:47 +0200 ] > Does anyone have a G33 chipset system working in 7.x? > > I have a 6.3 install here and it isn't working with that so I have been > merging things from HEAD but it still doesn't work. > > It would be worth switching to 7.x if it worked there though :) I'm using an Intel branded G33 board with 7.0-STABLE. Works better than the MSI G33 board I tried first... Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-STABLE #5: Thu May 15 21:13:01 SAST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/IGOR Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz (3185.32-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 Features=0xbfebfbff Features2=0x8e3fd> AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 8509808640 (8115 MB) avail memory = 8225095680 (7844 MB) ACPI APIC Table: Regards, Aragon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel G33 & FreeBSD 7.x
On Mon, 18 Aug 2008, Aragon Gouveia wrote: > | By Daniel O'Connor <[EMAIL PROTECTED]> > | [ 2008-08-18 09:47 +0200 ] > | > > Does anyone have a G33 chipset system working in 7.x? > > > > I have a 6.3 install here and it isn't working with that so I have > > been merging things from HEAD but it still doesn't work. > > > > It would be worth switching to 7.x if it worked there though :) > > I'm using an Intel branded G33 board with 7.0-STABLE. Works better > than the MSI G33 board I tried first... > > Copyright (c) 1992-2008 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, > 1994 The Regents of the University of California. All rights > reserved. FreeBSD is a registered trademark of The FreeBSD > Foundation. FreeBSD 7.0-STABLE #5: Thu May 15 21:13:01 SAST 2008 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/IGOR > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz (3185.32-MHz > K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 > Features=0xbfebfbffPGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PB >E> > Features2=0x8e3fdPR,PDCM,> AMD Features=0x20100800 > AMD Features2=0x1 > Cores per package: 2 > usable memory = 8509808640 (8115 MB) > avail memory = 8225095680 (7844 MB) > ACPI APIC Table: Guh sorry, I just realised that I asked the wrong question :-) Does anyone have a G33 onboard video working with FreeBSD with anything better than VESA? -- 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: Intel G33 & FreeBSD 7.x
On Mon, 2008-08-18 at 09:06 +0100, Oliver Peter wrote: > On Mon, 18 Aug 2008 17:16:36 +0930 > "Daniel O'Connor" <[EMAIL PROTECTED]> wrote: > > > Does anyone have a G33 chipset system working in 7.x? > ... > Unfortunately, the drm module does not recognize my chipset > (so I don't have DRI support under X.ORG) - could be a problem with > my hardware. I would like to discuss that later this week on the > list with more information. > > Cheers. Robert Noland posted last Wednesday on x11@ [1] that he had prepared an update to FreeBSD's drm kernel modules, which includes support for the G33 [2]. Cheers Tom [1] http://docs.freebsd.org/cgi/getmsg.cgi?fetch=36408+0 +archive/2008/freebsd-x11/20080817.freebsd-x11 [2] http://people.freebsd.org/~rnoland signature.asc Description: This is a digitally signed message part
Re: Intel G33 & FreeBSD 7.x
On Mon, 18 Aug 2008 10:18:14 +0100 Tom Evans <[EMAIL PROTECTED]> wrote: > On Mon, 2008-08-18 at 09:06 +0100, Oliver Peter wrote: > [...] > > Robert Noland posted last Wednesday on x11@ [1] that he had prepared > an update to FreeBSD's drm kernel modules, which includes support for > the G33 [2]. > > Cheers > > Tom > > [1] http://docs.freebsd.org/cgi/getmsg.cgi?fetch=36408+0 > +archive/2008/freebsd-x11/20080817.freebsd-x11 > [2] http://people.freebsd.org/~rnoland Excellent! I'll give it a try this evening and post some debug information here. Cheers. -- Oliver PETER, email: [EMAIL PROTECTED], ICQ# 113969174 "I like to con people. And I like to insult people. If you combine con & insult, you get consult!" -- Dogbert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel G33 & FreeBSD 7.x
On Mon, Aug 18, 2008 at 05:16:36PM +0930, Daniel O'Connor wrote: > Does anyone have a G33 chipset system working in 7.x? > > I have a 6.3 install here and it isn't working with that so I have been > merging things from HEAD but it still doesn't work. > > It would be worth switching to 7.x if it worked there though :) I'm using an HP DC7800, with a Q35 chip on it. It's working ok, and also drm should work on it. I still have a few error messages from Xorg whihc I could not diagnose, but they should be addressable. Had to uncomment some code in the kernel though. Look here: http://lists.freebsd.org/pipermail/cvs-src/2007-July/080677.html my dmesg: vgapci0: port 0x1230-0x1237 mem 0xf010-0xf017,0xe000-0xefff,0xf000-0xf00f irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7676k stolen memory agp0: aperture size is 256M -- Guido Falsi <[EMAIL PROTECTED]> ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel G33 & FreeBSD 7.x
On Mon, 18 Aug 2008, Tom Evans wrote: > Robert Noland posted last Wednesday on x11@ [1] that he had prepared > an update to FreeBSD's drm kernel modules, which includes support for > the G33 [2]. Ahh excellent, thanks for the pointers! Something to try tomorrow :) > Cheers > > Tom > > [1] http://docs.freebsd.org/cgi/getmsg.cgi?fetch=36408+0 > +archive/2008/freebsd-x11/20080817.freebsd-x11 > [2] http://people.freebsd.org/~rnoland -- 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: Intel G33 & FreeBSD 7.x
On Mon, 18 Aug 2008, Oliver Peter wrote: > On Mon, 18 Aug 2008 17:16:36 +0930 > > "Daniel O'Connor" <[EMAIL PROTECTED]> wrote: > > Does anyone have a G33 chipset system working in 7.x? > > I have a working Q35 chipset (which is using the same driver) > under latest -STABLE. > > FreeBSD 7.0-STABLE #0: Sat Aug 16 17:36:46 BST 2008 > > > I have a 6.3 install here and it isn't working with that so I have > > been merging things from HEAD but it still doesn't work. > > It has been in the source tree since 2007: > http://en.wikipedia.org/wiki/Intel_GMA#FreeBSD > http://lists.freebsd.org/pipermail/cvs-src/2007-July/080677.html > > ... and was finally enabled in -STABLE about two weeks ago: > http://lists.freebsd.org/pipermail/cvs-src/2008-August/093604.html > > dmesg[1] is attached. Ta. I MFC'd the AGP driver although quite possibly I stuffed something up. It does detect OK but X won't start with the ports intel driver. I tried the GIT one but I can't get that to compile due to an old libdrm in ports :( > > It would be worth switching to 7.x if it worked there though :) > > It is worth it anyway! :-) (zfs, zfs, zfs...) :) > Unfortunately, the drm module does not recognize my chipset > (so I don't have DRI support under X.ORG) - could be a problem with > my hardware. I would like to discuss that later this week on the > list with more information. I'd be very happy with accelerated 2D at this stage :) -- 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: FreeBSD 6.3/amd64: cvsup: Bus error (core dumped)
> This problem has been reported a couple of times but it is not clear what > change caused it. I upgraded my RELENG_6/amd64 system yesterday and ran into this bug. There's a fix (and an explanation of the bug) now in PR bin/124353. Koshy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you
At 04:14 AM 8/18/2008, Robert Watson wrote: On Sun, 3 Aug 2008, Robert Watson wrote: This is an advance warning that, late next week, I will be merging a fairly large set of changes to the IPv4 and IPv6 protocols layered over the inpcb/inpcbinfo kernel infrastructure. To be specific, this affects TCP, UDP, and raw sockets on both IPv4 and IPv6. I will post a further e-mail announcement along with patch set and schedule in a day or two once it's prepared. FYI: This patch has now been committed to Subversion. I'll keep a close eye out for difficulties; if you run into issues, please send me an e-mail (and CC stable@). Hi Robert, I just did a buildworld/kernel in case your commit fixed the routing bugs, but I am still seeing those bogus arp / routing table entries. I narrowed it down to the commits below. I dont think its the intel stuff, as another user reported the same issue using bce nics. date=2008.07.30.18.00.00 and date=2008.07.31.00.00.00 Updating collection src-all/cvs Edit src/sys/conf/files Add delta 1.1243.2.32 2008.07.30.20.35.41 kmacy Checkout src/sys/dev/e1000/LICENSE Checkout src/sys/dev/e1000/README Checkout src/sys/dev/e1000/e1000_80003es2lan.c Checkout src/sys/dev/e1000/e1000_80003es2lan.h Checkout src/sys/dev/e1000/e1000_82540.c Checkout src/sys/dev/e1000/e1000_82541.c Checkout src/sys/dev/e1000/e1000_82541.h Checkout src/sys/dev/e1000/e1000_82542.c Checkout src/sys/dev/e1000/e1000_82543.c Checkout src/sys/dev/e1000/e1000_82543.h Checkout src/sys/dev/e1000/e1000_82571.c Checkout src/sys/dev/e1000/e1000_82571.h Checkout src/sys/dev/e1000/e1000_82575.c Checkout src/sys/dev/e1000/e1000_82575.h Checkout src/sys/dev/e1000/e1000_api.c Checkout src/sys/dev/e1000/e1000_api.h Checkout src/sys/dev/e1000/e1000_defines.h Checkout src/sys/dev/e1000/e1000_hw.h Checkout src/sys/dev/e1000/e1000_ich8lan.c Checkout src/sys/dev/e1000/e1000_ich8lan.h Checkout src/sys/dev/e1000/e1000_mac.c Checkout src/sys/dev/e1000/e1000_mac.h Checkout src/sys/dev/e1000/e1000_manage.c Checkout src/sys/dev/e1000/e1000_manage.h Checkout src/sys/dev/e1000/e1000_nvm.c Checkout src/sys/dev/e1000/e1000_nvm.h Checkout src/sys/dev/e1000/e1000_osdep.c Checkout src/sys/dev/e1000/e1000_osdep.h Checkout src/sys/dev/e1000/e1000_phy.c Checkout src/sys/dev/e1000/e1000_phy.h Checkout src/sys/dev/e1000/e1000_regs.h Checkout src/sys/dev/e1000/if_em.c Checkout src/sys/dev/e1000/if_em.h Checkout src/sys/dev/e1000/if_igb.h Edit src/sys/kern/kern_synch.c Add delta 1.302.2.3 2008.07.30.18.28.09 rwatson Edit src/sys/kern/sys_process.c Add delta 1.145.2.1 2008.07.30.19.49.10 jhb Edit src/sys/netinet/tcp_subr.c Add delta 1.300.2.4 2008.07.30.20.35.41 kmacy Edit src/sys/netinet/tcp_syncache.c Add delta 1.130.2.9 2008.07.30.20.35.41 kmacy Add delta 1.130.2.10 2008.07.30.20.51.20 kmacy Edit src/sys/netinet/tcp_syncache.h Add delta 1.1.2.1 2008.07.30.20.35.41 kmacy Edit src/sys/netinet/tcp_usrreq.c Add delta 1.163.2.4 2008.07.30.20.35.41 kmacy Edit src/sys/netinet/udp_usrreq.c Add delta 1.218.2.1 2008.07.30.21.23.21 bz Edit src/sys/netinet6/ip6_input.c Add delta 1.95.2.1 2008.07.30.21.23.21 bz Edit src/sys/netinet6/ip6_var.h Add delta 1.39.2.2 2008.07.30.21.23.21 bz Edit src/sys/sys/socket.h Add delta 1.95.2.3 2008.07.30.19.35.40 kmacy Edit src/sys/ufs/ufs/ufs_lookup.c Add delta 1.83.2.2 2008.07.30.21.43.42 jhb Edit src/sys/vm/vm_object.c Add delta 1.385.2.2 2008.07.30.21.43.42 jhb Edit src/sys/vm/vm_object.h Add delta 1.114.2.1 2008.07.30.21.43.42 jhb Edit src/sys/vm/vnode_pager.c Add delta 1.236.2.2 2008.07.30.21.43.42 jhb ---Mike Thanks, Robert N M Watson Computer Laboratory University of Cambridge The thrust of this change is to replace the mutexes protecting the inpcb and inpcbinfo data structures with read-write locks (rwlocks). These structures represent, respectively, particular sockets and the global socket lists for all socket types in IPv4 and IPv6 except for SCTP. When you run netstat, inpcbinfo is the data structure referencing all connections, and each line in the nestat output reflects the contents of a specific inpcb. In the current stage of this work, the intent is to improve performance for datagram-related protocols on SMP systems by allowing concurrent acquisition of both global and connection locks during receive and transmit. This is possible because, in the common case, no connection or global state is modified during UDP/raw receive and transmit at the IP layer, so a read lock is sufficient to prevent data in those structures from unexpectedly changing. For receive, socket layer state is modified, but this is separately protected by socket layer locks. On transmit, no state is modified at any layer, so in principle we will allow fully parallel transmit from multiple threads down to about the routing and network interface layers, whereas previously they would bottleneck in UDP.
Re: FreeBSD 6.3/amd64: cvsup: Bus error (core dumped)
Joseph Koshy wrote: This problem has been reported a couple of times but it is not clear what change caused it. I upgraded my RELENG_6/amd64 system yesterday and ran into this bug. There's a fix (and an explanation of the bug) now in PR bin/124353. Koshy Thanks very much for tracking this down! Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you
On Monday 18 August 2008 09:37:51 am Mike Tancsa wrote: > At 04:14 AM 8/18/2008, Robert Watson wrote: > >On Sun, 3 Aug 2008, Robert Watson wrote: > >>This is an advance warning that, late next week, I will be merging > >>a fairly large set of changes to the IPv4 and IPv6 protocols > >>layered over the inpcb/inpcbinfo kernel infrastructure. To be > >>specific, this affects TCP, UDP, and raw sockets on both IPv4 and > >>IPv6. I will post a further e-mail announcement along with patch > >>set and schedule in a day or two once it's prepared. > > > >FYI: This patch has now been committed to Subversion. I'll keep a > >close eye out for difficulties; if you run into issues, please send > >me an e-mail (and CC stable@). > > Hi Robert, > I just did a buildworld/kernel in case your commit fixed the > routing bugs, but I am still seeing those bogus arp / routing table > entries. I narrowed it down to the commits below. I dont think its > the intel stuff, as another user reported the same issue using bce nics. > > date=2008.07.30.18.00.00 > and > date=2008.07.31.00.00.00 > > Updating collection src-all/cvs > Checkout src/sys/dev/e1000/LICENSE > Checkout src/sys/dev/e1000/README > Checkout src/sys/dev/e1000/e1000_80003es2lan.c > Checkout src/sys/dev/e1000/e1000_80003es2lan.h > Checkout src/sys/dev/e1000/e1000_82540.c > Checkout src/sys/dev/e1000/e1000_82541.c > Checkout src/sys/dev/e1000/e1000_82541.h > Checkout src/sys/dev/e1000/e1000_82542.c > Checkout src/sys/dev/e1000/e1000_82543.c > Checkout src/sys/dev/e1000/e1000_82543.h > Checkout src/sys/dev/e1000/e1000_82571.c > Checkout src/sys/dev/e1000/e1000_82571.h > Checkout src/sys/dev/e1000/e1000_82575.c > Checkout src/sys/dev/e1000/e1000_82575.h > Checkout src/sys/dev/e1000/e1000_api.c > Checkout src/sys/dev/e1000/e1000_api.h > Checkout src/sys/dev/e1000/e1000_defines.h > Checkout src/sys/dev/e1000/e1000_hw.h > Checkout src/sys/dev/e1000/e1000_ich8lan.c > Checkout src/sys/dev/e1000/e1000_ich8lan.h > Checkout src/sys/dev/e1000/e1000_mac.c > Checkout src/sys/dev/e1000/e1000_mac.h > Checkout src/sys/dev/e1000/e1000_manage.c > Checkout src/sys/dev/e1000/e1000_manage.h > Checkout src/sys/dev/e1000/e1000_nvm.c > Checkout src/sys/dev/e1000/e1000_nvm.h > Checkout src/sys/dev/e1000/e1000_osdep.c > Checkout src/sys/dev/e1000/e1000_osdep.h > Checkout src/sys/dev/e1000/e1000_phy.c > Checkout src/sys/dev/e1000/e1000_phy.h > Checkout src/sys/dev/e1000/e1000_regs.h > Checkout src/sys/dev/e1000/if_em.c > Checkout src/sys/dev/e1000/if_em.h > Checkout src/sys/dev/e1000/if_igb.h Since are seeing this w/o em we can rule all of these out. > Edit src/sys/kern/kern_synch.c >Add delta 1.302.2.3 2008.07.30.18.28.09 rwatson This is just a style change. > Edit src/sys/kern/sys_process.c >Add delta 1.145.2.1 2008.07.30.19.49.10 jhb This only affects userland reading memory of other process' userland (e.g. procfs 'mem' file, gdb, etc.). > Edit src/sys/conf/files >Add delta 1.1243.2.32 2008.07.30.20.35.41 kmacy > Edit src/sys/netinet/tcp_subr.c >Add delta 1.300.2.4 2008.07.30.20.35.41 kmacy > Edit src/sys/netinet/tcp_syncache.c >Add delta 1.130.2.9 2008.07.30.20.35.41 kmacy >Add delta 1.130.2.10 2008.07.30.20.51.20 kmacy > Edit src/sys/netinet/tcp_syncache.h >Add delta 1.1.2.1 2008.07.30.20.35.41 kmacy > Edit src/sys/netinet/tcp_usrreq.c >Add delta 1.163.2.4 2008.07.30.20.35.41 kmacy These are changes by Kip to do TCP offload (181013, 181014). > Edit src/sys/netinet/udp_usrreq.c >Add delta 1.218.2.1 2008.07.30.21.23.21 bz > Edit src/sys/netinet6/ip6_input.c >Add delta 1.95.2.1 2008.07.30.21.23.21 bz > Edit src/sys/netinet6/ip6_var.h >Add delta 1.39.2.2 2008.07.30.21.23.21 bz These changes are all to #ifdef INET6 only code, so probably not relevant. > Edit src/sys/sys/socket.h >Add delta 1.95.2.3 2008.07.30.19.35.40 kmacy More TCP offload stuff, though this just adds constants for new socket options. > Edit src/sys/ufs/ufs/ufs_lookup.c >Add delta 1.83.2.2 2008.07.30.21.43.42 jhb > Edit src/sys/vm/vm_object.c >Add delta 1.385.2.2 2008.07.30.21.43.42 jhb > Edit src/sys/vm/vm_object.h >Add delta 1.114.2.1 2008.07.30.21.43.42 jhb > Edit src/sys/vm/vnode_pager.c >Add delta 1.236.2.2 2008.07.30.21.43.42 jhb These are fixes to make UFS cache data from directories. Given that, I think the likeliest changes to cause this are the TCP offload changes. Note that Kip later MFC'd this change which changed ARP stuff: Author: kmacy Date: Thu Jul 31 22:42:27 2008 New Revision: 181075 URL: http://svn.freebsd.org/changeset/base/181075 Log: MFC ARP update hooks and change to arpresolve to do arp resolution without a pending mbuf to transmit Modified: stable/7/sys/net/route.c stable/7/sys/net/route.h stable/7/sys/netinet/if_ether.c stable/7/sys/netinet/if_ether.h However, I would stary by narrowing it down to see i
Re: trying to mount a write prptected zip disk panics the machine (unless the -r flag is used)
On Friday 15 August 2008 05:55:23 pm Torfinn Ingolfsen wrote: > Hello, > > Do you remember the zip[1] disks? The original 100 Mbyte ones? well > recently, I got a scsi zip drive (internal) with a scsi card (Adaptec > ava-2904) and some zip-100 disks, and a request to try to copy the data > from those disks. I found a cable, installed the card and zip drive > in a machine[2] running FreeBSd 7.0-stable, and luckily the zip disks could > be read. > > But during this process I discovered one thing; if I try to mount a > write protected zip disk without using the '-r' flag to the mount > command, my machine will panic a few seconds later. As there is no visual > indication to tell you that a zip disk is write protected, it is quite > easy to forget mounting it read only. > > Note: using zip disks that aren't write protected works fine. > > Details: > [EMAIL PROTECTED] uname -a > FreeBSD music1.kg4.no 7.0-STABLE FreeBSD 7.0-STABLE #0: Fri Aug 15 > 12:56:35 CEST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC > i386 > > [EMAIL PROTECTED] dmesg | grep ahc > ahc0: port 0x1400-0x14ff mem > 0x5c10-0x5c100fff irq 10 at device 15.0 on pci0 ahc0: Host Adapter Bios > disabled. Using default SCSI device parameters ahc0: [ITHREAD] > da0 at ahc0 bus 0 target 5 lun 0 > [EMAIL PROTECTED] dmesg | grep aic > aic7850: Single Channel A, SCSI Id=7, 3/253 SCBs > > [EMAIL PROTECTED] dmesg | grep da0 > da0 at ahc0 bus 0 target 5 lun 0 > da0: Removable Direct Access SCSI-2 device > da0: 3.300MB/s transfers > da0: 96MB (196608 512 byte sectors: 64H 32S/T 96C) > > This is what I got on the console (and in /var/log/messages) when I tried > to mount the disk: Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): > WRITE(06). CDB: a 0 0 21 8 0 Aug 15 20:14:33 music1 kernel: > (da0:ahc0:0:5:0): CAM Status: SCSI Status Error Aug 15 20:14:33 music1 > kernel: (da0:ahc0:0:5:0): SCSI Status: Check Condition Aug 15 20:14:33 > music1 kernel: (da0:ahc0:0:5:0): DATA PROTECT asc:27,0 Aug 15 20:14:33 > music1 kernel: (da0:ahc0:0:5:0): Write protected > Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): Unretryable error > Aug 15 20:14:33 music1 kernel: g_vfs_done():da0s4[WRITE(offset=512, > length=4096)]error = 13 Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): > WRITE(06). CDB: a 0 0 21 8 0 Aug 15 20:14:33 music1 kernel: > (da0:ahc0:0:5:0): CAM Status: SCSI Status Error Aug 15 20:14:33 music1 > kernel: (da0:ahc0:0:5:0): SCSI Status: Check Condition Aug 15 20:14:33 > music1 kernel: (da0:ahc0:0:5:0): DATA PROTECT asc:27,0 Aug 15 20:14:33 > music1 kernel: (da0:ahc0:0:5:0): Write protected > Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): Unretryable error > Aug 15 20:14:33 music1 kernel: g_vfs_done():da0s4[WRITE(offset=512, > length=4096)]error = 13 Aug 15 20:14:33 music1 kernel: fsync: giving up on > dirty > Aug 15 20:14:33 music1 kernel: 0xc2988114: tag devfs, type VCHR > Aug 15 20:14:33 music1 kernel: usecount 1, writecount 0, refcount 27 > mountedhere 0xc2617700 Aug 15 20:14:33 music1 kernel: flags () > Aug 15 20:14:33 music1 kernel: v_object 0xc299707c ref 0 pages 25 > Aug 15 20:14:33 music1 kernel: > Aug 15 20:14:33 music1 kernel: dev da0s4 > Aug 15 20:14:34 music1 kernel: GEOM_LABEL: Label for provider da0s4 is > msdosfs/DIPLOM. > > A few seconds went by, and then the machine panic'ed with apage fault: > [EMAIL PROTECTED] more /var/crash/info.0 > Dump header from device /dev/ad0s1b > Architecture: i386 > Architecture Version: 2 > Dump Length: 60837888B (58 MB) > Blocksize: 512 > Dumptime: Fri Aug 15 20:15:03 2008 > Hostname: music1.kg4.no > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 7.0-STABLE #0: Fri Aug 15 12:56:35 CEST 2008 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC > Panic String: page fault > Dump Parity: 2682527093 > Bounds: 0 > Dump Status: good > > (crash dump, 58 Mbyte, available on request). > > Is this how it is supposed to be, or should I file a PR? Can you get the stack trace? > References: > 1) http://en.wikipedia.org/wiki/Zip_drive > 2) http://tingox.googlepages.com/dp-ep-c400_freebsd -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Groff is not working in the latest code
The following happens in 7.0-STABLE built from the source "csup"ed
either yesterday's or this morning:
$ groff -mm -t -Tascii tmp.mm
groff: can't find `DESC' file
groff:fatal error: invalid device `ascii'
$ truss -mm -t -Tascii tmp.mm 2>&1 | grep DESC
++ [ ~/doc1/employ/ab-initio ] ++
truss groff -mm -t -Tascii tmp.mm 2>&1 | grep DESC
open("/usr/local/share/groff/site-font/devascii/DESC",O_RDONLY,0666)
ERR#2 'No such file or directory'
open("/usr/local/share/groff/1.19.2/font/devascii/DESC",O_RDONLY,0666)
ERR#2 'No such file or directory'
open("/usr/lib/font/devascii/DESC",O_RDONLY,0666) ERR#2 'No such file
or directory'
groff: can't find `DESC' file
write(2,"groff: can't find `DESC' file\n",30)= 30 (0x1e)
$ ls -l /usr/share/groff_font/devascii/DESC
-r--r--r-- 1 root wheel 95 Aug 18 08:59
/usr/share/groff_font/devascii/DESC
$ GROFF_FONT_PATH=/usr/share/groff_font groff -mm -t -Tascii tmp.mm
troff: fatal error: can't find macro file m
$ which groff
/usr/bin/groff
Note an attempt to look for a file under /usr/local, which should not
happen for a program in "base".
This behavior is very new -- no such problem existed in the code
fetched last Saturday. There, I see:
$ truss groff -mm -t -Tascii tmp.mm 2>&1 | grep DESC
open("/usr/share/groff_font/devascii/DESC",O_RDONLY,0666) = 3 (0x3)
Anybody know of what happened?
Thanks,
-- Alex -- [EMAIL PROTECTED] --
/*
* Machines that have broken down will work perfectly when the
* repairman arrives.
*/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
An oops [Re: Groff is not working in the latest code]
Oops, scratch (do not see) this piece in my previous message: ,--- I/Alex (Mon, 18 Aug 2008 11:09:10 -0400) * | $ truss -mm -t -Tascii tmp.mm 2>&1 | grep DESC | ++ [ ~/doc1/employ/ab-initio ] ++ `-* Thanks, -- Alex -- [EMAIL PROTECTED] -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you
At 10:24 AM 8/18/2008, John Baldwin wrote: Author: kmacy Date: Thu Jul 31 22:42:27 2008 New Revision: 181075 URL: http://svn.freebsd.org/changeset/base/181075 Log: MFC ARP update hooks and change to arpresolve to do arp resolution without a pending mbuf to transmit Modified: stable/7/sys/net/route.c stable/7/sys/net/route.h stable/7/sys/netinet/if_ether.c stable/7/sys/netinet/if_ether.h However, I would stary by narrowing it down to see if Kip's commits cause the change. Thanks, I grabbed the versions just prior to those committed 0[smtp2]% cd /usr/src/sys 0[smtp2]% ident net/route.c net/route.c: $FreeBSD: src/sys/net/route.c,v 1.120.2.4 2008/07/24 01:13:22 julian Exp $ 0[smtp2]% ident net/route.h net/route.h: $FreeBSD: src/sys/net/route.h,v 1.65.2.2 2008/07/24 01:13:22 julian Exp $ 0[smtp2]% ident netinet/if_ether.c netinet/if_ether.c: $FreeBSD: src/sys/netinet/if_ether.c,v 1.162.2.1 2008/07/24 01:13:22 julian Exp $ 0[smtp2]% ident netinet/if_ether.h netinet/if_ether.h: $FreeBSD: src/sys/netinet/if_ether.h,v 1.32 2005/02/22 13:04:03 glebius Exp $ 0[smtp2]% and still ? (199.212.134.1) at 00:15:17:3a:17:9d on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ICH9 Controller on Asus P5K-E showing up as "Intel AHCI controller"
It's not really a problem, as the device and the SATA hard drives and
DVD+RW attached to the bus operate properly, but I'm wondering why the
ICH9 controller (in AHCI mode) on the Asus P5K-E motherboard shows up
as:
atapci1: port
0xac00-0xac07,0xa880-0xa883,0xa800-0xa807,0xa480-0xa483,0xa400-0xa41f
mem 0xfbffe800-0xfbffefff irq 22 at device 31.2 on pci0
The chip ID (0x29228086) from pciconf:
[EMAIL PROTECTED]:0:31:2:class=0x010601 card=0x82771043 chip=0x29228086
rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82801IB/IR/IH (ICH9 Family) 6 port SATA AHCI Controller'
class = mass storage
Matches in ata-pci.h:
/usr/src/sys/dev/ata/ata-pci.h:#define ATA_I82801IB_AH60x29228086
And has an accompanying entry in ata-chipset.h:
/usr/src/sys/dev/ata/ata-chipset.c: { ATA_I82801IB_AH6, 0, AHCI,
0x00, ATA_SA300, "ICH9" },
Which correctly indicates it is AHCI compliant.
However, ata_ahci_ident() still falls back on a "generic" identifier,
which I guess means:
/* is this PCI device flagged as an AHCI compliant chip ? */
if (pci_read_config(dev, PCIR_PROGIF, 1) != PCIP_STORAGE_SATA_AHCI_1_0)
return ENXIO;
Is returning 0 and falling through to:
sprintf(buffer, "%s AHCI controller", ata_pcivendor2str(dev));
Just wondering why it is not properly detecting this as ICH9. Again,
just something cosmetic that I'm curious about. I'm going to double
check the BIOS settings now, but I am confident I have them set as
AHCI in the BIOS. I suppose this could be a BIOS bug of some sort. I
can also try upgrading to the latest BIOS.
The system is 7.0-STABLE/amd64 as of August 16, 2008.
Below is the full dmesg output, just in case it's pertinent.
Thanks much!
Josh
Copyright (c) 1992-2008 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.0-STABLE #0: Sat Aug 16 09:06:23 EDT 2008
[EMAIL PROTECTED]:/usr/jails/folsom/usr/obj/usr/src/sys/PFLOG
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz (3204.03-MHz K8-class CPU)
Origin = "GenuineIntel" Id = 0x6fb Stepping = 11
Features=0xbfebfbff
Features2=0xe3bd
AMD Features=0x20100800
AMD Features2=0x1
Cores per package: 4
usable memory = 4286234624 (4087 MB)
avail memory = 4124958720 (3933 MB)
ACPI APIC Table:
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
cpu0 (BSP): APIC ID: 0
cpu1 (AP): APIC ID: 1
cpu2 (AP): APIC ID: 2
cpu3 (AP): APIC ID: 3
ioapic0 irqs 0-23 on motherboard
netsmb_dev: loaded
acpi0: on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of 0, a (3) failed
acpi0: reservation of 10, cff0 (3) failed
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
pcib0: port 0xcf8-0xcff on acpi0
pci0: on pcib0
pcib1: irq 16 at device 1.0 on pci0
pci1: on pcib1
vgapci0: mem
0xfd00-0xfdff,0xd000-0xdfff,0xfc00-0xfcff irq
16 at device 0.0 on pci1
uhci0: port 0xb800-0xb81f irq 16 at
device 26.0 on pci0
uhci0: [GIANT-LOCKED]
uhci0: [ITHREAD]
usb0: on uhci0
usb0: USB revision 1.0
uhub0: on usb0
uhub0: 2 ports with 2 removable, self powered
uhci1: port 0xb880-0xb89f irq 21 at
device 26.1 on pci0
uhci1: [GIANT-LOCKED]
uhci1: [ITHREAD]
usb1: on uhci1
usb1: USB revision 1.0
uhub1: on usb1
uhub1: 2 ports with 2 removable, self powered
uhci2: port 0xbc00-0xbc1f irq 18 at
device 26.2 on pci0
uhci2: [GIANT-LOCKED]
uhci2: [ITHREAD]
usb2: on uhci2
usb2: USB revision 1.0
uhub2: on usb2
uhub2: 2 ports with 2 removable, self powered
ehci0: mem 0xfbfffc00-0xfbff
irq 18 at device 26.7 on pci0
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb3: EHCI version 1.0
usb3: companion controllers, 2 ports each: usb0 usb1 usb2
usb3: on ehci0
usb3: USB revision 2.0
uhub3: on usb3
uhub3: 6 ports with 6 removable, self powered
pcib2: irq 17 at device 28.0 on pci0
pci4: on pcib2
pcib3: irq 17 at device 28.4 on pci0
pci3: on pcib3
atapci0: port
0xdc00-0xdc07,0xd880-0xd883,0xd800-0xd807,0xd480-0xd483,0xd400-0xd40f
mem 0xfeafe000-0xfeaf irq 16 at device 0.0 on pci3
atapci0: [ITHREAD]
atapci0: AHCI called from vendor specific driver
atapci0: AHCI Version 01.00 controller with 2 ports detected
ata2: on atapci0
ata2: [ITHREAD]
ata3: on atapci0
ata3: [ITHREAD]
ata4: on atapci0
ata4: [ITHREAD]
pcib4: irq 16 at device 28.5 on pci0
pci2: on pcib4
mskc0: port 0xc800-0xc8ff mem
0xfe9fc000-0xfe9f irq 17 at device 0.0 on pci2
msk0: on mskc0
msk0: Ethernet address: 00:1d:60:bc:cc:39
miibus0: on msk0
e1000phy0: PHY 0 on miibus0
e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto
mskc0: [FILTER]
uhci3: port 0xb080-0xb09f irq 23 at
device 29.0 on pci0
uhci3: [GIANT-LOCKED]
uhci3: [ITHREAD]
usb4: on
Re: ICH9 Controller on Asus P5K-E showing up as "Intel AHCI controller"
On Mon, Aug 18, 2008 at 11:47:25AM -0400, Josh Carroll wrote: > It's not really a problem, as the device and the SATA hard drives and > DVD+RW attached to the bus operate properly, but I'm wondering why the > ICH9 controller (in AHCI mode) on the Asus P5K-E motherboard shows up > as: > > atapci1: port > 0xac00-0xac07,0xa880-0xa883,0xa800-0xa807,0xa480-0xa483,0xa400-0xa41f > mem 0xfbffe800-0xfbffefff irq 22 at device 31.2 on pci0 Because your motherboard allows for the enabling of AHCI on the ICH9. This is often a BIOS feature you can turn on/off. > Just wondering why it is not properly detecting this as ICH9. Again, > just something cosmetic that I'm curious about. I'm going to double > check the BIOS settings now, but I am confident I have them set as > AHCI in the BIOS. I suppose this could be a BIOS bug of some sort. I > can also try upgrading to the latest BIOS. I don't believe it's a bug. FreeBSD has a form of "generic AHCI" support, where for systems which indicate AHCI is available but has no direct AHCI chipset driver, will fall back to using a generic AHCI implementation that should work with most all AHCI implementations. I would say what you're seeing is good. AHCI == good. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you
At 10:24 AM 8/18/2008, John Baldwin wrote: > Edit src/sys/conf/files >Add delta 1.1243.2.32 2008.07.30.20.35.41 kmacy > Edit src/sys/netinet/tcp_subr.c >Add delta 1.300.2.4 2008.07.30.20.35.41 kmacy > Edit src/sys/netinet/tcp_syncache.c >Add delta 1.130.2.9 2008.07.30.20.35.41 kmacy >Add delta 1.130.2.10 2008.07.30.20.51.20 kmacy > Edit src/sys/netinet/tcp_syncache.h >Add delta 1.1.2.1 2008.07.30.20.35.41 kmacy > Edit src/sys/netinet/tcp_usrreq.c >Add delta 1.163.2.4 2008.07.30.20.35.41 kmacy These are changes by Kip to do TCP offload (181013, 181014). Given that, I think the likeliest changes to cause this are the TCP offload changes. Note that Kip later MFC'd this change which changed ARP stuff: However, I would stary by narrowing it down to see if Kip's commits cause the change. As I dont have the skills to unwind Robert's patch, I have done the following csup with date=2008.08.01.00.00.00 which shows the problem. I then manually grabbed the prior versions of the above files 0[smtp2]% ident src/sys/conf/files src/sys/conf/files: $FreeBSD: src/sys/conf/files,v 1.1243.2.30 2008/07/25 17:46:01 jhb Exp $ 0[smtp2]% ident src/sys/netinet/tcp_subr.c src/sys/netinet/tcp_subr.c: $FreeBSD: src/sys/netinet/tcp_subr.c,v 1.300.2.3 2008/07/24 01:13:22 julian Exp $ 0[smtp2]% ident src/sys/netinet/tcp_syncache.c src/sys/netinet/tcp_syncache.c: $FreeBSD: src/sys/netinet/tcp_syncache.c,v 1.130.2.8 2008/07/24 01:13:22 julian Exp $ 0[smtp2]% ident src/sys/netinet/tcp_syncache.h src/sys/netinet/tcp_syncache.h: $FreeBSD: src/sys/netinet/tcp_syncache.h,v 1.1 2007/07/27 00:57:06 silby Exp $ 0[smtp2]% ident src/sys/netinet/tcp_usrreq.c src/sys/netinet/tcp_usrreq.c: $FreeBSD: src/sys/netinet/tcp_usrreq.c,v 1.163.2.3 2008/03/01 11:50:00 rwatson Exp $ 0[smtp2]% All is OK. So it looks like the above introduced the bug. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you
got it On Mon, Aug 18, 2008 at 9:22 AM, Mike Tancsa <[EMAIL PROTECTED]> wrote: > At 10:24 AM 8/18/2008, John Baldwin wrote: > >> > Edit src/sys/conf/files >> >Add delta 1.1243.2.32 2008.07.30.20.35.41 kmacy >> > Edit src/sys/netinet/tcp_subr.c >> >Add delta 1.300.2.4 2008.07.30.20.35.41 kmacy >> > Edit src/sys/netinet/tcp_syncache.c >> >Add delta 1.130.2.9 2008.07.30.20.35.41 kmacy >> >Add delta 1.130.2.10 2008.07.30.20.51.20 kmacy >> > Edit src/sys/netinet/tcp_syncache.h >> >Add delta 1.1.2.1 2008.07.30.20.35.41 kmacy >> > Edit src/sys/netinet/tcp_usrreq.c >> >Add delta 1.163.2.4 2008.07.30.20.35.41 kmacy >> >> These are changes by Kip to do TCP offload (181013, 181014). >> >> Given that, I think the likeliest changes to cause this are the TCP >> offload >> changes. Note that Kip later MFC'd this change which changed ARP stuff: >> >> However, I would stary by narrowing it down to see if Kip's commits cause >> the >> change. > > > As I dont have the skills to unwind Robert's patch, I have done the > following > > csup with date=2008.08.01.00.00.00 > > which shows the problem. I then manually grabbed the prior versions of the > above files > > 0[smtp2]% ident src/sys/conf/files > src/sys/conf/files: > $FreeBSD: src/sys/conf/files,v 1.1243.2.30 2008/07/25 17:46:01 jhb Exp $ > 0[smtp2]% ident src/sys/netinet/tcp_subr.c > src/sys/netinet/tcp_subr.c: > $FreeBSD: src/sys/netinet/tcp_subr.c,v 1.300.2.3 2008/07/24 01:13:22 > julian Exp $ > 0[smtp2]% ident src/sys/netinet/tcp_syncache.c > src/sys/netinet/tcp_syncache.c: > $FreeBSD: src/sys/netinet/tcp_syncache.c,v 1.130.2.8 2008/07/24 01:13:22 > julian Exp $ > 0[smtp2]% ident src/sys/netinet/tcp_syncache.h > src/sys/netinet/tcp_syncache.h: > $FreeBSD: src/sys/netinet/tcp_syncache.h,v 1.1 2007/07/27 00:57:06 silby > Exp $ > 0[smtp2]% ident src/sys/netinet/tcp_usrreq.c > src/sys/netinet/tcp_usrreq.c: > $FreeBSD: src/sys/netinet/tcp_usrreq.c,v 1.163.2.3 2008/03/01 11:50:00 > rwatson Exp $ > 0[smtp2]% > > All is OK. So it looks like the above introduced the bug. > >---Mike > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you
At 12:55 PM 8/18/2008, Kip Macy wrote: got it Thanks. The problem manifests itself soon after boot. There is nothing special about the box, it has 2 em network interfaces doing a lot of sendmail as well as local recursive DNS for itself and a few other sendmail boxes and also talks to a cluster of spam / virus scanning machines over tcp and UDP. ---Mike On Mon, Aug 18, 2008 at 9:22 AM, Mike Tancsa <[EMAIL PROTECTED]> wrote: > At 10:24 AM 8/18/2008, John Baldwin wrote: > >> > Edit src/sys/conf/files >> >Add delta 1.1243.2.32 2008.07.30.20.35.41 kmacy >> > Edit src/sys/netinet/tcp_subr.c >> >Add delta 1.300.2.4 2008.07.30.20.35.41 kmacy >> > Edit src/sys/netinet/tcp_syncache.c >> >Add delta 1.130.2.9 2008.07.30.20.35.41 kmacy >> >Add delta 1.130.2.10 2008.07.30.20.51.20 kmacy >> > Edit src/sys/netinet/tcp_syncache.h >> >Add delta 1.1.2.1 2008.07.30.20.35.41 kmacy >> > Edit src/sys/netinet/tcp_usrreq.c >> >Add delta 1.163.2.4 2008.07.30.20.35.41 kmacy >> >> These are changes by Kip to do TCP offload (181013, 181014). >> >> Given that, I think the likeliest changes to cause this are the TCP >> offload >> changes. Note that Kip later MFC'd this change which changed ARP stuff: >> >> However, I would stary by narrowing it down to see if Kip's commits cause >> the >> change. > > > As I dont have the skills to unwind Robert's patch, I have done the > following > > csup with date=2008.08.01.00.00.00 > > which shows the problem. I then manually grabbed the prior versions of the > above files > > 0[smtp2]% ident src/sys/conf/files > src/sys/conf/files: > $FreeBSD: src/sys/conf/files,v 1.1243.2.30 2008/07/25 17:46:01 jhb Exp $ > 0[smtp2]% ident src/sys/netinet/tcp_subr.c > src/sys/netinet/tcp_subr.c: > $FreeBSD: src/sys/netinet/tcp_subr.c,v 1.300.2.3 2008/07/24 01:13:22 > julian Exp $ > 0[smtp2]% ident src/sys/netinet/tcp_syncache.c > src/sys/netinet/tcp_syncache.c: > $FreeBSD: src/sys/netinet/tcp_syncache.c,v 1.130.2.8 2008/07/24 01:13:22 > julian Exp $ > 0[smtp2]% ident src/sys/netinet/tcp_syncache.h > src/sys/netinet/tcp_syncache.h: > $FreeBSD: src/sys/netinet/tcp_syncache.h,v 1.1 2007/07/27 00:57:06 silby > Exp $ > 0[smtp2]% ident src/sys/netinet/tcp_usrreq.c > src/sys/netinet/tcp_usrreq.c: > $FreeBSD: src/sys/netinet/tcp_usrreq.c,v 1.163.2.3 2008/03/01 11:50:00 > rwatson Exp $ > 0[smtp2]% > > All is OK. So it looks like the above introduced the bug. > >---Mike > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: trying to mount a write prptected zip disk panics the machine (unless the -r flag is used)
On Mon, 18 Aug 2008 10:33:05 -0400
John Baldwin <[EMAIL PROTECTED]> wrote:
>
> Can you get the stack trace?
Like this?
[EMAIL PROTECTED] kgdb kernel.debug /var/crash/vmcore.0
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are welcome to change it and/or distribute copies of it under
certain conditions. Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details. This GDB was configured as "i386-marcel-freebsd"...
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc0737b19
stack pointer = 0x28:0xceb9cbcc
frame pointer = 0x28:0xceb9cbf8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 42 (syncer)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 24m34s
Physical memory: 307 MB
Dumping 58 MB: 43 27 11
Reading symbols from /boot/kernel/acpi.ko...Reading symbols
from /boot/kernel/acpi.ko.symbols...done. done.
Loaded symbols for /boot/kernel/acpi.ko
#0 doadump () at pcpu.h:195
195 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb)
(kgdb) backtrace
#0 doadump () at pcpu.h:195
#1 0xc078eed7 in boot (howto=260)
#at /usr/src/sys/kern/kern_shutdown.c:418 2 0xc078f199 in panic
#(fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:572
#3 0xc0a9efbc in trap_fatal (frame=0xceb9cb8c, eva=0)
#at /usr/src/sys/i386/i386/trap.c:899 4 0xc0a9f240 in trap_pfault
#(frame=0xceb9cb8c, usermode=0, eva=0)
#at /usr/src/sys/i386/i386/trap.c:812 5 0xc0a9fbec in trap
#(frame=0xceb9cb8c) at /usr/src/sys/i386/i386/trap.c:490 6 0xc0a859ab
#in calltrap () at /usr/src/sys/i386/i386/exception.s:139 7 0xc0737b19
#in g_io_request (bp=0xc299ba50, cp=0xc29b2e00)
#at /usr/src/sys/geom/geom_io.c:364 8 0xc073c116 in g_vfs_strategy
#(bo=0xc29881d4, bp=0xc88efc24) at /usr/src/sys/geom/geom_vfs.c:107 9
#0xc07f97b0 in bufwrite (bp=0xc88efc24) at buf.h:429 10 0xc07f2618 in
#bawrite (bp=0xc88efc24) at buf.h:417 11 0xc07fddaa in vop_stdfsync
#(ap=0xceb9ccd4) at /usr/src/sys/kern/vfs_default.c:479 12 0xc071cbbe
#in devfs_fsync (ap=0xceb9ccd4)
#at /usr/src/sys/fs/devfs/devfs_vnops.c:395 13 0xc0ab3ce2 in
#VOP_FSYNC_APV (vop=0xc0bcf040, a=0xceb9ccd4) at vnode_if.c:1007 14
#0xc080dff8 in sched_sync () at vnode_if.h:538 15 0xc076bc59 in
#fork_exit (callout=0xc080d8f0 , arg=0x0, frame=0xceb9cd38)
at /usr/src/sys/kern/kern_fork.c:781
#16 0xc0a85a20 in fork_trampoline ()
#at /usr/src/sys/i386/i386/exception.s:205
Let me know if it was wrong, or if you need something else.
--
Regards,
Torfinn Ingolfsen
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ICH9 Controller on Asus P5K-E showing up as "Intel AHCI controller"
> Because your motherboard allows for the enabling of AHCI on the ICH9. > This is often a BIOS feature you can turn on/off. I double checked and it is indeed set properly to "AHCI mode" (instead of "enhanced" or "legacy"). I also upgrade the BIOS and it still shows up the same way. > I don't believe it's a bug. FreeBSD has a form of "generic AHCI" > support, where for systems which indicate AHCI is available but has no > direct AHCI chipset driver, will fall back to using a generic AHCI > implementation that should work with most all AHCI implementations. > > I would say what you're seeing is good. AHCI == good. Right, and it is operating nominally (as far as I can tell). When I enabled the JMicron controller, interestingly enough it showed up as "JMicron AHCI controller" when set to AHCI mode in the BIOS. There doesn't seem to be any ill effect running with a generic AHCI vs. Intel-specific AHCI driver. Perhaps it's supposed to show up this way, I'm not sure. As I said, this is purely cosmetic and just piqued my interest/curiosity as to why it'd show in a "generic" fashion. Thanks! Josh ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
nanobsd build problem
I'm trying to build nanobsd. I get the error below. Any ideas? - >>> stage 4.2: building libraries -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/nanobsd.soekris/ MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= GROFF_BIN_PATH=/usr/obj/nanobsd.soekris//usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/nanobsd.soekris//usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/nanobsd.soekris//usr/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/usr/obj/nanobsd.soekris//usr/src/tmp INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/nanobsd.soekris//usr/src/tmp/legacy/usr/sbin:/usr/obj/nanobsd.soekris//usr/src/tmp/legacy/usr/bin:/usr/obj/nanobsd.soekris//usr/src/tmp/legacy/usr/games:/usr/obj/nanobsd.soekris//usr/src/tmp/usr/sbin:/usr/obj/nanobsd.soekris//usr/src/tmp/usr/bin:/usr/obj/nanobsd.soekris//usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 DESTDIR=/usr/obj/nanobsd.soekris//usr/src/tmp -DNO_FSCHG -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN -DWITHOUT_NLS -DWITHOUT_PROFILE libraries cd /usr/src; make -f Makefile.inc1 _prereq_libs; make -f Makefile.inc1 _startup_libs; make -f Makefile.inc1 _prebuild_libs; make -f Makefile.inc1 _generic_libs; ===> gnu/lib/libgcc (obj,depend,all,install) make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/usr/src/gnu/lib/libgcc/../../../contrib/gcc tm.h make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/usr/src/gnu/lib/libgcc/../../../contrib/gcc tconfig.h make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/usr/src/gnu/lib/libgcc/../../../contrib/gcc options.h TARGET_CPU_DEFAULT="" HEADERS="options.h i386/i386.h i386/unix.h i386/att.h dbxelf.h elfos.h freebsd-native.h freebsd-spec.h freebsd.h i386/freebsd.h defaults.h" DEFINES="" /bin/sh /usr/src/gnu/lib/libgcc/../../../contrib/gcc/mkconfig.sh tm.h TARGET_CPU_DEFAULT="" HEADERS="auto-host.h ansidecl.h" DEFINES="USED_FOR_TARGET" /bin/sh /usr/src/gnu/lib/libgcc/../../../contrib/gcc/mkconfig.sh tconfig.h awk -f /usr/src/gnu/lib/libgcc/../../../contrib/gcc/opt-gather.awk /usr/src/gnu/lib/libgcc/../../../contrib/gcc/c.opt /usr/src/gnu/lib/libgcc/../../../contrib/gcc/common.opt /usr/src/gnu/lib/libgcc/../../../contrib/gcc/config/i386/i386.opt > optionlist echo '#define EXTRA_MODES_FILE "i386/i386-modes.def"' >> tm.h make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/usr/src/gnu/lib/libgcc/../../../contrib/gcc unwind.h make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/usr/src/gnu/lib/libgcc/../../../contrib/gcc gthr-default.h ln -sf /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-generic.h unwind.h ln -sf /usr/src/gnu/lib/libgcc/../../../contrib/gcc/gthr-posix.h gthr-default.h awk -f /usr/src/gnu/lib/libgcc/../../../contrib/gcc/opt-functions.awk -f /usr/src/gnu/lib/libgcc/../../../contrib/gcc/opth-gen.awk < optionlist > options.h cc -c -O2 -fno-strict-aliasing -pipe -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/usr/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc -I. -I/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -fvisibility=hidden -DHIDE_EXPORTS -fPIC -DL_muldi3 -o _muldi3.o /usr/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc2.c cc -c -O2 -fno-strict-aliasing -pipe -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/usr/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc -I. -I/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -fvisibility=hidden -DHIDE_EXPORTS -fPIC -DL_negdi2 -o _negdi2.o /usr/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc2.c cc -c -O2 -fno-strict-aliasing -pipe -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/usr/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc -I. -I/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -fvisibility=hidden -DHIDE_EXPORTS -fPIC -DL_lshrdi3 -o _lshrdi3.o /usr/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc2.c In file included from /usr/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc2.c:33: /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:47:20: error: stddef.h: No such file or directory /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:48:19: error: float.h: No such file or dir
Re: nanobsd build problem
On Mon, 18 Aug 2008 22:14:04 +0300, Dan Pelleg <[EMAIL PROTECTED]> wrote: > I'm trying to build nanobsd. I get the error below. Any ideas? > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:111:18: error: > time.h: No such file or directory > *** Error code 1 Do you have WITHOUT_TOOLCHAIN set? That option currently only works for the install target, not the build target. Hope that helps. - Ben ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you
Hi Mike, Could you please check that this doesn't happen on HEAD as well? This same code has been in 8 since shortly after the branch. Thanks, Kip On Mon, Aug 18, 2008 at 10:14 AM, Mike Tancsa <[EMAIL PROTECTED]> wrote: > At 12:55 PM 8/18/2008, Kip Macy wrote: >> >> got it > > Thanks. The problem manifests itself soon after boot. There is nothing > special about the box, it has 2 em network interfaces doing a lot of > sendmail as well as local recursive DNS for itself and a few other sendmail > boxes and also talks to a cluster of spam / virus scanning machines over tcp > and UDP. > >---Mike > >> On Mon, Aug 18, 2008 at 9:22 AM, Mike Tancsa <[EMAIL PROTECTED]> wrote: >> > At 10:24 AM 8/18/2008, John Baldwin wrote: >> > >> >> > Edit src/sys/conf/files >> >> >Add delta 1.1243.2.32 2008.07.30.20.35.41 kmacy >> >> > Edit src/sys/netinet/tcp_subr.c >> >> >Add delta 1.300.2.4 2008.07.30.20.35.41 kmacy >> >> > Edit src/sys/netinet/tcp_syncache.c >> >> >Add delta 1.130.2.9 2008.07.30.20.35.41 kmacy >> >> >Add delta 1.130.2.10 2008.07.30.20.51.20 kmacy >> >> > Edit src/sys/netinet/tcp_syncache.h >> >> >Add delta 1.1.2.1 2008.07.30.20.35.41 kmacy >> >> > Edit src/sys/netinet/tcp_usrreq.c >> >> >Add delta 1.163.2.4 2008.07.30.20.35.41 kmacy >> >> >> >> These are changes by Kip to do TCP offload (181013, 181014). >> >> >> >> Given that, I think the likeliest changes to cause this are the TCP >> >> offload >> >> changes. Note that Kip later MFC'd this change which changed ARP >> >> stuff: >> >> >> >> However, I would stary by narrowing it down to see if Kip's commits >> >> cause >> >> the >> >> change. >> > >> > >> > As I dont have the skills to unwind Robert's patch, I have done the >> > following >> > >> > csup with date=2008.08.01.00.00.00 >> > >> > which shows the problem. I then manually grabbed the prior versions of >> > the >> > above files >> > >> > 0[smtp2]% ident src/sys/conf/files >> > src/sys/conf/files: >> > $FreeBSD: src/sys/conf/files,v 1.1243.2.30 2008/07/25 17:46:01 jhb >> > Exp $ >> > 0[smtp2]% ident src/sys/netinet/tcp_subr.c >> > src/sys/netinet/tcp_subr.c: >> > $FreeBSD: src/sys/netinet/tcp_subr.c,v 1.300.2.3 2008/07/24 01:13:22 >> > julian Exp $ >> > 0[smtp2]% ident src/sys/netinet/tcp_syncache.c >> > src/sys/netinet/tcp_syncache.c: >> > $FreeBSD: src/sys/netinet/tcp_syncache.c,v 1.130.2.8 2008/07/24 >> > 01:13:22 >> > julian Exp $ >> > 0[smtp2]% ident src/sys/netinet/tcp_syncache.h >> > src/sys/netinet/tcp_syncache.h: >> > $FreeBSD: src/sys/netinet/tcp_syncache.h,v 1.1 2007/07/27 00:57:06 >> > silby >> > Exp $ >> > 0[smtp2]% ident src/sys/netinet/tcp_usrreq.c >> > src/sys/netinet/tcp_usrreq.c: >> > $FreeBSD: src/sys/netinet/tcp_usrreq.c,v 1.163.2.3 2008/03/01 >> > 11:50:00 >> > rwatson Exp $ >> > 0[smtp2]% >> > >> > All is OK. So it looks like the above introduced the bug. >> > >> >---Mike >> > > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
LOR with pf + synproxy state
Hi!
Last week I discovered an LOR on 7-STABLE (last build: 2008-Aug-17,
RELENG_7).
I can easily recreate the problem when running a synproxy state rule for
incoming tcp connections and ssh'ing to my box.
W/o using synproxy state (keep'ing state instead), no LOR takes place.
lock order reversal:
1st 0xc575c92c pf task mtx (pf task mtx) @
/usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6774
2nd 0xc521777c radix node head (radix node head) @
/usr/src/sys/net/route.c:278
KDB: stack backtrace:
db_trace_self_wrapper(c0a2fa65,e557b890,c075f315,c0a30e10,c521777c,...)
at db_trace_self_wrapper+0x26
kdb_backtrace(c0a30e10,c521777c,c0a31129,c0a31129,c0a374a0,...) at
kdb_backtrace+0x29
witness_checkorder(c521777c,9,c0a374a0,116,c507d000,...) at
witness_checkorder+0x5e5
_mtx_lock_flags(c521777c,0,c0a374a0,116,c5fe9a00,...) at
_mtx_lock_flags+0x34
rtalloc1_fib(e557b998,1,100,0,e557b994,...) at rtalloc1_fib+0x76
rtalloc_ign_fib(e557b994,100,0,e557b9b4,c5734a38,...) at
rtalloc_ign_fib+0xad
in_rtalloc_ign(e557b994,100,0,692a1600,5b47f56,...) at in_rtalloc_ign+0x1f
pf_calc_mss(c62a881c,2,5b4,2,e557bb4c,...) at pf_calc_mss+0x88
pf_test_tcp(e557bb68,e557bb64,1,c56e9400,c5fe9a00,...) at pf_test_tcp+0xdf6
pf_test(1,c507d000,e557bbc4,0,0,...) at pf_test+0x1028
pf_check_in(0,e557bbc4,c507d000,1,0,...) at pf_check_in+0x39
pfil_run_hooks(c0b79ec0,e557bc18,c507d000,1,0,...) at pfil_run_hooks+0x78
ip_input(c5fe9a00,14e,800,c507d000,800,...) at ip_input+0x265
netisr_dispatch(2,c5fe9a00,10,3,0,...) at netisr_dispatch+0x55
ether_demux(c507d000,c5fe9a00,3,0,3,...) at ether_demux+0x1c1
ether_input(c507d000,c5fe9a00,c0a0391b,c57,c507d000,...) at
ether_input+0x323
bge_intr(c5084000,0,c0a2b122,4b6,c4ef84e8,...) at bge_intr+0x77a
ithread_loop(c50814f0,e557bd38,c0a2af4a,305,c508cad0,...) at
ithread_loop+0x155
fork_exit(c07102d0,c50814f0,e557bd38) at fork_exit+0x94
fork_trampoline() at fork_trampoline+0x8
--- trap 0, eip = 0, esp = 0xe557bd70, ebp = 0 ---
KDB: enter: witness_checkorder
exclusive sleep mutex pf task mtx r = 0 (0xc575c92c) locked @
/usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6774
shared rw PFil hook read/write mutex r = 0 (0xc0b79ed8) locked @
/usr/src/sys/net/pfil.c:73
exclusive sx so_rcv_sx r = 0 (0xc5db208c) locked @
/usr/src/sys/kern/uipc_sockbuf.c:148
exclusive sx so_rcv_sx r = 0 (0xc551f22c) locked @
/usr/src/sys/kern/uipc_sockbuf.c:148
exclusive sleep mutex pf task mtx r = 0 (0xc575c92c) locked @
/usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6774
shared rw PFil hook read/write mutex r = 0 (0xc0b79ed8) locked @
/usr/src/sys/net/pfil.c:73
pf rules used:
## Macros
TCPSYN="S/SA"
if_lan = "bge0"
if_wlan = "ndis0"
if_ipsec = "enc"
###
tcp_in = "{ ssh http mdns 9102 49101 5900 }"
udp_in = "{ mdns snmp 5029 }"
passicmp = "{ 3 4 6 9 10 11 12 17 18 }"
samba_tcp = "{ 139 445 }"
samba_udp = "{ 137 1434 }"
##
table { 127/8 10/8 172.16/12 192.168/16 }
table { 224/8 239/8 }
##
## GLOBAL OPTIONS
set block-policy drop
set fingerprints "/etc/pf.os"
set state-policy if-bound
set skip on lo0
set optimization conservative
###
## TRAFFIC NORMALIZATION
scrub all random-id fragment reassemble reassemble tcp
###
## TRANSLATION RULES (NAT)
nat on $if_lan -> ($if_lan)
nat on $if_wlan -> ($if_wlan)
##
## FILTER RULES
block quick on lo0 proto {tcp udp} from any to any port biff
pass quick on lo0 all
antispoof log quick for { $if_lan $if_wlan }
block drop log all
block return in quick proto { tcp udp } from any to any port auth
###
# IPSEC VPN
###
pass log quick on {$if_lan $if_wlan} proto udp from any \
to any port isakmp keep state
pass log quick on {$if_lan $if_wlan} proto udp from any \
to any port isakmp keep state
pass quick log on {$if_lan $if_wlan} proto { ah, esp } from any \
to any keep state
pass quick log on {$if_lan $if_wlan} proto { ah, esp } from any \
to any keep state
pass quick log on $if_ipsec from any to any keep state
###
# ICMP
###
pass quick log on {$if_lan $if_wlan} proto icmp from any to any \
tag PASSOK keep state
pass quick log inet proto icmp all icmp-type $passicmp keep state \
(max 2, max-src-states 1, max-src-nodes 1, source-track rule )
pass in quick log on {$if_lan $if_wlan} proto icmp from any to any \
keep state probability 50%
###
# out traffic
###
pass out log quick on {$if_lan $if_wlan} all flags $TCPSYN keep state
###
# in traffic
###
# allow broadcasts + samba - don't log
pass quick on $if_lan from any to ($if_lan:broadcast)
pass quick on $if_wlan from any to ($if_wlan:broadcas
Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you
At 06:32 PM 8/18/2008, Kip Macy wrote: Hi Mike, Could you please check that this doesn't happen on HEAD as well? This same code has been in 8 since shortly after the branch. Hi, I dont have any easy way to migrate the box to HEAD and then back. Can I just boot a kernel from HEAD ? I noticed on the commits prior to some of those files, (e.g. http://lists.freebsd.org/pipermail/cvs-src/2008-July/093223.html ) "MFC an ABI compatible implementation of Multiple routing tables." Is it possible your commit makes some assumptions that dont jive with that? ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you
On Mon, Aug 18, 2008 at 3:42 PM, Mike Tancsa <[EMAIL PROTECTED]> wrote: > At 06:32 PM 8/18/2008, Kip Macy wrote: >> >> Hi Mike, >> Could you please check that this doesn't happen on HEAD as well? This >> same code has been in 8 since shortly after the branch. > > Hi, >I dont have any easy way to migrate the box to HEAD and then back. > Can I just boot a kernel from HEAD ? Yes. That should work fine. A couple of utilities won't work (ps and netstat) but other than that it should be testable. > I noticed on the commits prior to some of those files, > (e.g. > http://lists.freebsd.org/pipermail/cvs-src/2008-July/093223.html > ) > "MFC an ABI compatible implementation of Multiple routing tables." > > Is it possible your commit makes some assumptions that dont jive with that? It is indeed possible. That would make the most sense. Thanks, Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you
On Mon, 18 Aug 2008, Mike Tancsa wrote: At 06:32 PM 8/18/2008, Kip Macy wrote: Could you please check that this doesn't happen on HEAD as well? This same code has been in 8 since shortly after the branch. I dont have any easy way to migrate the box to HEAD and then back. Can I just boot a kernel from HEAD ? In general yes, but the uart changes in HEAD mean that you may need to tweak device.hints or change configurations. 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 "[EMAIL PROTECTED]"
Re: Intel G33 & FreeBSD 7.x
On Mon, 18 Aug 2008 10:38:11 +0100 Oliver Peter <[EMAIL PROTECTED]> wrote: > On Mon, 18 Aug 2008 10:18:14 +0100 > Tom Evans <[EMAIL PROTECTED]> wrote: > > > On Mon, 2008-08-18 at 09:06 +0100, Oliver Peter wrote: > > [...] > > > > Robert Noland posted last Wednesday on x11@ [1] that he had prepared > > an update to FreeBSD's drm kernel modules, which includes support > > for the G33 [2]. > > > > Cheers > > > > Tom > > > > [1] http://docs.freebsd.org/cgi/getmsg.cgi?fetch=36408+0 > > +archive/2008/freebsd-x11/20080817.freebsd-x11 > > [2] http://people.freebsd.org/~rnoland > > Excellent! I'll give it a try this evening and post some debug > information here. Here we go: [EMAIL PROTECTED] /usr/src/sys % patch < /home/oliver/freebsd/src/drm-7-stable.20080813.patch ... [EMAIL PROTECTED] /usr/src % make -j4 buildkernel KERNCONF=DELOREAN ... -- >>> Kernel build for DELOREAN completed on Tue Aug 19 00:12:01 BST 2008 -- ... [EMAIL PROTECTED] /usr/src % make installkernel KERNCONF=DELOREAN ... [EMAIL PROTECTED] /usr/src % shutdown -r now ... [EMAIL PROTECTED] ~ % dmesg | grep drm drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xd000 256MB info: [drm] Initialized i915 1.6.0 20080312 drm0: [ITHREAD] drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xd000 256MB info: [drm] Initialized i915 1.6.0 20080312 drm0: [ITHREAD] drm0: [ITHREAD] ... [EMAIL PROTECTED] ~ % glxinfo | head name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe, GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer Unfortunately, the machine completely freezes up when trying a "X -config ..." and the throughput is not very satisfying as well... Example: [EMAIL PROTECTED] ~ % glxgears 727 frames in 5.0 seconds = 145.369 FPS 727 frames in 5.0 seconds = 145.272 FPS 720 frames in 5.0 seconds = 143.927 FPS ... I'll move that topic to freebsd-x11 tomorrow. :) -- Oliver PETER, email: [EMAIL PROTECTED], ICQ# 113969174 "I like to con people. And I like to insult people. If you combine con & insult, you get consult!" -- Dogbert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ICH9 Controller on Asus P5K-E showing up as "Intel AHCI controller"
Josh Carroll wrote: atapci1: port 0xac00-0xac07,0xa880-0xa883,0xa800-0xa807,0xa480-0xa483,0xa400-0xa41f mem 0xfbffe800-0xfbffefff irq 22 at device 31.2 on pci0 The chip ID (0x29228086) from pciconf: [EMAIL PROTECTED]:0:31:2:class=0x010601 card=0x82771043 chip=0x29228086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) 6 port SATA AHCI Controller' class = mass storage As Jeremy said it is ok. In pciconf output you can see "class=0x010601". Your ICH9 controller has PCI subclass 0x06 (SATA) and PCI programming interface 0x01 (AHCI). Driver identified it as AHCI-compatible and used AHCI facilities. Some of PCI ids in ata_intel_ident can be removed today (generic AHCI support will be used for controllers which are identified as AHCI). Some controllers don't identified as AHCI, but can work as AHCI. And they will be handled by ata_xxx_ident. -- WBR, Andrey V. Elsukov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
