Re: [Need Help]isboot (iSCSI boot driver) version 0.2.1
Updated to 0.2.2 I noticed a bug after writing previous mail. sosend was called from XPT_SCSI_IO with locked mutex. It caused "sleeping thread owns a non-sleepable lock". What's new?: add auto sense. add maxio=1m. modify max tags by iSCSI command window. fix locked sleep problem. Download links: http://www.peach.ne.jp/archives/isboot/isboot-0.2.2.tar.gz Download links(for testing purpose only): http://www.peach.ne.jp/archives/isboot/demo/FreeBSD-7.3-RELEASE-amd64-isboot-0.2.2.iso http://www.peach.ne.jp/archives/isboot/demo/FreeBSD-7.3-RELEASE-i386-isboot-0.2.2.iso http://www.peach.ne.jp/archives/isboot/demo/FreeBSD-8.1-RC2-amd64-isboot-0.2.2.iso http://www.peach.ne.jp/archives/isboot/demo/FreeBSD-8.1-RC2-i386-isboot-0.2.2.iso http://www.peach.ne.jp/archives/isboot/demo/unionfs-mkisboot.sh -- Daisuke Aoyama ___ 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"
GEOM/bsdlabel regression in 8.x?
I was helping a friend as he wanted to add a partition to a new install, ie he did (effectively) this.. truncate -s 10m /tmp/test mdconfig -a -t vnode -f /tmp/test fdisk -BI /dev/md0 bsdlabel -w /dev/md0s1 bsdlabel -e /dev/md0s1 a: 2048 164.2BSD0 0 0 newfs /dev/md0s1a mkdir /mnt/test mount /dev/md0s1a /mnt/test bsdlabel -e /dev/md0s1 Then you get.. "bsdlabel: Class not found" Note that just touching the file bsdlabel is using is enough to cause it to generate that error. I tried the same steps on a 7.x system and it worked fine. ktrace shows ... 90200 bsdlabel CALL ioctl(0x4,DIOCGMEDIASIZE,0x7fffe430) 90200 bsdlabel RET ioctl 0 90200 bsdlabel CALL ioctl(0x4,DIOCGSECTORSIZE,0x7fffe434) 90200 bsdlabel RET ioctl 0 90200 bsdlabel CALL ioctl(0x4,DIOCGFWSECTORS,0x7fffe454) 90200 bsdlabel RET ioctl 0 90200 bsdlabel CALL ioctl(0x4,DIOCGFWHEADS,0x7fffe454) 90200 bsdlabel RET ioctl 0 90200 bsdlabel CALL close(0x4) 90200 bsdlabel RET close 0 90200 bsdlabel CALL close(0x3) 90200 bsdlabel RET close 0 90200 bsdlabel CALL open(0x800c04040,O_RDWR,0x26ec) 90200 bsdlabel NAMI "/dev/md0s1" 90200 bsdlabel RET open -1 errno 1 Operation not permitted 90200 bsdlabel CALL open(0x800651b5f,O_RDONLY,0) 90200 bsdlabel NAMI "/dev/geom.ctl" 90200 bsdlabel RET open 3 90200 bsdlabel CALL ioctl(0x3,GEOM_CTL,0x800c06040) 90200 bsdlabel RET ioctl 0 90200 bsdlabel CALL close(0x3) Note that my friend tried it on real hardware and said that after he rebooted it appeared(!) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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/bsdlabel regression in 8.x?
On 2010-07-04 14:24, Daniel O'Connor wrote: ... > mkdir /mnt/test > mount /dev/md0s1a /mnt/test > bsdlabel -e /dev/md0s1 > > Then you get.. > "bsdlabel: Class not found" First unmount /dev/md0s1a, or the device /dev/md0s1 will be in use, and opening it for read/write (as bsdlabel probably does) will fail. Alternatively, you can turn on the "footshooting" debug flag in geom: Protection mechanisms in the geom(4) subsystem might prevent boot0cfg from being able to update the MBR on a mounted disk. Instructions for temporarily disabling these protection mechanisms can be found in the geom(4) manpage. Specifically, do a sysctl kern.geom.debugflags=0x10 to allow writing to the MBR, and restore it to 0 afterwards. and try again. This may not work as expected though. :) ___ 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/bsdlabel regression in 8.x?
On 04/07/2010, at 23:27, Dimitry Andric wrote: >> Then you get.. >> "bsdlabel: Class not found" > > First unmount /dev/md0s1a, or the device /dev/md0s1 will be in use, and > opening it for read/write (as bsdlabel probably does) will fail. > > Alternatively, you can turn on the "footshooting" debug flag in geom: > > Protection mechanisms in the geom(4) subsystem might prevent boot0cfg > from being able to update the MBR on a mounted disk. Instructions for > temporarily disabling these protection mechanisms can be found in the > geom(4) manpage. Specifically, do a > > sysctl kern.geom.debugflags=0x10 > > to allow writing to the MBR, and restore it to 0 afterwards. > > and try again. This may not work as expected though. :) It doesn't make a difference if you set that flag or not. (The fact you need to set debugflags to modify the MBR is a separate bug anyway IMO) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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/bsdlabel regression in 8.x?
On 2010-07-04, Daniel O'Connor wrote: > "bsdlabel: Class not found" This is because GEOM_BSD -> GEOM_PART_BSD change. bsdlabel(8) needs read-write access to the device. If it can't get that, it tries an alternative GEOM based method only supported by GEOM_BSD. The error message "Class not found" is printed because the "BSD" GEOM class doesn't exist. You might be able to do the changes with gpart(8). -- Jaakko ___ 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/bsdlabel regression in 8.x?
On 2010-07-04 16:26, Daniel O'Connor wrote: >> First unmount /dev/md0s1a, or the device /dev/md0s1 will be in use, and >> opening it for read/write (as bsdlabel probably does) will fail. >> >> Alternatively, you can turn on the "footshooting" debug flag in geom: ... > It doesn't make a difference if you set that flag or not. > > (The fact you need to set debugflags to modify the MBR is a separate bug > anyway IMO) On my 8-stable box, I have tried this sequence of commands: truncate -s 10m /tmp/test mdconfig -a -t vnode -f /tmp/test mdconfig -a -t vnode -f /tmp/test fdisk -BI /dev/md0 bsdlabel -w /dev/md0s1 bsdlabel -e /dev/md0s1 newfs /dev/md0s1a mkdir /mnt/test mount /dev/md0s1a /mnt/test bsdlabel -e /dev/md0s1 The last one indeed fails, because the device is in use. This is expected, but the error message is very misleading, and should be improved. The real 'bug' (although there will probably be loads of bikesheds about it) is probably that if you *do* unmount the filesystem, bsdlabel still fails: umount /mnt/test bsdlabel -e /dev/md0s1 [class not found yada yada] Apparently, unmounting does not properly 'release' whatever underlying geom device is preventing read/write access. However, if you then set the footshooting flag: sysctl -w kern.geom.debugflags=0x10 bsdlabel -e /dev/md0s1 bsdlabel can write without problems, at least on my box. Stranger even, if you subsequently turn off the footshooting flag, it *still* can write to the label. That is, unless you mount and unmount the filesystem, after which is again, sort of 'locked' against writing. All highly confusing. :) ___ 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: Odd behavior of labels on different filesystem types
> Sender: "J. Hellenthal" > Date: Sun, 04 Jul 2010 01:55:20 -0400 > From: jhell > > On 07/03/2010 16:51, Kevin Oberman wrote: > > I have run into an odd behavior in 8-stable that I can't see a reason > > for. > > > > If I have a FAT32 formatted removable drive, I get /dev entries for it > > as both /dev/msdosfs/LABEL and /dev/ufsid/ID. When I mount the > > filesystem, the /dev/ufsid label is removed, but the other two remain. > > > > If I have a UFS filesystem on the disk, I have similar devices except > > that the LABEL is /dev/ufs/LABEL. But, when the UFS device is mounted, > > the /dev/ufsid/ID AND the /dev/ufs/LABEL devs are both deleted. > > > > I'm not sure which is "right", but I can't see the reason for the > > different behavior and it has caused a fair bit of trouble when working > > with gnome-mount as I can't unmount a ufs device. When the > > /dev/ufs/LABEL device is created again on the umount, gnome-mount sees a > > new device and immediately re-mounts it. > > > > Can this inconsistency be corrected? > > Can you try to zero out that disk first i.e. > dd if=/dev/zero of=/dev/DISK bs=4m > > Then format your msdos fat part and relabel it. You should not see a > dev/ufsid/ label for this anymore. I believe that for some reason the > ufsid metadata or whatever you want to call it some how has been left > behind and is still being read for whatever reason and can be confirmed > by this. > > As for /dev/ufs/LABEL /dev/ufsid/ID /dev/device when you mount one the > others should disapear so this is correct behavior. Thanks for the suggestion. I will try a device which has never had a UFS file system and see if the ufsid device is created. Looks like the former is an issue with geom tasting and it would be nice to get it fixed, but it is not what is causing my problem. It is the latter issue that causes the problems with gnome-mount. The real issue for me is that /dev/ufs/LABEL is removed on a mount while /dev/msdosfs/LABEL remains. hald easily works around ufsid by ignoring it, but the /dev/FS/LABEL has to be acted upon differently depending on which filesystem is involved. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ 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: Odd behavior of labels on different filesystem types
On 07/04/2010 12:15, Kevin Oberman wrote: >> Sender: "J. Hellenthal" >> Date: Sun, 04 Jul 2010 01:55:20 -0400 >> From: jhell >> >> On 07/03/2010 16:51, Kevin Oberman wrote: >>> I have run into an odd behavior in 8-stable that I can't see a reason >>> for. >>> >>> If I have a FAT32 formatted removable drive, I get /dev entries for it >>> as both /dev/msdosfs/LABEL and /dev/ufsid/ID. When I mount the >>> filesystem, the /dev/ufsid label is removed, but the other two remain. >>> >>> If I have a UFS filesystem on the disk, I have similar devices except >>> that the LABEL is /dev/ufs/LABEL. But, when the UFS device is mounted, >>> the /dev/ufsid/ID AND the /dev/ufs/LABEL devs are both deleted. >>> >>> I'm not sure which is "right", but I can't see the reason for the >>> different behavior and it has caused a fair bit of trouble when working >>> with gnome-mount as I can't unmount a ufs device. When the >>> /dev/ufs/LABEL device is created again on the umount, gnome-mount sees a >>> new device and immediately re-mounts it. >>> >>> Can this inconsistency be corrected? >> >> Can you try to zero out that disk first i.e. >> dd if=/dev/zero of=/dev/DISK bs=4m >> >> Then format your msdos fat part and relabel it. You should not see a >> dev/ufsid/ label for this anymore. I believe that for some reason the >> ufsid metadata or whatever you want to call it some how has been left >> behind and is still being read for whatever reason and can be confirmed >> by this. >> >> As for /dev/ufs/LABEL /dev/ufsid/ID /dev/device when you mount one the >> others should disapear so this is correct behavior. > > Thanks for the suggestion. I will try a device which has never had a UFS > file system and see if the ufsid device is created. Looks like the > former is an issue with geom tasting and it would be nice to get it > fixed, but it is not what is causing my problem. It is the latter issue > that causes the problems with gnome-mount. > > The real issue for me is that /dev/ufs/LABEL is removed on a mount while > /dev/msdosfs/LABEL remains. hald easily works around ufsid by ignoring > it, but the /dev/FS/LABEL has to be acted upon differently depending on > which filesystem is involved. Do you use those labels for anything ? if not, I worked around this while I used gnome for a period with devfs.rules(5) example follows. rc.conf(5) add devfs_system_ruleset="your_system" [your_system=10] add path 'ufsid'hide add path 'msdosfs' hide add path 'ufs' hide add path 'iso9660' hide add path 'reiserfs' hide add path 'ntfs' hide add path 'ext2fs' hide add path 'gpt' hide And you can do the same for the actual devices that you use a label for, so mounting devices like daN can just be done from /dev/label/LABEL. add path 'da0' hide # Do this only after it is labeled. add path 'label/DA0LABEL' mode 0600 user jhell group jhell With a little toying of the above you should get the desired effect you want in gnome. I do find it frustrating having to resort to using only generic labels for situations like this and believe firmly that the generic label should take precedence over all labels except gpt & ufsid and result in the other name-brand labels disappearing not causing this frustration to happen. Having the multiple layers of labels available IMO is cause for confusion. Final note before I stretch this out like the Armstrong figurine ;), there was a case where I was using the module instead of having GEOM_LABEL option built into the kernel, this being loaded after the machine was already booted caused some strange results with the labels that I know of on 7.2-STABLE. I don't know if this still exists but the result from that was multiple labels still being available under /dev while its counterpart label was mounted. That caused Gnome/hald to get pretty confused. Regards & Good luck, -- +-+-+-+-+-+ |j|h|e|l|l| +-+-+-+-+-+ ___ 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/bsdlabel regression in 8.x?
On Sun, Jul 4, 2010 at 8:37 AM, Dimitry Andric wrote: > On 2010-07-04 16:26, Daniel O'Connor wrote: >>> First unmount /dev/md0s1a, or the device /dev/md0s1 will be in use, and >>> opening it for read/write (as bsdlabel probably does) will fail. >>> >>> Alternatively, you can turn on the "footshooting" debug flag in geom: > ... >> It doesn't make a difference if you set that flag or not. >> >> (The fact you need to set debugflags to modify the MBR is a separate bug >> anyway IMO) > > On my 8-stable box, I have tried this sequence of commands: > > truncate -s 10m /tmp/test > mdconfig -a -t vnode -f /tmp/test > mdconfig -a -t vnode -f /tmp/test > fdisk -BI /dev/md0 > bsdlabel -w /dev/md0s1 > bsdlabel -e /dev/md0s1 > newfs /dev/md0s1a > mkdir /mnt/test > mount /dev/md0s1a /mnt/test > bsdlabel -e /dev/md0s1 > > The last one indeed fails, because the device is in use. This is > expected, but the error message is very misleading, and should be > improved. > > The real 'bug' (although there will probably be loads of bikesheds about > it) is probably that if you *do* unmount the filesystem, bsdlabel still > fails: > > umount /mnt/test > bsdlabel -e /dev/md0s1 > [class not found yada yada] > > Apparently, unmounting does not properly 'release' whatever underlying > geom device is preventing read/write access. However, if you then set > the footshooting flag: > > sysctl -w kern.geom.debugflags=0x10 > bsdlabel -e /dev/md0s1 > > bsdlabel can write without problems, at least on my box. Stranger > even, if you subsequently turn off the footshooting flag, it *still* > can write to the label. That is, unless you mount and unmount the > filesystem, after which is again, sort of 'locked' against writing. > > All highly confusing. :) There's a weird ass feature in geom too under 7.x+ that if you have where if you have a dangerously dedicated disk partitioned like so that gets mounted, it automatically hides the slicing: $ dd if=/dev/zero of=afile bs=10m count=5 $ mdconfig -a -t vnode -f afile md1 $ ls /dev/md1* /dev/md1 $ sudo fdisk -BIq /dev/md1 $ bsdlabel -w /dev/md1s1 $ bsdlabel -e /dev/md1s1 # /dev/md1s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a:96311 16unused0 0 c:963270unused0 0 # "raw" part, don't edit # newfs /dev/md1s1 /dev/md1s1: 47.0MB (96324 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 11.77MB, 753 blks, 1536 inodes. super-block backups (for fsck -b #) at: 160, 24256, 48352, 72448 $ ls /dev/md1* /dev/md1/dev/md1s1 $ ls /dev/md1* /dev/md1/dev/md1s1 /dev/md1s1a $ mount /dev/md1s1 /mnt/mem $ ls /dev/md1* /dev/md1/dev/md1s1 $ umount /mnt/mem $ ls /dev/md1* /dev/md1/dev/md1s1 /dev/md1s1a It's something that someone noticed at my work. Thanks, -Garrett ___ 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/bsdlabel regression in 8.x?
On 05/07/2010, at 1:07, Dimitry Andric wrote: > bsdlabel -e /dev/md0s1 > > The last one indeed fails, because the device is in use. This is > expected, but the error message is very misleading, and should be > improved. Maybe, I wouldn't call it expected because it used to work :) I agree about the error message though! > The real 'bug' (although there will probably be loads of bikesheds about > it) is probably that if you *do* unmount the filesystem, bsdlabel still > fails: > > umount /mnt/test > bsdlabel -e /dev/md0s1 > [class not found yada yada] > > Apparently, unmounting does not properly 'release' whatever underlying > geom device is preventing read/write access. However, if you then set > the footshooting flag: > > sysctl -w kern.geom.debugflags=0x10 > bsdlabel -e /dev/md0s1 > > bsdlabel can write without problems, at least on my box. Stranger > even, if you subsequently turn off the footshooting flag, it *still* > can write to the label. That is, unless you mount and unmount the > filesystem, after which is again, sort of 'locked' against writing. > > All highly confusing. :) Hmm odd, the sysctl had no effect here.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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/bsdlabel regression in 8.x?
On 05/07/2010, at 24:52, Jaakko Heinonen wrote: > On 2010-07-04, Daniel O'Connor wrote: >> "bsdlabel: Class not found" > > This is because GEOM_BSD -> GEOM_PART_BSD change. bsdlabel(8) needs > read-write access to the device. If it can't get that, it tries an > alternative GEOM based method only supported by GEOM_BSD. The error > message "Class not found" is printed because the "BSD" GEOM class > doesn't exist. > > You might be able to do the changes with gpart(8). Ahh that does work.. midget# gpart add -t freebsd-ufs -i 4 md0s1 md0s1d added midget# newfs /dev/md0s1d /dev/md0s1d: 2.8MB (5744 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 0.70MB, 45 blks, 128 inodes. super-block backups (for fsck -b #) at: 160, 1600, 3040, 4480 mmidget# mount /dev/md0s1d /mnt/test2 midget# mount .. /dev/md0s1a on /mnt/test (ufs, local) /dev/md0s1d on /mnt/test2 (ufs, local) IMO it's still a regression because bsdlabel used to work, although I can appreciate it might be a rather in depth change to have it work with the New World Order (tm). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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/bsdlabel regression in 8.x?
On 05/07/2010, at 9:06, Daniel O'Connor wrote: > > On 05/07/2010, at 24:52, Jaakko Heinonen wrote: > >> On 2010-07-04, Daniel O'Connor wrote: >>> "bsdlabel: Class not found" >> >> This is because GEOM_BSD -> GEOM_PART_BSD change. bsdlabel(8) needs >> read-write access to the device. If it can't get that, it tries an >> alternative GEOM based method only supported by GEOM_BSD. The error >> message "Class not found" is printed because the "BSD" GEOM class >> doesn't exist. >> >> You might be able to do the changes with gpart(8). > > Ahh that does work.. > > midget# gpart add -t freebsd-ufs -i 4 md0s1 > IMO it's still a regression because bsdlabel used to work, although I can > appreciate it might be a rather in depth change to have it work with the New > World Order (tm). So, why didn't it? Shouldn't it DTRT? This is a stock kernel. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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"
8.0 network problem
Hi all, I've got a persistent problem with my LAN. I'm running a FreeBSD 8.0 box as a home server performing the following functions for wired and wireless networks: router; firewall; DHCP server; and file server. For what it's worth, I've got ZFS up and running as the main filesystem. The recurring issue is that file transfers from the FreeBSD box to computers on the wired network (gigabit) start out fast and then become agonizingly slow. I'm sharing home directories over Samba, and those transfers work briefly and then tail off to a few kilobytes per second. The failure is somewhat predicatable in that it tends to happen once a few hundred megabytes have been transferred. I've swapped out hardware, I've Googled extensively, and all of the (possibly benign) error messages that I've found have been eliminated. I'm happy to post logs, configs, etc., and I'd appreciate any help with a diagnosis. For the moment: > uname -a FreeBSD EightOh.dew.home 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Tue Jan 5 21:11:58 UTC 2010 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > ifconfig em0: flags=8843 metric 0 mtu 1500 options=9b ether 00:0e:0c:b7:71:44 inet 192.168.0.1 netmask 0xff00 broadcast 192.168.0.255 media: Ethernet autoselect (1000baseT ) status: active ral0: flags=8843 metric 0 mtu 2290 ether 00:1f:1f:3f:76:f3 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running nfe0: flags=8843 metric 0 mtu 1500 options=8 ether 00:01:29:d4:2d:6b inet XXX.XXX.XXX.XXX netmask 0xfc00 broadcast 255.255.255.255 media: Ethernet autoselect (100baseTX ) status: active plip0: flags=8810 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 wlan0: flags=8843 metric 0 mtu 1500 ether 00:1f:1f:3f:76:f3 inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running ssid FreeBSD_AP channel 7 (2442 Mhz 11g) bssid 00:1f:1f:3f:76:f3 country US authmode WPA privacy MIXED deftxkey 2 TKIP 2:128-bit txpower 0 scanvalid 60 protmode CTS dtimperiod 1 -dfs pflog0: flags=141 metric 0 mtu 33152 Thanks in advance! Dave ___ 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.0 network problem
On Sun, 4 Jul 2010, David Warren wrote: Hi all, I've got a persistent problem with my LAN. I'm running a FreeBSD 8.0 box as a home server Is it feasible for you to update to 8.1-RC2 and see if that helps? Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ 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.0 network problem
Hi Doug, I tried a binary update to 8.1 RC2, and then rebuilt all ports. Unfortunately, I'm still experiencing the same problem. Any thoughts on troubleshooting this? Thanks, Dave On Sun, Jul 4, 2010 at 8:40 PM, Doug Barton wrote: > On Sun, 4 Jul 2010, David Warren wrote: > > Hi all, >> >>I've got a persistent problem with my LAN. I'm running a FreeBSD 8.0 >> box as a home server >> > > Is it feasible for you to update to 8.1-RC2 and see if that helps? > > > Doug > > -- > >Improve the effectiveness of your Internet presence with >a domain name makeover!http://SupersetSolutions.com/ > >Computers are useless. They can only give you answers. >-- Pablo Picasso > > -- Post-doctoral Fellow Neurology Department University of Iowa Hospitals and Clinics davideugenewar...@gmail.com ___ 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.0 network problem
On Jul 4, 2010, at 5:52 PM, David Warren wrote: > Hi all, > > I've got a persistent problem with my LAN. I'm running a FreeBSD 8.0 > box as a home server performing the following functions for wired and > wireless networks: router; firewall; DHCP server; and file server. For what > it's worth, I've got ZFS up and running as the main filesystem. The > recurring issue is that file transfers from the FreeBSD box to computers on > the wired network (gigabit) start out fast and then become agonizingly > slow. I'm sharing home directories over Samba, and those transfers work > briefly and then tail off to a few kilobytes per second. The failure is > somewhat predicatable in that it tends to happen once a few hundred > megabytes have been transferred. I've swapped out hardware, I've Googled > extensively, and all of the (possibly benign) error messages that I've found > have been eliminated. I'm happy to post logs, configs, etc., and I'd > appreciate any help with a diagnosis. For the moment: Disable rxcsum and txcsum on the cards; see if that does the trick. Before that, I'd see whether or not Jack Vogel (the current em(4) maintainer) would some details about your traffic, like a tcpdump session log. HTH, -Garrett___ 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.0 network problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2010 01:52:11, David Warren wrote: > I've got a persistent problem with my LAN. I'm running a FreeBSD 8.0 > box as a home server performing the following functions for wired and > wireless networks: router; firewall; DHCP server; and file server. For what > it's worth, I've got ZFS up and running as the main filesystem. The > recurring issue is that file transfers from the FreeBSD box to computers on > the wired network (gigabit) start out fast and then become agonizingly > slow. I'm sharing home directories over Samba, and those transfers work > briefly and then tail off to a few kilobytes per second. The failure is > somewhat predicatable in that it tends to happen once a few hundred > megabytes have been transferred. I've swapped out hardware, I've Googled > extensively, and all of the (possibly benign) error messages that I've found > have been eliminated. I'm happy to post logs, configs, etc., and I'd > appreciate any help with a diagnosis. For the moment: Does this affect both wired and wireless LANs? Does this affect specific protocols more severely than other protocols? Does this affect all traffic happening at that point, all traffic on a particular interface or just specific connections? The effect you describe sounds bizarrely like entropy-pool exhaustion, which would kill any traffic over your wireless network, or anything using crypto protocols on either wired or wireless nets. I say "sounds like" because the yarrow entropy pool maintenance code in FreeBSD is extremely good, and I've seen FreeBSD boxes serving HTTPS at Mb/s without anything like what you are experiencing. Also, you're seeing it affect Samba over a wired connection, and that should be minimally affected by that sort of thing. Hmmm... Can you try transferring some large files (DVD .iso images around a few GB in size are handy for this) between systems using: * netcat or HTTP over wired connection * ssh over wired connection * netcat or HTTP over wireless * ssh over wireless Try these in both directions -- this should help show if it's slow disk performance on the receiving side. Also, check the output of 'netstat -i' to see if interface error counters are increasing: Ierrors, Idrop and Oerrors should all ideally be zero. If you see those starting to rise, it means either there's a configuration problem somewhere, like a duplex mismatch [no evidence for that from the ifconfig output you showed though] or perhaps there's still some dodgy hardware somewhere on your network despite all the swapping-out you've been doing. One final thought -- perhaps this isn't to do with the network at all, but it's disk IO performance bottoming out. In which case you should be able to see much the same effect copying files between different zpools, or between your main zpool and say, a USB memory stick. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwxb5IACgkQ8Mjk52CukIz6xQCffeqtaiZ5zc8JDX5EWzGAgdPo 1BoAn0F7Upq4QoTkg2O8mUPBCnYtom/T =EqiV -END PGP SIGNATURE- ___ 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.0 network problem
On Mon, Jul 5, 2010 at 12:37 AM, Matthew Seaman < m.sea...@infracaninophile.co.uk> wrote: > > One final thought -- perhaps this isn't to do with the network at all, > but it's disk IO performance bottoming out. In which case you should be > able to see much the same effect copying files between different zpools, > or between your main zpool and say, a USB memory stick. > IIRC, this issue may have been described before and it's ZFS related. I'm pretty sure there was an issue with ZFS transfer's stallling and the original poster was trying to do things like zfs send. I think it was resolved by upgrading to STABLE. If I remember more, I'll post it otherwise check the archive's (fs, general, net) from maybe around 2-3 months ago or even asking there. Skim search had this, http://lists.freebsd.org/pipermail/freebsd-fs/2010-February/007818.html -- Adam Vande More ___ 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.0 network problem
On Sun, Jul 04, 2010 at 07:52:11PM -0500, David Warren wrote: > I've got a persistent problem with my LAN. I'm running a FreeBSD 8.0 > box as a home server performing the following functions for wired and > wireless networks: router; firewall; DHCP server; and file server. For what > it's worth, I've got ZFS up and running as the main filesystem. The > recurring issue is that file transfers from the FreeBSD box to computers on > the wired network (gigabit) start out fast and then become agonizingly > slow. I'm sharing home directories over Samba, and those transfers work > briefly and then tail off to a few kilobytes per second. The failure is > somewhat predicatable in that it tends to happen once a few hundred > megabytes have been transferred. Your system has 3 different network interfaces on it (em, ral, nfe), but you don't tell us across which interface the slow transfers happen. You also don't tell us which firewalling stack you're using (ipfw, ipfilter, pf). Let us know. I'm going to make the assumption that based on your "...on the wired network (gigabit)..." statement that the transfers are going across the em0 interface, but again, I'm not sure. Relevant interfaces (wlan0 is tied to ral0): > em0: flags=8843 metric 0 mtu 1500 > options=9b > ether 00:0e:0c:b7:71:44 > inet 192.168.0.1 netmask 0xff00 broadcast 192.168.0.255 > media: Ethernet autoselect (1000baseT ) > status: active > ral0: flags=8843 metric 0 mtu 2290 > ether 00:1f:1f:3f:76:f3 > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > status: running > nfe0: flags=8843 metric 0 mtu 1500 > options=8 > ether 00:01:29:d4:2d:6b > inet XXX.XXX.XXX.XXX netmask 0xfc00 broadcast 255.255.255.255 > media: Ethernet autoselect (100baseTX ) > status: active > [...] > wlan0: flags=8843 metric 0 mtu 1500 > ether 00:1f:1f:3f:76:f3 > inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > status: running > ssid FreeBSD_AP channel 7 (2442 Mhz 11g) bssid 00:1f:1f:3f:76:f3 > country US authmode WPA privacy MIXED deftxkey 2 TKIP 2:128-bit > txpower 0 scanvalid 60 protmode CTS dtimperiod 1 -dfs First and foremost: is the problem specific to Samba? Can you reproduce the problem when using the FTP protocol? Are there any indications of problems in "dmesg" when the issue is happening? Can you provide output from "vmstat -i" while the problem is happening? Can you provide output from "pciconf -lvc"? Only interested in the sections relevant to the above devices. Can you provide contents of /etc/make.conf, /etc/sysctl.conf, and /boot/loader.conf? Have you looked at "netstat -I -indb" output during the slow transfers to see if there's any indication of problems, or some sort of "common rate" (transfer, etc.) Does disabling the firewalling stack improve things at all? Can the slowness be reproduced using benchmarks/netperf or only when using something that involves actual disk I/O? (To use netperf you'll need two FreeBSD boxes). If only disk I/O, then ZFS analysis might be needed (there are some performance adjustments that are often required). Focusing more on em0: Have you tried disabling rxcsum and txcsum (using ifconfig) to see if there's any improvement? I don't see TSO used by your interface, so that should rule out any problems with that feature. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
