Re: today's 5-current hang hard when building apache2 port
Hello, this is a simple ME TOO message i had the same problem yesterday at home, but not here with todays kernel. Here, where everything works i have INET6 disabled in kernel. I cannot look in the configuration file at home now. Greetings -- Fritz Heinrichmeyer mailto:[EMAIL PROTECTED] FernUniversitaet Hagen, LG ES, 58084 Hagen (Germany) tel:+49 2331/987-1166 fax:987-355 http://www-es.fernuni-hagen.de/~jfh To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mounting Root fails with error 22 (EINVAL)
On Sun, 23 Feb 2003 17:41:07 +0100 (CET) Soeren Schmidt [EMAIL PROTECTED] wrote: It seems that I managed to break the tagged queueing support somehow, so please disable tags while I look hunt for the problem.. For some of us it is broken since long ago... as you know. I hope you find the real problem which affects all of us, now that you are able to see it yourself. Bye, Alexander. -- The best things in life are free, but the expensive ones are still worth a look. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mounting Root fails with error 22 (EINVAL)
It seems Alexander Leidinger wrote: On Sun, 23 Feb 2003 17:41:07 +0100 (CET) Soeren Schmidt [EMAIL PROTECTED] wrote: It seems that I managed to break the tagged queueing support somehow, so please disable tags while I look hunt for the problem.. For some of us it is broken since long ago... as you know. I hope you find the real problem which affects all of us, now that you are able to see it yourself. This is a new problem as far as I can tell, its most likely something I overlooked during the last round of changes... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: WLAN
At 12:25 PM +1030 2003/02/24, Daniel O'Connor wrote: 802.11g isn't a final standard yet either (note no WiFi logo on 11g stuff) WiFi waffled. There probably won't be any kind of a WiFi logo on 11g equipment. Or 11a, for that matter. They're too beholden to corporate interests, and I don't think any interoperability tests of this sort will ever be conducted, or will ever be conductable. I remain willing to be convinced that I am wrong, however. Personally I'd wait a bit until the standard is finalised and the interoperability tests are done before buying any of it. Take some wool underwear with you if you go downstairs. ;-) -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
LAN support for nVidia nForce2
Is there any support of nVidia's nForce2 integrated LAN controller? Also I have following message during device probe: pcm0: measured ac97 link rate at 292571428 Hz mpg123 appears to play MP3s correctly. Sincerely, Maxim M. Kazachek mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]:0:0: class=0x06 card=0x chip=0x01e010de rev=0xa2 hdr=0x00 [EMAIL PROTECTED]:0:1: class=0x05 card=0x10001695 chip=0x01eb10de rev=0xa2 hdr=0x00 [EMAIL PROTECTED]:0:2: class=0x05 card=0x10001695 chip=0x01ee10de rev=0xa2 hdr=0x00 [EMAIL PROTECTED]:0:3: class=0x05 card=0x10001695 chip=0x01ed10de rev=0xa2 hdr=0x00 [EMAIL PROTECTED]:0:4: class=0x05 card=0x10001695 chip=0x01ec10de rev=0xa2 hdr=0x00 [EMAIL PROTECTED]:0:5: class=0x05 card=0x10001695 chip=0x01ef10de rev=0xa2 hdr=0x00 [EMAIL PROTECTED]:1:0: class=0x060100 card=0x10001695 chip=0x006010de rev=0xa3 hdr=0x00 [EMAIL PROTECTED]:1:1: class=0x0c0500 card=0x10001695 chip=0x006410de rev=0xa2 hdr=0x00 [EMAIL PROTECTED]:2:0: class=0x0c0310 card=0x10001695 chip=0x006710de rev=0xa3 hdr=0x00 [EMAIL PROTECTED]:2:1: class=0x0c0310 card=0x10001695 chip=0x006710de rev=0xa3 hdr=0x00 [EMAIL PROTECTED]:2:2: class=0x0c0320 card=0x10001695 chip=0x006810de rev=0xa3 hdr=0x00 [EMAIL PROTECTED]:4:0: class=0x02 card=0x10001695 chip=0x006610de rev=0xa1 hdr=0x00 [EMAIL PROTECTED]:5:0: class=0x040100 card=0x10001695 chip=0x006b10de rev=0xa2 hdr=0x00 [EMAIL PROTECTED]:6:0: class=0x040100 card=0x10001695 chip=0x006a10de rev=0xa1 hdr=0x00 [EMAIL PROTECTED]:8:0: class=0x060400 card=0x chip=0x006c10de rev=0xa3 hdr=0x01 [EMAIL PROTECTED]:9:0: class=0x01018a card=0x10001695 chip=0x006510de rev=0xa2 hdr=0x00 [EMAIL PROTECTED]:13:0: class=0x0c0010 card=0x10001695 chip=0x006e10de rev=0xa3 hdr=0x00 [EMAIL PROTECTED]:30:0: class=0x060400 card=0x chip=0x01e810de rev=0xa2 hdr=0x01 [EMAIL PROTECTED]:9:0: class=0x01 card=0x10001000 chip=0x000f1000 rev=0x26 hdr=0x00 [EMAIL PROTECTED]:0:0: class=0x03 card=0x chip=0x011010de rev=0xb2 hdr=0x00
sh: turning off NDELAY mode
I'm getting this from time to time in an xterm on my notebook running 5.0-current -- Chris Christoph P. U. Kukulies [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sh: turning off NDELAY mode
sh: turning off NDELAY mode appears from time to time in an xterm n my notebook running 5.0-current (sorry, forgot to mention actual message in body on previous post) -- Chris Christoph P. U. Kukulies [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: cc: Internal error: Illegal instruction (program as)
All; These two kernel options seem to have solved the problem. Builds now run smoothly and error-free. I read the comments in NOTES about these options and something clicked: I recall that most Pentium processors will only deal with 4 kB pages. Aren't 4 MB pages a feature of the Xeon processor, as it can address much more memory? If that is the case, then these options should be the default, and their inverse provided in the kernel configuration file (ENABLE_PSE ENABLE_PG_G). -- Paul A. Howes -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Hay Sent: Saturday, February 22, 2003 1:05 PM To: Paul A. Howes Cc: [EMAIL PROTECTED] Subject: Re: cc: Internal error: Illegal instruction (program as) On Sat, Feb 22, 2003 at 11:43:01AM -0500, Paul A. Howes wrote: All, I am receiving some strange errors during a buildworld of 5.0-RELEASE-p2 from 5.0-RELEASE-p1. The location of where the failure varies, but the program that causes the failure is the same every time: as. The errors are a variety of signal 10 and signal 4. I do find an as.core file under /usr/obj, but as is stripped, so there are no debugging symbols or listing that I can provide. The strange thing is that I have been able to successfully build XFree86, KDE, and many other ports on this system. I followed the 4.x-to-5.0 upgrade directions to the letter about a month ago, and have had no major problems before this. Any help would be greatly appreciated! -- Paul A. Howes Hardware Tyan S2099GNNR motherboard Intel P4-2.4/533 Crucial 512 MB PC2100 DIMM Maxtor 20 GB hard drive. I see it is a P4, try adding options DISABLE_PSE and DISABLE_PG_G to your kernel. My 1.8G P4 do the same without them. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cc: Internal error: Illegal instruction (program as)
It seems Paul A. Howes wrote: All; These two kernel options seem to have solved the problem. Builds now run smoothly and error-free. I read the comments in NOTES about these options and something clicked: I recall that most Pentium processors will only deal with 4 kB pages. Aren't 4 MB pages a feature of the Xeon processor, as it can address much more memory? If that is the case, then these options should be the default, and their inverse provided in the kernel configuration file (ENABLE_PSE ENABLE_PG_G). Just for the record but my [EMAIL PROTECTED]/533 512MB/DDR does *not* show this problem no matter how hard I beat it. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ports make index returns warnings/errors
I cvsupped a moment before including ports-all and - since I've learnt to 'make index' afterwards - making index returns Generating INDEX-5 - please wait../nonexistentlocal: not found Makefile, line 30: warning: /nonexistentlocal returned non-zero status and more of that. -- Chris Christoph P. U. Kukulies [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic: vm_page_wakeup(NULL)
Le 2003-02-05, Thomas Quinot écrivait :
#13 0xc032f438 in calltrap () at {standard input}:98
#14 0xc030652c in vm_page_wakeup (m=0x0) at /usr/src/sys/vm/vm_page.c:324
Got the same one again last night circa 04:30, while the machine was
completely idle (except for an xscreensaver process drawing nice stuff
on the screen.)
Thomas.
--
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cc: Internal error: Illegal instruction (program as)
On Mon, Feb 24, 2003 at 12:10:46PM +0100, Soeren Schmidt wrote: inverse provided in the kernel configuration file (ENABLE_PSE ENABLE_PG_G). Just for the record but my [EMAIL PROTECTED]/533 512MB/DDR does *not* show this problem no matter how hard I beat it. -Søren Try this: DON'T remove /usr/obj before doing a buildworld, just let it accumulate. It will show up someday (it's not deterministic). Even sh(1) can die during the build along with make(1) and as and gcc. My P4 never showed such behaviour if I properly remove /usr/obj before a build. Jiawei Ye -- Without the userland, the kernel is useless. --inspired by The Tao of Programming To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
performance / /usr/src/UPDATING
In /usr/src/UPDATING I read that -current is always compiled withlots of debugging flags on etc. Can this be switched off with a single switch in the Makefile? -- Chris Christoph P. U. Kukulies [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern kern_lock.c
jeff2003/02/16 02:39:49 PST Modified files: sys/kern kern_lock.c Log: - Add a WITNESS_SLEEP() for the appropriate cases in lockmgr(). Revision ChangesPath 1.64 +7 -0 src/sys/kern/kern_lock.c I now get the following: rebka# /daemon/build/current/rebka/src/sys/kern/kern_lock.c:239: could sleep with buf queue lock locked from /daemon/build/current/rebka/src/sys/kern/vfs_bio.c:2143 Debugger(witness_sleep) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db tr Debugger(c04a73dc,c04e005e,ef,c04e4d42,c04e769b) at Debugger+0x54 witness_sleep(1,c172c708,c04e005e,ef,c09f11e0) at witness_sleep+0x123 lockmgr(c172c7cc,10001,c172c708,c09f11e0,12) at lockmgr+0x71 vop_sharedlock(c5bfdc98,0,c04e95be,35c,c02efcf1) at vop_sharedlock+0x7d vn_lock(c172c708,12,c09f11e0,85f,c05b1d00) at vn_lock+0xeb flushbufqueues(c05b1d00,0,c04e765b,11e,64) at flushbufqueues+0xfb buf_daemon(0,c5bfdd48,c04df6c2,365,0) at buf_daemon+0xd5 fork_exit(c033e2e0,0,c5bfdd48) at fork_exit+0xc4 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xc5bfdd7c, ebp = 0 --- -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cc: Internal error: Illegal instruction (program as)
It seems leafy wrote: Try this: DON'T remove /usr/obj before doing a buildworld, just let it accumulate. It will show up someday (it's not deterministic). Even sh(1) can die during the build a long with make(1) and as and gcc. My P4 never showed such behaviour if I properl y remove /usr/obj before a build. Doesn't make any difference, the only way I (so far) has been able to reproduce this is by severely overclocking the CPU and RAM... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: cc: Internal error: Illegal instruction (program as)
Jiawei, I always remove the contents of /usr/obj prior to performing a buildworld, and I could reproduce this behavior every time. -- Paul A. Howes -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of leafy Sent: Monday, February 24, 2003 7:08 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: cc: Internal error: Illegal instruction (program as) On Mon, Feb 24, 2003 at 12:10:46PM +0100, Soeren Schmidt wrote: inverse provided in the kernel configuration file (ENABLE_PSE ENABLE_PG_G). Just for the record but my [EMAIL PROTECTED]/533 512MB/DDR does *not* show this problem no matter how hard I beat it. -S?en Try this: DON'T remove /usr/obj before doing a buildworld, just let it accumulate. It will show up someday (it's not deterministic). Even sh(1) can die during the build along with make(1) and as and gcc. My P4 never showed such behaviour if I properly remove /usr/obj before a build. Jiawei Ye -- Without the userland, the kernel is useless. --inspired by The Tao of Programming To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: cc: Internal error: Illegal instruction (program as)
Soren, I have a machine that uses a SiS 648, but it has other problems... I'm one of the unlucky individuals who bought the ASUS implementation of this board, and ended up with a flaky P.O.S. I'm seriously thinking of swapping it for a Tyan S2662 (Granite Bay) motherboard, or waiting a few months for the 800 MHz FSB boards and chips to come out. My wife does a great deal of photo restoration, and the faster FSB would be a major improvement over the ASUS board. I haven't bothered to test any of my systems in an over clocked state, as the stability is more important to me, and my work, than wringing out the last MHz of performance. :) -- Paul A. Howes -Original Message- From: Soeren Schmidt [mailto:[EMAIL PROTECTED] Sent: Monday, February 24, 2003 7:15 AM To: [EMAIL PROTECTED] Subject: Re: cc: Internal error: Illegal instruction (program as) Could very well be that, this is a SiS 648 system with DDR333 RAM.. I can provoke something that looks like this problem if I overclock it severely ie run it a ~3Ghz with 233Mhz mem clock... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cc: Internal error: Illegal instruction (program as)
It seems Paul A. Howes wrote: Soren, I have a machine that uses a SiS 648, but it has other problems... I'm one of the unlucky individuals who bought the ASUS implementation of this board, and ended up with a flaky P.O.S. Uhm the board here is and ASUS P4S8X and it works like a charm -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: nvidia.ko load failed on -current
Jan Stocker wrote: Before blaming me, i know it is not supported for 5.x or -current, but i think some of us have that stuff already running on -current. I've been in hospital for many weeks and now i updated my system (late November) to the currents current. After adding the missing include, i successfully compiled the nvidia driver but loading the kernel module leads to: Feb 24 08:17:08 Twoflower kernel: link_elf: symbol rman_get_start undefined... IIRC I had this same problem when I tried the new scheduler (SCHED_ULE) because (for some reason I don't understand) the linux.ko kernel module was not built when I compiled my kernel. When I went back to the old scheduler (SCHED_4BSD) the linux.ko module reappeared and all worked again -- except that you'll get a 'page fault while in kernel mode' when you shut down the X server. I didn't try actually compiling linux into the kernel with the new scheduler -- you might try that first if you want to run the new scheduler. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cc: Internal error: Illegal instruction (program as)
On Mon, Feb 24, 2003 at 12:10:46PM +0100, Soeren Schmidt [EMAIL PROTECTED] wrote: These two kernel options seem to have solved the problem. Builds now run smoothly and error-free. I read the comments in NOTES about these options and something clicked: I recall that most Pentium processors will only deal with 4 kB pages. Aren't 4 MB pages a feature of the Xeon processor, as it can address much more memory? If that is the case, then these options should be the default, and their inverse provided in the kernel configuration file (ENABLE_PSE ENABLE_PG_G). Just for the record but my [EMAIL PROTECTED]/533 512MB/DDR does *not* show this problem no matter how hard I beat it. Terry claims the problem is somewhat masked on systems using more memory and particular kernel options. Not my words and claims, but Terry's, however you can try to physically take out memory (if you have two 256MB modules) or limit it at boottime (into which I don't believe, personally, but that's my uneducated faith only). Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 1699953492 Hz CPU: Intel(R) Celeron(R) CPU 1.70GHz (1699.95-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf13 Stepping = 3 Features=0x3febfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM real memory = 132382720 (126 MB) avail memory = 123191296 (117 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled VESA: v3.0, 832k memory, flags:0x1, mode table:0xc043e2e0 (140) VESA: Brookdale-G Graphics Chip Accelerated VGA BIOS npx0: math processor on motherboard npx0: INT 16 interface acpi0: INTEL D845GLLY on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE31 Using $PIR table, 9 entries at 0xc00f3d20 -- Vallo Kallaste To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cc: Internal error: Illegal instruction (program as)
On Mon, Feb 24, 2003 at 01:21:46PM +0100, Soeren Schmidt wrote: Doesn't make any difference, the only way I (so far) has been able to reproduce this is by severely overclocking the CPU and RAM... -Søren I didn't believe it either at first. But I had kernel #54 before I first got this weird behavior. Ever since I have only kernel #0. If you do buildworld/buildkernel installworld/installkernel twice a day, you might get to it sometime around 20 days. Cheers, Jiawei Ye -- Without the userland, the kernel is useless. --inspired by The Tao of Programming To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Panic while on mid-load network traffic
Hello, I first noticed this last night, after recompiling the kernel to fix the delayed ACKs bug. What happens is that if I only use the network regularly (fetchmail/web browsing/IRC/IM/etc), the system seemed to run normally. But after launching a gnutella client, the system panics with the following message on the console (the first 3 times it occurred I was running gtk-gnutella, so I thought it could be either gtk-gnutella- or X-related and tried with mutella on the console with the same result): Fatal trap 12: page fault while in kernel mode fault virtual address = 0x2e405 fault code = supervisor write, page not present instruction pointer = 0x8:0xc025d976 stack pointer = 0x10:0xcce85cd8 frame pointer = 0x10:0xcce85ce0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 13 (swi6: tty:sio clock) trap number = 12 panic: page fault syncing disks, buffers remaining... panic: bwrite: buffer is not busy??? Uptime: 32m54s pfs_vncache_unload(): 2 entries remaining Automatic reboot in 15 seconds - press a key on console to abort I remember I reported a trap about 2 years ago for a 4.x-STABLE system, and when I pasted the error message someone asked me to perform other steps to further investigate what was going on. But I can't seem to remember what those steps were, so if anyone needs any other info, just ask and I'll provide. Fred -- God isn't dead, he just couldn't find a parking place. pgp0.pgp Description: PGP signature
Re: nvidia.ko load failed on -current
walt wrote: Jan Stocker wrote: Before blaming me, i know it is not supported for 5.x or -current, but i think some of us have that stuff already running on -current. I've been in hospital for many weeks and now i updated my system (late November) to the currents current. After adding the missing include, i successfully compiled the nvidia driver but loading the kernel module leads to: Feb 24 08:17:08 Twoflower kernel: link_elf: symbol rman_get_start undefined... IIRC I had this same problem when I tried the new scheduler (SCHED_ULE) because (for some reason I don't understand) the linux.ko kernel module was not built when I compiled my kernel. When I went back to the old scheduler (SCHED_4BSD) the linux.ko module reappeared and all worked again -- except that you'll get a 'page fault while in kernel mode' when you shut down the X server... Actually, this morning's patch by Scott Long fixed the 'page fault while in kernel mode'. (According to Alfred we'll be seeing file corruption instead, but that's another thread.) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: nvidia.ko load failed on -current
Jan Stocker wrote: Before blaming me, i know it is not supported for 5.x or -current, but i think some of us have that stuff already running on -current. I've been in hospital for many weeks and now i updated my system (late November) to the currents current. After adding the missing include, i successfully compiled the nvidia driver but loading the kernel module leads to: Feb 24 08:17:08 Twoflower kernel: link_elf: symbol rman_get_start undefined... IIRC I had this same problem when I tried the new scheduler (SCHED_ULE) because (for some reason I don't understand) the linux.ko kernel module was not built when I compiled my kernel. When I went back to the old scheduler (SCHED_4BSD) the linux.ko module reappeared and all worked again -- except that you'll get a 'page fault while in kernel mode' when you shut down the X server. I didn't try actually compiling linux into the kernel with the new scheduler -- you might try that first if you want to run the new scheduler My system has never seen the ULE scheduler, so there must be another thing... -- Jan Stocker [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic while on mid-load network traffic
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: I first noticed this last night, after recompiling the kernel to fix the delayed ACKs bug. What happens is that if I only use the network regularly (fetchmail/web browsing/IRC/IM/etc), the system seemed to run normally. But after launching a gnutella client, the system panics with the following message on the console (the first 3 times it occurred I was running gtk-gnutella, so I thought it could be either gtk-gnutella- or X-related and tried with mutella on the console with the same result): Do you have revision 1.196 of netinet/tcp_input.c? If not, please re-cvsup, as this version has some fixes that might apply in your case. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: machdep.guessed_bootdev sysctl on i386
Bruce Evans (Mon, Feb 24, 2003 at 06:27:26PM +1100) wrote: On Mon, 24 Feb 2003, I wrote: I tested with plain -current and old boot blocks. The sysctl still reports ad disks correctly. I don't care about the sysctl but want to keep the boot blocks as backwards compatible as possible. That means passing the boot device in the old encoding, which only takes a couple of lines of code. Current kernels ignore this and use a device name passed in the environment. This is presumably returned by the kenv syscall although not by a sysctl, so the sysctl is certainly not needed. I didn't test this since my boot blocks are too old and simple to pass an environment. They pass the device name more directly. Ok, I don't want to change the encoding or anything, but I think the sysctl should be nuked. Please see my later post to this thread, I have provided a patch. Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
make world fails in libexec/pt_chown
Freshly supped and got: === libexec/pt_chown cc -O -pipe -mcpu=pentiumpro -Wformat=2 -Wno-format-extra-args -Werror -c /usr/src/libexec/pt_chown/pt_chown.c cc1: warnings being treated as errors /usr/src/libexec/pt_chown/pt_chown.c: In function `main': /usr/src/libexec/pt_chown/pt_chown.c:86: warning: assignment makes pointer from integer without a cast *** Error code 1 Stop in /usr/src/libexec/pt_chown. *** Error code 1 Stop in /usr/src/libexec. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Should I cvsup again? -- Chris Christoph P. U. Kukulies [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make world fails in libexec/pt_chown
Date: Mon, 24 Feb 2003 15:43:34 +0100 From: Christoph Kukulies [EMAIL PROTECTED] Freshly supped and got: === libexec/pt_chown cc -O -pipe -mcpu=pentiumpro -Wformat=2 -Wno-format-extra-args -Werror -c /usr/src/libexec/pt_chown/pt_chown.c cc1: warnings being treated as errors /usr/src/libexec/pt_chown/pt_chown.c: In function `main': /usr/src/libexec/pt_chown/pt_chown.c:86: warning: assignment makes pointer from integer without a cast *** Error code 1 Stop in /usr/src/libexec/pt_chown. ... Should I cvsup again? Not sure about that, but I got through the make buildworld OK, and am building a -CURRENT kernel from today's sources. Recent CVSup history here: freebeast(5.0-C)[1] tail /var/log/cvsup-history.log CVSup begin from cvsup14.freebsd.org at Thu Feb 20 04:18:51 PST 2003 CVSup ended from cvsup14.freebsd.org at Thu Feb 20 04:29:15 PST 2003 CVSup begin from cvsup14.freebsd.org at Fri Feb 21 03:47:02 PST 2003 CVSup ended from cvsup14.freebsd.org at Fri Feb 21 03:58:48 PST 2003 CVSup begin from cvsup14.freebsd.org at Sat Feb 22 03:47:03 PST 2003 CVSup ended from cvsup14.freebsd.org at Sat Feb 22 03:58:53 PST 2003 CVSup begin from cvsup14.freebsd.org at Sun Feb 23 03:47:02 PST 2003 CVSup ended from cvsup14.freebsd.org at Sun Feb 23 03:55:36 PST 2003 CVSup begin from cvsup14.freebsd.org at Mon Feb 24 03:47:02 PST 2003 CVSup ended from cvsup14.freebsd.org at Mon Feb 24 03:56:04 PST 2003 (Yesterday's build was uneventful, FWIW. Oh -- committers: please note that this is *not* a complaint. :-}) Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] WARNING: Use of Microsoft products may be hazardous to your system's integrity. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Giving up on three buffers...
After this morning's cvsup I now get a 'syncing disks...giving up on three buffers' error message when shutting down the system and the filesystem doesn't get properly dismounted. For the last four days I could never shut the system down cleanly because of the nVidia driver problem causing a kernel panic when X got shut down, so I'm not sure if this problem really just started this morning or somethime in the past four days. Anyone else seeing this just today? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic while on mid-load network traffic
Do you have revision 1.196 of netinet/tcp_input.c? If not, please re-cvsup, as this version has some fixes that might apply in your case. I just re-cvsup'd and rebuilt the kernel. Same results, except that it now pagefaults quicker. Fred -- I'm So Miserable Without You It's Almost Like Having You Here -- Song title by Stephen Bishop. pgp0.pgp Description: PGP signature
Re: Panic while on mid-load network traffic
On Mon, Feb 24, 2003 at 12:43:43PM -0300, Fred Souza wrote: Do you have revision 1.196 of netinet/tcp_input.c? If not, please re-cvsup, as this version has some fixes that might apply in your case. I just re-cvsup'd and rebuilt the kernel. Same results, except that it now pagefaults quicker. Make sure you have DDB in your kernel (options DDB), then when the box panics, get the panic string and a stack backtrace via db t. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: nvidia.ko load failed on -current
Jan Stocker wrote: Jan Stocker wrote: Before blaming me, i know it is not supported for 5.x or -current, but i think some of us have that stuff already running on -current. I've been in hospital for many weeks and now i updated my system (late November) to the currents current. After adding the missing include, i successfully compiled the nvidia driver but loading the kernel module leads to: Feb 24 08:17:08 Twoflower kernel: link_elf: symbol rman_get_start undefined... IIRC I had this same problem when I tried the new scheduler (SCHED_ULE) because (for some reason I don't understand) the linux.ko kernel module was not built when I compiled my kernel. When I went back to the old scheduler (SCHED_4BSD) the linux.ko module reappeared and all worked again -- except that you'll get a 'page fault while in kernel mode' when you shut down the X server. I didn't try actually compiling linux into the kernel with the new scheduler -- you might try that first if you want to run the new scheduler My system has never seen the ULE scheduler, so there must be another thing... I didn't mean to imply that the scheduler itself caused the problem, just that the linux kernel module was missing for some reason and that was really the problem. Are you sure the linux module is there and is loaded before the nvidia kernel module? The link_elf error message suggests that maybe linux is not really there. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Giving up on three buffers...
Date: Mon, 24 Feb 2003 07:39:08 -0800 From: walt [EMAIL PROTECTED] After this morning's cvsup I now get a 'syncing disks...giving up on three buffers' error message when shutting down the system and the filesystem doesn't get properly dismounted. For the last four days I could never shut the system down cleanly because of the nVidia driver problem causing a kernel panic when X got shut down, so I'm not sure if this problem really just started this morning or somethime in the past four days. Anyone else seeing this just today? My build machine runs headless, so there may well be a salient difference there, but today's -CURRENT build reboot went just fine. Tail end of the console log (cut'n'paste) reads: Starting cron. Starting background file system checks in 60 seconds. Mon Feb 24 07:58:04 PST 2003 FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0) login: [0] f:00 typ:165 s(CHS):0/1/1 e(CHS):4/254/127 s:63 l:4192902 [1] f:00 typ:165 s(CHS):5/0/65 e(CHS):9/254/191 s:4192965 l:4192965 [2] f:00 typ:165 s(CHS):10/0/129 e(CHS):14/254/255 s:8385930 l:4192965 [3] f:80 typ:165 s(CHS):15/0/193 e(CHS):255/254/255 s:12578895 l:67697910 GEOM: Reconfigure ad0s1, start 32256 length 2146765824 end 2146798079 GEOM: Reconfigure ad0s2, start 2146798080 length 2146798080 end 4293596159 GEOM: Reconfigure ad0s3, start 4293596160 length 2146798080 end 6440394239 GEOM: Reconfigure ad0s4, start 6440394240 length 34661329920 end 41101724159 Fboot() called on cpu#0 Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks, buffers remaining... 2 2 done Uptime: 1m17s Power system off using ACPI... (And it actually did power off; this was in response to sudo boot0cfg -s 1 ad0 sudo halt -p || sudo reboot in case that's of interest or amusement.) Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] WARNING: Use of Microsoft products may be hazardous to your system's integrity. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Atapicam-error when dma is not turned on
Hi, Since I upgraded to 5.0-Release the cam-stuff acted a bit weird. During the boot-proces, right after the SCSI-bus reset it gives these messages: (probe1:ata0:0:1:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe1:ata0:0:1:0): CAM Status: SCSI Status Error (probe1:ata0:0:1:0): SCSI Status: Check Condition (probe1:ata0:0:1:0): ABORTED COMMAND asc:4b,0 (probe1:ata0:0:1:0): Data phase error (probe1:ata0:0:1:0): Retrying Command (per Sense Data) (probe1:ata0:0:1:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe1:ata0:0:1:0): CAM Status: SCSI Status Error (probe1:ata0:0:1:0): SCSI Status: Check Condition (probe1:ata0:0:1:0): ABORTED COMMAND asc:4b,0 (probe1:ata0:0:1:0): Data phase error (probe1:ata0:0:1:0): Retrying Command (per Sense Data) (probe1:ata0:0:1:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe1:ata0:0:1:0): CAM Status: SCSI Status Error (probe1:ata0:0:1:0): SCSI Status: Check Condition (probe1:ata0:0:1:0): ABORTED COMMAND asc:4b,0 (probe1:ata0:0:1:0): Data phase error (probe1:ata0:0:1:0): Retrying Command (per Sense Data) (probe1:ata0:0:1:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe1:ata0:0:1:0): CAM Status: SCSI Status Error (probe1:ata0:0:1:0): SCSI Status: Check Condition (probe1:ata0:0:1:0): ABORTED COMMAND asc:4b,0 (probe1:ata0:0:1:0): Data phase error (probe1:ata0:0:1:0): Retrying Command (per Sense Data) (probe1:ata0:0:1:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe1:ata0:0:1:0): CAM Status: SCSI Status Error (probe1:ata0:0:1:0): SCSI Status: Check Condition (probe1:ata0:0:1:0): ABORTED COMMAND asc:4b,0 (probe1:ata0:0:1:0): Data phase error (probe1:ata0:0:1:0): Retries Exhausted (probe1:ata0:0:1:0): INQUIRY. CDB: 12 0 0 0 5f 0 (probe1:ata0:0:1:0): CAM Status: SCSI Status Error (probe1:ata0:0:1:0): SCSI Status: Check Condition (probe1:ata0:0:1:0): ABORTED COMMAND asc:4b,0 (probe1:ata0:0:1:0): Data phase error (probe1:ata0:0:1:0): Retrying Command (per Sense Data) My system is overclocked, and the error doesn't appear at boot-time when I run it at default speed. But it still gives me some trouble once running. For example 'cdrecord -scanbus' tends to hang. Not every time, but sometimes it does. And it can be reproduced by executing that command rapidly a few times. After that I can't kill it anymore. Not even with kill -9. If dma for atapi-devices is turned on, no problems arise, and everyting seems to be working fine. The motherboard is an Abit-VP6 and the drive that's giving me trouble is a Compaq dvd-drive, but it has been flashed with Creative-firmware (to make it region-free). The output of 'camcontrol devlist' is: PLEXTOR CD-ROM PX-40TS 1.13 at scbus0 target 5 lun 0 (pass0,cd0) COMPAQ ST15150W 6216 at scbus1 target 0 lun 0 (pass1,da0) COMPAQ DFHSS4W 4343 at scbus1 target 1 lun 0 (pass2,da1) PLEXTOR CD-R PX-W1210A 1.09at scbus2 target 0 lun 0 (pass3,cd1) CREATIVE DVD5240E-1 1.30 at scbus2 target 1 lun 0 (pass4,cd2) current version of OS: [EMAIL PROTECTED]:~ uname -a FreeBSD Noisy.localhost.localdomain 5.0-RELEASE-p3 FreeBSD 5.0-RELEASE-p3 #0: Mon Feb 24 16:01:23 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NOISY5 i386 The full dmesg-output, kernel-config can be found at http://users.pandora.be/bomberboy/fbsd5/ As I said, everything seems to be working fine with dma turned on and I haven't encountered any problems so far. Maybe (/probably?) it just is the hardware, but I don't really have the spare hardware to test. But the problem never occured while I was using 4.7 So I figured I should at least mention the problem on this list. If I need to do some more tests or supply more info, I'll be glad to (try and) help. Thanks. -- Bruno The soul would have no rainbow had the eyes no tears. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: WLAN
In message: [EMAIL PROTECTED] Gerald Mixa [EMAIL PROTECTED] writes: : does anybody know wether FreeBSD supports PCMCIA cards for wireless : lan based on 802.11g (54MBit/s) standard? Nope. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cc: Internal error: Illegal instruction (program as)
It seems leafy wrote: Doesn't make any difference, the only way I (so far) has been able to reproduce this is by severely overclocking the CPU and RAM... -Søren I didn't believe it either at first. But I had kernel #54 before I first got thi s weird behavior. Ever since I have only kernel #0. If you do buildworld/buildkernel installworld/installkernel twice a day, you mig ht get to it sometime around 20 days. Well the box has been doing about 50 buildworlds aday in a loop for the last 4-5 days, I guess that should do it no ? :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Giving up on three buffers...
David Wolfskill wrote: Date: Mon, 24 Feb 2003 07:39:08 -0800 From: walt [EMAIL PROTECTED] After this morning's cvsup I now get a 'syncing disks...giving up on three buffers' error message when shutting down the system and the filesystem doesn't get properly dismounted. For the last four days I could never shut the system down cleanly because of the nVidia driver problem causing a kernel panic when X got shut down, so I'm not sure if this problem really just started this morning or somethime in the past four days. Anyone else seeing this just today? My build machine runs headless, so there may well be a salient difference there, but today's -CURRENT build reboot went just fine... I discovered that I was still running SCHED_ULE from yesterday and switching back to SCHED_4BSD eliminated the problem. I've actually been wondering why the system was so sluggish and now I know why ;-) Compiling a kernel was enough to drag the machine practically to uselessness, but now it's back to it's old self. The new scheduler still needs a bit of tweaking, methinks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cc: Internal error: Illegal instruction (program as)
Paul A. Howes wrote: These two kernel options seem to have solved the problem. Builds now run smoothly and error-free. I read the comments in NOTES about these options and something clicked: I recall that most Pentium processors will only deal with 4 kB pages. Aren't 4 MB pages a feature of the Xeon processor, as it can address much more memory? No. The feature is existance-tested before it is used. These processors have a bug when dealing with certain operations relating to interactions of 4K and 4M pages. If that is the case, then these options should be the default, and their inverse provided in the kernel configuration file (ENABLE_PSE ENABLE_PG_G). You will lose around 15% performance from not having them enabled. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cc: Internal error: Illegal instruction (program as)
On Mon, Feb 24, 2003 at 05:15:07PM +0100, Soeren Schmidt wrote: Well the box has been doing about 50 buildworlds aday in a loop for the last 4-5 days, I guess that should do it no ? :) -Søren It should :) But I still fail to see why it does or doesn't behave this way. :( Jiawei -- Without the userland, the kernel is useless. --inspired by The Tao of Programming To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cc: Internal error: Illegal instruction (program as)
leafy wrote: On Mon, Feb 24, 2003 at 12:10:46PM +0100, Soeren Schmidt wrote: inverse provided in the kernel configuration file (ENABLE_PSE ENABLE_PG_G). Just for the record but my [EMAIL PROTECTED]/533 512MB/DDR does *not* show this problem no matter how hard I beat it. Try this: DON'T remove /usr/obj before doing a buildworld, just let it accumulate. It will show up someday (it's not deterministic). Even sh(1) can die during the build along with make(1) and as and gcc. My P4 never showed such behaviour if I properly remove /usr/obj before a build. Also make sure: 1) You have the same amount of physical RAM 2) You are using the same kernel config -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cc: Internal error: Illegal instruction (program as)
Soeren Schmidt wrote: It seems Paul A. Howes wrote: I have a machine that uses a SiS 648, but it has other problems... I'm one of the unlucky individuals who bought the ASUS implementation of this board, and ended up with a flaky P.O.S. Uhm the board here is and ASUS P4S8X and it works like a charm You guys aren't listening again. It's a CPU implementation bug. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cc: Internal error: Illegal instruction (program as)
It seems Terry Lambert wrote: Soeren Schmidt wrote: It seems Paul A. Howes wrote: I have a machine that uses a SiS 648, but it has other problems... I'm one of the unlucky individuals who bought the ASUS implementation of this board, and ended up with a flaky P.O.S. Uhm the board here is and ASUS P4S8X and it works like a charm You guys aren't listening again. It's a CPU implementation bug. Well, and you aren't telling again :( So, if you have the info you claim to have, it should be very easy to tell us exactly what conditions make this error surface, so we can test and find out if this is for real once and for all.. If not, well I dont need to tell you what to do then do I ? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sh: turning off NDELAY mode
On Mon, Feb 24, 2003 at 10:27:22AM -0600, Dan Nelson wrote: In the last episode (Feb 24), Christoph Kukulies said: sh: turning off NDELAY mode appears from time to time in an xterm n my notebook running 5.0-current That means a program you were running exited without unsetting non-blocking mode, so /bin/sh fixed it for you. OK, that's /usr/X11R6/bin/mozilla. -- Chris Christoph P. U. Kukulies [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Problem with M_COPY_PACKET
Hi,
I did a cvsup today, and when I tried to compile the Netgraph ATM drivers,
I got this error:
~rodrigc/ngatm/ngatmbase-1.2b/fatm/if_fatm.c
cc1: warnings being treated as errors
/usr/home/rodrigc/ngatm/ngatmbase-1.2b/fatm/if_fatm.c: In function `copy_mbuf':
/usr/home/rodrigc/ngatm/ngatmbase-1.2b/fatm/if_fatm.c:1625: warning: implicit
declaration of function `M_COPY_PKTHDR'
The code in question looks like:
=
struct mbuf *
copy_mbuf(struct mbuf *m)
{
struct mbuf *new;
MGET(new, M_DONTWAIT, MT_DATA);
if(new == NULL)
return NULL;
if(m-m_flags M_PKTHDR)
M_COPY_PKTHDR(new, m);
if(m-m_flags M_EXT) {
MCLGET(new, M_DONTWAIT);
if(!(m-m_flags M_EXT)) {
m_free(new);
return NULL;
}
}
bcopy(m-m_data, new-m_data, m-m_len);
new-m_len = m-m_len;
new-m_flags = ~M_RDONLY;
=
I am not familiar with all the changes that have occurred to the M_*
macros. What should I do to correct this?
Thanks.
--
Craig Rodrigues
http://home.attbi.com/~rodrigc
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
reboots after crash
Hi folks! I have a serious problem. On a notebook with ufs the apm has launched a reboot after wakeup the notebook. It started fs-check in background and before login i get the error message: bad dir ino 70656 at offset 0 : mangled entry panic: ufs_dirbad: bad dir Then it falls into reboot and reboot ... This happened on the homedir. What can i do to recover the notebook? Thanks for any advice Alex Huth To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
The audio device drivers panics if I try to open /dev/dsp0.1 with flags O_RDWR
I have found an repeatable bug in the pcm device driver. How to repeat: Try opening /dev/dsp0.1 with flags O_RDWR and the kernel panics immediately. I've included source code of the program I used. Why the problem occurs: The _mtx_unlock(...) macro is called with a NULL (0x0) pointer from the CHN_UNLOCK(...) macro in /usr/src/sys/dev/pcm/channel.h. This is because the mutex pointer passed to CHN_UNLOCK(...) is a NULL pointer. (See gdb output). It looks like the mutex is destroyed twice. Probably because the program is trying to open the device with read+write. Since this is a call from userland, I think the open syscall to the device should return an error code instead of causing a panic. Fix: If the device isn't designed to support read+write something like this should be added to the code: if (flags O_RDWR) return ERROR_CODE; dmesg: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-RELEASE #0: Wed Jan 29 18:50:05 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMALLKERN_DEBUG Preloaded elf kernel /boot/kernel/kernel at 0xc045. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 62501253 Hz CPU: Overdrive Pentium/P54T Overdrive (62.50-MHz 586-class CPU) Origin = GenuineIntel Id = 0x1531 Stepping = 1 Features=0x13fFPU,VME,DE,PSE,TSC,MSR,CX8 real memory = 20971520 (20 MB) avail memory = 15908864 (15 MB) Intel Pentium detected, installing workaround for F00F bug Initializing GEOMetry subsystem VESA: v1.2, 512k memory, flags:0x0, mode table:0xc03d3974 (114) VESA: Cirrus Logic GD-54xx VGA npx0: math processor on motherboard npx0: INT 16 interface isa0: ISA bus on motherboard orm0: Option ROM at iomem 0xc-0xc7fff on isa0 ata0 at port 0x3f6,0x1f0-0x1f7 irq 14 on isa0 ata1 at port 0x376,0x170-0x177 irq 15 on isa0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 ed0 at port 0x280-0x29f iomem 0xd8000 irq 10 on isa0 ed0: address 00:50:bf:4c:21:a8, type NE2000 (16 bit) fdc0: Enhanced floppy controller (i82077, NE72065 or clone) at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fd0: 1440-KB 3.5 drive on fdc0 drive 0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 speaker0: PC speaker on isa0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sbc0: Creative SB16/SB32 at port 0x388-0x38b,0x330-0x331,0x220-0x22f irq 5 drq 5,1 on isa0 pcm0: SB16 DSP 4.13 on sbc0 ata2: Generic ESDI/IDE/ATA controller at port 0x3ee-0x3ef,0x1e8-0x1ef irq 11 on isa0 Timecounters tick every 1.000 msec ad0: 4126MB ST34311A [8944/15/63] at ata0-master BIOSPIO Mounting root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted ipfw2 initialized, divert disabled, rule-based forwarding enabled, default to deny, logging disabled pid 778 (convertdb), uid 0: exited on signal 10 (core dumped) pid 790 (convertdb), uid 0: exited on signal 10 (core dumped) pid 799 (convertdb), uid 0: exited on signal 10 (core dumped) pid 811 (convertdb), uid 0: exited on signal 10 (core dumped) pid 818 (convertdb), uid 0: exited on signal 10 (core dumped) pid 826 (convertdb), uid 0: exited on signal 10 (core dumped) pid 836 (convertdb), uid 0: exited on signal 10 (core dumped) pid 858 (convertdb), uid 0: exited on signal 10 (core dumped) pid 865 (convertdb), uid 0: exited on signal 10 (core dumped) pid 1101 (convertdb), uid 0: exited on signal 11 (core dumped) pid 2078 (lacnic), uid 0: exited on signal 11 (core dumped) pid 4692 (getlocation), uid 1000: exited on signal 11 (core dumped) pid 4695 (getlocation), uid 1000: exited on signal 11 (core dumped) pid 9113 (getlocation), uid 1000: exited on signal 11 (core dumped) pid 9126 (getlocation), uid 1000: exited on signal 11 (core dumped) pid 9134 (getlocation), uid 1000: exited on signal 11 (core dumped) pid 9138 (getlocation), uid 1000: exited on signal 11 (core dumped) arp: 10.53.4.10 moved from 00:10:dc:89:61:1e to 07:00:07:00:07:00 on ed0 GDB output: Script started on Mon Feb 24 17:10:09 2003 moonwalker.root# gdb -k /usr/ [K [K [K [Kboot/kernel/kernel.debug -c /var/crash/vmcore.1 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... panic: bwrite: buffer is not busy??? panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x20 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01e2767
Re: LAN support for nVidia nForce2
On Mon, Feb 24, 2003 at 04:09:11PM +0600, Maxim M. Kazachek wrote: Is there any support of nVidia's nForce2 integrated LAN controller? Also I have following message during device probe: pcm0: measured ac97 link rate at 292571428 Hz Should be -- I committed some support for it. rev 1.123 src/sys/pci/if_xl.c What sources are you using? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern kern_lock.c
Mike Makonnen wrote: jeff2003/02/16 02:39:49 PST Modified files: sys/kern kern_lock.c Log: - Add a WITNESS_SLEEP() for the appropriate cases in lockmgr(). Revision ChangesPath 1.64 +7 -0 src/sys/kern/kern_lock.c I now get the following: Same here, FWIW. rebka# /daemon/build/current/rebka/src/sys/kern/kern_lock.c:239: could sleep with buf queue lock locked from /daemon/build/current/rebka/src/sys/kern/vfs_bio.c:2143 Debugger(witness_sleep) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db tr Debugger(c04a73dc,c04e005e,ef,c04e4d42,c04e769b) at Debugger+0x54 witness_sleep(1,c172c708,c04e005e,ef,c09f11e0) at witness_sleep+0x123 lockmgr(c172c7cc,10001,c172c708,c09f11e0,12) at lockmgr+0x71 vop_sharedlock(c5bfdc98,0,c04e95be,35c,c02efcf1) at vop_sharedlock+0x7d vn_lock(c172c708,12,c09f11e0,85f,c05b1d00) at vn_lock+0xeb flushbufqueues(c05b1d00,0,c04e765b,11e,64) at flushbufqueues+0xfb buf_daemon(0,c5bfdd48,c04df6c2,365,0) at buf_daemon+0xd5 fork_exit(c033e2e0,0,c5bfdd48) at fork_exit+0xc4 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xc5bfdd7c, ebp = 0 --- -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: cc: Internal error: Illegal instruction (program as)
Soeren Schmidt wrote: You guys aren't listening again. It's a CPU implementation bug. Well, and you aren't telling again :( I sent you private email. If you are willing to agree to non-disclosure, you can know, too. Also again So, if you have the info you claim to have, it should be very easy to tell us exactly what conditions make this error surface, so we can test and find out if this is for real once and for all.. I have already provided a description, under non-disclosure, to Bosko, and he has already created a patch that works around the problem without disclosing what the problem is that it's working around, or why the workaround works, which is satisfactory to me. I have no problem with people having to crib code from FreeBSD, and use it in a particular way, in order to get the workaround. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: machdep.guessed_bootdev sysctl on i386
On 2003.02.24 01:35:02 -0500, Hiten Pandya wrote:
Okay. I have attached a patch which will nuke the sysctl, and replace
it's use in picobsd's mfs_tree rc scripts with something better, but
which still needs review. I have not tested the patch, but this patch
should not fail, hopefully.
PicoBSD does not necessarily have awk (actually most likely doesn't
since awk is 'big'). cut could be used instead since it much smaller :
mount | grep 'on / ' | cut -f 1 -d ' '
Perhaps somebody has a better way?
I have cc'ed -small, since somebody there might have good idea.
Index: src/release/picobsd/mfs_tree/etc/rc
===
RCS file: /home/ncvs/src/release/picobsd/mfs_tree/etc/rc,v
retrieving revision 1.9
diff -u -r1.9 rc
--- src/release/picobsd/mfs_tree/etc/rc 17 Nov 2002 20:19:34 - 1.9
+++ src/release/picobsd/mfs_tree/etc/rc 24 Feb 2003 06:21:31 -
@@ -7,7 +7,7 @@
HOME=/; export HOME
PATH=/bin; export PATH
-dev=`sysctl -n machdep.guessed_bootdev`
+dev=`mount | grep 'on / ' | awk '{ print $1 }'`
[ -c ${dev} ] || dev=/dev/fd0
trap echo 'Reboot interrupted'; exit 1 3
Index: src/release/picobsd/mfs_tree/stand/update
===
RCS file: /home/ncvs/src/release/picobsd/mfs_tree/stand/update,v
retrieving revision 1.5
diff -u -r1.5 update
--- src/release/picobsd/mfs_tree/stand/update 11 Mar 2002 05:15:44 - 1.5
+++ src/release/picobsd/mfs_tree/stand/update 24 Feb 2003 06:20:08 -
@@ -5,7 +5,7 @@
thefiles=$*
[ -z $thefiles ] \
thefiles=/etc/rc.conf /etc/rc.firewall /etc/master.passwd
-dev=`sysctl -n machdep.guessed_bootdev`
+dev=`mount | grep 'on / ' | awk '{ print $1 }'`
[ -c ${dev} ] || dev=/dev/fd0
mount ${dev} /mnt
if [ $? != 0 ] ; then
[CUT]
--
Simon L. Nielsen
pgp0.pgp
Description: PGP signature
Re: Vinum R5 [was: Re: background fsck deadlocks with ufs2 and big disk]
Terry Lambert [EMAIL PROTECTED] wrote: I think this is an expected problem with a lot of concatenation, whether through Vinum, GEOM, RAIDFrame, or whatever. This comes about for the same reason that you can't mount -u to turn Soft Updates from off to on: Soft Updates does not tolerate dirty buffers for which a dependency does not exist, and will crap out when a pending dirty buffer causes a write. Does this affect background fsck, too (on regular, non-vinum filesystems)? From what little I know of bg fsck, I'm guessing not, but I'd like to be sure. Thanks. -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Problem with M_COPY_PACKET
Craig Rodrigues (Mon, Feb 24, 2003 at 12:07:02PM -0500) wrote:
The code in question looks like:
=
struct mbuf *
copy_mbuf(struct mbuf *m)
{
struct mbuf *new;
MGET(new, M_DONTWAIT, MT_DATA);
if(new == NULL)
return NULL;
if(m-m_flags M_PKTHDR)
M_COPY_PKTHDR(new, m);
What you need, is m_dup_pkthdr(). M_COPY_PKTHDR has been
deprecated for several reasons, that are outlined in the
commit log of rev. 1.109 of sys/sys/mbuf.h.
Cheers.
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Problem with M_COPY_PACKET
On Mon, 24 Feb 2003, Hiten Pandya wrote:
HPCraig Rodrigues (Mon, Feb 24, 2003 at 12:07:02PM -0500) wrote:
HP The code in question looks like:
HP =
HP struct mbuf *
HP copy_mbuf(struct mbuf *m)
HP {
HP struct mbuf *new;
HP
HP MGET(new, M_DONTWAIT, MT_DATA);
HP if(new == NULL)
HP return NULL;
HP if(m-m_flags M_PKTHDR)
HP M_COPY_PKTHDR(new, m);
HP
HPWhat you need, is m_dup_pkthdr(). M_COPY_PKTHDR has been
HPdeprecated for several reasons, that are outlined in the
HPcommit log of rev. 1.109 of sys/sys/mbuf.h.
I wrote that code. It must be a M_MOVE_PKTHDR, because m is just disposed
afterwards.
harti
--
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: machdep.guessed_bootdev sysctl on i386
Simon L. Nielsen [EMAIL PROTECTED] wrote: PicoBSD does not necessarily have awk (actually most likely doesn't since awk is 'big'). cut could be used instead since it much smaller : mount | grep 'on / ' | cut -f 1 -d ' ' Perhaps somebody has a better way? Does PicoBSD have sed? If it does: mount | sed -n 's/^\([^ ]*\) on \/ .*/\1/p' Doesn't win a beauty contest, but saves one exec. (It could be done with ed, too, if there's no sed.) 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-current in the body of the message
Re: Panic while on mid-load network traffic
Am Mo, 2003-02-24 um 16.52 schrieb Jonathan Lemon: On Mon, Feb 24, 2003 at 12:43:43PM -0300, Fred Souza wrote: Do you have revision 1.196 of netinet/tcp_input.c? If not, please re-cvsup, as this version has some fixes that might apply in your Hi Hm, my system is still panicing. Gnutella crashes my system almost immediately now. ;) This seems to be caused by: = KASSERT(headlocked, (headlocked should be 1)); $FreeBSD: src/sys/netinet/tcp_input.c,v 1.196 2003/02/24 00:52:03 hsu Exp $ $FreeBSD: src/sys/netinet/ip_input.c,v 1.226 2003/02/23 00:47:06 sam Exp $ And here the backtrace: GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... panic: bremfree: bp 0xc73b6410 not locked panic messages: --- panic: headlocked should be 0 syncing disks, buffers remaining... panic: bremfree: bp 0xc73b6410 not locked Uptime: 4m5s Dumping 247 MB ata0: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 --- #0 doadump () at ../../../kern/kern_shutdown.c:239 239 dumping++; (kgdb) bt #0 doadump () at ../../../kern/kern_shutdown.c:239 #1 0xc01ad309 in boot (howto=260) at ../../../kern/kern_shutdown.c:371 #2 0xc01ad538 in panic () at ../../../kern/kern_shutdown.c:542 #3 0xc01e4659 in bremfreel (bp=0xc73b6410) at ../../../kern/vfs_bio.c:672 #4 0xc01e45e1 in bremfree (bp=0xc73b6410) at ../../../kern/vfs_bio.c:659 #5 0xc01e62de in vfs_bio_awrite (bp=0xc73b6410) at ../../../kern/vfs_bio.c:1714 #6 0xc01ec6cb in vop_stdfsync (ap=0xccdbbab4) at ../../../kern/vfs_default.c:755 #7 0xc01838b3 in spec_fsync (ap=0xccdbbab4) at ../../../fs/specfs/spec_vnops.c:422 #8 0xc0182ea3 in spec_vnoperate (ap=0x0) at ../../../fs/specfs/spec_vnops.c:123 #9 0xc02715b6 in ffs_sync (mp=0xc25bea00, waitfor=2, cred=0xc0e80e80, td=0xc031be60) at vnode_if.h:612 #10 0xc01f6566 in sync (td=0xc031be60, uap=0x0) at ../../../kern/vfs_syscalls.c:138 #11 0xc01acf65 in boot (howto=256) at ../../../kern/kern_shutdown.c:280 #12 0xc01ad538 in panic () at ../../../kern/kern_shutdown.c:542 #13 0xc021dd74 in tcp_input (m=0xc0ea1d00, off0=20) at ../../../netinet/tcp_input.c:2251 #14 0xc02171cd in ip_input (m=0xc0ea1d00) at ../../../netinet/ip_input.c:947 #15 0xc021724d in ipintr () at ../../../netinet/ip_input.c:965 #16 0xc0205e70 in swi_net (dummy=0x0) at ../../../net/netisr.c:97 #17 0xc019e5b6 in ithread_loop (arg=0xc0e8f100) at ../../../kern/kern_intr.c:536 #18 0xc019d9cf in fork_exit (callout=0xc019e490 ithread_loop, arg=0xc0e8f100, frame=0xccdbbd48) at ../../../kern/kern_fork.c:871 bye -- Tobias Reifenberger -- [EMAIL PROTECTED] -- DG1NGT GEE e* dpu s:- a-- C+++ UB+++ L- W+ N+ w--- Y+ tv+ b++ D++ h++ r--- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
problems with umass device
Hello current-users! I'm not having any luck getting my USB flash drive to work. The machine runs current as of today (24:th feb). Below is the output I get when I connect the drive. Does anyone have any ideas? -Richard usbd_new_device bus=0xc404a000 port=2 depth=1 speed=2 usbd_new_device: adding unit addr=2, rev=110, class=0, subclass=0, protocol=0, maxpacket=64, len=18, speed=2 usbd_new_device: new dev (addr 2), dev=0xc4178d80, parent=0xc4059f00 usbd_probe_and_attach: trying device specific drivers usbd_probe_and_attach: no device specific driver found usbd_probe_and_attach: looping over 1 configurations usbd_set_config_index: status=0x0001, error=NORMAL_COMPLETION usbd_set_config_index: (addr 1) cno=2 attr=0xc0, selfpowered=1, power=100 usbd_set_config_index: set config 1 umass0: Creative Tech NOMAD MuVo, rev 1.10/0.01, addr 2 umass0: SCSI over Bulk-Only; quirks = 0x000 umass0: Get Max Lun not supported (IOERROR) umass0:0:0:-1: Attached to scbus0 as device 0 da0 at umass-sim0 bus 0 target 0 lun 0 da0: CREATIVE NOMAD_MUVO 0001 Removable Direct Access SCSI-4 device da0: 1.000MB/s transfers da0: 125MB (256001 512 byte sectors: 64H 32S/T 125C) umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR [ Many repetitions of the umass0: triplet above...] Opened disk da0 - 5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Problem with M_COPY_PACKET
Harti Brandt (Mon, Feb 24, 2003 at 08:46:13PM +0100) wrote:
On Mon, 24 Feb 2003, Hiten Pandya wrote:
HPCraig Rodrigues (Mon, Feb 24, 2003 at 12:07:02PM -0500) wrote:
HP The code in question looks like:
HP =
HP struct mbuf *
HP copy_mbuf(struct mbuf *m)
HP {
HP struct mbuf *new;
HP
HP MGET(new, M_DONTWAIT, MT_DATA);
HP if(new == NULL)
HP return NULL;
HP if(m-m_flags M_PKTHDR)
HP M_COPY_PKTHDR(new, m);
HP
HPWhat you need, is m_dup_pkthdr(). M_COPY_PKTHDR has been
HPdeprecated for several reasons, that are outlined in the
HPcommit log of rev. 1.109 of sys/sys/mbuf.h.
I wrote that code. It must be a M_MOVE_PKTHDR, because m is just disposed
afterwards.
OK. This was mentioned in the comment in sys/mbuf.h and the commit log
too. :-)
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ports make index returns warnings/errors
On Mon, Feb 24, 2003 at 12:35:37PM +0100, Christoph Kukulies wrote: I cvsupped a moment before including ports-all and - since I've learnt to 'make index' afterwards - making index returns Generating INDEX-5 - please wait../nonexistentlocal: not found Makefile, line 30: warning: /nonexistentlocal returned non-zero status and more of that. Yes. See failure notices on ports@ Kris pgp0.pgp Description: PGP signature
Re: machdep.guessed_bootdev sysctl on i386
sorry for the crosspost but since it originated on -current maybe people interested in the rest of the discussion were there. I introduced the sysctl to export some amount of information to be used by picobsd disks to tell whether you booted from floppy or atapi disk. In turn, this is useful (and used) if you want to update something on the boot media for the next boot. The file system mounted on / has no relation with the boot device, e.g. in the picobsd case you will have an md disk mounted on root. So, the proposed replacement is not helpful. Please do not nuke the sysctl unless you have a replacement that can work where it is supposed to work. And if someone wants to propose a replacement, please remember that this compiles but i have not tested it tells absolutely nothing on how appropriate is the proposed patch. thanks luigi On Mon, Feb 24, 2003 at 09:13:35PM +0100, Oliver Fromme wrote: Simon L. Nielsen [EMAIL PROTECTED] wrote: PicoBSD does not necessarily have awk (actually most likely doesn't since awk is 'big'). cut could be used instead since it much smaller : mount | grep 'on / ' | cut -f 1 -d ' ' Perhaps somebody has a better way? Does PicoBSD have sed? If it does: mount | sed -n 's/^\([^ ]*\) on \/ .*/\1/p' Doesn't win a beauty contest, but saves one exec. (It could be done with ed, too, if there's no sed.) 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-small in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Vinum R5 [was: Re: background fsck deadlocks with ufs2 and big disk]
Darryl Okahata wrote: Terry Lambert [EMAIL PROTECTED] wrote: I think this is an expected problem with a lot of concatenation, whether through Vinum, GEOM, RAIDFrame, or whatever. This comes about for the same reason that you can't mount -u to turn Soft Updates from off to on: Soft Updates does not tolerate dirty buffers for which a dependency does not exist, and will crap out when a pending dirty buffer causes a write. Does this affect background fsck, too (on regular, non-vinum filesystems)? From what little I know of bg fsck, I'm guessing not, but I'd like to be sure. Thanks. No, it doesn't. Background fsck works by assuming that the only thing that could contain bad data is the cylinder group bitmaps, which means the worst case failure is some blocks are not available for reallocation. It works by taking a snapshot, which is a feature that allows modification of the FS while the bgfsck's idea of the FS remains unchanged. Then it goes through the bitmaps, verifying that the blocks it thinks are allocated are in fact allocated by files within the snapshot. Basically, it's only job is really to clear bits in the bitmap that represent blocks for which there are no files referencing them. There are situations where bgfsck can fail, sometimes catastrophically, but they are unrelated to having dirty blocks in memory for which no updates have been created. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: problems with umass device
I've got a cheesy cigar-pro USB flash-drive (256MB) that works fine on current (as of last night) -- Thus, Richard Nyberg had said: Hello current-users! I'm not having any luck getting my USB flash drive to work. The machine runs current as of today (24:th feb). Below is the output I get when I connect the drive. Does anyone have any ideas? -Richard usbd_new_device bus=0xc404a000 port=2 depth=1 speed=2 usbd_new_device: adding unit addr=2, rev=110, class=0, subclass=0, protocol=0, maxpacket=64, len=18, speed=2 usbd_new_device: new dev (addr 2), dev=0xc4178d80, parent=0xc4059f00 usbd_probe_and_attach: trying device specific drivers usbd_probe_and_attach: no device specific driver found usbd_probe_and_attach: looping over 1 configurations usbd_set_config_index: status=0x0001, error=NORMAL_COMPLETION usbd_set_config_index: (addr 1) cno=2 attr=0xc0, selfpowered=1, power=100 usbd_set_config_index: set config 1 umass0: Creative Tech NOMAD MuVo, rev 1.10/0.01, addr 2 umass0: SCSI over Bulk-Only; quirks = 0x000 umass0: Get Max Lun not supported (IOERROR) umass0:0:0:-1: Attached to scbus0 as device 0 da0 at umass-sim0 bus 0 target 0 lun 0 da0: CREATIVE NOMAD_MUVO 0001 Removable Direct Access SCSI-4 device da0: 1.000MB/s transfers da0: 125MB (256001 512 byte sectors: 64H 32S/T 125C) umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR [ Many repetitions of the umass0: triplet above...] Opened disk da0 - 5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message Virtually, Ned Wolpert [EMAIL PROTECTED] An idea is something you have; an ideology is something that has you. --Morris Berman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
What broke X between 5.0R and recent current?
So I got a new Dell laptop, ATI Radeon 7500. Installed FreeBSD 5.0-RELEASE, X 4.2.1, and KDE right off the FreeBSD Mall CD-ROM. I configured X from the installation setup and was happily running X and KDE @ 1400x1050. Cool. Then I cvsup'd to a recent -current from about a week ago, which my other laptop and desktop are currently running just fine (both use very old 3.x or 4.x built X's, probably XFree86 3.2.x and running with compat libraries). Now X refuses to work. It's not the kernel because before installing world, I installed the kernel and booted it to make sure everything still worked. X was happy with the old kernel too 'cause I went back and tried it again also. But after the installworld, X didn't work, not even xf86cfg. I tried the installworld with and without mergemaster'ing and X didn't work regardless. I went back and did another fresh install of 5.0R and X worked again, but after another installworld, I got the same problem. The XFree86 log file is at the end. It aborts with: [...] (II) LoadModule: ddc (II) Reloading /usr/X11R6/lib/modules/libddc.a (II) RADEON(0): VESA VBE DDC supported (II) RADEON(0): VESA VBE DDC Level none (II) RADEON(0): VESA VBE DDC transfer in appr. 2 sec. (II) RADEON(0): VESA VBE DDC read failed (==) RADEON(0): Write-combining range (0xfcff,0x8) was already clear (==) RADEON(0): Write-combining range (0xe000,0x200) (II) RADEON(0): PLL parameters: rf=2700 rd=12 min=12000 max=35000; xclk=16600 (==) RADEON(0): Using gamma correction (1.0, 1.0, 1.0) Fatal server error: Caught signal 10. Server aborting Any ideas? I'm in the process of trying a more recent -current and am also going to try and rebuild X (though we shouldn't have to do that). -- Dan Eischen XFree86 Version 4.2.1 / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 3 September 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: FreeBSD 5.0-RC i386 [ELF] Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/XFree86.0.log, Time: Mon Feb 24 10:49:06 2003 (==) Using config file: /usr/X11R6/lib/X11/XF86Config (==) ServerLayout XFree86 Configured (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device Card0 (**) |--Input Device Mouse0 (**) |--Input Device Keyboard0 (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel pc104 (**) XKB: model: pc104 (**) Option XkbLayout us (**) XKB: layout: us (==) Keyboard: CustomKeycode disabled (**) FontPath set to /usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/ (**) RgbPath set to /usr/X11R6/lib/X11/rgb (**) ModulePath set to /usr/X11R6/lib/modules (--) Using syscons driver with X support (version 2.0) (--) using VT number 9 (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.5 XFree86 XInput driver : 0.3 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.3 (II) Loader running on freebsd (II) LoadModule: bitmap (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=The XFree86 Project compiled for 4.2.1, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.3 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.2.1, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.5 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,1a30 card , rev 04 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,1a31 card , rev 04 class 06,04,00 hdr 01 (II) PCI: 00:1d:0: chip 8086,2482 card 8086,4541 rev 02 class 0c,03,00 hdr 00 (II) PCI: 00:1e:0: chip 8086,2448 card , rev 42 class 06,04,00 hdr 01 (II) PCI: 00:1f:0: chip 8086,248c card , rev 02 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,248a card 8086,4541 rev 02 class 01,01,8a hdr 00 (II) PCI: 00:1f:5: chip 8086,2485 card 1013,5959 rev 02 class 04,01,00 hdr 00 (II) PCI: 00:1f:6: chip 8086,2486 card 14f1,5422 rev 02 class 07,03,00 hdr 00 (II) PCI: 01:00:0: chip 1002,4c57 card 1028,012b rev 00 class 03,00,00 hdr 00 (II) PCI: 02:00:0: chip 10b7,9200 card 1028,012a rev 78 class 02,00,00 hdr 00 (II) PCI: 02:01:0: chip 104c,ac51 card fffc, rev
Re: LAN support for nVidia nForce2
On Tue, 2003-02-25 at 04:12, David O'Brien wrote: Should be -- I committed some support for it. rev 1.123 src/sys/pci/if_xl.c What sources are you using? Hmm.. I think that is the 3com chipset is added by some mobo vendors - not actually the nForce2 builtin network device.. http://www.freebsd.org/cgi/getmsg.cgi?fetch=174064+177805+/usr/local/www/db/text/2003/freebsd-hackers/20030126.freebsd-hackers -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[Fwd: mkisofs | burncd not working in 5.0 ?]
(forwarded from the NG comp.unix.bsd.freebsd.misc, from which I got no answer) Hi! I'm somehow surprised that the following command pipe doesn't work any more in 5.0R: $ mkisofs -J -r mydir | burncd -f /dev/acd1c -s 16 data - fixate next writeable LBA 0 writing from stdin $ _ ...and nothing else happens. I've also tried with a named pipe, also with a strange result: $ mkfifo mypipe $ mkisofs -J -r -o mypipe mydir (1s lag) mkisofs: Resource temporarily unavailable. Unable to open disc image file. If I begin at the other side of the pipe, I get the same result as case 1: $ burncd -f /dev/acd1c -s 16 data mypipe fixate $ mkisofs -J -r -o mypipe mydir next writeable LBA 0 writing from file mypipe size 0 KB Broken pipe Same results if I try to pass data in blocks by piping everything thru dd bs=2k, so I don't know any more tricks :( Not to mention that case 1 worked in 4-STABLE. Does anybody know what is happening here? Any hints will be greatly appreciated. Regards, David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Implicit typename warnings in fstream
Hi,
I did a cvsup yesterday and rebuilt the world.
The compiler I am using now is:
gcc version 3.2.2 [FreeBSD] 20030205 (release)
My compiler has a few minor patches, to enable
wchar_t support in libstdc++:
http://news.gw.com/freebsd.current/32128
If I try to compile any file which includes
fstream, I get the following warnings:
/usr/include/g++/fstream:304: warning: `typename std::basic_filebuf_CharT,
_Traits::int_type' is implicitly a typename
/usr/include/g++/fstream:304: warning: implicit typename is deprecated, please
see the documentation for details
/usr/include/g++/fstream:309: warning: `typename std::basic_filebuf_CharT,
_Traits::int_type' is implicitly a typename
/usr/include/g++/fstream:309: warning: implicit typename is deprecated, please
see the documentation for details
The lines in question are:
300 // Generic definitions.
301 template typename _CharT, typename _Traits
302 basic_filebuf_CharT, _Traits::int_type
303 basic_filebuf_CharT, _Traits::underflow()
304 { return _M_underflow_common(false); }
305
306 template typename _CharT, typename _Traits
307 basic_filebuf_CharT, _Traits::int_type
308 basic_filebuf_CharT, _Traits::uflow()
309 { return _M_underflow_common(true); }
Does anyone have any ideas?
Thanks.
--
Craig Rodrigues
http://home.attbi.com/~rodrigc
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Non-important but weird
Hi, I've just noticed it, and as the subject says, it's just weird. On Win2k/FreeBSD 4.7-STABLE (tested with a floppy install disk), my HDD usage LED blinks whenever there's disk usage, but with -CURRENT it just stays on all the time. Why does this happen, or what does it mean? Where can I find info on this behavior? Fred -- If love is the answer, could you rephrase the question? -- Lily Tomlin pgp0.pgp Description: PGP signature
Re: machdep.guessed_bootdev sysctl on i386
On Mon, 24 Feb 2003, Hiten Pandya wrote: Bruce Evans (Mon, Feb 24, 2003 at 06:27:26PM +1100) wrote: On Mon, 24 Feb 2003, I wrote: I tested with plain -current and old boot blocks. The sysctl still reports ad disks correctly. I don't care about the sysctl but want to keep the boot blocks as backwards compatible as possible. That means passing the boot device in the old encoding, which only takes a couple of lines of code. Ok, I don't want to change the encoding or anything, but I think the sysctl should be nuked. Please see my later post to this thread, I have provided a patch. The one that mostly remove stuff seems OK. piocbsd seems to have been just broken in using the sysctl to obtain the root device (the root device may be different from the boot device). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Checksum offload support for Intel 82550/82551
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: The bulk of the changes are in if_fxp.c and if_fxpreg.h. I've been testing this on 5.0-RELEASE, using 82557, 82559 and 82550 cards, and so far it seems to behave as expected. I would like to commit this, but first I want to make sure I'm not stepping on anyone's toes by doing so. I don't know who (if anyone) is maintaining the fxp driver at this point. (I think jlemon was doing, but don't know if he still is.) Tag! You're it! :-) Commit away. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
OpenSSL should define OPENSSL_THREADS?
Hi, I ran a cvsup of -CURRENT a few days ago. I have some code which assumes that OPENSSL_THREADS is defined if the OpenSSL version is greater than 0.9.7: #define OPENSSL_THREAD_DEFINES #include openssl/opensslconf.h #include openssl/opensslv.h #if OPENSSL_VERSION_NUMBER 0x0090700fL # if !defined(THREADS) # error Thread support not enabled # endif #else # if !defined(OPENSSL_THREADS) # error Thread support not enabled # endif #endif Should the OpenSSL in FreeBSD be defining OPENSSL_THREADS? Thanks. -- Craig Rodrigues http://home.attbi.com/~rodrigc [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OpenSSL should define OPENSSL_THREADS?
On Mon, Feb 24, 2003 at 09:58:21PM -0500, Craig Rodrigues wrote: Hi, I ran a cvsup of -CURRENT a few days ago. I have some code which assumes that OPENSSL_THREADS is defined if the OpenSSL version is greater than 0.9.7: I meant to say greater than or equal to 0.9.7. :) #define OPENSSL_THREAD_DEFINES #include openssl/opensslconf.h #include openssl/opensslv.h #if OPENSSL_VERSION_NUMBER 0x0090700fL # if !defined(THREADS) # error Thread support not enabled # endif #else # if !defined(OPENSSL_THREADS) # error Thread support not enabled # endif #endif Should the OpenSSL in FreeBSD be defining OPENSSL_THREADS? Thanks. -- Craig Rodrigues http://home.attbi.com/~rodrigc [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Craig Rodrigues http://home.attbi.com/~rodrigc [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: performance / /usr/src/UPDATING
kuku Can this be switched off with a single switch in the Makefile? No, or you misunderstand what FreeBSD-current is. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Checksum offload support for Intel 82550/82551
On Mon, 24 Feb 2003 18:13:42 -0800 (PST), in sentex.lists.freebsd.current you wrote: be reliable, nevermind pleasant to look at. I only have access to an 82550 card, so I don't know if this is fixed in the 82551 or not. Hi, Can you tell reliably from the dmesg which type one has ? % dmesg | egrep -i fxp|inphy fxp0: Intel Pro 10/100B/100+ Ethernet port 0xc000-0xc03f mem 0xe880-0xe881,0xe8831000-0xe8831fff irq 11 at device 1.0 on pci1 fxp0: Ethernet address 00:07:e9:09:69:60 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: Intel Pro/100 Ethernet port 0xc800-0xc83f mem 0xe8832000-0xe8832fff irq 10 at device 8.0 on pci1 fxp1: Ethernet address 00:01:80:40:0e:b3 inphy1: i82562ET 10/100 media interface on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Or do you have to look at the card / MB ? This is a good question. I apologize for not providing this info right off the bat. The fxp driver seems to use the same name strings for lots of different cards, so dmesg won't help you identify it. The only way to tell you have an 82550, other than looking at the card itself and checking for the i82550 part number, is to do: # pciconf -l | grep fxp and check for a revision code of 0xc (12) or higher. if_fxpreg.h lists a bunch of known revision values. Anything up to and including 0x9 is an 82557/8/9, which won't gain anything from these mods, I'm sorry to say. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = If stupidity were a handicap, you'd have the best parking spot. = To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
netncp/nwfs is rotting...
A few months ago there was a thread on this list discussing the state of NWFS/netncp/libncp/etc. on 5.0. Terry Lambert produced a patch [1] that made netncp compile. The patch still applies cleanly to -current and almost compiles; I broke it with ncp_ncp.c rev 1.13, adding #includes of sys/lock.h and sys/mutex.h fixes it. However, even with this patch, ncp.ko still does not load because the aout_sysvec symbol is not available. After patching ncp_load() to use SYS_MAXSYSCALL instead of elf_sysvec.sv_size, the module loads but crashes in ncp_timer(): ncp_load: [210-213] Fatal trap 12: page fault while in kernel mode fault virtual address = 0x10 fault code = supervisor read, page not present instruction pointer = 0x8:0xc1027d39 stack pointer = 0x10:0xc5b9cc8c frame pointer = 0x10:0xc5b9cc9c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, IOPL = 0 current process = 12 (swi6: clock) Even after that has been fixed, there are plenty of other bug fixes that need to be backported from smbfs. Is anyone still working on updating netncp/nwfs for 5.0? I think that it should be retired to the Attic if nobody has any plans to fix it before we create the RELENG_5 branch. Tim [1] http://marc.theaimsgroup.com/?l=freebsd-currentm=103835435100398w=2 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: ATAPI CDROM drive not found
hi, I also got same problem under DELL GX260 using recent -CURRENT. This is older -CURRENT dmesg: Feb 20 15:30:26 hwh kernel: FreeBSD 5.0-CURRENT #10: Thu Feb 20 14:42:31 CST 2003 ... Feb 20 15:30:26 hwh kernel: ad0: 76293MB IC35L080AVVA07-0 [155009/16/63] at ata0-master UDMA100 Feb 20 15:30:26 hwh kernel: acd0: CD-RW SAMSUNG CDRW/DVD SM-332B at ata1-master PIO4 Under my ThinkPad T23 I do not hit this problem. --hwh To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Checksum offload support for Intel 82550/82551
Yes, it's me. I'm still alive. And thanks to Wind River, I now know more about the Intel 8255x ethernet chipset than I ever really wanted to. Recently, I even learned how to enable checksum offload support for the 82550 and 82551 chips, and I decided it would be a good idea to add support for this to the if_fxp driver. There's a modified version of the code from 5.0-CURRENT sitting at: http://www.freebsd.org/~wpaul/Intel The bulk of the changes are in if_fxp.c and if_fxpreg.h. I've been testing this on 5.0-RELEASE, using 82557, 82559 and 82550 cards, and so far it seems to behave as expected. I would like to commit this, but first I want to make sure I'm not stepping on anyone's toes by doing so. I don't know who (if anyone) is maintaining the fxp driver at this point. (I think jlemon was doing, but don't know if he still is.) Some background: The 82550 and 82551 chips are newer than the 82559, even though their part number is lower. The 82559 has limited RX-only checksum offload capabilities. The 82550 and 82551 have IP and TCP/UDP checksum support for both TX and RX, using extended RX and TX descriptor structures. (Computing checksums across fragmented packets is _not_ supported.) The programming info used to enable the checksum offload support comes from the manual and driver source at: http://www.sourceforge.net/projects/e1000 Now, you'd think that the manual alone would be enough, but it isn't. The documentation describes the operation of TX checksum offload, which is implemented using a special command block called an IPCB. This is essentially an extended TxCB, except that where a TxCB contains two fragment pointer/length pairs, an IPCB has just one, and the extra space is used to control the packet parsing and offload capabilities. The manual also mentions the existence of extended RFDs for receive checksum offload, but the stupid thing doesn't tell you what they look like or how to enable them. For that, you have to go through Intel's Linux driver. It turns out there are extra bits in the config block that need to be set to enable extended RX mode. Also, the config block for the 82550 and 82551 is 32 bytes in size rather than 22. (The config bit to enable magic receive mode is in byte 23.) Adding support for these features while maintaining support for older chips (without making massive code changes) was a bit tricky. I don't think I did all that great a job of it, but it works. Basically, I overlaid the new IPCB structure pieces over the existing TxCB using a union. This allows the existing structure layout to be preserved for the benefit of older chips. There seems to be one annoying bug in TX checksum offload: the chip appears to botch IP header checksums for IP fragments containing less than 4 bytes. One of the tests I ran was to send a UDP packet of 1473 bytes, which ends up being fragmented across two IP datagrams, the latter containing only 1 byte of actual data. For some reason, the chip doesn't compute a proper checksum for this fragment. Consequently, TX IP header checksumming is turned off by default. If you compile the driver with -DFXP_IP_CSUM_WAR, you'll get some workaround code that attempts to hand-patch the IP checksum for datagrams of 1 to 3 bytes in size. This is not used by default because I don't consider it to be reliable, nevermind pleasant to look at. I only have access to an 82550 card, so I don't know if this is fixed in the 82551 or not. Unless anybody complains loudly, I'd like to commit this soon. I'm fairly confident that (at the very least) it doesn't break any existing functionality. Unfortunately, I'm not in a position to do in-depth performance tests right now. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = If stupidity were a handicap, you'd have the best parking spot. = To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sh: turning off NDELAY mode
In the last episode (Feb 24), Christoph P. Kukulies said: On Mon, Feb 24, 2003 at 10:27:22AM -0600, Dan Nelson wrote: In the last episode (Feb 24), Christoph Kukulies said: sh: turning off NDELAY mode appears from time to time in an xterm n my notebook running 5.0-current That means a program you were running exited without unsetting non-blocking mode, so /bin/sh fixed it for you. OK, that's /usr/X11R6/bin/mozilla. Weird. That shouldn't be messing with the tty at all. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: busdma documentation
On Mon, 24 Feb 2003, Hiten Pandya wrote: HPHarti Brandt (Mon, Feb 24, 2003 at 11:41:57AM +0100) wrote: HP On Mon, 24 Feb 2003, Dag-Erling Smorgrav wrote: HP HP DSis there any? if so, where? HP HP Hiten Pandya was/is working on this. Last time I had a look it had not HP much moved from NetBSD towards FreeBSD. Don't know about the current HP state: HP HP [1] http://www.unixdaemons.com/~hiten/work/misc/bus_dma.9.txt HP [2] http://www.unixdaemons.com/~hiten/work/misc/bus_dma.9.patch HP HPI am still working on it, and the URLs provided above are old. The new HPURL to busdma documentation stuff, is: HP HP http://www.unixdaemons.com/~hiten/work/busdma/ HP HPThere are some issues I am sorting out, and you can check my progress HPwith the TODO list in the directory. It will be finished sometime this HPweek as I was busy last week with other things, like school etc. Just a comment: the alignment argument to bus_dma_tag_create is unfortunately not used in the way you describe. It is ignored, except when bus_dmamem_alloc calls contigmalloc on all architectures. And it is used if it is larger than an IOPAGE on sparc64. If you need a smaller aligment, you must either fiddle around with a larger memory allocation (if you are going to call bus_dmamem_alloc) or rely on the undocumented fact, that aligning the virtual address also aligns the physical address (for small alignments). The latter is true at least for all architectures that have no IOMMU and for sparc. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sh: turning off NDELAY mode
In the last episode (Feb 24), Christoph Kukulies said: sh: turning off NDELAY mode appears from time to time in an xterm n my notebook running 5.0-current That means a program you were running exited without unsetting non-blocking mode, so /bin/sh fixed it for you. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: busdma documentation
Harti Brandt (Mon, Feb 24, 2003 at 11:41:57AM +0100) wrote: On Mon, 24 Feb 2003, Dag-Erling Smorgrav wrote: DSis there any? if so, where? Hiten Pandya was/is working on this. Last time I had a look it had not much moved from NetBSD towards FreeBSD. Don't know about the current state: [1] http://www.unixdaemons.com/~hiten/work/misc/bus_dma.9.txt [2] http://www.unixdaemons.com/~hiten/work/misc/bus_dma.9.patch I am still working on it, and the URLs provided above are old. The new URL to busdma documentation stuff, is: http://www.unixdaemons.com/~hiten/work/busdma/ There are some issues I am sorting out, and you can check my progress with the TODO list in the directory. It will be finished sometime this week as I was busy last week with other things, like school etc. Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
busdma documentation
is there any? if so, where? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: busdma documentation
Dag-Erling Smorgrav wrote: is there any? if so, where? Me too. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: busdma documentation
On Mon, 24 Feb 2003, Dag-Erling Smorgrav wrote: DSis there any? if so, where? Hiten Pandya was/is working on this. Last time I had a look it had not much moved from NetBSD towards FreeBSD. Don't know about the current state: [1] http://www.unixdaemons.com/~hiten/work/misc/bus_dma.9.txt [2] http://www.unixdaemons.com/~hiten/work/misc/bus_dma.9.patch harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
