src/sys/contrib/ipfilter/netinet/ip_state.c rev 1.38
Hi everyone. I check in cvs src/sys/contrib/ipfilter/netinet/ip_state.c I saw the following : "Sun Dec 24 02:18:36 2006 UTC (3 months ago) by darrenr TCP Window scaling was being recognised but the recorded settings were being clobbered and thus effectively disabled. MFC after: 7 days" Today is 29 March 2007. Who can MFC that rev. to STABLE_6. Thanks. __ Best regards, VipeR ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Pthreads signals
On Wed, 28 Mar 2007, Steve Watt wrote: In <[EMAIL PROTECTED]>, Daniel Eischen <[EMAIL PROTECTED]> wrote: On Wed, 28 Mar 2007, Peter Holmes wrote: How do signals work with pthreads in FreeBSD. How are process signals delivered? The best explanation of signals and threads in general is in the POSIX spec, or Butenhof's book. http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html I suspect the question was rather more specific than that, due to bad experiences with LinuxThreads. Does FreeBSD have a proper signal delivery model, where thread masks are per-signal, and signals sent to the process when all threads within the process have the signal blocked remain pending against the process so any thread may accept the signal using sigwait()/sigtimedwait()/sigwaintinfo(). These are POSIX threads, so if things don't behave as specified by or as allowed by the standard, a bug report should be filed. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em(4) losing link when if_bridge(4) addm/deletem are used
On Wed, Mar 28, 2007 at 03:30:45PM -0700, Jeremy Chadwick wrote: > On Thu, Mar 29, 2007 at 09:37:09AM +1200, Andrew Thompson wrote: > > On Tue, Mar 27, 2007 at 08:33:27PM -0700, Jeremy Chadwick wrote: > > > In the midst of the madness, I found that when doing either of the > > > following commands... > > > > > > ifconfig bridge0 addm em1 > > > ifconfig bridge0 deletem em1 > > > > > > ...I see the entire em1 interface completely reset, bringing down link, > > > then up again shortly after. The logs on my switch also confirm this. > > > > > The only other thing the bridge does to the interface when removing it > > is to reinstate IFCAP_TXCSUM, which is disabled when the interface is > > bridged. If you manually toggle this with ifconfig do you get the same > > result? > > Bingo. > > medusa# ifconfig em1 -txcsum > medusa# ifconfig em1 > em1: flags=8843 mtu 1500 > options=8 > inet 10.0.0.2 netmask 0xff00 broadcast 10.0.0.255 > ether 00:30:48:71:60:6b > media: Ethernet autoselect > status: no carrier > medusa# grep em1 /var/log/messages > Mar 28 15:29:34 medusa kernel: em1: link state changed to DOWN > Mar 28 15:29:36 medusa kernel: em1: link state changed to UP As a workaround you could remove txcsum at boot, then the bridge will not toggle it. Long term you could prod the em(4) maintainer to see if this can be resolved. Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em(4) losing link when if_bridge(4) addm/deletem are used
On Thu, Mar 29, 2007 at 09:37:09AM +1200, Andrew Thompson wrote: > On Tue, Mar 27, 2007 at 08:33:27PM -0700, Jeremy Chadwick wrote: > > In the midst of the madness, I found that when doing either of the > > following commands... > > > > ifconfig bridge0 addm em1 > > ifconfig bridge0 deletem em1 > > > > ...I see the entire em1 interface completely reset, bringing down link, > > then up again shortly after. The logs on my switch also confirm this. > > > > For sake of comparison, the bge(4) driver does not behave this way. > > > > I am aware that if_bridge(4) enables promiscuous mode on whatever > > interface is being added, ditto with -promisc on deletem. However, this > > does not appear to be the cause of the problem, because I can do > > "ifconfig em1 promisc" and "ifconfig em1 -promisc" without loss of link. > > The only other thing the bridge does to the interface when removing it > is to reinstate IFCAP_TXCSUM, which is disabled when the interface is > bridged. If you manually toggle this with ifconfig do you get the same > result? Bingo. medusa# ifconfig em1 -txcsum medusa# ifconfig em1 em1: flags=8843 mtu 1500 options=8 inet 10.0.0.2 netmask 0xff00 broadcast 10.0.0.255 ether 00:30:48:71:60:6b media: Ethernet autoselect status: no carrier medusa# grep em1 /var/log/messages Mar 28 15:29:34 medusa kernel: em1: link state changed to DOWN Mar 28 15:29:36 medusa kernel: em1: link state changed to UP -- | Jeremy Chadwickjdc at 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 "[EMAIL PROTECTED]"
Re: Pthreads signals
In <[EMAIL PROTECTED]>, Daniel Eischen <[EMAIL PROTECTED]> wrote: >On Wed, 28 Mar 2007, Peter Holmes wrote: > >> How do signals work with pthreads in FreeBSD. How are process signals >> delivered? > >The best explanation of signals and threads in general >is in the POSIX spec, or Butenhof's book. > > http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html I suspect the question was rather more specific than that, due to bad experiences with LinuxThreads. Does FreeBSD have a proper signal delivery model, where thread masks are per-signal, and signals sent to the process when all threads within the process have the signal blocked remain pending against the process so any thread may accept the signal using sigwait()/sigtimedwait()/sigwaintinfo(). I suspect the answer is yes, but I haven't played with threads on recent versions enough. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3" Internet: steve @ Watt.COM Whois: SW32-ARIN Free time? There's no such thing. It just comes in varying prices... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [SOLVED] NFS Mount problems
Tom Judge wrote: Hi, I have a HA NFS server setup, but I am having some problems with mounting the NFS shares. I have had to patch mountd to allow it to be configured with an IP to bind to, its a bit of quick hack (no docs, ipv6 etc...) but solves the problem for us where mountd sends the packets from the wrong ip. (See patch bellow). The NFS server IP is 172.31.0.200 and we have the following flags set in rc.conf: nfs_server_flags="-u -t -n 4 -h 172.31.0.200" rpcbind_flags="-h 172.31.0.200" mountd_flags="-r -p 832 -h 172.31.0.200" When I try and mount the share I get the following error the command: maverick# mount nfs-server:/usr/home /usr/home [udp] nfs-server:/usr/home: RPCPROG_MNT: RPC: Timed out [udp] nfs-server:/usr/home: RPCPROG_MNT: RPC: Timed out And the following data from tcpdump on the server: [EMAIL PROTECTED] /usr/home/mintel]# tcpdump -n 'ip host 172.31.0.2 and ip host 172.31.0.200' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on em0, link-type EN10MB (Ethernet), capture size 68 bytes 17:10:58.321858 IP 172.31.0.2.906 > 172.31.0.200.111: UDP, length 56 17:10:58.322018 IP 172.31.0.200.111 > 172.31.0.2.906: UDP, length 28 17:10:58.322231 IP 172.31.0.2.1175084341 > 172.31.0.200.2049: 40 null 17:10:58.322280 IP 172.31.0.200.2049 > 172.31.0.2.1175084341: reply ok 24 null 17:10:58.322481 IP 172.31.0.2.921 > 172.31.0.200.111: [|lwres] 17:10:58.322560 IP 172.31.0.200.111 > 172.31.0.2.921: [|lwres] 17:10:58.322731 IP 172.31.0.2.854 > 172.31.0.200.832: UDP, length 112 17:11:13.324547 IP 172.31.0.200.832 > 172.31.0.2.854: UDP, length 68 17:11:13.324652 IP 172.31.0.2 > 172.31.0.200: ICMP 172.31.0.2 udp port 854 unreachable, length 36 I can reproduce the problem on a number 6.2 Release systems (i386/amd64). Has anyone seen this before, or know of a fix? After running ktrace on the mountd process during the mount process, I noticed that mountd was trying to do a reverse DNS lookup on the address. The problem was that the DNS server was incorrectly configured and not responding to the request. Adding the client to the server hosts file fixed the problem. Sorry for the noise. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em(4) losing link when if_bridge(4) addm/deletem are used
On Tue, Mar 27, 2007 at 08:33:27PM -0700, Jeremy Chadwick wrote: > In the midst of the madness, I found that when doing either of the > following commands... > > ifconfig bridge0 addm em1 > ifconfig bridge0 deletem em1 > > ...I see the entire em1 interface completely reset, bringing down link, > then up again shortly after. The logs on my switch also confirm this. > > For sake of comparison, the bge(4) driver does not behave this way. > > I am aware that if_bridge(4) enables promiscuous mode on whatever > interface is being added, ditto with -promisc on deletem. However, this > does not appear to be the cause of the problem, because I can do > "ifconfig em1 promisc" and "ifconfig em1 -promisc" without loss of link. The only other thing the bridge does to the interface when removing it is to reinstate IFCAP_TXCSUM, which is disabled when the interface is bridged. If you manually toggle this with ifconfig do you get the same result? Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: freebsd-update problem (on 6.2)
Colin, Can I use freebsd-update to update from 6.1-STABLE-200608 to the latest version? When I try to run the program it says its not compatible... Is there a way to force it to update anyway, and is there any reason I would NOT want to force it? I'm just trying to figure out the best way to get my machine updated, which was installed from a snapshot ISO, without having to do a buildworld. Thanks! Don -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colin Percival Sent: Wednesday, March 28, 2007 11:26 AM To: Miroslav Lachman Cc: freebsd-stable@freebsd.org Subject: Re: freebsd-update problem (on 6.2) Miroslav Lachman wrote: > I did cvsup to RELENG_6_2 today and make build(world|kernel) > install(kernel|world) > > After mergemaster & reboot uname reports 6.2-RELEASE-p3 but > `freebsd-update fetch` downloads patches "to 6.2-RELEASE-p3" so I > installed them by `freebsd-update install`. > > uname reports 6.2-RELEASE-p2 after reboot! This is correct. uname(1) reports the kernel version, and the change from 6.2-RELEASE-p2 to 6.2-RELEASE-p3 did not affect the kernel. > The following files are affected by updates, but no changes have been > downloaded because the files have been modified locally: > /etc/rc.d/jail This is correct. The version you have here is not the version which was distributed with the release -- it's the version in the latest RELENG_6_2. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd-update problem (on 6.2)
Don O'Neil wrote: >Can I use freebsd-update to update from 6.1-STABLE-200608 to the latest > version? When I try to run the program it says its not compatible... Is > there a way to force it to update anyway Only by editing the freebsd-update script or by modifying uname(1). > and is there any reason I would > NOT want to force it? In general it's a bad idea, since FreeBSD Update looks at what files you had installed from the old release and whether you've modified any of them in order to decide how to upgrade to the new release. If you confuse freebsd-update enough to convince it to upgrade your non-supported installation, it's likely to overwrite modified configuration files or not update files. > I'm just trying to figure out the best way to get my machine updated, which > was installed from a snapshot ISO, without having to do a buildworld. There isn't any good solution here, yet. I might add support for the snapshot ISOs at some point (at least for upgrading to/from them -- there will not be security updates built for them). Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd-update problem (on 6.2)
Miroslav Lachman wrote: > I did cvsup to RELENG_6_2 today and make build(world|kernel) > install(kernel|world) > > After mergemaster & reboot uname reports 6.2-RELEASE-p3 but > `freebsd-update fetch` downloads patches "to 6.2-RELEASE-p3" so I > installed them by `freebsd-update install`. > > uname reports 6.2-RELEASE-p2 after reboot! This is correct. uname(1) reports the kernel version, and the change from 6.2-RELEASE-p2 to 6.2-RELEASE-p3 did not affect the kernel. > The following files are affected by updates, but no changes have > been downloaded because the files have been modified locally: > /etc/rc.d/jail This is correct. The version you have here is not the version which was distributed with the release -- it's the version in the latest RELENG_6_2. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
freebsd-update problem (on 6.2)
I did cvsup to RELENG_6_2 today and make build(world|kernel) install(kernel|world) After mergemaster & reboot uname reports 6.2-RELEASE-p3 but `freebsd-update fetch` downloads patches "to 6.2-RELEASE-p3" so I installed them by `freebsd-update install`. uname reports 6.2-RELEASE-p2 after reboot! If I try to run freebsd-update fetch again, I got this: - Looking up update.FreeBSD.org mirrors... 1 mirrors found. Fetching metadata signature from update1.FreeBSD.org... done. Fetching metadata index... done. Inspecting system... done. Preparing to download files... done. The following files are affected by updates, but no changes have been downloaded because the files have been modified locally: /etc/rc.d/jail No updates needed to update system to 6.2-RELEASE-p3. -- So there is definitely something wrong - uname reports p2, freebsd-update p3 and at last /etc/rc.d/jail seems to it locally modified, but it is not! The whole system is "GENERIC" without any modifications. Miroslav Lachman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] bge(4) patch for -STABLE
On Wednesday 28 March 2007 12:50 pm, Mike Tancsa wrote: > At 09:33 AM 3/17/2007, Mike Tancsa wrote: > >At 03:37 PM 3/16/2007, Jung-uk Kim wrote: > >>It might fix your problem (i.e., we have some fixes for BCM5750 > >>chipset family) but I am not so sure. Why don't you try it and > >> tell me? ;-) > > Hi, > Just to followup 11 days later and still no watchdog > timeouts. I would have had at least 2 with the old driver by now! > I havent tried whats in RELENG_6, just the patch you posted... But > I am guessing they are essentially the same. Thanks for fixing it! I am glad to hear it. BTW, I cannot take all the credit. It wasn't possible without help from many committers and testers. :-) Thanks, Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] bge(4) patch for -STABLE
At 09:33 AM 3/17/2007, Mike Tancsa wrote: At 03:37 PM 3/16/2007, Jung-uk Kim wrote: It might fix your problem (i.e., we have some fixes for BCM5750 chipset family) but I am not so sure. Why don't you try it and tell me? ;-) Hi, Just to followup 11 days later and still no watchdog timeouts. I would have had at least 2 with the old driver by now! I havent tried whats in RELENG_6, just the patch you posted... But I am guessing they are essentially the same. Thanks for fixing it! bge0: mem 0xfe5f-0xfe5f irq 19 at device 0.0 on pci4 miibus1: on bge0 brgphy0: on miibus1 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:e0:81:59:2b:06 [EMAIL PROTECTED]:0:0: class=0x02 card=0x165914e4 chip=0x165914e4 rev=0x11 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5750A1 NetXtreme Gigabit Ethernet PCI Express' class = network subclass = ethernet cap 01[48] = powerspec 2 supports D0 D3 current D0 cap 03[50] = VPD cap 05[58] = MSI supports 8 messages, 64 bit cap 10[d0] = PCI-Express 1 endpoint ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
NFS Mount problems
Hi,
I have a HA NFS server setup, but I am having some problems with
mounting the NFS shares. I have had to patch mountd to allow it to be
configured with an IP to bind to, its a bit of quick hack (no docs,
ipv6 etc...) but solves the problem for us where mountd sends the
packets from the wrong ip. (See patch bellow).
The NFS server IP is 172.31.0.200 and we have the following flags set in
rc.conf:
nfs_server_flags="-u -t -n 4 -h 172.31.0.200"
rpcbind_flags="-h 172.31.0.200"
mountd_flags="-r -p 832 -h 172.31.0.200"
When I try and mount the share I get the following error the command:
maverick# mount nfs-server:/usr/home /usr/home
[udp] nfs-server:/usr/home: RPCPROG_MNT: RPC: Timed out
[udp] nfs-server:/usr/home: RPCPROG_MNT: RPC: Timed out
And the following data from tcpdump on the server:
[EMAIL PROTECTED] /usr/home/mintel]# tcpdump -n 'ip host 172.31.0.2 and ip
host 172.31.0.200'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em0, link-type EN10MB (Ethernet), capture size 68 bytes
17:10:58.321858 IP 172.31.0.2.906 > 172.31.0.200.111: UDP, length 56
17:10:58.322018 IP 172.31.0.200.111 > 172.31.0.2.906: UDP, length 28
17:10:58.322231 IP 172.31.0.2.1175084341 > 172.31.0.200.2049: 40 null
17:10:58.322280 IP 172.31.0.200.2049 > 172.31.0.2.1175084341: reply ok
24 null
17:10:58.322481 IP 172.31.0.2.921 > 172.31.0.200.111: [|lwres]
17:10:58.322560 IP 172.31.0.200.111 > 172.31.0.2.921: [|lwres]
17:10:58.322731 IP 172.31.0.2.854 > 172.31.0.200.832: UDP, length 112
17:11:13.324547 IP 172.31.0.200.832 > 172.31.0.2.854: UDP, length 68
17:11:13.324652 IP 172.31.0.2 > 172.31.0.200: ICMP 172.31.0.2 udp port
854 unreachable, length 36
I can reproduce the problem on a number 6.2 Release systems (i386/amd64).
Has anyone seen this before, or know of a fix?
Thanks
Tom
/usr/src/sys/usr.sbin/mountd/
Index: mountd.c
===
--- mountd.c(revision 37)
+++ mountd.c(working copy)
@@ -257,7 +257,7 @@
fd_set readfds;
struct sockaddr_in sin;
struct sockaddr_in6 sin6;
- char *endptr;
+ char *endptr, *svcaddr;
SVCXPRT *udptransp, *tcptransp, *udp6transp, *tcp6transp;
struct netconfig *udpconf, *tcpconf, *udp6conf, *tcp6conf;
pid_t otherpid;
@@ -290,7 +290,7 @@
errx(1, "NFS server is not available or loadable");
}
- while ((c = getopt(argc, argv, "2dlnp:r")) != -1)
+ while ((c = getopt(argc, argv, "2dlnp:rh:")) != -1)
switch (c) {
case '2':
force_v2 = 1;
@@ -307,6 +307,9 @@
case 'l':
dolog = 1;
break;
+case 'h':
+svcaddr = optarg;
+break;
case 'p':
endptr = NULL;
svcport = (in_port_t)strtoul(optarg, &endptr, 10);
@@ -392,6 +395,7 @@
sin.sin_len = sizeof(struct sockaddr_in);
sin.sin_family = AF_INET;
sin.sin_port = htons(svcport);
+sin.sin_addr.s_addr = inet_addr(svcaddr);
bzero(&sin6, sizeof(struct sockaddr_in6));
sin6.sin6_len = sizeof(struct sockaddr_in6);
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
amd64 ahd scsi error/problem with tyan mb
hi some else has seen this? With more then 2 scsi disks on one channel I get the error below. The machine seems to work on all disks after then. With one or two disks the machine boots well. The error does not appear with FC6 and Tyan support argues a freebsd driver problem. some idea what I can do? Waiting 10 seconds for SCSI devices to settle ahd0: Invalid Sequencer interrupt occurred. >> Dump Card State Begins < ahd0: Dumping Card State at program address 0x23c Mode 0x0 Card was paused INTSTAT[0x0] SELOID[0x2] SELID[0x10] HS_MAILBOX[0x0] INTCTL[0x80] SEQINTSTAT[0x0] SAVED_MODE[0x11] DFFSTAT[0x33] SCSISIGI[0x0] SCSIPHASE[0x0] SCSIBUS[0x0] LASTPHASE[0x1] SCSISEQ0[0x0] SCSISEQ1[0x12] SEQCTL0[0x0] SEQINTCTL[0x6] SEQ_FLAGS[0x0] SEQ_FLAGS2[0x0] QFREEZE_COUNT[0x3] KERNEL_QFREEZE_COUNT[0x3] MK_MESSAGE_SCB[0xff00] MK_MESSAGE_SCSIID[0xff] SSTAT0[0x0] SSTAT1[0x0] SSTAT2[0x0] SSTAT3[0x0] PERRDIAG[0x0] SIMODE1[0xa4] LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x0] LQOSTAT0[0x0] LQOSTAT1[0x0] LQOSTAT2[0x0] SCB Count = 16 CMDS_PENDING = 0 LASTSCB 0x CURRSCB 0xd NEXTSCB 0xff00 qinstart = 36 qinfifonext = 37 QINFIFO: 0xf WAITING_TID_QUEUES: Pending list: 15 FIFO_USE[0x0] SCB_CONTROL[0x48] SCB_SCSIID[0x7] Total 1 Kernel Free SCB list: 14 13 1 2 3 4 5 6 7 8 9 10 11 12 0 Sequencer Complete DMA-inprog list: Sequencer Complete list: Sequencer DMA-Up and Complete list: Sequencer On QFreeze and Complete list: ahd0: FIFO0 Free, LONGJMP == 0x8000, SCB 0xe SEQIMODE[0x3f] SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89] SG_CACHE_SHADOW[0x2] SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x5] SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10] ahd0: FIFO1 Free, LONGJMP == 0x8063, SCB 0xd SEQIMODE[0x3f] SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89] SG_CACHE_SHADOW[0x2] SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x5] SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10] LQIN: 0x8 0x0 0x0 0xe 0x0 0x1 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 ahd0: LQISTATE = 0x0, LQOSTATE = 0x0, OPTIONMODE = 0x42 ahd0: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x1 ahd0: SAVED_SCSIID = 0x0 SAVED_LUN = 0x0 SIMODE0[0xc] CCSCBCTL[0x0] ahd0: REG0 == 0x7ffd, SINDEX = 0x10e, DINDEX = 0x106 ahd0: SCBPTR == 0xe, SCB_NEXT == 0xff00, SCB_NEXT2 == 0xd CDB 12 20 0 80 8 25 STACK: 0x237 0x2 0x0 0x0 0x0 0x0 0x0 0x0 < Dump Card State Ends >> SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! Copied 18 bytes of sense data offset 12: 0x70 0x0 0x6 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x29 0x2 0x0 0x0 0x0 0x0 Copied 18 bytes of sense data offset 12: 0x70 0x0 0x6 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x29 0x2 0x2 0x0 0x0 0x0 Copied 18 bytes of sense data offset 12: 0x70 0x0 0x6 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x29 0x2 0x2 0x0 0x0 0x0 da0 at ahd0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged Queueing Enabled da0: 35074MB (71833096 512 byte sectors: 255H 63S/T 4471C) da1 at ahd0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled da1: 70007MB (143374744 512 byte sectors: 255H 63S/T 8924C) da2 at ahd0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-3 device da2: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled da2: 70007MB (143374744 512 byte sectors: 255H 63S/T 8924C) Trying to mount root from ufs:/dev/da0s1a -- João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: possible bug in pxeboot with TFTP support
On Mon, Mar 26, 2007 at 03:16:15PM -0400, Ryan J. Taylor wrote: > I compiled pxeboot with TFTP support by doing: > cd /usr/src/sys/boot > make -DLOADER_TFTP_SUPPORT > > I have clients booting via PXE and grabbing their root filesystem from a > memory disk. However, there was a long delay in the boot sequence. > tcpdump revealed that after downloading pxeboot, the client was sending > RPC traffic, presumably looking for NFS. This caused the boot to stall > for 30 seconds or so until the loader spit out "NFS MOUNT RPC error: 60" > and then continued booting via tftp. Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=91720 Regards, Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> pgpUeDGfq1ywv.pgp Description: PGP signature
Re: Dell SAS5 Performance Issue
On Tue, 27 Mar 2007, Matthew Jacob wrote: On 3/27/07, Richard Tector <[EMAIL PROTECTED]> wrote: Thank you for the quick reply. Is there any information I could obtain that would be of use to you in tracking this one down? not at the momeny- it's really that I won't have time until april As said, I won't have the chance to test anything from this evening on and I had a few minutes so I added the usual printfs to get the detailed information for the reported mpt_cam_event()s. : grep ^mpt dell_pe860-20070328-02.log mpt0: port 0xec00-0xecff mem 0xfe9fc000-0xfe9f,0xfe9e-0xfe9e irq 16 at device 8.0 on pci2 mpt0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xec00 mpt0: Reserved 0x4000 bytes for rid 0x14 type 3 at 0xfe9fc000 mpt0: [GIANT-LOCKED] mpt0: MPI Version=1.5.12.0 mpt0: Event on. mpt0: SAS discovery started. mpt0: SAS PHY(0x00) link status: Rate: 3.0 Gbps. mpt0: SAS PHY(0x01) link status: Rate: 3.0 Gbps. mpt0: SAS discovery done. That's also what the controller reports (but I think the driver does not try to re-neg/discover anything itself here?). Most likely that's it from me on the write performance topic. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
