Re: fxp: stalled transfers
pyu...@gmail.com wrote:
Could you disable TSO and try again?('ifconfig fxp0 -tso' will do
the job).
Yes, disabling TSO helps. That's a reasonable workaround for me. Thanks.
Let me know if you need further information in case you want to make
changes to the fxp driver regarding this problem.
Björn
___
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: fxp: stalled transfers
On Thu, Apr 09, 2009 at 09:15:12AM +0200, Bjoern Koenig wrote:
pyu...@gmail.com wrote:
Could you disable TSO and try again?('ifconfig fxp0 -tso' will do
the job).
Yes, disabling TSO helps. That's a reasonable workaround for me. Thanks.
Let me know if you need further information in case you want to make
changes to the fxp driver regarding this problem.
If you can easily reproduce the issue, can you capture stalled TCP
session with tcpdump on receiving host?(Make sure to disable Rx
checksum offload prior to capturing the session.)
___
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 and iSCSI for disks.
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --enig90DADA8437A99D893FB775F8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Danny Braniss wrote: Garance A Drosihn wrote: Some friends of mine are looking at the new DroboPro, which makes a= lot of disk space available via iSCSI (in addition to firewire 800), and they were wondering how well iSCSI works with FreeBSD. I haven't= paid attention to iSCSI support. Is there anyone using it heavily for disk-storage under FreeBSD? Has there been much changed for iSCSI support in the 8.x branch, or is 7.x support working fine? I suppose you are interested in the client (initiator) side of iSCSI= support. It hasn't changed much between 7.x and 8.x but there are apparently some announcements of a newer version: http://lists.freebsd.org/pipermail/freebsd-scsi/2009-March/003834.html= I can't find any more information on it. the latest is in: http://www.cs.huji.ac.il/~danny/ftp/freebsd/iscsi-2.1.1.tar.gz Thanks! Is there anything in particular you'd like to get tested in the new version, any significant changes or improvements? mainly fixed some bugs, and some code cleanup. give it a spin, and let me know what target you are testing. btw, the default tag opening is a bit concervative (1), you might want to change it to somewhat larger, say 64 or 128. cheers, danny ___ 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: ZFSKnownProblems - needs revision? / Lighttpd
Ivan Voras wrote: 2009/4/8 Miroslav Lachman 000.f...@quip.cz: (Lighttpd problem may be related to jail instead of ZFS - I did not test it yet) Completely unrelated to ZFS, but wasn't there some issue with lighttpd and sendfile() relatively recently (sendfile is the default)? Have you tried server.network-backend = writev ? I know about the problem with sendfile as I was hit by it on the main server with Lighttpd + UFS. It has different behavior and it was fixed in the latest version of Lighttpd from ports. Both servers (main with UFS and second with ZFS + Jail) are running this fixed version. I will test it with writev, thanks for suggestion. With lower load, Lighttpd is shown in `top` with state 'kqread', but with higher load in the case of slowdown, the state is 'zfs-io'. Miroslav Lachman ___ 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 and iSCSI for disks.
Trying to build 2.1.1 on a CURRENT results in this: === iscsi/initiator (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/GENERIC -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c: In function 'iscsi_open': /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:120: error: invalid operands to binary /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:122: error: invalid operands to binary /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:126: error: invalid operands to binary /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c: In function 'iscsi_close': /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:149: error: invalid operands to binary /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:154: error: invalid operands to binary /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c: In function 'iscsi_ioctl': /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:184: error: invalid operands to binary /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:210: error: invalid operands to binary /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c: In function 'iscsi_read': /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:290: error: invalid operands to binary /glz --On April 9, 2009 10:43:06 +0300 Danny Braniss da...@cs.huji.ac.il wrote: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --enig90DADA8437A99D893FB775F8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Danny Braniss wrote: Garance A Drosihn wrote: Some friends of mine are looking at the new DroboPro, which makes a= lot of disk space available via iSCSI (in addition to firewire 800), and they were wondering how well iSCSI works with FreeBSD. I haven't= paid attention to iSCSI support. Is there anyone using it heavily for disk-storage under FreeBSD? Has there been much changed for iSCSI support in the 8.x branch, or is 7.x support working fine? I suppose you are interested in the client (initiator) side of iSCSI= support. It hasn't changed much between 7.x and 8.x but there are apparently some announcements of a newer version: http://lists.freebsd.org/pipermail/freebsd-scsi/2009-March/003834.htm l= I can't find any more information on it. the latest is in: http://www.cs.huji.ac.il/~danny/ftp/freebsd/iscsi-2.1.1.tar.gz Thanks! Is there anything in particular you'd like to get tested in the new version, any significant changes or improvements? mainly fixed some bugs, and some code cleanup. give it a spin, and let me know what target you are testing. btw, the default tag opening is a bit concervative (1), you might want to change it to somewhat larger, say 64 or 128. cheers, danny ___ 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 ... the future isMobile Goran Lowkrantz goran.lowkra...@ismobile.com System Architect, isMobile AB Sandviksgatan 81, PO Box 58, S-971 03 Luleå, Sweden Mobile: +46(0)70-587 87 82 http://www.ismobile.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: no USB mice detected on GA-MA74GM-S2
On Wed, 08 Apr 2009 15:48:04 -0500, Robert Noland wrote On Wed, 2009-04-08 at 21:08 +0200, Piotr Smyrak wrote: I recently upgraded my system to newer hardware with motherboard GIGABYTE GA-MA74GM-S2 Rev 1.0 with AMD 740G chipset (north bridge) and AMD SB700 (south) where USB support is located. Everything would be fine except there is no USB mice detection by FreeBSD at all. And I am stuck with USB mise since the mobo has no PS/2 port. First I started with my old build of 6.2, then upgraded to 6.4 STABLE, to finally upgrade to 7.2 PRERELEASE in hope of fixing the issue. None of versions gave me USB mouse support. I have tried connecting 3 various mice. No luck. The only effect I can achieve after connecting a mouse, is a somewhat delayed message on console: rebuild/reinstall devel/libpciaccess now that you have updated kernel. I think I was not clear in my first post. My issue is the kernel does not recognizes my USB mice, so I get no /dev/ums* devices at all. I have made a clean install of all my ports after upgrade. Thanks for your suggestion. -- Piotr Smyrak piotr.smy...@heron.pl ___ 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 and iSCSI for disks.
Robert Blayzor wrote: On Apr 7, 2009, at 5:43 PM, Garance A Drosihn wrote: Some friends of mine are looking at the new DroboPro, which makes a lot of disk space available via iSCSI (in addition to firewire 800), and they were wondering how well iSCSI works with FreeBSD. I haven't paid attention to iSCSI support. Is there anyone using it heavily for disk-storage under FreeBSD? Has there been much changed for iSCSI support in the 8.x branch, or is 7.x support working fine? If you're looking for production ready iSCSI initiator support in FreeBSD, do yourself a favor, save some time, and look into something else. Seriously, we went down this road just recently testing both FreeBSD 7.0/7.1 amd64 on various Dell servers with Intel (em) Gig-E NIC's and it was very easy to basically get the box to lock up solid and/or panic. Our targets were both Netapp and Equallogic iSCSI SAN's. We didn't have a lot of time to debug it, our setup was pretty simple.. yet when we tried to run various simulated real world load on it the boxes just caved. Even with jumbo frames enabled on the NIC's the performance was mediocre at best. Unfortunately due a time constraint we had to move the clients to CentOS 5.2/5.3 and things have been very good so far. I was hoping that FreeBSD's iSCSI support was a bit more solid, or at least hoping that the (isp) driver had support for the QLogic iSCSI HBA's... no luck. I have a feeling this is because the ISCSI initiator in FreeBSD hasn't been updated since 2007. There have been patches and new development but nothing committed and/or MFC-ed. I'm just starting to evaluate it, so I can't say anything about its stability yet. signature.asc Description: OpenPGP digital signature
Re: FreeBSD and iSCSI for disks.
Danny Braniss wrote:
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--enig90DADA8437A99D893FB775F8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Danny Braniss wrote:
Garance A Drosihn wrote:
Some friends of mine are looking at the new DroboPro, which makes a=
lot of disk space available via iSCSI (in addition to firewire 800),
and they were wondering how well iSCSI works with FreeBSD. I haven't=
paid attention to iSCSI support. Is there anyone using it heavily
for disk-storage under FreeBSD? Has there been much changed for
iSCSI support in the 8.x branch, or is 7.x support working fine?
I suppose you are interested in the client (initiator) side of iSCSI=
support. It hasn't changed much between 7.x and 8.x but there are
apparently some announcements of a newer version:
http://lists.freebsd.org/pipermail/freebsd-scsi/2009-March/003834.html=
I can't find any more information on it.
the latest is in:
http://www.cs.huji.ac.il/~danny/ftp/freebsd/iscsi-2.1.1.tar.gz
Thanks!
Is there anything in particular you'd like to get tested in the new
version, any significant changes or improvements?
mainly fixed some bugs, and some code cleanup.
give it a spin, and let me know what target you are testing.
btw, the default tag opening is a bit concervative (1), you might want to
change it to somewhat larger, say 64 or 128.
Hi,
camcontrol tags hangs:
Apr 9 15:36:36 terminator kernel: da3 at iscsi0 bus 0 target 1 lun 0
Apr 9 15:36:36 terminator kernel: da3: FreeBSD iSCSI DISK 0001 Fixed
Direct Access SCSI-5 device
Apr 9 15:36:38 terminator kernel: (da2:iscsi0:0:0:0): lost device
Apr 9 15:36:38 terminator kernel: (da2:iscsi0:0:0:0): removing device entry
terminator:~ivoras/temp/sbin/iscontrol# ls /dev/da*
/dev/da0 /dev/da0s1 /dev/da0s1a /dev/da0s1b /dev/da0s1c
/dev/da1 /dev/da3
terminator:~ivoras/temp/sbin/iscontrol# camcontrol tags da3
The configuration is:
target0 {
targetaddress = 161.53.72.65
targetname = iqn.2007-09.jp.ne.peach:disk1
tags = 16
}
signature.asc
Description: OpenPGP digital signature
Re: no USB mice detected on GA-MA74GM-S2
On Wed, 8 Apr 2009 22:49:25 +0200, Martin wrote Am Wed, 8 Apr 2009 21:08:05 +0200 schrieb Piotr Smyrak piotr.smy...@heron.pl: First I started with my old build of 6.2, then upgraded to 6.4 STABLE, to finally upgrade to 7.2 PRERELEASE in hope of fixing the issue. None of versions gave me USB mouse support. I have tried connecting 3 various mice. No luck. The only effect I can achieve after connecting a mouse, is a somewhat delayed message on console: I have had also problems with recent Gigabyte Mainboards and USB mice. Something is really broken in this branch. Unlike you, I could always get my mouse to work by re- attaching it. You should perhaps take a look at the BIOS USB settings, so you could get at least the re-attaching work-around to work. BIOS settings that influence the behavior of USB mice are: - any legacy USB support settings - so-called BIOS support for USB mice I have 5 options regarding USB in the BIOS: * OnChip USB controller * USB EHCI controller * USB Keyboard support * USB Mouse support * Legacy USB storage detect Should mention in the original post, I have them all but the first one disabled. I have tried many combinations including disabling the OnChip controller totally. All in vain. Because -STABLE has been really frustrating, I migrated all my desktops to -CURRENT that has the new USB-v2 stack. The USB problems disappeared there. I'm overall satisfied with -CURRENT. I've always wanted to say that FreeBSD developers do a really great job on the -CURRENT branch. It's running very stable and has plenty of new features. I know I shouldn't recommend to migrate to -CURRENT, but I'm almost sure, it runs much better than every -CURRENT I've seen before and sometimes I have the impression that it's even nicer than the -STABLE branch. Well, I am not scared by -CURRENT at all, but I was hesitating to upgrade main build since it is after all a moving target and I would like to keep my main work horse as much steady as possible. Thanks for suggestions, -- Piotr Smyrak piotr.smy...@heron.pl ___ 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: fxp: stalled transfers
pyu...@gmail.com wrote: If you can easily reproduce the issue, can you capture stalled TCP session with tcpdump on receiving host?(Make sure to disable Rx checksum offload prior to capturing the session.) I transferred a 256 kiB file and these are the tcpdumps: http://www.alpha-tierchen.de/~bkoenig/fxp0-with-tso.txt http://www.alpha-tierchen.de/~bkoenig/fxp0-without-tso.txt Actually the transfer doesn't stall although ftp and scp told me so. It becomes incredibly slow. It seems like that the chunks are too large and a smaller packet will be resent. I decreased the MTU from 1500 to 1492 and it works fine with TSO enabled. I also captured the traffic on my router: http://www.alpha-tierchen.de/~bkoenig/fxp0-with-tso-router.txt http://www.alpha-tierchen.de/~bkoenig/fxp0-without-tso-router.txt It reveals a suspect information: truncated-ip - 8 bytes missing! I almost suppose that this is a PPPoE-related configuration issue and the fxp driver is not necessarily the problem since decreasing the MTU of the LAN host solves it. Björn ___ 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: system report 7.2 beta1
On Thu, 2009-04-09 at 14:30 +0800, GOD wrote: I trace all of 7.* version on my laptop. But some thing is always a problem! 1. The acpi is not well supported. I try acpiconf -s 3 , the system will die. I take it you are running i386 then? Can you try compiling SMP support out of your kernel, disabling the second core in the BIOS, and seeing if you have the same problem? If suspend starts to work then the problem is that i386 suspend isn't properly implemented for SMP. Recently, amd64 gained suspend/resume and works on SMP. Although this support hasn't been merged back to 7.x, it might be worthwhile booting the 8.0 amd64 live CD and seeing if that works for you - if it does, there's probably more chance the amd64 support will appear in 7.x before the i386 suspend support, so maybe you could consider moving to amd64. 2 The ath0 wifi support, I test and nerver find it can transfer with more than 5MB per second rate. 3 The big problem of my laptop is the intel video card, xorg eat up half of my memory,and it's very slow moving windows . I'm afraid I can't help with these, other than to say that wireless support in 8.x is much better than in 7.x. Indeed, given how close 8.0 is to being released (a few months away, I believe), it may be best either to wait, or to consider upgrading your system to -CURRENT amd64 and seeing if your problems are already resolved. Gavin ___ 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 and iSCSI for disks.
Danny Braniss wrote:
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--enig90DADA8437A99D893FB775F8
Content-Type: text/plain; charset=3DUTF-8
Content-Transfer-Encoding: quoted-printable
Danny Braniss wrote:
Garance A Drosihn wrote:
Some friends of mine are looking at the new DroboPro, which makes=
a=3D
lot of disk space available via iSCSI (in addition to firewire 800)=
,
and they were wondering how well iSCSI works with FreeBSD. I haven=
't=3D
paid attention to iSCSI support. Is there anyone using it heavily
for disk-storage under FreeBSD? Has there been much changed for
iSCSI support in the 8.x branch, or is 7.x support working fine?
I suppose you are interested in the client (initiator) side of iSC=
SI=3D
support. It hasn't changed much between 7.x and 8.x but there are
apparently some announcements of a newer version:
http://lists.freebsd.org/pipermail/freebsd-scsi/2009-March/003834.ht=
ml=3D
I can't find any more information on it.
the latest is in:
http://www.cs.huji.ac.il/~danny/ftp/freebsd/iscsi-2.1.1.tar.gz
Thanks!
Is there anything in particular you'd like to get tested in the new
version, any significant changes or improvements?
mainly fixed some bugs, and some code cleanup.
=20
give it a spin, and let me know what target you are testing.
btw, the default tag opening is a bit concervative (1), you might want =
to
change it to somewhat larger, say 64 or 128.
Hi,
camcontrol tags hangs:
Apr 9 15:36:36 terminator kernel: da3 at iscsi0 bus 0 target 1 lun 0
Apr 9 15:36:36 terminator kernel: da3: FreeBSD iSCSI DISK 0001 Fixed
Direct Access SCSI-5 device
Apr 9 15:36:38 terminator kernel: (da2:iscsi0:0:0:0): lost device
Apr 9 15:36:38 terminator kernel: (da2:iscsi0:0:0:0): removing device en=
try
terminator:~ivoras/temp/sbin/iscontrol# ls /dev/da*
/dev/da0 /dev/da0s1 /dev/da0s1a /dev/da0s1b /dev/da0s1c
/dev/da1 /dev/da3
terminator:~ivoras/temp/sbin/iscontrol# camcontrol tags da3
The configuration is:
target0 {
targetaddress =3D 161.53.72.65
targetname =3D iqn.2007-09.jp.ne.peach:disk1
tags =3D 16
}
Q: what kernel?
Q: what target?
btw, without the camcontrol tags, is it working?
danny
___
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 and iSCSI for disks.
2009/4/9 Danny Braniss da...@cs.huji.ac.il:
The configuration is:
target0 {
targetaddress =3D 161.53.72.65
targetname =3D iqn.2007-09.jp.ne.peach:disk1
tags =3D 16
}
Q: what kernel?
Q: what target?
7-STABLE AMD64.
btw, without the camcontrol tags, is it working?
It appears it can be made to hang under some circumstances, possibly
if there is a spelling error in the configuration file.
After a reboot, both regular usage and camcontrol tags work.
___
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 and iSCSI for disks.
On Thursday 09 April 2009 10:32:05 am Danny Braniss wrote:
Danny Braniss wrote:
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--enig90DADA8437A99D893FB775F8
Content-Type: text/plain; charset=3DUTF-8
Content-Transfer-Encoding: quoted-printable
Danny Braniss wrote:
Garance A Drosihn wrote:
Some friends of mine are looking at the new DroboPro, which
makes=
a=3D
lot of disk space available via iSCSI (in addition to firewire
800)=
,
and they were wondering how well iSCSI works with FreeBSD. I
haven=
't=3D
paid attention to iSCSI support. Is there anyone using it
heavily for disk-storage under FreeBSD? Has there been much
changed for iSCSI support in the 8.x branch, or is 7.x support
working fine?
I suppose you are interested in the client (initiator) side of
iSC=
SI=3D
support. It hasn't changed much between 7.x and 8.x but there
are apparently some announcements of a newer version:
http://lists.freebsd.org/pipermail/freebsd-scsi/2009-March/00383
4.ht=
ml=3D
I can't find any more information on it.
the latest is in:
http://www.cs.huji.ac.il/~danny/ftp/freebsd/iscsi-2.1.1.tar.gz
Thanks!
Is there anything in particular you'd like to get tested in the
new version, any significant changes or improvements?
mainly fixed some bugs, and some code cleanup.
=20
give it a spin, and let me know what target you are testing.
btw, the default tag opening is a bit concervative (1), you might
want =
to
change it to somewhat larger, say 64 or 128.
Hi,
camcontrol tags hangs:
Apr 9 15:36:36 terminator kernel: da3 at iscsi0 bus 0 target 1 lun 0
Apr 9 15:36:36 terminator kernel: da3: FreeBSD iSCSI DISK 0001
Fixed Direct Access SCSI-5 device
Apr 9 15:36:38 terminator kernel: (da2:iscsi0:0:0:0): lost device
Apr 9 15:36:38 terminator kernel: (da2:iscsi0:0:0:0): removing
device en= try
terminator:~ivoras/temp/sbin/iscontrol# ls /dev/da*
/dev/da0 /dev/da0s1 /dev/da0s1a /dev/da0s1b /dev/da0s1c
/dev/da1 /dev/da3
terminator:~ivoras/temp/sbin/iscontrol# camcontrol tags da3
The configuration is:
target0 {
targetaddress =3D 161.53.72.65
targetname =3D iqn.2007-09.jp.ne.peach:disk1
tags =3D 16
}
Q: what kernel?
From his previous message it looks like 7-STABLE amd64
Q: what target?
From the targetname it looks like the recently committed net/istgt running
on another FreeBSD machine.
btw, without the camcontrol tags, is it working?
That one I can't infer. :)
JN
___
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
atapicam question
Howdy! Amd64, 7.1. Few days ago I replaced dieing dvd writer with brand new pioneer 116d. In the kernel I removed all not needed stuff and included atapicam and both cd and acd. Previously I used cd only with no hiss. Making dvd I first encountered error at the very beginning of the whole process: acd: Failure - Inquiry illegal request. Using growisofs I got another errors, but nothing that made dvd unusable: failure - read_toc illegal request and failure - unknown cmd. Dvd that contained files with typos, with (, ) and ` gave me some looking for lun message du- ring the write. Not shown in /var/log/messages anyway. Since I included atapicam into the kernel and it booted fine, it works with both device drivers. I found some posts that hal could be set not to probe writer, but it is not good, for acd to read dvd. Any opinion on this topic? Maybe some growisofs bug I'm not aware of. I have an impression dvd device is not broken, aside it is new one. Firmware version is 1.06, with 1.09 as the lattest on pioneer site. Another topic could be how to reflash dvd writer from freebsd?. Best reagards Zoran ___ 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
6.x acpi powerbutton
Hello, I am trying to figure out what happens on a soft poweroff? Is there a userspace script that gets called? Thanks, Steve ___ 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 and iSCSI for disks.
2009/4/9 John Nielsen li...@jnielsen.net: Q: what kernel? From his previous message it looks like 7-STABLE amd64 Q: what target? From the targetname it looks like the recently committed net/istgt running on another FreeBSD machine. Correct on both :) ___ 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: 6.x acpi powerbutton
on 09/04/2009 19:17 Stephen Clark said the following: Hello, I am trying to figure out what happens on a soft poweroff? Is there a userspace script that gets called? If everything works correctly, then acpi driver sends a signal to init which causes a typical graceful shutdown. BTW, was this really a question for stable ml? -- 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
Re: 6.x acpi powerbutton
Andriy Gapon wrote: on 09/04/2009 19:17 Stephen Clark said the following: Hello, I am trying to figure out what happens on a soft poweroff? Is there a userspace script that gets called? If everything works correctly, then acpi driver sends a signal to init which causes a typical graceful shutdown. BTW, was this really a question for stable ml? Probably not. But I spent a couple of hours googling without much luck so I got desperate. ;-) Is there a reason it doesn't send and event like Linux that can be acted upon by user space other than signaling init? I like to have a message written in /var/log/messages that someone pressed the powerbutton. Thanks -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) ___ 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: ZFSKnownProblems - needs revision?
Hi, in one production case (1), haven't seen panics or deadlocks for a long time, yet on another much more powerful machine (2), I could not get rid of vm_thread_new: kstack allocation failed, ultimately rendering the machine useless pretty fast. This was at least till RELENG_7/november (7.1-PRERELEASE), where I decided to stop the zfs experiment for now and went back to ufs. trying to understand now if 7.2 is worth a new try, or if, for that matter, the only reasonable wait is until 8.0. perhaps worth of note, the kstack errors still occurred (albeit after more time) with all zpools exported (and system rebooted) but the zfs.ko still loaded. only after rebooting without zfs_load=YES the server began to work seemlessly for months. I'm asking myself if/how important the underlying driver/provider (mfi, mpt, ad, ciss, etc..) can be in regard to the remaining/ recurring problems with zfs.. (since I've seen so different behaviors with different machines...)? (1) Homebrewn Opteron / 2GB RAM / SATA ad / 7.1-PRERELEASE w. usual tuning, one zpool on a SATA mirror for backups via rsync of several servers (2) DELL PE 1950 1 Quad-Xeon / 8GB RAM / LSI mpt / 7.1-PRERELEASE w. many tunings tried, one zpool on a partition on top of HW RAID 1, moderately loaded mailserver box running courier and mysql Regards, Lorenzo ___ 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
libc ABI changes in RELENG_7
Hi Building a samba package in a recent RELENG_7 box and install on a 7.1-RELEASE system I found ABI changes that make ldconfig fail. This is related to a new strndup symbol in libc that samba build autodetect and use. This is really necesary? -- josemi ___ 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: libc ABI changes in RELENG_7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jose, Jose M Rodriguez wrote: Hi Building a samba package in a recent RELENG_7 box and install on a 7.1-RELEASE system I found ABI changes that make ldconfig fail. This is related to a new strndup symbol in libc that samba build autodetect and use. This is really necesary? The only way to guarantee a package is usable under 7.1-RELEASE is to build it under a 7.1-RELEASE chroot or jail, when building it on a newer host system. That's said, we strive our best to maintain backward compatibility, i.e. make sure that newer FreeBSD versions would always run older binaries; we do want to keep some sort of upward compatibility, for instance, when you build a binary on newer FreeBSD version, it's *likely* that it can be run on older FreeBSD version, but this is not strictly guaranteed or we can not add any new functionalities into new FreeBSD versions. I personally feel very strongly against of not having a POSIX-defined libc function just because older 7.x does not have it, unless we want the whole 7.x branch to be EoL'ed soon. Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkneeYgACgkQi+vbBBjt66CUlwCeJINd92n72WiiV1fBkwR6Oisp KCkAoMDxWdNd3r1654Vddf+ZFmOILrH0 =wJnZ -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: Network sysctl tuning [was Re: ZFSKnownProblems - needs revision?]
On Wed, Apr 8, 2009 at 3:55 PM, Antony Mawer fbsd-sta...@mawer.org wrote: Freddie Cash wrote: ... We've also heavily modified /etc/sysctl.conf and upped a bunch of the network-related sysctls. Doing so increased our SSH throughput from ~30 Mbits/sec across all connections to over 90 Mbits/sec per SSH connection. Are you able to share any of these with the list? It would be useful to compare as a lot of these tunings people do individually and it would be good to allow others to test in their environments to see if they help, as well as potentially adding them to the tuning man-page. They're all taken from the HPN-SSH website and various google searches related to HPN-enabled OpenSSH. I don't know exactly what all the different, individual sysctls do, nor whether this is the most optimal setup, but here's the sysctl.conf that we use. This is on 2 systems using a quad-port gigabit NIC where the top two ports are connected via lagg(4) and the bottom two ports are connected via lagg(4), with the two laggX interfaces on separate networks. I did a bunch of scp/sftp transfers of 100 MB files filled with random data pulled from /dev/random between these two boxes tweaking the options one at a time, but didn't do too much in the way of scientific/empirical measurements and comparisons beyond the throughput data that scp/sftp shows. If there are any glaring errors, gotchas, or why would you ever do thats, let me know. :) # General network settings net.isr.direct=1# Whether to enable Direct Dispatch for netisr # IP options net.inet.ip.forwarding=0# Whether to enable packet forwarding for NAT/routing net.inet.ip.process_options=0 # Disable processing of IP options (nothing uses this field) net.inet.ip.random_id=1 # Randomise the IP header ID number net.inet.ip.redirect=0 # Whether to allow redirect packets #net.inet.ip.stealth=0 # Whether to appear in traceroute output # ICMP options net.inet.icmp.icmplim=200 # Limit ICMP packets to this many per second net.inet.icmp.drop_redirect=1 # Drop ICMP redirect packets net.inet.icmp.log_redirect=0# Don't log ICMP redirect packets # TCP options net.inet.tcp.blackhole=1# Drop packets destined to unused ports net.inet.tcp.inflight.enable=0 # Use automatic TCP window-scaling net.inet.tcp.log_in_vain=0 # Don't log the blackholed packets net.inet.tcp.path_mtu_discovery=1 # Use ICMP type 3 to find the MTU to use net.inet.tcp.recvbuf_max=16777216 # The max size of the receive buffer (16 MB) net.inet.tcp.recvspace=131072 # The initial size in bytes of the receive buffer net.inet.tcp.sack.enable=1 # Enable Selective ACKs net.inet.tcp.sendbuf_max=16777216 # The max size of the send buffer net.inet.tcp.sendspace=131072 # The initial size in bytes of the send buffer net.inet.tcp.syncookies=1 # Enable SYN cookie protection net.inet.tcp.rfc1323=1 # Enable RFC1323 extensions (TCP window scaling) # UDP options net.inet.udp.blackhole=1# Drop packets destined to unused ports net.inet.udp.checksum=1 # Enable UDP checksums net.inet.udp.log_in_vain=0 # Don't log the blackholed packets net.inet.udp.recvspace=65536# Size in bytes of the receive buffer # Debug options debug.minidump=1# Disable the small kernel core dump (only mem in use) debug.mpsafevfs=1 # Enable threaded VFS subsystem # Kernel options kern.coredump=0 # Disable kernel core dumps kern.ipc.maxsockbuf=4194304 # Set the max size of the socket buffers (4 MB) kern.ipc.somaxconn=1024 # Expand the IP listen queue kern.maxvnodes=25 # Bump up the max number of vnodes # PCI bus options hw.pci.enable_msix=1# Enable Message Signalled Interrupts - Extended hw.pci.enable_msi=1 # Enable Message Signalled Interrupts hw.pci.enable_io_modes=1# Enable alternate I/O access modes -- Freddie Cash fjwc...@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
anyone using seagate microdrives and freebsd ?
I have on and no luck in working this config out. If anyone could give any hint. I've seen this pr http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/110407 and some other cases from some searching, but no one ever said anything about success case. thanks, matheus -- We will call you cygnus, The God of balance you shall be ___ 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: fxp: stalled transfers
On Thu, Apr 09, 2009 at 11:02:06AM +0200, Bjoern Koenig wrote: pyu...@gmail.com wrote: If you can easily reproduce the issue, can you capture stalled TCP session with tcpdump on receiving host?(Make sure to disable Rx checksum offload prior to capturing the session.) I transferred a 256 kiB file and these are the tcpdumps: http://www.alpha-tierchen.de/~bkoenig/fxp0-with-tso.txt http://www.alpha-tierchen.de/~bkoenig/fxp0-without-tso.txt Actually the transfer doesn't stall although ftp and scp told me so. It becomes incredibly slow. It seems like that the chunks are too large and a smaller packet will be resent. I decreased the MTU from 1500 to 1492 and it works fine with TSO enabled. I also captured the traffic on my router: http://www.alpha-tierchen.de/~bkoenig/fxp0-with-tso-router.txt http://www.alpha-tierchen.de/~bkoenig/fxp0-without-tso-router.txt It reveals a suspect information: truncated-ip - 8 bytes missing! I almost suppose that this is a PPPoE-related configuration issue and the fxp driver is not necessarily the problem since decreasing the MTU of the LAN host solves it. I think you're right. Thanks a lot! ___ 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: anyone using seagate microdrives and freebsd ?
Nenhum_de_Nos wrote: I have on and no luck in working this config out. I remember microdrives... those are from long ago, when the C64s and ZX Spectrums ruled the world ;-) Alphons (sorry, couldn't resist) -- All right, that does it Bill [Donahue]. I'm pretty sure that killing Jesus is not very Christian. -- Pope Benedict XVI, Southpark season 11 episode 5 ___ 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: watchdog timeout
On Wed, Apr 08, 2009 at 10:41:44AM +0200, xer wrote:
Hello
I have some problems with 3Com nics, after a upgrade from 5.5-STABLE to
6.4-STABLE.
This machine has two 3com nics (one is LAN other is WAN) and i see too much
watchdog timeout on both cards.
This on/off up/down on cards, affect the interrupt to clients that are
downloading from apache web server, especially on large files.
xer:/root# dmesg
xl1: watchdog timeout
xl1: link state changed to DOWN
xl1: link state changed to UP
xl1: watchdog timeout
xl1: link state changed to DOWN
xl1: link state changed to UP
xl1: watchdog timeout
xl1: link state changed to DOWN
xl1: link state changed to UP
-
xer:/root# cat /var/run/dmesg.boot | grep xl
xl0: 3Com 3c905C-TX Fast Etherlink XL port 0xec00-0xec7f mem
0xfceffc00-0xfceffc7f irq 23 at device 11.0 on pci2
miibus0: MII bus on xl0
xlphy0: 3c905C 10/100 internal PHY on miibus0
xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
xl0: Ethernet address: 00:01:02:e0:04:1b
xl1: 3Com 3c905C-TX Fast Etherlink XL port 0xe880-0xe8ff mem
0xfceff800-0xfceff87f irq 20 at device 12.0 on pci2
miibus1: MII bus on xl1
xlphy1: 3c905C 10/100 internal PHY on miibus1
xlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
xl1: Ethernet address: 00:01:02:df:fe:ed
-
Another doubt would be my kernel config, maybe there is something wrong
that i cannot see, i'll post at the end of this post, 'cause is too long.
As you can see, the cards are 3c905C-TX model.
Someone told me to change drivers, but i cannot understand this advice.
I got same errors with same cards but with another mainboard, same problem,
watchdog appears after an upgrade from 5.4-STABLE to 6.4-STABLE.
I don't think that to change nic's pci slots, will solve the problem, i
think that maybe change the nics would resolve the matter, but i cannot
access to both FreeBSD phisically, cause the boxes are too far from me
(about 3500 km).
I'm asking you some advices, and i can i fix this problem.
p.s. with both 5.4 or 5.5 old kernel, the nics was fine.
I vaguely remember there were a couple of reports on xl(4) watchdog
timeouts. I'm not sure this came from missing Tx interrupts but
would you try attached patch?
Note, it was generated against HEAD and you should experiment the
attached patch on local box prior to applying to your production
server.
Index: sys/dev/xl/if_xl.c
===
--- sys/dev/xl/if_xl.c (revision 190876)
+++ sys/dev/xl/if_xl.c (working copy)
@@ -2097,13 +2097,13 @@
m_freem(cur_tx-xl_mbuf);
cur_tx-xl_mbuf = NULL;
ifp-if_opackets++;
+ ifp-if_drv_flags = ~IFF_DRV_OACTIVE;
cur_tx-xl_next = sc-xl_cdata.xl_tx_free;
sc-xl_cdata.xl_tx_free = cur_tx;
}
if (sc-xl_cdata.xl_tx_head == NULL) {
- ifp-if_drv_flags = ~IFF_DRV_OACTIVE;
sc-xl_wdog_timer = 0;
sc-xl_cdata.xl_tx_tail = NULL;
} else {
@@ -2540,6 +2540,9 @@
XL_LOCK_ASSERT(sc);
+ if ((ifp-if_drv_flags (IFF_DRV_RUNNING | IFF_DRV_OACTIVE)) !=
+ IFF_DRV_RUNNING)
+ return;
/*
* Check for an available queue slot. If there are none,
* punt.
@@ -2668,7 +2671,8 @@
XL_LOCK_ASSERT(sc);
- if (ifp-if_drv_flags IFF_DRV_OACTIVE)
+ if ((ifp-if_drv_flags (IFF_DRV_RUNNING | IFF_DRV_OACTIVE)) !=
+ IFF_DRV_RUNNING)
return;
idx = sc-xl_cdata.xl_tx_prod;
@@ -3207,12 +3211,31 @@
{
struct ifnet *ifp = sc-xl_ifp;
u_int16_t status = 0;
+ int misintr;
XL_LOCK_ASSERT(sc);
if (sc-xl_wdog_timer == 0 || --sc-xl_wdog_timer != 0)
return (0);
+ xl_rxeof(sc);
+ xl_txeoc(sc);
+ misintr = 0;
+ if (sc-xl_type == XL_TYPE_905B) {
+ xl_txeof_90xB(sc);
+ if (sc-xl_cdata.xl_tx_cnt == 0)
+ misintr++;
+ } else {
+ xl_txeof(sc);
+ if (sc-xl_cdata.xl_tx_head == NULL)
+ misintr++;
+ }
+ if (misintr != 0) {
+ device_printf(sc-xl_dev,
+ watchdog timeout (missed Tx interrupts) -- recovering\n);
+ return (0);
+ }
+
ifp-if_oerrors++;
XL_SEL_WIN(4);
status = CSR_READ_2(sc, XL_W4_MEDIA_STATUS);
@@ -3222,9 +3245,6 @@
device_printf(sc-xl_dev,
no carrier - transceiver cable problem?\n);
- xl_txeoc(sc);
- xl_txeof(sc);
- xl_rxeof(sc);
xl_reset(sc);
xl_init_locked(sc);
___
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
