Re: crash - perhaps vinum or sym related
On Sat, Apr 29, 2000 at 08:53:24AM +0930, Greg Lehey wrote: > On Friday, 28 April 2000 at 18:49:08 +0200, Jesper Skriver wrote: > > > > I'm not sure if this is a vinum problem, or a problem with the sym > > driver, I hope someone is able to help us here. > > It's difficult to tell from the backtrace. The crash happens in the > sym driver, but it is interrupted out of Vinum. I'd need to look at > the dump. The box hangs now, so I'll need to go press the reset button, when I'm there I'll reproduce the crash again - what exactly do you want ? It it what you specify at http://www.lemis.com/vinum/how-to-debug.html#panic or ? Just making sure I get the correct information to you. > >> From /var/log/messages: > > Try to trim this more in future. Will do. /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work:Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek@ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: module dependency metadata committed
A functional checkpoint of module metadata has been committed in -current. This is to provide a decent module-level dependency and versioning system, rather than the mostly-broken file-level system that presently exists. Not everything is in place yet, so the KMODDEPS lines in modules/*/Makefile are still there so that the current loader does the right thing still. There was work in the pipeline some time ago to implement the metadata strategy, but it's not strictly required yet. Dependency information is presently being done twice - once for loader's benefit (using KMODDEPS and DT_NEEDED), and one for the in-kernel code's benefit (using metadata in linker sets). I'm fairly sure it will work wothout causing too much trouble, I've been doing crash-and-burn testing over the last two days, and incidently, found some nasty bugs where I didn't expect to find them. The ipfw and linux kld's have a nasty habit of randomly corrupting the malloc pool on unload (even before my changes) - so don't try load/unload loops on those two. :-> See the commit message for more detail. There will be more work over the next few days, including resolving how the version numbers will be enforced. The present version numbers are ignored. The good news though.. once this is all done, the nasty suprises that turn up if you accidently get your kld's out of sync with a kernel should be a thing of the past. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
MVP3 problems - current state?
Hello! 2320: * * * W A R N I N G * * * The ata driver has some issues with the Apollo MVP3 chipset. Drives work only in pio mode and must be set to pio mode early int the boot process. Do not upgrade. If you must upgrade in the face of this, add /sbin/sysctl -w hw.atamodes=pio,pio,pio,pio to the start of /etc/rc.conf. Even if you do this, any and all damage to your system is at your own risk. You have been warned. * * * W A R N I N G * * * Of _course_ I own such a thing. FreeBSD 5.0-CURRENT #0: Fri Mar 31 16:52:11 CEST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/cichlids pcib0: on motherboard pci0: on pcib0 pcib2: at device 1.0 on pci0 atapci0: port 0xe000-0xe00f at device 7.1 on pci0 Two things: As you can see, my -current is from Mar 31,though I don't know exaclty if I've taken sourcs from Mar 31, but I'm kinda sure. Question is: Does the problem affect all versions? It doesn't seem so, since I'm running two disks at UDMA33 without problems: ad0: 4133MB [8959/15/63] at ata0-master using UDMA33 ad2: 6197MB [12592/16/63] at ata1-master using UDMA33 There still is a little chance that my sources wasn't from pre-03/20, so - is this problem fixed? Alex -- I need a new ~/.sig. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MVP3 problems - current state?
I spread stupidity: > There still is a little chance that my sources wasn't from pre-03/20, > so - is this problem fixed? I mean: There still is a little chance that my sources were from pre-03/20, and if I update now I'm running into problems. That's why I ask if the problem is fixed. Alex -- I need a new ~/.sig. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: crash - perhaps vinum or sym related
On Sat, Apr 29, 2000 at 02:20:47PM +0200, Jesper Skriver wrote: > On Sat, Apr 29, 2000 at 08:53:24AM +0930, Greg Lehey wrote: > > On Friday, 28 April 2000 at 18:49:08 +0200, Jesper Skriver wrote: > > > > > > I'm not sure if this is a vinum problem, or a problem with the sym > > > driver, I hope someone is able to help us here. > > > > It's difficult to tell from the backtrace. The crash happens in the > > sym driver, but it is interrupted out of Vinum. I'd need to look at > > the dump. > > The box hangs now, so I'll need to go press the reset button, when I'm > there I'll reproduce the crash again - what exactly do you want ? > > It it what you specify at http://www.lemis.com/vinum/how-to-debug.html#panic > or ? Just making sure I get the correct information to you. We build a debug kernel, and enabled kernel dumps, as described in the handbook (http://www.freebsd.org/handbook/kerneldebug.html#AEN20443), but it didn't write a kernel dump, can anyone see what we did wrong ? remie# dumpon -v /dev/da0s1b dumpon: crash dumps to /dev/da0s1b (13, 131073) remie# Apr 29 17:49:59 remie su: ncbp to root on /dev/ttyp0 Apr 29 17:49:59 remie su: ncbp to root on /dev/ttyp0 Apr 29 17:50:06 remie /kernel: vinum: raid01.p1.s0 is reviving, not up Apr 29 17:50:06 remie /kernel: vinum: raid01.p1.s1 is reviving, not up Apr 29 17:50:06 remie /kernel: vinum: raid01.p1.s2 is reviving, not up Apr 29 17:50:06 remie /kernel: vinum: raid01.p1.s3 is reviving, not up Apr 29 sym0:3: ERROR (81:0) (8-0-0) (1f/9f) @ (mem 8:f000ff53). sym0: regdump: da 00 00 9f 47 1f 03 03 04 08 81 00 80 00 0f 02 00 aa 7b 00 02 ff ff ff. sym1: bad DSA (8bac00) in done queue. sym1:2: ERROR (81:0) (0-a7-80) (1f/9f) @ (mem 8:f000ff53). sym1: regdump: da 10 80 9f 47 1f 02 03 0c 00 88 a7 80 00 0f 02 00 a2 7b 00 08 ff ff ff. (noperiph:sym0:0:-1:-1): SCSI BUS reset detected. Fatal trap 12: page fault while in kernel mode mp_lock = 0103; cpuid = 1; lapic.id = fault virtual address = 0x4 fault code = supervisor write, page not present instruction pointer = 0x8:0xc012f19c stack pointer = 0x10:0xc6233bdc frame pointer = 0x10:0xc6233be8 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 = 222 (vinum) interrupt mask = cam <- SMP: XXX kernel: type 12 trap, code=0 Stopped at sym_flush_comp_queue+0x1c: movl%edi,0x4(%eax) db> trace sym_flush_comp_queue(c08bb000,e,384,c08bb000,c6233c1c) at sym_flush_comp_queue+0x1c sym_flush_busy_queue(c08bb000,e,c08bb000,2,c09a1bfa) at sym_flush_busy_queue+0x53 sym_init(c08bb000,1,c0235510,c05a1690,6bf8) at sym_init+0xec sym_intr1(c08bb000,c6233cc0,c02102d5,c08bb000,0) at sym_intr1+0x119 sym_intr(c08bb000,0,c6230018,c6230010,c08c0010) at sym_intr+0xb Xresume16() at Xresume16+0x38 --- interrupt, eip = 0xc0225aa8, esp = 0xc6233c98, ebp = 0xc6233cc0 --- splx(24,c09a1bc0,c8,9c00,af80) at splx+0x30 vinumstart(c1d3cc4c,1,c0bca000,13,c0bca000) at vinumstart+0x45 revive_block(13,c0bca000,c098aa00,c5cd2040,0) at revive_block+0x363 start_object(c0bca000,0,c098aa00,c5cd2040,c621f6c0) at start_object+0x10d setstate(c0bca000,c6233de4,c098aa00,c0bca000,c6233db4) at setstate+0x205 vinumioctl(c098aa00,c400464c,c0bca000,3,c5cd2040) at vinumioctl+0x4f9 spec_ioctl(c6233de4,c6233dcc,c01ec895,c6233de4,c6233e74) at spec_ioctl+0x26 spec_vnoperate(c6233de4,c6233e74,c0180f38,c6233de4,c0b353c0) at spec_vnoperate+0x15 ufs_vnoperatespec(c6233de4,c0b353c0,0,400,c0258600) at ufs_vnoperatespec+0x15 vn_ioctl(c0b353c0,c400464c,c0bca000,c5cd2040,3) at vn_ioctl+0x110 ioctl(c5cd2040,c6233f80,bfbff6c4,bfbff244,13) at ioctl+0x20b syscall2(2f,2f,2f,13,bfbff244) at syscall2+0x219 Xint0x80_syscall() at Xint0x80_syscall+0x2c db> continue Fatal trap 12: page fault while in kernel mode mp_lock = 0103; cpuid = 1; lapic.id = fault virtual address = 0x4 fault code = supervisor write, page not present instruction pointer = 0x8:0xc012f19c stack pointer = 0x10:0xc6233bdc frame pointer = 0x10:0xc6233be8 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 = 222 (vinum) interrupt mask = cam <- SMP: XXX kernel: type 12 trap, code=0 Stopped at sym_flush_comp_queue+0x1c: movl%edi,0x4(%eax) db> continue Fatal trap 12: page fault while in kernel mode mp_lock = 0103; cpuid = 1; lapic.id = fault virtual address = 0x4 fault code = supervisor write, page not present instruction pointer = 0x8:0xc012f19c stack pointer = 0x10:0xc6233bdc frame pointer = 0x10:0xc6233be8 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 proces
ldconfig -m not configuring ?
Dear FreeBSD'ers I cvsup'ed -CURRENT on 25 April at about 9 GMT. I succesfully made the world apart from a couple of minor issues. In the next few days, I installed some ports and, in, particular, the linux_base-6.1 port; then I installed StarOffice5.1a (via ports). Everything seemed to work properly. I installed Acrobat Reader 4.05 (via ports) and then other ports (e.g. Apsfilter (ie teTeX), lyx, textproc/docproj, ...) and I configured JADETEX & C. But when I issued "acroread4", the terminal spat out "ELF interpreter /lib/ld-linux.so.2 not found." The interpreter does exist in /usr/compat/linux/lib/ld-linux.so.2 --> ld-2.1.2.so and this is what "file ld-2.1.2.so" says: ld-2.1.2.so: ELF 32-bit LSB shared object, Intel 80386, version 1, not stripped. I issued a "ldconfig -r | grep ld-linux" and, actually, I found nothing. Then I issued a "ldconfig -m /usr/compat/linux/lib" and even a "ldconfig -aout -m /usr/compat/linux/lib" (paranoia.) Now ldconfig -r shows a bunch of /usr/compat/linux/lib libraries EXCEPT the one I would have liked it to save among the hints. For some obscure (to me) reason, it refuses to take ld-linux.so.2 (ie ld-2.1.2.so) into consideration. By the way, acroread is correctly brandelfed, since it was installed after remaking the -CURRENT world. Just to be paranoidly safe, I rebrandelfed it, and a diff with the .orig version (previously copied) of course showed no difference. What prevents ldconfig -m /usr/compat/linux/lib from doing its duty ? What am I missing ? Many thanks in advance and happy weekend, Salvo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re:Sound problem
Hopefully I'm hiting the right thread here - This is in reply to the post about excessively high loads caused by xmms. I'm showing about 90% from xmms as well. However, I'm not sure it's real. I'm not seeing much, if any slowdown. Is top the tool I should be using to figure this out? Possible causes: I rebuild xmms and my kernel/world last night, and it showed up. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re:Sound problem
> about excessively high loads caused by xmms. I'm showing about 90% from > xmms as well. However, I'm not sure it's real. I'm not seeing much, if > any slowdown. Is top the tool I should be using to figure this out? > > Possible causes: I rebuild xmms and my kernel/world last night, and it > showed up. FYI, I have seen top report 100% usage when zombie or stopped processes were active yet a vmstat or uptime reports normal operation. I would suspect top. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kde2pre: is it FreeBSD or Kde fault?
Hey Vallo, You can try to edit the libtool file in the kdelibs directory to set deplibs="$deplibs -lc -lgcc" (around line number 2600). This will link the __eh_rtime_match. I still get a nonworking khtm however.. : khtml (cache): CachedImage::ref() khtml (cache): Cache::notify() konqueror: KCrash: crashing crashRecursionCounter = 0 konqueror: KCrash: Appname = 0x8073fb0 apppath = 0x0 konqueror: Unable to start dr. konqi DCOP: unregister 'konqueror'kio (KIOConnection): read kio (kioslave): slavewrapper: Communication with app lost. Returning to slave pool. Any ideas? --jh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re:Sound problem
Ok, I'll try to get a better handle on whether or not it's real. On Sat, 29 Apr 2000, Kevin Lyons wrote: > > about excessively high loads caused by xmms. I'm showing about 90% from > > xmms as well. However, I'm not sure it's real. I'm not seeing much, if > > any slowdown. Is top the tool I should be using to figure this out? > > > > Possible causes: I rebuild xmms and my kernel/world last night, and it > > showed up. > > FYI, I have seen top report 100% usage when zombie or stopped processes > were active yet a vmstat or uptime reports normal operation. I would suspect > top. > > > > 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: crash - perhaps vinum or sym related
On Sat, Apr 29, 2000 at 06:11:08PM +0200, Jesper Skriver wrote: > On Sat, Apr 29, 2000 at 02:20:47PM +0200, Jesper Skriver wrote: > > On Sat, Apr 29, 2000 at 08:53:24AM +0930, Greg Lehey wrote: > > > On Friday, 28 April 2000 at 18:49:08 +0200, Jesper Skriver wrote: > > > > > > > > I'm not sure if this is a vinum problem, or a problem with the sym > > > > driver, I hope someone is able to help us here. > > > > > > It's difficult to tell from the backtrace. The crash happens in the > > > sym driver, but it is interrupted out of Vinum. I'd need to look at > > > the dump. > > > > The box hangs now, so I'll need to go press the reset button, when I'm > > there I'll reproduce the crash again - what exactly do you want ? > > > > It it what you specify at http://www.lemis.com/vinum/how-to-debug.html#panic > > or ? Just making sure I get the correct information to you. > > We build a debug kernel, and enabled kernel dumps, as described in the > handbook (http://www.freebsd.org/handbook/kerneldebug.html#AEN20443), > but it didn't write a kernel dump, can anyone see what we did wrong ? I don't know what happened before, but now we got a kernel dump, I'll sent you the URL's in a private email. remie# gdb -k GNU gdb 4.18 Copyright 1998 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-unknown-freebsd". (kgdb) symbol-file kernel.debug Reading symbols from kernel.debug...done. (kgdb) exec-file /var/crash/kernel.0 (kgdb) core-file /var/crash/vmcore.0 SMP 2 cpus IdlePTD 3063808 initial pcb at 278820 panicstr: from debugger panic messages: --- Fatal trap 12: page fault while in kernel mode mp_lock = 0103; cpuid = 1; lapic.id = fault virtual address = 0x4 fault code = supervisor write, page not present instruction pointer = 0x8:0xc012f19c stack pointer = 0x10:0xc6233bdc frame pointer = 0x10:0xc6233be8 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 = 222 (vinum) interrupt mask = cam <- SMP: XXX Fatal trap 12: page fault while in kernel mode mp_lock = 0103; cpuid = 1; lapic.id = fault virtual address = 0x4 fault code = supervisor write, page not present instruction pointer = 0x8:0xc012f19c stack pointer = 0x10:0xc6233bdc frame pointer = 0x10:0xc6233be8 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 = 222 (vinum) interrupt mask = cam <- SMP: XXX Fatal trap 12: page fault while in kernel mode mp_lock = 0103; cpuid = 1; lapic.id = fault virtual address = 0x4 fault code = supervisor write, page not present instruction pointer = 0x8:0xc012f19c stack pointer = 0x10:0xc6233bdc frame pointer = 0x10:0xc6233be8 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 = 222 (vinum) interrupt mask = cam <- SMP: XXX panic: from debugger mp_lock = 0103; cpuid = 1; lapic.id = Fatal trap 12: page fault while in kernel mode mp_lock = 0104; cpuid = 1; lapic.id = fault virtual address = 0x4 fault code = supervisor write, page not present instruction pointer = 0x8:0xc012f19c stack pointer = 0x10:0xc6233bdc frame pointer = 0x10:0xc6233be8 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 = 222 (vinum) interrupt mask = cam <- SMP: XXX panic: from debugger mp_lock = 0104; cpuid = 1; lapic.id = boot() called on cpu#1 Uptime: 5m46s (da5:sym0:0:0:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da6:sym0:0:1:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da7:sym0:0:2:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da8:sym0:0:3:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da9:sym0:0:4:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da10:sym0:0:5:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da11:sym0:0:6:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da12:sym0:0:8:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 (da13:sym0:0:9:0): Synchron
high CPU usage by xmms
Ok, I checked, and vmstat shows cpu usage to be quite normal, about 6% while playing. What's up w/ top? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: high CPU usage by xmms
> Ok, I checked, and vmstat shows cpu usage to be quite normal, about 6% > while playing. What's up w/ top? Not on my computer: pantzer@skalman ~ >vmstat -w 1 procs memory pagedisks faults cpu r b w avm fre flt re pi po fr sr ad0 da0 in sy cs us sy id 4 1 0 339480 5552 131 0 0 1 147 233 0 0 288 1722 1971 6 5 89 1 1 0 339480 55328 0 0 0 0 0 3 1 312 34105 34350 16 84 0 1 1 0 339456 55565 0 0 0 6 0 0 0 321 34349 34608 10 90 0 1 1 0 339456 55525 0 0 0 0 0 0 1 321 34211 34484 12 88 0 If you only run vmstat you get the average since the computer started. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kernel builds fail
I can't build a kernel after CVSUP'ing today. After successfully completing a `make world', I tried to build a kernel. Edited script below. chapel-hill# cd /sys/i386/conf chapel-hill# rm -rf ../../compile/GENERIC chapel-hill# config GENERIC WARNING: Old ISA driver compatability shims present. Don't forget to do a ``make depend'' Kernel build directory is ../../compile/GENERIC chapel-hill# cd ../../compile/GENERIC chapel-hill# make -s depend all ./aicasm: 725 instructions used [[ lots of warnings deleted ]] ../../kern/vfs_bio.c:2584: warning: no previous prototype for `biowait' [[ more warnings deleted ]] linking kernel vfs_bio.o: In function `bread': vfs_bio.o(.text+0x485): undefined reference to `bufwait' vfs_bio.o: In function `breadn': vfs_bio.o(.text+0x64f): undefined reference to `bufwait' vfs_bio.o: In function `bwrite': vfs_bio.o(.text+0x87e): undefined reference to `bufwait' vfs_cluster.o: In function `cluster_read': vfs_cluster.o(.text+0x481): undefined reference to `bufwait' nfs_vnops.o: In function `nfs_writebp': nfs_vnops.o(.text+0x11951): undefined reference to `bufwait' ffs_inode.o(.text+0xc0c): more undefined references to `bufwait' follow *** Error code 1 Stop in /usr/src/sys/compile/GENERIC. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ldconfig not configuring NOT solved: followup (RTFM .RTFM RTFM ... )
Dear FreeBSD'ers, I apologize for the previous very superficial question. I had missed the Linux mode stuff I RTFMed it. However, the problem is still there *re-sigh* I ran the Linux ldconfig, ie /usr/compat/linux/sbin/ldconfig -p | grep ld: it said that ld-linux-so.2 WAS in the hints. Then I ran /usr/compat/linux/ldconfig (no options). And yet I got the same error when I launched "acroread4": ELF interpreter /lib/ld-linux.so.2 not found. I made a copy of ld-2.1.2.so (the actual file referred to by ld-linux.so.2) with suffix .orig, and I brandelfed -t Linux ld.2.1.2.so. Alas, it did NOT work either. I had a look at another slice (4-STABLE) of mine, where Acrobat Reader 4.05 works. BTW, the ld.so.cache was equal. I have not yet discovered any illuminating difference in the /usr/compat/linux subtree. **If** I fully understand the situation and if I am not missing other pieces of the puzzle, the "syntax" is all right. Therefore the problem should be "semantical". In other words, under 5-CURRENT (sources as of 25 April 9 GMT) the Linux mode does NOT work properly. Please note: StarOffice 5.1a works whereas Acrobat Reader (which requires the ld-linux.so.2 interpreter) does NOT. This problem should not be related to the brandelf issue: I installed the linux_base-6.1 and a couple of Linux-emulated ports (StarOffice, Acrobat) *after* making the 5-CURRENT world. As I said in the previous message, StarOffice works. And brandelfing acroread produces a file *equal* to the non-brandelfed acroread. What am I missing now ? Is the Linux mode just broken ? Thanks in advance again for any help and best regards, Salvo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: high CPU usage by xmms
I did reboot for that reason, but I retried it and got about 50. Mabey I didn't run the player long enough... > > Ok, I checked, and vmstat shows cpu usage to be quite normal, about 6% > > while playing. What's up w/ top? > > Not on my computer: > > pantzer@skalman ~ >vmstat -w 1 > procs memory pagedisks faults cpu > r b w avm fre flt re pi po fr sr ad0 da0 in sy cs us sy id > 4 1 0 339480 5552 131 0 0 1 147 233 0 0 288 1722 1971 6 5 89 > 1 1 0 339480 55328 0 0 0 0 0 3 1 312 34105 34350 16 84 0 > 1 1 0 339456 55565 0 0 0 6 0 0 0 321 34349 34608 10 90 0 > 1 1 0 339456 55525 0 0 0 0 0 0 1 321 34211 34484 12 88 0 > > > If you only run vmstat you get the average since the computer started. > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
WaveLan wi0
On today's current, I plugged in my WaveLan Card that I haven't used for about a week and it first has a problem with IRQ: wi0: No irq?!I added some others and it responded with: wi0: No I/O space?! Has something changed in the last few days that would cause this? My network card DE-660 just keeps plugging away, thank goodness:-) Thanks for any help, ed To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: high CPU usage by xmms
I'm also getting this behavior now. It's not the xmms binary that's taking all the cpu though... top reports it as "system" CPU usage. = | Kenneth Culver | FreeBSD: The best OS around.| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = On Sat, 29 Apr 2000, VINSON WAYNE HOWARD wrote: > I did reboot for that reason, but I retried it and got about 50. Mabey I > didn't run the player long enough... > > > > > Ok, I checked, and vmstat shows cpu usage to be quite normal, about 6% > > > while playing. What's up w/ top? > > > > Not on my computer: > > > > pantzer@skalman ~ >vmstat -w 1 > > procs memory pagedisks faults cpu > > r b w avm fre flt re pi po fr sr ad0 da0 in sy cs us sy id > > 4 1 0 339480 5552 131 0 0 1 147 233 0 0 288 1722 1971 6 5 89 > > 1 1 0 339480 55328 0 0 0 0 0 3 1 312 34105 34350 16 84 0 > > 1 1 0 339456 55565 0 0 0 6 0 0 0 321 34349 34608 10 90 0 > > 1 1 0 339456 55525 0 0 0 0 0 0 1 321 34211 34484 12 88 0 > > > > > > If you only run vmstat you get the average since the computer started. > > > > > > 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: cvs commit: src/lib/libstand ext2fs
On Sat, 29 Apr 2000, Jonathan Lemon wrote: >On Sun, Apr 30, 2000 at 11:15:47AM +0930, Greg Lehey wrote: >> On Saturday, 29 April 2000 at 13:44:08 -0700, Jonathan Lemon wrote: >> > jlemon 2000/04/29 13:44:08 PDT >> > >> > Added files: >> > lib/libstand ext2fs.c >> > Log: >> > Add ext2fs support to the loader. >> >> What's the need for this? > >It allows us to see linux partition types, and load from them; >I should be able to boot a freebsd kernel and memory image from >a pure linux box, although I've only used it to load the kernel >at this point. >-- >Jonathan Not sure if this is a silly question or not, but could the kernel somehow view a specific dir on a ext2fs disk as the freebsd root and boot a freebsd system from it? Also being able to access the stuff below the freebsd root on the ext2fs partition would be cool. Any idea how much work it might take someone to do this? An alternative would be mounting a file on the ext2fs via vn as the freebsd root containing a freebsd install on ffs or ext2. This way might make it easier to have access to the underlying ext2 and make it easier for the base linux system to populate / modify if linux has trouble with ffs. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
