Re: Kernel probe order issues
on 02/02/2010 08:36 Peter Jeremy said the following: > On 2010-Feb-01 11:37:33 +0200, Andriy Gapon wrote: >>> This strikes me as undesirable. Is there some way to bump up the >>> probe/attach priority of console input devices to ensure that they >>> exist before the kernel tries to read input? >> It seems to be a problem with either your keyboard or your USB controller. >> USB keyboard can be discovered much earlier than mountroot if the hardware is >> ready. No magical software priority bump can help here. > > I've tried a couple of different USB ports (controllers) with no > change in behaviour. I'll try another keyboard if I can find one. It > _does_ work as expected on 7.x so this is a regression. Unfortunately you keep being low on hardware details. For me going from stable/7 to stable/8 resulted in an improvement of the opposite nature on two different systems: now my keyboard is detected before disks are detected, whereas previously it was detected some time later. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Kernel probe order issues
On 2010-Feb-01 11:37:33 +0200, Andriy Gapon wrote: >> This strikes me as undesirable. Is there some way to bump up the >> probe/attach priority of console input devices to ensure that they >> exist before the kernel tries to read input? > >It seems to be a problem with either your keyboard or your USB controller. >USB keyboard can be discovered much earlier than mountroot if the hardware is >ready. No magical software priority bump can help here. I've tried a couple of different USB ports (controllers) with no change in behaviour. I'll try another keyboard if I can find one. It _does_ work as expected on 7.x so this is a regression. -- Peter Jeremy pgpniZsRcRtHw.pgp Description: PGP signature
Kernel Panic on Freebsd 8-RELEASE
Hi all, A recent HLDS update is causing my machine to kernel panic. Here is a copy of the kernel dump: #0 sched_switch (td=0x80be7600, newtd=0xff00014f6720, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1864 1864cpuid = PCPU_GET(cpuid); (kgdb) (kgdb) bt #0 sched_switch (td=0x80be7600, newtd=0xff00014f6720, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1864 #1 0x805879bf in mi_switch (flags=260, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:449 #2 0x805b94a2 in sleepq_timedwait (wchan=0x80be71a0, pri=68) at /usr/src/sys/kern/subr_sleepqueue.c:623 #3 0x80587f38 in _sleep (ident=0x80be71a0, lock=0x0, priority=Variable "priority" is not available. ) at /usr/src/sys/kern/kern_synch.c:230 #4 0x807c7faa in scheduler (dummy=Variable "dummy" is not available. ) at /usr/src/sys/vm/vm_glue.c:779 #5 0x8053a859 in mi_startup () at /usr/src/sys/kern/init_main.c:251 #6 0x8018a33c in btext () at /usr/src/sys/amd64/amd64/locore.S:81 #7 0x00e74000 in ?? () #8 0x in ?? () #9 0x in ?? () #10 0x80c0c710 in sleepq_chains () #11 0x80be7600 in proc0 () #12 0x80e52be0 in ?? () #13 0x80e52b98 in ?? () #14 0xff00014f6720 in ?? () #15 0x805a2bd8 in sched_switch (td=0x0, newtd=0x0, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1858 Previous frame inner to this frame (corrupt stack?) (kgdb) uname -a: FreeBSD dl0009.sjc02.denetron.net 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Thu Jan 28 05:36:57 UTC 2010 r...@dl0009.sjc02.denetron.net:/usr/obj/usr/src/sys/GENERIC amd64 The message displayed to the console: • Unread portion of the kernel message buffer: • panic: tdsignal(): invalid signal 0 • cpuid = 2 • Uptime: 6m52s • Physical memory: 4073 MB t_j in the ##freebsd channel on freenode asked me to do this so I'll include it incase it's some help: (kgdb) frame 0 #0 sched_switch (td=0x80be7600, newtd=0xff00014f6720, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1864 1864cpuid = PCPU_GET(cpuid); (kgdb) list 1859/* 1860 * We may return from cpu_switch on a different cpu. However, 1861 * we always return with td_lock pointing to the current cpu's 1862 * run queue lock. 1863 */ 1864cpuid = PCPU_GET(cpuid); 1865tdq = TDQ_CPU(cpuid); 1866lock_profile_obtain_lock_success( 1867&TDQ_LOCKPTR(tdq)->lock_object, 0, 0, __FILE__, __LINE__); 1868#ifdef HWPMC_HOOKS The crash is repeatable (occurs everytime for me). I also confirmed that another FreeBSD 8 machine I have ran into the same panic (also amd64). I'm guessing this is a bug of some kind, if there's more information I need to provide, just let me know. Thanks, Daniel
Re: terminfo missing?
On Mon, Feb 01, 2010 at 07:13:48PM +0100, Ivan Voras wrote: > This has bugged me on a couple of machines but I've always > attributed it to some misconfiguration of mine: running curses-like > programs under "screen" (i.e. in virtual screens) fails with > messages like "terminal entry not found". For example, "less" does > this, and "vim" complains with this: > > E558: Terminal entry not found in terminfo > 'screen' not known. Available builtin terminals are: > builtin_ansi > builtin_xterm > builtin_iris-ansi > builtin_dumb > defaulting to 'ansi' > > Looking at terminfo(5) it looks like terminfo should be located at > /usr/share/misc/terminfo/ but I have no such directory here. There > is a /usr/share/misc/termcap file. > > This machine is relatively fresh, only a source-based update was > performed from 8.0-R to 8.0-STABLE, so I don't think there is some > package that does this. > > Can someone enlight me about what is happening here? Don't let the message from vim fool you; it says "Terminal entry not found in terminfo", but what it's really trying to tell you is "not found in termcap". It'll say "terminfo" no matter what. FreeBSD uses termcap, not terminfo. The definition for the "screen" termcap entry is in /usr/share/misc/termcap, which is what /etc/termcap is symlinked to. You should also have a /usr/share/misc/termcap.db file. I've no issues using vim, sade, sysinstall, less, etc. under screen on RELENG_7 or RELENG_8 machines. This is with TERM=screen as well (no dotfiles or environment settings overriding it). Do you have some sort of library on your machine which is trumping the ones in /usr/lib? Relevant linking: /usr/local/bin/vim: libm.so.5 => /lib/libm.so.5 (0x30781000) libncurses.so.8 => /lib/libncurses.so.8 (0x308a) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x309ea000) libc.so.7 => /lib/libc.so.7 (0x30be3000) /usr/bin/less: libncurses.so.8 => /lib/libncurses.so.8 (0x3065e000) libc.so.7 => /lib/libc.so.7 (0x307a8000) -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
terminfo missing?
Hi, This has bugged me on a couple of machines but I've always attributed it to some misconfiguration of mine: running curses-like programs under "screen" (i.e. in virtual screens) fails with messages like "terminal entry not found". For example, "less" does this, and "vim" complains with this: E558: Terminal entry not found in terminfo 'screen' not known. Available builtin terminals are: builtin_ansi builtin_xterm builtin_iris-ansi builtin_dumb defaulting to 'ansi' Looking at terminfo(5) it looks like terminfo should be located at /usr/share/misc/terminfo/ but I have no such directory here. There is a /usr/share/misc/termcap file. This machine is relatively fresh, only a source-based update was performed from 8.0-R to 8.0-STABLE, so I don't think there is some package that does this. Can someone enlight me about what is happening here? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: uma_zalloc_arg complaining about non-sleepable locks
On Mon, 1 Feb 2010, John Baldwin wrote: I'd say that your patch works. John, are you okay with that patch? http://people.freebsd.org/~marius/fha_extract_info_realign2.diff It's intention is to: - Move nfs_realign() from the NFS client to the shared NFS code and remove the NFS server version in order to reduce code duplication. The shared version now uses a second parameter how, which is passed on to m_get(9) and m_getcl(9) as the server used M_WAIT while the client requires M_DONTWAIT, and replaces the the previously unused parameter hsiz. I don't think the client side can use M_WAIT/M_WAITOK if it wants to. (I believe that it was once called from the socket upcall and that was why M_DONTWAIT was used, but that isn't how it is called in the client now.) I mentioned this to dfr@ because I use a version shared between client and server for the experimental one that does M_WAIT, but he didn't think the regular client needed to be changed. Basically, I think the current code in the regular client can return ENOMEM for I/O system calls, which probably isn't what the app. expected. In the NFS client, you end up with this "do I wait forever?" or "do I return an error to an I/O system call which an app. doesn't expect" issue cropping up here and there. I don't know the correct answer to this, but tend to lean in the "wait forever" direction. - Change nfs_realign() to use nfsm_aligned() so as with other NFS code the alignment check isn't actually performed on platforms without strict alignment requirements for performance reasons because as the comment suggests only occasionally occurs with TCP. - Change fha_extract_info() to use nfs_realign() with M_NOWAIT rather than M_DONTWAIT because it's called with the RPC sp_lock held. Btw, from an historical perspective, this was originally added for the DEC PMAX port (MIPS R2000), which would trap whenever an unaligned ptr was used. Then, there was this involved chunk of MIPS assembly code that worked around the unaligned ptr access and the trap returned. Obviously this was a major performance hit and happened fairly frequently for NFS over ISO TP4. As you've seen, it happens infrequently enough over TCP (back then, I think it was only when the TCP window size ended up really small, although I'm way out of date on the TCP stack, so I have no idea now:-) that I'd only do the re-alignment on achitectures that will crash if it isn't done? I missed the beginning of this. Was there crashes occurring because the alignment wasn't being done or problems because the alignment wasn't working correctly? (I guess I'm trying to say that, if the arch works without nfs_realign(), then you might consider just not doing it for that arch. I suppose that isn't a good enough reason to not fix the function, though?;-) The only downside of the shared nfs_realign() are the combined SYSCTL counters but the fact we incremented them non-atomically so far I think already indicates that their intention only is a rough indication rather than exact values for client and server. I'll admit I don't see how NFSCLIENT and NFSSERVER can both be loaded as modules without the stuff in sys/nfs/nfs_common.c coming up multiply defined, but it seems to work, so... This all sounds good to me, but isn't M_NOWAIT == M_DONTWAIT? Hmm, reading the code more closely, it looks like fha_extract_info() was using M_WAIT rather than M_DONTWAIT previously. Also, I think you should be careful to use M_DONTWAIT instead of M_NOWAIT for mbufs, so I would fix that in fha_extract_info(). As noted above, I think the client can use M_WAIT safely. It was just a design choice to do otherwise. Have fun with it, rick ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: loading module sdhci causes panic
On Sunday 31 January 2010 07:33:19 pm Steven Friedrich wrote: > On Sunday 31 January 2010 05:57:14 pm Jeremy Chadwick wrote: > > On Sun, Jan 31, 2010 at 04:44:39PM -0500, Steven Friedrich wrote: > > > On Saturday 30 January 2010 08:56:06 am Bartosz Fabianowski wrote: > > > > > Can anyone verify that sdhci is compatible with FreeBSD 8? > > > > > > > > I loaded mmc, mmcsd, and sdhci when I first installed FreeBSD 8.0 > > > > without any problems. Since then, I have updated to -STABLE and put > > > > these three devices in my kernel configuration file. No problems > > > > either. It must be very recent breakage or some incompatibility with > > > > your particular hardware. > > > > > > > > - Bartosz > > > > > > When I add the three drivers to my kernel, I don't get a panic, but > > > when I insert an SD 1GB card, nothing happens. > > > > > > pciconf -lv reveals that the driver attached to my device: > > > > > > sdh...@pci0:11:0:4: class=0x080500 card=0x3082103c chip=0x8034104c > > > rev=0x00 hdr=0x00 > > > vendor = 'Texas Instruments (TI)' > > > device = 'SDA Standard Compliant SD Host Controller (10981734)' > > > class = base peripheral > > > subclass = SD host controller > > > > > > I verified that this SD card is recognized by Windows XP. > > > > > > When I plug in a card, should some message appear on the console? Will > > > it auto-mount? > > > > Can you please post your entire kernel configuration file (specifically > > the one which includes the above 3 drivers in it)? > > # > # LAPTOP -- Laptop kernel configuration file for FreeBSD/i386 > # > > ident LAPTOP > machine i386 > cpu I586_CPU > cpu I686_CPU > > # To statically compile in device wiring instead of /boot/device.hints > #hints"LAPTOP.hints" # Default places to look for > devices. > > makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols > > # hopefully, cure the shutdown anomaly > options PRINTF_BUFR_SIZE=128 > > options INCLUDE_CONFIG_FILE > > options SCHED_ULE # ULE scheduler > #options SCHED_4BSD # 4BSD scheduler > options PREEMPTION # Enable kernel thread preemption > # IPI_PREEMPTION instructs the kernel to preempt threads running on other > # CPUS if needed. Relies on the PREEMPTION option > options IPI_PREEMPTION > options INET# InterNETworking > options INET6 # IPv6 communications protocols > options SCTP# Stream Control Transmission Protocol > options FFS # Berkeley Fast Filesystem > options SOFTUPDATES # Enable FFS soft updates support > options UFS_ACL # Support for access control lists > options UFS_DIRHASH # Improve performance on big directories > options UFS_GJOURNAL# Enable gjournal-based UFS journaling > #options MD_ROOT # MD is a potential root device > options PROCFS # Process filesystem (requires PSEUDOFS) > options PSEUDOFS# Pseudo-filesystem framework > #options GEOM_GPT# GUID Partition Tables. > # The options COMPAT_43 kernel configuration option has been deemed > unnecessary and > # has been removed from GENERIC and related kernel configurations. This > change may > # result in a small performance increase for some workloads. > #options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] > options COMPAT_43TTY# BSD 4.3 TTY compat [KEEP THIS!] > options COMPAT_FREEBSD4 # Compatible with FreeBSD4 > options COMPAT_FREEBSD5 # Compatible with FreeBSD5 > options COMPAT_FREEBSD6 # Compatible with FreeBSD6 > options COMPAT_FREEBSD7 # Compatible with FreeBSD7 > options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI > options SYSVSHM # SYSV-style shared memory > options SYSVMSG # SYSV-style message queues > options SYSVSEM # SYSV-style semaphores > options P1003_1B_SEMAPHORES # POSIX-style semaphores > options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions > options KBD_INSTALL_CDEV# install a CDEV entry in /dev > #options ADAPTIVE_GIANT # Giant mutex is adaptive. > options SC_HISTORY_SIZE=1000 > options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) > options AUDIT # Security event auditing > options MAC # TrustedBSD MAC Framework > options FLOWTABLE # per-cpu routing cache > options KTRACE # ktrace(1) support > options STACK # stack(9) support > #options KD
Re: uma_zalloc_arg complaining about non-sleepable locks
On Sunday 31 January 2010 11:28:54 am Marius Strobl wrote: > On Sun, Jan 31, 2010 at 12:06:18PM +1100, Peter Jeremy wrote: > > Sorry for the delay, I was trying to avoid rebooting my server. > > I've setup a similar environment in VirtualBox to test it. > > > > On 2010-Jan-27 12:52:29 +0100, Marius Strobl wrote: > > >Ah, I forgot that using nfsm_aligned() causes nfs_realign() to > > >be a NOP on architectures without strict alignment requirements > > >for performance reasons. That's generally fine but unfortunately > > >that way you don't actually exercise the code which caused the > > >problem before (unfortunately I still don't manage to hit the > > >unaligned case myself). > > > > >Could you please test with #ifdef __NO_STRICT_ALIGNMENT replaced > > >with #if 0 in sys/nfs/nfs_common.h? The vfs.nfs.realign_count > > >counter should also increase then. > > > > I'm not sure what triggers the unaligned case either - I tried > > roughly "tar -cf - -C /mnt/usr src | tar -xf - -C /mnt/tmp" and > > that caused some unaligned accesses (but also completely wedged > > the VBox host). I also tried copying a pile of files off my > > NFS client (FreeBSD-8.x/i386) and that also triggered some > > unaligned accesses without any errors being reported. > > > > Currently, I have: > > vfs.nfs.realign_count: 12 > > vfs.nfs.realign_test: 188817 > > > > I'd say that your patch works. > > John, are you okay with that patch? > http://people.freebsd.org/~marius/fha_extract_info_realign2.diff > > It's intention is to: > - Move nfs_realign() from the NFS client to the shared NFS code and > remove the NFS server version in order to reduce code duplication. > The shared version now uses a second parameter how, which is passed > on to m_get(9) and m_getcl(9) as the server used M_WAIT while the > client requires M_DONTWAIT, and replaces the the previously unused > parameter hsiz. > - Change nfs_realign() to use nfsm_aligned() so as with other NFS code > the alignment check isn't actually performed on platforms without > strict alignment requirements for performance reasons because as the > comment suggests only occasionally occurs with TCP. > - Change fha_extract_info() to use nfs_realign() with M_NOWAIT rather > than M_DONTWAIT because it's called with the RPC sp_lock held. > > The only downside of the shared nfs_realign() are the combined > SYSCTL counters but the fact we incremented them non-atomically > so far I think already indicates that their intention only is a > rough indication rather than exact values for client and server. This all sounds good to me, but isn't M_NOWAIT == M_DONTWAIT? Hmm, reading the code more closely, it looks like fha_extract_info() was using M_WAIT rather than M_DONTWAIT previously. Also, I think you should be careful to use M_DONTWAIT instead of M_NOWAIT for mbufs, so I would fix that in fha_extract_info(). -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Kernel probe order issues
on 01/02/2010 10:51 Peter Jeremy said the following: > Whilst trying to boot a brand new FreeBSD 8-stable/amd64 kernel, > I ran into an unfortunate nasty with the kernel probe order. > > This particular box has no PS/2 ports so I have a USB keyboard and > have removed atkbd et al from my kernel config. Unfortunately, whilst > trying to merge changes from 5 different sources, I also accidently > deleted my HDD controller. Quite reasonably, the lack of disk > controller made the kernel spit out an error message and "mountroot>" > prompt. Unfortunately, this occurs after the kernel has switched from > BIOS to its own drivers but _before_ ukbd(4) is probed so I didn't > have any keyboard. (Some experimenting with a serial console > confirmed that ukbd is probed after the root device). > > This strikes me as undesirable. Is there some way to bump up the > probe/attach priority of console input devices to ensure that they > exist before the kernel tries to read input? It seems to be a problem with either your keyboard or your USB controller. USB keyboard can be discovered much earlier than mountroot if the hardware is ready. No magical software priority bump can help here. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Kernel probe order issues
Whilst trying to boot a brand new FreeBSD 8-stable/amd64 kernel, I ran into an unfortunate nasty with the kernel probe order. This particular box has no PS/2 ports so I have a USB keyboard and have removed atkbd et al from my kernel config. Unfortunately, whilst trying to merge changes from 5 different sources, I also accidently deleted my HDD controller. Quite reasonably, the lack of disk controller made the kernel spit out an error message and "mountroot>" prompt. Unfortunately, this occurs after the kernel has switched from BIOS to its own drivers but _before_ ukbd(4) is probed so I didn't have any keyboard. (Some experimenting with a serial console confirmed that ukbd is probed after the root device). This strikes me as undesirable. Is there some way to bump up the probe/attach priority of console input devices to ensure that they exist before the kernel tries to read input? -- Peter Jeremy pgpije7UV1cSy.pgp Description: PGP signature
