Re: APM not working on Dell Latitude D600
* Andreas Klemm [EMAIL PROTECTED] [2003-11-03 17:00]: Is there somebody interested to get ssh access on my new DELL Laptop to find out why apm doesn't work ? Did you - upgrade to the latest BIOS provided by DELL - apply the DSDT patch available from http://sandcat.nl/~stijn/freebsd/dell.php ??? Regards -Thorsten -- You're not out of shape... because technically a circle is a shape. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic during shutdown in lockmgr()
Hi, with a -CURRENT kernel built today I am consistently getting a panic during shutdown. Unfortunately a debug kernel refuses to do a core dump, so I only have a naked stack trace: panic: lockmgr: thread 0xc1918720, not exclusive lock holder 0xc06b5660 unlocking #0 0xc04fc40a in doadump () #1 0xc04fcaac in boot () #2 0xc04fce03 in poweroff_wait () #3 0xc04eff3c in lockmgr () #4 0xc054b2b2 in vop_stdunlock () #5 0xc054b15a in vop_defaultop () #6 0xc05e2f73 in ufs_vnoperate () #7 0xc0555cd8 in vput () #8 0xc05d3a86 in ffs_sync () #9 0xc0558a5d in sync () #10 0xc04fc5a4 in boot () #11 0xc04fc1bf in reboot () #12 0xc0632372 in syscall () #13 0xc0622fdd in Xint0x80_syscall () This panic occurs when I shut the machine down with all filesystems mounted. I can avoid it when I go to single user mode and umount all filesystems first. Please let me know if I can provide further information. Regards -Thorsten -- The moon may be smaller than Earth, but it's further away. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI trouble with EPIA-M
* Nate Lawson [EMAIL PROTECTED] [2003-10-27 22:13]: ... What you probably want to do now is do tr pid for the pids below to see what they're blocked on. Likely culprits are 24 (since it's on irq 7), 23 (acpi), 29, and 25. The most likely one is 24 because irq 7 is normally edge triggered/legacy and that means it cannot be shared. But in your config, it is shared. So my guess is that acpi is routing interrupts differently than $PIR mode. OK, here we go: pid 24 ([IWAIT] irq7: fwohci0 uhci1) pid 35 ([IWAIT] irq0: ppc0) pid 32 ([IWAIT] irq15: ata1) pid 31 ([IWAIT] irq14: ata0) stack trace: sched_switch() mi_switch() ithread_loop() fork_exit() fork_trampoline() pid 23 (new [IWAIT] irq9: acpi0) pid 29 (new [IWAIT] irq10: uhci2 pcm0) pid 25 (new [IWAIT] irq11: vr0 uhci0) stack trace (yes, this is just one line): fork_trampoline() Hope that helps... (though I fear it does not) Regards -Thorsten -- There are 10 kinds of people in the world, those who understand binary and those who don't. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI trouble with EPIA-M
* Nate Lawson [EMAIL PROTECTED] [2003-10-24 22:57]: Type tr at the DDB prompt to get a trace of what is hanging. At the time of the hang a 'ps' in DDB shows two screenful's of processes. Doing a simple 'tr' just gives the backtrace of how I got into DDB which - I presume - is not relevant to this problem. I have no serial console, so I have to copy things by hand. A ps shows (only selected columns): pid ... flag stat ... 38204 new [IWAIT] irq8: rtc 37204 new [IWAIT] irq4: sio0 36204 new [IWAIT] swi0: tty:sio 35204 [IWAIT] irq0: ppc0 34204 new [IWAIT] irq12: psm0 33204 [CPU0] irq1: atkbd0 32204 [IWAIT] irq15: ata1 31204 [IWAIT] irq14: ata0 30204 [SLP]usbdly 0x... usb2 29204 new [IWAIT] irq10: uhci2 pcm0 28204 [SLP] usbdly 0x... usb1 27204 [SLP] usbtsk 0x... usbtask 26204 [SLP] usbdly 0q... usb0 25204 new [IWAIT] irq11: vr0 uhci0 24204 [IWAIT] irq7: fwohci0 uhci1 8204 [SLP]actask 0x... acpi_task2 7204 [SLP]actask 0x... acpi_task1 6204 [SLP]actask 0x... acpi_task0 23204 new [IWAIT] irq9: acpi0 22204 new [IWAIT] irq13: 21204 new [IWAIT] swi3: cambio 20204 new [IWAIT] swi2: camnet 19204 new [IWAIT] swi5:+ 5204 [SLP]tqthr 0x... taskqueue 18204 [IWAIT] swi7: acpitaskq 17204 [IWAIT] swi6:+ 16204 [IWAIT] swi6: task queue 15204 [SLP]- 0x... random 4204 [SLP]- 0x... g_down 3204 [SLP]- 0x... g_up 2204 [SLP]- 0x... g_event 14204 new [IWAIT] swi5: vm 1320c new [IWAIT] swi8: tty:sio clock 12204 new [IWAIT] swi1: net 1120c [Can run] idle 1200 new [INACTIVE] swapper 10204 [CV]ktrace 0x... ktrace 0200 [SLP]conifhk 0x... swapper This state seems to be pretty reproducible. Any idea what is wrong? Regards -Thorsten -- People who claim they don't let little things bother them have never slept in a room with a single mosquito. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ACPI trouble with EPIA-M
Hi everybody, I have a VIA EPIA-M 1 board which works mostly when I disable ACPI in the bios. Unfortunately the parallel port is controlled by some Super-IO chip and is not recognized during boot. The same holds true for serial ports and the floppy controller. When I enable ACPI in the bios the machine boots normally and recognizes the parallel port BUT stops after displaying the hd/cdrom identification , at the point where it would normally start init (before the Mounting root from ... is displayed). At this point it just stops. I can break into DDB but nothing else... This machine is running a custom kernel based on GENERIC with several device drivers removed and debugging stuff disabled (DDB is still there), cvsupped Oct 17. There are no ACPI error messages displayed during the boot process. I will happily provide more information on request. Please help me to get this parallel port going as I want to hook up my printer there. Thanks! Regards -Thorsten -- If you understand what you're doing, you're not learning anything. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with geom_bde
* Poul-Henning Kamp [EMAIL PROTECTED]: Did you call gbde detach before the umount ? No. You need to unmount first. Yes, that's what I tried. I then get the fsync: giving up on dirty message. When I shut down the box, it tries to sync the dirty buffers and finally says giving up on 2 buffers, leaving all my filesystems dirty, and corrupted data on the gbde device (lots of zero bytes in files). Regards -Thorsten __ Bestes Testergebnis: Stiftung Warentest Doppelsieg fur WEB.DE FreeMail und WEB.DE Club. Nur fuer unsere Nutzer! http://f.web.de/?mc=021182 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with geom_bde
* Poul-Henning Kamp [EMAIL PROTECTED] [2003-09-30 10:54]: Did you call gbde detach before the umount ? You need to unmount first. After investigating further I think I have found the reason for the problem. When I created the disklabel for the partition I was lazy and entered a size of 200 blocks for the slice. I just tried to reproduce the problem and re-created the slice with a size of 1024M (which is 2097152 blocks) and the problem seems to have disappeared - at least I cannot reproduce it anymore. So now I wonder if there is any magic constant which the slice size needs to be a multiple of...? Regards -Thorsten -- There are 10 kinds of people in the world, those who understand binary and those who don't. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Problems with geom_bde
Hi, inspired by the recent posting of the gbde tutorial I went out and set up an encrypted partition using geom_bde on my laptop. When trying to umount this partition the umount fails with: # umount /crypto umount: unmount of /crypto failed: Resource temporarily unavailable and the following message gets logged: fsync: giving up on dirty: 0xc456ec8c: tag devfs, type VCHR, usecount 5140, writecount 0, refcount 93, flags (VV_OBJBUF), lock type devfs: EXCL (count 1) by thread 0xc4240130 dev ad0s3a.bde This is with a fairly recent kernel, cvsupped a few hours ago: # uname -a FreeBSD tybalt 5.1-CURRENT FreeBSD 5.1-CURRENT #26: Mon Sep 29 22:18:26 CEST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/TYBALT i386 The kernel config is a standard GENERIC with some device drivers removed. geom_bde was loaded as a module. Please let me know if I can provide further information. Regards -Thorsten -- You know you've landed gear-up when it takes full power to taxi. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to newfs/fsck partition on -current because of write failed.
* Nicolai Petri [EMAIL PROTECTED] [2003-09-21 12:23]: But now even newfs gives me Write failed. This seems a bit odd because i can easily do a dd if=/dev/zero of=/dev/ad0s2d and clear out the label. Any hints ? I'm thinking geom and/or blocksize problems. But that's just a guess. There was a small window in which the -CURRENT kernel was broken. This happened just around September 14th, so I suggest you either upgrade your kernel or use a kernel built before September 14th. Regards -Thorsten -- Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mdmfs: newfs exited with error code 36
* Deiter Alexandr Valerievich [EMAIL PROTECTED] [2003-09-14 22:10]: mdmfs: newfs exited with error code 36 This error seems to be generic, I see it on i386 too. I usually mount /tmp with the following entry from fstab: md /tmp mfs rw,-s250m 2 0 This gives the newfs error mentioned above. Doing the steps by hand I get: # mdconfig -a -t swap -s 256m md4 # newfs /dev/md4 /dev/md4: 256.0MB (524288 sectors) block size 16384, fragment size 4096 using 4 cylinder groups of 64.02MB, 4097 blks, 4160 inodes. super-block backups (for fsck -b #) at: 160, 131264, 262368, 393472 newfs: wtfs: 4096 bytes at sector 192: Bad address Regards -Thorsten -- Williams and Holland's Law: If enough data is collected, anything may be proven by statistical methods. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bikeshed
* Liew Jay Sern [EMAIL PROTECTED] [2003-09-13 17:07]: I missed BSDcon 03, what's a bikeshed got to do with anything, anyway? (besides bikes). See the Handbook here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING Regards -Thorsten -- You can't carve your way to success without cutting remarks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: clock works slowly when I change CPU speed
* Bob Fleck [EMAIL PROTECTED] [2003-08-15 22:46]: So, what should be done to restore the proper behavior of the timekeeping on these systems? $ dmesg | grep counter Timecounter i8254 frequency 1193182 Hz Timecounter ACPI-fast frequency 3579545 Hz Timecounter TSC frequency 1595302164 Hz $ sysctl -w kern.timecounter.hardware=i8254 Fixes the problem for me. I suspect you should set this in /etc/sysctl.conf to enable it permanently. Regards -Thorsten -- One good reason why computers can do more work than people is that they never have to stop and answer the phone. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
Hi, after upgrading the Kernel I found that the glx-related programs of the NVidia graphics driver die in calls to sysarch. Here is a truss fragment of a 'glxinfo' run: sysarch(0x1,0xbfbffb14) ERR#22 'Invalid argument' SIGNAL 10 SIGNAL 10 Process stopped because of: 16 process exit, rval = 138 In the sysarch call the first argument indicats - according to machine/sysarch.h - a call of I386_SET_LDT. For 4.X it was necessary to enable USER_LDT in the kernel config. This option is no longer present in the kernel config (the NVidia driver worked without before my cvs update...). Best regards -Thorsten -- For every complex problem, there is a solution that is simple, neat, and wrong. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
* Julian Elischer [EMAIL PROTECTED] [2003-08-01 23:44]: can you compile your sys_machdep.c with the option -DDEBUG? I noticed there is a debug printf that is enabled byu this and may show what request the NVIDIA people are making. This is what gets logged: Aug 1 23:42:43 tybalt kernel: i386_set_ldt: start=6 num=1 descs=0xbfbff724 I will test wether the problem still occurs with version 1.84 of sys_machdep.c and let you know. Regards -Thorsten -- Those who in quarrels interpose, must often wipe a bloody nose. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
* Thorsten Greiner [EMAIL PROTECTED] [2003-08-01 23:47]: I will test wether the problem still occurs with version 1.84 of sys_machdep.c and let you know. Yup, reverting to 1.84 unbreaks this for me. Looking at the changes made it appears to me that the check if (uap-start NLDT || uap-num = 0) return (EINVAL);i causes this, because NLDT is 6 and the NVidia stuff passes uap-start == 6 to this call. Regards -Thorsten -- Adding manpower to a late software project makes it later ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
* Daniel Eischen [EMAIL PROTECTED] [2003-08-02 00:06]: I think the bug was in the old code allowing this to happen... Well, than someone should tell that to NVidia. Their driver is closed source and comes without user servicable parts. Regards -Thorsten -- There are 10 kinds of people in the world, those who understand binary and those who don't. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
no subject
Andreas wrote: [EMAIL PROTECTED] ~ vim Vim: Caught deadly signal BUS Vim: Finished. Bus error (core dumped) You can work around this by unsetting SESSION_MANAGER in your environment. I have no idea what the root cause is... Regards -Thorsten Nur bei WEB.DE Testsieger FreeMail testen und damit 1 qm Regenwald schuetzen. Jetzt anmelden und mithelfen! http://user.web.de/Regenwald ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Vim: Caught deadly signal BUS (after -current update with newgcc)
You can work around this by unsetting SESSION_MANAGER in your environment. I have no idea what the root cause is... Where can I get rid of this variable ? I see no easy way. Currently I use gvim as default text editor within KDE environment ... In an xterm or such I could disable it, but how for KDE ?? As far as I understand it, this variable is set by the session management of the respective desktop (KDE in your case, GNOME in mine). Maybe you can workaround the problem by using a small shell script which unsets SESSION_MANAGER and than calls gvim? Regards -Thorsten Nur bei WEB.DE Testsieger FreeMail testen und damit 1 qm Regenwald schuetzen. Jetzt anmelden und mithelfen! http://user.web.de/Regenwald ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ACPI Regression in -CURRENT?
Hi everyone, some time ago several people (including me) reported ACPI related problems on various Dell laptops resulting in error messages of the form ACPI-0293: *** Warning: Buffer created with zero length in AML During the 5.1 release process these problems have been temporarily fixed. At least I have a 5.1-BETA kernel built on June 1st which does not exhibit these problems. Today I tried a 5.1-CURRENT kernel and found that these problems have reappeared. This made me wonder wether this is an intended behaviour or a regression. Best regards -Thorsten __ UNICEF bittet um Spenden für die Kinder im Irak! Hier online an UNICEF spenden: https://spenden.web.de/unicef/special/?mc=021101 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
'make buildworld' breakage in kdump
Hi, a recently cvsupped copy of the RELENG_5_0 branch breaks in usr.bin/kdump: === usr.bin/kdump sh /usr/src/usr.bin/kdump/mkioctls /usr/obj/usr/src/i386/usr/include ioctl.c /usr/src/usr.bin/kdump/mkioctls: awk: Argument list too long /usr/src/usr.bin/kdump/mkioctls: awk: Argument list too long *** Error code 2 The environment was: tybalt# echo $PATH /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/root/bin tybalt# which xargs /usr/bin/xargs tybalt# It seems that a manual 'make; make install; make clean' for xargs fixed this - I am just redoing a 'make buildworld'. Regards -Thorsten To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Missing MFC of geom_slice.c ?
Hi, I just tried to compile 5.0-RC2 from using a recently cvsupped copy using the RELENG_5_0 tag and found that src/sys/geom/geom_slice.c does not compile. It seems that the version of geom_slice.h which was tagged as RELENG_5_0 is out of sync with the .c file. Getting the HEAD revision of geom_slice.c fixed this problem. Regards -Thorsten __ Verleihen Sie Ihren E-Mails eine personliche Note mit WEB.DE FreeMail http://freemail.web.de/features/?mc=021139 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
USB problems
Hi, I cannot get the USB interface to work on my ASUS L7300G Laptop with -CURRENT. I have attached an excerpt of the message file and the section of the config file dealing with USB. Any hints? messages: Jan 23 10:01:22 tybalt /boot/kernel/kernel: uhci0: Intel 82443MX USB controller port 0x1c00-0x1c1f irq 11 at device 7.2 on pci0 Jan 23 10:01:22 tybalt /boot/kernel/kernel: uhci_run: setting run=0 Jan 23 10:01:22 tybalt /boot/kernel/kernel: uhci_run: done cmd=0x0 sts=0x20 Jan 23 10:01:22 tybalt /boot/kernel/kernel: uhci_run: setting run=1 Jan 23 10:01:22 tybalt /boot/kernel/kernel: uhci_run: done cmd=0x81 sts=0x0 Jan 23 10:01:22 tybalt /boot/kernel/kernel: usb0: Intel 82443MX USB controller on uhci0 Jan 23 10:01:22 tybalt /boot/kernel/kernel: usb0: USB revision 1.0 Jan 23 10:01:22 tybalt /boot/kernel/kernel: uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Jan 23 10:01:22 tybalt /boot/kernel/kernel: uhub0: 2 ports with 2 removable, self powered Jan 23 10:01:22 tybalt /boot/kernel/kernel: uhci_waitintr: timeout Jan 23 10:01:22 tybalt /boot/kernel/kernel: usbd_transfer_cb: short transfer 08 Jan 23 10:01:22 tybalt /boot/kernel/kernel: uhci_waitintr: timeout Jan 23 10:01:22 tybalt /boot/kernel/kernel: usbd_transfer_cb: short transfer 08 Jan 23 10:01:22 tybalt /boot/kernel/kernel: uhci_waitintr: timeout Jan 23 10:01:22 tybalt /boot/kernel/kernel: usbd_transfer_cb: short transfer 08 Jan 23 10:01:22 tybalt /boot/kernel/kernel: usbd_new_device: addr=2, getting first desc failed Jan 23 10:01:22 tybalt /boot/kernel/kernel: uhub_explore: usb_new_device failed, error=SHORT_XFER Jan 23 10:01:22 tybalt /boot/kernel/kernel: uhub0: device problem, disabling port 1 config: # USB support device uhci# UHCI PCI-USB interface device usb # USB Bus (required) device ugen# Generic device uhid# "Human Interface Devices" device ums # Mouse options UHCI_DEBUG options USB_DEBUG options UGEN_DEBUG options UHID_DEBUG options UHUB_DEBUG options UMS_DEBUG Thanks -Thorsten To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
