Re: System borked: loader stack overflow.
On Sat, Jan 17, 2009 at 10:09:52PM -0500, Andrew Lankford wrote: > After rebuilding world from 7-stable after cvsup, I can no longer boot. > The loader tries to load the kernel but instead locks up with a stack > overflow. Wish I could send more details, but I'll have to find another > way to boot up my system first. just to identify the problem - what was the version of your previous loader, and what kind of CPU do you have (Intel or AMD, single or multi core) etc. (to boot again you can replace /boot/loader with one taken from an older 6.3 or 7.0 CD) cheers luigi ___ 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: System borked: loader stack overflow.
On 2009-Jan-17 22:09:52 -0500, Andrew Lankford wrote: >After rebuilding world from 7-stable after cvsup, I can no longer boot. >The loader tries to load the kernel but instead locks up with a stack >overflow. Wish I could send more details, but I'll have to find another >way to boot up my system first. If you press any key during the first spinner, you should get a prompt similar to the following: >> FreeBSD/i386 BOOT Default: 0:ad(0,a)/boot/loader boot: You can then enter the name of the program you wish to run - eg /boot/loader.old (or directly load /boot/kernel/kernel) See the following for a more complete description: http://www.freebsd.org/cgi/man.cgi?query=boot&apropos=0&sektion=0&manpath=FreeBSD+7.1-RELEASE&format=html Alternatively, you could boot off a "live filesystem" CD. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgp6UN5GMnCSa.pgp Description: PGP signature
Re: System borked: loader stack overflow.
I got the same thing. I put only the options I needed into loader.conf and it booted fine. On Sun, Jan 18, 2009 at 1:33 AM, Luigi Rizzo wrote: > On Sat, Jan 17, 2009 at 10:09:52PM -0500, Andrew Lankford wrote: >> After rebuilding world from 7-stable after cvsup, I can no longer boot. >> The loader tries to load the kernel but instead locks up with a stack >> overflow. Wish I could send more details, but I'll have to find another >> way to boot up my system first. > > just to identify the problem - what was the version of your > previous loader, and what kind of CPU do you have (Intel or AMD, > single or multi core) etc. > > (to boot again you can replace /boot/loader with one taken from > an older 6.3 or 7.0 CD) > > cheers > luigi > ___ > 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" > ___ 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"
NFS-Locking problem with 6.4/7.1-RELEASE
Hello, I operate two FreeBSD-Servers in a Windows- and HP-UX Environment. One is a SAMBA-Server as a gateway between the Windows and the Unix world, the other is NFS-Server for the HP-UX 11i v1 Workstations. Both are HP ProLiants DL380 with additional external disks on SmartRAID Controllers. Since the HP-UX Workstations and their disks are becoming quite old, I started to move the home-directories to the FreeBSD Server, wich worked with 6.3-RELEASE quite good so far. Brave as I am, I updated the servers to 6.4 RELEASE and since then the users on the HP-UX machines with the homedirs on the FreeBSD-Server were locked... :-( I tried to find out what was happening and this are my results: When a user logs in on a HP-UX machine, his '.profile' file is opened and read/executed, but it seems, that it cannot be closed any more. So if the last line in the '.profile' is "echo foo bar" you *can* see "foo bar" on the screen, but then nothing happens any more, the machine is locked. I recorded such a session with 'tcpdump' and looked at the dump... the only noticeable things are *Bursts* of NLM V4 CANCEL_MSGes on the same filehandle. Eg: "V4 CANCEL_MSG Call FH:0x644201fe svid: pos:0-0" This line is repeated 7 times with various values for 'svid'. I'm no NFS specialist at all, so I cannot tell you more :-/ But I can supply the dump (if needed), it's 92KB, so the size should not be a problem... BTW: I tried this with and without kernel support for NFS-Locking - no difference. I also tried the new replacement server with FreeBSD 7.1- RELEASE: Just the same problems, with and without kernel support. I hope someone is willing to work on that issue... As mentioned, a new, non-productive server is available in the moment, so tests are easily possible. TIA Matthew -- Ciao/BSD - Matthias Matthias Schuendehuette, Berlin (Germany)
Re: Big problems with 7.1 locking up :-(
Tomas Randa wrote: Hello, I have similar problems. The last "good" kernel I have from stable brach, october the 8. Then in next upgrade, I saw big problems with performance. I tried ULE, 4BSD etc, but nothing helps, only downgrading system back. Now I am trying 7.1-p1 and problems are here again. Mysql is waiting a lot of time with status "waiting for opening table" or "waiting for close tables" I have 32bit FreeBSD with PAE, 1x xeon 5420, supermicro motherboard, areca SATA controller. Could not be problem in "da" device for example? You and anyone else seeing performance problems should try to work through the advice given here: http://people.freebsd.org/~kris/scaling/Help_my_system_is_slow.pdf Kris ___ 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: Big problems with 7.1 locking up :-(
Tomas Randa wrote: > Hello, > > I have similar problems. The last "good" kernel I have from stable > brach, october the 8. Then in next upgrade, I saw big problems with > performance. I can add a "me too" here. This is on my desktop, very lightly loaded. This computer never had a single problem under FreeBSD so i don't suspect a hardware problem. My previous upgrade was FreeBSD 7.0-STABLE #0: Tue Jul 22, and worked perfectly fine with exactly the same software configuration. Now i have FreeBSD 7.1-STABLE #0: Mon Jan 5 , and the situation is disastrous. Freshly after boot the machine seems to work normal, but after a few days it becomes slower and slower, windows takes seconds to appear, firefox3 begins to have garbled output, etc. Then i had the following problem, firefox got stuck in kernel, impossible to kill it by kill -9. Needless to say i inspected everything, dmesg, xsession-errors, top, etc. without seeing anything suspicious. So i rebooted, and bingo! the machine paniced, mentioning firefox. But the panic itself get stuck and i had to push the reset button, so no dump. After reboot, machine works OK for two or three days, then problems begin again. I am convinced there is a big problem in the kernel. For reference, here is top and dmesg: CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 264M Active, 613M Inact, 485M Wired, 22M Cache, 112M Buf, 116M Free Swap: 2023M Total, 4K Used, 2023M Free PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 62965 michel 1 440 3532K 1884K CPU1 1 0:00 0.29% top 2327 root 1 440 161M 29228K select 1 30:39 0.00% Xorg 95937 root 1 440 24112K 16800K select 1 2:35 0.00% kdm-bin_gr 3099 root 1 40 3304K 1028K select 0 1:30 0.00% moused 2209 news 1 80 3464K 1052K wait 0 0:37 0.00% sh 884 root 1 440 4712K 2028K select 1 0:12 0.00% ntpd 453 _pflogd 1 -580 3380K 1352K bpf0 0:11 0.00% pflogd 1634 www 1 40 6268K 2656K kqread 0 0:10 0.00% lighttpd 788 root 1 440 3164K 3184K select 0 0:04 0.00% amd 2206 news 1 440 15208K 12160K select 0 0:03 0.00% innd 879 root 9 40 5432K 2460K kqread 1 0:02 0.00% nscd 955 root 1 440 2736K 1216K select 1 0:02 0.00% master 758 root 1 440 3164K 1340K select 1 0:02 0.00% ypbind ... so no memory problem Copyright (c) 1992-2009 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-STABLE #0: Mon Jan 5 14:29:23 CET 2009 mic...@niobe.lpthe.jussieu.fr:/usr/obj/usr/src/sys/NIOBE Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.06GHz (3073.65-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebfbff Features2=0x4400 Logical CPUs per core: 2 real memory = 1610530816 (1535 MB) avail memory = 1568387072 (1495 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ ioapic0 irqs 0-23 on motherboard acpi0: on motherboard acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 22 acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 5ff0 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xd800-0xd8ff mem 0xe000-0xefff,0xdf00-0xdf00 irq 16 at device 0.0 on pci1 uhci0: port 0xb800-0xb81f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xb400-0xb41f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xb000-0xb01f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xde80-0xde8003ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6
Re: System borked: loader stack overflow.
I can't say what version of the loader it is that I'm using, but (following Peter's advice, thanks), I've tried loader.old (about a week old) and the latest loader (built yesterday), and both start. Where each loader has a problem appears to be reading (include-ing?) /boot/default/loader.conf . The spinner spins for a longer time than usual, and then the loader gives up with the stack overflow. Fortunately, I still got a prompt and am able to load the latest kernel acpi and a what few other modules I need to boot successfully and reply to your emails. A quick look at /boot/defaults/loader.conf ( version 1.122.2.4 2008/11/24 00:52:26 ) shows nothing out of the ordinary. FYI: I'm using the Windows Vista boot manager with boot1 instead of boot0, although boot1 doesn't appear to have changed since I first installed 7.0 on my notebook. Andrew Lankford Luigi Rizzo wrote: On Sat, Jan 17, 2009 at 10:09:52PM -0500, Andrew Lankford wrote: After rebuilding world from 7-stable after cvsup, I can no longer boot. The loader tries to load the kernel but instead locks up with a stack overflow. Wish I could send more details, but I'll have to find another way to boot up my system first. just to identify the problem - what was the version of your previous loader, and what kind of CPU do you have (Intel or AMD, single or multi core) etc. (to boot again you can replace /boot/loader with one taken from an older 6.3 or 7.0 CD) cheers luigi ___ 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: System borked: loader stack overflow.
The cpu I'm using is: CPU: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2194.52-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x2010 AMD Features2=0x1 Cores per package: 2 real memory = 2137444352 (2038 MB) avail memory = 2086969344 (1990 MB) ACPI APIC Table: It's a Dell Vostro 1400. Andrew Lankford Luigi Rizzo wrote: On Sat, Jan 17, 2009 at 10:09:52PM -0500, Andrew Lankford wrote: After rebuilding world from 7-stable after cvsup, I can no longer boot. The loader tries to load the kernel but instead locks up with a stack overflow. Wish I could send more details, but I'll have to find another way to boot up my system first. just to identify the problem - what was the version of your previous loader, and what kind of CPU do you have (Intel or AMD, single or multi core) etc. (to boot again you can replace /boot/loader with one taken from an older 6.3 or 7.0 CD) cheers luigi ___ 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: System borked: loader stack overflow.
On Sun, Jan 18, 2009 at 10:38:51AM -0500, Andrew Lankford wrote: > > I can't say what version of the loader it is that I'm using, but > (following Peter's advice, thanks), I've tried loader.old (about a week > old) and the latest loader (built yesterday), and both start. Where > each loader has a problem appears to be reading (include-ing?) > /boot/default/loader.conf . The spinner spins for a longer time than ok so the problem could be is a recursive assignment of loader_conf_files in your previous installation (either as a result of the default installation, or because of manual modifications). Could you please send me a copy of your /boot/loader.conf and /boot/defaults/loader.conf so i can check ? A recent commit fixed the handling of loader_conf_files, which previously was broken (in some cases assignments were ignored). A side effect of the fix is that now certain errors in the config files are now detected as such. cheers luigi ___ 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: System borked: loader stack overflow.
On Sun, Jan 18, 2009 at 05:47:24PM +0100, Luigi Rizzo wrote: > On Sun, Jan 18, 2009 at 10:38:51AM -0500, Andrew Lankford wrote: > > > > I can't say what version of the loader it is that I'm using, but > > (following Peter's advice, thanks), I've tried loader.old (about a week > > old) and the latest loader (built yesterday), and both start. Where > > each loader has a problem appears to be reading (include-ing?) > > /boot/default/loader.conf . The spinner spins for a longer time than > > ok so the problem could be is a recursive assignment of loader_conf_files > in your previous installation (either as a result of the default > installation, or because of manual modifications). > Could you please send me a copy of your /boot/loader.conf and > /boot/defaults/loader.conf so i can check ? also /boot/loader.conf.local please... thanks luigi > A recent commit fixed the handling of loader_conf_files, > which previously was broken (in some cases assignments were ignored). > A side effect of the fix is that now certain errors in the config > files are now detected as such. > > cheers > luigi ___ 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: System borked: loader stack overflow.
On Sun, 18 Jan 2009, Andrew Lankford wrote: I can't say what version of the loader it is that I'm using, but (following Peter's advice, thanks), I've tried loader.old (about a week old) and the latest loader (built yesterday), and both start. Where each loader has a problem appears to be reading (include-ing?) /boot/default/loader.conf . The spinner spins for a longer time than usual, and then the loader gives up with the stack overflow. Fortunately, I still got a prompt and am able to load the latest kernel acpi and a what few other modules I need to boot successfully and reply to your emails. Hmm, there's also a new PR in (kern/130674) which sounds like the same issue, on -HEAD. Gavin ___ 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: ext2 inode size patch - RE: PR kern/124621
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 3 Dec 2008 17:53:43 -0500
"Josh Carroll" mentioned:
> > Ok, I describe my concern once more. I do not object against the checking
> > of the inode size. But, if inode size is changed, then some data is added
> > to the inode, that could (and usually does, otherwise why extend it ?)
> > change intrerpetation of the inode. Thus, we need a verification of the
> > fact that simply ignoring added fields does not damage filesystem or
> > cause user data corruption. Verification != testing.
>
> Let me take another crack at explaining why I think this patch is not
> dangerous.
>
> The inode size is determined by reading the following member:
>
> __u16 s_inode_size;
>
> of the ext2_super_block structure.
>
> I took a look at the Linux 2.6.27.7 kernel source, and indeed they do
> something very similar if not the same:
>
> #define EXT2_INODE_SIZE(s) (EXT2_SB(s)->s_inode_size)
>
> If you compare to what I did:
>
> #define EXT2_INODE_SIZE(s) ((s)->u.ext2_sb.s_inode_size)
>
> This is really the same thing, since EXT2_SB is defined (in the Linux
> kernel src as):
>
> #ifdef __KERNEL__
> #include
> static inline struct ext2_sb_info *EXT2_SB(struct super_block *sb)
> {
> return sb->s_fs_info;
> }
>
> And struct ext2_sb_info has the following member:
>
> int s_inode_size;
>
> Essentially, the changes I made simply query the existing information
> from the filesystem, which is what the Linux kernel does as well.
>
> The inode size, blocks per group, etc are all defined at filesystem
> creation time by mke2fs and it ensures the sanity of the relationship
> between the inodes/blocks/block groups.
>
> The first diagram here:
>
> http://sunsite.nus.sg/LDP/LDP/tlk/node95.html
>
> Makes it clear that as long as the number of inodes per block and the
> blocks per group is is sane during fs creation, looking up the inode
> size as my patch does is fine, since the creation of the filesystem is
> ensures a correct by construction situation. We're simply reading the
> size of the inode based on the filesystem.
>
> I hope this is sufficient to convince some further thought about
> committing this.
>
> For those interested in the relevant Linux kernel source, you can have
> a look at line 105 of include/linux/ext2_fs.h from the linux-2.6.27.7
> kernel source.
>
Hi Josh!
I've commited the similar patch today that should be fixing your problem.
Can you check this, please?
Sorry I've missed this thread in the first place.
- --
Stanislav Sedov
ST4096-RIPE
-BEGIN PGP SIGNATURE-
iEYEARECAAYFAklzYsoACgkQK/VZk+smlYF3ZwCeOyVUdzrKOdu4Pg3ztAZ0QQaY
GGIAnA+oL054T0EAajbfwpYSTDRKVISC
=jJFT
-END PGP SIGNATURE-
!DSPAM:497362c8967002668918391!
___
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: Big problems with 7.1 locking up :-(
On Sun, 18 Jan 2009 13:21:17 +0100 Michel Talon wrote: > My previous upgrade was FreeBSD 7.0-STABLE #0: Tue Jul 22, and worked > perfectly fine with exactly the same software configuration. > Now i have FreeBSD 7.1-STABLE #0: Mon Jan5, and the situation is > disastrous. Makes you wonder on on earth could have changed that much between 7.0/7.1 Nice upgrade.. This should not happen on the same hardware! -- Dick Hoogendijk -- PGP/GnuPG key: 01D2433D + http://nagual.nl/ | SunOS sxce snv105 ++ + All that's really worth doing is what we do for others (Lewis Carrol) ___ 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: System borked: loader stack overflow.
Shortened my loader.conf to the bare essentials and now I'm back in business! Still curious whether redefining loader_conf_files (which I suppose should only be defined in the default loader.conf) caused the problem or whether it was something else. Thanks, Andrew Lankford ___ 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: Big problems with 7.1 locking up :-(
>> My previous upgrade was FreeBSD 7.0-STABLE #0: Tue Jul 22, and worked >> perfectly fine with exactly the same software configuration. >> Now i have FreeBSD 7.1-STABLE #0: Mon Jan5, and the situation is >> disastrous. > > Makes you wonder on on earth could have changed that much between > 7.0/7.1 Nice upgrade.. This should not happen on the same hardware! There will always be changes when new features/options/enhancements are introduced. Me for my part have never had any serious trouble with FreeBSD what so ever since FreeBSD 5.1/2 when some kernel-limits had to be changed. My problem was solved with the help from this list. -- regards Claus When lenity and cruelty play for a kingdom, the gentler gamester is the soonest winner. Shakespeare ___ 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: System borked: loader stack overflow.
On Sun, Jan 18, 2009 at 05:47:24PM +0100, Luigi Rizzo wrote: > On Sun, Jan 18, 2009 at 10:38:51AM -0500, Andrew Lankford wrote: > > > > I can't say what version of the loader it is that I'm using, but > > (following Peter's advice, thanks), I've tried loader.old (about a week > > old) and the latest loader (built yesterday), and both start. Where > > each loader has a problem appears to be reading (include-ing?) > > /boot/default/loader.conf . The spinner spins for a longer time than > > ok so the problem could be is a recursive assignment of loader_conf_files > in your previous installation (either as a result of the default > installation, or because of manual modifications). > Could you please send me a copy of your /boot/loader.conf and > /boot/defaults/loader.conf so i can check ? > > A recent commit fixed the handling of loader_conf_files, > which previously was broken (in some cases assignments were ignored). > A side effect of the fix is that now certain errors in the config > files are now detected as such. Having the following in /boot/loader.conf triggers it for me, loader_conf_files="/boot/device.hints /boot/loader.conf" You may say thats its an invalid config line but the loader shouldnt blow up from it. Can this be fixed up somehow? Andrew ___ 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: System borked: loader stack overflow.
Andrew Thompson wrote: On Sun, Jan 18, 2009 at 05:47:24PM +0100, Luigi Rizzo wrote: On Sun, Jan 18, 2009 at 10:38:51AM -0500, Andrew Lankford wrote: I can't say what version of the loader it is that I'm using, but (following Peter's advice, thanks), I've tried loader.old (about a week old) and the latest loader (built yesterday), and both start. Where each loader has a problem appears to be reading (include-ing?) /boot/default/loader.conf . The spinner spins for a longer time than ok so the problem could be is a recursive assignment of loader_conf_files in your previous installation (either as a result of the default installation, or because of manual modifications). Could you please send me a copy of your /boot/loader.conf and /boot/defaults/loader.conf so i can check ? A recent commit fixed the handling of loader_conf_files, which previously was broken (in some cases assignments were ignored). A side effect of the fix is that now certain errors in the config files are now detected as such. Having the following in /boot/loader.conf triggers it for me, loader_conf_files="/boot/device.hints /boot/loader.conf" You may say thats its an invalid config line but the loader shouldnt blow up from it. Can this be fixed up somehow? Andrew Indeed, it would be nice if um someone (anyone, mind you) with commit priviledges might put some descriptive comments around the "default-only" settings in /boot/default/loader.conf...:) Andrew Lankford ___ 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: System borked: loader stack overflow.
On Sun, Jan 18, 2009 at 02:19:23PM -0500, Andrew Lankford wrote: > Andrew Thompson wrote: ... > >Having the following in /boot/loader.conf triggers it for me, > > > > loader_conf_files="/boot/device.hints /boot/loader.conf" > > > >You may say thats its an invalid config line but the loader shouldnt > >blow up from it. Can this be fixed up somehow? no, this cannot be "fixed" because it is the user misprogramming the system, such as providing the wrong path to the kernel or writing a loop in /etc/rc.conf or a billion other ways. Setting loader_conf_files="x y z" is basically equivalent to writing "call a; call b; call c;" in a programming language, with the only difference that the action is done at the end of the current file. > Indeed, it would be nice if um someone (anyone, mind you) with commit > priviledges might put some descriptive comments around the > "default-only" settings in /boot/default/loader.conf...:) it is not "default only", either - it is just one of the many files loaded by /boot/loader, you just need to avoid infinite loops. I can write some extra notes in the manpage, and perhaps suggest a rename of the /boot/defaults/ file so one does not end up with two copies by mistake. cheers luigi ___ 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: System borked: loader stack overflow.
On Sun, Jan 18, 2009 at 09:08:56PM +0100, Luigi Rizzo wrote: > On Sun, Jan 18, 2009 at 02:19:23PM -0500, Andrew Lankford wrote: > > Andrew Thompson wrote: > ... > > >Having the following in /boot/loader.conf triggers it for me, > > > > > > loader_conf_files="/boot/device.hints /boot/loader.conf" > > > > > >You may say thats its an invalid config line but the loader shouldnt > > >blow up from it. Can this be fixed up somehow? > > no, this cannot be "fixed" because it is the user misprogramming > the system, such as providing the wrong path to the kernel > or writing a loop in /etc/rc.conf or a billion other ways. Yes, but you can copy /etc/defaults/rc.conf to /etc/rc.conf and things still work. > Setting loader_conf_files="x y z" is basically equivalent to > writing "call a; call b; call c;" in a programming language, > with the only difference that the action is done at the end of > the current file. Ok, then loader_conf_files needs to be marked as special and not to be overridden from /boot/defaults/loader.conf like all the other options. A better way would be to track included files and not reprocess them. Also an entry in UPDATING that a config error that was once harmless now renders the system unbootable (without intervention). cheers, Andrew ___ 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: System borked: loader stack overflow.
On Sun, Jan 18, 2009 at 12:18:09PM -0800, Andrew Thompson wrote: > On Sun, Jan 18, 2009 at 09:08:56PM +0100, Luigi Rizzo wrote: > > On Sun, Jan 18, 2009 at 02:19:23PM -0500, Andrew Lankford wrote: > > > Andrew Thompson wrote: > > ... > > > >Having the following in /boot/loader.conf triggers it for me, > > > > > > > > loader_conf_files="/boot/device.hints /boot/loader.conf" > > > > > > > >You may say thats its an invalid config line but the loader shouldnt > > > >blow up from it. Can this be fixed up somehow? > > > > no, this cannot be "fixed" because it is the user misprogramming > > the system, such as providing the wrong path to the kernel > > or writing a loop in /etc/rc.conf or a billion other ways. > > Yes, but you can copy /etc/defaults/rc.conf to /etc/rc.conf and things > still work. just because it contains only variable assignments, whereas the "assignments" in loader.conf have other side effects. However, I agree that a split of the content of loader.conf might make reduce the chance of mistakes. I'll look into this. > Ok, then loader_conf_files needs to be marked as special and not to be > overridden from /boot/defaults/loader.conf like all the other options. Unless i misunderstand what you say, this is already documented in loader.conf(5) cheers luigi ___ 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"
iwn driver on 7.1
I have a working driver for the Intel 4965, aka iwn(4), loaded on my Lenovo X300 running FreeBSD 7.1-RELEASE (amd64). This driver is a slightly-modified version of the iwn(4) driver backported from 8.0-CURRENT by Gavin Atkinson: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=221758+0+/usr/local/www/db/text/2008/freebsd-stable/20080928.freebsd-stable I was seeing the same symptoms described in these threads (among others): http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045264.html http://www.freebsd.org/cgi/getmsg.cgi?fetch=1334322+1338147+/usr/local/www/db/text/2009/freebsd-questions/20090118.freebsd-questions http://www.freebsd.org/cgi/getmsg.cgi?fetch=1418632+1421765+/usr/local/www/db/text/2009/freebsd-questions/20090118.freebsd-questions ...so I debugged and modified Gavin's driver for my system. The driver and the source tree diff can be downloaded here for any brave souls wanting to test it out: http://sites.google.com/site/bsdgooch/files I'm using the driver now to send this e-mail over a link to my TP-LINK TL-WR941ND access point (with WPA2). Feedback and bug reports would be useful. -brandon ___ 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: iwn driver on 7.1
On Sun, 18 Jan 2009 14:17:39 -0600 Brandon Gooch wrote: > I have a working driver for the Intel 4965, aka iwn(4), loaded on my > Lenovo X300 running FreeBSD 7.1-RELEASE (amd64). FWIW, I am using the latest perforce version of the iwn driver as documented here[1] on a ThinkPad T61 running FreeBSD 7.1-stable / i386 - no modifications necessary. It works great. I just use the p4fetch.rb script to get the driver. HTH References: 1) http://clearchain.com/wiki/iwn -- Regards, Torfinn Ingolfsen ___ 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: iwn driver on 7.1
Da Rock wrote: On Sun, 2009-01-18 at 14:17 -0600, Brandon Gooch wrote: I have a working driver for the Intel 4965, aka iwn(4), loaded on my Lenovo X300 running FreeBSD 7.1-RELEASE (amd64). This driver is a slightly-modified version of the iwn(4) driver backported from 8.0-CURRENT by Gavin Atkinson: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=221758+0+/usr/local/www/db/text/2008/freebsd-stable/20080928.freebsd-stable I was seeing the same symptoms described in these threads (among others): http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045264.html http://www.freebsd.org/cgi/getmsg.cgi?fetch=1334322+1338147+/usr/local/www/db/text/2009/freebsd-questions/20090118.freebsd-questions http://www.freebsd.org/cgi/getmsg.cgi?fetch=1418632+1421765+/usr/local/www/db/text/2009/freebsd-questions/20090118.freebsd-questions ...so I debugged and modified Gavin's driver for my system. The driver and the source tree diff can be downloaded here for any brave souls wanting to test it out: http://sites.google.com/site/bsdgooch/files I'm using the driver now to send this e-mail over a link to my TP-LINK TL-WR941ND access point (with WPA2). Feedback and bug reports would be useful. -brandon Sounds like you got to it before I did- thank god! :) Question though: have you got it figured for a channels yet? I'll test it for you and keep you updated with my results. Thanks for working on the driver! The only difference to the version of gavin that I could see is that the bands in iwn_bands that got commented out were brought back. Or did I miss something? Do you know why they were commented out and it was unnecessary? Or was it just to fix the crash? I did a few test runs: It does not crash immediately as the version from gavin, but the error I had with the perforce version iwn0: error, INTR=8200 STATUS=0x1 iwn0: iwn_config: could not set power mode, error 35 is there -- in 3 out of 3 tries. So nothing improved there. (I hit that error on first use in about 50% of the cases before.) Moreover, at 3 out of 4 tries to 'kldunload if_iwn' after hitting the error (after '/etc/rc.d/netif stop iwn0' and 'ifconfig iwn0 down'), there was a crash: 2 page faults and 1 freeze. I have not had that with the perforce version. (Maybe once long ago, but I think I forgot to stop iwn0 at that time.) The one time I actually got the (WPA2) connection up, I was able to transfer with a similar speed as with the perforce version. Thus, for me, there are no improvement over the (old) perforce version. Probably by chance, but I had more crashes. I think the thread on stable@ should rather be continued than the one on questions@, but since Da Rock answered on questions@, I reinclude both. Cheers, Jan Henrik ___ 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: FreeBSD 7.0 kernel panic
l1nyx...@googlemail.com wrote:
Hello, FreeBSD-stable.
Last week I have a lot of kernel panics like:
[r...@router1 /usr/obj/usr/src/sys/TINCOKERNEL2]# kgdb kernel.debug
/var/crash/vmcore.20
[GDB will not be able to debug user-mode threads:
/usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".
Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x9
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc079f1af
stack pointer = 0x28:0xe5697c80
frame pointer = 0x28:0xe5697cbc
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 14 (swi4: clock)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 51m49s
Physical memory: 2032 MB
Dumping 177 MB: 162 146 130 114 98 82 66 50 34 18 2
#0 doadump () at pcpu.h:195
195 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) bt
#0 doadump () at pcpu.h:195
#1 0xc078d1b7 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:409
#2 0xc078d479 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:563
#3 0xc0a0eaac in trap_fatal (frame=0xe5697c40, eva=9) at
/usr/src/sys/i386/i386/trap.c:899
#4 0xc0a0f42f in trap (frame=0xe5697c40) at /usr/src/sys/i386/i386/trap.c:280
#5 0xc09f565b in calltrap () at
/usr/src/sys/i386/i386/exception.s:139
#6 0xc079f1af in softclock (dummy=0x0) at
/usr/src/sys/kern/kern_timeout.c:202
#7 0xc076f31b in ithread_loop (arg=0xc5101250) at
/usr/src/sys/kern/kern_intr.c:1036
#8 0xc076c119 in fork_exit (callout=0xc076f170 , arg=0xc5101250,
frame=0xe5697d38)
at /usr/src/sys/kern/kern_fork.c:781
#9 0xc09f56d0 in fork_trampoline () at
/usr/src/sys/i386/i386/exception.s:205
(kgdb)
Looks likely to be a hardware fault, to me.
Kris
___
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"
RFC: side effects of fixing loader_conf_files handling
hi, in some recent commits to HEAD and stable/7 i fixed the handling of loader_conf_files so that it behaves as always intended and documented in loader.conf(5): ... loader_conf_files Defines additional configuration files to be processed right after the present file. Previously, the check for new assignments was incorrect, and it happened to ignored assignments which did not result in a buffer reallocation by the Forth interpreter (essentially, any string not longer than the current one was ignored). An annoying side effect of the fix is that now people who (mistakenly) copied /boot/defaults/loader.conf into /boot/loader.conf (and possibly edit it), now create a loop because their /boot/loader.conf now contains loader_conf_files="/boot/device.hints /boot/loader.conf /boot/loader.conf.local" which is not just a pure assignments. Never mind the fact nobody ever recommended to copy the file and then modify the copy, there seem to be several people who do this (and do the same for /etc/defaults/rc.conf). I think we should remove the use of loader_conf_files=... from /boot/defaults/loader.conf, partly to prevent this kind of bugs, and partly because it is nice to have only "pure assigments" in this file. If there are no objections, i will look at how to do it. Probably this requires putting the initial list of files somewhere else, probably in /boot/loader.rc after the include /boot/loader.4th statement. Comments ? cheers luigi ___ 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: iwn driver on 7.1
Torfinn Ingolfsen wrote: On Sun, 18 Jan 2009 14:17:39 -0600 Brandon Gooch wrote: I have a working driver for the Intel 4965, aka iwn(4), loaded on my Lenovo X300 running FreeBSD 7.1-RELEASE (amd64). FWIW, I am using the latest perforce version of the iwn driver as documented here[1] on a ThinkPad T61 running FreeBSD 7.1-stable / i386 - no modifications necessary. It works great. I just use the p4fetch.rb script to get the driver. HTH References: 1) http://clearchain.com/wiki/iwn Since from that address, you are using the latest version of the benjsc perforce branch, you are probably using the same as I, since I took the initial version from the sam_vap branch (before vap got introduced). I do not know how far it is, but there is vap_releng7 in the sam perforce and projects/vap7 in svn on which Sam Leffler is actively working: http://lists.freebsd.org/pipermail/svn-src-projects/2009-January/thread.html I would like to have if_iwn working on a otherwise unmodified 7.1-RELEASE-pX and help to test it, but maybe waiting on sam to bring vap to 7 would be a better way to go. Cheers, Jan Henrik ___ 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: iwn driver on 7.1
The kernel panic was due to a NULL pointer dereference in the module. The code that was commented out created a situation in which the array of structs (line 2412): static const struct iwn_chan_band iwn_bands[] contained only 2 items. The code following the struct array that obtained the list of authorized channels: /* read the list of authorized channels */ for (i = 0; i < N(iwn_bands)-2; i++) iwn_read_eeprom_band(sc, &iwn_bands[i]); didn't actually get a list of anything, since N(iwn_bands)-2 evaluates to zero in this case. The NULL pointer part comes in when the call to ieee80211_sort_channels() on line 2436 sends a list of no items with a value of 0 for ic->ic_nchans. The backported insertion sort code from 8.0-CURRENT's 802.11 stack fails somewhere because of this value, due to access of some memory address in the chancompar() or swap(?) -- I didn't really dig that far into it. I guess the purpose of commenting out the A channels in the iwn_bands[] was to keep the driver from potentially using them, but honestly, I'm not sure if that's the appropriate way to do that (I'm just getting into this stuff). I'm sure the MFC'd VAP stuff that Sam Leffler is working on will alleviate all of this, but I wanted a working iwn(4) for now ;) On Sun, Jan 18, 2009 at 4:10 PM, Jan Henrik Sylvester wrote: > Da Rock wrote: >> >> On Sun, 2009-01-18 at 14:17 -0600, Brandon Gooch wrote: >>> >>> I have a working driver for the Intel 4965, aka iwn(4), loaded on my >>> Lenovo X300 running FreeBSD 7.1-RELEASE (amd64). >>> >>> This driver is a slightly-modified version of the iwn(4) driver >>> backported from 8.0-CURRENT by Gavin Atkinson: >>> >>> >>> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=221758+0+/usr/local/www/db/text/2008/freebsd-stable/20080928.freebsd-stable >>> >>> I was seeing the same symptoms described in these threads (among others): >>> >>> >>> http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045264.html >>> >>> >>> http://www.freebsd.org/cgi/getmsg.cgi?fetch=1334322+1338147+/usr/local/www/db/text/2009/freebsd-questions/20090118.freebsd-questions >>> >>> >>> http://www.freebsd.org/cgi/getmsg.cgi?fetch=1418632+1421765+/usr/local/www/db/text/2009/freebsd-questions/20090118.freebsd-questions >>> >>> ...so I debugged and modified Gavin's driver for my system. >>> >>> The driver and the source tree diff can be downloaded here for any >>> brave souls wanting to test it out: >>> >>> http://sites.google.com/site/bsdgooch/files >>> >>> I'm using the driver now to send this e-mail over a link to my TP-LINK >>> TL-WR941ND access point (with WPA2). Feedback and bug reports would be >>> useful. >>> >>> -brandon >> >> Sounds like you got to it before I did- thank god! :) >> >> Question though: have you got it figured for a channels yet? >> >> I'll test it for you and keep you updated with my results. > > Thanks for working on the driver! > > The only difference to the version of gavin that I could see is that the > bands in iwn_bands that got commented out were brought back. Or did I miss > something? Do you know why they were commented out and it was unnecessary? > Or was it just to fix the crash? > > I did a few test runs: It does not crash immediately as the version from > gavin, but the error I had with the perforce version > iwn0: error, INTR=8200 STATUS=0x1 > iwn0: iwn_config: could not set power mode, error 35 > is there -- in 3 out of 3 tries. So nothing improved there. (I hit that > error on first use in about 50% of the cases before.) > > Moreover, at 3 out of 4 tries to 'kldunload if_iwn' after hitting the error > (after '/etc/rc.d/netif stop iwn0' and 'ifconfig iwn0 down'), there was a > crash: 2 page faults and 1 freeze. I have not had that with the perforce > version. (Maybe once long ago, but I think I forgot to stop iwn0 at that > time.) > > The one time I actually got the (WPA2) connection up, I was able to transfer > with a similar speed as with the perforce version. > > Thus, for me, there are no improvement over the (old) perforce version. > Probably by chance, but I had more crashes. > > I think the thread on stable@ should rather be continued than the one on > questions@, but since Da Rock answered on questions@, I reinclude both. > > Cheers, > Jan Henrik > ___ 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"
Sound only on 1 channel, plus other quirks post snd_hda import
I am running RELENG_7 from 12 Jan, I noticed that I am only getting sound on 1 channel. Also opening up "Volume Control" from Gnome and altering either of "Volume" or "PCM" produces crackles on the non functioning channel, and kills susbsequent sound output on either channel! (Just to be sure I tried the speakers out with another machine, and they work fine - both channels) I have hw.snd.maxautovchans=2 set in /etc/sysctl.conf - I'm wondering if that is wrong these days. $ dmesg|grep -i hda hdac0: mem 0xff5fc000-0xff5f irq 17 at device 1.0 on pci2 hdac0: HDA Driver Revision: 20081226_0122 hdac0: [ITHREAD] hdac0: HDA Codec #0: Analog Devices AD1986A hdac0: hdac_widget_connection_parse: nid=18 WARNING: zero cnid entnum=4 j=2 index=0 entries=8 found=2 res=0x21002211 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 hdac0: mem 0xff5fc000-0xff5f irq 17 at device 1.0 on pci2 hdac0: HDA Driver Revision: 20081226_0122 hdac0: [ITHREAD] hdac0: HDA Codec #0: Analog Devices AD1986A hdac0: hdac_widget_connection_parse: nid=18 WARNING: zero cnid entnum=4 j=2 index=0 entries=8 found=2 res=0x21002211 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 hdac0: mem 0xff5fc000-0xff5f irq 17 at device 1.0 on pci2 hdac0: HDA Driver Revision: 20081226_0122 hdac0: [ITHREAD] hdac0: HDA Codec #0: Analog Devices AD1986A hdac0: hdac_widget_connection_parse: nid=18 WARNING: zero cnid entnum=4 j=2 index=0 entries=8 found=2 res=0x21002211 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 ___ 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: System borked: loader stack overflow.
Andrew Thompson wrote: > Also an entry in UPDATING that a config error that was once harmless now > renders the system unbootable (without intervention). Would this also be something that mergemaster could check for and warn against? Jim ___ 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"
Hangs, maybe a clue
I've had some mysterious hangs which I notice that several others have too. Two of the machines in question are Soekris 4801's running as routers; this is hard to handle ddb with (though possible for one of them...) I started noticing this sometime in December. My laptop finally hung in a state where I could do a ps (waiting a long time for the response.) The strange and likely related to the hang was softdepflush in R state with 43 MINUTES of cpu. (the machine has been up maybe an hour.) This is 7.1-stable csup'd Jan 9. I'm backing up to Dec 1 since I didn't notice it (maybe just didn't notice?). The load average was about 10 but mostly that was lower-priority things ready but not run. -- Pete ___ 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: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
On Sat, Jan 17, 2009 at 06:04:37PM +0100, Dimitry Andric wrote: > On 2009-01-17 05:54, Pyun YongHyeon wrote: > > I think the initial setup time issue of 8169SC is different one. > > Did re(4) of 7.0-RELEASE also have the same issue? > > Sometimes, and sometimes not. :) It was flaky, to say the least... > > > > Also would you try attached patch? It doesn't fix initial setup > > time issue but I'd like to know whether it makes your controller > > work. > > This patch not only makes my controller(s) work, it also speeds up the > initial setup time greatly! I have tested this through about 3 reboots, > and one complete powerdown + powerup cycle. Thanks for testing. But the patch does not have any changes to fix your intitial setup time issue. If the patch has any effects on the issue it's a luck, I guess. -- Regards, Pyun YongHyeon ___ 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: Sound only on 1 channel, plus other quirks post snd_hda import
Mark Kirkwood wrote: I am running RELENG_7 from 12 Jan, I noticed that I am only getting sound on 1 channel. Also opening up "Volume Control" from Gnome and altering either of "Volume" or "PCM" produces crackles on the non functioning channel, and kills susbsequent sound output on either channel! I have hw.snd.maxautovchans=2 set in /etc/sysctl.conf - I'm wondering if that is wrong these days. Removing this makes no difference. Also here is output from /dev/sndstat: FreeBSD Audio Driver (newpcm: 32bit 2007061600/i386) Installed devices: pcm0: at cad 0 nid 1 on hdac0 kld snd_hda [MPSAFE] (1p:1v/1r:1v channels duplex default) pcm1: at cad 0 nid 1 on hdac0 kld snd_hda [MPSAFE] (1p:1v/0r:0v channels) regards Mark ___ 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"
