Re: No sound on 10.1-RELEASE
On 03/08/15 22:15, Chris H wrote: On Sun, 08 Mar 2015 19:14:47 +0100 Piotr Kubaj pku...@riseup.net wrote On 03/07/15 01:55, Chris H wrote: On Sat, 07 Mar 2015 00:08:38 +0100 Piotr Kubaj pku...@riseup.net wrote I've got MSI X99 motherboard and am using it with UEFI installation of 10.1 (BIOS mode doesn't work with FreeBSD). At first, sound worked properly (even in KDE), but now it doesn't. I'm not sure what happened, since snd_hda is in kernel (I use GENERIC). I've checked all possible values of hw.snd.default_unit and turned off KDE to check what happens when doing cat /dev/random /dev/dsp (it does nothing). Attached below is dmesg and /dev/sndstat. -8--- Installed devices: pcm0: NVIDIA (0x0071) (HDMI/DP 8ch) (play) pcm1: NVIDIA (0x0071) (HDMI/DP 8ch) (play) pcm2: NVIDIA (0x0071) (HDMI/DP 8ch) (play) pcm3: NVIDIA (0x0071) (HDMI/DP 8ch) (play) pcm4: Realtek ALC892 (Rear Analog 5.1/2.0) (play/rec) default pcm5: Realtek ALC892 (Front Analog) (play/rec) pcm6: Realtek ALC892 (Rear Digital) (play) pcm7: USB audio (rec) Honestly, this could potentially go a lot of different directions; software/driver(s)/setup... It might be helpful to get the pinouts. The kernel (dmesg(8)) will provide it for you. You can see them by; loader.conf(5) adding the following to /boot/loader.conf: boot_verbose=YES or by simply selecting boot verbose on the loader menu 6 -- boot verbose and then getting the results from dmesg(8) /var/run/dmesg.boot If everything looks as anticipated, you might check that your software is using the right sound system (OSS). I've had very good experiences on these sound systems by installing audio/xfce4-mixer doing so, always seems to get the correct settings for everything on these boards -- even if you never use the application. Because these boards can be so troublesome where sound is concerned; I used to have a script that would both check, as well as set everything up. But I can't seem to locate it ATM. HTH --Chris ___ 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 I'm not sure what may be wrong in dmesg.boot so I've uploaded it here: http://pastebin.com/pP0KXp4v Out of the 4 MSI boards I that I have; 3 run the same Realtek ALC893 HDA CODEC that yours does. The other, the Realtek ALC1200 HDA CODEC. All four of them work. But I notice 1 notable difference; that yours reports 2 HDA interfaces: hdac0: NVIDIA (0x0fbb) HDA Controller and hdac1: Intel Wellsburg HDA Controller I see hdac0 is disregarded (unused) whereas hdac1 is enabled, and functioning. I think your problems quite possibly lies in your (sound) system attempting to use the first HDA device in the list, which is effectively disabled. If you can determine a way to tell KDE, and friends to use the 2nd HDA. Things may well go as intended. None of the 4 MSI boards I have display 2 HDA's, as yours does. If you have any additional questions, you may well find the FreeBSD forums already have answers to your issue. This is where I originally found answers to my issues, when I first started using these boards. HTH KDE is definitely using OSS as chosen in its settings (I also use its own mixer which can do the same as Xfce's). I also use VLC's Phonon backend because Gstreamer is said to cause problems, but that also works on 3 other computers. --Chris -- I don't think it's KDE's fault, as it also happens when I kill KDE (service kdm4 stop) and do cat /dev/random /dev/dsp. Of course, I have vol and pcm maxed out. ___ 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: Is there a linux_base available for RELENG_9?
Indeed. Having read UPDATING prior to the attempted upgrade, I followed the advise to add 'compat.linux.osrelease=2.6.18' to sysctl.conf(5). And rebooted. If you rebooted then it should have been set - and you should not have needed to do it manually. But what turned out to be the *actual* solution, was to use sysctl(8). Applying it directly fixed it. :-) This should not have been necessary if you rebooted. I think you should try and find out what went wrong, as otherwise this will not work when you reboot next time and you will have to set it by hand on each reboot. It sounds like you did all the right things - nt sure why it didnt work for you. Have you rebooted since ? What is the value after rebooting now ? -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
There has to be a better way of merging /etc during a major freebsd-update
This flag to mergemaster saved a lot of work when I did upgrades the old way, with cvsup and the make steps and then mergemaster: # Install the new file if it differs only by VCS Id ($FreeBSD) FREEBSD_ID=yes Is there some equivalent to this flag in freebsd-update/merge? I just did my first major upgrade (8.4-RELEASE-p24 - 9.3-RELEASE-p10) with freebsd-update. It took more than an hour of manual keyboard activity, most of which could probably be done automatically. (And here I thought that computers were supposed to free us from tedious routine work...) First robotically pressing dd..j.ZZ in a lot of files. Occasionally combined with / to find more places that needed changing in files that didn't fit in the screen. Eg sendmail.cf. Of all these files that needed manual editing I had made my own changes in only one file (/etc/hosts), the rest of them just had this kind of change: The following file could not be merged automatically: /etc/rc.d/nisdomain Press Enter to edit this file in vi and resolve the conflicts manually... current version # $FreeBSD: src/etc/rc.d/nisdomain,v 1.5.2.2 2013/03/28 13:02:44 svnexp Exp $ === # $FreeBSD: releng/9.3/etc/rc.d/nisdomain 193197 2009-06-01 04:55:13Z dougb $ 9.3-RELEASE And then, after all these edits, I had to wade through entering y to Does this look reasonable (y/n)? for all these files! This is of course a necessary step to avoid being bitten by any === lines left behind by mistake (easy to do when you lose your concentration after more than a hundred files), but most of this step could be entirely avoided by automatically accepting the ID changes. (I amused myself by counting all files during this stage. I had to answer y to about 320 files, most of which only had changes in the ID.) This was my first upgrade from 8.4 to 9.3. I have 30 more to go before the 8.4 EoL this summer. I see 30 completely unnecessarily wasted hours in my future... And think of the combined lost man hours worldwide in these upgrades! Merge seems to be a really stupid choice for major upgrades. (Unless of course there is some flag to freebsd-update which makes this kind of change automatically accepted. But I see no such flag in man freebsd-update in 8.4, 9.3 or 10.1.) And yes, I could maybe copy most of /etc from the first upgraded server to the rest of them before upgrading, but that seems error-prone and not really a good solution for every FreeBSD user. -- Peter Olsson ___ 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: There has to be a better way of merging /etc during a major freebsd-update
On Tue, Mar 10, 2015 at 1:58 PM, Chris H bsd-li...@bsdforge.com wrote: Hello, Peter. This has probably been answered by now. But just in case. I believe what you're looking for is: mergemaster -vF This is my [chosen] default. I also find it helpful, as a safety net to cp _Rp /etc /eetc prior to the mergemaster(8) step. I use these steps after new kernel boots OK with old world: zfs set readonly=off zroot zfs mount -a adjkerntz -i mergemaster -piF cd /usr/src make installworld mergemaster -iFPU make delete-old I get very few questions asked of me by mergemaster. Cheers Tom ___ 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: There has to be a better way of merging /etc during a major freebsd-update
On Tue, 10 Mar 2015 13:05:40 +0100 Peter Olsson list-freebsd-sta...@jyborn.se wrote This flag to mergemaster saved a lot of work when I did upgrades the old way, with cvsup and the make steps and then mergemaster: # Install the new file if it differs only by VCS Id ($FreeBSD) FREEBSD_ID=yes Is there some equivalent to this flag in freebsd-update/merge? Hello, Peter. This has probably been answered by now. But just in case. I believe what you're looking for is: mergemaster -vF This is my [chosen] default. I also find it helpful, as a safety net to cp _Rp /etc /eetc prior to the mergemaster(8) step. On a related note. I'm not very fond of mergemaster. As a result, I recently took on maintaining sysutils/etcmerge. sysutils/etcupdate, is also a [mergemaster] related port. Hope this helps. --Chris I just did my first major upgrade (8.4-RELEASE-p24 - 9.3-RELEASE-p10) with freebsd-update. It took more than an hour of manual keyboard activity, most of which could probably be done automatically. (And here I thought that computers were supposed to free us from tedious routine work...) First robotically pressing dd..j.ZZ in a lot of files. Occasionally combined with / to find more places that needed changing in files that didn't fit in the screen. Eg sendmail.cf. Of all these files that needed manual editing I had made my own changes in only one file (/etc/hosts), the rest of them just had this kind of change: The following file could not be merged automatically: /etc/rc.d/nisdomain Press Enter to edit this file in vi and resolve the conflicts manually... current version # $FreeBSD: src/etc/rc.d/nisdomain,v 1.5.2.2 2013/03/28 13:02:44 svnexp Exp $ === # $FreeBSD: releng/9.3/etc/rc.d/nisdomain 193197 2009-06-01 04:55:13Z dougb $ 9.3-RELEASE And then, after all these edits, I had to wade through entering y to Does this look reasonable (y/n)? for all these files! This is of course a necessary step to avoid being bitten by any === lines left behind by mistake (easy to do when you lose your concentration after more than a hundred files), but most of this step could be entirely avoided by automatically accepting the ID changes. (I amused myself by counting all files during this stage. I had to answer y to about 320 files, most of which only had changes in the ID.) This was my first upgrade from 8.4 to 9.3. I have 30 more to go before the 8.4 EoL this summer. I see 30 completely unnecessarily wasted hours in my future... And think of the combined lost man hours worldwide in these upgrades! Merge seems to be a really stupid choice for major upgrades. (Unless of course there is some flag to freebsd-update which makes this kind of change automatically accepted. But I see no such flag in man freebsd-update in 8.4, 9.3 or 10.1.) And yes, I could maybe copy most of /etc from the first upgraded server to the rest of them before upgrading, but that seems error-prone and not really a good solution for every FreeBSD user. -- Peter Olsson ___ 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
Re: There has to be a better way of merging /etc during a major freebsd-update
Hi! This flag to mergemaster saved a lot of work when I did upgrades the old way, with cvsup and the make steps and then mergemaster: # Install the new file if it differs only by VCS Id ($FreeBSD) FREEBSD_ID=yes Is there some equivalent to this flag in freebsd-update/merge? I just did my first major upgrade (8.4-RELEASE-p24 - 9.3-RELEASE-p10) with freebsd-update. It took more than an hour of manual keyboard activity, most of which could probably be done automatically. (And here I thought that computers were supposed to free us from tedious routine work...) Well, I've been through this in the past as well. If it helps, it gets much better with more recent versions of FreeBSD (9.3 - 10.x). So, yes, it's a drag, but it will not repeat in future updates. -- p...@opsec.eu+49 171 3101372 5 years to go ! ___ 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: There has to be a better way of merging /etc during a major freebsd-update
Peter Olsson wrote on 03/10/2015 13:05: [...] (I amused myself by counting all files during this stage. I had to answer y to about 320 files, most of which only had changes in the ID.) This was my first upgrade from 8.4 to 9.3. I have 30 more to go before the 8.4 EoL this summer. I see 30 completely unnecessarily wasted hours in my future... And think of the combined lost man hours worldwide in these upgrades! Merge seems to be a really stupid choice for major upgrades. [...] This and some other problems with freebsd-update (hanging on the reboot after update) turns me back to using source compiled upgrades. I am compiling 10.1 right now to do the upgrades from 8.4 to 10.1 on 15 machines. Once compiled, I will NFS mount /usr/src and /usr/obj to all machines and will run installkernel, installworld and mergemaster with customized .mergemasterrc. It is more reliable and predictable upgrade, than freebsd-update. (I used freebsd-update for many years, but enough is enough) Miroslav Lachman PS: on PC-BSD there is etcupdate for merging changed files in /etc ___ 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: Suspected libkvm infinite loop
On 11/03/15 07:59, Mark Johnston wrote:
On Tue, Mar 10, 2015 at 02:10:09PM -0400, John Baldwin wrote:
Often loops using libkvm are due to programs using libkvm are trying to read
kernel data structures while they are changing. However, if you use sysctls
to fetch this data instead, you should be able to get a stable snapshot of the
system state without getting stuck in a possible loop. I believe for libkvm
to use sysctl instead of /dev/kmem you have to pass a NULL for the kernel and
/dev/null for the core image.
In our code, we're invoking kvm_openfiles as you suggest:
kd = kvm_openfiles (NULL, _PATH_DEVNULL, NULL, O_RDONLY, errbuf)
It sounds like this issue might be the one fixed in r272566: if the
KERN_PROC_ALL sysctl is read with an insufficiently large buffer, an
sbuf error return value could bubble up and be treated as ERESTART,
resulting in a loop.
This can be confirmed with something like
dtrace -n 'syscall:::entry /pid == $target/{@[probefunc] = count();} tick-3s
{exit(0);}' -p pid of looping proc
If the output consists solely of __sysctl, this bug is likely the
culprit.
Unfortunately, I accidentally killed fstat this morning before I could do any
further debug.
I ran truss -p on it yesterday and it was spinning solely on __sysctl.
I'll try compiling with debug symbols in case it happens again. I haven't been able to reproduce the
problem in a reasonable time frame so it could be days or weeks before we see it happen again.
-Nick
___
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: There has to be a better way of merging /etc during a major freebsd-update
On Tue, Mar 10, 2015 at 10:17:18AM -0500, Adam Vande More wrote: On Tue, Mar 10, 2015 at 7:05 AM, Peter Olsson list-freebsd-sta...@jyborn.se wrote: This flag to mergemaster saved a lot of work when I did upgrades the old way, with cvsup and the make steps and then mergemaster: https://svnweb.freebsd.org/base?view=revisionrevision=221780 I'd venture to guess the script will work fine on older installs, but testing should be done first. -- Adam This seems like an excellent addition fo freebsd-update, how come it isn't added? Possibly as a flag, so the default operation isn't changed. Peter Olsson ___ 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: There has to be a better way of merging /etc during a major freebsd-update
On Tue, Mar 10, 2015 at 06:58:07AM -0700, Chris H wrote: On Tue, 10 Mar 2015 13:05:40 +0100 Peter Olsson list-freebsd-sta...@jyborn.se wrote This flag to mergemaster saved a lot of work when I did upgrades the old way, with cvsup and the make steps and then mergemaster: # Install the new file if it differs only by VCS Id ($FreeBSD) FREEBSD_ID=yes Is there some equivalent to this flag in freebsd-update/merge? Hello, Peter. This has probably been answered by now. But just in case. I believe what you're looking for is: mergemaster -vF Yes, that would probably solve my problem. Can I just change this line in /etc/freebsd-update.conf: MergeChanges /etc/ /var/named/etc/ /boot/device.hints to this: MergeChanges /var/named/etc/ /boot/device.hints And run mergemaster after the first freebsd-update install, before I reboot? Thanks! Peter Olsson This is my [chosen] default. I also find it helpful, as a safety net to cp _Rp /etc /eetc prior to the mergemaster(8) step. On a related note. I'm not very fond of mergemaster. As a result, I recently took on maintaining sysutils/etcmerge. sysutils/etcupdate, is also a [mergemaster] related port. Hope this helps. --Chris I just did my first major upgrade (8.4-RELEASE-p24 - 9.3-RELEASE-p10) with freebsd-update. It took more than an hour of manual keyboard activity, most of which could probably be done automatically. (And here I thought that computers were supposed to free us from tedious routine work...) First robotically pressing dd..j.ZZ in a lot of files. Occasionally combined with / to find more places that needed changing in files that didn't fit in the screen. Eg sendmail.cf. Of all these files that needed manual editing I had made my own changes in only one file (/etc/hosts), the rest of them just had this kind of change: The following file could not be merged automatically: /etc/rc.d/nisdomain Press Enter to edit this file in vi and resolve the conflicts manually... current version # $FreeBSD: src/etc/rc.d/nisdomain,v 1.5.2.2 2013/03/28 13:02:44 svnexp Exp $ === # $FreeBSD: releng/9.3/etc/rc.d/nisdomain 193197 2009-06-01 04:55:13Z dougb $ 9.3-RELEASE And then, after all these edits, I had to wade through entering y to Does this look reasonable (y/n)? for all these files! This is of course a necessary step to avoid being bitten by any === lines left behind by mistake (easy to do when you lose your concentration after more than a hundred files), but most of this step could be entirely avoided by automatically accepting the ID changes. (I amused myself by counting all files during this stage. I had to answer y to about 320 files, most of which only had changes in the ID.) This was my first upgrade from 8.4 to 9.3. I have 30 more to go before the 8.4 EoL this summer. I see 30 completely unnecessarily wasted hours in my future... And think of the combined lost man hours worldwide in these upgrades! Merge seems to be a really stupid choice for major upgrades. (Unless of course there is some flag to freebsd-update which makes this kind of change automatically accepted. But I see no such flag in man freebsd-update in 8.4, 9.3 or 10.1.) And yes, I could maybe copy most of /etc from the first upgraded server to the rest of them before upgrading, but that seems error-prone and not really a good solution for every FreeBSD user. -- Peter Olsson ___ 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
Re: There has to be a better way of merging /etc during a major freebsd-update
On Tue, Mar 10, 2015 at 12:45 PM, Peter Olsson list-freebsd-sta...@jyborn.se wrote: On Tue, Mar 10, 2015 at 10:17:18AM -0500, Adam Vande More wrote: On Tue, Mar 10, 2015 at 7:05 AM, Peter Olsson list-freebsd-sta...@jyborn.se wrote: This flag to mergemaster saved a lot of work when I did upgrades the old way, with cvsup and the make steps and then mergemaster: https://svnweb.freebsd.org/base?view=revisionrevision=221780 I'd venture to guess the script will work fine on older installs, but testing should be done first. -- Adam This seems like an excellent addition fo freebsd-update, how come it isn't added? It is added, no flag needed. You are running a version of freebsd-update which didn't have the feature(8.4). -- Adam ___ 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: There has to be a better way of merging /etc during a major freebsd-update
Don Lewis wrote on 03/11/2015 02:05: On 10 Mar, Miroslav Lachman wrote: This and some other problems with freebsd-update (hanging on the reboot after update) turns me back to using source compiled upgrades. I am compiling 10.1 right now to do the upgrades from 8.4 to 10.1 on 15 machines. I only do source upgrades, but I've still run into the hang on reboot problem with 10.1-STABLE. The problem seems to have gone away when I switched the root filesystem (there's actually only one filesystem on that machine) from SU+J to SU. It is a strange. I am not using SU+J on any machine, but some machines did hang on reboot after freebsd-update even on an older releases like 8.x or 9.x. Upgraded from 9.1 an 9.2 to 10.1 from sources and rebooted without problem. Miroslav Lachman ___ 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: There has to be a better way of merging /etc during a major freebsd-update
On 10 Mar, Miroslav Lachman wrote: This and some other problems with freebsd-update (hanging on the reboot after update) turns me back to using source compiled upgrades. I am compiling 10.1 right now to do the upgrades from 8.4 to 10.1 on 15 machines. I only do source upgrades, but I've still run into the hang on reboot problem with 10.1-STABLE. The problem seems to have gone away when I switched the root filesystem (there's actually only one filesystem on that machine) from SU+J to SU. ___ 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: No sound on 10.1-RELEASE
On Tue, 10 Mar 2015 12:15:22 +0100 Piotr Kubaj pku...@riseup.net wrote On 03/08/15 22:15, Chris H wrote: On Sun, 08 Mar 2015 19:14:47 +0100 Piotr Kubaj pku...@riseup.net wrote On 03/07/15 01:55, Chris H wrote: On Sat, 07 Mar 2015 00:08:38 +0100 Piotr Kubaj pku...@riseup.net wrote I've got MSI X99 motherboard and am using it with UEFI installation of 8---BIG-SNIP--- I'm not sure what may be wrong in dmesg.boot so I've uploaded it here: http://pastebin.com/pP0KXp4v Out of the 4 MSI boards I that I have; 3 run the same Realtek ALC893 HDA CODEC that yours does. The other, the Realtek ALC1200 HDA CODEC. All four of them work. But I notice 1 notable difference; that yours reports 2 HDA interfaces: hdac0: NVIDIA (0x0fbb) HDA Controller and hdac1: Intel Wellsburg HDA Controller I see hdac0 is disregarded (unused) whereas hdac1 is enabled, and functioning. I think your problems quite possibly lies in your (sound) system attempting to use the first HDA device in the list, which is effectively disabled. If you can determine a way to tell KDE, and friends to use the 2nd HDA. Things may well go as intended. None of the 4 MSI boards I have display 2 HDA's, as yours does. If you have any additional questions, you may well find the FreeBSD forums already have answers to your issue. This is where I originally found answers to my issues, when I first started using these boards. HTH KDE is definitely using OSS as chosen in its settings (I also use its own mixer which can do the same as Xfce's). I also use VLC's Phonon backend because Gstreamer is said to cause problems, but that also works on 3 other computers. I don't think it's KDE's fault, as it also happens when I kill KDE (service kdm4 stop) and do cat /dev/random /dev/dsp. Of course, I have vol and pcm maxed out. If your speakers are amplified, you should hear them pop, when the kernel finds, and creates/attaches the driver(s) to it. Same would be true, if you were wearing your headphones when bouncing your box. I'm quite sure that the sound system is defaulting the the first HDA presented. Which, in your case, is the one that is disabled/ non-operational. It's not KDE per se; but how the software decides, by default, to hook sound up. If you had a sound control panel available in KDE. You *should* be able to *choose* which sound device to use. In your case, provided it's even seen, it would be the *2nd* HDA. The sound control panel should also present the *status* of the sound device that it's using. Which, in your case, would indicate everything as being muted, and/or unavailable. On the box I'm writing this from, the HDA/CODEC is the Realtek ALC893, as yours is. I have it hooked up to a 700 watt external amplifier that I use as sound for my entire house. With the amplifier turned on, if I bounce the box (reboot) I hear a pop when the kernel detects/attaches to the sound chip. These are the relevant, and only sound related devices, created/listed in /dev: cd0 dsp0.0 dsp1.0 dsp2.0 dsp4.0 midistat mixer0 mixer1 mixer2 mixer4 sndstat If I'm not mistaken, you're probably running GENERIC, which has *also* loaded snd_hda, and possibly/probably, others. Which accounts for the additional HDA listing in dmesg(8). What I would do, if I were you, is build/install a custom kernel, stripped of any device not available on your MB. This is the first thing I do, after a fresh install, and, as you're discovering, for good reason. :) You should also find, by doing so, that your system performs much better, as a result. The *only* sound related listings I have in my KERNCONF file, is: speaker # PC beeper sound # geneic sound snd_hda # Realtec CODEC HDA Last, and only because I have to say it; you *are* sure that you have your headphones/speakers plugged into the *correct* jack, right? ;-) Hey! It happens. :) --Chris -- ___ 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: There has to be a better way of merging /etc during a major freebsd-update
On Tue, Mar 10, 2015 at 7:05 AM, Peter Olsson list-freebsd-sta...@jyborn.se wrote: This flag to mergemaster saved a lot of work when I did upgrades the old way, with cvsup and the make steps and then mergemaster: https://svnweb.freebsd.org/base?view=revisionrevision=221780 I'd venture to guess the script will work fine on older installs, but testing should be done first. -- Adam ___ 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: There has to be a better way of merging /etc during a major freebsd-update
On Tue, 10 Mar 2015 06:58:07 -0700 Chris H bsd-li...@bsdforge.com wrote On Tue, 10 Mar 2015 13:05:40 +0100 Peter Olsson list-freebsd-sta...@jyborn.se wrote This flag to mergemaster saved a lot of work when I did upgrades the old way, with cvsup and the make steps and then mergemaster: # Install the new file if it differs only by VCS Id ($FreeBSD) FREEBSD_ID=yes Is there some equivalent to this flag in freebsd-update/merge? Hello, Peter. This has probably been answered by now. But just in case. I believe what you're looking for is: mergemaster -vF This is my [chosen] default. I also find it helpful, as a safety net to cp _Rp /etc /eetc Ahem... On the off chance it wasn't obvious. The above line /should/ have read cp -Rp /etc /eetc ___^ Sorry. --Chris prior to the mergemaster(8) step. On a related note. I'm not very fond of mergemaster. As a result, I recently took on maintaining sysutils/etcmerge. sysutils/etcupdate, is also a [mergemaster] related port. Hope this helps. --Chris I just did my first major upgrade (8.4-RELEASE-p24 - 9.3-RELEASE-p10) with freebsd-update. It took more than .. -- Peter Olsson ___ 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 ___ 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: Suspected libkvm infinite loop
On Tuesday, March 10, 2015 10:17:07 AM Nick Frampton wrote: Hi, For the past several months, we have had an intermittent problem where a process calling kvm_openfiles(3) or kvm_getprocs(3) (not sure which) gets stuck in an infinite loop and goes to 100% cpu. We have just observed fstat -m do the same thing and suspect it may be the same problem. Our environment is a 10.1-RELEASE-p6 amd64 guest running in VirtualBox, with ufs root and zfs /home. Has anyone else experienced this? Is there anything we can do to investigate the problem further? Often loops using libkvm are due to programs using libkvm are trying to read kernel data structures while they are changing. However, if you use sysctls to fetch this data instead, you should be able to get a stable snapshot of the system state without getting stuck in a possible loop. I believe for libkvm to use sysctl instead of /dev/kmem you have to pass a NULL for the kernel and /dev/null for the core image. fstat -m should be doing that by default however, so if it is not that, can you ktrace fstat when it is spinning to see if it is spinning userland or in the kernel? If you see no activity via ktrace, then it is spinning in one of the two places without making any system calls, etc. You can attach to it with gdb to pause it, then see where gdb thinks it is. If gdb hangs attaching to it, then it is stuck in the kernel. If gdb attaches to it ok, then it is spinning in userland. Unfortunately, for gdb to be useful, you really need debug symbols. We don't currently provide those for release binaries or binaries provided via freebsd-update (though that is being worked on for 11.0). If you build from source, then the simplest way to get this is to add 'WITH_DEBUG_FILES=yes' to /etc/src.conf and rebuild your world without NO_CLEAN. If you are building from source and are able to reproduce with those binaries, then after attaching to the process with gdb, use 'bt' to see where it is hung and reply with that. If it is hanging in the kernel, then you will need to use the kernel debugger to see where it is hanging. The simplest way to do this is probably to force a crash via the debug.kdb.panic sysctl (set it to a non-zero value). You will then need to fire up kgdb on the crash dump after it reboots, switch to the fstat process via the 'proc pid' command and get a backtrace via 'bt'. -- 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: There has to be a better way of merging /etc during a major freebsd-update
On Tue, 10 Mar 2015 10:17:18 -0500 Adam Vande More amvandem...@gmail.com wrote On Tue, Mar 10, 2015 at 7:05 AM, Peter Olsson list-freebsd-sta...@jyborn.se wrote: This flag to mergemaster saved a lot of work when I did upgrades the old way, with cvsup and the make steps and then mergemaster: https://svnweb.freebsd.org/base?view=revisionrevision=221780 I'd venture to guess the script will work fine on older installs, but testing should be done first. Isn't that pretty much what the -F flag, I mentioned does? -FIf the files differ only by VCS Id ($FreeBSD) install the new file. In all honesty, I too got stuck answering y ~100 times, way back when. And decided I needed to either find a better way, or see if the mergemaster(8) had any secrets I wasn't aware of. ;-) --Chris -- Adam ___ 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
Re: There has to be a better way of merging /etc during a major freebsd-update
On Tue, Mar 10, 2015 at 2:01 PM, Chris H bsd-li...@bsdforge.com wrote: https://svnweb.freebsd.org/base?view=revisionrevision=221780 I'd venture to guess the script will work fine on older installs, but testing should be done first. Isn't that pretty much what the -F flag, I mentioned does? -FIf the files differ only by VCS Id ($FreeBSD) install the new file. Op asked for a freebsd-update solution which excludes any mergemaster solution short of at least a partial rewrite. -- Adam ___ 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: There has to be a better way of merging /etc during a major freebsd-update
On Tue, Mar 10, 2015 at 12:01:54PM -0700, Chris H wrote: On Tue, 10 Mar 2015 10:17:18 -0500 Adam Vande More amvandem...@gmail.com wrote On Tue, Mar 10, 2015 at 7:05 AM, Peter Olsson list-freebsd-sta...@jyborn.se wrote: This flag to mergemaster saved a lot of work when I did upgrades the old way, with cvsup and the make steps and then mergemaster: https://svnweb.freebsd.org/base?view=revisionrevision=221780 I'd venture to guess the script will work fine on older installs, but testing should be done first. Isn't that pretty much what the -F flag, I mentioned does? -FIf the files differ only by VCS Id ($FreeBSD) install the new file. In all honesty, I too got stuck answering y ~100 times, way back when. And decided I needed to either find a better way, or see if the mergemaster(8) had any secrets I wasn't aware of. ;-) I think you are mixing up mergemaster with merge. Freebsd-update uses merge, not mergemaster. (But I will try running freebsd-update without merging /etc, and use mergemaster -F instead. Should solve my problem.) Peter Olsson ___ 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: Suspected libkvm infinite loop
On Tue, Mar 10, 2015 at 02:10:09PM -0400, John Baldwin wrote:
On Tuesday, March 10, 2015 10:17:07 AM Nick Frampton wrote:
Hi,
For the past several months, we have had an intermittent problem where a
process calling kvm_openfiles(3) or kvm_getprocs(3) (not sure which) gets
stuck in an infinite loop and goes to 100% cpu. We have just observed
fstat -m do the same thing and suspect it may be the same problem.
Our environment is a 10.1-RELEASE-p6 amd64 guest running in VirtualBox, with
ufs root and zfs /home.
Has anyone else experienced this? Is there anything we can do to investigate
the problem further?
Often loops using libkvm are due to programs using libkvm are trying to read
kernel data structures while they are changing. However, if you use sysctls
to fetch this data instead, you should be able to get a stable snapshot of
the
system state without getting stuck in a possible loop. I believe for libkvm
to use sysctl instead of /dev/kmem you have to pass a NULL for the kernel and
/dev/null for the core image. fstat -m should be doing that by default
however, so if it is not that, can you ktrace fstat when it is spinning to
see
if it is spinning userland or in the kernel? If you see no activity via
ktrace, then it is spinning in one of the two places without making any
system
calls, etc. You can attach to it with gdb to pause it, then see where gdb
thinks it is. If gdb hangs attaching to it, then it is stuck in the kernel.
If gdb attaches to it ok, then it is spinning in userland. Unfortunately,
for
gdb to be useful, you really need debug symbols. We don't currently provide
those for release binaries or binaries provided via freebsd-update (though
that is being worked on for 11.0). If you build from source, then the
simplest way to get this is to add 'WITH_DEBUG_FILES=yes' to /etc/src.conf
and
rebuild your world without NO_CLEAN. If you are building from source and are
able to reproduce with those binaries, then after attaching to the process
with gdb, use 'bt' to see where it is hung and reply with that.
If it is hanging in the kernel, then you will need to use the kernel debugger
to see where it is hanging. The simplest way to do this is probably to force
a crash via the debug.kdb.panic sysctl (set it to a non-zero value). You
will
then need to fire up kgdb on the crash dump after it reboots, switch to the
fstat process via the 'proc pid' command and get a backtrace via 'bt'.
It sounds like this issue might be the one fixed in r272566: if the
KERN_PROC_ALL sysctl is read with an insufficiently large buffer, an
sbuf error return value could bubble up and be treated as ERESTART,
resulting in a loop.
This can be confirmed with something like
dtrace -n 'syscall:::entry /pid == $target/{@[probefunc] = count();} tick-3s
{exit(0);}' -p pid of looping proc
If the output consists solely of __sysctl, this bug is likely the
culprit.
-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
Re: There has to be a better way of merging /etc during a major freebsd-update
Quoth Peter Olsson list-freebsd-sta...@jyborn.se: (But I will try running freebsd-update without merging /etc, and use mergemaster -F instead. Should solve my problem.) I'm fairly sure this won't do what you want, and in fact won't work at all, unless your /etc is identical to the stock /etc installed from the ISO. (Which it isn't, of course.) installworld specifically avoids installing the files in /etc; then, when you run mergemaster, it installs the new versions of those files into a temporary directory and merges them with the existing /etc. freebsd-update works a little differently: because it doesn't have a source tree available, it has to fetch the stock versions of the files in /etc for the release you're upgrading from, so that it can patch them to the new release and then merge the changes into your current /etc. If you tell freebsd-update to install /etc without merging it will blindly update files you haven't changed (which is probably what you want) but (I think) will fail to update the files that you have changed, because it uses binary patches which won't apply to your modified versions. If you want a rather hackish solution, you could try something like this: - Rename /etc to /oldetc. - Find yourself a copy of the stock /etc for the version you are upgrading from. (tar -xpf base.txz --include /etc) - Run freebsd-update with /etc removed from the merge list. This will (should?) give you a stock /etc for the version you are upgrading to. - Rename /etc - /tmp/etc, /oldetc - /etc and run mergemaster with -t /tmp. Obviously I would script this if I was doing more than one or two machines. Ben ___ 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: Is there a linux_base available for RELENG_9?
On Tue, 10 Mar 2015 11:29:12 + Pete French petefre...@ingresso.co.uk wrote Indeed. Having read UPDATING prior to the attempted upgrade, I followed the advise to add 'compat.linux.osrelease=2.6.18' to sysctl.conf(5). And rebooted. If you rebooted then it should have been set - and you should not have needed to do it manually. But what turned out to be the *actual* solution, was to use sysctl(8). Applying it directly fixed it. :-) This should not have been necessary if you rebooted. I think you should try and find out what went wrong, as otherwise this will not work when you reboot next time and you will have to set it by hand on each reboot. It sounds like you did all the right things - nt sure why it didnt work for you. Have you rebooted since ? What is the value after rebooting now ? Hello Peter, and thank you for the reply. I only just now got a chance to bounce the box. I first sysctl compat.linux.osrelease=2.6.16 as that's what it reported, after the [kern/world] install, and before/during my attempts to install -c6. I then confirmed the setting via sysctl, then confirmed sysctl.conf(5) had the sysctl compat.linux.osrelease=2.6.18 setting listed. Bounced the box, and the sysctl.conf settings took. I have absolutely no idea why it wouldn't work as stated in UPDATING, or after loading it in sysctl.conf, yesterday. But it *apparently* works now. I think, under the circumstances, I'd do well to continue to monitor that setting for awhile. Fortunately, given it's FreeBSD, and a server, I won't have a need to bounce it very often. Thanks again, Peter, for taking the time to reply. --Chris -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 ___ 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
