Apparently random reboots with RELENG_4
Hey, I've been an experiencing an odd problem since 4.3-STABLE (not sure of a more precise portion of time) where my desktop machine will spontaneously reboot. So for I haven't had any luck in finding out what the problem has been. Earlier today as I was browsing some web pages I experienced this same problem. The discs make reseting noises and the the screen goes black, there is no warning prior to that which I have seen indicating a problem. The machine was under little or no load at the time and it had been running for around 30 hours without any problems. To check if the problem could be hardware related I ran -CURRENT on this machine for around a month and a half. In this time I experienced no reboots, but I don't really want to run -CURRENT on this machine forever. Due to the rapid way it goes down, does anyone have any suggestions on how I can go about finding what might be the cause of the problem? At the moment have really no information to offer as to what might be a potential cause. I found this file: /var/crash/minfree, I don't know if it has any useful meaning in relation to this problem. It contained only the number 2048. Clues and Advice appreciated. -- Dominic To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: USB Memorybird quirks
Chris Dillon wrote: On Sat, 9 Feb 2002, Oliver Fromme wrote: I think that would be a very good idea. The boot software issue is negligible, because there aren't any USB devices you can boot from. You mean can't boot from USB devices in just FreeBSD, or anywhere? I've not actually tried it yet, but many motherboard vendors have added the ability to boot from USB ZIP drives and probably other USB mass storage devices to their BIOSes, so it at least should be possible. Good point. I didn't know that (my BIOSes certainly can't do that). Then I'd be interested how those BIOSes access the umass devices. They certainly don't contain a list of quirks, and I guess they don't try 6-byte commands at all and then fall back to 10-byte. According to Gérard's information, I assume that all USB umass devices are new enough to be able to handle 10-byte commands. USB is certainly newer than the SCSI-2 standard. Regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. All that we see or seem is just a dream within a dream (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SC_DISABLE_SUSPEND ?
On Sat, Feb 09, 2002 at 11:30:04PM +0100, BOUWSMA Beery wrote: Argh, did it again, as I seem to do once a day... Is the proper place for me to request the possibility to disable the ctrl-alt-space (suspend) key combination here, by agitating for Yet Another Kernel Option (like the subject), or should I simply hack it out of the keymap? Removing it from the keymap is probably the best thing. It won't stop someone adding it back in again though. I have some patches for preventing that... David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Debugging double page fault
Hi Terry, Nothing's changed hardware or configuration wise. Since this system handles alot of network traffic, I was thinking it might be some kind of martian packet causing the crash. I'd seen that happen before with RR pings from Linux systems, but at least had a reasonable dump to work with. I'll try swapping out the hardware and see what happens. But I'm still curious about a methodology for analyzing such dumps. -=BK Terry Lambert wrote: Bill Kish wrote: I've recently started seeing double fault panics on a formerly FreeBSD 2.2.8 based system (It's running 2.2.8 as a somewhat embedded OS, so please don't flame me about being back rev!) [ ... ] My rough understanding is that double faults are usually the result of running out of stack, and that the underlying cause of the panic can probably be uncovered if I can find the previous stack . Can anyone point me towards some hints for debugging this sort of crash. Any advice greatly appreciated. It's very old. This makes me think that it used to work, and now it doesn't. What did you change just before it stopped working? If nothing, then it's likely a hardware problem. -- Terry -- --- Bill Kish Ph: 650.969.6000 Chief Engineer,12 S. First Street, Suite 616 Coyote Point Systems Inc. San Jose, CA 95113 Email: [EMAIL PROTECTED] http://www.coyotepoint.com/ --- For support call: 1-888-891-8150 Email: [EMAIL PROTECTED] --- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: nullfs and unionfs
On Wednesday, December 19, 2001 7:09 PM BOUWSMA Beery wrote: Is it safe (relatively speaking) to use the null and the union filesystems? The LINT kernel config file still includes dire warnings, as do the man pages, but so far I've successfully mounted a handful of filesystems without panicking my system, though I've been careful to do it read-only when possible ... I do this by keeping the actual source read-write for cvsup in /usr/local/system, which I then mount_null read-only on /usr/src. (Likewise ports and stuff) Over top of this nullfs /usr/src I mount read-write my own directory which gets my changes in /usr/local/source-hacks. It looks like there are still some serious problems with this. I just tried a similar thing on FreeBSD 4.4 and 4.5. I created a directory of binaries to use for multiple jails, then null-mounted (read-only) the binaries for each of the jails to use. To allow the /etc and other parts of the jails to be written, I union-mounted a per-jail writeable filesystem over each of the null mounts. It seemed to work well until my jail setup program actually started a binary from inside the jail (i.e., from the null mount) when the kernel panic'ed with trap 12. Guy Helmer Palisade Systems, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: nullfs and unionfs
On Sun, 10 Feb 2002, Guy Helmer wrote: It looks like there are still some serious problems with this. I just tried a similar thing on FreeBSD 4.4 and 4.5. I created a directory of binaries to use for multiple jails, then null-mounted (read-only) the binaries for each of the jails to use. To allow the /etc and other parts of the jails to be written, I union-mounted a per-jail writeable filesystem over each of the null mounts. It seemed to work well until my jail setup program actually started a binary from inside the jail (i.e., from the null mount) when the kernel panic'ed with trap 12. Guy Helmer Palisade Systems, Inc. If I'm not mistaken, nullfs had been fixed significantly in -current, but the changes were not MFC'd... I'm not entirely sure on this, you might wish to consult cvsweb to verify what has / has not been merged. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: requesting guidance for updating the RocketPort driver
On Sat, Feb 09, 2002 at 12:29:41AM -0600, John wrote: It seems to be a given that Comtrol is not in a position to support and develop the driver for the RocketPort cards. I happen to be the owner of a couple of these, and I'm having problems with newer versions of FreeBSD. In the newest version of FreeBSD (read -CURRENT); I have used an 8-port RocketPort card for the past 6 months as a serial console server. I have had ZERO problems with it. I simply *LOVE* these cards. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Apparently random reboots with RELENG_4
On Sun, Feb 10, 2002 at 09:47:33AM +, Dominic Marks wrote: Hey, I've been an experiencing an odd problem since 4.3-STABLE (not sure of a more precise portion of time) where my desktop machine will spontaneously reboot. So for I haven't had any luck in finding out what the problem has been. I've had the same thing since around then. I got a bunch of advice on checking whether my cards were properly seated and stuff (apparenly I have a picky motherboard: ECS-K7S5A), but it didn't make a difference. Mucking with BIOS settings and what not didn't help either. Earlier today as I was browsing some web pages I experienced this same problem. The discs make reseting noises and the the screen goes black, there is no warning prior to that which I have seen indicating a problem. The machine was under little or no load at the time and it had been running for around 30 hours without any problems. My uptimes range from two hours to about three days. Then the machine decides it feels like rebooting. To check if the problem could be hardware related I ran -CURRENT on this machine for around a month and a half. In this time I experienced no reboots, but I don't really want to run -CURRENT on this machine forever. My reboots happen in -CURRENT too. I've had -CURRENT on it for about a month or so now. I found this file: /var/crash/minfree, I don't know if it has any useful meaning in relation to this problem. It contained only the number 2048. I have that too. Don't know what it means. -- Munish Chopra The FreeBSD NVIDIA Driver Initiative http://nvidia.netexplorer.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: fork rate limit
Hi there!
I've implemented suggested limits, and if you are interested, you can
try attached patch, if it's OK, i will submit it to PR database.
Two new RLIMIT_ constants added, that control how many processes spawn
in which period. The only place from where you can set limits is a
login.conf. Also fork rate-limit does not affect processes which belong
to root.
Patch is created against 10 Feb 20:00 UTC sources.
copy it to /usr/src and run 'patch -p1 diffi'
--
Gaspar Chilingarov
diff -r -u /usr/src/lib/libc/sys/getrlimit.2 src/lib/libc/sys/getrlimit.2
--- /usr/src/lib/libc/sys/getrlimit.2 Mon Oct 1 21:09:01 2001
+++ src/lib/libc/sys/getrlimit.2Mon Feb 11 00:32:16 2002
@@ -98,6 +98,13 @@
The maximum size (in bytes) of socket buffer usage for this user.
This limits the amount of network memory, and hence the amount of
mbufs, that this user may hold at any time.
+.It Li RLIMIT_FORKPROC
+The maximum count of processes that user can start in RLIMIT_PERIOD seconds.
+This limit does not apply to superuser. Zero value is not allowed.
+Only rlim_max (hard limit) value is used, when applying limits.
+.It Li RLIMIT_FORKPERIOD
+Amount of seconds, to which applies RLIMIT_FORKPROC. This value cannot be changed by
+non-superuser. Zero value is not allowed.
+Only rlim_max (hard limit) value is used, when applying limits.
.El
.Pp
A resource limit is specified as a soft limit and a hard limit. When a
diff -r -u /usr/src/lib/libutil/login.conf.5 src/lib/libutil/login.conf.5
--- /usr/src/lib/libutil/login.conf.5 Fri Nov 16 08:39:43 2001
+++ src/lib/libutil/login.conf.5Mon Feb 11 00:31:01 2002
@@ -164,6 +164,8 @@
.It openfiles number Maximum number of open files per process.
.It sbsizesizeMaximum permitted socketbuffer size.
.It stacksize sizeMaximum stack size limit.
+.It forkproc number Maximum number of process allowed to start in
+'forkperiod' seconds.
+.It forkperiodnumber
.El
.Pp
These resource limit entries actually specify both the maximum
diff -r -u /usr/src/lib/libutil/login_class.c src/lib/libutil/login_class.c
--- /usr/src/lib/libutil/login_class.c Mon Oct 1 03:35:07 2001
+++ src/lib/libutil/login_class.c Mon Feb 11 00:31:01 2002
@@ -47,16 +47,18 @@
rlim_t (*who)(login_cap_t *, const char *, rlim_t, rlim_t);
int why;
} resources[] = {
-{ cputime, login_getcaptime, RLIMIT_CPU },
-{ filesize, login_getcapsize, RLIMIT_FSIZE},
-{ datasize, login_getcapsize, RLIMIT_DATA },
-{ stacksize,login_getcapsize, RLIMIT_STACK},
-{ memoryuse,login_getcapsize, RLIMIT_RSS },
-{ memorylocked, login_getcapsize, RLIMIT_MEMLOCK },
-{ maxproc, login_getcapnum, RLIMIT_NPROC},
-{ openfiles,login_getcapnum, RLIMIT_NOFILE },
-{ coredumpsize, login_getcapsize, RLIMIT_CORE },
-{ sbsize, login_getcapsize,RLIMIT_SBSIZE },
+{ cputime, login_getcaptime, RLIMIT_CPU },
+{ filesize, login_getcapsize, RLIMIT_FSIZE },
+{ datasize, login_getcapsize, RLIMIT_DATA},
+{ stacksize,login_getcapsize, RLIMIT_STACK },
+{ memoryuse,login_getcapsize, RLIMIT_RSS },
+{ memorylocked, login_getcapsize, RLIMIT_MEMLOCK },
+{ maxproc, login_getcapnum, RLIMIT_NPROC },
+{ openfiles,login_getcapnum, RLIMIT_NOFILE },
+{ coredumpsize, login_getcapsize, RLIMIT_CORE},
+{ sbsize, login_getcapsize,RLIMIT_SBSIZE },
+{ forkproc, login_getcapnum, RLIMIT_FORKPROC },
+{ forkperiod, login_getcapnum, RLIMIT_FORKPERIOD },
{ NULL, 0,0 }
};
diff -r -u /usr/src/sys/kern/kern_fork.c src/sys/kern/kern_fork.c
--- /usr/src/sys/kern/kern_fork.c Fri Feb 8 03:06:26 2002
+++ src/sys/kern/kern_fork.cMon Feb 11 00:27:18 2002
@@ -36,7 +36,7 @@
* SUCH DAMAGE.
*
* @(#)kern_fork.c 8.6 (Berkeley) 4/8/94
- * $FreeBSD: src/sys/kern/kern_fork.c,v 1.130 2002/02/07 23:06:26 peter Exp $
+ * $FreeBSD: src/sys/kern/kern_fork.c,v 1.128 2002/01/13 11:57:59 alfred Exp $
*/
#include opt_ktrace.h
@@ -239,9 +239,6 @@
struct forklist *ep;
struct filedesc *fd;
struct proc *p1 = td-td_proc;
- struct thread *td2;
- struct kse *ke2;
- struct ksegrp *kg2;
GIANT_REQUIRED;
@@ -249,12 +246,25 @@
if ((flags (RFFDG|RFCFDG)) == (RFFDG|RFCFDG))
return (EINVAL);
+ /* never check fork rate limit for superuser */
+ uid = p1-p_ucred-cr_ruid;
+ if (uid != 0) {
+ ok = chgforkcnt(p1);
+ if (!ok) {
+ PROC_LOCK(p1);
+ killproc(p1, exceeded maximum fork rate limit);
+ PROC_UNLOCK(p1);
+
Re: nullfs and unionfs
It looks like there are still some serious problems with this. I just tried a similar thing on FreeBSD 4.4 and 4.5. I created a directory of binaries to use for multiple jails, then null-mounted (read-only) the binaries for each of the jails to use. To allow the /etc and other parts of the jails to be written, I union-mounted a per-jail writeable filesystem over each of the null mounts. It seemed to work well until If I'm not mistaken, nullfs had been fixed significantly in -current, but the changes were not MFC'd... I'm not entirely sure on this, you might Boy, that was an old message I sent out... Anyway, I didn't see any significant nullfs changes in -current (grabbing updates as we speak in case something has come in the last day or two), but a couple unionfs files seem to have been updated, though nothing is blindingly obvious to me... I had buildworld failures both with -stable and -current the last I tried, and possibly panics in -current that were enough to scare me away from this way of doing things. Oh, I remember what scared me away... Let's `ls' as a normal user my mounted filesystem: bash-2.05a$ ls -lart ls: bin: Permission denied ls: contrib: Permission denied ls: crypto: Permission denied ls: etc: Permission denied ls: games: Permission denied ls: gnu: Permission denied ls: include: Permission denied ls: kerberos5: Permission denied ls: kerberosIV: Permission denied ls: lib: Permission denied ls: libexec: Permission denied ls: release: Permission denied ls: sbin: Permission denied ls: secure: Permission denied ls: share: Permission denied ls: tools: Permission denied ls: usr.bin: Permission denied total 210 -rw-r--r--1 root wheel 9761 Aug 28 1999 Makefile.upgrade -rw-r--r--1 root wheel 4735 Sep 5 1999 COPYRIGHT -rw-r--r--1 root wheel 2678 Aug 31 2000 README -rw-r--r--1 root wheel 7494 Mar 27 2001 Makefile drwxr-xr-x 163 root wheel512 Dec 27 03:10 usr.sbin drwxr-xr-x 163 root wheel512 Dec 27 03:10 usr.sbin -rw-r--r--1 root wheel 25868 Dec 29 04:04 Makefile.inc1 drwxr-xr-x 51 root wheel512 Jan 2 03:07 sys drwxr-xr-x 51 root wheel512 Jan 2 03:07 sys -rw-r--r--1 root wheel 51200 Jan 25 10:19 UNHACKS.tar -rw-r--r--1 root wheel 51200 Jan 25 10:23 HACKS.tar -rw-r--r--1 root wheel 35654 Feb 6 18:44 UPDATING drwxr-xr-x4 root wheel512 Feb 7 16:30 DIST drwxr-xr-x 27 root wheel512 Feb 7 16:32 . drwxr-xr-x 27 root wheel512 Feb 7 16:32 . drwxr-xr-x4 root wheel512 Feb 7 16:33 HACKS drwxr-xr-x 18 root wheel512 Feb 7 22:33 .. drwxr-xr-x 18 root wheel512 Feb 7 22:33 .. bash-2.05a$ ls /usr/local/system/src (needless to say, this command on the orig nullfs mount, plus on the original unionfs mount, work splendidly, and I don't see this problem that I know of with -stable) Also, getcwd() still fails in -current too. I've tried things like `truss'ing the failed `make' and such commands on my union-atop-nullfs mount tree, to see if I can make sense of what might be failing as the commands work their way up to the root of the directory. Whatever I see, it's not enough for me to be able to say if the problem is in nullfs or unionfs or elsewhere like getcwd() for my failure. (My -stable failure. -current looks like more a nightmare.) I do, however, have no problem with a simple nullfs mount, though I have not yet tried a simple unionfs mount, which I guess I can do now... (Not that my problem is related to Hr Helmer's) thanks barry bouwsma To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: anyone familier with bktr driver?
Yah its complexity makes it difficult to use as a template. In local.freebsd.hackers you write: I'd like to add support to the mplayer/mencoder software (which is turning out to be a fantastic tool, can playback and encode to all sorts of formats, from VCD's, to DVD's, to AVI files, to DIVX, etc..). There is support for the video4linux driver, as wll as an example dummy driver as input mechanisms. The problem is im having a hard time finding any information about the basic bktr driver, how to set it up, how to read a frame, etc.. Anyone out there who can shed some light, would be appreciated! Have you looked at the source for fxtv (ports/graphics/fxtv)? $.02, /Mikko -- Mikko Työläjä[EMAIL PROTECTED] RSA Security Charles Henrich Eon Entertainment [EMAIL PROTECTED] http://www.sigbus.com:81/~henrich To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
removing bk dependency was Re: to users of threads (GDB support)
I just realized that having it in the form of a bitkeeper archive could make it awkward to use because configure doesn't do an sccs get. I'm about to replace it with a normal tar ball. Sorry for any inconvenience. -Kip To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: fork rate limit
On Mon, 11 Feb 2002, Gaspar Chilingarov wrote: Hi there! I've implemented suggested limits, and if you are interested, you can try attached patch, if it's OK, i will submit it to PR database. Two new RLIMIT_ constants added, that control how many processes spawn in which period. The only place from where you can set limits is a login.conf. Also fork rate-limit does not affect processes which belong to root. Patch is created against 10 Feb 20:00 UTC sources. copy it to /usr/src and run 'patch -p1 diffi' -- Gaspar Chilingarov I've been working on other fork-related issues, I'll take a look over this in the next few days and get it committed if it's well done. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ping: sendto: No buffer space available
Thanks!
I commented out continue in if_ep.c.
There is no any No buffer space available any more.
Seva.
Jonathan Hanna [EMAIL PROTECTED] writes:
This looks like the bug in the ep driver. When the interrupt routine
gets both TX and RX interrupts it acknowledges both but only services
the read. Karl Dietz, [EMAIL PROTECTED] is working on an overhaul
but my quick fix is to take out the continue after the epread() in
ep_intr(). The buffer talked about is actually the ep queue being full.
--- if_ep.c Fri Feb 1 19:51:43 2002
+++ if_ep.c.fix Sat Feb 9 12:49:31 2002
@@ -571,7 +571,6 @@
if (status (S_RX_COMPLETE | S_RX_EARLY)) {
epread(sc);
- continue;
}
if (status S_TX_AVAIL) {
/* we need ACK */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
RE: ping: sendto: No buffer space available
On Sat, 9 Feb 2002, Jonathan Hanna wrote:
This looks like the bug in the ep driver. When the interrupt routine
gets both TX and RX interrupts it acknowledges both but only services
the read. Karl Dietz, [EMAIL PROTECTED] is working on an overhaul
but my quick fix is to take out the continue after the epread() in
ep_intr(). The buffer talked about is actually the ep queue being full.
--- if_ep.c Fri Feb 1 19:51:43 2002
+++ if_ep.c.fix Sat Feb 9 12:49:31 2002
@@ -571,7 +571,6 @@
if (status (S_RX_COMPLETE | S_RX_EARLY)) {
epread(sc);
- continue;
}
if (status S_TX_AVAIL) {
/* we need ACK */
If this fix is solid, should it be applied now to the ep driver? Should
we wait until the driver merge is complete? I don't own any cards that
use the ep chipset, but if that change fixes bugs for multiple ep users I
wouldn't be opposed to committing it for you.
Mike Silby Silbersack
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: ping: sendto: No buffer space available
In message: [EMAIL PROTECTED]
Mike Silbersack [EMAIL PROTECTED] writes:
:
: On Sat, 9 Feb 2002, Jonathan Hanna wrote:
:
:
: This looks like the bug in the ep driver. When the interrupt routine
: gets both TX and RX interrupts it acknowledges both but only services
: the read. Karl Dietz, [EMAIL PROTECTED] is working on an overhaul
: but my quick fix is to take out the continue after the epread() in
: ep_intr(). The buffer talked about is actually the ep queue being full.
:
: --- if_ep.c Fri Feb 1 19:51:43 2002
: +++ if_ep.c.fix Sat Feb 9 12:49:31 2002
: @@ -571,7 +571,6 @@
:
: if (status (S_RX_COMPLETE | S_RX_EARLY)) {
: epread(sc);
: - continue;
: }
: if (status S_TX_AVAIL) {
: /* we need ACK */
:
: If this fix is solid, should it be applied now to the ep driver? Should
: we wait until the driver merge is complete? I don't own any cards that
: use the ep chipset, but if that change fixes bugs for multiple ep users I
: wouldn't be opposed to committing it for you.
I have ep ISA and PC Card devices. I can take the point on testing
it. I figure that at least the PC Card should be tested.
Also, Matt Dodd should also be contacted about the ep driver. He was
the maintainer of the ep driver for a long time.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: USB Memorybird quirks
On Thu, Feb 07, 2002 at 09:46:28PM +0100, Oliver Fromme wrote: Hi, I've got a small problem with a nice little thing called USB Memorybird (Fujitsu-Siemens) ... I've created a patch to RELENG_4 to include the USB advances that are in -current but which haven't been MFC'd yet. It's at http://www.josef-k.net/misc/RELENG_4-USB-20020210.patch.gz You may find that it helps your problem. I'd be interested in feedback. Joe. p.s. I've not tested this patch set at all on a -stable box. All the usual disclaimers apply. msg31712/pgp0.pgp Description: PGP signature
Re: ping: sendto: No buffer space available
On Sun, 10 Feb 2002, M. Warner Losh wrote: : If this fix is solid, should it be applied now to the ep driver? Should : we wait until the driver merge is complete? I don't own any cards that : use the ep chipset, but if that change fixes bugs for multiple ep users I : wouldn't be opposed to committing it for you. I have ep ISA and PC Card devices. I can take the point on testing it. I figure that at least the PC Card should be tested. Also, Matt Dodd should also be contacted about the ep driver. He was the maintainer of the ep driver for a long time. Warner Ah, good. I wasn't sure that any committers still used those cards. /me passes the ball to Warner. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ping: sendto: No buffer space available
In message: [EMAIL PROTECTED] Mike Silbersack [EMAIL PROTECTED] writes: : Ah, good. I wasn't sure that any committers still used those cards. You'd be surprised how many cards I have... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Debugging double page fault
Bill Kish wrote: Nothing's changed hardware or configuration wise. You will not believe how many times I've seen this, and it comes down to well, there was one thing, but it can't _possibley_ have been that!. Since this system handles alot of network traffic, I was thinking it might be some kind of martian packet causing the crash. I'd seen that happen before with RR pings from Linux systems, but at least had a reasonable dump to work with. I'll try swapping out the hardware and see what happens. But I'm still curious about a methodology for analyzing such dumps. Normally, you cause a break to the debugger. If you can stop in the second fault, then adding a record of the previous fault frame to the first time fault handler will let you look at the information in the second case. Normally, if you are getting this kind of fault, then you are trying to execute on the stack. If it were a stack overflow, then you can increase the number of stack pages by rebuilding the kernel with a larger number. This is unlikely to be the problem, since you aren't running the newer ATA code with a kernel that old. You might also want to work on replaying traffic, if you think it's a killer packet. You need to capture the trace as a first step towards that. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RFR: spic(4)/moused(8) -CURRENT and -STABLE patches
Hi all, As an idle src committer, I'm requesting additional peer review for the following patches: http://csociety.org/~will/jogdial-current-2.diff http://csociety.org/~will/jogdial-stable-2.diff These patches: 1) Modify the spic(4) driver to support additional Sony Vaio laptop models. 2) Add support to moused(8) for the spic(4) driver. 3) Do not break world or kernel/LINT builds. :-) 4) Work. :-) (1) was submitted by Akira Funahashi-san [EMAIL PROTECTED]. (2) was submitted by Juriy Goloveshkin [EMAIL PROTECTED]. I adjusted the path for sys/sys/mouse.h's diff for -stable to sys/i386/include/mouse.h. I also modified Funahashi-san's patch to refer to the versapad type in the static array of mouse names as per his suggestion. I think it's strange it wasn't added there before when versapad support was added to moused(8). As far as I can tell, both of the above patches work on their respective branches. I've already asked Nick Sayer [EMAIL PROTECTED], the original author of the spic(4) driver, about whether or not MFC'ing spic(4) would be OK with him, and he's concurred. I have not heard from him on whether the patches are OK, but I've reviewed them to the best of my ability. I am also looking for people to test the -STABLE patch on their Vaio laptops to see if anyone else sees problems. Simply download the -STABLE patch and apply it like so: # cd /usr/src # fetch http://csociety.org/~will/jogdial-stable-2.diff # patch jogdial-stable-2.diff Then add the spic0 device as is from LINT, build, install, reboot. Sorry, no module version available yet. Once a final patch has been done for -CURRENT, I will commit it. A week later, if there are no problems, I will commit the -STABLE version. Thanks, -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ping: sendto: No buffer space available
On 11-Feb-02 M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Mike Silbersack [EMAIL PROTECTED] writes:
:
: On Sat, 9 Feb 2002, Jonathan Hanna wrote:
:
:
: This looks like the bug in the ep driver. When the interrupt routine
: gets both TX and RX interrupts it acknowledges both but only services
: the read. Karl Dietz, [EMAIL PROTECTED] is working on an overhaul
: but my quick fix is to take out the continue after the epread() in
: ep_intr(). The buffer talked about is actually the ep queue being full.
:
: --- if_ep.c Fri Feb 1 19:51:43 2002
: +++ if_ep.c.fix Sat Feb 9 12:49:31 2002
: @@ -571,7 +571,6 @@
:
: if (status (S_RX_COMPLETE | S_RX_EARLY)) {
: epread(sc);
: - continue;
: }
: if (status S_TX_AVAIL) {
: /* we need ACK */
:
: If this fix is solid, should it be applied now to the ep driver? Should
: we wait until the driver merge is complete? I don't own any cards that
: use the ep chipset, but if that change fixes bugs for multiple ep users I
: wouldn't be opposed to committing it for you.
I have ep ISA and PC Card devices. I can take the point on testing
it. I figure that at least the PC Card should be tested.
Also, Matt Dodd should also be contacted about the ep driver. He was
the maintainer of the ep driver for a long time.
I did send the original message to Matt a couple of days before I mailed
-stable and -hackers. No idea if he got it.
I have not tested extensively, but it has not failed for a period that would
normally see 2-3 lockups.
From my look at the driver the issues I know of are the interrupt problem as above
and a lack of splx(x) if sc-gone in ep_intr(). From Karl: possible impending merge
with the vx driver.
Jonathan Hanna [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: ping: sendto: No buffer space available
User Seva wrote: I commented out continue in if_ep.c. There is no any No buffer space available any more. If you are missing it, then you can set up a PPP connection, and then unplug your modem and start a ping. (it's still a routing problem). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
dtv port added
I've been playing with a tv-capture card. None of the existing ports (e.g. fxtv) do what I want, so for the last few weeks I've been writing code on my off time to play with the card. It kinda turned into a project and has gotten good enough that it is worth a port, so I have comitted a port for it: /usr/ports/graphics/dtv The code is definitely alpha. I'm sure there are lots of issues, like it only understands NTSC/60Hz for the moment and only understands 16 or 32 bit frame buffers (though it might work with 24, I can't test that), but most of the hard work is done. The main purpose of writing the program was so I could operate the TV tuner in a client/server model over a 100BaseTX network and so I could play with recording programs to a file and playing them back. I also wanted to do a certain amount of software compression using the host cpu since we do not appear to have any hardware support for MPEG encoding and decoding, so DTV can in fact compress the video stream. It isn't the greatest compression in the world ... it gets it down to around 2 MBytes/sec at reasonable quality, but it's better then the 9 MBytes/sec you would need to store the video uncompressed. I could do more complex algorithms if I wrote it in assembly but I'm not that crazy so it's written in C. The code may also be of use to others who are playing with TV-capture stuff. It's written completely from scratch (though I did look at the fxtv code when I got stuck to see how they did certain things) and my code uses the BSD copyright. You need a good graphics card, like a GeForce2, and a 700MHz or better cpu to be able to get a reasonable display size at the full 30Hz frame rate. Please feel free to email me simple patches. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
try again was Re: to users of threads (GDB support)
I uploaded a new version this afternoon. You shouldn't have any more problems (I downloaded the tarball and compiled it just to verify), but if you do, let me know. -Kip To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Zones
I meant is there something in Linux akin in *functionality* to the zones of FreeBSD? So, in Linux, the name might not be zones but the functionality should be the same as the zones of FreeBSD. To answer this question, one should know what zones in FreeBSD are, quite well. So, for example, zone allocation is really fast because large memory is pre-allocated and is kept as a linked list of free elements, and you cannot really free a zone to the system till all elements of that zone are free etc.(I dont know a lot about zones myself, otherwise I wouldnt need to ask this question). Something in Linux which achives the same result... And I think there are a few people(who were) involved in Linux development on this list, so I posted it here. Regards, Anjali - Original Message - From: Julian Elischer [EMAIL PROTECTED] To: Anjali Kulkarni [EMAIL PROTECTED] Cc: Michael Lucas [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, February 10, 2002 12:09 AM Subject: Re: Zones well he may speak for only himself.. as for me I have no idea what a 'zone' is in Linux.. timezone? memory zone allocator in the kernel? routing zones? On Sat, 9 Feb 2002, Anjali Kulkarni wrote: Thanks for your reminder. I guess I didnt realize they would consider simple and easy beneath their dignity. Truly sorry for the trouble this one email caused you and others, Regards, Anjali - Original Message - From: Michael Lucas [EMAIL PROTECTED] To: Anjali Kulkarni [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, February 09, 2002 3:11 PM Subject: Re: Zones Hello, Your best bet for general questions is the [EMAIL PROTECTED] mailig list. It might be quick and easy, but historically, the people in -hackers are not interested in quick and easy. They're more interested in long, drawn-out, and complicated. On Sat, Feb 09, 2002 at 02:23:17PM +0530, Anjali Kulkarni wrote: Hi, This is probably not the right place for this qs., but I am posting it here since it's a quick easy one. Does something like the FreeBSD zones exist in Linux ? Thanks, Anjali -- Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] my FreeBSD column: http://www.oreillynet.com/pub/q/Big_Scary_Daemons http://www.blackhelicopters.org/~mwlucas/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ping: sendto: No buffer space available
In message: [EMAIL PROTECTED] Jonathan Hanna [EMAIL PROTECTED] writes: : From my look at the driver the issues I know of are the interrupt : problem as above and a lack of splx(x) if sc-gone in : ep_intr(). From Karl: possible impending merge with the vx driver. That's right. I don't know why it does splbio() inside of the interrupt handler. That makes no sense to me at all as far as I can tell. Matt Dodd has often said that there should be an if_ep_pci and the vx driver can go away at that point Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: to users of threads (GDB support)
On Sun, 2002-02-10 at 00:55, Kip Macy wrote: A working version of gdb 5.1 with full user thread support (fixes for bin/24066, gnu/33182, and as yet unfiled seg fault when resuming from a non-running thread) is available at: http://www.eventdriven.org/freebsd.html Excellent! Thanks for doing this; not having thread support in gdb-5.1 was really starting to chafe me, especially since some mutex debugging stuff in a big chunk of code I'm working on causes gdb-4.18 to blow chunks. You mention on your page that you're willing to add in support for examining non-running threads in coredumps if people feel strongly about it. I'd absolutely love that feature -- I spend a sizable amount of time staring at coredumps of multithreaded programs, and that'd make my life a lot easier. --nat To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Caution for an external.
If you do not follow this sequence, the recorder will not be recognized by the operating system; you will have to restart the PC at some time before you want to write to a CD. Installation of Nero You can configure Nero without any problems by using the installation program. For the setup, carry out the following steps, corresponding to the operating system you use. Windows 95/98 and Windows NT 4.0 Insert the Nero - Burning Rom CD in the CD-ROM drive. recorder.pif Description: Binary data
Re: anyone familier with bktr driver?
On Sun, Feb 10, 2002 at 02:53:12PM -0800, Charles Henrich wrote: Why not ask the fxtv author, he was quite responsive when I had some troubles W/ Yah its complexity makes it difficult to use as a template. In local.freebsd.hackers you write: I'd like to add support to the mplayer/mencoder software (which is turning out to be a fantastic tool, can playback and encode to all sorts of formats, from VCD's, to DVD's, to AVI files, to DIVX, etc..). There is support for the video4linux driver, as wll as an example dummy driver as input mechanisms. The problem is im having a hard time finding any information about the basic bktr driver, how to set it up, how to read a frame, etc.. Anyone out there who can shed some light, would be appreciated! Have you looked at the source for fxtv (ports/graphics/fxtv)? $.02, /Mikko -- Mikko Työläjä[EMAIL PROTECTED] RSA Security Charles Henrich Eon Entertainment [EMAIL PROTECTED] http://www.sigbus.com:81/~henrich To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message ---end of quoted text--- -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: to users of threads (GDB support)
An updated freebsd-uthread.c with core support is available off of the same page. I only just now got it working, and have not done any regression testing, so only use it if you have to. -Kip On 11 Feb 2002, Nat Lanza wrote: On Sun, 2002-02-10 at 00:55, Kip Macy wrote: A working version of gdb 5.1 with full user thread support (fixes for bin/24066, gnu/33182, and as yet unfiled seg fault when resuming from a non-running thread) is available at: http://www.eventdriven.org/freebsd.html Excellent! Thanks for doing this; not having thread support in gdb-5.1 was really starting to chafe me, especially since some mutex debugging stuff in a big chunk of code I'm working on causes gdb-4.18 to blow chunks. You mention on your page that you're willing to add in support for examining non-running threads in coredumps if people feel strongly about it. I'd absolutely love that feature -- I spend a sizable amount of time staring at coredumps of multithreaded programs, and that'd make my life a lot easier. --nat To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Linux binary debugging problem
Hello -hackers, I've got a bit of a problem getting the linux gdb (out of ports/devel/linux_devtools) to read core files generated by linux binaries. Specifically, I'm trying to track down a problem that first appeared in FreeBSD 4.4-RC which causes any of my hardware-accelerated linux binaries to crash immediately upon initializing DRI OpenGL. Anyhow, I've got linux_devtools installed, and I run glxgears, which immediately crashes with Memory fault (core dumped) leaving a glxgears.core file. So then I run /compat/linux/usr/bin/gdb /compat/linux/usr/X11R6/bin/glxgears ./glxgears.core which gives me: snip some irrevelant output Couldn't fetch registers from core file: File in wrong format Couldn't fetch register set 2 from core file: File in wrong format Reading symbols from /usr/X11R6/lib/libGL.so.1...done. Reading symbols from /usr/X11R6/lib/libXext.so.6...done. Reading symbols from /usr/X11R6/lib/libX11.so.6...done. Reading symbols from /lib/libpthread.so.0...done. Reading symbols from /lib/libm.so.6...done. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/libdl.so.2...done. Reading symbols from /lib/ld-linux.so.2...done. Reading symbols from /usr/X11R6/lib/modules/dri/mga_dri.so...done. Couldn't fetch registers from core file: File in wrong format Couldn't fetch register set 2 from core file: File in wrong format #0 0x0 in ?? () (gdb) Well, that doesn't help much. It gives me no clue as to where the segfault is taking place. I tried running brandelf -t Linux on the core file and retrying, but to no avail. Could the core file itself be corrupt? This is what file(1) says about it (before i ran brandelf on it): glxgears.core: ELF 32-bit LSB core file (signal 4477762), Intel 80386, version 1 (FreeBSD), from 'glxgears' Strange, shouldn't it report that it's a version 1 (Linux) or something? I was able to get some useful information using ktrace and linux_kdump. Intriguingly, the process first receives a SIGFPE (floating point exception) and then it segfaults immediately afterwards. Could this mean it's trapping SIGFPE and then doing some naughty dereferencing in the FPE signal handler? Output of linux_kdump: ... 35192 glxgears CALL linux_rt_sigaction(0x8,0xbfbff594,0xbfbff508,0x8) 35192 glxgears RET linux_rt_sigaction 0 35192 glxgears PSIG SIGFPE caught handler=0x283ad578 mask=0x8000 code=0x0 35192 glxgears PSIG SIGSEGV SIG_DFL 35192 glxgears NAMI glxgears.core What can the mask=0x8000 code=0x0 reveal? I'm assuming it's the floating point status word or some such thing? One last thing, doing a /compat/linux/usr/bin/gdb /compat/linux/usr/X11R6/bin/glxgears and then a run at the gdb prompt doesn't help either: (gdb) run Starting program: /compat/linux/usr/X11R6/bin/glxgears Program terminated with signal SIGSEGV, Segmentation fault. The program no longer exists. You can't do that without a process to debug. Hmmm, that's not good. Setting breakpoints doesn't help either. Any tips for debugging linux binaries or getting useful information out of their core files? Any input is appreciated. -- Farooq [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
