make installkernel fails
Hi I cvsupped my sources yesterday. # make bulidworld # make buildkernel were o.k. , # make installkernel stopped with cd /usr/obj/usr/src/sys/PUKRUPPA-5.5; MAKEOBJDIRPREFIX=/usr/obj COMPILER_PATH=/usr/obj/usr/src/i386/usr/libexec:/usr/obj/usr/src/i386/usr/bin LIBRARY_PATH=/usr/obj/usr/src/i386/usr/lib:/usr/obj/usr/src/i386/usr/lib OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec CFLAGS="-nostdinc -O -pipe " PERL5LIB=/usr/obj/usr/src/i386/usr/libdata/perl/5.6.0 GROFF_BIN_PATH=/usr/obj/usr/src/i386/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/i386/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386/usr/share/tmac MACHINE=i386 make KERNEL=kernel install *** Error code 2 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Regards. Uli. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
gen_lex_hash in mysql-server-3.23.39 build hangs forever under -current
I don't know if this belongs here, in the database list, or in the ports list... Under -current from early Sunday morning [CDT], a build of mysql-server-3.23.39 hangs forever at: --- ===> Building for mysql-server-3.23.39 . . [snip] . ./gen_lex_hash > lex_hash.h --- It was there since about the time I went to bed, and it's still there now. I'll try to `make clean ; make`, just to be sure that something wierd didn't happen. Is this a -current issue, or should I post this problem in one of the other lists? jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
USB Microtech CameraMate CF/CF+/CF+II/Microdrive/SmartMedia reader
I did an archive search of this list, and found a post from April from a guy who had some diffs to scsi_da.c and the umass driver to get this thing working. I sent him an email on Friday, but haven't heard back yet. He said he had it working under -current. Does anyone have a copy of these diffs? Also, I may be a little behind the times, as this is my first USB device to play with, so some tips on how to get it working with the drivers once patched would help too... jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gen_lex_hash in mysql-server-3.23.39 build hangs forever under -current
I forgot to add: I am using the make option: `make WITH_LINUXTHREADS=yes` Jim Bryant wrote: > > I don't know if this belongs here, in the database list, or in the ports list... > > Under -current from early Sunday morning [CDT], a build of mysql-server-3.23.39 >hangs forever at: > > --- > ===> Building for mysql-server-3.23.39 > . > . [snip] > . > ./gen_lex_hash > lex_hash.h > --- > > It was there since about the time I went to bed, and it's still there now. > > I'll try to `make clean ; make`, just to be sure that something wierd didn't happen. > > Is this a -current issue, or should I post this problem in one of the other lists? jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gen_lex_hash in mysql-server-3.23.39 build hangs forever under -current
Okay, I just built it successfully without "WITH_LINUXTHREADS=yes". I also noticed that my linuxthreads lib was linuxthreads-2.1.2, and I'm rebuilding it with the linuxthreads-2.2.3_1 sources. Afterwards, I'll try the compile again. Jim Bryant wrote: > > I forgot to add: > > I am using the make option: `make WITH_LINUXTHREADS=yes` > > Jim Bryant wrote: > > > > I don't know if this belongs here, in the database list, or in the ports list... > > > > Under -current from early Sunday morning [CDT], a build of mysql-server-3.23.39 >hangs forever at: > > > > --- > > ===> Building for mysql-server-3.23.39 > > . > > . [snip] > > . > > ./gen_lex_hash > lex_hash.h > > --- > > > > It was there since about the time I went to bed, and it's still there now. > > > > I'll try to `make clean ; make`, just to be sure that something wierd didn't >happen. > > > > Is this a -current issue, or should I post this problem in one of the other lists? jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Looks like I solved my own problem... Sorry...
Okay, AFTER rebuilding linuxthreads with the most recent port, IT DID make it past gen_lex_hash. Word to the wise, if you haven't rebuilt linuxthreads, I suggest you do to avoid the problems I have had. Again, I am running -current of the early hours [CDT] of Sunday morning. Jim Bryant wrote: > > Okay, I just built it successfully without "WITH_LINUXTHREADS=yes". > > I also noticed that my linuxthreads lib was linuxthreads-2.1.2, and I'm rebuilding >it with the linuxthreads-2.2.3_1 sources. > Afterwards, I'll try the compile again. > > Jim Bryant wrote: > > > > I forgot to add: > > > > I am using the make option: `make WITH_LINUXTHREADS=yes` > > > > Jim Bryant wrote: > > > > > > I don't know if this belongs here, in the database list, or in the ports list... > > > > > > Under -current from early Sunday morning [CDT], a build of mysql-server-3.23.39 >hangs forever at: > > > > > > --- > > > ===> Building for mysql-server-3.23.39 > > > . > > > . [snip] > > > . > > > ./gen_lex_hash > lex_hash.h > > > --- > > > > > > It was there since about the time I went to bed, and it's still there now. > > > > > > I'll try to `make clean ; make`, just to be sure that something wierd didn't >happen. > > > > > > Is this a -current issue, or should I post this problem in one of the other >lists? jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
xl0 lock order reversal
My apologies for not looking into this more throughly before posting to the list, but I thought someone might be interested. The first time I run tcpdump after a reboot, I get this kernel message: xl0: promiscuous mode enabled lock order reversal 1st 0xc04f3fa0 bpf global lock @ ../../../net/bpf.c:365 2nd 0xc16beb9c xl0 @ ../../../pci/if_xl.c:2824 I'm running a mostly generic 5.0 kernel built from sources down loaded Jul 30 03:36 with a 1GHz Athlon system; the only difference from the GENERIC config is: device acpica options ACPI_DEBUG profile 1 On a related note, I've noticed that when doing compiles and other high load activities, my systems spends allot of time (nearly 50%) in witness_lock(), which not only has a nested loop in it, but also seems to do spin locking. Are spinlock's really a good idea on a single processor system (which is what I have)? thanx, brad ACPI debug layer 0x0 debug level 0x0 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: Sat Jul 28 13:10:18 MDT 2001 [EMAIL PROTECTED]:/scratch/5.0/src/sys/i386/compile/ACPI Calibrating clock(s) ... TSC clock: 1010038034 Hz, i8254 clock: 1193295 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: AMD Athlon(tm) Processor (1009.95-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x642 Stepping = 2 Features=0x183f9ff AMD Features=0xc044<,AMIE,DSP,3DNow!> Data TLB: 24 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 268369920 (262080K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00607000 - 0x0ffe7fff, 262017024 bytes (63969 pages) avail memory = 255184896 (249204K bytes) bios32: Found BIOS32 Service Directory header at 0xc00fdb40 bios32: Entry = 0xfdb50 (c00fdb50) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xdb71 pnpbios: Found PnP BIOS data at 0xc00f7710 pnpbios: Entry = f:6604 Rev = 1.0 Other BIOS signatures found: Preloaded elf kernel "kernel" at 0xc05e1000. Preloaded elf module "snd_sb16.ko" at 0xc05e109c. Preloaded elf module "snd_sbc.ko" at 0xc05e113c. Preloaded elf module "snd_pcm.ko" at 0xc05e11dc. Preloaded elf module "bktr.ko" at 0xc05e127c. Preloaded elf module "bktr_mem.ko" at 0xc05e1318. Preloaded elf module "joy.ko" at 0xc05e13b8. bktr_mem: memory holder loaded null: random: mem: Pentium Pro MTRR support enabled WARNING: Driver mistake: destroy_dev on 154/0 Math emulator present apm0: on motherboard apm0: found APM BIOS v1.2, connected at v1.2 acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. acpi0: sleep button is handled as a fixed feature programming model. Timecounter "ACPI" frequency 3579545 Hz acpi_cpu0: on acpi0 acpi_tz0: on acpi0 acpi_button0: on acpi0 acpi_pcib0: on acpi0 pci0: physical bus=0 map[10]: type 3, range 32, base e800, size 26, enabled map[14]: type 3, range 32, base eedfe000, size 12, enabled map[18]: type 4, range 32, base dc00, size 2, port disabled found-> vendor=0x1022, dev=0x7006, revid=0x25 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 found-> vendor=0x1022, dev=0x7007, revid=0x01 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 found-> vendor=0x1022, dev=0x7408, revid=0x01 bus=0, slot=7, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 map[20]: type 4, range 32, base f000, size 4, enabled found-> vendor=0x1022, dev=0x7409, revid=0x07 bus=0, slot=7, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 found-> vendor=0x1022, dev=0x740b, revid=0x03 bus=0, slot=7, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 map[10]: type 1, range 32, base efffe000, size 12, enabled found-> vendor=0x1022, dev=0x740c, revid=0x06 bus=0, slot=7, func=4 class=0c-03-10, hdrtype=0x00, mfdev=0 intpin=d, irq=7 map[10]: type 3, range 32, base eedff000, size 12, enabled found-> vendor=0x109e, dev=0x0350, revid=0x12 bus=0, slot=10, func=0 class=04-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=9 map[10]: type 4, range 32, base de00, size 7, enabled map[14]: type 1, range 32, base ef80, size 7, enabled found-> vendor=0x10b7, dev=0x9055, revid=0x24 bus=0, slot=12, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=10
THE GREATEST NO.1 SHOWS ON THE NET !
Dear Ladies & Gentlemen, Welcome to the GREATEST SEX SHOW on the ENTIRE NET ! We now offer you to ENTER to world´s No.1 voted SEX-SERVER on the WEB ! By far the largest and most incredible content of LIVE SEX is now served to users WORLDWIDE! EVERYTHING is offered 100% ANONOMOUSLY & you don´t need to sign-up or have a creditcard ... The way it should be ! PLUGIN RIGHT HERE AT: http://siam.to/worldclass ... If this Site does not open properly ... please try http://cyberu.to/worldclass Or this one, if you just love true LESBIAN SEX, CHAT and MORE from Sunny Ibiza in Spain: http://siam.to/classbabes ... If this Site does not open properly ... please try http://cyberu.to/hotbabes and get access to something you with guarantee NEVER have seen before ! Yours truly, XXXSENSATION Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xl0 lock order reversal
This lock order reversal is not a problem. See http://www.geocrawler.com/lists/3/FreeBSD/147/50/6267627/ for the meta-issue of witness being too verbose; I'd post URL's for the followup discussion but there wasn't any. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xl0 lock order reversal
On 30-Jul-01 Bill Fenner wrote: > > This lock order reversal is not a problem. See > http://www.geocrawler.com/lists/3/FreeBSD/147/50/6267627/ > for the meta-issue of witness being too verbose; I'd post URL's for > the followup discussion but there wasn't any. See my response to this thread that I just sent out earlier this morning. -- 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
fdisk broke?
Hi?! Got fdisk broken recently or does it have to do with SOFTUPDATES? Thanks! Jan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Uh Oh...Crash
On Sun, 29 Jul 2001, Matthew Jacob wrote: > 'truss clear |& tee /tmp/x'? ok, I figured out the clear issue...I didn't have entries in termcap for the QNX terminals (of course, not know that QNX used odd terminal names, ...). I'm still wondering, though, if there is such a thing as lost+found in UFS-land; when FreeBSD rebooting, I noticed a lot of lost files and such, and I haven't found anything on where they would be restored (or if/how they are restored)... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Uh Oh...Crash
fsck will create lost+found if it's not there. On Mon, 30 Jul 2001, Aaron Angel wrote: > On Sun, 29 Jul 2001, Matthew Jacob wrote: > > > 'truss clear |& tee /tmp/x'? > > ok, I figured out the clear issue...I didn't have entries in termcap for > the QNX terminals (of course, not know that QNX used odd terminal names, > ...). I'm still wondering, though, if there is such a thing as lost+found > in UFS-land; when FreeBSD rebooting, I noticed a lot of lost files and > such, and I haven't found anything on where they would be restored (or > if/how they are restored)... > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: just moved to current, mouse is jerky
- Original Message -
From: "Donald J. Maddox" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 30, 2001 12:10 AM
Subject: Re: just moved to current, mouse is jerky
> Try not using /dev/{u}random (don't load random.ko at boot). The random
> device uses mouse interrupts to harvest entropy, and it can cause some
> real jerkiness in the mouse. Of course, if you need to use something
> that really NEEDS good randomness, like SSH, then not loading random.ko
> is not really an option :(
Actually, I'm not loading Yarrow in the first place. That's why I think this
is weird.
(That and the fact that the last time I tried current, just after the
4.0-RELEASE was
split off, this was already happening.) It only happens on this box and
apparently
nobody else sees this exact problem (the last time I asked about it, back
then,
nobody answered it). I'm going to try it as a serial mouse and see what
happens.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
apache spins on signal 1 in -current
I've got an ongoing problem with apache. Sometimes in normal operation, and always when sent a SIGHUP, the main httpd process will spin and consume the cpu. GDB reveals that it's stuck somewhere in a thread handling routine: Program received signal SIGINT, Interrupt. 0x2862a31c in _thread_sig_handle_pending () from /usr/lib/libc_r.so.5 This is with the latest apache port and uthread_sig.c version 1.38. - Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Hard Lockup
Hi, Just cvsup'd the latest sources and now KDE is very unstable. During window opens or during busy times the box locks up. This is also happening reliably on logout. I have two boxes running current, and they both have the same symptoms. One's a 500MHz PIII and the other is a 233MHz PII. I'd include logs but there are no errors, just have to hard reboot. The box seems fine when I dont have X running. Beech --- Beech Rintoul - IT Manager - Instructor - [EMAIL PROTECTED] /"\ ASCII Ribbon Campaign | Anchorage Gospel Rescue Mission \ / - NO HTML/RTF in e-mail | P.O. Box 230510 X - NO Word docs in e-mail | Anchorage, AK 99523-0510 / \ - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock order reversals that aren't problematic
On Mon, Jul 30, 2001 at 12:31:43PM -0400, Garrett Wollman wrote: > < said: > > > However, the networking stack is being redone, > > By whom? I haven't seen anything about this posted to -net. I don't think John actually means "redone," just "locked down," or "mutexified." > -GAWollman -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Lock order reversals that aren't problematic
>...since a lock order reversal means that you can get in a deadlock... Argh, of course. It's only not problematic if it's a uniprocessor and it doesn't take an interrupt at the wrong time. Sorry for being dense, I'm still used to spl() =) Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Lock order reversals that aren't problematic
On 30-Jul-01 Garrett Wollman wrote: > < > said: > >> However, the networking stack is being redone, > > By whom? I haven't seen anything about this posted to -net. Err, bogon, networking stack _locking_ is being redone. (Missing keyword there) jlemon is heading up that task atm, but I don't know how far he has got. > -GAWollman -- 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: ACPI: Clock problems in -current
Mike Smith schrieb: [...] > Unfortunately, I can't reproduce the problem here - the new timer seems > to be working just fine. Can anyone seeing this please let me know: > > - What power management hardware your system has: look at the output of >pciconf -lv for a "power management controller", eg: > This machine has no separate controller. Attached is the complete output of "pciconf -lv" > > - which timecounter is in use on your system, eg: > > mass# sysctl kern.timecounter.hardware > kern.timecounter.hardware: ACPI During the Off/2 errors this variable contained "ACPI" > - whether you are seeing any "*time went backwards" console messages. Tons of, even with negative CPU-Usage times. Interesting enough, a "sleep 10" sleeps 10 real seconds: % date; sleep 10; date Mo 30 Jul 2001 19:27:07 CEST [...10 seconds delay...] Mo 30 Jul 2001 19:27:27 CEST -- Daniel agp0@pci0:0:0: class=0x06 card=0x154110b9 chip=0x154110b9 rev=0x04 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'M1541 Aladdin V AGPset Host Bridge' class= bridge subclass = HOST-PCI pcib1@pci0:1:0: class=0x060400 card=0x00e0 chip=0x524310b9 rev=0x04 hdr=0x01 vendor = 'Acer Labs Inc.' device = 'ALI M1541 PCI to AGP Bridge' class= bridge subclass = PCI-PCI ohci0@pci0:2:0: class=0x0c0310 card=0x chip=0x523710b9 rev=0x03 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'ALI M5237 USB Host Controller' class= serial bus subclass = USB isab0@pci0:7:0: class=0x060100 card=0x chip=0x153310b9 rev=0xc3 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'M1533 PCI South Bridge' class= bridge subclass = PCI-ISA none0@pci0:8:0: class=0x04 card=0x chip=0x0002121a rev=0x02 hdr=0x00 vendor = '3dfx Interactive Inc' device = 'Voodoo2 Voodoo 2 3D Accelerator' class= multimedia subclass = video sym0@pci0:9:0: class=0x01 card=0x chip=0x00041000 rev=0x04 hdr=0x00 vendor = 'LSI Logic' device = '53C815 Fast SCSI' class= mass storage subclass = SCSI rl0@pci0:10:0: class=0x02 card=0x813910ec chip=0x813910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RT8139 (A/B/C/8130) Fast Ethernet Adapter' class= network subclass = ethernet fxp0@pci0:11:0: class=0x02 card=0x00098086 chip=0x12298086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '82557/8/9 Fast Ethernet LAN Controller' class= network subclass = ethernet atapci0@pci0:15:0: class=0x0101fa card=0x chip=0x522910b9 rev=0xc1 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'M1543 Southbridge EIDE Controller' class= mass storage subclass = ATA none1@pci1:0:0: class=0x03 card=0x001c105d chip=0x493d105d rev=0x00 hdr=0x00 vendor = 'Number Nine Visual Technology' device = 'T2R Revolution 3D' class= display subclass = VGA
Re: (ref5) kdump: Cannout allocate memory
In some email I received from Bruce Evans, sie wrote: > On Mon, 30 Jul 2001, Darren Reed wrote: > > > Using ktrace ref5, I created ~darrenr/ktrace.out with "ktrace -i cc ..." > > but trying to print it I get: > > % kdump -f ~/ktrace.out > lout > > kdump: Cannot allocate memory > > > > Is this stack corruption by kdump? ref5:~darrenr/ktrace.out is available > > for anyone who wants to diagnose this further. > > This is probably a corrupt ktrace record. Atomic writing of ktrace > records seems to have been broken in rev.1.37 of kern_ktrace.c. I've > only seen this problem when the output file is written to an nfs > filesystem. Hmmm, for what it's worth, running the ktrace command which caused that broken ktrace.out file to be created, multiple times, resulted in it being corrupt at the same location each time. Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current lockups
On Mon, Jul 30, 2001 at 09:28:06AM -0700, John Baldwin wrote: > > On 30-Jul-01 Kris Kennaway wrote: > > Hi all, > > > > For the past 2 or 3 weeks my -current system has been experiencing > > temporary lockups, usually under disk load. The entire system will > > hang for around 20-30 seconds, during which time absolutely no > > network/IO/keyboard/mouse activity is accepted. Usually, after 20-30 > > seconds the system will unwedge and activity will resume, but > > sometimes it hangs forever. There are no console messages logged by > > this event. I cannot break into DDB until after system activity > > resumes normally. > > > > My system is a PPro 233 using IDE drives. Has anyone else seen > > something like this? > > I see this on my laptop sometimes, always accompanied by heavy disk I/O > during the entire interval. Since disk interrupts are higher priority than TTY > interrupts right now (no disk drivers use the PI_DISKLOW priority, partially > because there is no mechanism for them to do so right now) if a continual > stream of disk interrupts keeps the disk driver ithread busy, we will starve > TTY ithreads such as the one for keyboard and mouse. There's no disk activity during this period. I can hear my disks when they do work, and the machine is totally silent until it unwedges and the disk I/O resumes. Kris PGP signature
Re: quick informal survey: OpenSSH broken?
"David O'Brien" <[EMAIL PROTECTED]> wrote: > On Sun, Jul 29, 2001 at 09:53:09PM -0400, Brian Fundakowski Feldman wrote: > > I need to know, if OpenSSH is ever going to get MFC'ed, are there any people > > currently running OpenSSH 2.9 from -CURRENT's base and getting major > > problems with it? Or even minor ones that actually make things more > > You've never responded to requests from people asking what it would take > to make things fall back to v1 gracefully. We all know it is a "feature" > that with a default configuration, it will try ssh2 first and if it is > not able to authenticate (say you have no .ssh/authorized_keys2 file) the > connection can fail. I don't mean to disappoint, but I don't think it will be possible to fall back without creating modifications on both sides (both renogotiation of connection on the server side and client side, because the protocols are inherently different). For what it's worth, I tend to simply set "Protocol 1,2" in my .ssh/config and for the default case, it works fine (just like it used to). I don't want to make that policy decision, though, because we will be better off when everyone moves to the protocol version 2, so it's reasonable for the default to make things "difficult" to encourage the switch. I support the OpenSSH developers' plan here. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current lockups
On Sun, Jul 29, 2001 at 07:00:11PM -0700, Kris Kennaway wrote: > For the past 2 or 3 weeks my -current system has been experiencing > temporary lockups, usually under disk load. The entire system will > hang for around 20-30 seconds, during which time absolutely no > network/IO/keyboard/mouse activity is accepted. Usually, after 20-30 > seconds the system will unwedge and activity will resume, but > sometimes it hangs forever. There are no console messages logged by > this event. I cannot break into DDB until after system activity > resumes normally. I am also experiencing total wedging on disk activity (vi foo, was one) on a SCSI system since I updated late last week. My May 7th kernel was rock solid. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: X in free(): error: recursive call.
On Sun, Jul 29, 2001 at 04:38:06PM +0200, Sheldon Hearn wrote: > On Sun, 29 Jul 2001 22:29:40 +0800, Michael Robinson wrote: > > I'd like to get advice on which of the following courses of action to take: > > > > 1. Isolate and fix the problem. I would need some help here. > > Try a better-proven release of XFree86, namely 3.3.6. Based on my preliminary efforts to isolate the problem, it seems pretty clear that A) the code path required to reach the error is not exposed by the malloc API to applications (after all, how could an application call "free" recursively?), and B) it likely has something to do with an overlooked race condition in the thread safety retrofit of libc late last year. But, as was mentioned previously, XFree86 3.3.6 doesn't have the required chip support for the Dell 5000e, so that's not an option, regardless. I welcome further suggestions, though. -Michael Robinson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: quick informal survey: OpenSSH broken?
On Mon, 30 Jul 2001, Brian F. Feldman wrote: >For what it's worth, I tend to simply set "Protocol 1,2" in my .ssh/config >and for the default case, it works fine (just like it used to). I don't >want to make that policy decision, though, because we will be better off >when everyone moves to the protocol version 2, so it's reasonable for the >default to make things "difficult" to encourage the switch. I support the >OpenSSH developers' plan here. FWIW, I do the same in my .ssh/config because I work in a heterogeneous computing environment where my home directory is NFS automounted. Some operating systems come with SSH daemons still installed by default as 1,2. The newer operating systems, including most of our linux installs, are 2,1 by default. I use RSA keys to authenticate and it's easier to just have one keypair to worry about. When every machine I use has sshv2 support and does it by default, then I'll kill the RSA keys and generate DSA keys. It's quite annoying that systems which have 2,1 in their sshd_config won't detect that I have RSA keys in .ssh but no DSA keys and go ahead and select sshv1 on their own. -- Brandon D. Valentine <[EMAIL PROTECTED]> The very powerful and the very stupid have one thing in common. Instead of altering their views to fit the facts, they alter the facts to fit their views ... which can be very uncomfortable if you happen to be one of the facts that needs altering. - Doctor Who, "Face of Evil" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current lockups
On Mon, 30 Jul 2001 09:28:09 MST, John Baldwin wrote: > > panic: witness_restore: lock (sleep mutex) Giant not locked > > This is a different one. Is this during the dump itself? That I can > try to work on. (Basically, I need to make witness just stop doing > all of its various checks if panicstr != NULL). Oh cool! Yes, this is during the dump. I get the witness panic, following by something along the lines of "dump already in progress, bailing". Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: X in free(): error: recursive call.
Hello, I was running in the same problem early this year. Probably you have found my mails in the archive. Unfortunately I was not able solve the problem. I am running now 3.3.6 on my laptop (which furtunately supports the graphics chips that my laptop has). Just as a datapoint: My understanding of the problem is that it is really a problem of XFree (as opposed to FreeBSD) There seems to be a situation where malloc is called within a signal handler. It was explained to me that malloc cannot be recursively called. Therefore, if a signal interrupts Xfree when it is in the libc *alloc-functions, this can crash the server. The following trace shows this scenario: #0 0x2820a9e8 in kill () from /usr/lib/libc.so.5 #1 0x2825bb3d in abort () from /usr/lib/libc.so.5 #2 0x2825a682 in isatty () from /usr/lib/libc.so.5 #3 0x2825a6b0 in isatty () from /usr/lib/libc.so.5 #4 0x2825b6a6 in malloc () from /usr/lib/libc.so.5 #5 0x80d19ff in Xalloc (amount=16) at utils.c:1225 #6 0x80cc30c in TimerSet (timer=0x0, flags=0, millis=50, func=0x8788ef0, arg=0x88a0b00) at WaitFor.c:744 #7 0x87890fa in ?? () #8 0x878927d in ?? () #9 0x8788bf0 in ?? () #10 0x807da23 in xf86SigioReadInput (fd=7, closure=0x88a0b00) at xf86Events.c:1039 #11 0x8093d48 in xf86SIGIO (sig=23) at sigio.c:99 #12 0xbfbfffac in ?? () #13 0x2825b1b0 in isatty () from /usr/lib/libc.so.5 #14 0x2825b901 in realloc () from /usr/lib/libc.so.5 #15 0x80d1b18 in Xrealloc (ptr=0x8eb3000, amount=4096) at utils.c:1322 #16 0x80ceef4 in StandardReadRequestFromClient (client=0x8a0d100) at io.c:403 #17 0x80ac00c in Dispatch () at dispatch.c:438 #18 0x80bc395 in main (argc=3, argv=0xbfbffdc0, envp=0xbfbffdd0) at main.c:439 #19 0x806b31d in _start () My understanding is that the problem is with XFree using malloc in a signal-handler. Strange enough, my system at home (with a Matrox G400-Card and Xfree86-4.1.0) does not show this symptom. Michael On Tue, 31 Jul 2001, Michael Robinson wrote: > On Sun, Jul 29, 2001 at 04:38:06PM +0200, Sheldon Hearn wrote: > > On Sun, 29 Jul 2001 22:29:40 +0800, Michael Robinson wrote: > > > I'd like to get advice on which of the following courses of action to take: > > > > > > 1. Isolate and fix the problem. I would need some help here. > > > > Try a better-proven release of XFree86, namely 3.3.6. > > Based on my preliminary efforts to isolate the problem, it seems pretty > clear that A) the code path required to reach the error is not exposed by > the malloc API to applications (after all, how could an application call > "free" recursively?), and B) it likely has something to do with an overlooked > race condition in the thread safety retrofit of libc late last year. > > But, as was mentioned previously, XFree86 3.3.6 doesn't have the required > chip support for the Dell 5000e, so that's not an option, regardless. > > I welcome further suggestions, though. > > -Michael Robinson > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > > ___ Michael ClassE-Mail: [EMAIL PROTECTED] E-Business Solution Division ___ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current lockups
On Mon, 30 Jul 2001 07:26:55 MST, "David O'Brien" wrote: > I am also experiencing total wedging on disk activity (vi foo, was one) > on a SCSI system since I updated late last week. My May 7th kernel was > rock solid. Was this before or after you posted publically that -CURRENT seemed stable and that "now is a good time to upgrade if you've been holding back"? :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: acpica malfunctions
In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Mon, Jul 30, 2001 at 02:06:26AM -0700 On Mon, Jul 30, 2001 at 02:06:26AM -0700, Mike Smith wrote: > I've just committed a slightly different patch, based on a mix of your > ideas and mine (mostly yours). Thank you. Hmm, my previous patch was doing many unnecessary things... > Can you test the -current code, and let > me know what I broke this time? 8) Yes, apply the attached patch to unbrake it. :) Regards. Shop Smart Compare Prices on Name-Brand Products from Name-Brand Stores!! http://www.smartshop.com/cgi-bin/main.cgi?ssa=4099 dev.acpica.diff
Re: quick informal survey: OpenSSH broken?
On Sun, Jul 29, 2001 at 09:53:09PM -0400, Brian Fundakowski Feldman wrote: > I need to know, if OpenSSH is ever going to get MFC'ed, are there any people > currently running OpenSSH 2.9 from -CURRENT's base and getting major > problems with it? Or even minor ones that actually make things more You've never responded to requests from people asking what it would take to make things fall back to v1 gracefully. We all know it is a "feature" that with a default configuration, it will try ssh2 first and if it is not able to authenticate (say you have no .ssh/authorized_keys2 file) the connection can fail. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current lockups
On Mon, Jul 30, 2001 at 04:32:00PM +0200, Sheldon Hearn wrote: > > I am also experiencing total wedging on disk activity (vi foo, was one) > > on a SCSI system since I updated late last week. My May 7th kernel was > > rock solid. > > Was this before or after you posted publically that -CURRENT seemed > stable and that "now is a good time to upgrade if you've been holding > back"? :-) This is after. When I said that, I was happy with the state of affairs on the Alpha, and the IDE -current build boxes I have. However, those machines don't see as much use as this machine that is now locking up. However, those boxes were panicing often before I made that statement. So I still believe current is now in better shape than it was in June. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: quick informal survey: OpenSSH broken?
At 2:02 AM -0400 7/30/01, Garance A Drosihn wrote: >I will do some tests at home tomorrow morning, and >let you know how it works out. In the following: "gilead" refers to a MacOS 10 machine in my office at work which is running MacOS 10.0.4 plus an update to OpenSSH that reports itself as OpenSSH_2.9p1, SSH protocols 1.5/2.0, OpenSSL 0x0090581f "pulse-10" is a MacOS 10 machine at home, which is running MacOS 10.0.4 plus Apple's "Web Sharing Update, and OpenSSH in that reports itself as OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090581f "f14"is the freebsd machine at home when it is running stable. "f15"is the same machine when it is running -current. pulse-10 -> f14: does not work with openssh using protocol v1 does not work with openssh using protocol v2 does not work with a program called NiftyTelnetSSH, which uses v1 DOES work if I use a program called MacSSH, which uses v2 for all three which do not work, it acts as if f14 is simply not running sshd. f14 -> f14 does work, for both ssh1 and ssh2 f14 -> pulse-10 hrm. I forgot to write down what this did. I think it worked for one protocol but not for the other, but I don't remember for sure. pulse-10 -> f15 does not work with openssh using protocol v1 does not work with openssh using protocol v2 DOES work if I use NiftyTelnetSSH, using v1 DOES work if I use MacSSH, using v2 again, for the ones which didn't work, they just acted as if f15 was not running sshd, but obviously it was or the other two programs could not have connected... f15 -> pulse-10 works for openssh using v1 works for openssh using v2 f14 -> gilead arg. again I forgot to write it down. I think that what happened is that I did one set of tests, copied my notes from home to work, and then did the second set of tests without re-copying my notes... f15 -> gilead works for openssh using v1 dies a horrible death for openssh using v2: "Disconnecting: Bad packet length -1384901965" And just to be complete: pulse-10 -> gilead (ie, both MacOS 10's, with different openssh's) openssh v1 works openssh v2 dies: "Disconnecting: Bad packet length -1741630907" So, no matter how you slice it I seem to be able to come up with problems going between MacOS 10 and openssh on freebsd. However, I can't really say that openssh in -current is particularly worse than -stable, it's just different. Also note that I was doing these tests at 8am, which was about three hours earlier than I had expected to be awake this morning. So, they probably aren't as complete or as helpful as they might have been -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: md/mdmfs bugs
Kris Kennaway <[EMAIL PROTECTED]> writes:
> 1) For some reason, my mdmfs line in /etc/fstab always does a chmod
> 777 /tmp at mount-time
>
> /dev/md0/tmpmfs rw,-s=65536 0 0
I can't reproduce this. You say it "does a chmod"; does that mean you
see it caling chmod(2) (see as in using truss(1), or the undocumented
-X option), or is the symptom that it "winds up with mode 777"? Also,
does it happen when you run mdmfs from the command line, and/or with
directories other than /tmp?
> 2) the -X debugging option to mdmfs isn't documented in the manpage
Oops, will fix.
> 3) The following sequence of commands will cause my -current box to blow up:
>
> Step 1: disklabel -r -w md1c auto
^
Disklabel wants the disk name, not the partition. This is still a
panic(8)/hang(8) implementation, but it doesn't derive you of any
functionality.
> where md1 isn't a valid configured md instance. This command spits
> out a driver_mistake console warning message
> Step 2: mdconfig -d -u md1
> Step 3: Watch the console spew messages in an infinite loop until the
> end of time (Step 3 is optional).
This is actually a bug in the disk minilayer. md(4) is just the most
convenient driver to exploit those bugs, which is why we don't see
stuff like this happening with ad/da.
Furthermore, this is actually an exception-handling bug, not a real
functionality problem. Notice how you call disklabel with "md1c" as
an argument, while disklabel wants the name of the *disk*, not the
partition! What ends up happening is that disklabel tries to access
"md1cc", which isn't valid.
However, when subr_disk.c::disk_clone() parses the name to clone, it
only parses it up to where it got all the information it wants (it
wants the unit, slice, and partition). This means that asking it to
clone "md1cKRIS" will work just fine (try it: ls -l /dev/md1cKRIS);
the major/minor will be the same as md1c. How should this be handled?
It can either strip off the extraneous parts, or it can do nothing.
Either of these will remove the cause of the infinite loop (step 3).
I've attached a patch that does the latter as a proof-of-concept.
All that said, I probably just scratched the surface, and likely got a
few points even doing that. I'm sure phk will find the "real" problem
when he wakes up :-).
Index: subr_disk.c
===
RCS file: /ref/cvsf/src/sys/kern/subr_disk.c,v
retrieving revision 1.41
diff -u -r1.41 subr_disk.c
--- subr_disk.c 2001/05/29 18:19:57 1.41
+++ subr_disk.c 2001/07/30 08:42:25
@@ -82,6 +82,10 @@
continue;
else
p = name[i] - 'a';
+ if (name[++i] != '\0') {
+ printf("WARNING: attempt to access %s\n", name);
+ return;
+ }
}
*dev = make_dev(pdev->si_devsw, dkmakeminor(u, s, p),
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: acpica malfunctions
> Mike, > Seems like I managed to solve my problem. Attached is to be applied against > sys/dev/acpica/acpi_pcib.c, rev 1.10 . Thanks for tracking this down; without hardware to test here, it's been difficult. Great bug report! I've just committed a slightly different patch, based on a mix of your ideas and mine (mostly yours). Can you test the -current code, and let me know what I broke this time? 8) I've also let Intel know about the AcpiRsCaluclataeByteStreamLength bug, and some others I noticed while looking at the code, thanks for spotting this too. Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Lock order reversals that aren't problematic
On 27-Jul-01 Bill Fenner wrote: > > I'm curious what the long-term plan is for witness(4). For > example, it complains about BPF and device locks being reversed > when BPF takes the device out of promiscuous mode -- > > lock order reversal > 1st 0xc04c1560 bpf global lock @ /usr/src/sys/net/bpf.c:365 > 2nd 0xc1302b88 dc1 @ /usr/src/sys/pci/if_dc.c:3251 > > This is because when traffic is being handed to bpf from the > device, the device is locked so witness first sees dc1's > lock and then bpf's. The lock reversal occurs when the socket > is closed; bpfclose() calls bpf_detachd() which calls ifpromisc() > which calls into the device, which obtains its lock, but bpf > is already locked.. > > It's hard to add this case to the blessed_list, since it > can be any ethernet driver paired with bpf. > > Basically, I'm curious if this is a problem that needs to > be solved (i.e. the eventual goal is for witness to never > print any notices) or if this is expected behavior (i.e. > witness is expected to say things and it's up to the developer > to determine if a given thing that witness says is a problem). This is a problem that needs to be solved, since you a lock order reversal means that you can get in a deadlock, which is a Bad Thing (tm). However, the networking stack is being redone, which will involve redoing the network driver locks, so basically the network driver locks are on hold until the stack itself is done. -- 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: md/mdmfs bugs
On Mon, Jul 30, 2001 at 02:03:31AM -0700, Dima Dorfman wrote: > Kris Kennaway <[EMAIL PROTECTED]> writes: > > 1) For some reason, my mdmfs line in /etc/fstab always does a chmod > > 777 /tmp at mount-time > > > > /dev/md0/tmpmfs rw,-s=65536 0 0 > > I can't reproduce this. You say it "does a chmod"; does that mean you > see it caling chmod(2) (see as in using truss(1), or the undocumented > -X option), or is the symptom that it "winds up with mode 777"? Also, > does it happen when you run mdmfs from the command line, and/or with > directories other than /tmp? I haven't tracked it down, except that every time I reboot my /tmp winds up mode 777 again. > > Step 1: disklabel -r -w md1c auto > ^ > Disklabel wants the disk name, not the partition. This is still a > panic(8)/hang(8) implementation, but it doesn't derive you of any > functionality. Yeah..this was a typo, but it's stil wrong :) Kris PGP signature
Re: HEADS UP: new libmp imported
On Mon, Jul 30, 2001 at 07:44:33AM -0700, David O'Brien wrote: > On Sun, Jul 29, 2001, Kris Kennaway wrote: > > > > installed. This would involve a repo copy of crypto/openssl/crypto/bn > > to contrib/openssl-bn or something, and I'd keep the two in sync with > > future vendor imports. > > You're likely to get people saying "repo bloat". And it does seem a > little wrong to have two copies in the tree like that. > > Just what programs are affected by this issue (ie, which use libmp)? I don't have the list to hand right now, but they all related to the "secure RPC" code which arguably should be in the crypto distribution anyway. > > can get it to work, so much the better. That said, right now > > everything that uses libmp could be considered `crypto' code, anyway, > > I don't see anything wrong with that. At this point the `crypto' code > should be seen as virtually required. Originally was was "optional" > because of USA export laws. That is not an issue today. We've tried to take the position that the crypto collection is useful and installed by default, but that the system should be fully usable without it. Not everyone lives in the USA, and other countries still have repressive crypto laws which might otherwise prevent them from using FreeBSD. Kris PGP signature
Re: HEADS UP: new libmp imported
On Sun, Jul 29, 2001, Kris Kennaway wrote: > > installed. This would involve a repo copy of crypto/openssl/crypto/bn > to contrib/openssl-bn or something, and I'd keep the two in sync with > future vendor imports. You're likely to get people saying "repo bloat". And it does seem a little wrong to have two copies in the tree like that. Just what programs are affected by this issue (ie, which use libmp)? On Sun, Jul 29, 2001 at 03:41:11PM -0700, Dima Dorfman wrote: > > > libmp that I haven't been able to test is the Kerberized telnet, but > > > since it's the same code as the other telnets, there shouldn't be any > > > problems. > > > > When Mark and I talked about this a few months ago, we concluded that > > we'd have to first break out the (self-contained) bignum lib [...] > > BIGNUM isn't self-contained. It needs the ERR_* subsystem, as well as > (I think) the BIO subsystem. ... > can get it to work, so much the better. That said, right now > everything that uses libmp could be considered `crypto' code, anyway, I don't see anything wrong with that. At this point the `crypto' code should be seen as virtually required. Originally was was "optional" because of USA export laws. That is not an issue today. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: (ref5) kdump: Cannout allocate memory
On Mon, 30 Jul 2001, Darren Reed wrote: > Using ktrace ref5, I created ~darrenr/ktrace.out with "ktrace -i cc ..." > but trying to print it I get: > % kdump -f ~/ktrace.out > lout > kdump: Cannot allocate memory > > Is this stack corruption by kdump? ref5:~darrenr/ktrace.out is available > for anyone who wants to diagnose this further. This is probably a corrupt ktrace record. Atomic writing of ktrace records seems to have been broken in rev.1.37 of kern_ktrace.c. I've only seen this problem when the output file is written to an nfs filesystem. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current lockups
On 30-Jul-01 Sheldon Hearn wrote: > > > On Mon, 30 Jul 2001 07:38:47 MST, "David O'Brien" wrote: > >> However, those boxes were panicing often before I made that statement. >> So I still believe current is now in better shape than it was in June. > > I'll be a lot happier when I can enabled DDB_UNATTENDED and do whatever > it is that causes my panic of the day and actually get a crashdump > instead of > > panic: witness_restore: lock (sleep mutex) Giant not locked This is a different one. Is this during the dump itself? That I can try to work on. (Basically, I need to make witness just stop doing all of its various checks if panicstr != NULL). -- 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: -current lockups
On Mon, 30 Jul 2001 07:38:47 MST, "David O'Brien" wrote: > However, those boxes were panicing often before I made that statement. > So I still believe current is now in better shape than it was in June. I'll be a lot happier when I can enabled DDB_UNATTENDED and do whatever it is that causes my panic of the day and actually get a crashdump instead of panic: witness_restore: lock (sleep mutex) Giant not locked :-) Fortunately, jhb has said he'll try take a look at this some time this week. However, if I hadn't interacted with the guy directly, I'd be pretty frustrated with -CURRENT. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: su root broken in -CURRENT
On Thu, 26 Jul 2001, Sheldon Hearn wrote: > On Wed, 25 Jul 2001 19:20:45 MST, Kris Kennaway wrote: > > > Isn't this backwards? Code shouldn't be making assumptions about the > > special meaning of numeric gids. What if you wanted to renumber gid > > wheel to something else? > > So? My primary group is 0. In /etc/group, group wheel's numeric value > is 0. The FreeBSD 4.3 manpage says: Only users who are a member of group 0 (normally ``wheel'') can su to ``root''. If group 0 is missing or empty, any user can su to ``root''. The OpenBSD-current manpage says (more explicitly): If group 0 (normally ``wheel'') has users listed then only those users can su to ``root''. It is not sufficient to change a user's /etc/passwd entry to add them to the ``wheel'' group; they must explicitly be listed in /etc/group. If no one is in the ``wheel'' group, it is ignored, and anyone who knows the root password is permitted to su to ``root''. The FreeBSD -CURRENT manpage doesn't mention wheel at all, referring the reader to pam.conf to work out the semantics. I think this is a loss - the defaults for su in pam.conf should at least be covered in the manpage. Joshua To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Lock order reversals that aren't problematic
< said: > However, the networking stack is being redone, By whom? I haven't seen anything about this posted to -net. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: -current lockups
On 30-Jul-01 Kris Kennaway wrote: > Hi all, > > For the past 2 or 3 weeks my -current system has been experiencing > temporary lockups, usually under disk load. The entire system will > hang for around 20-30 seconds, during which time absolutely no > network/IO/keyboard/mouse activity is accepted. Usually, after 20-30 > seconds the system will unwedge and activity will resume, but > sometimes it hangs forever. There are no console messages logged by > this event. I cannot break into DDB until after system activity > resumes normally. > > My system is a PPro 233 using IDE drives. Has anyone else seen > something like this? I see this on my laptop sometimes, always accompanied by heavy disk I/O during the entire interval. Since disk interrupts are higher priority than TTY interrupts right now (no disk drivers use the PI_DISKLOW priority, partially because there is no mechanism for them to do so right now) if a continual stream of disk interrupts keeps the disk driver ithread busy, we will starve TTY ithreads such as the one for keyboard and mouse. > Kris -- 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
