Re: -CURRENT slowdown in last 2 weeks
Andrea Campi wrote: Nope, UDMA33 (IBM-DARA-20600 on IBM Thinkpad). Question: you built a world yesterday, but what world did you have BEFORE? I mean, what matters is the kernel/world which was running while you were compiling, was that recent ( 15 days old)? Are you seeing any lock reversal message? The previous world and kernel where from that same day (I had been playing around with user.h and kmod.mk and rebuilt to make sure everything was still okay). I did not see any lock reversal messages. My config is pretty standard, let me know if you want a peek (the only "non-standard" bit is the fact that I'm running newcard, I doubt this would matter in this case). Best Regards, PYD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Building procedure of krb5 is broken
At 21 Feb 2001 13:45:55 GMT, Makoto MATSUSHITA wrote: Anyway, I'll wait until tomorrow's job starts at current.jp.FreeBSD.org :-) Hmmm, today's "make release" at current.jp failed. It seems a patch from matusita-san is required... o Last 50 lines of today's log ftp://current.jp.FreeBSD.org/pub/FreeBSD/snapshots/i386/5.0-CURRENT-20010222-JPSNAP.log o Full of today's log ftp://current.jp.FreeBSD.org/pub/FreeBSD/snapshots/i386/log/5.0-CURRENT-20010222-JPSNAP.log.gz -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: find(1) -regex/-iregex
* Daniel C. Sobral [EMAIL PROTECTED] [010220 19:39] wrote: Alfred Perlstein wrote: * Akinori MUSHA [EMAIL PROTECTED] [010220 11:19] wrote: Hi, I have implemented -regex and -iregex options for find(1): Sounds good, just make sure the regex engine matches the one that the other find(1)'s use. It won't. GNU find certainly uses GNU regexp library, which has lots of extra stuff. Naturally, our find will be using our library instead. shrug Nothing we can do about it. It is the way of the Gnu to extend and embrace. Well a subset or superset is fine, as long as it's the same type of regex. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernfs
On Thu, Feb 22, 2001 at 10:39:47AM +0900, Daniel C. Sobral wrote: It seems the error for kernfs is activating a couple of other warnings: I think Des retired kernfs in -current in a commit on 2000/12/28. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
A possible bug in the interrupt thread preemption code [Was: Kernel panic in irq14: ata0]
Dag-Erling Smorgrav wrote: Maxim Sobolev [EMAIL PROTECTED] writes: It's not an ata specific problem, but rather a problem of all ISA devices (I have an ISA based ata controller). I don't think it has anything to do with ISA. I've had similar problems on a PCI-only system (actually, PCI+EISA motherboard with no EISA cards) with no ATA devices (disks, CD-ROM and streamer are all SCSI). Considering that backing out rev 1.14 of ithread.c eliminates the panics, and that that revision is supposed to enable interrupt thread preemption, and that the crashed kernels show signs of stack smashing, I'd say the cause is probably a bug in the preemption code. Update: the bug is still here, as of -current from 22 Feb. Hovewer, this time it even doesn't let to boot into single-user with following panic message: kernel trap 12 with interrupts disabled panic: mutex sched lock recursed at ../../kern/kern_synch.c:872 syncing disks... -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: A possible bug in the interrupt thread preemption code [Was:
John Baldwin [EMAIL PROTECTED] writes:
On 22-Feb-01 Maxim Sobolev wrote:
Dag-Erling Smorgrav wrote:
Maxim Sobolev [EMAIL PROTECTED] writes:
It's not an ata specific problem, but rather a problem of all ISA
devices (I have an ISA based ata controller).
I don't think it has anything to do with ISA. I've had similar
problems on a PCI-only system (actually, PCI+EISA motherboard with no
EISA cards) with no ATA devices (disks, CD-ROM and streamer are all
SCSI).
Considering that backing out rev 1.14 of ithread.c eliminates the
panics, and that that revision is supposed to enable interrupt thread
preemption, and that the crashed kernels show signs of stack smashing,
I'd say the cause is probably a bug in the preemption code.
Update: the bug is still here, as of -current from 22 Feb. Hovewer, this time
it even doesn't let to boot into single-user with following panic message:
kernel trap 12 with interrupts disabled
panic: mutex sched lock recursed at ../../kern/kern_synch.c:872
E. That would be something that is leaking sched_lock. Hmm...
I have another sched_lock-related problem which showed up over the
weekend. Starting StarOffice 5.2 invariably triggers the following
panic:
root@aes /var/crash# gdb -k
sGNU 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) source ~des/kgdb
(kgdb) kernel 0
IdlePTD 3526656
initial pcb at 2cb980
panicstr: from debugger
panic messages:
---
panic: mutex sched lock not owned at ../../posix4/ksched.c:215
panic: from debugger
Uptime: 3m37s
dumping to dev ad0b, offset 262528
dump ata0: resetting devices .. done
127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107
106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81
80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52
51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23
22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
---
#0 dumpsys () at ../../kern/kern_shutdown.c:476
476 if (dumping++) {
(kgdb) where
#0 dumpsys () at ../../kern/kern_shutdown.c:476
#1 0xc0187a04 in boot (howto=260) at ../../kern/kern_shutdown.c:319
#2 0xc0187dd9 in panic (fmt=0xc02521b4 "from debugger")
at ../../kern/kern_shutdown.c:569
#3 0xc011cdad in db_panic (addr=-1071459127, have_addr=0, count=-1,
modif=0xc879cd9c "") at ../../ddb/db_command.c:433
#4 0xc011cd4b in db_command (last_cmdp=0xc0285420, cmd_table=0xc0285280,
aux_cmd_tablep=0xc02b68bc) at ../../ddb/db_command.c:333
#5 0xc011ce12 in db_command_loop () at ../../ddb/db_command.c:455
#6 0xc011f07f in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
#7 0xc022d258 in kdb_trap (type=3, code=0, regs=0xc879ce9c)
at ../../i386/i386/db_interface.c:164
#8 0xc023a098 in trap (frame={tf_fs = -1060962280, tf_es = -932118512,
tf_ds = -1060962288, tf_edi = -1071197888, tf_esi = 256,
tf_ebp = -931541272, tf_isp = -931541304, tf_ebx = 514,
tf_edx = -1071149169, tf_ecx = -1070757120, tf_eax = 18, tf_trapno = 3,
tf_err = 0, tf_eip = -1071459127, tf_cs = 8, tf_eflags = 70,
tf_esp = -1071149185, tf_ss = -1071240285}) at ../../i386/i386/trap.c:615
#9 0xc022d4c9 in Debugger (msg=0xc0262ba3 "panic") at machine/cpufunc.h:60
#10 0xc0187dd0 in panic (fmt=0xc0261a48 "mutex %s not owned at %s:%d")
at ../../kern/kern_shutdown.c:567
#11 0xc0180c89 in _mtx_assert (m=0xc02e3e20, what=1,
file=0xc026d140 "../../posix4/ksched.c", line=215)
---Type return to continue, or q return to quit---
at ../../kern/kern_mutex.c:611
#12 0xc01f0d51 in ksched_yield (ret=0xc8712f24, ksched=0xc0a97660)
at ../../posix4/ksched.c:215
#13 0xc01f100b in sched_yield (p=0xc8712dc0, uap=0xc879cf80)
at ../../posix4/p1003_1b.c:225
#14 0xc023b239 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077939044, tf_esi = 706867048, tf_ebp = -1077939116,
tf_isp = -931541036, tf_ebx = 714966384, tf_edx = 1, tf_ecx = 134979841,
tf_eax = 158, tf_trapno = 22, tf_err = 2, tf_eip = 717073383,
tf_cs = 31, tf_eflags = 514, tf_esp = -1077939144, tf_ss = 47})
at ../../i386/i386/trap.c:1191
#15 0xc022dbe3 in Xint0x80_syscall ()
#16 0x2a182a9e in ?? ()
#17 0x2a18a328 in ?? ()
#18 0x2a057f6b in ?? ()
#19 0x2a057eb5 in ?? ()
#20 0x28f5e2a9 in ?? ()
#21 0x28191db5 in ?? ()
#22 0x80513a3 in ?? ()
#23 0x28f55eab in ?? ()
#24 0x80512da in ?? ()
#25 0x2a059cf1 in ?? ()
#26 0x2a181e35 in ?? ()
---Type return to continue, or q return to quit---
#27 0x2ab551eb in ?? ()
(kgdb)
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To
Re: kernfs
David Malone wrote: On Thu, Feb 22, 2001 at 10:39:47AM +0900, Daniel C. Sobral wrote: It seems the error for kernfs is activating a couple of other warnings: I think Des retired kernfs in -current in a commit on 2000/12/28. Let me follow up on this. Kernfs is not actually the guilty party, but the problem was _not_ the kernfs warning. The problem, as I saw it, was the two following warnings (ffs and ffs_root). Alas, the ffs warning is correct but happens only once, so it seems that the guilty one was ffs. To be more precise, it seems that when the ffs warning gets activated, the ffs_root warning also gets shown. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "Too bad sentience isn't a marketable commodity." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT slowdown in last 2 weeks
On Wed, Feb 21, 2001 at 10:20:46PM +, Pierre Y. Dampure wrote: Andrea Campi wrote: I am noticing a severe slowdown on my -CURRENT system. It actually started after Feb [3-5] changes in intrupt handling, but I didn't really notice until I run a make world (which I delayed doing because of, well you guess, the libc breakage). When I say severe I mean make buildworld takes x3 longer. Hmmm. Buit world yesterday evening on a 733 VAIO, UDMA ATA drive, took around 1h15mn, which is fairly much what I would expect... U using SCSI? Nope, UDMA33 (IBM-DARA-20600 on IBM Thinkpad). Question: you built a world yesterday, but what world did you have BEFORE? I mean, what matters is the kernel/world which was running while you were compiling, was that recent ( 15 days old)? Are you seeing any lock reversal message? Thanks anyway, bye, Andrea -- Reboot America. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT slowdown in last 2 weeks
Hmm, Feb 3-5 (looks). You mean the preemptive scheduling committed on Feb 1? Can you try updating to early this week to see if it goes away? Hi John, every "recent" version I tried resulted in a slowdown so I didn't recompile very often; until tonight, I was still runninng a kernel from 20010214. Tonight I created a new kernel but I finally figured out I should take out most debugging options: options DDB # options WITNESS # options WITNESS_DDB # options MUTEX_DEBUG # options INVARIANT_SUPPORT # options INVARIANTS and now performance is very good, event with: kern.random.sys.harvest_ethernet: 1 kern.random.sys.harvest_point_to_point: 0 kern.random.sys.harvest_interrupt: 1 Later tonight (my locale) I saw a few other commits to ithreads and such, exp. your commit which should fix my issue with pccard (thanks a lot for that!), so later a will update again and start building kernels adding back the debugging options one at a time. I'll post the result. Bye, Andrea -- Actually, Microsoft is sort of a mixture between the Borg and the Ferengi. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: A possible bug in the interrupt thread preemption code [Was:
John Baldwin wrote: On 22-Feb-01 Maxim Sobolev wrote: Dag-Erling Smorgrav wrote: Maxim Sobolev [EMAIL PROTECTED] writes: It's not an ata specific problem, but rather a problem of all ISA devices (I have an ISA based ata controller). I don't think it has anything to do with ISA. I've had similar problems on a PCI-only system (actually, PCI+EISA motherboard with no EISA cards) with no ATA devices (disks, CD-ROM and streamer are all SCSI). Considering that backing out rev 1.14 of ithread.c eliminates the panics, and that that revision is supposed to enable interrupt thread preemption, and that the crashed kernels show signs of stack smashing, I'd say the cause is probably a bug in the preemption code. Update: the bug is still here, as of -current from 22 Feb. Hovewer, this time it even doesn't let to boot into single-user with following panic message: kernel trap 12 with interrupts disabled panic: mutex sched lock recursed at ../../kern/kern_synch.c:872 E. That would be something that is leaking sched_lock. Hmm... Got a backtrace? What is really annoying is that preemption has been in the kernel since Feb 1. I just accidentally turned it off in the ithread code reorganization and then turned it back on. It was off for a few hours after only being on for 2 weeks, and now everyone magically has problems. Here it is (from DDB): panic(c027de93,c0297409,c027f878,368,80286) _mtx_assert(c02ea000,9,c027f878,368,80286) mi_switch(c32c5da0,3,c02cea44,c357be98) ithread_schedule(c0747c00,1) sched_ithd(e) Xresume14() --- interrupt, eip = 0xc025b60f, esp = 0x80296, ebp = 0xc357bf08 --- trap(18, 10, 10,c01597b6,20) calltrap() --- trap 0x9, eip = 0xc025a5de, esp = 0xc357bf50, ebp = 0xc357bf64 --- sw1b(c0146cbc,c0146cbc,c32c5da0,c357bf94) ithread_loop(c0747c00,c357bfa8) fork_exit(c0146cbc,c0747c00,c357bfa8) fork_trampoline() -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: A possible bug in the interrupt thread preemption code [Was:
On 22-Feb-01 Maxim Sobolev wrote: John Baldwin wrote: On 22-Feb-01 Maxim Sobolev wrote: Dag-Erling Smorgrav wrote: Maxim Sobolev [EMAIL PROTECTED] writes: It's not an ata specific problem, but rather a problem of all ISA devices (I have an ISA based ata controller). I don't think it has anything to do with ISA. I've had similar problems on a PCI-only system (actually, PCI+EISA motherboard with no EISA cards) with no ATA devices (disks, CD-ROM and streamer are all SCSI). Considering that backing out rev 1.14 of ithread.c eliminates the panics, and that that revision is supposed to enable interrupt thread preemption, and that the crashed kernels show signs of stack smashing, I'd say the cause is probably a bug in the preemption code. Update: the bug is still here, as of -current from 22 Feb. Hovewer, this time it even doesn't let to boot into single-user with following panic message: kernel trap 12 with interrupts disabled panic: mutex sched lock recursed at ../../kern/kern_synch.c:872 E. That would be something that is leaking sched_lock. Hmm... Got a backtrace? What is really annoying is that preemption has been in the kernel since Feb 1. I just accidentally turned it off in the ithread code reorganization and then turned it back on. It was off for a few hours after only being on for 2 weeks, and now everyone magically has problems. Here it is (from DDB): panic(c027de93,c0297409,c027f878,368,80286) _mtx_assert(c02ea000,9,c027f878,368,80286) mi_switch(c32c5da0,3,c02cea44,c357be98) ithread_schedule(c0747c00,1) sched_ithd(e) Xresume14() --- interrupt, eip = 0xc025b60f, esp = 0x80296, ebp = 0xc357bf08 --- trap(18, 10, 10,c01597b6,20) calltrap() --- trap 0x9, eip = 0xc025a5de, esp = 0xc357bf50, ebp = 0xc357bf64 --- sw1b(c0146cbc,c0146cbc,c32c5da0,c357bf94) ithread_loop(c0747c00,c357bfa8) fork_exit(c0146cbc,c0747c00,c357bfa8) fork_trampoline() *sigh* This is why enabling interrupts in trap() is such a bad idea. If we get a trap in the scheduler, then lots of bad crap starts to happen because we can get an interrupt while we are in a trap. :( Can you compile your kernel with INVARIANTS on though, as I think the kernel should've panic'd earlier if it is doing what I think it is doing. Also, if you are feeling industrious, edit sys/i386/i386/trap.c and comment out the enable_intr() call near the beginning of the trap() function right after the printf for 'kernel trap %d with interrupts disabled'. -Maxim -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: A possible bug in the interrupt thread preemption code [Was:
On 22-Feb-01 Dag-Erling Smorgrav wrote: John Baldwin [EMAIL PROTECTED] writes: On 22-Feb-01 Maxim Sobolev wrote: Dag-Erling Smorgrav wrote: Maxim Sobolev [EMAIL PROTECTED] writes: It's not an ata specific problem, but rather a problem of all ISA devices (I have an ISA based ata controller). I don't think it has anything to do with ISA. I've had similar problems on a PCI-only system (actually, PCI+EISA motherboard with no EISA cards) with no ATA devices (disks, CD-ROM and streamer are all SCSI). Considering that backing out rev 1.14 of ithread.c eliminates the panics, and that that revision is supposed to enable interrupt thread preemption, and that the crashed kernels show signs of stack smashing, I'd say the cause is probably a bug in the preemption code. Update: the bug is still here, as of -current from 22 Feb. Hovewer, this time it even doesn't let to boot into single-user with following panic message: kernel trap 12 with interrupts disabled panic: mutex sched lock recursed at ../../kern/kern_synch.c:872 E. That would be something that is leaking sched_lock. Hmm... I have another sched_lock-related problem which showed up over the weekend. Starting StarOffice 5.2 invariably triggers the following panic: root@aes /var/crash# gdb -k sGNU 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) source ~des/kgdb (kgdb) kernel 0 IdlePTD 3526656 initial pcb at 2cb980 panicstr: from debugger panic messages: --- panic: mutex sched lock not owned at ../../posix4/ksched.c:215 Easy enough. It seems I missed adding sched_lock around a need_resched(). I'll fix in a second.. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: A possible bug in the interrupt thread preemption code [Was:
On 22-Feb-01 Maxim Sobolev wrote: Here it is (from DDB): panic(c027de93,c0297409,c027f878,368,80286) _mtx_assert(c02ea000,9,c027f878,368,80286) mi_switch(c32c5da0,3,c02cea44,c357be98) ithread_schedule(c0747c00,1) sched_ithd(e) Xresume14() --- interrupt, eip = 0xc025b60f, esp = 0x80296, ebp = 0xc357bf08 --- trap(18, 10, 10,c01597b6,20) calltrap() --- trap 0x9, eip = 0xc025a5de, esp = 0xc357bf50, ebp = 0xc357bf64 --- sw1b(c0146cbc,c0146cbc,c32c5da0,c357bf94) ithread_loop(c0747c00,c357bfa8) fork_exit(c0146cbc,c0747c00,c357bfa8) fork_trampoline() *sigh* This is why enabling interrupts in trap() is such a bad idea. If we get a trap in the scheduler, then lots of bad crap starts to happen because we can get an interrupt while we are in a trap. :( Can you compile your kernel with INVARIANTS on though, as I think the kernel should've panic'd earlier if it is doing what I think it is doing. It's already have INVARIANTS, MUTEX_DEBUG, WITNESS and WITNESS_DDB. Hmm, ouch, you do'nt want MUTEX_DEBUG, that'll slow your system to a crawl. Also, if you are feeling industrious, edit sys/i386/i386/trap.c and comment out the enable_intr() call near the beginning of the trap() function right after the printf for 'kernel trap %d with interrupts disabled'. Ok, I'll try so. -Maxim It will still panic, just hopefully a better panic. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: A possible bug in the interrupt thread preemption code [Was:
John Baldwin [EMAIL PROTECTED] writes: On 22-Feb-01 Maxim Sobolev wrote: It's already have INVARIANTS, MUTEX_DEBUG, WITNESS and WITNESS_DDB. Hmm, ouch, you do'nt want MUTEX_DEBUG, that'll slow your system to a crawl. For the same reason, you probably want WITNESS_SKIPSPIN. WITNESS_DDB is a bad idea, BTW, there's a (presumably harmless) lock order reversal in the FS code that you're practically guaranteed to to hit during boot. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kernel Compilation
Hi, I couldn't solve a problem regarding to kernel compilation. After I edit MYKERNEL and do the /usr/sbin/config, i do the make depend. It gives this error: ../../dev/xe/if_xe.c:138: card_if.h: No such file or directory. It seems that i lack that header file. Where can I find that header file, or is my problem a different one? Thanks in advance... __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: A possible bug in the interrupt thread preemption code [Was:
On 22-Feb-01 Dag-Erling Smorgrav wrote: John Baldwin [EMAIL PROTECTED] writes: On 22-Feb-01 Maxim Sobolev wrote: It's already have INVARIANTS, MUTEX_DEBUG, WITNESS and WITNESS_DDB. Hmm, ouch, you do'nt want MUTEX_DEBUG, that'll slow your system to a crawl. For the same reason, you probably want WITNESS_SKIPSPIN. Not really. WITNESS doesn't really bog down spin mutexes all that much. It has a very simple order checking that is nothing like the order checking for sleep mutexes. The killer for MUTEX_DEBUG is that each mtx_init() involves walking a linked list of _all_ of the mutexes in the system and checking each one with the one beign init'd to check for a duplicate init. WITNESS_DDB is a bad idea, BTW, there's a (presumably harmless) lock order reversal in the FS code that you're practically guaranteed to to hit during boot. Well, they aren't necessarily harmless, but they've been around for a very long time, so if they do cause rare lockups, they are rare at least. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Compilation
On Thu, Feb 22, 2001 at 06:31:58AM -0800, chris hopkins wrote: Hi, I couldn't solve a problem regarding to kernel compilation. After I edit MYKERNEL and do the /usr/sbin/config, i do the make depend. It gives this error: ../../dev/xe/if_xe.c:138: card_if.h: No such file or directory. It seems that i lack that header file. Where can I find that header file, or is my problem a different one? Thanks in advance... in order to compile support for the xe driver, you need to have the pccard devices in your kernel, which will cause card_if.h to be generated. -- garrett rooneyUnix was not designed to stop you from [EMAIL PROTECTED] doing stupid things, because that would http://electricjellyfish.net/ stop you from doing clever things. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernfs
"Daniel C. Sobral" [EMAIL PROTECTED] writes: It seems the error for kernfs is activating a couple of other warnings: WARNING: unknown option `KERNFS' removed from /usr/obj/home/src/sys/DCS/opt_dont use.h WARNING: option `FFS' moved from opt_ffs.h to opt_dontuse.h WARNING: unknown option `FFS_ROOT' removed from /usr/obj/home/src/sys/DCS/opt_ff s.h Neither KERNFS nor FFS_ROOT exist any more. The warning about FFS is correct. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: A possible bug in the interrupt thread preemption code [Was:
John Baldwin wrote: On 22-Feb-01 Maxim Sobolev wrote: Here it is (from DDB): panic(c027de93,c0297409,c027f878,368,80286) _mtx_assert(c02ea000,9,c027f878,368,80286) mi_switch(c32c5da0,3,c02cea44,c357be98) ithread_schedule(c0747c00,1) sched_ithd(e) Xresume14() --- interrupt, eip = 0xc025b60f, esp = 0x80296, ebp = 0xc357bf08 --- trap(18, 10, 10,c01597b6,20) calltrap() --- trap 0x9, eip = 0xc025a5de, esp = 0xc357bf50, ebp = 0xc357bf64 --- sw1b(c0146cbc,c0146cbc,c32c5da0,c357bf94) ithread_loop(c0747c00,c357bfa8) fork_exit(c0146cbc,c0747c00,c357bfa8) fork_trampoline() *sigh* This is why enabling interrupts in trap() is such a bad idea. If we get a trap in the scheduler, then lots of bad crap starts to happen because we can get an interrupt while we are in a trap. :( Can you compile your kernel with INVARIANTS on though, as I think the kernel should've panic'd earlier if it is doing what I think it is doing. It's already have INVARIANTS, MUTEX_DEBUG, WITNESS and WITNESS_DDB. Hmm, ouch, you do'nt want MUTEX_DEBUG, that'll slow your system to a crawl. It doesn't really matter, because system can't even boot into single-user due to panic. Also, if you are feeling industrious, edit sys/i386/i386/trap.c and comment out the enable_intr() call near the beginning of the trap() function right after the printf for 'kernel trap %d with interrupts disabled'. Ok, I'll try so. -Maxim It will still panic, just hopefully a better panic. I did understand that, but the panic I see after the change is exactly the same as before. Any other ideas? -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: A possible bug in the interrupt thread preemption code [Was:
On 22-Feb-01 Maxim Sobolev wrote: John Baldwin wrote: On 22-Feb-01 Maxim Sobolev wrote: Here it is (from DDB): panic(c027de93,c0297409,c027f878,368,80286) _mtx_assert(c02ea000,9,c027f878,368,80286) mi_switch(c32c5da0,3,c02cea44,c357be98) ithread_schedule(c0747c00,1) sched_ithd(e) Xresume14() --- interrupt, eip = 0xc025b60f, esp = 0x80296, ebp = 0xc357bf08 --- trap(18, 10, 10,c01597b6,20) calltrap() --- trap 0x9, eip = 0xc025a5de, esp = 0xc357bf50, ebp = 0xc357bf64 --- sw1b(c0146cbc,c0146cbc,c32c5da0,c357bf94) ithread_loop(c0747c00,c357bfa8) fork_exit(c0146cbc,c0747c00,c357bfa8) fork_trampoline() *sigh* This is why enabling interrupts in trap() is such a bad idea. If we get a trap in the scheduler, then lots of bad crap starts to happen because we can get an interrupt while we are in a trap. :( Can you compile your kernel with INVARIANTS on though, as I think the kernel should've panic'd earlier if it is doing what I think it is doing. It's already have INVARIANTS, MUTEX_DEBUG, WITNESS and WITNESS_DDB. Hmm, ouch, you do'nt want MUTEX_DEBUG, that'll slow your system to a crawl. It doesn't really matter, because system can't even boot into single-user due to panic. Also, if you are feeling industrious, edit sys/i386/i386/trap.c and comment out the enable_intr() call near the beginning of the trap() function right after the printf for 'kernel trap %d with interrupts disabled'. Ok, I'll try so. -Maxim It will still panic, just hopefully a better panic. I did understand that, but the panic I see after the change is exactly the same as before. Any other ideas? A recursive sched_lock? Erm, well, stick these options in your kernel config: options KTR options KTR_EXTEND options KTR_COMPILE=KTR_LOCK options KTR_MASK=KTR_MASK Then when it panics, use the 'show ktr' command to list the mutex operations up until that point. Hopefully you can see where it is grabbing sched lock the first time and then not releasing it. Also, hsa the backtrace changed at all? If not, then you may have commented out the wrong enable_intr(). :) -Maxim -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: A possible bug in the interrupt thread preemption code [Was:
John Baldwin wrote: On 22-Feb-01 Maxim Sobolev wrote: John Baldwin wrote: On 22-Feb-01 Maxim Sobolev wrote: Here it is (from DDB): panic(c027de93,c0297409,c027f878,368,80286) _mtx_assert(c02ea000,9,c027f878,368,80286) mi_switch(c32c5da0,3,c02cea44,c357be98) ithread_schedule(c0747c00,1) sched_ithd(e) Xresume14() --- interrupt, eip = 0xc025b60f, esp = 0x80296, ebp = 0xc357bf08 --- trap(18, 10, 10,c01597b6,20) calltrap() --- trap 0x9, eip = 0xc025a5de, esp = 0xc357bf50, ebp = 0xc357bf64 --- sw1b(c0146cbc,c0146cbc,c32c5da0,c357bf94) ithread_loop(c0747c00,c357bfa8) fork_exit(c0146cbc,c0747c00,c357bfa8) fork_trampoline() *sigh* This is why enabling interrupts in trap() is such a bad idea. If we get a trap in the scheduler, then lots of bad crap starts to happen because we can get an interrupt while we are in a trap. :( Can you compile your kernel with INVARIANTS on though, as I think the kernel should've panic'd earlier if it is doing what I think it is doing. It's already have INVARIANTS, MUTEX_DEBUG, WITNESS and WITNESS_DDB. Hmm, ouch, you do'nt want MUTEX_DEBUG, that'll slow your system to a crawl. It doesn't really matter, because system can't even boot into single-user due to panic. Also, if you are feeling industrious, edit sys/i386/i386/trap.c and comment out the enable_intr() call near the beginning of the trap() function right after the printf for 'kernel trap %d with interrupts disabled'. Ok, I'll try so. -Maxim It will still panic, just hopefully a better panic. I did understand that, but the panic I see after the change is exactly the same as before. Any other ideas? A recursive sched_lock? Erm, well, stick these options in your kernel config: options KTR options KTR_EXTEND options KTR_COMPILE=KTR_LOCK options KTR_MASK=KTR_MASK Then when it panics, use the 'show ktr' command to list the mutex operations up until that point. Hopefully you can see where it is grabbing sched lock the first time and then not releasing it. Ok, I'll do it and send results later. Also, hsa the backtrace changed at all? If not, then you may have commented out the wrong enable_intr(). :) Did what you have suggested. Please see attached diff. -Maxim --- src/sys/i386/i386/trap.c2001/02/22 16:20:12 1.1 +++ src/sys/i386/i386/trap.c2001/02/22 16:20:58 @@ -264,7 +264,7 @@ * We should walk p_heldmtx here and see if any are * spin mutexes, and not do this if so. */ - enable_intr(); +/* enable_intr();*/ } }
Re: A possible bug in the interrupt thread preemption code [Was:
John Baldwin wrote: On 22-Feb-01 Maxim Sobolev wrote: John Baldwin wrote: On 22-Feb-01 Maxim Sobolev wrote: Here it is (from DDB): panic(c027de93,c0297409,c027f878,368,80286) _mtx_assert(c02ea000,9,c027f878,368,80286) mi_switch(c32c5da0,3,c02cea44,c357be98) ithread_schedule(c0747c00,1) sched_ithd(e) Xresume14() --- interrupt, eip = 0xc025b60f, esp = 0x80296, ebp = 0xc357bf08 --- trap(18, 10, 10,c01597b6,20) calltrap() --- trap 0x9, eip = 0xc025a5de, esp = 0xc357bf50, ebp = 0xc357bf64 --- sw1b(c0146cbc,c0146cbc,c32c5da0,c357bf94) ithread_loop(c0747c00,c357bfa8) fork_exit(c0146cbc,c0747c00,c357bfa8) fork_trampoline() *sigh* This is why enabling interrupts in trap() is such a bad idea. If we get a trap in the scheduler, then lots of bad crap starts to happen because we can get an interrupt while we are in a trap. :( Can you compile your kernel with INVARIANTS on though, as I think the kernel should've panic'd earlier if it is doing what I think it is doing. It's already have INVARIANTS, MUTEX_DEBUG, WITNESS and WITNESS_DDB. Hmm, ouch, you do'nt want MUTEX_DEBUG, that'll slow your system to a crawl. It doesn't really matter, because system can't even boot into single-user due to panic. Also, if you are feeling industrious, edit sys/i386/i386/trap.c and comment out the enable_intr() call near the beginning of the trap() function right after the printf for 'kernel trap %d with interrupts disabled'. Ok, I'll try so. -Maxim It will still panic, just hopefully a better panic. I did understand that, but the panic I see after the change is exactly the same as before. Any other ideas? A recursive sched_lock? Erm, well, stick these options in your kernel config: options KTR options KTR_EXTEND options KTR_COMPILE=KTR_LOCK options KTR_MASK=KTR_MASK Bah, it even doesn't compile with these options: cc -c -pipe -O -march=pentium -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../dev -I../../../include -I../../contrib/dev/acpica/Subsystem/Include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../kern/kern_ktr.c ../../kern/kern_ktr.c: In function `__Tunable_ktr_mask': ../../kern/kern_ktr.c:95: `KTR_MASK' undeclared (first use in this function) ../../kern/kern_ktr.c:95: (Each undeclared identifier is reported only once ../../kern/kern_ktr.c:95: for each function it appears in.) *** Error code 1 1 error -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: A possible bug in the interrupt thread preemption code [Was:
On 22-Feb-01 Maxim Sobolev wrote: John Baldwin wrote: A recursive sched_lock? Erm, well, stick these options in your kernel config: options KTR options KTR_EXTEND options KTR_COMPILE=KTR_LOCK options KTR_MASK=KTR_MASK Bah, it even doesn't compile with these options: cc -c -pipe -O -march=pentium -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../dev -I../../../include -I../../contrib/dev/acpica/Subsystem/Include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../kern/kern_ktr.c ../../kern/kern_ktr.c: In function `__Tunable_ktr_mask': ../../kern/kern_ktr.c:95: `KTR_MASK' undeclared (first use in this function) ../../kern/kern_ktr.c:95: (Each undeclared identifier is reported only once ../../kern/kern_ktr.c:95: for each function it appears in.) *** Error code 1 1 error Oh, whoops, that should be: options KTR_MASK=KTR_LOCK -Maxim -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: A possible bug in the interrupt thread preemption code [Was:
John Baldwin wrote: On 22-Feb-01 Maxim Sobolev wrote: John Baldwin wrote: On 22-Feb-01 Maxim Sobolev wrote: Here it is (from DDB): panic(c027de93,c0297409,c027f878,368,80286) _mtx_assert(c02ea000,9,c027f878,368,80286) mi_switch(c32c5da0,3,c02cea44,c357be98) ithread_schedule(c0747c00,1) sched_ithd(e) Xresume14() --- interrupt, eip = 0xc025b60f, esp = 0x80296, ebp = 0xc357bf08 --- trap(18, 10, 10,c01597b6,20) calltrap() --- trap 0x9, eip = 0xc025a5de, esp = 0xc357bf50, ebp = 0xc357bf64 --- sw1b(c0146cbc,c0146cbc,c32c5da0,c357bf94) ithread_loop(c0747c00,c357bfa8) fork_exit(c0146cbc,c0747c00,c357bfa8) fork_trampoline() *sigh* This is why enabling interrupts in trap() is such a bad idea. If we get a trap in the scheduler, then lots of bad crap starts to happen because we can get an interrupt while we are in a trap. :( Can you compile your kernel with INVARIANTS on though, as I think the kernel should've panic'd earlier if it is doing what I think it is doing. It's already have INVARIANTS, MUTEX_DEBUG, WITNESS and WITNESS_DDB. Hmm, ouch, you do'nt want MUTEX_DEBUG, that'll slow your system to a crawl. It doesn't really matter, because system can't even boot into single-user due to panic. Also, if you are feeling industrious, edit sys/i386/i386/trap.c and comment out the enable_intr() call near the beginning of the trap() function right after the printf for 'kernel trap %d with interrupts disabled'. Ok, I'll try so. -Maxim It will still panic, just hopefully a better panic. I did understand that, but the panic I see after the change is exactly the same as before. Any other ideas? A recursive sched_lock? Erm, well, stick these options in your kernel config: options KTR options KTR_EXTEND options KTR_COMPILE=KTR_LOCK options KTR_MASK=KTR_MASK Then when it panics, use the 'show ktr' command to list the mutex operations up until that point. Hopefully you can see where it is grabbing sched lock the first time and then not releasing it. Got the following: 724: REL (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:438 723: GOT (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:350 722: REL (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:438 721: GOT (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:350 680: REL (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:438 679: GOT (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:350 569: REL (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:438 568: GOT (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:350 546: REL (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:438 545: GOT (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:350 544: REL (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:438 543: GOT (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:350 515: REL (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:438 366: REL (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:438 365: GOT (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:350 317: REL (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:438 254: REL (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:438 253: GOT (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:350 252: REL (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:438 251: GOT (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:350 194: REL (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:438 193: GOT (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:350 182: REL (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:438 181: GOT (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:350 46: GOT (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:350 1020: REL (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:438 1019: GOT (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:350 -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT slowdown in last 2 weeks
On Tue, Feb 20, 2001 at 01:50:23AM +0100, Andrea Campi wrote: I am noticing a severe slowdown on my -CURRENT system. It actually started after Feb [3-5] changes in intrupt handling, but I didn't really notice until I run a make world (which I delayed doing because of, well you guess, the libc breakage). When I say severe I mean make buildworld takes x3 longer. Do you have MUTEX_DEBUG in your kernel? Kris PGP signature
Re: as segfaulting during world-build
Szilveszter Adam schrieb: On Tue, Feb 20, 2001 at 11:27:17AM -0500, Mikhail Teterin wrote: No, I don't think it is hardware. It died on the same spot for the third time in a row: ... What date is the -CURRENT you are attempting the build on from? There were problems with as failing for a while not long ago. Check your version of src/lib/libc/stdio/findfp.c (the installed one...) to see if it is revision 1.15 or later. If not, you will have to get a working as (and as reported by Martin Blapp, the other binutiles in /usr/bin/ and /usr/libexec/elf too) from somwhere like an ftp snapshot... if this is not the problem, I dunno, I did not have any such problems even though I have just finished a buildworld. I did have the same problem. But just rebuilding binutils didn't help either. Trying to rebuild libc resulted in above SEGV from as. Some sort of Catch 22 I didn't have a working libc.so.5, so I just did the following: % cp /usr/lib/libc.so.4 /tmp/libc.so.5 [Maybe it's in /usr/lib/compat - I even found a libc.so.3 in /usr/lib. Hasn't been reinstalled since Mid 1998] % cd /usr/src/lib/libc; LD_LIBRARY_PATH=/tmp make all install -- Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP Re: cvs commit: src/sys/alpha/alpha trap.c src/sys/dev/acpica/Osd OsdSchedule.c src/sys/i386/i386 genassym.c swtch.s trap.c src/sys/ia64/ia64 trap.c src/sys/kern init_main.c kern_condvar.c kern_idle.c kern_intr.c kern_mib.c kern_mutex.c kern_proc.c ...
Jake Burkholder schrieb: [...] As I mentioned in the commit message, this changes the size and layout of struct kinfo_proc, so you'll have to recompile libkvm-using programs. As always, make world is your friend. You may have forgotten to also change KINFO_PROC_SIZE in src/sys/user.h I'm now getting bootup warning all the time: ... real memory = 197066752 (192448K bytes) avail memory = 187293696 (182904K bytes) Preloaded elf kernel "kernel" at 0xc045. WARNING: size of kinfo_proc (648) should be 644!!! Pentium Pro MTRR support enabled ... BTW What is the purpose of KINFO_PROC_SIZE? Why not simply using sizeof()? -- Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Release b0rked..
=== lib/libgssapi rm -f .depend mkdep -f .depend -a -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/krb5 -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/asn1 -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/roken -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/des -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/include -I/usr/obj/usr/src/kerberos5/lib/libgssapi/../../lib/libasn1 -I/usr/src/kerberos5/lib/libgssapi/../../include -I/usr/src/kerberos5/lib/libgssapi/../../include -DHAVE_CONFIG_H -DINET6 /usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi/8003.c ... In file included from /usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/krb5/krb5_locl.h:14 2, from /usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi/gssapi_locl. h:39, from /usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi/8003.c:34: /usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/krb5/krb5.h:43: krb5_err.h: No such file or directory /usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/krb5/krb5.h:44: heim_err.h: No such file or directory In file included from /usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi/gssapi_locl. h:39, from /usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi/8003.c:34: /usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/krb5/krb5_locl.h:14 3: krb5_err.h: No such file or directory ... (repeat about 50 times) mkdep: compile failed *** Error code 1 Stop in /usr/src/kerberos5/lib/libgssapi. *** Error code 1 Stop in /usr/src/kerberos5/lib. *** Error code 1 Stop in /usr/src/kerberos5. *** Error code 1 Stop in /usr/src/release. *** Error code 1 Stop in /usr/src/release. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
dirty buffers on reboot again?
guring syscons:. Additional ABI support:. Starting local daemons:. Local package initialization: Networker Samba. Additional TCP options:. Thu Feb 22 11:38:43 PST 2001 FreeBSD/i386 (quarm.feral.com) (ttyd0) login: (da0:ahc0:0:0:0): tagged openings now 16 Feb 22 15:17:31 quarm rebootWaiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks... 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 giving up on 3 buffers Uptime: 3h44m4s I'm seeing a lot of this again. Anyone else? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: System hangs with -current ...
Okay, I have to pick up a NULL modem cable tomorrow and dive into this ...
finally ...
The various KTR_ that you mention below, these are kernel settings that I
compile into the kernel?
On Tue, 2 Jan 2001, John Baldwin wrote:
On 02-Jan-01 The Hermit Hacker wrote:
Over the past several months, as others have reported, I've been getting
system hangs using 5.0-CURRENT w/ SMP ... I've got DDB enabled, but
ctl-alt-esc doesn't break me to the debugger ...
I'm not complaining about the hangs, if I was overly concerned, I'd run
-STABLE, but I'm wondering how one goes about providing debug information
on them other then through DDB?
Not easily. :( If you can make the problem easily repeatable, then you can try
turning on KTR in your kernel (see NOTES, you will need KTR_EXTEND), setting up
a serial console that you log the output of, create a shell script that runs
the following commands:
#!/bin/sh
# Turn on KTR_INTR, KTR_PROC, and KTR_LOCK
sysctl -w debug.ktr_mask=0x1208
sysctl -w debug.ktr_verbose=2
run_magic_command_that_hangs_my_machine
and run the script. You probably want to run it over a tty or remote login so
tthat the serial console output is just the logging (warning, it will be very
verbose!). Also, you probably want to use
http://www.FreeBSD.org/~jhb/patches/mtx_quiet.patch to shut up most of the
irrelevant and cluttery mutex trace messages. Note that having this much
logging on will probably slow the machine to a crawl as well, so you may have
to just start this up and go off and do something else until it hangs. :-/
Another alternative is to rig up a NMI debouncer and use it to break into the
debugger. Then you can start poking around to see who owns sched_lock, etc.
Thanks ...
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: dirty buffers on reboot again?
On Thu, 22 Feb 2001 15:20:10 -0800 (PST), Matthew Jacob [EMAIL PROTECTED] said: syncing disks... 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 giving up on 3 buffers I'm seeing a lot of this again. Anyone else? Yup. -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA [EMAIL PROTECTED] [EMAIL PROTECTED] Where ignorance is our master, there is no possibility of real peace. -- the Dalai Lama To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
How could I do with my sound card?
Hello, My question is: My sound card is CS423X, FreeBSD supports it. It says: pcm1: CS423x at port 0x534-0x537,0x388-0x38b,0x220-0x22f irq 5 drq 1,0 on isa0 . But my system is FreeBSD-current, the /dev file system I can't write, can't use sh MAKEDEV snd0, and all software to look for /dev/mixer0 .. So how could to now? my dmesg: Copyright (c) 1992-2001 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-CURRENT #0: Wed Feb 21 19:57:08 GMT 2001 [EMAIL PROTECTED]:/usr/home/src-cur/sys/compile/bigbear Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 300685261 Hz CPU: AMD-K6tm w/ multimedia extensions (300.69-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x570 Stepping = 0 Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX AMD Features=0x400b10 real memory = 67108864 (65536K bytes) avail memory = 61530112 (60088K bytes) Preloaded elf kernel "kernel" at 0xc03b5000. seq0-15: Midi sequencers. Using $PIR table, 4 entries at 0xc00fdc10 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C586 ATA33 controller port 0xe000-0xe00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: serial bus, USB at 7.2 (no driver attached) pci0: old, non-VGA display device at 7.3 (no driver attached) ed0: NE2000 PCI Ethernet (RealTek 8029) port 0xe800-0xe81f irq 10 at device 10.0 on pci0 ed0: address 00:e0:4c:dd:a0:ec, type NE2000 (16 bit) pci0: display, VGA at 12.0 (no driver attached) atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 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 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0303 can't assign resources unknown: PNP0f13 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0700 can't assign resources unknown: PNP0401 can't assign resources unknown: PNP0501 can't assign resources pcm1: CS423x at port 0x534-0x537,0x388-0x38b,0x220-0x22f irq 5 drq 1,0 on isa0 ad0: 4112MB WDC AC14300R [8912/15/63] at ata0-master UDMA33 ad1: 2014MB QUANTUM FIREBALL ST2.1A [4092/16/63] at ata0-slave UDMA33 acd0: CDROM LTN341 at ata1-master using PIO4 Mounting root from ufs:/dev/ad0s1a cd9660: RockRidge Extension my dev: acd0a dsp1.0 ppi0sequencer9 ttyv5 acd0c dsp1.1 psm0sndstat ttyv6 ad0 dspW1.0 random stderr ttyv7 ad0s1a dspW1.1 sequencer0 stdin ttyv8 ad0s1b fd sequencer1 stdout ttyv9 ad0s1e fd0 sequencer10 sysmousettyva ad1 io sequencer11 tty ttyvb audio1.0kbd0sequencer12 ttyd0 ttyvc audio1.1klogsequencer13 ttyd1 ttyvd bpsm0 kmemsequencer14 ttyid0 ttyve console log sequencer15 ttyid1 ttyvf consolectl lpt0sequencer2 ttyld0 urandom cuaa0 lpt0.ctlsequencer3 ttyld1 vga cuaa1 mdctl sequencer4 ttyv0 zero cuaia0 mem sequencer5 ttyv1 cuaia1 mixer1 sequencer6 ttyv2 cuala0 nullsequencer7 ttyv3 cuala1 pci sequencer8 ttyv4 my df: Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/ad0s1a22820798219 11173247%/ devfs 110 100% /dev/ /dev/ad0s1e 3460132 1892196 129112659%/usr procfs 440 100% /proc /dev/acd0a 659010 6590100 100% /cdrom __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices!
RE: How could I do with my sound card?
On 23-Feb-01 Liu Siwei wrote: Hello, My question is: My sound card is CS423X, FreeBSD supports it. It says: pcm1: CS423x at port 0x534-0x537,0x388-0x38b,0x220-0x22f irq 5 drq 1,0 on isa0 . But my system is FreeBSD-current, the /dev file system I can't write, can't use sh MAKEDEV snd0, and all software to look for /dev/mixer0 .. So how could to now? try MAKEDEV snd1 I'm fairly sure there is a FAQ or handbook entry on this. --- 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How could I do with my sound card?
On Thu, Feb 22, 2001 at 04:31:30PM -0800, Liu Siwei wrote: Hello, My question is: My sound card is CS423X, FreeBSD supports it. It says: pcm1: CS423x at port 0x534-0x537,0x388-0x38b,0x220-0x22f irq 5 drq 1,0 on isa0 . But my system is FreeBSD-current, the /dev file system I can't write, can't use sh MAKEDEV snd0, and all software to look for /dev/mixer0 .. Are you trying to run MAKEDEV as root? So how could to now? -- Brian 'you Bastard' Reichert[EMAIL PROTECTED] 37 Crystal Ave. #303Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How could I do with my sound card?
says: pcm1: CS423x at port 0x534-0x537,0x388-0x38b,0x220-0x22f irq 5 drq 1,0 on isa0 you have a bogus device pcm0. you probably have a mistake in your hints file. -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: System hangs with -current ...
On 22-Feb-01 The Hermit Hacker wrote:
Okay, I have to pick up a NULL modem cable tomorrow and dive into this ...
finally ...
The various KTR_ that you mention below, these are kernel settings that I
compile into the kernel?
Yes. You want this:
options KTR
options KTR_EXTEND
options KTR_COMPILE=0x1208
The mtx_quiet.patch is old and won't apply to current now I'm afraid.
On Tue, 2 Jan 2001, John Baldwin wrote:
On 02-Jan-01 The Hermit Hacker wrote:
Over the past several months, as others have reported, I've been getting
system hangs using 5.0-CURRENT w/ SMP ... I've got DDB enabled, but
ctl-alt-esc doesn't break me to the debugger ...
I'm not complaining about the hangs, if I was overly concerned, I'd run
-STABLE, but I'm wondering how one goes about providing debug information
on them other then through DDB?
Not easily. :( If you can make the problem easily repeatable, then you can
try
turning on KTR in your kernel (see NOTES, you will need KTR_EXTEND), setting
up
a serial console that you log the output of, create a shell script that runs
the following commands:
#!/bin/sh
# Turn on KTR_INTR, KTR_PROC, and KTR_LOCK
sysctl -w debug.ktr_mask=0x1208
sysctl -w debug.ktr_verbose=2
run_magic_command_that_hangs_my_machine
and run the script. You probably want to run it over a tty or remote login
so
tthat the serial console output is just the logging (warning, it will be
very
verbose!). Also, you probably want to use
http://www.FreeBSD.org/~jhb/patches/mtx_quiet.patch to shut up most of the
irrelevant and cluttery mutex trace messages. Note that having this much
logging on will probably slow the machine to a crawl as well, so you may
have
to just start this up and go off and do something else until it hangs. :-/
Another alternative is to rig up a NMI debouncer and use it to break into
the
debugger. Then you can start poking around to see who owns sched_lock, etc.
Thanks ...
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Marc G. Fournier ICQ#7615664 IRC Nick:
Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary:
scrappy@{freebsd|postgresql}.org
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: System hangs with -current ...
On Thu, 22 Feb 2001, John Baldwin wrote:
On 22-Feb-01 The Hermit Hacker wrote:
Okay, I have to pick up a NULL modem cable tomorrow and dive into this ...
finally ...
The various KTR_ that you mention below, these are kernel settings that I
compile into the kernel?
Yes. You want this:
options KTR
options KTR_EXTEND
options KTR_COMPILE=0x1208
okay, just so that I understand ... I compile my kernel with these
options, and then run the two sysctl commands you list below? the
KTR_COMPILE arg looks similar to the ktr_mask one below, which is why I'm
confirming ...
The mtx_quiet.patch is old and won't apply to current now I'm afraid.
On Tue, 2 Jan 2001, John Baldwin wrote:
On 02-Jan-01 The Hermit Hacker wrote:
Over the past several months, as others have reported, I've been getting
system hangs using 5.0-CURRENT w/ SMP ... I've got DDB enabled, but
ctl-alt-esc doesn't break me to the debugger ...
I'm not complaining about the hangs, if I was overly concerned, I'd run
-STABLE, but I'm wondering how one goes about providing debug information
on them other then through DDB?
Not easily. :( If you can make the problem easily repeatable, then you can
try
turning on KTR in your kernel (see NOTES, you will need KTR_EXTEND), setting
up
a serial console that you log the output of, create a shell script that runs
the following commands:
#!/bin/sh
# Turn on KTR_INTR, KTR_PROC, and KTR_LOCK
sysctl -w debug.ktr_mask=0x1208
sysctl -w debug.ktr_verbose=2
run_magic_command_that_hangs_my_machine
and run the script. You probably want to run it over a tty or remote login
so
tthat the serial console output is just the logging (warning, it will be
very
verbose!). Also, you probably want to use
http://www.FreeBSD.org/~jhb/patches/mtx_quiet.patch to shut up most of the
irrelevant and cluttery mutex trace messages. Note that having this much
logging on will probably slow the machine to a crawl as well, so you may
have
to just start this up and go off and do something else until it hangs. :-/
Another alternative is to rig up a NMI debouncer and use it to break into
the
debugger. Then you can start poking around to see who owns sched_lock, etc.
Thanks ...
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Marc G. Fournier ICQ#7615664 IRC Nick:
Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary:
scrappy@{freebsd|postgresql}.org
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Release b0rked..
=== lib/libgssapi
rm -f .depend
mkdep -f .depend -a
...
/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/krb5/krb5.h:43:
krb5_err.h: No such file or directory
/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/krb5/krb5.h:44:
heim_err.h: No such file or directory
You can get past this error with this patch, but it will just die a little
later in another part of kerberos. You should have better luck by building
a release with NOKERBEROS=YES. I was able to build one yesterday.
John
--
John Hay -- [EMAIL PROTECTED]
Index: kerberos5/lib/libgssapi/Makefile
===
RCS file: /home/ncvs/src/kerberos5/lib/libgssapi/Makefile,v
retrieving revision 1.1
diff -u -r1.1 Makefile
--- kerberos5/lib/libgssapi/Makefile2001/02/13 16:56:50 1.1
+++ kerberos5/lib/libgssapi/Makefile2001/02/17 15:13:38
@@ -7,7 +7,8 @@
-I${KRB5DIR}/lib/roken \
-I${KRB5DIR}/lib/des\
-I${KRB5DIR}/include\
- -I${ASN1OBJDIR}
+ -I${ASN1OBJDIR} \
+ -I${KRB5OBJDIR}
SRCS= \
8003.c \
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: System hangs with -current ...
On 23-Feb-01 The Hermit Hacker wrote: On Thu, 22 Feb 2001, John Baldwin wrote: On 22-Feb-01 The Hermit Hacker wrote: Okay, I have to pick up a NULL modem cable tomorrow and dive into this ... finally ... The various KTR_ that you mention below, these are kernel settings that I compile into the kernel? Yes. You want this: options KTR options KTR_EXTEND options KTR_COMPILE=0x1208 okay, just so that I understand ... I compile my kernel with these options, and then run the two sysctl commands you list below? the KTR_COMPILE arg looks similar to the ktr_mask one below, which is why I'm confirming ... Yes. KTR_COMPILE controls what KTR tracepoints are actually compiled into the kernel. The ktr_mask sysctl controls a runtime mask that lets you choose which of the compiled in masks you want to enable. I have manpages for this stuff, but they are waiting for doc guys to review them. The mtx_quiet.patch is old and won't apply to current now I'm afraid. On Tue, 2 Jan 2001, John Baldwin wrote: On 02-Jan-01 The Hermit Hacker wrote: Over the past several months, as others have reported, I've been getting system hangs using 5.0-CURRENT w/ SMP ... I've got DDB enabled, but ctl-alt-esc doesn't break me to the debugger ... I'm not complaining about the hangs, if I was overly concerned, I'd run -STABLE, but I'm wondering how one goes about providing debug information on them other then through DDB? Not easily. :( If you can make the problem easily repeatable, then you can try turning on KTR in your kernel (see NOTES, you will need KTR_EXTEND), setting up a serial console that you log the output of, create a shell script that runs the following commands: #!/bin/sh # Turn on KTR_INTR, KTR_PROC, and KTR_LOCK sysctl -w debug.ktr_mask=0x1208 sysctl -w debug.ktr_verbose=2 run_magic_command_that_hangs_my_machine and run the script. You probably want to run it over a tty or remote login so tthat the serial console output is just the logging (warning, it will be very verbose!). Also, you probably want to use http://www.FreeBSD.org/~jhb/patches/mtx_quiet.patch to shut up most of the irrelevant and cluttery mutex trace messages. Note that having this much logging on will probably slow the machine to a crawl as well, so you may have to just start this up and go off and do something else until it hangs. :-/ Another alternative is to rig up a NMI debouncer and use it to break into the debugger. Then you can start poking around to see who owns sched_lock, etc. Thanks ... -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
USER_LDT gone?
With the great libc debacle of 2001, I have not tried
to update my system for about 2 weeks. In that time I
may have missed the commit message that said that USER_LDT, which was needed
for at least wine, was removed.
root[221] cd /usr/src/
root[222] setenv KERNCONF `hostname -s`
root[223] make buildkernel
--
Kernel build for C456086-A started on Thu Feb 22 21:28:18 GMT 2001
--
=== C456086-A
mkdir -p /usr/obj/usr/src/sys
cd /usr/src/sys/i386/conf;
PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin
config -d /usr/obj/usr/src/sys/C456086-A C456086-A
C456086-A: unknown option "USER_LDT"
*** Error code 1
root[224 find /sys/ -type f | xargs grep USER_LDT
/sys/i386/conf/C456086-A:optionsUSER_LDT#allow user-level
control of i386 ldt
/sys/i386/i386/swtch.s.orig:#ifdef USER_LDT
/sys/i386/linux/linux_machdep.c:printf("linux: modify_ldt needs kernel
option USER_LDT\n");
/sys/i386/svr4/svr4_machdep.c:#if 0 /* USER_LDT */
/sys/i386/svr4/svr4_machdep.c:#if 0 /* USER_LDT */
/sys/i386/svr4/svr4_machdep.c:#warning "USER_LDT doesn't work - are you sure you want
this?"
/sys/modules/svr4/TO-DO: * VM86 and USER_LDT are currently disabled (low-priority)
So, is USER_LDT no longer needed, and will wine work?
--
steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: USER_LDT gone?
On Thu, Feb 22, 2001 at 09:34:12PM +, Steven G. Kargl wrote: With the great libc debacle of 2001, I have not tried to update my system for about 2 weeks. In that time I may have missed the commit message that said that USER_LDT, which was needed for at least wine, was removed. according to the commit message i saw, it is now turned on by default, so the next gen pthreads libs can use it. -- garrett rooneyUnix was not designed to stop you from [EMAIL PROTECTED] doing stupid things, because that would http://electricjellyfish.net/ stop you from doing clever things. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USER_LDT gone?
* Steven G. Kargl [EMAIL PROTECTED] [010222 21:35] wrote: With the great libc debacle of 2001, I have not tried to update my system for about 2 weeks. In that time I may have missed the commit message that said that USER_LDT, which was needed for at least wine, was removed. Why are you using -current and not reading commit messages? :P Peter Wemm made it the default and it's no longer optional. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USER_LDT gone?
Alfred Perlstein wrote: * Steven G. Kargl [EMAIL PROTECTED] [010222 21:35] wrote: With the great libc debacle of 2001, I have not tried to update my system for about 2 weeks. In that time I may have missed the commit message that said that USER_LDT, which was needed for at least wine, was removed. Why are you using -current and not reading commit messages? :P Peter Wemm made it the default and it's no longer optional. I do read the commit messages, but I don't remember one about USER_LDT. A search of the mailing list archive at www.freebsd.org didn't turn up an obvious commit. PS: I've been running current longer than you have been involved in the project. Yes, I had 386BSD 0.0 floppy disk until I tossed them because the floppy were damaged. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USER_LDT gone?
Will Andrews wrote: On Thu, Feb 22, 2001 at 09:46:24PM -0800, Steve Kargl wrote: I do read the commit messages, but I don't remember one about USER_LDT. A search of the mailing list archive at www.freebsd.org didn't turn up an obvious commit. It was committed less than 2 hours ago. Actually, 4 hours :-) I won't see this commit message until tomorrow. Revision 1.146 / (download) - annotate - [select for diffs], Fri Feb 23 01:24:59 2001 UTC (4 hours, 24 minutes ago) by peter Branch: MAIN CVS Tags: HEAD Changes since 1.145: +1 -2 lines Diff to previous 1.145 (colored) Activate USER_LDT by default. The new thread libraries are going to depend on this. The linux ABI emulator tries to use it for some linux binaries too. VM86 had a bigger cost than this and it was made default a while ago. Reviewed by:jhb, imp -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
known problem with certain programs freezing in state poll?
Just wondering if the following is a known problem, or if I can provide any more useful info? After updating from a pre-Feb 10 current, i'm now seeing Licq freezing on exit, with top showing it to be in state "poll". (and has to be kill'ed to exit it) Xmms is worse, after playing an mp3 for a short while, FreeBSD freezes solid, (no panic) top running in another window shows it to be in state "poll" when this happens. Cheers Kelvin. [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
unsubscribe
unsubscribe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
How is -CURRENT?
Hi folks... Now I am running 20010210-CURRENT. I was wondering, how is the state of -CURRENT? I've checked current.freebsd.org, but there are no newer snapshots than 20010210. Is it safe to make world right now? Do KDE2 apps work flawlessly on newest -CURRENT? If there are people that can say yes to that answer, than I am ready to blow away all my /usr/X11R6 and /usr/local and build everything from scratch, thank you... /john To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USER_LDT gone?
* Steve Kargl [EMAIL PROTECTED] [010222 21:46] wrote: Alfred Perlstein wrote: * Steven G. Kargl [EMAIL PROTECTED] [010222 21:35] wrote: With the great libc debacle of 2001, I have not tried to update my system for about 2 weeks. In that time I may have missed the commit message that said that USER_LDT, which was needed for at least wine, was removed. Why are you using -current and not reading commit messages? :P Peter Wemm made it the default and it's no longer optional. I do read the commit messages, but I don't remember one about USER_LDT. A search of the mailing list archive at www.freebsd.org didn't turn up an obvious commit. PS: I've been running current longer than you have been involved in the project. Yes, I had 386BSD 0.0 floppy disk until I tossed them because the floppy were damaged. Hence the ":P". :) -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
