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=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR AMD Features=0xc044b18,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: null device, zero device random: entropy source mem: memory I/O Pentium Pro MTRR support enabled WARNING: Driver mistake: destroy_dev on 154/0 Math emulator present apm0: APM BIOS on motherboard apm0: found APM BIOS v1.2, connected at v1.2 acpi0: AMIINT 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: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_button0: Power Button on acpi0 acpi_pcib0: Host-PCI bridge 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,
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: On Mon, 30 Jul 2001 09:28:03 -0700 (PDT), John Baldwin [EMAIL PROTECTED] 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: On Mon, 30 Jul 2001 09:28:03 -0700 (PDT), John Baldwin [EMAIL PROTECTED] 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: 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: 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: -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: 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 f14is the freebsd machine at home when it is running stable. f15is 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: 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 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
On Mon, 30 Jul 2001 09:28:03 -0700 (PDT), John Baldwin [EMAIL PROTECTED] 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
