Re: ACPI: Clock problems in -current
On Sat, 28 Jul 2001, Mike Smith wrote: You could also try building a kernel with CLK_CALIBRATION_LOOP defined and then booting with -v (without the timer disabled). This might be instructive (I don't know for certain that it'll calibrate the ACPI timer, since it may not have been probed yet). It won't. CLK_CALIBRATION_LOOP only iterates calibration of the i8254 and TSC timers relative to the RTC. None of the clock calibration stuff is very useful. All the clock frequencies depend on the temperature, so their values at boot time are only slightly more related to their values at run time than their values at a random time. Average values are probably better than boot time values. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current kernel panicing
Just a update, I did the latest buildworld with the latest -current sources and it still hapens... root@pele [9:29pm][/usr/temp] Jul 28 21:29:40 pele /boot/kernel/kernel: lock order reversal Jul 28 21:29:40 pele /boot/kernel/kernel: lock order reversal Jul 28 21:29:40 pele /boot/kernel/kernel: 1st 0xd92fea9c process lock @ /usr/src/sys/vm/vm_glue.c:469 Jul 28 21:29:40 pele /boot/kernel/kernel: 1st 0xd92fea9c process lock @ /usr/src/sys/vm/vm_glue.c:469 Jul 28 21:29:40 pele /boot/kernel/kernel: 2nd 0xc118dfb0 lockmgr interlock @ /usr/src/sys/kern/kern_lock.c:239 Jul 28 21:29:40 pele /boot/kernel/kernel: 2nd 0xc118dfb0 lockmgr interlock @ /usr/src/sys/kern/kern_lock.c:239 Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin On Sat, 28 Jul 2001, Vincent Poy wrote: Interesting... I'm running on a cvsup of July 25, 2001 17:00GMT except because of Ian Dowse mentioning in the message thread: SIGCHLD changes causing fault on nofault entry panics, I reverted back to src/sys/kern/kern_exit.c 1.130 and src/sys/kern/kern_sig.c 1.124 to test. Sometimes it will just hang. I noticed that sometimes it will say when it hangs solid: swap_pager: out of swap space swap_pager_getswapspace:failed And this machine does have 512Megs of ram and only 64 is used most of the time. Even swapinfo indicates that it's not using the swap yet. root@pele [4:23pm][/usr/home/vince] swapinfo Device 1K-blocks UsedAvail Capacity Type /dev/da0s1b2620160 262016 0%Interleaved From the following output, it seems like nfs code is at fault but we're not even using nfs at all root@pele [4:24pm][/usr/home/vince] nm -n /boot/kernel/kernel | grep da041d9c root@pele [4:25pm][/usr/home/vince] nm -n /boot/kernel/kernel | grep da041d9 root@pele [4:25pm][/usr/home/vince] nm -n /boot/kernel/kernel | grep da041d root@pele [4:25pm][/usr/home/vince] nm -n /boot/kernel/kernel | grep da041 root@pele [4:25pm][/usr/home/vince] nm -n /boot/kernel/kernel | grep da04 c02bda04 T nfs_curusec root@pele [4:25pm][/usr/home/vince] nm -n /boot/kernel/kernel | grep c118de00 root@pele [4:27pm][/usr/home/vince] nm -n /boot/kernel/kernel | grep c118de0 root@pele [4:27pm][/usr/home/vince] nm -n /boot/kernel/kernel | grep c118de root@pele [4:27pm][/usr/home/vince] nm -n /boot/kernel/kernel | grep c118d root@pele [4:27pm][/usr/home/vince] nm -n /boot/kernel/kernel | grep c118 c03dc118 ? __set_sysuninit_set_sym_M_IFADDR_uninit_sys_uninit c03ec118 d twed_twe_driver_list Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin On Sat, 28 Jul 2001, matt wrote: Something wrong in the fs lock code. == WWW.XGFORCE.COM The Next Generation Load Balance and Fail Safe Server Clustering Software for the Internet. == - Original Message - From: Vincent Poy [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, July 28, 2001 2:49 AM Subject: -current kernel panicing I'm getting a panic in the -current kernel with using kernels built with src/sys/kern/kern_exit.c 1.130 and src/sys/kern/kern_sig.c 1.124 as well as with src/sys/kern/kern_exit.c 1.131 and src/sys/kern/kern_sig.c 1.125. This seems to be a problem that only passwd(1) and chpass(1) seems to cause. vipw appears to work fine as well as everything else. This is what happens: root@pele [10:55pm][~] passwd toor Changing local password for toor. New password: Retype new password: passwd: updating the database... passwd: done root@pele [10:55pm][~] root@pele [10:55pm][~] root@pele [10:55pm][~] root@pele [10:55pm][~] root@pele [10:55pm][~] root@pele [10:55pm][~] root@pele [10:55pm][~] root@pele [10:55pm][~] After here, it just freezes solid for 1 minute then displays on the console... Jul 27 22:57:24 pele /boot/kernel/kernel: lock order reversal Jul 27 22:57:24 pele /boot/kernel/kernel: lock order reversal Jul 27 22:57:24 pele /boot/kernel/kernel: 1st 0xda041d9c process lock @
Re: SIGCHLD changes causing fault on nofault entry panics
On Fri, 27 Jul 2001, Ian Dowse wrote:
The panics in exit1() that have been reported on -stable appear to
be caused by these commits:
REV:1.92.2.4kern_exit.c 2001/07/25 17:21:46 dillon
REV:1.72.2.7kern_sig.c 2001/07/25 17:21:46 dillon
MFC kern_exit.c 1.131, kern_sig.c 1.125 - bring SIGCHLD SIG_IGN signal
handling in line with other operating systems.
These probably correspond to similar panics seen in -current, but I
haven't checked the details.
In the vmcore I just got, the panic occurred in the following
fragment in exit1(), when dereferencing p_sigacts (which is
p_procsig-ps_sigacts). I guess there is a race here if the parent
is exiting or something?
+ if ((p-p_pptr-p_procsig-ps_flag PS_NOCLDWAIT)
+ || p-p_pptr-p_sigacts-ps_sigact[_SIG_IDX(SIGCHLD)] == SIG_IGN) {
Matt, I will just back out these changes from RELENG_4 shortly
until the issue is resolved. The change was non-essential and quite
contained, so it's probably better than waiting for a fix.
Ian
The problem seems to cause the following panic in vm_glue.c and nd
kern_lock.c as well.
Jul 28 21:29:40 pele /boot/kernel/kernel: lock order reversal
Jul 28 21:29:40 pele /boot/kernel/kernel: lock order reversal
Jul 28 21:29:40 pele /boot/kernel/kernel: 1st 0xd92fea9c process lock @
/usr/src/sys/vm/vm_glue.c:469
Jul 28 21:29:40 pele /boot/kernel/kernel: 1st 0xd92fea9c process lock @
/usr/src/sys/vm/vm_glue.c:469
Jul 28 21:29:40 pele /boot/kernel/kernel: 2nd 0xc118dfb0 lockmgr interlock
@ /usr/src/sys/kern/kern_lock.c:239
Jul 28 21:29:40 pele /boot/kernel/kernel: 2nd 0xc118dfb0 lockmgr interlock
@ /usr/src/sys/kern/kern_lock.c:239
panic: recurse
Debugger (panic)
Stopped at Debugger+0x44: push1 %ebx
db
and then it just hangs solid here.
Cheers,
Vince - [EMAIL PROTECTED] - Vice President __
Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ]
WurldLink Corporation / / / / | / | __] ]
San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ]
HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[]
Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
HEADS UP: new libmp imported
I've imported the libmp-in-terms-of-OpenSSL library and connected it to the build. I've also disconnected libgmp and friends from the build, but have not `cvs rm`'d it yet. Assuming no problems turn up, I plan to do that in two or three days. The only program that use 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
X in free(): error: recursive call.
I am running -CURRENT as of 2001/01/31 12:00, more or less uneventfully for the last six months on a Dell 5000e. The one problem is that X occasionally dies without coredump or cleanup with the error 'X in free(): error: recursive call.'. This usually (but not always) happens while using Mozilla with heavy window creation/deletion and heavy (dialup) network activity. This has happened under several recent versions of Mozilla, two different versions of fvwm2, with and without session managers, and with both X 4.0.3 and 4.1.0. It took me a while to identify the problem, because it happens infrequently, unpredicably, and leaves the video drivers in an unusable state (forcing a blind reboot). I tried linking /etc/malloc.conf to 'A' to get a coredump from X, but that doesn't work. I found a very short discussion of a related problem in the -CURRENT mail archives from the beginning of January, but there wasn't any apparent resolution of the problem. 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. 2. Downgrade to -STABLE. The reason I was running -CURRENT originally was for ACPI support, but Dell has since released an APM-enabled BIOS for the 5000e, so -CURRENT is no longer a requirement. 3. Upgrade to current -CURRENT. I don't know if this is such a good idea judging from mailing list traffic. 4. Hang in with the status quo for another couple months until 5.0 is released, install that, and start back at #1 if that doesn't work. Any advice, comments, or suggestions warmly appreciated. Thanks. -Michael Robinson 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, 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. 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.
From: Sheldon Hearn [EMAIL PROTECTED] Date: Sun, 29 Jul 2001 16:38:06 +0200 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. FWIW, the laptop I use is very similar to a Dell Inspiron 5000e. I was unable to use XF86 3.x because the machine has a display with a resolution of 1400x1050 (which XF86 3.x apparently doesn't cope with for the ATI Rage Mobility). Information about how I set the machine up is at http://www.catwhisker.org/~david/FreeBSD/laptop.html -- briefly, I've been tracking both -STABLE -CURRENT daily (with a few exceptions). Though I do most of tthe work on the machine in -STABLE, I do not recall encountering the symptoms mentioned by Michael Robinson, and I do fire up netscape a few other things in -CURRENT as a reality check fairly often. If there's a more specific sequence of events for causing the observed failure, I'll be happy to try the sequence after today's -CURRENT finishes building, and report back. Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Have a good laugh!
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Wind-up A Friend, Colleague, Relative Or Even An Enemy -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Call Jokeline and you'll be in stitches! With our new service you're able to wind-up, confuse and bemuse people with a choice of bogus callers that you can transfer to your victim on any UK landline or mobile and then listen in to the call and hear their reaction Don't worry though, they won't be able to hear you, nor tell that you made the call - try it on a speaker phone and a group can hear -~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Just use the easy to follow recipe: -~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- (i) choose one ripe victim (ii) add Jokeline by dialling 0906 736 9265 and select 1 - Wind-up samples 2 - Mr Angry 3 - The Irate Delivery Driver 4 - An Invite To No 10 5 - There's A Bomb In Your Street 6 - You're Wanted At The Police Station 7 - The Tax Inspector 8 - You've Got My Daughter Pregnant (iii) enter your victims number and wait for the transfer (iv) when they answer, prepare yourself and ...enjoy! -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This has got to be the funniest way to wind-up anyone -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jokeline BCM 1543 London WC1N 3XX United Kingdom Calls to 0906 numbers are charged at £1/min at all times Maximum call duration 5 mins, average 2 mins Please ensure you have the permission of the bill payer before calling -~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- You've received this email as you're on our mailing list If however, you do not wish to receive any further emails simply mailto:[EMAIL PROTECTED] with the email address(es) to be removed inserted in the subject line To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Death sentence to KLD screen savers? Comments?
Kazutaka YOKOTA wrote: I propose to have user-land screen savers instead of KLD screen savers. [ ... performance degradation ... ] [ ... file access ... ] I don't see either of these as being compelling arguments in favor of a user space implementation; I guess this means you want to do file access in your screen saver(s). Both points/complaints/requests have been raised several times in our mailing lists in the past. (Sorry, I don't keep copies.) I didn't say they weren't arguments, merely that I did not find them compelling. This looks to me like change for the sake of change. Some people don't like cputime eaten up by the screen saver in the kernel... The simple answer for this is to run in a kproc, and set the priority to idle, so it only runs when there is nothing else to run. Actually, running in user space adds two problems: 1) Performance degradation as a result of protection domain crossing which does not exist in the current implementation 2) Inability to disable the screen saver in, for example, a panic situation, where there is no opportunity to return to user space and have the screen put back into a known good state. This is analogous to the problem we have diagnosing kernel panics while X11 is running on the console: only the user space program can undo what it has done, and we can not run the user space program. Some peopel want to write interesting screen savers... Now we see the real reason for this... 8^). Now if you could run Windows screen saver modules, you might have a good argument for change, above and beyond change for the sake of change. Personally I am not interested in fancy screen savers :-) But, just want to keep things tidy and keep the system running smoothly. By moving much of the screen saver support from the console driver to the user-land... The problem here is that only the video driver knows what it knows; short of converting FreeBSD's console over to something like GGI, you will have a hard time moving *everything* to userland. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Death sentence to KLD screen savers? Comments?
Actually, running in user space adds two problems: 1) Performance degradation as a result of protection domain crossing which does not exist in the current implementation So, you seems to be effectively saying that any program running in the lower priority in the user-land is the source of performance degrataion :-) 2) Inability to disable the screen saver in, for example, a panic situation, where there is no opportunity to You may be thinking that we can put the video hardware back to the known state after ANY KLD screen saver has run. This is simply not true. It is simply that the KLD screen savers we currently have are well-behaved. Once you write a KLD screen saver which directly manipulates the video hardware in the way the console driver isn't aware of (and there is no mechanisms which will prevent you from doing this), it becomes impossible for the console driver to undo such operation. return to user space and have the screen put back into a known good state. This is analogous to the problem we have diagnosing kernel panics while X11 is running on the console: only the user space program can undo what it has done, and we can not run the user space program. The console driver cannot undo what the X server does, because the X server manipulates every bits of the video hardware to maximize its performance and the console has no control over this. IF the X server used olny console ioctls or touched generic VGA registers only, we could put the video card back to the known state when the kernel panics. It's true that you can write a user-land screen saver which touchs the video hardware (non-standard registers etc.) in a similar way to the X server. But, such screen savers won't be portable in the sense that it runs only on certain video cards, and breaks on the other. Therefore, you need to stick with console ioctls (and libvgl) to make it run on every hardware. # Of course, we don't have this problem with text-type screen savers # which may use escape sequences or ncurses. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
just moved to current, mouse is jerky
I just upgraded to current today on my goof-off box, and the mouse moves in big jerks instead of smoothly. It does this either in X or in console, and also in X without moused running (reading /dev/psm0 directly). I've also tried setting high resolution on this device (flags 0x004). Nothing has made any difference. Should I really be using the devfs devices and not the old static ones (in general, not just in this case)? Is this a known issue? What should I try next? (Am I just being an idiot bothering people about this? I realize that expecting current to work perfectly is unreasonable, but this sure puts a crimp in my messing around on it.) Thanks for helping out a not-very-important current user with a dumb problem. 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
I've seen the same thing for over three weeks, but haven't had time to figure out why. I am using devfs, so that is not it. Just typing text is jerky and the system response is slower overall. This probably started happening in the week or week and a half before July 8th. On Sunday 29 July 2001 22:06, Ray Kohler wrote: I just upgraded to current today on my goof-off box, and the mouse moves in big jerks instead of smoothly. It does this either in X or in console, and also in X without moused running (reading /dev/psm0 directly). I've also tried setting high resolution on this device (flags 0x004). Nothing has made any difference. Should I really be using the devfs devices and not the old static ones (in general, not just in this case)? Is this a known issue? What should I try next? (Am I just being an idiot bothering people about this? I realize that expecting current to work perfectly is unreasonable, but this sure puts a crimp in my messing around on it.) Thanks for helping out a not-very-important current user with a dumb problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Danny J. Zerkel [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Uh Oh...Crash
Okay, had a storm here and power went out and fizzed a little, going between on and off, until it finally shut off. Now, this is the first time that I've actually had something like this happen, and have bad things happen after fbsd rebooted. First off, is there such a thing as lost+found? Also, I'm having what seems to be a termcap problem. Whenever I use things the look up stuff in termcap, like clear, and sysinstall, it says tgetent: file not found, but /etc/termcap (linked to /usr/share/misc/termcap) and /etc/termcap.db both exist... Any suggustions for either of these problems? Thanks. -- By all means, become the media. - Emmanual Goldstein, 2600 Magazine To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
(ref5) kdump: Cannout allocate memory
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. FYI: % limit cputime unlimited filesizeunlimited datasize524288 kbytes stacksize 65536 kbytes coredumpsizeunlimited memoryuse unlimited descriptors 2088 memorylockedunlimited maxproc 1043 I can't see that I've got any special malloc debugging things defined either in environment variables or elsewhere. Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
lock panic July 27th current
This occurred when running vmware while simultaneously compiling koffice over an NFS link. I've got dumpdev set now, so I'll get a core on the next crash. barry fxp0: promiscuous mode enabled vmnet1: promiscuous mode enabled lock order reversal 1st 0xc19e8700 pcm0:3:play @ /usr/src/sys/dev/sound/pcm/dsp.c:117 2nd 0xc19e8ac0 pcm0 @ /usr/src/sys/dev/sound/pcm/sound.c:99 lock order reversal 1st 0xcc14eb9c process lock @ /usr/src/sys/vm/vm_glue.c:469 2nd 0xc0cdaf80 lockmgr interlock @ /usr/src/sys/kern/kern_lock.c:239 recursed on non-recursive lock (sleep mutex) process lock @ /usr/src/sys/kern/kern_lock.c:262 first acquired @ /usr/src/sys/kern/kern_exit.c:327 panic: recurse syncing disks... 36 36 panic: Lock (sx) allproc not locked @ /usr/src/sys/kern/kern_proc.c:152. Uptime: 12m21s /dev/vmmon: Module vmmon: unloaded Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... 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: Fri Jul 27 19:50:06 EDT 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/VAIO Timecounter i8254 frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (645.21-MHz 686-class CPU) Origin = GenuineIntel Id = 0x683 Stepping = 3 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 201261056 (196544K bytes) avail memory = 190930944 (186456K bytes) Preloaded elf kernel kernel at 0xc04a7000. Preloaded elf module ugen.ko at 0xc04a709c. Preloaded elf module ums.ko at 0xc04a7138. Preloaded elf module umass.ko at 0xc04a71d4. Preloaded elf module ipl.ko at 0xc04a7274. Pentium Pro MTRR support enabled Using $PIR table, 7 entries at 0xc00fdf50 apm0: APM BIOS on motherboard apm0: found APM BIOS v1.2, connected at v1.2 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Intel 82443BX (440 BX) host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at 0.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xfc90-0xfc9f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xfca0-0xfcbf irq 9 at device 7.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhub1: Philips Semiconductors hub, class 9/0, rev 1.10/1.10, addr 2 uhub1: 3 ports with 3 removable, self powered umass0: Sony USB Memory Stick Slot, rev 1.10/1.31, addr 3 ums0: Logitech USB Mouse, rev 1.10/6.20, addr 4, iclass 3/1 ums0: 3 buttons and Z dir. pci0: bridge, PCI-unknown at 7.3 (no driver attached) pci0: serial bus, FireWire at 8.0 (no driver attached) pcm0: Yamaha DS-1E (YMF744) port 0xfc8c-0xfc8f,0xfcc0-0xfcff mem 0xfedf8000-0xfedf irq 9 at device 9.0 on pci0 pci0: simple comms at 10.0 (no driver attached) fxp0: Intel Pro 10/100B/100+ Ethernet port 0xfc40-0xfc7f mem 0xfec0-0xfecf,0xfedf6000-0xfedf6fff irq 9 at device 11.0 on pci0 fxp0: Ethernet address 08:00:46:0d:8b:a9 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci_cfgintr_unique: hard-routed to irq 9 pci_cfgintr: 0:12 INTA routed to irq 9 pcic0: Ricoh RL5C475 PCI-CardBus Bridge irq 9 at device 12.0 on pci0 pcic0: Memory mapped device, will work. pcic0: PCI Memory allocated: 0x4400 pccard0: PC Card bus (classic) on pcic0 orm0: Option ROMs at iomem 0xc-0xc,0xdc000-0xd on isa0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model GlidePoint, device ID 0 pmtimer0 on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x90 on isa0 sio0: type 16550A vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0303 can't assign resources unknown: PNP0c02 can't assign resources unknown: PNP0c02 can't assign resources unknown: PNP0501 can't assign resources IPsec: Initialized Security Association Processing. IP Filter: v3.4.16 initialized. Default = pass all, Logging = enabled ad0: 11513MB FUJITSU MHK2120AT [23392/16/63] at ata0-master UDMA33 (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition (probe0:umass-sim0:0:0:0): NOT READY asc:3a,0 (probe0:umass-sim0:0:0:0): Medium not present (probe0:umass-sim0:0:0:0): Unretryable error Mounting root from ufs:/dev/ad0s2a WARNING: / was not properly
md/mdmfs bugs
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 2) the -X debugging option to mdmfs isn't documented in the manpage 3) The following sequence of commands will cause my -current box to blow up: Step 1: disklabel -r -w md1c auto 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). Kris PGP signature
quick informal survey: OpenSSH broken?
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 difficult? I want to have no real outstanding issues, except simple ones like Protocol being set to 2,1 by default (which is a reasonable default nowadays), before I MFC OpenSSH, because I really don't want to leave anyone screwed over in the process. So let me know, ASAP, what problems you all are having with OpenSSH in -CURRENT, specifically in the FreeBSD-specific parts. I'm also not certain of KRB4 and KRB5 auth still both work properly, and need that verified. Thanks, everybody. -- 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
-current lockups
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? Kris PGP signature
Re: Help wanted: loadable SMBFS
I have an update on this one. (John, lemme know if you want access to
the crashdump).
On Wed, 25 Jul 2001 21:30:49 +0200, Sheldon Hearn wrote:
Log:
Add build infrastructure for a libiconv loadable kernel module.
This should allow the use of the smbfs module without the
requirement to rebuild the kernel with LIBICONV.
I haven't connected this to the modules build because I can't test that
it works. Sure, it loads fine, but I get a reproducible kernel mode
page fault in the rl(4) interrupt handler when I actually try to use it.
The kernel mode page fault isn't in the if_rl interrupt handler. That
was a weird red herring.
It took a while to get a working crashdump. I would type panic and
press enter, coming right back to the prompt. If I pressed enter or
typed panic and pressed enter at the prompt, I'd get this:
panic: Lock (sx) allproc not locked. [...] kern_synch.c:297
Eventually, I got a crashdump as follows:
panic
trace
panic
Weird. So here's what's actually going wrong for me:
#10 0xc0271480 in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16,
tf_edi = -881182336, tf_esi = -1053397736, tf_ebp = -852845520,
tf_isp = -852845552, tf_ebx = -1070565552, tf_edx = 0,
tf_ecx = -881182336, tf_eax = -1070717408, tf_trapno = 12, tf_err = 0,
tf_eip = -1071939473, tf_cs = 8, tf_eflags = 66071,
tf_esp = -1053397736, tf_ss = -1054244352})
at /usr/src/sys/i386/i386/trap.c:410
410 (void) trap_pfault(frame, FALSE, eva);
#11 0xc01b806f in witness_destroy (lock=0xc1366d18)
at /usr/src/sys/kern/subr_witness.c:395
#12 0xc0191b8b in mtx_destroy (m=0xc1366d18)
at /usr/src/sys/kern/kern_mutex.c:680
#13 0xc134827d in smb_iod_destroy (iod=0xc1366d00)
at /usr/src/sys/modules/smbfs/../../netsmb/smb_iod.c:692
[...]
Looking inside frame #11...
(kgdb) frame 11
#11 0xc01b806f in witness_destroy (lock=0xc1366d18)
at /usr/src/sys/kern/subr_witness.c:395
395 STAILQ_REMOVE(all_locks, lock, lock_object, lo_list);
(kgdb) print *lock-lo_witness
$34 = {w_name = 0xc029dbc6 (dead), w_class = 0xc02e0380, w_list = {
stqe_next = 0xc0307778}, w_typelist = {stqe_next = 0xc0307778},
w_children = 0x0, w_file = 0xc029dbc6 (dead), w_line = 0, w_level = 1,
w_refcount = 0, w_Giant_squawked = 0 '\000', w_other_squawked = 0 '\000',
w_same_squawked = 0 '\000'}
I'm absolutely stumped.
Ciao,
Sheldon.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: -current lockups
This has happened on and off for various platforms since SMPNG. On Sun, 29 Jul 2001, 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? Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NFS file locking fails from Solaris
[EMAIL PROTECTED] wrote: The Solaris client mounts the FreeBSD exported filesystem fine. I can create, delete, and manipulate files fine. However, when I try to use fcntl to lock a file, the Solaris client hangs. Normally, I would just let this go; however, Cadence (the VLSI CAD tool company) requires locks to work in order to use its tools. Therefore, I can't use FreeBSD as a fileserver in my environment. If I monitor the traffic on the line with ethereal, I see the request for the version 4 nlockmgr from the Solaris client to the FreeBSD server. I see the FreeBSD server respond with the correct version and port. However, after this, I start seeing a bunch of SYN/RST packets being thrown around, and I never see a lock request initiated from the Solaris client. Who is sending the RST's? (= the connection you are attempting to use does not exist) Who is sending the SYN's? (= I am attempting to establis a new conneciton) This may be related to the secure initial sequence number generation algorithm FreeBSD uses; there have been several fixes that have backed this out in various branches. It may also be that your FreeBSD box is multihomes, and you are sending the response on an interface different that the one it was received on (and thus different than the IP address the client is expecting, so the client believes it's a spoof attempt). You should be able to fix this by setting up an explicit route on the FreeBSD box, and potentially the Sun box, depending on how arcane your network setup is. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Help wanted: loadable SMBFS
On Sun, 29 Jul 2001 22:18:51 +0200, Sheldon Hearn wrote: (kgdb) frame 11 #11 0xc01b806f in witness_destroy (lock=0xc1366d18) at /usr/src/sys/kern/subr_witness.c:395 395 STAILQ_REMOVE(all_locks, lock, lock_object, lo_list); I got a little help from some folks on IRC who helped me with a disassembly that confirms a null pointer dereference in the STAILQ_REMOVE(). So I started walking all_locks. It's a boring process. Isn't there a faster way to find out whether lock's address is the value of an lo_list-stqe_next member of any entry in all_locks before the list-terminating NULL? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
scsi controller causes sysinstall to freeze machine
Hi all, I have started running down why my machine won't boot off of a current CD when my new SCSI controller is installed. When my scsi controller is installed (with or without the SCSI-bus connected to the controller), `sysinstall' hangs at the deviceTry call at line 403 of `devices.c'. A power-cycle is then required. The SCSI controller is a adaptec 29160 (and it works great otherwise). Any thoughts/pointers? Kent To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI: Clock problems in -current
On Sat, 28 Jul 2001, Mike Smith wrote: You could also try building a kernel with CLK_CALIBRATION_LOOP defined and then booting with -v (without the timer disabled). This might be instructive (I don't know for certain that it'll calibrate the ACPI timer, since it may not have been probed yet). It won't. CLK_CALIBRATION_LOOP only iterates calibration of the i8254 and TSC timers relative to the RTC. None of the clock calibration stuff is very useful. All the clock frequencies depend on the temperature, so their values at boot time are only slightly more related to their values at run time than their values at a random time. Average values are probably better than boot time values. Understsood, however the current problem reports indicate an off-by-2x problem, which the calibration loops would deal with just fine. 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: none0@pci0:7:3: class=0x068000 card=0x chip=0x71138086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82371AB PIIX4 Power Management Controller' class= bridge subclass = PCI-unknown - which timecounter is in use on your system, eg: mass# sysctl kern.timecounter.hardware kern.timecounter.hardware: ACPI - whether you are seeing any *time went backwards console messages. Thanks. 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: quick informal survey: OpenSSH broken?
At 9:53 PM -0400 7/29/01, 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 difficult? [...] So let me know, ASAP, what problems you all are having with OpenSSH in -CURRENT, specifically in the FreeBSD-specific parts. I'm also not certain of KRB4 and KRB5 auth still both work properly, and need that verified. Thanks, everybody. I have a machine at home which I dual-boot between -current and -stable. I also have a MacOS 10 machine at home, which was running the version of openssh that Scott Anguish had made available for MacOS 10 (and which was newer than what Apple had put in 10.0.4). I have had some problems ssh-ing between the two machines when the freebsd machine is running -current, but not when it is running -stable. As luck would have it, I just upgraded my MacOS 10 system at home so it has a newer version of openssh from apple, just about six hours ago. So, I don't know if that's still a problem. I also don't know for sure if the problem was with Scott's version for MacOS 10, or with the version in freebsd-current. I will do some tests at home tomorrow morning, and let you know how it works out. I am not using KRB4 or KRB5, both machines are just standalone setups. -- 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: HEADS UP: new libmp imported
On Sun, Jul 29, 2001 at 02:06:58AM -0700, Dima Dorfman wrote: I've imported the libmp-in-terms-of-OpenSSL library and connected it to the build. I've also disconnected libgmp and friends from the build, but have not `cvs rm`'d it yet. Assuming no problems turn up, I plan to do that in two or three days. The only program that use 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 from the openssl code so it's available without the crypto source code 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. Kris PGP signature
Re: HEADS UP: new libmp imported
Kris Kennaway [EMAIL PROTECTED] writes: On Sun, Jul 29, 2001 at 02:06:58AM -0700, Dima Dorfman wrote: I've imported the libmp-in-terms-of-OpenSSL library and connected it to the build. I've also disconnected libgmp and friends from the build, but have not `cvs rm`'d it yet. Assuming no problems turn up, I plan to do that in two or three days. The only program that use 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. I tried creating a libbignum by only compiling stuff from openssl/bn, and it didn't work very well. If you can get it to work, so much the better. That said, right now everything that uses libmp could be considered `crypto' code, anyway, so it may just be better to classify it as such as not install it in the NO_CRYPTO case (is there such a knob, anyway?). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: new libmp imported
I think I might have missed part of this thread so forgive me if this has already been brought up. We need to get a couple of package builds under our belts before this gets MFCd. I seem to recall there were a couple of ports that expected libgmp to be around. If so, we'll need to weed those out and either get them to use libmp if possible or provide libgmp as a port. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: new libmp imported
On Sun, Jul 29, 2001 at 06:38:36PM -0500, Steve Price wrote: I think I might have missed part of this thread so forgive me if this has already been brought up. We need to get a couple of package builds under our belts before this gets MFCd. I seem to recall there were a couple of ports that expected libgmp to be around. If so, we'll need to weed those out and either get them to use libmp if possible or provide libgmp as a port. Yep; I dont think anyone is talking about MFCing this in the near future. libgmp3 is already a port. Kris PGP signature
