Re: PS/2 mouse (psm0) is not detected with recent -current
I tried to upgrade my -current system today (I hadn't upgraded for a couple of weeks before this), and my PS/2 mouse went undetected. [...] and here's my verbose dmesg from a boot with today's sources: I notice that my atkbdc gets allocated as: atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 Yes, I know we get this output on some systems... which Kazutaka YOKOTA suggested in a different thread might indicate some weirdness. Any suggestions? I tried setting acpi_load=NO at boot,but the acpi module gets loaded anyway. Um, you should have typed unset acpi_load at the loader prompt to disable the acpi module... Please do unset acpi_load boot -v at the loader prompt and send me dmesg's output. Thank you, Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PS/2 mouse (psm0) is not detected with recent -current
On Fri, Sep 21, 2001 at 03:00:08PM -0400, Viren R.Shah wrote: atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 ^ Same here (Asus CUBX mobo): atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 Would you do the following and send me dmesg's output in each case? 1. Start the kernel with the acpi module enabled; just type boot -v at the loader prompt. 2. Reboot the system. This time disable the acpi module by unset acpi_load boot -v Thank you, Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Panic with recursed on non-recursive lock
Hi, I got following panic with recent -current (src-cur.4972.gz): recursed on non-recursive lock (sleep mutex) process lock @ ../../../i386/i386/trap.c:807 first acquired @ ../../../kern/subr_trap.c:100 panic: recurse syncing disks... panic: bremfree: bp 0xc3bbd5ec not locked System rebooted automatically, so I couldn't get any traces... :-( Has anybody seen this before? Thank you, haro =-- _ _Munehiro (haro) Matsuda -|- /_\ |_|_| Business Incubation Dept., Kubota Corp. /|\ |_| |_|_| 1-3 Nihonbashi-Muromachi 3-Chome Chuo-ku Tokyo 103-8310, Japan Tel: +81-3-3245-3318 Fax: +81-3-3245-3315 Email: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic with recursed on non-recursive lock
On 23 Sep, Munehiro Matsuda wrote: Hi, I got following panic with recent -current (src-cur.4972.gz): recursed on non-recursive lock (sleep mutex) process lock @ ../../../i386/i386/trap.c:807 first acquired @ ../../../kern/subr_trap.c:100 panic: recurse syncing disks... panic: bremfree: bp 0xc3bbd5ec not locked System rebooted automatically, so I couldn't get any traces... :-( Has anybody seen this before? Sort of (-current archive), at least the bremfree part: - Message-ID: [EMAIL PROTECTED] - Message-ID: [EMAIL PROTECTED] Bye, Alexander. -- The three Rs of Microsoft support: Retry, Reboot, Reinstall. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic on mount
Hello, After compiling a new kernel, installing it, when my laptop tries to mount its drive, it panics with this message: panic: lock (sleep mutex) vnode interlock not locked @ ../../../kern/vfs_default.c:460 which is: if (ap-a_flags LK_INTERLOCK) mtx_unlock(ap-a_vp-v_interlock); within the function vop_nolock. Thanks, Evan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic with recursed on non-recursive lock
Hi all, Here's another one from src-cur.4972.gz. It's repeatable. --- # ps -ae lock order reversal 1st 0xc7fe4d08 process lock @ ../../../kern/kern_proc.c:215 2nd 0xc03e6620 Giant @ ../../../kern/subr_trap.c:98 exclusive (sleep mutex) process lock (0xc7fe4d08) locked @ ../../../kern/kern_proc.c:215 panic: system call open returning with mutex(s) held Debugger(panic) Stopped at Debugger+0x44: pushl%ebx db t Debugger(c0322ffb) at Debugger+0x44 panic(c0345de0,c0327489,bfbfe574,10,bfb0) at panic+0x70 syscall(2f,2f,2f,bfb0,10) at syscall+0x602 syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (1, FreeBSD ELF, sys_exit), eip = 0x804f404, esp = 0xbfbfe538, ebp = 0xbfbe974 --- db --- Also, newest kernel (from src-cur.4973.gz) panics on boot. --- Mounting root from ufs:/dev/ad0s2a panic: lock (sleep mutex) vnode interlock not locked @ ../../../kern/vfs_default.c:460 Debugger(panic) Stopped at Debugger+0x44: pushl%ebx db t Debugger(c0321e3b) at Debugger+0x44 panic(c0324e00,c0320e60,c0328ffc,c0328990,1cc) at panic+0x70 witness_unlock(c85e3f2c,8,c0328980,1cc,c85e3f2c,1,c0320e77,f6) at witness_unlock+0x1d0 _mtx_unlock_flags(c85e3f2c,0,c0328980,1cc,c04d0bd0) at _mtx_unlock_flags+0x59 vop_nolock(c04d0be8,c04d0bf8,c021fd56,c04d0be8,c04d0d4c) at vop_nolock+0x24 vop_defaultop(c04d0be8) at vop_defaultop+0x15 vn_lock(c85e3ec0,20002,c03e01e4,c04d0d4c,c1405780) at vn_lock+0xca ffs_mountfs(c85e3ec0,c1406200,c03e01e4,c0388140,c04d0d4c) at ffs_mountfs+0x7e ffs_mount(c1406200,0,0,0,c03e01e4) at ffs_mount+0x67 vfs_mountroot_try(c04ad52d,c032858c) at vfs_mountroot_try+0x14e vfs_mountroot(0,4cdc00,4cd000,0,c012881c) at vfs_mountroot+0x5a mi_startup() at mi_startup+0x90 begin() at begin+0x43 db --- Hope this helps, Haro =-- _ _Munehiro (haro) Matsuda -|- /_\ |_|_| Business Incubation Dept., Kubota Corp. /|\ |_| |_|_| 1-3 Nihonbashi-Muromachi 3-Chome Chuo-ku Tokyo 103-8310, Japan Tel: +81-3-3245-3318 Fax: +81-3-3245-3315 Email: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on mount
After compiling a new kernel, installing it, when my laptop tries to mount its drive, it panics with this message: panic: lock (sleep mutex) vnode interlock not locked @ ../../../kern/vfs_default.c:460 which is: if (ap-a_flags LK_INTERLOCK) mtx_unlock(ap-a_vp-v_interlock); I get exactly the same thing. Manual bactrace is: panic witness_unlock _mtx_unlock_flags vop_nolock vop_defaultop vn_lock ffs_mountfs ffs_mount vfs_mountroot_try vfs_mountroot mi_startup begin M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Suggestion: move rc.devfs invocation up in rc
My rc.devfs has: ln -fs /dev/psm0 /dev/mouse My rc.conf has: moused_port=/dev/mouse Unfortunately, this doesn't work because rc.syscons (which starts moused) is run before rc.devfs, i.e. before the symlink is created. Could rc.devfs not be moved up in rc so this does work? Why? I'd like to be able to refer to my logical mouse device as ``/dev/mouse'' (interface) and define the actual device (implementation) in one place only, for obvious reasons. Thanks, -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on mount
Mark Murray wrote: After compiling a new kernel, installing it, when my laptop tries to mount its drive, it panics with this message: panic: lock (sleep mutex) vnode interlock not locked @ ../../../kern/vfs_default.c:460 which is: if (ap-a_flags LK_INTERLOCK) mtx_unlock(ap-a_vp-v_interlock); I get exactly the same thing. Manual bactrace is: panic witness_unlock _mtx_unlock_flags vop_nolock vop_defaultop vn_lock ffs_mountfs ffs_mount vfs_mountroot_try vfs_mountroot mi_startup begin Eww. I was looking at this as an Alpha SMP bug. I was just about to compile an x86 kernel with the same debug options in case it was a generic problem. :-( Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: stdin/out/err changes kill world
On 2001-Sep-21 10:45:42 +0300, Ruslan Ermilov [EMAIL PROTECTED] wrote:
Also, this error may only be caused if:
1. The previous ``buildworld'' installed new headers in
${WORLDTMP}/usr/include.
2. The next ``buildworld'' was run with -DNOCLEAN.
(Only in this case ${WORLDTMP}/usr/include will be
non-empty.)
I have an old -CURRENT system[1] that can't do a buildworld any more,
even with the latest bsd.{prog,lib}.mk changes (1.101 and 1.98). I
delete /usr/obj before the buildworld, which writes off the above
scenarios. Is anyone else seeing problems?
[1] From January. I know it's old but I don't seem to have found the
time to update lately (and I didn't realise it has been that long).
Peter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: stdin/out/err changes kill world
In message [EMAIL PROTECTED] Peter Jeremy writes:
: I have an old -CURRENT system[1] that can't do a buildworld any more,
: even with the latest bsd.{prog,lib}.mk changes (1.101 and 1.98). I
: delete /usr/obj before the buildworld, which writes off the above
: scenarios. Is anyone else seeing problems?
:
: [1] From January. I know it's old but I don't seem to have found the
: time to update lately (and I didn't realise it has been that long).
Did you try the UPDATING workaround?
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
libutil.so.3: Undefined symbol __stdoutp
Hi there, anyone out there has this problem? a new made world and kernel from last night (09/22) cvsup, and is unable to cvsup again tonight (09/23). [donny@sys]/usr/src cvsup /usr/libexec/ld-elf.so.1: /usr/lib/libutil.so.3: Undefined symbol __stdoutp 5.0-c, with cvsup 16.1e. -- // Donny To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libutil.so.3: Undefined symbol __stdoutp
Donny Lee wrote: Hi there, anyone out there has this problem? a new made world and kernel from last night (09/22) cvsup, and is unable to cvsup again tonight (09/23). [donny@sys]/usr/src cvsup /usr/libexec/ld-elf.so.1: /usr/lib/libutil.so.3: Undefined symbol __stdoutp 5.0-c, with cvsup 16.1e. Read UPDATING. You have an old libc.so.4. You can have it updated automatically by adding COMPAT4X=yes into /etc/make.conf. For now: # echo COMPAT4X=yes /etc/make.conf # cd /usr/src/lib/compat # make obj # make # make install and you should be set. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libutil.so.3: Undefined symbol __stdoutp
On Mon, Sep 24, 2001 at 01:06:47PM +0800, Donny Lee wrote: Hi there, anyone out there has this problem? Are you even reading this list? Kris PGP signature
Re: Seen this lock order reversal?
On Sun, Sep 23, 2001 at 08:49:29PM +0200, Wilko Bulte wrote: Is there any reason to assume that specifying CPUTYPE ev56 has any influence on the lock order reversal? No that I know of. I used to run a -CURRENT DS20 with CPUTYPE=ev56. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seen this lock order reversal?
On Thu, Sep 20, 2001 at 07:40:52PM +0200, Wilko Bulte wrote: On Wed, Sep 19, 2001 at 01:32:28PM -0700, John Baldwin wrote: On 19-Sep-01 Wilko Bulte wrote: On Tue, Sep 18, 2001 at 03:01:25PM -0700, John Baldwin wrote: ... p_flag to p_sflag which changed its locking semantics.) Another one, on a -current from yesterday, on -alpha: lock order reversal 1st 0xfc7fcef0 clk @ ../../../alpha/alpha/clock.c:702 2nd 0xfc7f65d8 callout @ ../../../kern/kern_timeout.c:225 ds10# Hmm, ok, that one is new and is a problem. Can you turn on WITNESS_DDB (it's available as the debug.witness_ddb sysctl and loader variableas well) and then get me a traceback in ddb? I built a GENERIC with WITNESS_DDB. Sofar (of course... :-/ ) no reproduction of the problem. I'm running buildworlds, any other good suggestions to help trigger it are welcome Bah. I cannot reproduce this on my DS10. Is there any reason to assume that specifying CPUTYPE ev56 has any influence on the lock order reversal? By default world is built with ev4, but I have gone to ev56 now. Rumor has it that results in 'less buggy' code. Wilko -- | / o / /_ _ email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
