Re: enable ECC in OS code?
In 200908271130.18073.er...@apsara.com.sg, er...@apsara.com.sg wrote: Hi, On 27 August 2009 am 06:53:36 Steve Watt wrote: In 4a954a35.4030...@icyb.net.ua, a...@icyb.net.ua wrote: Assuming that ECC data lanes are connected between the two on motherboard, and given that BIOS doesn't perform any ECC setup (nor there is any option to control that) - would it be possible to turn on ECC from OS code? Or is it too late in the game already? It's about 100 times easier to have the BIOS do this. First off, it's usually quite specific to the chip set exactly how to how should it be done at OS level at all when the OS is loaded into RAM? I do not thing that normal PC hardware is capable of handling this. Only code running in a ROM can do this. Disable the ECC error reporting and copy memory back to itself? Again, quite controller-specific. That said, the BIOS should do it, and any that doesn't is broken. -- 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: enable ECC in OS code?
In 4a954a35.4030...@icyb.net.ua, a...@icyb.net.ua wrote: Here is a question that I am afraid I know an answer for. I have some ECC capable hardware: 1) Athlon II with embedded memory controller that can do ECC 2) DRAM modules with ECC Assuming that ECC data lanes are connected between the two on motherboard, and given that BIOS doesn't perform any ECC setup (nor there is any option to control that) - would it be possible to turn on ECC from OS code? Or is it too late in the game already? It's about 100 times easier to have the BIOS do this. First off, it's usually quite specific to the chip set exactly how to do it. Next, if ECC wasn't enabled previously, the ECC bytes will all be wrong, which means that you'll have to rewrite all of memory after you've turned it on. Oh, and you have to fetch the code that rewrites the ECC from the memory with incorrect ECC to do that. If the BIOS is broken to the extent that it doesn't enable ECC on a system that it should be available, whine at the vendor. -- 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Question about PCIe networks
In 20090519193727.7512e4fc...@xroff.net, emor...@xroff.net write: I have read recently this http://www.wwpi.com/hardware/hardware/6540-ethernet-tunneling-through-pci-express-inter-processor-communication-low-latency-storage-io (From a company that makes PCIe switches to connect multiple root complexes together.) It's about using PCIe to connect 2 servers directly, without using ethernet or other hardware. Can it be done in FreeBSD? What is needed to know? Certainly. Non-transparent PCIe bridges basically create windows of memory space into the other side. You'd need the two sides to agree on the data structures, and what signalling mechanism to use for packet availability. Quite straightforward, really. What you'll need is the bridge hardware that connects to the two systems, the two systems, datasheets, and some time. Each side of the bridge would allocate some DMAable memory, and set up the bridge so that is visible to the other side. Set up a pair of rings (one per direction of traffic), and go. -- 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: tcsh loses the foreground process group?
On Wed, Dec 03, 2008 at 03:58:36PM -0800, Nate Eldredge wrote: On Tue, 2 Dec 2008, Steve Watt wrote: In [EMAIL PROTECTED] Steve Watt wrote: [ tcsh 6.15.00 ] The symptom is that when I do a long-ish running task inside a `` expansion that I then ^C, nobody gets the foreground process group... I never get a prompt back after the ^C, and ^T gets me load: 0.27 no foreground process group I've got another FreeBSD machine available that was running tcsh 6.14.00, and it does _NOT_ display the problem. When I build 6.15.00 on that same box (/usr/src is more up to date than the install right now), that does fail. Thanks for the report. It looks like this is yet another manifestation of a problem in tcsh, where it does inappropriate things in a vfork'ed subshell. In my tests, running tcsh with -F (which causes it to use fork instead of vfork) causes the problem to go away. It is also present in 7.0-RELEASE and probably all later versions. Did the behavior change between 6.14.00 and 6.15.00? (Yeah, OK, I can go look myself.) OK, I went and looked. Answer: Yep, lots of additions of inappropriate things in backeval(). But it no longer has a 10K limit. There are several open bugs related to this problem, but so far they do not seem to have attracted the interest of any committers. Among them are: bin/41297 bin/52746 bin/125185 amd64/128259 bin/129378 (which you just opened) The fix is simple: make -F the default. There is a minor performance penalty, but that's a small price to pay for correct behavior. A more involved fix would be to make tcsh not do inappropriate things after vfork (modifying global variables), or at least clean up before exiting, but IMHO that is less clean; vfork really shouldn't be used here at all. Actually, there's another cost to making -F default: It makes hashstat rather less useful. OK, it's not like it's that useful to begin with, and is arguably a debugging function, but it's a side effect. As for a possible why? -F changes the hashstat behavior so? Probably because it's counting on not-quite-legal vfork() activity. Ugh. I'd managed to forget how unfun the code inside that shell is. I'll try to forget again. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tcsh loses the foreground process group?
In article [EMAIL PROTECTED] you write: [ ... ] I'm running 6-STABLE (6.4-PRE as of 24 Nov right now), tcsh 6.15.00, which shows tcsh 6.15.00 (Astron) 2007-03-03 (i386-intel-FreeBSD) options wide,nls,dl,al,kan,sm,rh,color,filec as $version. The symptom is that when I do a long-ish running task inside a `` expansion that I then ^C, nobody gets the foreground process group... I never get a prompt back after the ^C, and ^T gets me load: 0.27 no foreground process group [ ... ] One portable reproduction: # cd /usr/src # less `egrep -lir '^Foo.*baz' *` ^Cload: 0.02 no foreground process group (I typed ^C ^T) SIGKILL to the shell seems to be the only way to get things back to normal. I've gotten one me too, which indicated that SIGHUP to the shell will also make it go away, but does not solve the problem. I've got another FreeBSD machine available that was running tcsh 6.14.00, and it does _NOT_ display the problem. When I build 6.15.00 on that same box (/usr/src is more up to date than the install right now), that does fail. Thus I'm pretty comfortable saying that it's a tcsh bug of some sort, and probably a regression. Hopefully this can be fixed (PR being filed now) before 6.4 releases... -- 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
tcsh loses the foreground process group?
(Please don't cc: me on replies, I can usually keep up with -hackers.) I've run into this about 5 or 6 times recently, and it seems to have survived the last couple of world updates. I'm running 6-STABLE (6.4-PRE as of 24 Nov right now), tcsh 6.15.00, which shows tcsh 6.15.00 (Astron) 2007-03-03 (i386-intel-FreeBSD) options wide,nls,dl,al,kan,sm,rh,color,filec as $version. The symptom is that when I do a long-ish running task inside a `` expansion that I then ^C, nobody gets the foreground process group... I never get a prompt back after the ^C, and ^T gets me load: 0.27 no foreground process group Sending SIGCHLD and/or SIGCONT to the tcsh doesn't seem to make any difference at all. The tcsh is sitting in pause WCHAN, which seems sensible. A truss on tcsh reveals (oddly enough) that it's sitting in sigsuspend(). Sending it signals makes it loop through a wait4() call and go back into sigsuspend(). It happens running either as root (from sudo) or as a regular user. It happens under xterm, under ssh sessions, and on a direct console login. One portable reproduction: # cd /usr/src # less `egrep -lir '^Foo.*baz' *` ^Cload: 0.02 no foreground process group (I typed ^C ^T) SIGKILL to the shell seems to be the only way to get things back to normal. I'm not sure how to isolate it further - it seems likely that this is a bug in the kernel, rather than in tcsh, but the session management stuff is pretty hairy in both places. Does anyone have debugging thoughts? -- 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Doubt] Can a PCI device communicate with another PCI or other
In [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I think a PCI device can communicate with another PCI device directly without the intervention of the CPU. Absolutely. Happens a fair amount in embedded networking systems (among others). The host is responsible for enumeration and resource assignment, but once that's complete, any device on the bus can see all others. Whether that's useful depends rather heavily on the devices on the bus, obviously. TANSTAAFL applies, though, in that multiple initiators must be careful not to step on each others' accesses. -- 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Path to executable of current process?
In [EMAIL PROTECTED], Michael B Allen [EMAIL PROTECTED] wrote: Actually what I'm *really* trying to do is port some code that invokes GDB to do a backtrace and I need to give GDB the path to the executable of the current process (e.g. on linux this is /proc/pid/exe) and the pid of the process to trace (easy - getpid). The first argument is trickey since FreeBSD frequently does not have a /proc filesystem. So it seems kvm_getargv should have this path no? # mount_procfs proc /proc # /bin/ls -l /proc/pid/file Note that if the executable on disk gets replaced, this won't work. -- 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: p_vmspace in syscall
In [EMAIL PROTECTED], Nicolas Cormier [EMAIL PROTECTED] wrote: On 7/4/07, Robert Watson [EMAIL PROTECTED] wrote: When operating in a system call, the 'td' argument to the system call function is the current thread pointer. You can follow td-td_proc to get to the current process (and therefore, its address space). In general, I prefer mapping user pages into kernel instead of kernel pages into user space, as it reduces the chances of leakage of kernel data to user space, and there are some useful primitives for making this easier. For example, take a look at the sf_buf infrastructure used for things like socket zero-copy send, which manages a temporary kernel mapping for a page. netmalloc syscall does something like that: - query distant host to allocate size - receive an id from distant host - malloc in kernel size - map the buffer to user process (*) netdetach syscall: - send data to distant host netattach syscall: - get data from host - malloc in kernel size - map the buffer to user process (*) What this really sounds like is network shared memory or remote DMA. I would architect this to remove as much of the management code as possible from the kernel (i.e. query the distant host, get ID, etc.) into a userland daemon. Depending on the exact semantics you want, you'll probably need to write a new kind of pager. Basically, at the netmalloc call, you would simply pass the reqest back to the userland daemon, which would format it in whatever way is needed to cross the net, send the request off, receive the ID, and give association information back to the kernel (number of pages, protections, whatever). Then the call would map the new pages into the userland process just like it was a shared memory segment. At detach time, the message would again go to the userland daemon, which would map the pages locally and probably use a zero-copy send to ship the data to the remote host. There are some fun potential interactions in there in code I haven't looked at in a long time. I'll resist the urge to dive in and hack something together, since VM systems have a way of being tricky in unexpected places. -- 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sendto() giving EPERM outside a jail
On Mar 28, 10:23, Daniel O'Connor wrote: } Subject: Re: sendto() giving EPERM outside a jail } } On Saturday 24 March 2007 02:47, Steve Watt wrote: } According to my reading of the man page it is not possible to get this } error unless I'm using jails (which I'm not). The code in question does. } That's probably a buglet in the man page. } } I guess it would be nice if the man page(s) mentioned that a firewall could } cause EPERM. I have seen it before with other apps but the sendto() confused } me. It's one of those unpleasant interactions between pluggable subsystems, so it's a bit tough to document -- there are various different firewalls available, after all. } Can someone shed light on what the problem is? The application appears to } work fine even with this error though. } } man setsockopt, search for SO_BROADCAST. } } It doesn't say anything about EPERM. If you're sending broadcast broadcast or multicast datagrams, you need to set the SO_BROADCAST socket option, as well. -- 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sendto() giving EPERM outside a jail
In [EMAIL PROTECTED],
Daniel O'Connor [EMAIL PROTECTED] wrote:
Hi,
I am trying to port miniupnpd (http://miniupnp.tuxfamily.org/) and by in large
it seems to work fine (evil idea as it is :) However it spews out a lot of..
miniupnpd[13010]: sendto(udp_notify): Operation not permitted
According to my reading of the man page it is not possible to get this error
unless I'm using jails (which I'm not). The code in question does..
That's probably a buglet in the man page.
memset(sockname, 0, sizeof(struct sockaddr_in));
sockname.sin_family = AF_INET;
sockname.sin_port = htons(PORT);
sockname.sin_addr.s_addr = inet_addr(UPNP_MCAST_ADDR);
while(known_service_types[i])
{
snprintf(bufr, sizeof(bufr),
NOTIFY * HTTP/1.1\r\n
HOST:%s:%d\r\n
...
n = sendto(s, bufr, strlen(bufr), 0,
(struct sockaddr *)sockname, sizeof(struct sockaddr_in) );
(line 278 of miniupnpd.c).
Can someone shed light on what the problem is? The application appears to work
fine even with this error though.
man setsockopt, search for SO_BROADCAST.
--
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-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sendto() giving EPERM outside a jail
In article [EMAIL PROTECTED],
Daniel O'Connor [EMAIL PROTECTED] wrote:
Hi,
I am trying to port miniupnpd (http://miniupnp.tuxfamily.org/) and by in large
it seems to work fine (evil idea as it is :) However it spews out a lot of..
miniupnpd[13010]: sendto(udp_notify): Operation not permitted
According to my reading of the man page it is not possible to get this error
unless I'm using jails (which I'm not). The code in question does..
memset(sockname, 0, sizeof(struct sockaddr_in));
sockname.sin_family = AF_INET;
sockname.sin_port = htons(PORT);
sockname.sin_addr.s_addr = inet_addr(UPNP_MCAST_ADDR);
while(known_service_types[i])
{
snprintf(bufr, sizeof(bufr),
NOTIFY * HTTP/1.1\r\n
HOST:%s:%d\r\n
...
n = sendto(s, bufr, strlen(bufr), 0,
(struct sockaddr *)sockname, sizeof(struct sockaddr_in) );
(line 278 of miniupnpd.c).
Can someone shed light on what the problem is? The application appears to work
fine even with this error though.
man setsockopt, search for SO_BROADCAST.
--
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-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: harddrive no memory ---FreeBSD scenario
In [EMAIL PROTECTED], Rudy wrote: A chip level loading of the core kernel would be the only way. So its not possible todo without a completly new hardware infrastructre design. - I'm wanting todo this because computers are too slow. You need to learn a little more about the parts of a computer. Perhaps go to Google groups, and read comp.arch for a couple of months, making sure you understand all of the references. Disk drives are about 6 orders of magnitude (1,000,000x) slower than DDR memory. It takes a few tens of nanoseconds to read a random address from DDR, a few tens of milliseconds to read a random address from a disk. Note that DDR isn't the fastest memory in the system, either -- there are the L1 and L2 (and sometimes L3) caches as well. -- 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Trying to join an already exited pthread
In [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Just wondering: If I was to try and join a pthread that already exited, would there be an error message output and/or errno set to an error value, or would a system hang? Was the thread created with detach state set PTHREAD_CREATE_DETACHED or PTHREAD_CREATE_JOINABLE? If it was PTHREAD_CREATE_JOINABLE, has the thread already been joined? You should be able to join a thread that was created joinable, only once. If you join it again, or join a thread that was created detached, the results are unspecified in POSIX. There is an error status that may be returned, but it may do other bad things to your system. Note that pthread_join doesn't set errno; it returns an error value directly. I would never expect the system to hang, though the application might. If your application is hanging, make sure that you're not trying to call pthread_join from within a signal handler. It this variable on Unix OSes? That the results are unspecified? No. What unspecified means? Absolutely. -- 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Interesting TCP issue
On Jan 22, 9:15, Uwe Doering wrote:
} Subject: Re: Interesting TCP issue
} Steve Watt wrote:
} In [EMAIL PROTECTED], Julian Elischer wrote:
}
} [ Snip discussion of symptoms of window scaling broken when
} talking to at least the skype mail servers. ]
}
} we have seen this since 4.x
} I think a fix may be in 7.0 but I'm not sure..
} I thin kthere is a problem when the far end sets the window down to 1
} but scales it by a factor of 2^{big number}.
}
} Andre, can you check out this problem and MFC the correct fix
} if it is indeed the same problem in 6.2?
}
} It is the same problem; I took the (one-line) fix as indicated by
}
}
http://cvs.ironport.com/cgi-bin/viewcvs.cgi/freebsd/src/sys/netinet/tcp_syncache.c.diff?r1=1.84r2=1.85
}
} (well, not cvs.ironport.com, which doesn't seem to exist at the moment),
} and applied the diff from 1.84 to
} 1.85 and to a 6.2-PRERELEASE box updated around 25 Dec 06.
} It works like a charm.
}
} I would vote to MFC 1.85 now that 6.2 is out.
}
} I wonder whether it is that easy. As far as I can tell the commit to
} HEAD actually comprised changes to three files:
I wonder as well, but that single diff fixes the problem I was running
into with the skype mail servers.
}
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c.diff?r1=1.290r2=1.291
}
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_syncache.c.diff?r1=1.84r2=1.85
}
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_var.h.diff?r1=1.127r2=1.128
}
} How about the modifications in 'tcp_input.c'? Are they relevant to the
} problem this thread is about? If so, assessing the correctness of an
} MFC might prove to be a little harder.
Looking at it, yeah, those probably need to be picked up in some form as
well. I didn't look closely at the tcpdump after, only observing that
it worked where it didn't before.
Hmm.
--
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-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipw3945 assistance?
In [EMAIL PROTECTED], xoundmind [EMAIL PROTECTED] wrote: Hi, Please excuse my noob status...I would like some assistance with installing the wpi-freebsd driver on a 6_2 Release setup. Please feel free to be a specific as possible, as I suspect there are many others who wish to get this working (and are not used to applying non-standard drivers.) What have you tried so far, and how is it failing? http://www.catb.org/~esr/faqs/smart-questions.html Steve -- 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Interesting TCP issue
In [EMAIL PROTECTED], Julian Elischer wrote:
[ Snip discussion of symptoms of window scaling broken when
talking to at least the skype mail servers. ]
we have seen this since 4.x
I think a fix may be in 7.0 but I'm not sure..
I thin kthere is a problem when the far end sets the window down to 1
but scales it by a factor of 2^{big number}.
Andre, can you check out this problem and MFC the correct fix
if it is indeed the same problem in 6.2?
It is the same problem; I took the (one-line) fix as indicated by
http://cvs.ironport.com/cgi-bin/viewcvs.cgi/freebsd/src/sys/netinet/tcp_syncache.c.diff?r1=1.84r2=1.85
(well, not cvs.ironport.com, which doesn't seem to exist at the moment),
and applied the diff from 1.84 to
1.85 and to a 6.2-PRERELEASE box updated around 25 Dec 06.
It works like a charm.
I would vote to MFC 1.85 now that 6.2 is out.
The diff, for those who are following along at home, is:
===
RCS file: /usr/local/www/cvsroot/FreeBSD/src/sys/netinet/tcp_syncache.c,v
retrieving revision 1.84
retrieving revision 1.85
diff -u -p -r1.84 -r1.85
--- src/sys/netinet/tcp_syncache.c 2006/02/09 21:29:02 1.84
+++ src/sys/netinet/tcp_syncache.c 2006/02/28 23:05:59 1.85
@@ -682,7 +682,7 @@ syncache_socket(sc, lso, m)
tp-t_flags |= TF_NOOPT;
if (sc-sc_flags SCF_WINSCALE) {
tp-t_flags |= TF_REQ_SCALE|TF_RCVD_SCALE;
- tp-requested_s_scale = sc-sc_requested_s_scale;
+ tp-snd_scale = sc-sc_requested_s_scale;
tp-request_r_scale = sc-sc_request_r_scale;
}
if (sc-sc_flags SCF_TIMESTAMP) {
--
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-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Interesting TCP issue
On Jan 1, 23:56, Julian Elischer wrote: } Subject: Re: Interesting TCP issue } Steve Watt wrote: } One of my users is having trouble receiving mail from Skype. So, } after some sniffing, I discovered this: } } # tcpdump -vv -s 1500 -i dc0 -X net 213.244.128.0/18 } tcpdump: lestening on dc0, link-type EN10MB (Ethernet), capture size 1500 bytes } 13:18:13.607493 IP (tos 0x20, ttl 58, id 12896, offset 0, flags [DF], proto: TCP (6), length: 74) share.skype.net.50406 wattres.watt.com.smtp: P, cksum 0x9297 (correct), 4072464914:4072464936(22) ack 1248591103 win 46 nop,nop,timestamp 2511885672 520058954 [ sneck ] } } And no responses from my system. } } Interesting. I presume it has something to do with the } idiotically small window the remote server is advertising. So I } set net.inet.tcp.minmss down to 46, and that resulted in a RST } being spit back to skype's server when its retransmit happened. } [...] } } turn off window scaling (I forget the sysctl) and see if that helps } It's broken in some versions of freeBSD at least. Duh, should've mentioned the version: FreeBSD wattres.Watt.COM 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #6: Tue Dec 26 11:46:36 PST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/WATTRES i386 I did the cvsup just before the build time above. I just turned off net.inet.tcp.rfc1323; we'll see if that helps on the next polling attempt by skype's server. -- 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Interesting TCP issue
On Jan 2, 0:06, Steve Watt wrote: } Subject: Re: Interesting TCP issue } On Jan 1, 23:56, Julian Elischer wrote: } } Subject: Re: Interesting TCP issue } } Steve Watt wrote: } } One of my users is having trouble receiving mail from Skype. So, } } after some sniffing, I discovered this: } } } } # tcpdump -vv -s 1500 -i dc0 -X net 213.244.128.0/18 } } tcpdump: lestening on dc0, link-type EN10MB (Ethernet), capture size 1500 bytes } } 13:18:13.607493 IP (tos 0x20, ttl 58, id 12896, offset 0, flags [DF], proto: TCP (6), length: 74) share.skype.net.50406 wattres.watt.com.smtp: P, cksum 0x9297 (correct), 4072464914:4072464936(22) ack 1248591103 win 46 nop,nop,timestamp 2511885672 520058954 } [ sneck ] } } } } And no responses from my system. } } } } Interesting. I presume it has something to do with the } } idiotically small window the remote server is advertising. So I } } set net.inet.tcp.minmss down to 46, and that resulted in a RST } } being spit back to skype's server when its retransmit happened. } } [...] } } } } turn off window scaling (I forget the sysctl) and see if that helps } } It's broken in some versions of freeBSD at least. } } Duh, should've mentioned the version: } } FreeBSD wattres.Watt.COM 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #6: Tue Dec 26 11:46:36 PST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/WATTRES i386 } } I did the cvsup just before the build time above. } } I just turned off net.inet.tcp.rfc1323; we'll see if that helps on the } next polling attempt by skype's server. We have a winner -- setting net.inet.tcp.rfc1323=0 let the mail message come in on the next try. p0f's guess at the remote machine is that it's a newer Linux 2.6 box; that doesn't seem like an interoperability problem that should've slipped through -BETA, given how common those are... The exchange with rfc1323 looks completely normal, with the remote end giving windows of 5840. But it ended the conversation in a very Windows way by sending a couple of RSTs after the FIN exchange. Or has that brokenness now extended itself to Linux as well? -- 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Interesting TCP issue
One of my users is having trouble receiving mail from Skype. So, after some sniffing, I discovered this: # tcpdump -vv -s 1500 -i dc0 -X net 213.244.128.0/18 tcpdump: lestening on dc0, link-type EN10MB (Ethernet), capture size 1500 bytes 13:18:13.607493 IP (tos 0x20, ttl 58, id 12896, offset 0, flags [DF], proto: TCP (6), length: 74) share.skype.net.50406 wattres.watt.com.smtp: P, cksum 0x9297 (correct), 4072464914:4072464936(22) ack 1248591103 win 46 nop,nop,timestamp 2511885672 520058954 0x: 4520 004a 3260 4000 3a06 c609 d5f4 aa50 [EMAIL PROTECTED]:..P 0x0010: 425d 8582 c4e6 0019 f2bc e212 4a6b fcff B]..Jk.. 0x0020: 8018 002e 9297 0101 080a 95b8 5568 ..Uh 0x0030: 1eff 784a 4548 4c4f 2073 6861 7265 2e73 ..xJEHLO.share.s 0x0040: 6b79 7065 2e6e 6574 0d0a kype.net.. 0x: 4520 004a 3261 4000 3a06 c608 d5f4 aa50 [EMAIL PROTECTED]:..P 0x0010: 425d 8582 c4e6 0019 f2bc e212 4a6b fcff B]..Jk.. 0x0020: 8018 002e 1d67 0101 080a 95b8 ca98 .g.. 0x0030: 1eff 784a 4548 4c4f 2073 6861 7265 2e73 ..xJEHLO.share.s 0x0040: 6b79 7065 2e6e 6574 0d0a kype.net.. And no responses from my system. Interesting. I presume it has something to do with the idiotically small window the remote server is advertising. So I set net.inet.tcp.minmss down to 46, and that resulted in a RST being spit back to skype's server when its retransmit happened. 13:20:13.610975 IP (tos 0x20, ttl 58, id 12897, offset 0, flags [DF], proto: TCP (6), length: 74) share.skype.net.50406 wattres.watt.com.smtp: P, cksum 0x1d67 (correct), 0:22(22) ack 1 win 46 nop,nop,timestamp 2511915672 520058954 13:20:13.611036 IP (tos 0x20, ttl 64, id 39789, offset 0, flags [DF], proto: TCP (6), length: 40) wattres.watt.com.smtp share.skype.net.50406: R, cksum 0x5b51 (correct), 1248591103:1248591103(0) win 0 0x: 4520 0028 9b6d 4000 4006 571e 425d 8582 E..([EMAIL PROTECTED]@.W.B].. 0x0010: d5f4 aa50 0019 c4e6 4a6b fcff ...PJk.. 0x0020: 5004 5b51 P...[Q.. The packets shown here are the complete capture. I can hand-type stuff to the skype server and it appears to get through just fine, but when it connects to my box, no segments make their way back to skype. I can see them sitting in the Send-Q: # netstat -f inet Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address(state) [ ... ] tcp4 0213 wattres.smtp share.skype.net.50406 ESTABLISHED [ ... ] Very strange. Any opinions on possible workarounds, since I'm not expecting Skype to fix their (broken) system? -- 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Interesting TCP issue
In [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: From Steve Watt on Monday, January 01, 2007 4:37 PM # tcpdump -vv -s 1500 -i dc0 -X net 213.244.128.0/18 [ snip ] Interesting. I presume it has something to do with the idiotically small window the remote server is advertising. So I set net.inet.tcp.minmss down to 46, and that resulted in a RST being spit back to skype's server when its retransmit happened. Are you sure the window is really that small and that window scaling was not negotiated at the start of the connection? The initial packets are not captured here so I can't tell. Is it possible to get a really complete capture of a session including the initial handshake? Good point. Here's the full capture from a different session. Same tcpdump flags. My FreeBSD box (a.k.a. wattres.watt.com) said wscale 1, so that's (if I remember my TCP correctly) what gets used. Note after the ACK from share.skype.net, my machine doesn't ACK the segment with the EHLO in it, so we get retransmits. At the application level, I can see that sendmail got the EHLO, because the milter cb_helo callback happened. I wasn't at the box when this particular connection attempt happened, so I couldn't see the Send Q in netstat, but this is exactly the same appearance as the snippet I showed earlier, so I'm presuming a similar failure occurred. Very strange behavior. 22:44:17.578821 IP (tos 0x20, ttl 58, id 56305, offset 0, flags [DF], proto: TCP (6), length: 60) share.skype.net.59816 wattres.watt.com.smtp: S, cksum 0xf0c3 (correct), 1414414327:1414414327(0) win 5840 mss 1460,sackOK,timestamp 2520376326 0,nop,wscale 7 0x: 4520 003c dbf1 4000 3a06 1c86 d5f4 aa50 E..[EMAIL PROTECTED]:..P 0x0010: 425d 8582 e9a8 0019 544e 3ff7 B]..TN?. 0x0020: a002 16d0 f0c3 0204 05b4 0402 080a 0x0030: 9639 e406 0103 0307.9.. 22:44:17.578958 IP (tos 0x0, ttl 64, id 30930, offset 0, flags [DF], proto: TCP (6), length: 64) wattres.watt.com.smtp share.skype.net.59816: S, cksum 0xb1c9 (correct), 1236670735:1236670735(0) ack 1414414328 win 65535 mss 1460,nop,wscale 1,nop,nop,timestamp 554156269 2520376326,sackOK,eol 0x: 4500 0040 78d2 4000 4006 79c1 425d 8582 [EMAIL PROTECTED]@[EMAIL PROTECTED] 0x0010: d5f4 aa50 0019 e9a8 49b6 190f 544e 3ff8 ...PI...TN?. 0x0020: b012 b1c9 0204 05b4 0103 0301 0x0030: 0101 080a 2107 c0ed 9639 e406 0402 !9.. 22:44:17.742243 IP (tos 0x20, ttl 58, id 56306, offset 0, flags [DF], proto: TCP (6), length: 52) share.skype.net.59816 wattres.watt.com.smtp: ., cksum 0xf13d (correct), 1:1(0) ack 1 win 46 nop,nop,timestamp 2520376367 554156269 0x: 4520 0034 dbf2 4000 3a06 1c8d d5f4 aa50 [EMAIL PROTECTED]:..P 0x0010: 425d 8582 e9a8 0019 544e 3ff8 49b6 1910 B]..TN?.I... 0x0020: 8010 002e f13d 0101 080a 9639 e42f .=...9./ 0x0030: 2107 c0ed!... 22:44:17.785110 IP (tos 0x0, ttl 64, id 30938, offset 0, flags [DF], proto: TCP (6), length: 64) wattres.watt.com.57166 share.skype.net.auth: S, cksum 0x6899 (correct), 2124104998:2124104998(0) win 65535 mss 1460,nop,wscale 1,nop,nop,timestamp 554156474 0,sackOK,eol 0x: 4500 0040 78da 4000 4006 79b9 425d 8582 [EMAIL PROTECTED]@[EMAIL PROTECTED] 0x0010: d5f4 aa50 df4e 0071 7e9b 4526 ...P.N.q~.E 0x0020: b002 6899 0204 05b4 0103 0301 h... 0x0030: 0101 080a 2107 c1ba 0402 !... 22:44:17.947113 IP (tos 0x20, ttl 58, id 0, offset 0, flags [DF], proto: TCP (6), length: 40) share.skype.net.auth wattres.watt.com.57166: R, cksum 0xc429 (correct), 0:0(0) ack 2124104999 win 0 0x: 4520 0028 4000 3a06 f88b d5f4 aa50 E..([EMAIL PROTECTED]:..P 0x0010: 425d 8582 0071 df4e 7e9b 4527 B]...q.N~.E' 0x0020: 5014 c429 P) 22:44:17.952929 IP (tos 0x0, ttl 64, id 30939, offset 0, flags [DF], proto: TCP (6), length: 98) wattres.watt.com.smtp share.skype.net.59816: ., cksum 0x3baf (correct), 1:47(46) ack 1 win 33304 nop,nop,timestamp 554156642 2520376367 0x: 4500 0062 78db 4000 4006 7996 425d 8582 [EMAIL PROTECTED]@.y.B].. 0x0010: d5f4 aa50 0019 e9a8 49b6 1910 544e 3ff8 ...PI...TN?. 0x0020: 8010 8218 3baf 0101 080a 2107 c262 ;...!..b 0x0030: 9639 e42f 3232 3020 7761 7474 7265 732e .9./220.wattres. 0x0040: 7761 7474 2e63 6f6d 2045 534d 5450 2053 watt.com.ESMTP.S 0x0050: 656e 646d 6169 6c20 382e 3133 2e38 2f38 endmail.8.13.8/8 0x0060: 2e31 .1 22:44:18.115814 IP (tos 0x20, ttl 58, id 56307, offset 0, flags [DF], proto: TCP (6), length: 52
Re: Infrequent disk system hang on 5.4-RELEASE-p8
(OK, I'm *waaay* behind on -hackers.) In [EMAIL PROTECTED] you write: We have an older server, running 5.4-RELEASE-p8 and used primarily for email, which hangs every couple of weeks. The hang seems to be in the disk I/O system. Based on the times of the hangs, the triggering event seems to be running dump. We have a serial console set up, I broke to the debugger and got the following. Since the hang is in the disk I/O system, a dump is not possible. The many versions of inetd are likely due to users attempting to POP their email. Any suggestions or tips on how to track this down and get it resolved would be appreciated. This looks very much like a bug I ran across a while ago. Look for snapshots and innds in the subject line. It doesn't seem like this has been resolved. You may slap my hand for not filing a bug report previously; I'm about to do that. The solution, so far, seems to be upgrade to 6.x. Whee. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9 Internet: steve @ Watt.COM Whois: SW32-ARIN Free time? There's no such thing. It just comes in varying prices... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nvi for serious hacking
In article [EMAIL PROTECTED] you write: Hello, FreeBSD people. First thing to mention is that I'm very experienced Emacs user. I was using it [ snip reasons for becoming a VI user ] and according to documentation it has powerful editing mechanism. It is. So, my question goes to all FreeBSD hackers who uses `nvi' as their general editor. Is it possible to do serious hacking with it? More accurate: I mostly use vim, not nvi. Reasons: - vim can do syntax highlighting. - vim does smart indentation correctly for my value of correctly. * What programming features it support? (Does it have something like etags? Does it have interface to gdb? And such other things..) Ctags originated with vi. I can't imagine why an editor should interface with gdb -- that's what other windows are for. * Is it possible to use it comfortable with Dvorak layout? (I noticed some bindings that relies on keys arrangement) I use a Dvorak keyboard all the time. It works just fine; your fingers have already learned the hard part. Besides, j and k are still next to each other, and I almost never use h or l for moving left/right (usually use space or W for right and 0 to go to beginning of line). * How to setup it to standard FreeBSD C code indentation? And don't use tabs as well. :set tabstop=8 shiftwidth=4 Use tabs. They're part of the FreeBSD standard, last I checked, but that's an area of religious discussion I try to avoid. It's hard choice for me to switch old good Emacs to something new, so please give me your opinions. I've tried emacs several times, and keep going back to vi because I don't like hitting so many modifier keys. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9 Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: perl's tie problem
In article [EMAIL PROTECTED] you write: Hi all, Consider the following except from a perl program: tie(%foodb, 'MLDBM', $BAR_FILE, O_CREAT | O_RDWR, 0666) or die(Cannot open $BAR_FILE: $!\n); I expect it to create a new $BAR_FILE, if none existed, with 0666 permissions. But it doesn't. It creates a file with default umask specified permissions - 0644. So I have to manually do chmod on that file afterwards. Is there anything I don't understand? %uname -a FreeBSD doom.homeunix.org 4.11-STABLE FreeBSD 4.11-STABLE #0: Tue Jul 5 21:05:20 MSD 2005 [...] i386 umask applies after the open call's permissions, and is used to remove bits from the value passed in to the open. That's the way POSIX says it works, and that's how it works on UNIX machines. Down in the guts of the open() syscall, there's a line that effectively says file_permissions = passed_in_permissions ~umask; It's working as designed. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9 Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
getdirtybuf()'s kdb_backtrace fired
A number of times yesterday. That's a first on this system, though I've seen the lock order reversal problem with ffs suspend vs fsync(). Anyhoo, the traces: Aug 9 15:08:26 wattres kernel: KDB: stack backtrace: kdb_backtrace(c0931dd8,2,c5afb0cc,0,22) at kdb_backtrace+0x2f getdirtybuf(d0287bac,0,1,c5afb0cc,1) at getdirtybuf+0x28 flush_deplist(c253c94c,1,d0287bd4,d0287bd8,0) at flush_deplist+0x4a flush_inodedep_deps(c15ee800,33c24,8,c08b2c61,c27d4c60) at flush_inodedep_deps+0x98 softdep_sync_metadata(d0287c98,0,c08b2c61,137,0) at softdep_sync_metadata+0x95 ffs_fsync(d0287c98,0,c08a5b1c,bd5,0) at ffs_fsync+0x3c0 fsync(c1dbb780,d0287d04,c08bb2dd,3e7,1) at fsync+0x15a syscall(2f,2f,2f,bfbfabb0,bfbfaba8) at syscall+0x291 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (95, FreeBSD ELF32, fsync), eip = 0x282cb56b, esp = 0xbfbfab7c, ebp = 0xbfbfb468 --- Aug 9 15:08:27 wattres kernel: KDB: stack backtrace: kdb_backtrace(c0931dd8,2,c5b27030,0,22) at kdb_backtrace+0x2f getdirtybuf(d05e3bac,0,1,c5b27030,1) at getdirtybuf+0x28 flush_deplist(c29e42cc,1,d05e3bd4,d05e3bd8,0) at flush_deplist+0x4a flush_inodedep_deps(c15ee800,33c26,8,c08b2c61,c21f3000) at flush_inodedep_deps+0x98 softdep_sync_metadata(d05e3c98,0,c08b2c61,137,0) at softdep_sync_metadata+0x95 ffs_fsync(d05e3c98,0,c08a5b1c,bd5,0) at ffs_fsync+0x3c0 fsync(c2adfc00,d05e3d04,c08bb2dd,3e7,1) at fsync+0x15a syscall(2f,2f,2f,bfbfabb0,bfbfaba8) at syscall+0x291 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (95, FreeBSD ELF32, fsync), eip = 0x282cb56b, esp = 0xbfbfab7c, ebp = 0xbfbfb468 --- Aug 9 15:08:27 wattres kernel: KDB: stack backtrace: kdb_backtrace(c0931dd8,2,c5b5f6d8,0,22) at kdb_backtrace+0x2f getdirtybuf(cf873bac,0,1,c5b5f6d8,1) at getdirtybuf+0x28 flush_deplist(c2a71ecc,1,cf873bd4,cf873bd8,0) at flush_deplist+0x4a flush_inodedep_deps(c15ee800,33c28,8,c08b2c61,c234b420) at flush_inodedep_deps+0x98 softdep_sync_metadata(cf873c98,0,c08b2c61,137,0) at softdep_sync_metadata+0x95 ffs_fsync(cf873c98,0,c08a5b1c,bd5,0) at ffs_fsync+0x3c0 fsync(c167,cf873d04,c08bb2dd,3e7,1) at fsync+0x15a syscall(2f,2f,2f,bfbfabb0,bfbfaba8) at syscall+0x291 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (95, FreeBSD ELF32, fsync), eip = 0x282cb56b, esp = 0xbfbfab7c, ebp = 0xbfbfb468 --- Aug 9 15:10:16 wattres kernel: KDB: stack backtrace: kdb_backtrace(c0931dd8,2,c5b50f38,0,22) at kdb_backtrace+0x2f getdirtybuf(d02d6bac,0,1,c5b50f38,1) at getdirtybuf+0x28 flush_deplist(c24860cc,1,d02d6bd4,d02d6bd8,0) at flush_deplist+0x4a flush_inodedep_deps(c15ee800,33cff,8,c08b2c61,c177a840) at flush_inodedep_deps+0x98 softdep_sync_metadata(d02d6c98,0,c08b2c61,137,0) at softdep_sync_metadata+0x95 ffs_fsync(d02d6c98,0,c08a5b1c,bd5,0) at ffs_fsync+0x3c0 fsync(c179c780,d02d6d04,c08bb2dd,3e7,1) at fsync+0x15a syscall(2f,2f,2f,bfbfc630,bfbfc628) at syscall+0x291 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (95, FreeBSD ELF32, fsync), eip = 0x282cb56b, esp = 0xbfbfc5fc, ebp = 0xbfbfcee8 --- Aug 9 15:10:52 wattres kernel: KDB: stack backtrace: kdb_backtrace(c0931dd8,2,c5b46d6c,0,22) at kdb_backtrace+0x2f getdirtybuf(d018cbac,0,1,c5b46d6c,1) at getdirtybuf+0x28 flush_deplist(c229394c,1,d018cbd4,d018cbd8,0) at flush_deplist+0x4a flush_inodedep_deps(c15ee800,33cc1,8,c08b2c61,c1f69b58) at flush_inodedep_deps+0x98 softdep_sync_metadata(d018cc98,0,c08b2c61,137,0) at softdep_sync_metadata+0x95 ffs_fsync(d018cc98,0,c08a5b1c,bd5,0) at ffs_fsync+0x3c0 fsync(c1b21300,d018cd04,c08bb2dd,3e7,1) at fsync+0x15a syscall(2f,2f,2f,810f560,0) at syscall+0x291 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (95, FreeBSD ELF32, fsync), eip = 0x282cb56b, esp = 0xbfbf94fc, ebp = 0xbfbfaed8 --- Aug 9 15:11:10 wattres kernel: KDB: stack backtrace: kdb_backtrace(c0931dd8,2,c5b3a10c,0,22) at kdb_backtrace+0x2f getdirtybuf(d0327bac,0,1,c5b3a10c,1) at getdirtybuf+0x28 flush_deplist(c2a7184c,1,d0327bd4,d0327bd8,0) at flush_deplist+0x4a flush_inodedep_deps(c15ee800,33d0f,8,c08b2c61,c1f20e70) at flush_inodedep_deps+0x98 softdep_sync_metadata(d0327c98,0,c08b2c61,137,0) at softdep_sync_metadata+0x95 ffs_fsync(d0327c98,0,c08a5b1c,bd5,0) at ffs_fsync+0x3c0 fsync(c2166480,d0327d04,c08bb2dd,3e7,1) at fsync+0x15a syscall(2f,2f,2f,bfbfc630,bfbfc628) at syscall+0x291 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (95, FreeBSD ELF32, fsync), eip = 0x282cb56b, esp = 0xbfbfc5fc, ebp = 0xbfbfcee8 --- The system in question is 5-STABLE updated around 17Z on 2 May. It's running inn, sendmail, and a bevy of milterish things, but is otherwise pretty quiet, a few thousand email per day, no jails, no weird (i.e. all are ufs or devfs) filesystems in use. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9 Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices
Re: unitialized memory is all zeros...why not garbage instead?
Mike Hunter [EMAIL PROTECTED] wrote: On Jun 11, Dag-Erling Smrgrav wrote: Mike Hunter [EMAIL PROTECTED] writes: I have a feeling that I'm missing something really obvious, but I'm having trouble understanding why the following program: [...] Never prints anything but 0's. Because the kernel always hands processes pre-zeroed pages. Thanks for setting me straight. I guess it wasn't this way on DOS where I first learned C++ and I've assumed garbage ever since :) Is the pre-zeroing of malloc'd memory documented somewhere? By my reading of the malloc manapge... Careful now: The return value in memory from malloc() is not directly related to the return value in memory from sbrk(). malloc() may give the application back memory that was free()d previously by the same application. New pages that come out of sbrk() are 0s, but those aren't always needed to fulfill a malloc() request. The calloc() function allocates space for number objects, each size bytes in length. The result is identical to calling malloc() with an argument of ``number * size'', with the exception that the allocated memory is explicitly initialized to zero bytes. ...it seems like it's saying that malloc (as opposed to calloc) is NOT pre-zeroed. Is there a different document I should be reading? And if calloc() grabs something from the in-process used, now free pool, it will be zeroed. If malloc() grabs something from that same pool, it won't be. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9 Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: snapshots and innds
On Jun 1, 15:24, Juergen Unger wrote: } Subject: Re: snapshots and innds } Hi ! } } I don't know if its may or may not be from the same reason: } On an 5.4-p1 I started using snapshots on loopback mouted } files with mdconfig. First I seems to be all ok but then } more first one, then more and more processes get stuck in some } (for me) unknown state and in the end even the start of the } login shell for the serial console hang. Since I did not } know how to look more into detail with this stuck processes } the only way was to power-cycle. } What can I do to track down this problem when I am able } to reproduce it on the my testmachine (which is identical } except memory to the system where it happend) ? You will need to compile DDB into your kernel. When the machine starts getting ill, if you can still run ps -axl, and you're seeing this problem, you'll see a bunch of processes with wchan of suspfs. If you can't run ps, hit Ctrl+Alt+ESC on the system console, and do ps there. The wmesg column on a number of processes/threads will say suspfs, and somewhere there'll be a mksnap_ffs waiting on ufs. If that's not what it looks like, you're not seeing this problem. The best choice at that point would be to type call doadump at the DDB prompt to get a kernel dump (going through doadump seems to be the most reliable way to get a usable dump, at least for me). -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9 Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: snapshots and innds
,
frac = 14633034536159281822}, p_uu = 128520517, p_su = 329272740, p_iu = 1,
p_uticks = 16437, p_sticks = 42112, p_iticks = 0, p_profthreads = 0,
p_maxthrwaits = 0, p_traceflag = 0, p_tracevp = 0x0, p_tracecred = 0x0,
p_textvp = 0xc19aa210, p_siglist = {__bits = {0, 0, 0, 0}}, p_lock = 0 '\0',
p_sigiolst = {slh_first = 0x0}, p_sigparent = 20, p_sig = 0, p_code = 0,
p_stops = 0,
p_stype = 0, p_step = 0 '\0', p_pfsflags = 0 '\0', p_nlminfo = 0x0, p_aioinfo
= 0x0,
p_singlethread = 0x0, p_suspcount = 0, p_xthread = 0x0, p_boundary_count = 0,
p_magic = 3203398350, p_comm =
innd\000tart\000ic\000\000\000\000\000\000\000,
p_pgrp = 0xc2a00c40, p_sysent = 0xc093a320, p_args = 0xc2a09380,
p_cpulimit = 9223372036854775807, p_nice = 0 '\0', p_xstat = 0, p_klist = {
kl_lock = 0xc1c4e230, kl_list = {slh_first = 0x0}}, p_numthreads = 1,
p_numksegrps = 1, p_md = {md_ldt = 0xc1c569a0}, p_itcallout = {c_links = {sle
= {
sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0,
c_arg = 0x0, c_func = 0, c_flags = 8}, p_unused2 = 0x0, p_acflag = 1, p_ru
= 0x0,
p_peers = 0x0, p_leader = 0xc1c4e1c4, p_emuldata = 0x0, p_label = 0x0,
p_sched = 0xc1c4e388}
OK, so why is inn holding a locked vnode while it's sleeping for the
suspend? That's pretty clear -- there's a vn_lock(vp) which happens to
be the vnode in question (0xc19af318) in vm_object_sync(), line 1022.
Now for the really hard question: Fixes. The obvious (but not so
elegant) fix is for the snapshot creation code to run under Giant,
which will hold vm_object_sync out at the correct place.
But that's *adding* Giant, which seems like a bad idea.
Also, it seems like this bug should be easily reproduced by having
a process do a lot of msync() while another creates snapshots. I
don't have a box that's scratch enough to try running that on,
though.
--
Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9
Internet: steve @ Watt.COM Whois: SW32
Free time? There's no such thing. It just comes in varying prices...
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
EPERM from write()
(0x0301) len 205
Handshake: ServerKeyExchange
TLS Record Handshake (22) TLS 1.0 (0x0301) len 166
Handshake: CertificateRequest
{client} {mybox} TCP A seq=161 ack=1794 len=0
{mybox} {client} TCP FPA seq=1794 ack=161 len=1201
Continuation of certificate pile
TLS Record Handshake (22) TLS 1.0 (0x0301) len 205
Handshake: ServerKeyExchange
TLS Record Handshake (22) TLS 1.0 (0x0301) len 166
Handshake: CertificateRequest
{client} {mybox} TCP A seq=161 ack=2996 len=146
TLS Record Handshake (22) TLS 1.0 (0x0301) len 7
Handshake: Certificate (0 certificates)
TLS Record Handshake (22) TLS 1.0 (0x0301) len 70
Handshake: ClientKeyExchange (len 66)
TLS Record ChangeCipherSpec TLS 1.0 (0x0301) len 1
TLS Record Handshake (22) TLS 1.0 (0x0301) len 48
Handshake: Encrypted
{mybox} {client} TCP RST seq=2996 ack={0} len=0
The offset sequence number in the first FIN segment from my
FreeBSD box (sequence 1796, when 1794 is the next expected)
is reproduceable.
Another odd thing is that the client responded to the SSL record
from my server, which I find mildly unexpected since there's no
ServerHelloDone message. I suppose that could be because the
data got pushed up the SSL stack because of the FIN, and it didn't
notice.
Extra intriguingly, the ISC server that's running the DHCP
mailing list can successfully transfer mail, and it uses TLS.
As can any number of other servers...
This appears to have broken sometime between late February and
mid April, but enough sites work that I didn't notice it until
recently.
I'm pretty stumped, and looking for ideas... Solving the TLS
handshake problem is first, but that 2 byte skip in sequence
numbers is _weird_. I suppose it could be related somehow.
--
Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9
Internet: steve @ Watt.COM Whois: SW32
Free time? There's no such thing. It just comes in varying prices...
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Route/arp help?
In article [EMAIL PROTECTED] you write: On 4/13/05, Iasen Kostov [EMAIL PROTECTED] wrote: M. Parsons wrote: Honestly I have no clue why its not working, it should be simple, but it isnt.. Here is what the arp cache shows and the routing table (and its ed0, not de0, my mistake in original message). arp: (after doing the arp -s command) modem (10.0.0.1) at 00:0b:23:2a:b0:c4 on ed0 permanent [ethernet] Why do you set mac address static at all ? Huh? I dont understand what youre saying. He's wondering why ARP doesn't just work. The only command I typed was arp -s 10.0.0.1 00:0b:23:2a:b0:c4 , which creates the arp address I should want. (my modems mac address is 00:0b:etc) The only thing I can possibly seeing as being screwed up, is seeing as I have a default gateway, when I do a telnet 10.0.0.1 its using my internet gateway instead of the ed0 device. Which is why I thought I needed a route command to force a 10.0.0.1 connection to go through ed0. (linux needed the route command...) Oh well, Ive probably confused you, and myself as well. :-) I think you're trying to over-complexify the problem. All you really need to do is: # ifconfig ed0 alias 10.0.0.2/24 # telnet 10.0.0.1 No silly route commands, no forcing of ARP. Just add the IP address to the interface and do your connect. My guess is that the same is true in Linux, but I don't know the exact syntax there. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9 Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Causing a process switch to test a theory.
On Mar 21, 10:05, Matthew Hagerty wrote: } Steve Watt wrote: } In [EMAIL PROTECTED], } [EMAIL PROTECTED] wrote: } That's another layer of indirection, though. If all of the children } have separate pipes to the parent, and then the parent logs to your } program, all should be fine. } } That's an interesting idea about each child having a pipe open back to } the parent, but I don't think that's what is happening. I'm pretty sure } each child has the logging pipe open directly. Here is an fstat: } There is a grouping like this for each Apache child process that's runing: } geniehttpd 61320 root / 2 drwxr-xr-x 512 r } geniehttpd 61320 wd / 2 drwxr-xr-x 512 r } geniehttpd 61320 text /usr 5110792 -rwxr-xr-x 9766440 r } geniehttpd 613200 /dev 8 crw-rw-rw-null r } geniehttpd 613201 /dev 8 crw-rw-rw-null w } geniehttpd 613202 /usr 5110968 -rw-r--r-- 494192 w } geniehttpd 61320 15 /usr 5110968 -rw-r--r-- 494192 w } geniehttpd 61320 16 /usr 5110969 -rw-r--r-- 451616 w } geniehttpd 61320 17 /usr 5110981 -rw-r--r-- 1056219 w } geniehttpd 61320 18 /usr 5111084 -rw-r--r-- 3886425 w } geniehttpd 61320 19* internet stream tcp c5d1e2d0 } geniehttpd 61320 20 /usr 578 prw-rw-rw- 0 w } geniehttpd 61320 21 /usr 578 prw-rw-rw- 0 w } geniehttpd 61320 22 /usr 578 prw-rw-rw- 0 w } geniehttpd 61320 23 /usr 578 prw-rw-rw- 0 w } geniehttpd 61320 24 /usr 5110835 -rw-r--r-- 573236 w } } My pipe listener (fd 0), which each child has open 4 times on fd 20 - 23: } root pglogd 519 root / 2 drwxr-xr-x 512 r } root pglogd 519 wd / 2 drwxr-xr-x 512 r } root pglogd 519 text /usr 8528219 -rwxr-xr-x 22793 r } root pglogd 5190 /usr 578 prw-rw-rw- 0 rw } root pglogd 5191 /usr 598 -rw-r--r-- 0 r } root pglogd 5192 /usr 598 -rw-r--r-- 0 w } root pglogd 5193* local stream c5dcb7a8 - c5dcb71c There aren't any pipes in your fstat output, but if I look at my currently running Apache, I see that there are pipes around, and everyone's got the same ones (they're fds 5 and 6 with my config). So yeah, I'd say that you've identified a problem, and it's some combination of good luck that hasn't gotten someone tripped. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9 Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Causing a process switch to test a theory.
In [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: I think I have found a possible bug in Apache's logging when using their reliable pipe feature, but I'd like to test it prior to submitting a bug report (or possibly a patch.) Of course I posted a message on the Apache development forum before posting here, but I have had no response from that group. And based on your description, I think I agree. My understanding of PIPE_BUF is that it is the largest amount of data the kernel will guarantee to be atomic when writing to a pipe. Thus if more than one process is writing to the same pipe, and more than PIPE_BUF bytes needs to be written, there is the chance of the data being interleaved due to a context switch during write(), or between multiple calls to write() in order to write all required data. Yes, that is exactly the POSIX semantic for PIPE_BUF. There are a lot of tricky details in there that are not fully obvious, and it's now been long enough (6 years) that I've forgotten the exact details. There are some weird interactions between O_NONBLOCK and PIPE_BUF, but it looks like some of them have been ironed out in recent versions of the standard. I've been reading the Apache source code to try and determine if PIPE_BUF is taken into consideration while logging entries to a pipe. What appears to happen is that if a single log entry is more than 512 bytes, it is simply written to the the pipe without regard to PIPE_BUF. Then there is definitely a risk of interleaving. This is basically a race condition -- if you're lucky the log reader can cope, but that depends greatly on the guts of the logger. In this situation (each child logging it's own entries) it seems there is the possibility that a child could be preempted during it's call to write() when trying to write more than PIPE_BUF bytes of log data. What I'd like to do is create a test where I would be making requests to Apache that would cause log entries longer than PIPE_BUF in length, then be able to show the interleaving of log entries due to the PIPE_BUF limit being exceeded. I would guess that the easiest way to run into this is to cause lots of processes to write larger blocks to the same pipe (are they all really writing to the exact same pipe? If not, no problem!) at the same time. An SMP box might be able to tickle this one better. Under the conditions such that cls-log_fd is a pipe (inherited from the parent), len PIPE_BUF, and there are multiple child processes all logging entries with this code. Assuming they're all writing to the same log_fd, then you might have a problem. Knowing if Apache could possibly write interleaved logs when writing to a pipe is critical to a program I'm developing which receives log entries from Apache via a pipe. That's another layer of indirection, though. If all of the children have separate pipes to the parent, and then the parent logs to your program, all should be fine. But at the kernel level, yes, writes longer than PIPE_BUF might get interleaved. The longer the write, the higher the probability, so for your test, if you can generate, say, 10K writes over and over, you can probably trip it. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9 Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sched_4BSD
[ Attempted to clean up citations, apologies if I mis-attribute something ] In article [EMAIL PROTECTED], Kamal R. Prasad [EMAIL PROTECTED] wrote: Kamal--- Julian Elischer [EMAIL PROTECTED] wrote: Julian Kamal R. Prasad wrote: Kamal--- Julian Elischer [EMAIL PROTECTED] wrote: JulianKamal R. Prasad wrote: KamalMaybe the freebsd implementation should implement KamalNPTL in entirety. JulianNPTL? JulianNew Pthreads Library from Library? No, Native POSIX Threads Library for Linux. It's a Linux implementation of kernel-level threads that was spearheded by Ulrich Drepper. It fixes most (all?) of the ugly signal problems that LinuxThreads had. KamalYes. Julianisn't that GPL'd? Yes. KamalNo -it is a standard. The linux implementation of nptl Kamalis gpl'ed. No, POSIX 1003.1 is the standard, the thread portion was known for some time as 1003.1c, but was combined in with the base. NPTL is a particular (less brain damaged than LinuxThreads) implementation of the POSIX thread standard. Likewise, scheduler activations are a decent implementation of threads. I'll refrain from commenting further about libc_r. Julian so how does that differ from what we have ... a Julian native pthreads library? KamalI just said if it was conformant with NPTL, thread and Kamalprocess scheduling would co-exist. Uh, as far as I understand, in NPTL, each thread gets a scheduler slot, and it is my understanding that there is nothing to protect against the issue that Julian is asking about (1000 threads of a single process *do* get 1000 times the time slices). Whether that is a bug or a feature depends very heavily on the system load. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9 Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sched_4BSD
In [EMAIL PROTECTED], Kamal R. Prasad [EMAIL PROTECTED] wrote: --- Steve Watt [EMAIL PROTECTED] wrote: [ snip ] NPTL is a particular (less brain damaged than LinuxThreads) implementation of the POSIX thread standard. Likewise, scheduler activations are a decent implementation of doesn't that have a problem with M:N performance (M |= N)? Problem? Scheduler activations may be used to build M:N systems, but that is not a requirement -- you can easily build a 1:1 (all threads are system contention scope) system with activations. Admittedly, at this point in industry experience, most threads experts will say that M:N threading usually isn't worth the implementation headaches. But there are definite classes of problem, often having to do with certain styles of user-interface design or a less-than-optimal object system, where thousands of threads are a useful developer convenience. Very many processes with thousands of threads in them will drag down a 1:1 system pretty rapidly. Julian so how does that differ from what we have ... a Julian native pthreads library? KamalI just said if it was conformant with NPTL, thread and Kamalprocess scheduling would co-exist. Uh, as far as I understand, in NPTL, each thread gets a scheduler slot, and it is my understanding that there is nothing to protect against the issue that Julian is asking about (1000 threads of a single process *do* get 1000 times the time slices). (AFAIK) Referring to the POSIX std (and not NPTL) -if threads were defined within process scope and not system scope -the scheduling attributes of the process will apply. Yes, and a system that has both system scope and process scope is usually called an M:N system. I will grant that it is possible for the kernel to be aware of all of the threads in the system (i.e. a 1:1 model) but handle contention scope correctly. I don't think anyone has built such a system, but would be happy to be proven wrong -- it'd be a useful advancement of the art. One challenge is accounting for time on threads that don't do much work when awakened before going back to sleep -- if there are 1000 process-scope threads, and all of them run for half a millisecond and block, in the aggregate you need to charge the process the entire 500mS, or the timesharing characteristics won't come out right. It's somewhat challenging to do that charging cheaply. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9 Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: clock time in milliseconds into a c program
In article [EMAIL PROTECTED] you write: Hi, I need to clock the function execution time into a C program. I know /usr/include/time.h library but I need to clock the time in milliseconds. Any suggestions, links? % man clock_gettime Is nanoseconds too much? -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9 Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Determining userland return address (from syscall)
In article [EMAIL PROTECTED] you write: [ snip ] The solution I am about to implement is based on a custom setuid syscall, that would allow limited list of processes to obtain root privileges from a limited set of locations (supposedly, the trusted ones, originating in the httpd's .text section). Unfortunately, the extremely powerful mmap() and munmap() system calls will allow remapping of text addresses, which kinda blows away your whole scheme. The key point here is ability to trust a call being made from a specific location. I assume that process cannot change its .text section once loaded so this scheme would no be abused by overwriting the location with malicious code. Am I correct here? What do you think of this scheme overall? Probably insufficient. The safest way is still isolated processes, possibly one (or, worse resource-wise, more) per UID, and those processes communicate via pipes, unix-domain socket pairs, or similar controlled IPC. The parent vfork()s, does appropriate uid/gid/gidset rearrangement, and execs the user server process, which would then hang around servicing stuff for some time. There don't seem to be better alternatives for doing this securely and still keep reasonable *NIX-like behavior. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9 Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
snapshots and innds
I'm getting a strong hunch that snapshots and inn don't get along
well, presumably having something to do with inn's extensive use
of mmap().
Just for an example, my system panic()ed earlier today (different
problem) and during the reboot, I'm stuck with an fsck_ufs on wchan
ufs and innd on wchan suspfs, and neither of them responding
in any way.
Unfortunately, my attempts to figure out *where* exactly everyone's
hung is being hampered by my not having any idea how to cause kgdb
to attach to the desired thread, or how to determine what thread
number (100xx) is related to what entry in ps -H.
For that matter, when I try to do a print *(struct proc *)0x{blah}
in kgdb for an address I got out of ps -o pid,uprocp,wchan,command,
it doesn't seem to believe that there is a struct proc.
Is there an up-to-date (i.e. covers 5.3) place that talks about
kernel debugging?
--
Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9
Internet: steve @ Watt.COM Whois: SW32
Free time? There's no such thing. It just comes in varying prices...
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Booting encrypted
In article [EMAIL PROTECTED] you write: Has any work been done to boot from an encrypted filesystem, or otherwise modify the loader to support GBDE with a compiled-in passphrase? The purpose would be to prevent reverse engineering of an appliance based on FreeBSD. Thoughts, ideas? Having the password compiled in to something that's necessarily clear-text on the same media? You're not adding anything resembling a challenge for someone who's really interested in reverse-engineering your system. Any user (I won't call such a person *acker) incapable of getting around such a thing probably won't be trying to reverse-engineer it anyhow. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9 Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Booting encrypted
On Sep 7, 13:54, [EMAIL PROTECTED] wrote: } Subject: Re: Booting encrypted } } Having the password compiled in to something that's necessarily clear-text } on the same media? } } If the authorization mechanism is limited to plain text, then yes. I know } that strings can be used to attempt to find the passphrase in the load, } but there may be ways to prevent the passphrase from being retrieved in } this manner. It can be a 256-bit AES key for all I care -- it simply must be the key necessary to decrypt the remaining contents of the filesystem available in a way that it can be fed to the crypto algorithm and get plain-text of the filesystem out. And the key must be in plain-text, because you don't have any keys available to decrypt the key... } You're not adding anything resembling a challenge for someone who's really } interested in reverse-engineering your system. Any user (I won't call such } a person *acker) incapable of getting around such a thing probably won't } be trying to reverse-engineer it anyhow. } } Well the point is to have a system where the entire filesystem (except the } loader of coarse) is encrypted. Runtime access to the system via the shell } would be removed or locked down. } } I wasn't able to find any info about booting encrypted filesystems, but I } can't believe I'm the only one that has raised the question. Because it doesn't contribute any security to the system to have the bootable partition encrypted, or else you wind up requiring a password to boot (not necessarily a bad thing, but probably not appropriate for your application). -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9 Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: api for sharing memory from kernel to userspace?
In article [EMAIL PROTECTED] you write: On Wed, May 19, 2004 at 05:29:07AM -0700, Alfred Perlstein wrote: + I need to share about 100megs of memory between kernel and userspace. + + The memory can not be paged and should appear contig in the process's + address space. Any suggestions? + + I need a way to either: + map user memory into the kernel's address space. + map kernel memory into the user's address space. + + I was looking at pmap_qenter() but it didn't see attractive because + it's for short term mappings, this mapping will exist for quite a + while. In mapping kernel memory into user's address space I am interested as well for GEOM Gate and other evil projects. The way we accomplished this in some other operating system was to create a shared memory segment with an implementation-reserved name, and then have the application shm_open the name and mmap it in. Shouldn't be hard with a device driver. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9 Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to flush out cache.?
In article [EMAIL PROTECTED] you write: Ok so I have an application where I need to reread a file I have just written to ensure that it went to disk correctly.. Other than reading a few GB of data, is there a way to flush out the cache copy of a file I've written? You can flush the file to disk with fsync(). But I don't think that evicts the blocks from the cache, just forces them to be written. To the disk controller's cache, if you're lucky. possibilities include: a file flag saying don't keep a copy after it's written to disk? a syscall discard_cached_blocks(fd); ? any other suggestions? What are you hoping to accomplish? There are probably other ways to solve the larger problem. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9 Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to flush out cache.?
On Apr 21, 13:28, Julian Elischer wrote: } Subject: Re: how to flush out cache.? } } On Wed, 21 Apr 2004, Steve Watt wrote: } } In article [EMAIL PROTECTED] you write: } } Ok so I have an application where I need to } reread a file I have just written to ensure that it went to disk } correctly.. } } What are you hoping to accomplish? There are probably other ways } to solve the larger problem. } } I thought I was being clear.. } I need to remove all the pages from cache so that a reread of the file } is forced to go to disk. } and I don't want to go read a 2GB dummy file to force the flush.. No, my question is what are you trying to accomplish with the reread, at a higher level than I want to know it's on disk. Is there some reason you have for not trusting the hardware? Are you trying to do a database commit protocol? Debugging the storage system? } Someone suggested that I read the file usign 'dump' through the raw } device.. Even doing that doesn't necessarily mean the bits have made it onto the rotating media. There can also be caches in the disk controller, and/or caches on the drive itself. If you're trying for a case where you want to pull the power, unmounting and remounting the filesystem will get it about as close as you can. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9 Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: send(2) does not block, send(2) man page wrong?
[EMAIL PROTECTED] wrote:
do what ping does (ping -f)
when you get an ENOBUFS do a usleep for 1 mSec.
and then send it again.
So how, exactly, do you actually sleep for 1mSec? I recently did some
experiments using nanosleep(), and it seems that the minimum sleep time
is 2 / HZ. I.e. ask for 100nS, get 20mS (on a 10mS-ticking system).
Mind you, that behavior is precisely aligned with what POSIX says should
happen, since nanosleep() is not allowed to return success before the
specified amount of time has expired, and you might be calling it 5nS
before the clock tick. But it does make doing correct Tx pacing a bit
more challenging.
Tried the same thing with usleep(1), same result of ~20mS per
sleep.
Here's the program I tested that with. Same results on a 4.4-RELEASE
and a 5.2-RELEASE machine.
Numbers from one run:
4.4-REL: 1501 loops, 30.017931 elapsed, time per loop: 19998.622 us
5.2-REL: 1501 loops, 30.016053 elapsed, time per loop: 19997.371 us
- - - 8 - - -
#include stdio.h
#include errno.h
#include sys/time.h
/* Seconds to count loops */
#define RUNTIME 30
int
main(int argc, char **argv)
{
struct timespec start, now, end, delay, remain;
double ts, te;
long loops = 0;
int rv;
clock_gettime(CLOCK_REALTIME, start);
end.tv_sec = start.tv_sec + RUNTIME;
end.tv_nsec = start.tv_nsec;
do {
delay.tv_sec = 0;
delay.tv_nsec = 1; /* 10uS */
do {
rv = nanosleep(delay, remain);
delay = remain;
} while (rv 0 errno == EINTR);
++loops;
clock_gettime(CLOCK_REALTIME, now);
} while ((now.tv_sec == end.tv_sec) ?
(now.tv_nsec end.tv_nsec) :
(now.tv_sec end.tv_sec));
te = now.tv_sec + (now.tv_nsec / 10.);
ts = start.tv_sec + (start.tv_nsec / 10.);
printf(%d loops, %f elapsed, , loops, te - ts);
printf(time per loop: %.3f us\n, ((te - ts) / loops) * 100.);
return 0;
}
--
Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9
Internet: steve @ Watt.COM Whois: SW32
Free time? There's no such thing. It just comes in varying prices...
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
kernel environment between reboots, diskless
Greetings, I'm working on a dataless system that will be booting and rooting from flash for some environmental chamber (thermal) tests, and logging the results to an NFS server outside the chamber. The problem is that the driver for the card under test only supports one card at a time. That's relatively easy to hack around by passing in a kernel environment varible from loader that indicates which PCI slot is OK. Then the probe routine of the driver looks for that variable and won't accept the device unless it matches. I'm trying to see if there's a way to get that information into the loader (or the driver) in some way that doesn't require rewriting a file in the flash every reboot, to avoid flash write cycles. I know there's some amount of NVRAM in PCs, but didn't spot anything about how to get at it from the driver. It'd be nice, for this sort of application, if there was a way to stash somewhere between 2 and 8 bytes somewhere... Thanks for insights! Pls cc: me directly on replies. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9 Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel environment between reboots, diskless
On Jan 14, 13:11, Brooks Davis wrote: } On Wed, Jan 14, 2004 at 12:55:49PM -0800, Steve Watt wrote: } I'm working on a dataless system that will be booting and rooting } from flash for some environmental chamber (thermal) tests, and } logging the results to an NFS server outside the chamber. } } I've got to ask, if you're in an NFS environment, why boot from flash at } all? Why not PXE boot or use etherboot? I'm attempting to minimize reboot cycle time, since part of the test suite involves 50 reboots per card, and with 5 cards in the system, a minute extra boot time is suddenly four hours. But I'll admit to not having gathered the data on that one, so I'll give it a closer look. If I PXE or etherboot, how would the kernel environment get populated then? -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9 Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel environment between reboots, diskless
On Jan 14, 13:24, Brooks Davis wrote: } On Wed, Jan 14, 2004 at 01:16:01PM -0800, Steve Watt wrote: } On Jan 14, 13:11, Brooks Davis wrote: } } On Wed, Jan 14, 2004 at 12:55:49PM -0800, Steve Watt wrote: } } I'm working on a dataless system that will be booting and rooting } } from flash for some environmental chamber (thermal) tests, and } } logging the results to an NFS server outside the chamber. } } } } I've got to ask, if you're in an NFS environment, why boot from flash at } } all? Why not PXE boot or use etherboot? } } I'm attempting to minimize reboot cycle time, since part of the test } suite involves 50 reboots per card, and with 5 cards in the system, } a minute extra boot time is suddenly four hours. } } Hmm, that might be an issue. If your network is reliable (and you } configure your switches so you don't get screwed by spanning tree), PXE } boots are quite fast, probably not more then a few seconds longer then } booting from local media (possiably less since you could disabling BIOS } probing of the media which takes forever.) It's going to be an isolated net, so it shouldn't be a problem on this part. } But I'll admit to not having gathered the data on that one, so I'll } give it a closer look. If I PXE or etherboot, how would the kernel } environment get populated then? } } From the server. The advantage of this is that it would be easy to } script changes on the server as opposed to changes on the flash card. } You also don't need to worry about wearing out the server's disks. Ah! I see how that works. Only catch is, I'm getting a strange result when trying diskless boots. I've got the DHCP server configured as suggested in pxeboot(8), and I see the loader get started. It grabs (over NFS) loader.rc, loader.4th, and support.4th. I see the start word get executed, but adding .( message ) cr in various places, it seems like it's getting to the end of start, but not coming back to the loader.rc code. And most of my Forth knowledge is from working with PostScript 15 years ago, which doesn't help a lot. :P Anyone want to hazard a guess? I feel like I'm falling deeper into that maze of twisty little passages. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9 Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
PCI bridges interrupts
0xfebfe000-0xfebf irq 11 at device 3.1 on pci4 +ahd1: Adaptec AIC7902 Ultra320 SCSI adapter port 0xe400-0xe4ff,0xe800-0xe8ff mem 0xfebfe000-0xfebf irq 11 at device 3.1 on pci5 ahd1: Defaulting to MEMIO on ahd1: Reading VPD from SEEPROM...ahd1: VPD parsing successful ahd1: Reading SEEPROM...done. @@ -197,12 +203,15 @@ ahd1: Downloading Sequencer Program... 710 instructions downloaded ahd1: Features 0x101, Bugs 0x8f, Flags 0x43f0 aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs +pci-: pci5 exists, using next available unit number pcib5: ServerWorks host to PCI bridge(unknown chipset) on motherboard -pci5: PCI bus on pcib5 +pci6: PCI bus on pcib5 +pci-: pci6 exists, using next available unit number pcib6: ServerWorks host to PCI bridge(unknown chipset) on motherboard -pci6: PCI bus on pcib6 +pci7: PCI bus on pcib6 +pci-: pci7 exists, using next available unit number pcib7: ServerWorks host to PCI bridge(unknown chipset) on motherboard -pci7: PCI bus on pcib7 +pci8: PCI bus on pcib7 ex_isa_identify() ata-: ata0 exists, using next available unit number ata-: ata1 exists, using next available unit number - - - 8 - - - dmesg diffs -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9 Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: PCI bridges interrupts
On Sep 24, 16:38, John Baldwin wrote:
} Subject: RE: PCI bridges interrupts
}
} On 24-Sep-2003 Steve Watt wrote:
} [ Too advanced for -questions? Trying again. ]
}
} I'm having a strange problem with interrupts, PCI bridges, and
} FreeBSD 4-STABLE (cvsupped from a few months ago).
}
} The motherboard is a Supermicro X5DL8-GG, dual-Xeon capable (only one is
} populated). The BIOS is AMIBIOS 7.00.00. The BIOS settings have PnP OS
} set to NO, ACPI OS is YES ('cause FreeBSD-CURRENT was once installed),
} and power management is all disabled.
}
} Turn ACPI off, there's a slim chance it might help.
No joy, I'm afraid.
} Everything on the board works when directly connected to the host,
} except that we can't go 66MHz and we can't close the case. With
} the riser card, *almost* everything works, except for interrupts.
} I can see the interrupt line low *on the card edge connector on
} the motherboard*, but it's not acknowledged, and our driver's ISR
} doesn't run. We've throttled the riser card to 33MHz to eliminate
} that possibility.
And if I were clever, I would've mentioned that it's in the
same slot. And the IRQ that gets assigned (by reading the
dmesg, as well as reading out the register from config space)
is the same.
} What follows is the verbose dmesg from the boot up without the
} riser (bridge), followed by diffs when booted with the riser.
}
} I'm looking for clues. It's about that far from working right,
} and this almost looks like a FreeBSD issue.
}
} Buddy, can you spare a clue? Why isn't the ISR running?
}
} Have you tried 5.x? Basically, 4.x doesn't really have all the
} infrastructure to route interrupts, and if your BIOS screws it up,
} then you aren't going to get the right IRQ number hooked up.
If the BIOS is screwing it up, it's somehow in the configuration
of the interrupt controller, which I thought was completely
owned by the OS.
I'd love to migrate it to 5.x, but there are bits of the driver
that have a rather intimate knowledge of other areas of the kernel
that are somewhat painful to drag forward. Management wants me
to try it on Linux, where the next gen of our driver is being
brought up.
But that's yet another OS install, and I'm (aren't we all?) in a
bit of a hurry.
Thanks,
--
Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9
Internet: steve @ Watt.COM Whois: SW32
Free time? There's no such thing. It just comes in varying prices...
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: PCI bridges interrupts
On Sep 24, 18:17, John Baldwin wrote: } Subject: RE: PCI bridges interrupts } } On 24-Sep-2003 Steve Watt wrote: } On Sep 24, 16:38, John Baldwin wrote: } } Subject: RE: PCI bridges interrupts } } And if I were clever, I would've mentioned that it's in the } same slot. And the IRQ that gets assigned (by reading the } dmesg, as well as reading out the register from config space) } is the same. } } Across bridges the interrupts get swizzled sort of. Which means } that device 0,4,8,etc. INT A gets mapped to INT A on the front } side of the bridge, device 1,5,7,etc. INT A gets mapped to INT B. } etc. IIRC your device is at device 5.0, so it's INT A should be } mapped to INT B of that slot, which should get a different interrupt. It's at 2.0 when plugged directly in, and 6.0 when on the bridge, which seems like the same swizzle target. Oh, wait, the bus number goes into the swizzle equation too, doesn't it? Hmm. I wonder if turning on APIC_IO would help. } } What follows is the verbose dmesg from the boot up without the } } riser (bridge), followed by diffs when booted with the riser. } } } } I'm looking for clues. It's about that far from working right, } } and this almost looks like a FreeBSD issue. } } } } Buddy, can you spare a clue? Why isn't the ISR running? } } } } Have you tried 5.x? Basically, 4.x doesn't really have all the } } infrastructure to route interrupts, and if your BIOS screws it up, } } then you aren't going to get the right IRQ number hooked up. } } If the BIOS is screwing it up, it's somehow in the configuration } of the interrupt controller, which I thought was completely } owned by the OS. } } No, the BIOS sets it up and we may try to tweak it. In 5.x we } fully tweak it now, but 4.x still relies on the BIOS to set this } up. OK. Last time I looked closely at the PC architecture, it was a '386 and things were simple. On Sep 24, 18:17, John Baldwin wrote: } Subject: Re: PCI bridges interrupts } } On 24-Sep-2003 M. Warner Losh wrote: } You might want to make sure that you have an up to date stable. There } was a fix to the PCI bridge interrupt swizzle. } } Ah yes, that's true. However, it doesn't seem that his interrupt is } being routed, but I could be wrong. Also, there is another bug in the } $PIR handling that I committed at BSDCon that also might fix the } problem. Was that committed to 4-STABLE? If so, I'll be getting it momentarily. Thanks! -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9 Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
