No UDP/TCP IPv6 connectivity (only) to router using gif interface - maybe ARM related
Hi, I tried to set up my raspberry PI as an ipv6 router. As a tunnel broker I use sixxs. Now I observed an interesting behavior: Every host from my network can reach the ipv6 world. The ipv6 world can also reach every host in my network. However - the router itself is unable to make udp or tcp connection to the world and is also unable to accept connections form the world ICMP however works properly. I had a look to the tcpdump and when trying to connect i.e. to www.kame.net the rasperry router sends a syn packet and get a syn/ack packet back. The rest of the handshake is missing. I tried also some udp with netcat (nc -6 -u -l on the server and nc -6 -u server on the client) This works great for internal (ethernet) traffic but when the data should go through the tunnel if fails. The last test is maybe the most significant to describe the bug: Start netcat to listen for UDP packages on an external host: external host nc -6 -u -l Connect from the RPI-Router to that host RPI nc -6 -u 2001:4dd0::::2 Now it is possible to send data from the RPI router to the external host but the opposite direction does not work. Tcpdump however shows that the udp package arrives but it is not forwarded to the application. So for me it seems to be a problem with the handling of the receiving data in the gif interface. This behavior is independent from net.inet6.ip6.forwarding or net.inet6.ip6.redirect status. The router system: FreeBSD raspberry-pi.xxx 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r254984 Best regards, Martin Laabs ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: how do i cross build world/kernel with clang?
On 2 Sep 2013, at 03:01, John-Mark Gurney j...@funkthat.com wrote: b/crtn.o: warning: linking PIC files with non-PIC files I think that this is an issue in our import of clang. I'll have to check whether I upstreamed the code, but it's basically just not setting the e_flags field in the ELF header correctly (this required a little bit of tweaking in LLVM, because MIPS is the only platform that uses e_flags in quite this way - for everything else you know what the value should be from the target triple). exect.So: In function `exect': (.text+0x18): relocation truncated to fit: R_MIPS_PC16 against `__cerror' I believe that this is a limitation of our ld. The PC16 relocation ought to be made to point to a PLT entry if it's too close, but it is just being truncated instead. This is fixed in upstream ld-bfd, and hopefully will be easy to fix with MCLinker if it doesn't already work. I'll see if we can make clang default to using larger relocation types for things not in the same compilation unit. David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[RFC][CFT] GEOM direct dispatch and fine-grained CAM locking
Hi. I would like to invite more people to review and test my patches for improving CAM and GEOM scalability, that for last six months you could see developing in project/camlock SVN branch. Full diff of that branch against present head (r255131) can be found here: http://people.freebsd.org/~mav/camlock_patches/camlock_20130902.patch Heavy CAM changes there were focused on reducing scope of SIM lock to only protecting SIM internals, but not CAM core. That allows many times reduce lock congestion, especially on heavily parallel request submission with GEOM changes below. More detailed description of changes you could see here earlier: http://docs.freebsd.org/cgi/mid.cgi?520D4ADB.50209 GEOM changes were focused on avoiding switching to GEOM up/down threads in relatively simple setups where respective classes don't require it (and were explicitly marked so). That allows save on context switches and on systems with several HBAs and disks talk to them concurrently (that is where CAM locking changes are handy). Such classes were modified to support it: DEV, DISK, LABEL, MULTIPATH, NOP, PART, RAID (partially), STRIPE, ZERO, VFS, ZFS::VDEV, ZFS::ZVOL and some others. Requests to/from other classes will be queued to GEOM threads same as before. Together that allows to double block subsystem performance on high (at least 100-200K) IOPS benchmarks, allowing to reach up to a million total IOPS, while keeping full compatibility with all major ABIs/KBIs. Since we are already in 10.0 release process and changes are quite big, my plan is to wait and commit them to head branch after the freeze end, and then merge to stable/10. I hope the release process will go on schedule to not delay this work for another six months. This work is sponsored by iXsystems, Inc. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 2013 MacBook Air Project
On Mon, Sep 2, 2013 at 4:16 AM, Adrian Chadd adr...@freebsd.org wrote: did you contribute this stuff back up to the linux driver? I did not; I was simply following a few how-tos on a colleague's machine to help her get a stable network connection. We never did fully crack that nut; I quickly realised how far out of my depth I was :) On Mon, Sep 2, 2013 at 11:02 AM, Lundberg, Johannes johan...@brilliantservice.co.jp wrote: This is the info OSX gives me about the 11 2013 MacBook Air. After a little bit of Googling, it looks like the chip inside the mid-2013 MacBook Air is the Broadcom BCM4360 (Not the 4331 I've played with) which is currently _not_ supported[1] by the legacy b43 Linux driver. Additionally, it doesn't seem to be listed in the list of supported devices of Broadcom's official open-source Linux drivers[2]. Broadcom's website seems a little helpful - they offer you the ability to submit a request for driver help - but not for this model of chip. I think your best bet will be to work from the sources of the bcmwl driver[3] - which /might/ be related to the brcm80211 stuff? I've not dug any further. [1] http://wireless.kernel.org/en/users/Drivers/b43#Supported_devices [2] http://wireless.kernel.org/en/users/Drivers/brcm80211#Supported_Chips [3] https://launchpad.net/ubuntu/+source/bcmwl JB ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: i915kms.ko not loading
30.08.2013 22:32, Jean-Sébastien Pédron пишет: reat! Could you please run: kgdb /boot/kernel/kernel /var/crash/vmcore.0 And, at gdb prompt: bt Then send the whole output (from the moment you run kgdb to the end of bt output) and your /var/log/messages file? Hi root kgdb /boot/kernel/kernel /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 amd64-marcel-freebsd...(no debugging symbols found)... Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. #0 0x80458f75 in doadump () (kgdb) bt #0 0x80458f75 in doadump () #1 0x80458d80 in kern_reboot () #2 0x80459107 in panic () #3 0x8062886a in trap_fatal () #4 0x8062851e in trap () #5 0x806120a3 in calltrap () #6 0x81040276 in ?? () #7 0xfe011f2da3a0 in ?? () #8 0x802f4f6e in acpi_pci_read_ivar () #9 0x8102ba4f in ?? () #10 0xf80005a717c0 in ?? () #11 0xf8012f89b000 in ?? () #12 0xfed100010005 in ?? () #13 0xfe000a71f000 in ?? () #14 0xfe011f2da470 in ?? () #15 0x0048 in ?? () #16 0xfe000a71f000 in ?? () #17 0x80462700 in sysctl_move_oid () #18 0x80319070 in drm_attach () #19 0x804837e6 in device_attach () #20 0x80484c09 in bus_generic_driver_added () #21 0x804819ea in devclass_driver_added () #22 0x8048194c in devclass_add_driver () #23 0x8044663b in module_register_init () #24 0x8043c835 in linker_load_module () #25 0x8043d9f7 in kern_kldload () #26 0x8043dbcb in sys_kldload () #27 0x80628ea3 in amd64_syscall () #28 0x8061238b in Xfast_syscall () #29 0x0008027d0dfa in ?? () Previous frame inner to this frame (corrupt stack?) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: i915kms.ko not loading
On 02.09.2013 12:00, Alexander wrote: (...) #17 0x80462700 in sysctl_move_oid () #18 0x80319070 in drm_attach () (...) The kernel is missing debug symbols. Could you please rebuild your kernel with the following option: makeoptions DEBUG=-g (also found in GENERIC) Then reproduce the problem and send the output of kgdb again? Thanks! -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: how do i cross build world/kernel with clang?
On 2 September 2013 00:47, David Chisnall thera...@freebsd.org wrote: On 2 Sep 2013, at 03:01, John-Mark Gurney j...@funkthat.com wrote: b/crtn.o: warning: linking PIC files with non-PIC files I think that this is an issue in our import of clang. I'll have to check whether I upstreamed the code, but it's basically just not setting the e_flags field in the ELF header correctly (this required a little bit of tweaking in LLVM, because MIPS is the only platform that uses e_flags in quite this way - for everything else you know what the value should be from the target triple). exect.So: In function `exect': (.text+0x18): relocation truncated to fit: R_MIPS_PC16 against `__cerror' I believe that this is a limitation of our ld. The PC16 relocation ought to be made to point to a PLT entry if it's too close, but it is just being truncated instead. This is fixed in upstream ld-bfd, and hopefully will be easy to fix with MCLinker if it doesn't already work. I'll see if we can make clang default to using larger relocation types for things not in the same compilation unit. Thanks! -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: LSI SAS2008 mps(4) 4TB disk only shows 2TB on CURRENT r255089
On Sat, Aug 31, 2013 at 1:07 PM, Sam Fourman Jr. sfour...@gmail.com wrote: Hello list I have two issues that may in fact be both related to the LSI SAS2008 card or the mps(4) driver. this server is running FreeBSD 10.0-CURRENT #0 r255089 1) All of the SSD disks are showing up at SATA2 300MB's but the card is in fact a 6GB Sata3 card.. 2) a Westren Digital 4TB disk only shows 2TB (connected to the LSI controller) full dmesg here https://gist.github.com/sfourman/6399419 full pciconf here https://gist.github.com/sfourman/6399454 Below is some disk info, $ sudo camcontrol identify da6 pass6: WDC WD4000FYYZ-01UL1B0 01.01K01 ATA-8 SATA 3.x device pass6: 300.000MB/s transfers, Command Queueing Enabled protocol ATA/ATAPI-8 SATA 3.x device model WDC WD4000FYYZ-01UL1B0 firmware revision 01.01K01 serial number WD-WCC130721596 WWN 50014ee25de95b67 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 268435455 sectors LBA48 supported 7814037168 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM 7200 Feature Support Enabled Value Vendor read ahead yes yes write cacheyes yes flush cacheyes yes overlapno Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes yes 128/0x80 automatic acoustic management no no media status notification no no power-up in Standbyyes no write-read-verify no no unload yes yes free-fall no no Data Set Management (DSM/TRIM) no Host Protected Area (HPA) yes no 7814037168/7814037168 HPA - Security no $ sudo gpart create -s gpt /dev/da6 da6 created $ gpart show = 34 234441581 da0 GPT (111G) 341281 freebsd-boot (64k) 162 2243951362 freebsd-ufs (107G) 22439529883886083 freebsd-swap (4.0G) 2327839061657709 - free - (809M) =34 4294967227 da6 GPT (2T) 34 4294967227 - free - (2T) $ sudo gpart add -a 4k -t freebsd-zfs -l backup da6 da6p1 added $ $ $ $ $ $ gpart show = 34 234441581 da0 GPT (111G) 341281 freebsd-boot (64k) 162 2243951362 freebsd-ufs (107G) 22439529883886083 freebsd-swap (4.0G) 2327839061657709 - free - (809M) =34 4294967227 da6 GPT (2T) 34 6 - free - (3.0k) 40 42949672161 freebsd-zfs (2T) 4294967256 5 - free - (2.5k) -- Sam Fourman Jr. is it possible that the problem is in the cam layer and not the mps(4) driver? -- Sam Fourman Jr. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
bug with special bracket expressions in regular expressions
re_format(7) says: There are two special cases‡ of bracket expressions: the bracket expres‐ sions ‘[[::]]’ and ‘[[::]]’ match the null string at the beginning and end of a word respectively. A word is defined as a sequence of word characters which is neither preceded nor followed by word characters. A word character is an alnum character (as defined by ctype(3)) or an underscore. This is an extension, compatible with but not specified by IEEE Std 1003.2 (“POSIX.2”), and should be used with caution in software intended to be portable to other systems. However I observe the following: $ echo cd0 cd1 xx | sed 's/cd[0-9][^ ]* *//g' xx $ echo cd0 cd1 xx | sed 's/[[::]]cd[0-9][^ ]* *//g' cd1 xx In my opinion '[[::]]' should not affect how the pattern is matched in this case. Any thoughts, suggestions? Thank you! -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bug with special bracket expressions in regular expressions
On Mon, 2 Sep 2013, Andriy Gapon wrote: re_format(7) says: There are two special cases? of bracket expressions: the bracket expres? sions ?[[::]]? and ?[[::]]? match the null string at the beginning and end of a word respectively. A word is defined as a sequence of word characters which is neither preceded nor followed by word characters. A word character is an alnum character (as defined by ctype(3)) or an underscore. This is an extension, compatible with but not specified by IEEE Std 1003.2 (?POSIX.2?), and should be used with caution in software intended to be portable to other systems. However I observe the following: $ echo cd0 cd1 xx | sed 's/cd[0-9][^ ]* *//g' xx $ echo cd0 cd1 xx | sed 's/[[::]]cd[0-9][^ ]* *//g' cd1 xx In my opinion '[[::]]' should not affect how the pattern is matched in this case. Any thoughts, suggestions? there are two simpler expressions, whose difference I don't understand either (tested on 8.4-PRERELEASE) $ echo cd0 cd1 xx | sed 's/cd[0-9] //g' xx $ echo cd0 cd1 xx | sed 's/[[::]]cd[0-9] //g' cd1 xx -- Damian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bug with special bracket expressions in regular expressions
on 02/09/2013 17:54 Andriy Gapon said the following: re_format(7) says: There are two special cases‡ of bracket expressions: the bracket expres‐ sions ‘[[::]]’ and ‘[[::]]’ match the null string at the beginning and end of a word respectively. A word is defined as a sequence of word characters which is neither preceded nor followed by word characters. A word character is an alnum character (as defined by ctype(3)) or an underscore. This is an extension, compatible with but not specified by IEEE Std 1003.2 (“POSIX.2”), and should be used with caution in software intended to be portable to other systems. However I observe the following: $ echo cd0 cd1 xx | sed 's/cd[0-9][^ ]* *//g' xx $ echo cd0 cd1 xx | sed 's/[[::]]cd[0-9][^ ]* *//g' cd1 xx In my opinion '[[::]]' should not affect how the pattern is matched in this case. It seems that the code works like this: - first it matches cd0 and removes it - then it passes cd1 xx for matching with a flag that tells that this is not a real start of the string - thus the matching code o knows that this is not a real line start, so it can't match [[::]] just for that reason o it does _not_ know what was the character before the start of the given substring, so it can not know if it could match [[::]] So matching fails. Not sure if this is an internal problem of regex(3) or a problem of how sed(1) uses regex(3). -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 2013 MacBook Air Project
On Mon, Sep 02, 2013 at 08:00:29PM +1000, Jason Birch wrote: On Mon, Sep 2, 2013 at 4:16 AM, Adrian Chadd adr...@freebsd.org wrote: did you contribute this stuff back up to the linux driver? I did not; I was simply following a few how-tos on a colleague's machine to help her get a stable network connection. We never did fully crack that nut; I quickly realised how far out of my depth I was :) On Mon, Sep 2, 2013 at 11:02 AM, Lundberg, Johannes johan...@brilliantservice.co.jp wrote: This is the info OSX gives me about the 11 2013 MacBook Air. After a little bit of Googling, it looks like the chip inside the mid-2013 MacBook Air is the Broadcom BCM4360 (Not the 4331 I've played with) which is currently _not_ supported[1] by the legacy b43 Linux driver. Additionally, it doesn't seem to be listed in the list of supported devices of Broadcom's official open-source Linux drivers[2]. Broadcom's website seems a little helpful - they offer you the ability to submit a request for driver help - but not for this model of chip. I think your best bet will be to work from the sources of the bcmwl driver[3] - which /might/ be related to the brcm80211 stuff? I've not dug any further. [1] http://wireless.kernel.org/en/users/Drivers/b43#Supported_devices [2] http://wireless.kernel.org/en/users/Drivers/brcm80211#Supported_Chips [3] https://launchpad.net/ubuntu/+source/bcmwl While not helpful in getting a native driver working, does the device work under the NDIS emulation layer with the Windows driver? Gary ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bug with special bracket expressions in regular expressions
On Mon, Sep 2, 2013 at 7:45 PM, Andriy Gapon a...@freebsd.org wrote: on 02/09/2013 17:54 Andriy Gapon said the following: re_format(7) says: There are two special cases‡ of bracket expressions: the bracket expres‐ sions ‘[[::]]’ and ‘[[::]]’ match the null string at the beginning and end of a word respectively. A word is defined as a sequence of word characters which is neither preceded nor followed by word characters. A word character is an alnum character (as defined by ctype(3)) or an underscore. This is an extension, compatible with but not specified by IEEE Std 1003.2 (“POSIX.2”), and should be used with caution in software intended to be portable to other systems. However I observe the following: $ echo cd0 cd1 xx | sed 's/cd[0-9][^ ]* *//g' xx $ echo cd0 cd1 xx | sed 's/[[::]]cd[0-9][^ ]* *//g' cd1 xx In my opinion '[[::]]' should not affect how the pattern is matched in this case. It seems that the code works like this: - first it matches cd0 and removes it - then it passes cd1 xx for matching with a flag that tells that this is not a real start of the string - thus the matching code o knows that this is not a real line start, so it can't match [[::]] just for that reason o it does _not_ know what was the character before the start of the given substring, so it can not know if it could match [[::]] So matching fails. Not sure if this is an internal problem of regex(3) or a problem of how sed(1) uses regex(3). -- Andriy Gapon In my opinion this is a bug. The [[::]] operator is said to match the empty string at the beginning of a word with no mention that the word has to be at the beginning of the whole string that is matched. OS X version of sed(1) works differently: $ echo cd0 cd1 xx | sed 's/cd[0-9][^ ]* *//g' xx $ echo cd0 cd1 xx | sed 's/[[::]]cd[0-9][^ ]* *//g' xx -Kimmo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 2013 MacBook Air Project
On 2 September 2013 09:48, Gary Palmer gpal...@freebsd.org wrote: While not helpful in getting a native driver working, does the device work under the NDIS emulation layer with the Windows driver? I don't know. But the wifi NDIS stuff has evolved quite significantly over the years and I don't know if the ndis layer has been taught about it. -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: LSI SAS2008 mps(4) 4TB disk only shows 2TB on CURRENT r255089
On Sat, Aug 31, 2013 at 13:07:53 -0400, Sam Fourman Jr. wrote: Hello list I have two issues that may in fact be both related to the LSI SAS2008 card or the mps(4) driver. this server is running FreeBSD 10.0-CURRENT #0 r255089 1) All of the SSD disks are showing up at SATA2 300MB's but the card is in fact a 6GB Sata3 card.. 2) a Westren Digital 4TB disk only shows 2TB (connected to the LSI controller) full dmesg here https://gist.github.com/sfourman/6399419 Both problems are because the drives in question are plugged into an mpt(4) controller, not the mps(4) controller in the system. The first one is because mpt(4) controllers only support up to 3Gb of course, but the second one is because mpt(4) controllers don't support SATA drives over 2TB. Or more precisely don't let you access the capacity over 2TB. Both problems should go away if you plug them into the mps(4) controller. From the dmesg: mps0: LSI SAS2008 port 0xe000-0xe0ff mem 0xfeb3c000-0xfeb3,0xfeb4-0xfeb7 irq 24 at device 0.0 on pci9 mps0: Firmware: 15.00.00.00, Driver: 16.00.00.00-fbsd mps0: IOCCapabilities: 1285cScsiTaskFull,DiagTrace,SnapBuf,EEDP,TransRetry,EventReplay,HostDisc pcib2: ACPI PCI-PCI bridge irq 52 at device 3.0 on pci0 pci8: ACPI PCI bus on pcib2 mpt0: LSILogic SAS/SATA Adapter port 0xd000-0xd0ff mem 0xfe7ec000-0xfe7e,0xfe7f-0xfe7f irq 28 at device 0.0 on pci8 mpt0: MPI Version=1.5.20.0 [ ...] da0 at mpt0 bus 0 scbus1 target 1 lun 0 da0: ATA INTEL SSDSC2BB12 0350 Fixed Direct Access SCSI-5 device da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 114473MB (234441648 512 byte sectors: 255H 63S/T 14593C) cd0 at ata0 bus 0 scbus6 target 1 lun 0 cd0: MATSHITA DVD-ROM UJ8B0AC 1.00 Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed da1 at mpt0 bus 0 scbus1 target 2 lun 0 da1: ATA INTEL SSDSC2BB12 0350 Fixed Direct Access SCSI-5 device da1: 300.000MB/s transfers da1: Command Queueing enabled da1: 114473MB (234441648 512 byte sectors: 255H 63S/T 14593C) da2 at mpt0 bus 0 scbus1 target 3 lun 0 da2: ATA INTEL SSDSC2BA80 0250 Fixed Direct Access SCSI-5 device da2: 300.000MB/s transfers da2: Command Queueing enabled da2: 763097MB (1562824368 512 byte sectors: 255H 63S/T 97281C) da3 at mpt0 bus 0 scbus1 target 4 lun 0 da3: ATA INTEL SSDSC2BA80 0250 Fixed Direct Access SCSI-5 device da3: 300.000MB/s transfers da3: Command Queueing enabled da3: 763097MB (1562824368 512 byte sectors: 255H 63S/T 97281C) da4 at mpt0 bus 0 scbus1 target 5 lun 0 da4: ATA INTEL SSDSC2BA80 0250 Fixed Direct Access SCSI-5 device da4: 300.000MB/s transfers da4: Command Queueing enabled da4: 763097MB (1562824368 512 byte sectors: 255H 63S/T 97281C) da5 at mpt0 bus 0 scbus1 target 6 lun 0 da5: ATA INTEL SSDSC2BA80 0250 Fixed Direct Access SCSI-5 device da5: 300.000MB/s transfers da5: Command Queueing enabled da5: 763097MB (1562824368 512 byte sectors: 255H 63S/T 97281C) da6 at mpt0 bus 0 scbus1 target 8 lun 0 da6: ATA WDC WD4000FYYZ-0 1K01 Fixed Direct Access SCSI-5 device da6: 300.000MB/s transfers da6: Command Queueing enabled da6: 2097151MB (4294967294 512 byte sectors: 255H 63S/T 267349C) Ken -- Kenneth Merry k...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] VMware vmxnet3 ethernet driver
- Original Message - - Original Message - Bezüglich Bryan Venteicher's Nachricht vom 27.08.2013 06:18 (localtime): ... snip The intr usage is higher than the other drivers you compared against because if_vmx does the off-level processing in ithreads where as the others do it in a taskqueue. BTW: if_vmx can to LRO as well. I don't think the emulated e1000 can, but I bet the e1000e does. if_vmx - if_vmx 1.32 GBits/sec, load: 10-45%Sys 40-48%Intr if_vmxJumbo - if_vmxJumbo 5.01 GBits/sec, load: 10-45%Sys 40-48%Intr Please find attached the different outputs of dev.vmx.X (the mtu9000 run was only 3.47GBits/sec in that case, took the numbers anyway) Thanks for the sysctl output. dev.vmx.0.txq0.ringfull: 133479 dev.vmx.0.txq0.hstats.tso_packets: 564986 dev.vmx.0.txq0.hstats.ucast_packets: 570604 For the number of packets transmitted, there's a really high percentage of time we find the Tx queue full enough it is not able to hold the next to transmit frame. I've haven't been able to recreate this. But I recently made a commit [1] that might help alleviate this. [1] http://svnweb.freebsd.org/base?view=revisionrevision=255055 wbr, -Harry ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
