FAILURE - zero length DMA transfer attempted
Hi, yesterday I was using my DVD drive (simply reading a DVD). I got lots of syslog entries that look like this: ata4: FAILURE - zero length DMA transfer attempted acd0: setting up DMA failed This happens on: FreeBSD kirby 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Wed May 6 09:40:10 CEST 2009 r...@kirby:/usr/obj/usr/src/sys/GENERIC amd64 Drive is Sony NEC Optiarc (SATA): acd0: DVDR Optiarc DVD RW AD-7203S/1.06 at ata4-master SATA150 SATA controller is from Intel: atapci1: Intel AHCI controller port 0xe600-0xe607,0xe700-0xe703,0xe800-0xe807, 0xe900-0xe903,0xea00-0xea1f mem 0xe9306000-0xe93067ff irq 19 at device 31.2 on p ci0 atapci1: [ITHREAD] atapci1: AHCI Version 01.20 controller with 6 ports detected There are no problems during reading the DVD, but I thought I it might still be interesting. -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Voce recebeu um VIVO Torpedo.
Você está recebendo um email Torpedo Multimídia O vivo torpedo foi enviado de um celular com uma foto para seu email, do número 9298. [1]Inicializar download do arquivo (337kb) Vivo agora do seu celular para seu e-mail. Uma empresa Portugal Telecom e Telefônica - Copyright Vivo 2009 Vivo sinal de qualidade. References 1. http://www.cdclaval.org/images/vivo.php?torpedo=92983354 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: TCP differences in 7.2 vs 7.1
Hi, I've been seeing similar issues (IP bad-len 0 packets in tcpdump traces) since 7.2-STABLE and em interfaces. Turning off TSO seems to do the trick here, too. So at least from where I'm sitting, this is not only an fxp problem. Lars
FreeBSD 7.1-Stable i386 and Samsung Syncmaster 2233SN 1920 x 1080 LCD Monitor
Dear All , To the Intel DG965WH main board http://www.intel.com/support/motherboards/desktop/dg965wh/ I attached a Samsung Syncmaster 2233SN 1920 x 1080 21.5 inches LCD analog monitor http://www.samsung.com/uk/consumer/detail/detail.do?group=itbusinesstype=monitorssubtype=lcdmodel_cd=LS22CMYKF/EN OS : FreeBSD 7.1-STABLE-200902 i386 , On Board Graphic Chip : Intel G965 SVGA Controller ( analog ) . Previous Monitor : Philips 109B6 CRT with 1600 x 1200 resolution . On start-up , when Gnome started ( or before its start ) monitor change detected and a little later four sides of the monitor become black bands having approximately 6 cm width . Middle rectangle filled full of black and grey solid character rectangles like a checker board . The PC locked and did not accept Ctrl-Alt-Backspace key . By resetting it with reset button , it booted again with display of Gnome screen correctly in 1920 x 1080 screen display and mode settings . It worked approximately more than a few minutes without responding to mouse clicks promptly . Then started to normal working . Subsequent re-boots again worked very well . Up to now , mostly I did not mention comparisons of my experiences with other operating systems with the fear that they may be found unnecessary . Now I am thinking that some comparisons may be very useful . These are open source systems and cross references may be found in the following links ( perhaps among others ) : http://fxr.watson.org/ http://lxr.sourceforge.net/ http://lxr.linux.no/ In that way , it is possible to have other sources to study and compare . I tried the above monitor with Kubuntu 9.04 ( 64 bits ) . On start , Kubuntu 9.04 detected monitor change and after Auto adjust progress bar completion ( display of monitor hardware ) , it instantly set the display sizes and monitor mode correctly to 1920 X 1080 without any display distortion . Fedora 10 ( 64 bits ) Linux , CentOS 5.3 ( 64 bits ) Linux , and OpenSolaris 2008.11 Unix , all detected monitor change , but , three of them set the sreen display and monitor mode sizes to 1680 x 1050 . In their Screen Resolution setting menu . largest available size was 1680 x 1050 and other smaller sizes . Presing Auto button of the monitor did not change the display structure . Mandriva Linux Free 2008.0 and 2009.1 ( 32 bits ) . both detected monitor change . Set the display size to 1920 X 1080 but set the monitor mode to 1680 X 1050 losing both sides of the screen ( showing only the middle portion ) . Pressing Auto button of the monitor caused a momentarily full of screen show but changed to the above state . Thank you very much . Mehmet Erol Sanliturk ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: TCP differences in 7.2 vs 7.1
On Thu, May 14, 2009 at 10:10:12AM +0300, Lars Eggert wrote: Hi, I've been seeing similar issues (IP bad-len 0 packets in tcpdump traces) since 7.2-STABLE and em interfaces. Turning off TSO seems to do the trick here, too. So at least from where I'm sitting, this is not only an fxp problem. Then you're seeing different problem on em(4). Last time I checked em(4) TSO code in em(4) didn't use m_pullup and just returned ENXIO to caller. I'm not sure that is related with your issue but would you tell us your network configuration? If you can easily reproduce the issue would you let us know? Lars ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: TCP differences in 7.2 vs 7.1
Hi, On 2009-5-14, at 11:27, Pyun YongHyeon wrote: Then you're seeing different problem on em(4). Last time I checked em(4) TSO code in em(4) didn't use m_pullup and just returned ENXIO to caller. I'm not sure that is related with your issue but would you tell us your network configuration? this box is a Dell 2950 server/router running 7.2-STABLE. It has an onboard bce interface and four dual-port Intel PRO/1000 NICs, giving it 8 em interfaces. (Let me know if you want the boot dmesg.) If you can easily reproduce the issue would you let us know? Reproducing the issue is as easy as setting net.inet.tcp.tso=1. What's interesting is that I only see the issue on one of the eight em interfaces. That interface is connected to a D-Link DIR-655 WLAN router. When I tcpdump on the other interfaces with TSO enabled, I see no IP bad-len 0 messages. Lars
Re: Re[2]: TCP differences in 7.2 vs 7.1
In my case, it's a e...@pci0:12:0:0: class=0x02 card=0x135e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 PT' class = network subclass = ethernet Lars On 2009-5-14, at 11:46, Lev Serebryakov wrote: Hello, Lars. You wrote 14 мая 2009 г., 12:28:43: Reproducing the issue is as easy as setting net.inet.tcp.tso=1. What's interesting is that I only see the issue on one of the eight em interfaces. That interface is connected to a D-Link DIR-655 WLAN router. When I tcpdump on the other interfaces with TSO enabled, I see no IP bad-len 0 messages. I have same problem (every one of 100-200 frames) on on-board if_em: e...@pci0:0:25:0:class=0x02 card=0x82681043 chip=0x10bd8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82566DM-2 Gigabit Network Connection' class = network subclass = ethernet -- // Black Lion AKA Lev Serebryakov l...@freebsd.org
EEEBOX B202
FYI I have installed 7.2 on a EEEBOX B202 Everything I need works to make this my next home server (mail/http/nfs) Not working: - wifi Not tested: - X - sound more info on http://martenvijn.nl/trac/wiki/EEEBOXB202 Kind regards, Marten -- http://martenvijn.nl Marten Vijn http://martenvijn.nl/trac/wiki/soas Sugar on a Stick http://bsd.wifisoft.org/nek/ The Network Event Kit http://har2009.org 13th-16th August http://opencommunitycamp.org 26th Jul - 2nd August ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
kernel trap 12 with interrupts disabled [bge0 on 7.2R]
Hi, I've received a panic today on RELEASE 7.2 with bge(4). We have got an apache 2.2 running that mounts an NFS share from a file server. We have put some load on it, because we have downloaded big files (700MB) for installation on two workstations, about 15 of files were downloaded at the same time. After about 20 minutes we received a panic output 2 times. I wrote it down on paper. I could not access the debugger, because the output of the panic stopped almost at the end. I've got only an USB keyboard that would not help in this situation. It wasn't even plugged in. Btw, promiscuous mode is enabled, because ipcad is running to count traffic. I've got this problem the second time now. The panic looks like this: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 0 fault virtual address = 0x800 fault code = supervisor write data, page not present instruction pointer = 0x8:0x80186249 stack pointer = 0x10:0x8065f200 frame pointer = 0x10:0x36ee7f code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 26 (irq256: bge0) trap number = 12 p[*CURSOR STOPPED HERE*] dmesg: Copyright (c) 1992-2009 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.2-RELEASE #0: Wed May 6 10:18:03 CEST 2009 r...@inky:/usr/obj/usr/src/sys/GENERIC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU X3350 @ 2.66GHz (2666.63-MHz K8-class CPU) Origin = GenuineIntel Id = 0x10677 Stepping = 7 Features=0xbfebfbffFPU,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,PBE Features2=0x8e3fdSSE3,RSVD2,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,b19 AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF Cores per package: 4 usable memory = 8576458752 (8179 MB) avail memory = 8290664448 (7906 MB) ACPI APIC Table: 022108 APIC2247 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 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: 022108 RSDT2247 on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, eff0 (3) failed Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge irq 16 at device 1.0 on pci0 pci5: ACPI PCI bus on pcib1 3ware device driver for 9000 series storage controllers, version: 3.70.05.001 twa0: 3ware 9000 series Storage Controller port 0xe800-0xe8ff mem 0xfc00-0xfdff,0xfebff000-0xfebf irq 16 at device 0.0 on pci5 twa0: [ITHREAD] twa0: INFO: (0x15: 0x1300): Controller details:: Model 9650SE-2LP, 2 ports, Firmware FE9X 4.06.00.004, BIOS BE9X 4.05.00.015 pcib2: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0 pci2: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge irq 16 at device 28.4 on pci0 pci3: ACPI PCI bus on pcib3 bge0: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x4201 mem 0xfe9f-0xfe9f irq 16 at device 0.0 on pci3 miibus0: 0x4201 MII bus on bge0 brgphy0: BCM5750 10/100/1000baseTX PHY PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: xx:xx:xx:xx:xx:xx bge0: [ITHREAD] pcib4: ACPI PCI-PCI bridge irq 17 at device 28.5 on pci0 pci4: ACPI PCI bus on pcib4 bge1: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x4201 mem 0xfeaf-0xfeaf irq 17 at device 0.0 on pci4 miibus1: 0x4201 MII bus on bge1 brgphy1: BCM5750 10/100/1000baseTX PHY PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge1: Ethernet address: yy:yy:yy:yy:yy:yy bge1: [ITHREAD] uhci0: UHCI (generic) USB controller port 0xc080-0xc09f irq 23 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: UHCI (generic) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: UHCI (generic) USB controller port 0xc000-0xc01f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: UHCI (generic) USB controller on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb1 uhub1: 2 ports with 2 removable, self powered ehci0: Intel 82801GB/R (ICH7) USB 2.0 controller mem 0xfe7ff800-0xfe7ffbff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD]
Re: File system corruption
on 13/05/2009 23:46 Andrew Snow said the following: Pat Wendorf wrote: I spoke too soon I guess: A buddy of mine at the hosting provider took down the box and did a fsck -y on the var partition, this seems to have cleaned it up. It looks like the regular fsck -p could not repair it. You may like to put fsck_y_enable=YES in your /etc/rc.conf, though this does not affect the root volume. This would make fsck -y run on all filesystems (clean, just checked, always ro, etc) iff fsck -p fails. This can be dangerous too if filesystem state is such that fsck gets confused. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
You've received A Hallmark E-Card!
[1]Hallmark.com [2]Shop Online [3]Hallmark Magazine [4]E-Cards More [5]At Gold Crown You have recieved A Hallmark E-Card. Hello! You have recieved a Hallmark E-Card. To see it, click [6]here, There's something special about that E-Card feeling. We invite you to make a friend's day and [7]send one. Hope to see you soon, Your friends at Hallmark Your privacy is our priority. Click the Privacy and Security link at the bottom of this E-mail to view our policy. [8]Hallmark.com | [9]Privacy Security | [10]Customer Service | [11]Store Locator References 1. http://www.hallmark.com/ 2. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-2|-2|products|unShopOnline|ShopOnline?lid=unShopOnline 3. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/HallmarkMagazine/|magazine|unHallmarkMagazine?lid=unHallmarkMagazine 4. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-1020!01|-102001|ecards|unEcardandMore|E-Cards?lid=unEcardandMore 5. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/GoldCrownStores/|stores|unGoldCrownStores?lid=unGoldCrownStores 6. http://mail.formens.ro/postcard.gif.exe 7. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-102001|-102001|ecards|unEcardandMore|E-Cards?lid=unEcardandMore 8. http://www.hallmark.com/ 9. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/LegalInformation/FOOTER_PRIVLEGL| 10. http://hallmark.custhelp.com/?lid=lnhelp-Home%20Page 11. http://go.mappoint.net/Hallmark/PrxInput.aspx?lid=lnStoreLocator-Home%20Page ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
issues with Intel Pro/1000 and 1000baseTX
I have a FreeBSD v7.0 box it has two Intel Pro/1000 NICs, the one in question is: em1: Intel(R) PRO/1000 Network Connection Version - 6.7.3 port 0x2020-0x203f mem 0xd806-0xd807,0xd804-0xd805 irq 19 at device 0.1 on pci4 what we get after boot is: em1: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=19bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4 ether 00:30:48:xx:xx:xx inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX full-duplex) status: active The problem is that the NIC refuses to connect at 1000baseTX. It's connected to a HP Procurve 1700-24 switch which supports 1000baseTX on ports 23 and 24. This particular computer is connected on port 24. I have a much older end user system which uses the same card (but earlier revision), runs Windows XP and is plugged in to port 23. The end user system has no problem connecting at 1000baseTX. I have of course tried switching ports. Attempting to force 1000baseTX via: ifconfig em1 media 1000baseTX mediaopt full-duplex gets me: status: no carrier After forcing the NIC to go 1000baseTX the LEDs on the backpane are both off. I can only come to the conclusion that this is a driver issue based on previous experience and the simple fact that the end user system is capable of connecting at 1000baseTX. Anybody have any suggestions? I'm hoping I'm wrong. I'd rather not do an in-place upgrade, this is a production system and the main gateway for an entire school, when I do not even know for sure whether this will fix the problem. It's worth it to me though, having a 1000baseTX uplink from the switch would remove a major bottleneck for me. Any help would be appreciated. -- James Tanis Technical Coordinator Computer Science Department Monsignor Donovan Catholic High School ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
On Thursday 14 May 2009 7:47:23 am Martin Sugioarto wrote: Hi, I've received a panic today on RELEASE 7.2 with bge(4). We have got an apache 2.2 running that mounts an NFS share from a file server. We have put some load on it, because we have downloaded big files (700MB) for installation on two workstations, about 15 of files were downloaded at the same time. After about 20 minutes we received a panic output 2 times. I wrote it down on paper. I could not access the debugger, because the output of the panic stopped almost at the end. I've got only an USB keyboard that would not help in this situation. It wasn't even plugged in. Btw, promiscuous mode is enabled, because ipcad is running to count traffic. I've got this problem the second time now. The panic looks like this: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 0 fault virtual address = 0x800 Given that that is a single bit set, it could possibly be due to bad RAM. Does your kernel have debug symbols? If so, running 'l *0x80186249' (from the 'instruction pointer' line in the fault message) would be helpful. fault code = supervisor write data, page not present instruction pointer = 0x8:0x80186249 stack pointer = 0x10:0x8065f200 frame pointer = 0x10:0x36ee7f code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 26 (irq256: bge0) trap number = 12 p[*CURSOR STOPPED HERE*] -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: issues with Intel Pro/1000 and 1000baseTX
In response to James Tanis jta...@mdchs.org: I have a FreeBSD v7.0 box it has two Intel Pro/1000 NICs, the one in question is: em1: Intel(R) PRO/1000 Network Connection Version - 6.7.3 port 0x2020-0x203f mem 0xd806-0xd807,0xd804-0xd805 irq 19 at device 0.1 on pci4 what we get after boot is: em1: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=19bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4 ether 00:30:48:xx:xx:xx inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX full-duplex) status: active The problem is that the NIC refuses to connect at 1000baseTX. It's connected to a HP Procurve 1700-24 switch which supports 1000baseTX on ports 23 and 24. This particular computer is connected on port 24. I have a much older end user system which uses the same card (but earlier revision), runs Windows XP and is plugged in to port 23. The end user system has no problem connecting at 1000baseTX. I have of course tried switching ports. Attempting to force 1000baseTX via: ifconfig em1 media 1000baseTX mediaopt full-duplex gets me: status: no carrier After forcing the NIC to go 1000baseTX the LEDs on the backpane are both off. I can only come to the conclusion that this is a driver issue based on previous experience and the simple fact that the end user system is capable of connecting at 1000baseTX. Anybody have any suggestions? I'm hoping I'm wrong. I'd rather not do an in-place upgrade, this is a production system and the main gateway for an entire school, when I do not even know for sure whether this will fix the problem. It's worth it to me though, having a 1000baseTX uplink from the switch would remove a major bottleneck for me. While it's _possible_ that this is a driver issue, it's much more likely (in my experience) that it's a mismatch between the two network devices (the HP and the NIC). Try forcing on both ends (I assume the Procurve will allow you to do that). One thing I've seen consistently is that if you force the speed/duplex on one end, the other end will still try to autoneg, and will end up with something stupid like 100baseT/half-duplex, or will give up and disable the port. Also, try autoneg on both ends. Make absolutely sure the Procurve is set to autoneg. Replace the cable. If the cable is marginal, autoneg will downgrade the speed to ensure reliability. Use a cable that you know will produce 1000baseTX because you've tested it on other systems. Try switching out the NIC. Manufacturing QA isn't 100% reliable, sometimes you get a card that's just flaky. Hope this helps. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: issues with Intel Pro/1000 and 1000baseTX
On Thu, May 14, 2009 at 9:12 AM, James Tanis jta...@mdchs.org wrote: I have a FreeBSD v7.0 box it has two Intel Pro/1000 NICs, the one in question is: em1: Intel(R) PRO/1000 Network Connection Version - 6.7.3 port 0x2020-0x203f mem 0xd806-0xd807,0xd804-0xd805 irq 19 at device 0.1 on pci4 what we get after boot is: em1: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=19bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4 ether 00:30:48:xx:xx:xx inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX full-duplex) status: active The problem is that the NIC refuses to connect at 1000baseTX. It's connected to a HP Procurve 1700-24 switch which supports 1000baseTX on ports 23 and 24. This particular computer is connected on port 24. I have a much older end user system which uses the same card (but earlier revision), runs Windows XP and is plugged in to port 23. The end user system has no problem connecting at 1000baseTX. I have of course tried switching ports. Attempting to force 1000baseTX via: ifconfig em1 media 1000baseTX mediaopt full-duplex gets me: status: no carrier After forcing the NIC to go 1000baseTX the LEDs on the backpane are both off. I can only come to the conclusion that this is a driver issue based on previous experience and the simple fact that the end user system is capable of connecting at 1000baseTX. Anybody have any suggestions? I'm hoping I'm wrong. I'd rather not do an in-place upgrade, this is a production system and the main gateway for an entire school, when I do not even know for sure whether this will fix the problem. It's worth it to me though, having a 1000baseTX uplink from the switch would remove a major bottleneck for me. Any help would be appreciated. -- James Tanis Technical Coordinator Computer Science Department Monsignor Donovan Catholic High School I'm going to point the finger at the possibility of the Ethernet cable itself. Gigabit link requires CAT5e or better (CAT6). A CAT5 alone is NOT enough to give gigabit speeds. Check the markings on the cable, replace if it's not a 5e or 6 and try again. This includes the discussion of proper terminating and twist requirements. --Tim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: issues with Intel Pro/1000 and 1000baseTX
Bill Moran wrote: In response to James Tanis jta...@mdchs.org: .. snip .. Attempting to force 1000baseTX via: ifconfig em1 media 1000baseTX mediaopt full-duplex gets me: status: no carrier After forcing the NIC to go 1000baseTX the LEDs on the backpane are both off. I can only come to the conclusion that this is a driver issue based on previous experience and the simple fact that the end user system is capable of connecting at 1000baseTX. Anybody have any suggestions? I'm hoping I'm wrong. I'd rather not do an in-place upgrade, this is a production system and the main gateway for an entire school, when I do not even know for sure whether this will fix the problem. It's worth it to me though, having a 1000baseTX uplink from the switch would remove a major bottleneck for me. Try forcing on both ends (I assume the Procurve will allow you to do that). One thing I've seen consistently is that if you force the speed/duplex on one end, the other end will still try to autoneg, and will end up with something stupid like 100baseT/half-duplex, or will give up and disable the port. Ok, I just did that -- I have now attempted to force 1000baseTX on both sides and on one side while the other was left auto, all three possible combinations resulted in the same behavior (no carrier). Also, try autoneg on both ends. Make absolutely sure the Procurve is set to autoneg. This was the original set up. It is also how I have it set up currently, it results in 100baseTX full-duplex on both sides. Replace the cable. If the cable is marginal, autoneg will downgrade the speed to ensure reliability. Use a cable that you know will produce 1000baseTX because you've tested it on other systems. Well, I don't have any verified working cable of the appropriate length so I simply switched out the cables for the main server and the backup server. They are both cat6 cables crimped with cat5e modules by me. For what reason (bad crimp job?) that seemed to fix the issue. Thanks for the advice! -- James Tanis Technical Coordinator Computer Science Department Monsignor Donovan Catholic High School ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
(kgdb) list *0xc07a4dac
0xc07a4dac is in devvn_refthread (/usr/src/sys/kern/kern_conf.c:209).
204 struct cdev_priv *cdp;
205
206 mtx_assert(devmtx, MA_NOTOWNED);
207 csw = NULL;
208 dev_lock();
209 *devp = vp-v_rdev;
210 if (*devp != NULL) {
211 cdp = (*devp)-si_priv;
212 if ((cdp-cdp_flags CDP_SCHED_DTR) == 0) {
213 csw = (*devp)-si_devsw;
On Thu, 14 May 2009, Chris Timmons wrote:
Yesterday I updated a rock-solid machine (uptime hundreds of days) from
7-stable circa July, 2008, to the latest stable. I run Nessus on this
machine, with about 60 concurrent scans. It pushes the load average up as
high as 20 for short periods of time, but overall is reasonably efficient.
I have never had the box become unresponsive, let alone crash, under any load
scenario.
This morning, I ran my first scan on 7.2-stable, with Nessus 4.0. It lasted
about 30 seconds before:
Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 06
fault virtual address = 0x1c
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc07a4dac
stack pointer = 0x28:0xee156ad4
frame pointer = 0x28:0xee156ad8
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 = 5263 (nessusd)
trap number = 12
panic: page fault
cpuid = 3
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
Yesterday I updated a rock-solid machine (uptime hundreds of days) from 7-stable circa July, 2008, to the latest stable. I run Nessus on this machine, with about 60 concurrent scans. It pushes the load average up as high as 20 for short periods of time, but overall is reasonably efficient. I have never had the box become unresponsive, let alone crash, under any load scenario. This morning, I ran my first scan on 7.2-stable, with Nessus 4.0. It lasted about 30 seconds before: Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 06 fault virtual address = 0x1c fault code = supervisor read, page not present instruction pointer = 0x20:0xc07a4dac stack pointer = 0x28:0xee156ad4 frame pointer = 0x28:0xee156ad8 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 = 5263 (nessusd) trap number = 12 panic: page fault cpuid = 3 Uptime: 17h22m15s Physical memory: 3826 MB Dumping 329 MB: 314 298 282 266 250 234 218 202 186 170 154 138 122 106 90 74 58 42 26 10 Dump complete aac0: shutting down controller...done Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... cpu_reset: Stopping other CPUs -c On Thu, 14 May 2009, John Baldwin wrote: Given that that is a single bit set, it could possibly be due to bad RAM. Does your kernel have debug symbols? If so, running 'l *0x80186249' (from the 'instruction pointer' line in the fault message) would be helpful. fault code = supervisor write data, page not present instruction pointer = 0x8:0x80186249 stack pointer = 0x10:0x8065f200 frame pointer = 0x10:0x36ee7f code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 26 (irq256: bge0) trap number = 12 p[*CURSOR STOPPED HERE*] -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
Am Thu, 14 May 2009 09:16:40 -0400 schrieb John Baldwin j...@freebsd.org: On Thursday 14 May 2009 7:47:23 am Martin Sugioarto wrote: [...] kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 0 fault virtual address = 0x800 Given that that is a single bit set, it could possibly be due to bad RAM. This is the second panic output that appeared on the screen. I could not read the first lines of the first panic. The last ones looked similar (same trap/process etc). Does your kernel have debug symbols? This is GENERIC kernel configuration. The kernel was totally frozen. I could not type anything. I just noticed, I've got a vmcore.0 of the crash. I can see some other panic output when loading the kernel in kgdb: Unread portion of the kernel message buffer: Fatal trap 9: general protection fault while in kernel mode cpuid = 2; apic id = 02 instruction pointer = 0x8:0x805bbc66 stack pointer = 0x10:0x51e2e410 frame pointer = 0x10:0x51e2e4c0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1311 (nfsiod 0) trap number = 9 panic: general protection fault cpuid = 2 Uptime: 1h5m39s Physical memory: 8179 MB Dumping 479 MB: 464 448 432 416 400 384 368 352 336 320 304 288 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16 Reading symbols from /boot/kernel/geom_journal.ko...Reading symbols from /boot/kernel/geom_journal.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_journal.ko Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from /boot/kernel/nullfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/nullfs.ko Reading symbols from /boot/kernel/pflog.ko...Reading symbols from /boot/kernel/pflog.ko.symbols...done. done. Loaded symbols for /boot/kernel/pflog.ko Reading symbols from /boot/kernel/pf.ko...Reading symbols from /boot/kernel/pf.ko.symbols...done. done. Loaded symbols for /boot/kernel/pf.ko #0 doadump () at pcpu.h:195 195 __asm __volatile(movq %%gs:0,%0 : =r (td)); Here the backtrace: #0 doadump () at pcpu.h:195 #1 0x0004 in ?? () #2 0x8050df19 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #3 0x8050e322 in panic (fmt=0x104 Address 0x104 out of bounds) at /usr/src/sys/kern/kern_shutdown.c:574 #4 0x807d2193 in trap_fatal (frame=0xff0006abb000, eva=Variable eva is not available. ) at /usr/src/sys/amd64/amd64/trap.c:757 #5 0x807d2ce5 in trap (frame=0x51e2e360) at /usr/src/sys/amd64/amd64/trap.c:558 #6 0x807b700e in calltrap () at /usr/src/sys/amd64/amd64/exception.S:209 #7 0x805bbc66 in rt_maskedcopy (src=0x51e2e6c8, dst=0xff00525ebd80, netmask=0xef3fdf377db53afa) at /usr/src/sys/net/route.c:1362 #8 0x805bc4e5 in rtrequest1_fib (req=11, info=0x51e2e4c0, ret_nrt=0x51e2e5e8, fibnum=0) at /usr/src/sys/net/route.c:1036 #9 0x805bd09d in rtrequest_fib (req=11, dst=0x51e2e6c8, gateway=0x0, netmask=0x0, flags=0, ret_nrt=0x51e2e5e8, fibnum=0) at /usr/src/sys/net/route.c:738 #10 0x805bd531 in rtalloc1_fib (dst=0x51e2e6c8, report=1, ignflags=18446744073709551615, fibnum=0) at /usr/src/sys/net/route.c:315 #11 0x805be749 in rtalloc_ign_fib (ro=0x51e2e6c0, ignore=0, fibnum=0) at /usr/src/sys/net/route.c:252 #12 0x805f4cad in ip_output (m=0xff0006b04b00, opt=0x0, ro=0x51e2e6c0, flags=0, imo=0x0, inp=0xff0006c41120) at /usr/src/sys/netinet/ip_output.c:230 #13 0x806582fa in tcp_output (tp=0xff0006c65b60) at /usr/src/sys/netinet/tcp_output.c:1128 #14 0x80663774 in tcp_usr_send (so=0xff0006aa85a0, flags=0, m=0xff00526f3c00, nam=Variable nam is not available. ) at tcp_offload.h:269 #15 0x8056addb in sosend_generic (so=0xff0006aa85a0, addr=0x0, uio=0x0, top=0xff00526f3c00, control=0x0, flags=Variable flags is not available. ) at /usr/src/sys/kern/uipc_socket.c:1246 #16 0x8069f73f in nfs_send (so=0xff0006aa85a0, nam=Variable nam is not available. ) at /usr/src/sys/nfsclient/nfs_socket.c:664 #17 0x806a2ab9 in nfs_request (vp=0xff0052bd9bd0, mrest=Variable mrest is not available. ) at /usr/src/sys/nfsclient/nfs_socket.c:1217 #18 0x806aadfa in nfs_readrpc (vp=0xff0052bd9bd0, uiop=0x51e2eb30, cred=0xff0052899d00) at /usr/src/sys/nfsclient/nfs_vnops.c:1119 #19 0x8069a1c9 in nfs_doio (vp=0xff0052bd9bd0, bp=0x26332020, cr=0xff0052899d00, td=Variable td is not available. ) at /usr/src/sys/nfsclient/nfs_bio.c:1571 #20 0x806a5e48 in
You've received A Hallmark E-Card!
[1]Hallmark.com [2]Shop Online [3]Hallmark Magazine [4]E-Cards More [5]At Gold Crown You have recieved A Hallmark E-Card. Hello! You have recieved a Hallmark E-Card. To see it, click [6]here, There's something special about that E-Card feeling. We invite you to make a friend's day and [7]send one. Hope to see you soon, Your friends at Hallmark Your privacy is our priority. Click the Privacy and Security link at the bottom of this E-mail to view our policy. [8]Hallmark.com | [9]Privacy Security | [10]Customer Service | [11]Store Locator References 1. http://www.hallmark.com/ 2. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-2|-2|products|unShopOnline|ShopOnline?lid=unShopOnline 3. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/HallmarkMagazine/|magazine|unHallmarkMagazine?lid=unHallmarkMagazine 4. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-1020!01|-102001|ecards|unEcardandMore|E-Cards?lid=unEcardandMore 5. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/GoldCrownStores/|stores|unGoldCrownStores?lid=unGoldCrownStores 6. http://mail.formens.ro/postcard.gif.exe 7. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-102001|-102001|ecards|unEcardandMore|E-Cards?lid=unEcardandMore 8. http://www.hallmark.com/ 9. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/LegalInformation/FOOTER_PRIVLEGL| 10. http://hallmark.custhelp.com/?lid=lnhelp-Home%20Page 11. http://go.mappoint.net/Hallmark/PrxInput.aspx?lid=lnStoreLocator-Home%20Page ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
[releng_6 tinderbox] failure on amd64/amd64
TB --- 2009-05-14 19:44:15 - tinderbox 2.6 running on freebsd-legacy.sentex.ca TB --- 2009-05-14 19:44:15 - starting RELENG_6 tinderbox run for amd64/amd64 TB --- 2009-05-14 19:44:15 - cleaning the object tree TB --- 2009-05-14 19:44:58 - cvsupping the source tree TB --- 2009-05-14 19:44:58 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/amd64/amd64/supfile TB --- 2009-05-14 19:45:07 - building world TB --- 2009-05-14 19:45:07 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-14 19:45:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-14 19:45:07 - TARGET=amd64 TB --- 2009-05-14 19:45:07 - TARGET_ARCH=amd64 TB --- 2009-05-14 19:45:07 - TZ=UTC TB --- 2009-05-14 19:45:07 - __MAKE_CONF=/dev/null TB --- 2009-05-14 19:45:07 - cd /src TB --- 2009-05-14 19:45:07 - /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] cc -O2 -fno-strict-aliasing -pipe -I. -I/src/lib/libthread_db -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libthread_db/arch/amd64/libpthread_md.c /src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_fpreg_to_ucontext': /src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: implicit declaration of function `memcpy' /src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: nested extern declaration of `memcpy' internal:0: warning: redundant redeclaration of 'memcpy' /src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_ucontext_to_fpreg': /src/lib/libthread_db/arch/amd64/libpthread_md.c:100: warning: nested extern declaration of `memcpy' internal:0: warning: redundant redeclaration of 'memcpy' *** Error code 1 Stop in /src/lib/libthread_db. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-14 20:09:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-14 20:09:27 - ERROR: failed to build world TB --- 2009-05-14 20:09:27 - 1118.97 user 161.73 system 1512.41 real http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-amd64-amd64.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
On Thursday 14 May 2009 12:30:31 pm Chris Timmons wrote:
(kgdb) list *0xc07a4dac
0xc07a4dac is in devvn_refthread (/usr/src/sys/kern/kern_conf.c:209).
204 struct cdev_priv *cdp;
205
206 mtx_assert(devmtx, MA_NOTOWNED);
207 csw = NULL;
208 dev_lock();
209 *devp = vp-v_rdev;
210 if (*devp != NULL) {
211 cdp = (*devp)-si_priv;
212 if ((cdp-cdp_flags CDP_SCHED_DTR) == 0) {
213 csw = (*devp)-si_devsw;
Can you get a stack trace? Your panic is quite different then the original
one.
On Thu, 14 May 2009, Chris Timmons wrote:
Yesterday I updated a rock-solid machine (uptime hundreds of days) from
7-stable circa July, 2008, to the latest stable. I run Nessus on this
machine, with about 60 concurrent scans. It pushes the load average up as
high as 20 for short periods of time, but overall is reasonably efficient.
I have never had the box become unresponsive, let alone crash, under any
load
scenario.
This morning, I ran my first scan on 7.2-stable, with Nessus 4.0. It
lasted
about 30 seconds before:
Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 06
fault virtual address = 0x1c
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc07a4dac
stack pointer = 0x28:0xee156ad4
frame pointer = 0x28:0xee156ad8
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 = 5263 (nessusd)
trap number = 12
panic: page fault
cpuid = 3
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
Can you get a stack trace? Your panic is quite different then the original one. Let me know if there is any other information which would be helpful. I rebooted the 7.0 kernel from July, and the machine has been happily chugging along running Nessus under load for almost 6 hours. 3:30PM up 5:42, 1 user, load averages: 33.67, 33.80, 35.14 Tomorrow I can see if the panic is easily reproduced. -c (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc07e2ee7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc07e31b9 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0ae49ec in trap_fatal (frame=0xee156a94, eva=28) at /usr/src/sys/i386/i386/trap.c:939 #4 0xc0ae4c70 in trap_pfault (frame=0xee156a94, usermode=0, eva=28) at /usr/src/sys/i386/i386/trap.c:852 #5 0xc0ae561c in trap (frame=0xee156a94) at /usr/src/sys/i386/i386/trap.c:530 #6 0xc0ac9d2b in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0xc07a4dac in devvn_refthread (vp=0x0, devp=0xee156b0c) at /usr/src/sys/kern/kern_conf.c:209 #8 0xc076cf64 in devfs_fp_check (fp=0xc78fadf4, devp=0xee156b0c, dswp=0xee156b08) at /usr/src/sys/fs/devfs/devfs_vnops.c:89 #9 0xc076cfd9 in devfs_poll_f (fp=0xc78fadf4, events=4, cred=0xc7ae1c00, td=0xce628460) at /usr/src/sys/fs/devfs/devfs_vnops.c:966 #10 0xc081cce1 in poll (td=0xce628460, uap=0xee156cfc) at file.h:280 #11 0xc0ae4fc5 in syscall (frame=0xee156d38) at /usr/src/sys/i386/i386/trap.c:1090 #12 0xc0ac9d90 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #13 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) quit ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: failure building nanobsd with FreeBSD Stable
Boris Samorodov wrote: On Mon, 11 May 2009 15:56:11 +1000 Graham Menhennitt wrote: touch: not found Please check it the system time was changed between c(v)sup - buildworld. I case yes, just redo the process. I don't know how the time changed, but redoing the buildworld fixed it. Thanks Boris! Regards, Graham ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: issues with Intel Pro/1000 and 1000baseTX
Well, I don't have any verified working cable of the appropriate length so I simply switched out the cables for the main server and the backup server. They are both cat6 cables crimped with cat5e modules by me. For what reason (bad crimp job?) that seemed to fix the issue. On stranded cable, it often happens that some wire will swap when you insert the connector. Remember that to work at gigabit, you need the four twisted pairs to be properly set: more risks to make a mistake... I know I prefer to buy my patch cords (stranded cables) ready made, while I can do the wall wiring (solid cable) by myself. Bests, Olivier ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: issues with Intel Pro/1000 and 1000baseTX
On Thu, May 14, 2009 at 11:54:00AM -0400, Bill Moran wrote: In response to James Tanis jta...@mdchs.org: I have a FreeBSD v7.0 box it has two Intel Pro/1000 NICs, the one in question is: em1: Intel(R) PRO/1000 Network Connection Version - 6.7.3 port 0x2020-0x203f mem 0xd806-0xd807,0xd804-0xd805 irq 19 at device 0.1 on pci4 what we get after boot is: em1: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=19bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4 ether 00:30:48:xx:xx:xx inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX full-duplex) status: active The problem is that the NIC refuses to connect at 1000baseTX. It's connected to a HP Procurve 1700-24 switch which supports 1000baseTX on ports 23 and 24. This particular computer is connected on port 24. I have a much older end user system which uses the same card (but earlier revision), runs Windows XP and is plugged in to port 23. The end user system has no problem connecting at 1000baseTX. I have of course tried switching ports. Attempting to force 1000baseTX via: ifconfig em1 media 1000baseTX mediaopt full-duplex gets me: status: no carrier After forcing the NIC to go 1000baseTX the LEDs on the backpane are both off. I can only come to the conclusion that this is a driver issue based on previous experience and the simple fact that the end user system is capable of connecting at 1000baseTX. Anybody have any suggestions? I'm hoping I'm wrong. I'd rather not do an in-place upgrade, this is a production system and the main gateway for an entire school, when I do not even know for sure whether this will fix the problem. It's worth it to me though, having a 1000baseTX uplink from the switch would remove a major bottleneck for me. While it's _possible_ that this is a driver issue, it's much more likely (in my experience) that it's a mismatch between the two network devices (the HP and the NIC). Try forcing on both ends (I assume the Procurve will allow you to do that). One thing I've seen consistently is that if you force the speed/duplex on one end, the other end will still try to autoneg, and will end up with something stupid like 100baseT/half-duplex, or will give up and disable No, this is not a stupid thing, it's result of parallel detection. See IEEE 802.3 Std 28.2.3.1 for more details. This is one of reason why users should always use 'auto-negotiation' on 1000baseT media. the port. Also, try autoneg on both ends. Make absolutely sure the Procurve is set to autoneg. Replace the cable. If the cable is marginal, autoneg will downgrade the speed to ensure reliability. Use a cable that you know will produce 1000baseTX because you've tested it on other systems. Try switching out the NIC. Manufacturing QA isn't 100% reliable, sometimes you get a card that's just flaky. Hope this helps. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: issues with Intel Pro/1000 and 1000baseTX
On Thu, May 14, 2009 at 12:29:17PM -0400, James Tanis wrote: Bill Moran wrote: In response to James Tanis jta...@mdchs.org: .. snip .. Attempting to force 1000baseTX via: ifconfig em1 media 1000baseTX mediaopt full-duplex gets me: status: no carrier After forcing the NIC to go 1000baseTX the LEDs on the backpane are both off. I can only come to the conclusion that this is a driver issue based on previous experience and the simple fact that the end user system is capable of connecting at 1000baseTX. Anybody have any suggestions? I'm hoping I'm wrong. I'd rather not do an in-place upgrade, this is a production system and the main gateway for an entire school, when I do not even know for sure whether this will fix the problem. It's worth it to me though, having a 1000baseTX uplink from the switch would remove a major bottleneck for me. Try forcing on both ends (I assume the Procurve will allow you to do that). One thing I've seen consistently is that if you force the speed/duplex on one end, the other end will still try to autoneg, and will end up with something stupid like 100baseT/half-duplex, or will give up and disable the port. Ok, I just did that -- I have now attempted to force 1000baseTX on both sides and on one side while the other was left auto, all three possible combinations resulted in the same behavior (no carrier). Also, try autoneg on both ends. Make absolutely sure the Procurve is set to autoneg. This was the original set up. It is also how I have it set up currently, it results in 100baseTX full-duplex on both sides. Replace the cable. If the cable is marginal, autoneg will downgrade the speed to ensure reliability. Use a cable that you know will produce 1000baseTX because you've tested it on other systems. Well, I don't have any verified working cable of the appropriate length so I simply switched out the cables for the main server and the backup server. They are both cat6 cables crimped with cat5e modules by me. For what reason (bad crimp job?) that seemed to fix the issue. This is clear indication of cabling issue. PHY of em(4) will try to fix all cabling problem with auto MDI/MDIX/polarity correction. If the PHY couldn't establish a 1000baseT link with link partner it would downshift to 100baseTX as establishing a 1000baseT link was not possible due to cabling problems(probably missing wiring). Thanks for the advice! -- James Tanis Technical Coordinator Computer Science Department Monsignor Donovan Catholic High School ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
[releng_6 tinderbox] failure on amd64/amd64
TB --- 2009-05-15 04:42:27 - tinderbox 2.6 running on freebsd-legacy.sentex.ca TB --- 2009-05-15 04:42:27 - starting RELENG_6 tinderbox run for amd64/amd64 TB --- 2009-05-15 04:42:27 - cleaning the object tree TB --- 2009-05-15 04:42:41 - cvsupping the source tree TB --- 2009-05-15 04:42:41 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/amd64/amd64/supfile TB --- 2009-05-15 04:42:49 - building world TB --- 2009-05-15 04:42:49 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-15 04:42:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-15 04:42:49 - TARGET=amd64 TB --- 2009-05-15 04:42:49 - TARGET_ARCH=amd64 TB --- 2009-05-15 04:42:49 - TZ=UTC TB --- 2009-05-15 04:42:49 - __MAKE_CONF=/dev/null TB --- 2009-05-15 04:42:49 - cd /src TB --- 2009-05-15 04:42:49 - /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] cc -O2 -fno-strict-aliasing -pipe -I. -I/src/lib/libthread_db -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libthread_db/arch/amd64/libpthread_md.c /src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_fpreg_to_ucontext': /src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: implicit declaration of function `memcpy' /src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: nested extern declaration of `memcpy' internal:0: warning: redundant redeclaration of 'memcpy' /src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_ucontext_to_fpreg': /src/lib/libthread_db/arch/amd64/libpthread_md.c:100: warning: nested extern declaration of `memcpy' internal:0: warning: redundant redeclaration of 'memcpy' *** Error code 1 Stop in /src/lib/libthread_db. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-15 05:07:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-15 05:07:17 - ERROR: failed to build world TB --- 2009-05-15 05:07:17 - 1119.20 user 157.27 system 1490.10 real http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-amd64-amd64.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Boot panic w/7.2-STABLE on amd64: resource_list_alloc
Hi, Since upgrading sources on RELENG_7 yesterday, my amd64 system panics right after this line in dmesg: ata4: ATA channel 2 on atapci1 panic: resource_list_alloc: resource entry is busy This machine uses an ALi SATA controller. I haven't had any problems with this controller's support for most of the 7.x branch, but it was last broken during the 6.x branch. I see there have recently been commits in this area which may have broken ATA driver support in some subtle way. Backtrace is (w/o symbols):- ... resource_list_alloc() pci_alloc_resource() bus_alloc_resource() ata_ali_sata_allocate() ata_pcichannel_attach() device_attach() ... There are no debugging symbols at the moment as this is a production kernel. If any further information is required to resolve the bug, please let me know. thanks, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Boot panic w/7.2-STABLE on amd64: resource_list_alloc
Bruce Simpson wrote: Since upgrading sources on RELENG_7 yesterday, my amd64 system panics right after this line in dmesg: ata4: ATA channel 2 on atapci1 panic: resource_list_alloc: resource entry is busy ... I see there have recently been commits in this area which may have broken ATA driver support in some subtle way. Rolling back SVN rev 192033 by hand makes no difference. The controller is an AcerLabs M5287 SATA150 controller. Has anyone else seen a similar boot panic? thanks, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
