Re: IPv4 vs. IPv6 Ethernet Performance
On Thu, Aug 30, 2012 at 5:06 PM, Norbert Aschendorff wrote: > I tested it using tcpdump: http://nopaste.info/9394068f54_nl.html > The length field says for each packet 1408 bytes, so that should be OK. > TCP the packet size is OK (MSS negociated), it's in IPv6 UDP mode that iperf have a problem with the default packet size: "iperf -V -u -c desthost" "tcpdump host desthost" output (notice the frag and default length): 00:08:33.256304 IP6 (flowlabel 0x09036, hlim 64, next-header Fragment (44) payload length: 1440) 2001:db8::1 > 2001:db8::2: frag (0x3c8d768a:0|1432) 39065 > commplex-link: UDP, length 1470 00:08:33.256307 IP6 (flowlabel 0x09036, hlim 64, next-header Fragment (44) payload length: 54) 2001:db8::1 > 2001:db8::2: frag (0x3c8d768a:1432|46) 00:08:33.256317 IP6 (flowlabel 0x09036, hlim 64, next-header Fragment (44) payload length: 1440) 2001:db8::1 > 2001:db8::2: frag (0x6f6f083c:0|1432) 39065 > commplex-link: UDP, length 1470 00:08:33.256320 IP6 (flowlabel 0x09036, hlim 64, next-header Fragment (44) payload length: 54) 2001:db8::1 > 2001:db8::1: frag (0x6f6f083c:1432|46) Regards, 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: IPv4 vs. IPv6 Ethernet Performance
On Wed, Aug 29, 2012 at 8:14 PM, Norbert Aschendorff wrote: > This confirms the FreeBSD IPv6 receive rate measured with Linux as > sender (iperf client). > Hi, Last time I've played with IPerf and IPV6 between my FreeBSD machines, he didn't take care of the IPv6 Ethernet MTU (1480 and not 1500), neither the IPv6 size header and send 1470 bytes datagrams in place of 1430 bytes datagrams: All my IPerf generated IPv6 packets were fragmented, and this fragmentation reduce a lot's the throughput in IPv6 mode. Can you check if this problem was fixed ? Regards, 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: Geom label lost after expanding partition
On Thu, Aug 16, 2012 at 6:30 PM, Kevin Oberman wrote: > I have a GPT formatted disk where I recently expanded the size of a > partition. I used "gpart resize -i 6 ada1" first to expand the > partition to use the remaining free space and then growfs to modify > the FFS file system to use the full partition. This was all done in > single-user mode, of course, but when I enter "exit" to bring the > system up, it failed to mount /usr. This was because /dev/ufs/usr did > not exist! I've met the same problem, check this PR for a dirty workaround: http://www.freebsd.org/cgi/query-pr.cgi?pr=165962 Regards, 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"
Problem for compiling net-mgmt/net-snmp (sctp related) in 9-stable
Hi all, I've got a problem with 9-stable and sctp since the 20 july (seems related to SVN rev 238613 on 2012-07-19 09:32:59Z by tuexen) : If I put this date in my csup config file: src-all tag=RELENG_9 "date=2012.07.19.00.00.00" => After a csup/rebuild-insall world (without sctp in my kernel config file), I've got no problem for building net-mgmt/net-snmp But if I increment one day in my csup config file: src-all tag=RELENG_9 "date=2012.07.20.00.00.00" This update changes only theses files: Updating collection src-all/cvs Edit src/sys/netinet/sctp_asconf.c Edit src/sys/netinet/sctp_output.c Edit src/sys/netinet/sctp_uio.h Edit src/sys/netinet/sctp_usrreq.c Edit src/sys/netinet6/sctp6_usrreq.c Edit src/usr.bin/netstat/Makefile Edit src/usr.bin/netstat/sctp.c => After a new csup/rebuild+install world (still without sctp in my kernel config file), I can't no more compile net-mgmt/net-snmp. The error message is: sctp-mib/sctpTables_freebsd.c: In function 'parse_assoc_local_addresses': sctp-mib/sctpTables_freebsd.c:40: error: 'union sctp_sockstore' has no member named 'sin' sctp-mib/sctpTables_freebsd.c: In function 'parse_remaddr_xraddr': sctp-mib/sctpTables_freebsd.c:157: error: 'union sctp_sockstore' has no member named 'sin' *** [sctp-mib/sctpTables_freebsd.lo] Error code 1 Can someone check the problem ? Thanks, 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"
cpio and directory owner preservation behaviour
Hi all, I meet a problem with cpio and I would to know if it's a normal behaviour or a bug. I would to save some files and create directories if needed with owner and permission kept. here is an example with net/quagga: I would to save /usr/local/etc/quagga/ripd.conf and creating needed directory in /tmp [root@R3]/#ls -alh /usr/local/etc | grep quagga drwxr-xr-x 2 quagga quagga 512B Sep 22 15:28 quagga [root@R3]/#ls -alh /usr/local/etc/quagga/ripd.conf -rw--- 1 quagga quagga 134B Sep 22 15:28 quagga/ripd.conf [root@R3]/#(cd /usr/local/etc; find . -name ripd.conf -type f | cpio -dumpv /tmp/) The file owner and permission for ripd.conf is keept: [root@R3]/#ls -alh /tmp/quagga/ripd.conf -rw--- 1 quagga quagga 134B Sep 22 15:28 /tmp/quagga/ripd.conf But not the directory owner that is changed to root:wheel [root@R3]/#ls -alh /tmp | grep quagga drwxr-xr-x 2 root wheel 512B Sep 22 16:41 quagga Is a cpio bug ? Thanks, 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: problems booting 8.x kernel
On Mon, Mar 14, 2011 at 11:06 AM, Mike Scott wrote: > > Basically, I'm finding that the 8.1 and 8.2 kernels hang on certain machines > during bootup, specifically during device discover and module load. I've > tried 8.2 off the current release CD, and also 8.1 off the Debian kfreebsd > 6.0.0 distribution - both have the same issue. > I've got the same problem with one motherboard (Asus K8N7-E deluxe): Since FreeBSD 8.0, there is an ACPI bug (pr 142263) in the FreeBSD kernel that detect wrong address for all devices. As example, here is an extract of the dmesg on FreeBSD 7.2: nfe0: port 0xb000-0xb007 mem 0xd300-0xd3000fff irq 21 at device 10.0 on pci0 nfe0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xd300 But, since FreeBSD 8.0, the dmesg report this (note the reserved mem diff): nfe0: irq 21 at device 10.0 on pci0 nfe0: Lazy allocation of 0x100 bytes rid 0x10 type 3 at 0x8100 nfe0: Reserved 0x100 bytes for rid 0x10 type 3 at 0x8100! Try to boot by disabling ACPI into the FreeBSD boot screen… This solve the problem on my motherboard. Regards, 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: Regression with iwn drivers (4965BGN) in 8.2-PRERELEASE ?
2011/1/6 Bernhard Schmidt : > > What do you mean with 'unusable' exactly? Lots of packet loss, or just slow > transfer rates? 'wlandebug +rate' might shed some light on this one. Hi, it's just very slow transfer rates. I didn't know wlandebug, thanks for the tips. Here are the result just after a boot, during pinging my gateway (few traffic): Jan 6 11:02:25 d630 kernel: wlan0: [3a:41:c4:e3:1e:18] AMRR increasing rate 48 (txcnt=11 retrycnt=0) Jan 6 11:02:36 d630 kernel: wlan0: [3a:41:c4:e3:1e:18] AMRR increasing rate 72 (txcnt=11 retrycnt=0) Jan 6 11:03:02 d630 kernel: wlan0: [3a:41:c4:e3:1e:18] AMRR increasing rate 96 (txcnt=11 retrycnt=0) Now, I start xorg and a start a browser: Jan 6 11:04:04 d630 kernel: wlan0: [3a:41:c4:e3:1e:18] AMRR decreasing rate 72 (txcnt=11 retrycnt=10) Jan 6 11:04:09 d630 kernel: wlan0: [3a:41:c4:e3:1e:18] AMRR decreasing rate 48 (txcnt=13 retrycnt=7) Jan 6 11:04:10 d630 kernel: wlan0: [3a:41:c4:e3:1e:18] AMRR decreasing rate 36 (txcnt=43 retrycnt=24) Jan 6 11:04:11 d630 kernel: wlan0: [3a:41:c4:e3:1e:18] AMRR decreasing rate 24 (txcnt=84 retrycnt=38) Jan 6 11:04:12 d630 kernel: wlan0: [3a:41:c4:e3:1e:18] AMRR decreasing rate 22 (txcnt=25 retrycnt=9) Jan 6 11:04:12 d630 kernel: wlan0: [3a:41:c4:e3:1e:18] AMRR decreasing rate 18 (txcnt=31 retrycnt=11) Jan 6 11:04:13 d630 kernel: wlan0: [3a:41:c4:e3:1e:18] AMRR decreasing rate 12 (txcnt=29 retrycnt=11) Jan 6 11:04:13 d630 kernel: wlan0: [3a:41:c4:e3:1e:18] AMRR decreasing rate 11 (txcnt=53 retrycnt=28) Jan 6 11:04:18 d630 kernel: wlan0: [3a:41:c4:e3:1e:18] AMRR decreasing rate 4 (txcnt=17 retrycnt=7) Jan 6 11:04:20 d630 kernel: wlan0: [3a:41:c4:e3:1e:18] AMRR decreasing rate 2 (txcnt=11 retrycnt=10) Jan 6 11:06:07 d630 wpa_supplicant[413]: CTRL-EVENT-SCAN-RESULTS Jan 6 11:09:48 d630 kernel: wlan0: [3a:41:c4:e3:1e:18] AMRR increasing rate 4 (txcnt=11 retrycnt=0) Jan 6 11:09:57 d630 kernel: wlan0: [3a:41:c4:e3:1e:18] AMRR increasing rate 11 (txcnt=11 retrycnt=0) Jan 6 11:10:30 d630 kernel: wlan0: [3a:41:c4:e3:1e:18] AMRR increasing rate 12 (txcnt=11 retrycnt=0) Jan 6 11:10:38 d630 kernel: wlan0: [3a:41:c4:e3:1e:18] AMRR decreasing rate 11 (txcnt=35 retrycnt=16) Jan 6 11:10:43 d630 kernel: wlan0: [3a:41:c4:e3:1e:18] AMRR decreasing rate 4 (txcnt=11 retrycnt=4) Jan 6 11:11:04 d630 kernel: wlan0: [3a:41:c4:e3:1e:18] AMRR increasing rate 11 (txcnt=11 retrycnt=0) Jan 6 11:11:09 d630 wpa_supplicant[413]: CTRL-EVENT-SCAN-RESULTS Jan 6 11:11:09 d630 kernel: wlan0: [3a:41:c4:e3:1e:18] AMRR decreasing rate 4 (txcnt=11 retrycnt=4) The rate decrease too much for using a browser (but I can still ping my gateway)… Regards, 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"
Regression with iwn drivers (4965BGN) in 8.2-PRERELEASE ?
Hi all, Since I've upgraded from 8.1 to 8.2RC, my wireless negotiated speed is very very slow (more exactly it start at normal speed, but decrease each second still stopping a 1Mbps and became unusuable). I'm using iwn drivers: iwn0: mem 0xf6cfe000-0xf6cf irq 17 at device 0.0 on pci12 iwn0: MIMO 2T3R, MoW2, address 00:1d:e0:72:10:01 iwn0: [ITHREAD] iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps [r...@d630]~#uname -a FreeBSD d630.bsdrp.net 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #1: Sun Jan 2 01:32:14 CET 2011 r...@d630.bsdrp.net:/usr/obj/usr/src/sys/GENERIC amd64 Does anybody else meet the same problem ? Thanks, 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: iwn firmware instability with an up-to-date stable kernel
2010/4/18 Bernhard Schmidt : > Are you able to reproduce this on demand? As in type a few commands and > the firmware error occurs? > No, I'm not able to reproduce on demand this problem. Regards, 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"
iwn firmware instability with an up-to-date stable kernel
Hi, I meet instability with an up-to-date stable 8 kernel and iwn drivers: About twice a day, my wireless connection hang and I've this error message in dmesg: firmware error log: error type = "NMI_INTERRUPT_WDG" (0x0004) program counter = 0x046C source line = 0x00D0 error data = 0x00020703 branch link = 0x50F204C2 interrupt link = 0x06DE18B8 time= 2103860338 driver status: tx ring 0: qid=0 cur=19 queued=0 tx ring 1: qid=1 cur=0 queued=0 tx ring 2: qid=2 cur=0 queued=0 tx ring 3: qid=3 cur=2 queued=0 tx ring 4: qid=4 cur=234 queued=0 tx ring 5: qid=5 cur=0 queued=0 tx ring 6: qid=6 cur=0 queued=0 tx ring 7: qid=7 cur=0 queued=0 tx ring 8: qid=8 cur=0 queued=0 tx ring 9: qid=9 cur=0 queued=0 tx ring 10: qid=10 cur=0 queued=0 tx ring 11: qid=11 cur=0 queued=0 tx ring 12: qid=12 cur=0 queued=0 tx ring 13: qid=13 cur=0 queued=0 tx ring 14: qid=14 cur=0 queued=0 tx ring 15: qid=15 cur=0 queued=0 rx ring: cur=52 Does anyone meet the same problem ? More information about my kernel and device (Dell Latitude D630): uname -a FreeBSD d630.bsdrp.net 8.0-STABLE FreeBSD 8.0-STABLE #66: Tue Apr 13 02:16:26 CEST 2010 r...@d630.bsdrp.net:/usr/obj/usr/src/sys/DellD630 amd64 dmesg iwn0: mem 0xf6cfe000-0xf6cf irq 17 at device 0.0 on pci12 iwn0: MIMO 2T3R, MoW2, address 00:1d:e0:72:10:01 iwn0: [ITHREAD] iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps pciconf i...@pci0:12:0:0: class=0x028000 card=0x11218086 chip=0x42298086 rev=0x61 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel Wireless WiFi Link 4965AGN(supporting 802.11a/b/g/Draft-N) (Intel 4965AGN)' class = network Thanks, 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: 8-STABLE outgoing scp stalling frequently.
On Tue, Feb 9, 2010 at 10:51 PM, Pyun YongHyeon wrote: > > I guess I fixed all known vge(4) issues, how recent stable/8 you > use? > Hi, my mistake, it's a release and not a stable version that I'm using: uname -a FreeBSD dev.bsdrp.net 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Tue Jan 5 16:02:27 UTC 2010 r...@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 Regards, 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: 8-STABLE outgoing scp stalling frequently.
On Tue, Feb 2, 2010 at 8:36 PM, Jonathan Chen wrote: > Hi, > > I've noticed that on a recent 8-STABLE/amd64, scp(1) appears to be > stalling very frequently. I've got the same problem since I've upgraded from 7.2 to 8-stable (32bit). My NIC is a vge(4), with txsum and rxsum disabled. dmesg: vge0: port 0xfc00-0xfcff mem 0xfdfff000-0xfdfff0ff irq 18 at device 14.0 on pci0 I can't SCP big file too because my transferts stall and abord. Regards, 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"
Regression with txcsum/rxcsum on vge(4) drivers on 8.0-Release
Hi, I've just upgraded on of my server from 7.2 to 8.0-Release and meet a problem with the vge(4) drivers: All my SCP transferts didn't works since this upgrade: they close, after a random time, with "Corrupted MAC on input" message. And Putty SSH tunnel closed with "Incorrect MAC received on packet". I need to disable txcsum and rxcsum on the vge network card for solving this problem. Does anyone meet the same regression between 7.2 and 8.0 ? Thanks, 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"
Regression with Asus K8N7-E deluxe motherboard on 8-stable: ACPI or PCI drivers bug ?
Hi, I've met 3 regressions on 8-stable on my Asus K8N7-E deluxe motherboard: - PATA drivers (kern/139143) - USB 2.0 drivers (usb/139142) - Ethernet (nfe) drivers But, I don't think that the USB/PATA/nfe drivers are the problem: The problem seems came from ACPI or PCI bus drivers bug with this motherboard. There are lot's of differences between the dmesg on 7.2 and 8.0 regarding the hardware ressources informations. Full dmesg under FreeBSD 7.2 here: http://pastebin.com/f7bbdcb3a Full dmesg under FreeBSD 8.0 here: http://pastebin.com/f52df9c4c Here, are some examples of the diff between the 2 dmesg: -- About ACPI, there is this error on 8.0: ACPI Error: Package List length (6) larger than NumElements count (3), truncated 20090521 dsobject-590 --- About PCI link18 (Initial Probe IRQ diff): 7.2: pci_link18: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 18 Validation 0 255 N 0 18 After Disable 0 255 N 0 18 8.0: pci_link18: Index IRQ Rtd Ref IRQs Initial Probe 05 N 0 18 Validation 0 255 N 0 18 After Disable 0 255 N 0 18 (Note the IRQ diff) --- And lot's of devices have map size diff: on 7.2: found-> vendor=0x10de, dev=0x0052, revid=0xa2 map[10]: type I/O Port, range 32, base 0xdc00, size 5, enabled map[20]: type I/O Port, range 32, base 0x4c00, size 6, enabled map[24]: type I/O Port, range 32, base 0x4c40, size 6, enabled found-> vendor=0x10de, dev=0x0053, revid=0xf2 map[20]: type I/O Port, range 32, base 0xf000, size 4, enabled found-> vendor=0x10de, dev=0x0055, revid=0xf3 map[10]: type I/O Port, range 32, base 0x9e0, size 3, enabled map[14]: type I/O Port, range 32, base 0xbe0, size 2, enabled map[18]: type I/O Port, range 32, base 0x960, size 3, enabled map[1c]: type I/O Port, range 32, base 0xb60, size 2, enabled map[20]: type I/O Port, range 32, base 0xc400, size 4, enabled on 8.0: found-> vendor=0x10de, dev=0x0052, revid=0xa2 map[10]: type I/O Port, range 32, base 0xdc00, size 10, enabled map[20]: type I/O Port, range 32, base 0x4c00, size 10, enabled map[24]: type I/O Port, range 32, base 0x4c40, size 6, enabled found-> vendor=0x10de, dev=0x0053, revid=0xf2 map[20]: type I/O Port, range 32, base 0xf000, size 12, enabled found-> vendor=0x10de, dev=0x0055, revid=0xf3 map[10]: type I/O Port, range 32, base 0x9e0, size 5, enabled map[14]: type I/O Port, range 32, base 0xbe0, size 5, enabled map[18]: type I/O Port, range 32, base 0x960, size 5, enabled map[1c]: type I/O Port, range 32, base 0xb60, size 5, enabled map[20]: type I/O Port, range 32, base 0xc400, size 10, enabled (Note the size diff) --- An unknown and USB error on 8.0: 7.2: pcib0: slot 2 INTA routed to irq 21 via \_SB_.PCI0.APCF 8.0: pcib0: slot 2 INTA routed to irq 21 via \_SB_.PCI0.APCF unknown: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0x8000 unknown: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x8000 ohci early: SMM active, request owner change ohci early: SMM does not respond, resetting --- The memory addresses of devices or reserved addresse bytes are different: 7.2: ohci0: mem 0xd3003000-0xd3003fff irq 21 at device 2.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xd3003000 ioapic0: routing intpin 21 (PCI IRQ 21) to vector 49 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 6.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf000 atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xd800-0xd80f mem 0xd3002000-0xd3002fff irq 22 at device 7.0 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xd800 ioapic0: routing intpin 22 (PCI IRQ 22) to vector 52 nfe0: port 0xb000-0xb007 mem 0xd300-0xd3000fff irq 21 at device 10.0 on pci0 nfe0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xd300 miibus0: on nfe0 e1000phy0: PHY 15 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto nfe0: bpf attached nfe0: Ethernet address: 00:13:d4:d6:3a:7b 8.0: ohci0: mem 0x8000-0x8fff irq 21 at device 2.0 on pci0 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 49 (Note the mem diff) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376 at device 6.0 on pci0 atapci0: Lazy allocation of 0x1000 bytes rid 0x20 type 4 at 0x1000 atapci0: Reserved 0x1000 bytes for rid 0x20 type 4 at 0x1000 (Note the reserved bytes diff) atapci2: irq 23 at device 8.0 on pci0 atapci2: Lazy allocation of 0x400 bytes rid 0x20 type 4 at 0x2c00 atapci2: Reserved 0x400 bytes for rid 0x20 type 4 at 0x2c00 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 52 (Note the reserved bytes diff) nfe0: irq 21 at device 10.0 on pci0 nfe0: Lazy allocation of 0x1000
Re: FreeBSD 8.0: can't PXE Boot using nvidia nForce4 network card
On Tue, Dec 29, 2009 at 1:37 AM, Pyun YongHyeon wrote: > > :-( > How about this one? Sorry, I'm just guessing(no hardware, no > documentation). > Thanks for this new patch but still same error: FreeBSD 8.0-STABLE #5: Tue Dec 29 08:50:27 CET 2009 r...@debugger.bsdrp.net:/usr/obj/usr/src/sys/GENERIC i386 (...) nfe0: irq 21 at device 10.0 on pc i0 nfe0: Lazy allocation of 0x100 bytes rid 0x10 type 3 at 0x8100 nfe0: Reserved 0x100 bytes for rid 0x10 type 3 at 0x8100 nfe0: MII without any phy! device_attach: nfe0 attach returned 6 (...) Regards, Oliver ___ 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: FreeBSD 8.0: can't PXE Boot using nvidia nForce4 network card
On Mon, Dec 28, 2009 at 11:21 PM, Pyun YongHyeon wrote: > Ok, it seems Linux forcedeth driver seems to poke NFE_STATUS > register before accessing PHY. I'm not sure whether this code could > be related with the issue but would you try attached patch? > Allready a patch to try! Thanks for your reactivity! The patch was applyed successfully and new kernel compiled/installed without problem but same error message: FreeBSD 8.0-STABLE #4: Mon Dec 28 23:48:36 CET 2009 r...@debugger.bsdrp.net:/usr/obj/usr/src/sys/GENERIC i386 (...) nfe0: irq 21 at device 10.0 on pci0 nfe0: Lazy allocation of 0x100 bytes rid 0x10 type 3 at 0x8100 nfe0: Reserved 0x100 bytes for rid 0x10 type 3 at 0x8100 nfe0: MII without any phy! device_attach: nfe0 attach returned 6 (...) Trying to mount root from nfs:10.0.0.1:/usr/tftpboot nfs_diskless: no interface ROOT MOUNT ERROR: (...) Regards, 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: FreeBSD 8.0: can't PXE Boot using nvidia nForce4 network card
On Thu, Dec 24, 2009 at 8:33 PM, Pyun YongHyeon wrote: >> nfe0: MII without any phy! > ^^ > Maybe this is the reason why you can't use NFS. > If your BIOS has an option that disables management feature > of ethernet controller try toggle the feature. > Hi, I've disabled the "POST Check LAN Cable" in the BIOS: But still the same "MII without any phy!" message. Regards, 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"
FreeBSD 8.0: can't PXE Boot using nvidia nForce4 network card
Hi all, I've got a PC which have 2 bugs with FreeBSD 8.0: It can't boot from USB (usb/139142) neither from PATA hard-drive (kern/139143). But I would boot this PC for giving acces to somes FreeBSD devs for debuging it: Then I've choose boot my buggy PC using PXE, then I've prepared a second PC with a DHCP/TFTP/NFS/serial-cable this bugguy PC. I've posted my problem on the FreeBSD forum some weeks ago, but didn't found usefull help: http://forums.freebsd.org/showthread.php?t=8324 The up-to-date 8.0-STABLE kernel boot fine from PXE/TFTP, but when it tries to mount the rootfilesystem from NFS it display an errror: Trying to mount root from nfs:10.0.0.1:/usr/tftpboot nfs_diskless: no interface ROOT MOUNT ERROR: The network card is a NVIDIA nForce4 CK804 MCP8. I've seen that the pxe loader populate correctly lot's of the needed boot variables (boot.netif.ip, boot.netif.netmask, boot.netif.gateway, etc...) but with the only expection of "boot.netif.name". It seems to have a problem in /usr/src/sys/nfsclient/nfs_diskless.c that can't set this variable. Does some one have any clue for fixing this file ? Thanks, Olivier PS: Here is the full verbose boot messages: SMAP type=01 base= len=0009f800 SMAP type=02 base=000f len=0001 SMAP type=02 base=fec0 len=1000 SMAP type=02 base=fee0 len=0010 SMAP type=02 base=fefffc00 len=0400 SMAP type=02 base= len=0001 SMAP type=02 base=e000 len=1000 SMAP type=03 base=7fff3000 len=d000 SMAP type=04 base=7fff len=3000 SMAP type=02 base=0009f800 len=0800 SMAP type=01 base=0010 len=7fef 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 8.0-STABLE #3: Wed Dec 23 01:14:48 CET 2009 r...@debugger.bsdrp.net:/usr/obj/usr/src/sys/GENERIC i386 Preloaded elf kernel "/boot/kernel/kernel" at 0xc0f79000. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2010313531 Hz CPU: AMD Athlon(tm) 64 Processor 3000+ (2010.31-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x20fc2 Stepping = 2 Features=0x78bfbff Features2=0x1 AMD Features=0xe2500800 AMD Features2=0x1 Data TLB: 32 entries, fully associative Instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative WARNING: This architecture revision has known SMP hardware bugs which may cause random instability real memory = 2147483648 (2048 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x01026000 - 0x7db9afff, 2092388352 bytes (510837 pages) avail memory = 2091081728 (1994 MB) Table 'FACP' at 0x7fff30c0 Table 'MCFG' at 0x7fff96c0 Table 'APIC' at 0x7fff9600 APIC: Found table at 0x7fff9600 MP Configuration Table version 1.4 found at 0xc00f1400 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) ACPI APIC Table: APIC: CPU 0 has ACPI ID 0 bios32: Found BIOS32 Service Directory header at 0xc00fb950 bios32: Entry = 0xf1f80 (c00f1f80) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0x1fb0 pnpbios: Found PnP BIOS data at 0xc00fc4d0 pnpbios: Entry = f:c500 Rev = 1.0 Other BIOS signatures found: ULE: setup cpu 0 ACPI: RSDP 0xf77b0 00014 (v0 Nvidia) ACPI: RSDT 0x7fff3040 00030 (v1 Nvidia AWRDACPI 42302E31 AWRD ) ACPI: FACP 0x7fff30c0 00074 (v1 Nvidia AWRDACPI 42302E31 AWRD ) ACPI: DSDT 0x7fff3180 06402 (v1 NVIDIA AWRDACPI 1000 MSFT 010E) ACPI: FACS 0x7fff 00040 ACPI: MCFG 0x7fff96c0 0003C (v1 Nvidia AWRDACPI 42302E31 AWRD ) ACPI: APIC 0x7fff9600 0006E (v1 Nvidia AWRDACPI 42302E31 AWRD ) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec0 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level MADT: Interrupt override: source 14, irq 14 MADT: Interrupt override: source 15, irq 15 lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x VER: 0x00050010 LDR: 0x DFR: 0x lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff timer: 0x000100ef therm: 0x0001 err: 0x0001 pcm: 0x00010400 wlan: <802.11 Link Layer> null: random: nfslock: p
