Re: Data corruption over NFS in -current
--+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Stefan Bethke wrote on Wed, Jan 11, 2012 at 07:14:44PM +0100: Am 11.01.2012 um 17:57 schrieb Martin Cracauer: I'm sorry for the unspecific bug report but I thought a heads-up is better than none. $ uname -a FreeBSD wings.cons.org 10.0-CURRENT FreeBSD 10.0-CURRENT #2: Wed Dec 28 12:19:21 EST 2011 craca...@wings.cons.org:/usr/src/sys/amd64/compile/WINGS amd64 I'm sure Rick will want to know which NFS version, which client code (default new code I'm assuming) and which mount options... It's all default both in fstab and as reported by mount(8). This is a diskless PXE boot but the mount affected (usr) is not the root filesystem, so this should come in via fstab. BTW, my /usr/ports is another mount so the corruption is cross-mount (garbage from /usr/ports entering /usr). Appending nfsstat output. I am re-running things contiguously to see how reproducible this is. This machine was recently updated from a -current almost a year old, so it's its first time with the new NFS client code. Martin I've seen problems, but they were always related to programs running out of resources and not reporting it correctly - in dataless specialy if running out of memory and there is no swap available. btw, most of my servers are dataless (they boot via PXE but have local swap, var, etc) hth, danny I see filesystem corruption on NFS filesystems here. I am running a heavy shellscript that is noodling around with ascii files assembling them with awk and whatnot. Some actions are concurrent with up to 21 forks doing full-CPU load scripting. This machine is a K8 with a total of 8 cores, diskless NFS and memory filesystem for /tmp. I observe two problems: - for no reason whatsoever, some files change from my (user/group) cracauer/wheel to root/cracauer - the same files will later be corrupted. The beginning of the file is normal but then it has what looks like parts of /usr/ports, including our CVS files and binary junk, mostly zeros I did do some ports building lately but not at the same time that this problem manifested itself. I speculate some ports blocks were still resident in the filesystem buffer cache. Server is Linux. Martin -- %%% Martin Cracauer craca...@cons.org http://www.cons.org/cracauer/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 -- %%% Martin Cracauer craca...@cons.org http://www.cons.org/cracauer/ --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=l Client Info: Rpc Counts: Getattr SetattrLookup Readlink Read WriteCreate Remove 94392942513117 3637266 2577 40227237 2824593333832 304567 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 32522 5121 4856 20363 13954179035 0 3534382 MknodFsstatFsinfo PathConfCommit 5 21127240 3 2999521782 Rpc Info: TimedOut Invalid X Replies Retries Requests 0 0 0 0 167678419 Cache Info: Attr HitsMisses Lkup HitsMisses BioR HitsMisses BioW Hits Misses 1933340911 73265447 1123380719 3636242 90975094450509 4917135 2824593 BioRLHitsMisses BioD HitsMisses DirE HitsMisses Accs Hits Misses 54732346 2577599049142917352394 0 733726346 3534382 Server Info: Getattr SetattrLookup Readlink Read WriteCreate Remove 0 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 MknodFsstatFsinfo PathConfCommit 0 0 0 0 0 Server Ret-Failed 0 Server Faults 0 Server Cache Stats: Inprog Idem Non-idemMisses 0 0 0 0 Server Write Gathering: WriteOps WriteRPC Opsaved 0 0 0 --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ___ freebsd-current@freebsd.org mailing list
Re: Very fresh (two days ago) 10-current becomes completely unresponsive under load
Hello, Lev. You wrote 12 января 2012 г., 0:33:32: I'll try to find revision, which breaks ULE + NetGraph by binary search, but it takes some time as here is 590 revisions in head/sys between previous version I used (which works Ok with ULE) and current version (which doesn't). So, it should be ~9 iterations, and every iteration takes ~1 hour and I could not spend 9 hours in row on this task. Everything is much worse, that I thought. mpd built on old systems could not work on new ones and vice versa. I need to rebuild FULL system (not only kernel), update build box, rebuild ports, build image for router. It is about 5 hours per version. More than 512 revisions to search, about 10 iterations. FML. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
SCHED_ULE / NetGraph interaction broken somwhere between r227874 and r229818
Hello, Freebsd-current.
I have router, which connects to upstream ISP with mpd5 from ports
using PPPoE.
I've used SCHED_ULE for long time without nay problems. Under heavy
network load (router is not the fastest one -- 500Mhz Geode CPU) main
consumer of CPU was intr{swi1: netisr 0} thread. But it never
consumes more than 75% and even when upstream channel was
competently saturated router was accessible and responsive.
Latest good I'm sure about revision is about r227874 (yes, from
November 2011, I didn't update router's system for long time).
But revision r229818 behaves completely different: under network
load 100% CPU is consumed by ng_queue thread (which is never ever
consume any CPU on old system). System is unresponsive, DNS based on
this system returns timeouts, I could not log-in via SSH or seral
console (pause between login and passwd is so huge, that it leads to
timeouts), etc. LA jumps up to 20+, pre-started `top' updates screen
one time per 3-4 minutes, etc.
Switching to 4BSD helps. 4BSD works as usual: all CPU time is
interrupts and network thread, system is responsive under heaviest load,
normal operations of DNS, DHCP and hostapd.
There was NO significant changes in netgraph (svn log -r
227874:229818 sys/netgraph) and three changes (r229429, r228960,
r228718) in kern/sched_*.c files. But I'm not sure, that these
changes are only which could affect this behavior.
Now I'm trying to find bad revision by binary search, but it is
very hard to do: old mpd5 doesn't work on new kernel and vice versa,
so I need to rebuild whole world, update my build-box, rebuild ports
with new world, and only after that build NanoBSD image for my
router. It takes about 5 hours per iteration and here is more than
512 revisions, so it is about 10 iterations :(
I could provide any debug information from old and new systems.
--
// Black Lion AKA Lev Serebryakov l...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kernel config files outside of sys/${ARCH}/conf ?
On Thu, 12 Jan 2012 09:11:39 +0100
Luigi Rizzo ri...@iet.unipi.it wrote:
usr/sbin/config assumes that the kernel config file
lives in ${src_base}/sys/${arch}/conf , which means that
if you need to build a custom kernel one needs RW
access to that directory.
Any idea on how we can enable config to work in a
generic directory ?
I scanned the source code usr.sbin/config and found that
it uses hardwired paths -- specifically, it looks for
the kernel source tree in ../.. and has multiple
hardwired paths such as ../../conf/.
There is also a somewhat undocumented access to a
file called DEFAULTS that extends the configuration you pass.
Any objections to the addition of a -s option to config(8)
to specify the location of the source tree ?
Seems like a good idea to me as long as the old behavior is kept.
--
Gary Jennejohn (gj@)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: couldn't log on to my -CURRENT machine after upgrade to latest PAM
Don Lewis truck...@freebsd.org writes: building shared library libpam.so.5 make: don't know how to make openpam.3. Stop *** Error code 2 Ah, yes, the man pages are generated during the release process, so you either have to copy them over from the original contrib/openpam directory (or export the new sources on top of the existing directory) or build with -DNO_MAN. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kernel config files outside of sys/${ARCH}/conf ?
On Thu, Jan 12, 2012 at 10:16:53AM +0100, Gary Jennejohn wrote:
On Thu, 12 Jan 2012 09:11:39 +0100
Luigi Rizzo ri...@iet.unipi.it wrote:
usr/sbin/config assumes that the kernel config file
lives in ${src_base}/sys/${arch}/conf , which means that
if you need to build a custom kernel one needs RW
access to that directory.
Any idea on how we can enable config to work in a
generic directory ?
I scanned the source code usr.sbin/config and found that
it uses hardwired paths -- specifically, it looks for
the kernel source tree in ../.. and has multiple
hardwired paths such as ../../conf/.
There is also a somewhat undocumented access to a
file called DEFAULTS that extends the configuration you pass.
Any objections to the addition of a -s option to config(8)
to specify the location of the source tree ?
Seems like a good idea to me as long as the old behavior is kept.
of course :)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SCHED_ULE / NetGraph interaction broken somwhere between r227874 and r229818
on 12/01/2012 11:31 Lev Serebryakov said the following: Switching to 4BSD helps. 4BSD works as usual: all CPU time is interrupts and network thread, system is responsive under heaviest load, normal operations of DNS, DHCP and hostapd. How reproducible is this result? In other words, have you definitely ruled out all other factors besides the scheduler? -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kernel config files outside of sys/${ARCH}/conf ?
On Thu, Jan 12, 2012 at 2:06 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
On Thu, Jan 12, 2012 at 10:16:53AM +0100, Gary Jennejohn wrote:
On Thu, 12 Jan 2012 09:11:39 +0100
Luigi Rizzo ri...@iet.unipi.it wrote:
usr/sbin/config assumes that the kernel config file
lives in ${src_base}/sys/${arch}/conf , which means that
if you need to build a custom kernel one needs RW
access to that directory.
Any idea on how we can enable config to work in a
generic directory ?
I scanned the source code usr.sbin/config and found that
it uses hardwired paths -- specifically, it looks for
the kernel source tree in ../.. and has multiple
hardwired paths such as ../../conf/.
There is also a somewhat undocumented access to a
file called DEFAULTS that extends the configuration you pass.
Any objections to the addition of a -s option to config(8)
to specify the location of the source tree ?
Seems like a good idea to me as long as the old behavior is kept.
of course :)
Why not just set KERNCONFDIR?
Thanks,
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kernel config files outside of sys/${ARCH}/conf ?
On Thu, Jan 12, 2012 at 01:55:39AM -0800, Garrett Cooper wrote:
On Thu, Jan 12, 2012 at 2:06 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
On Thu, Jan 12, 2012 at 10:16:53AM +0100, Gary Jennejohn wrote:
On Thu, 12 Jan 2012 09:11:39 +0100
Luigi Rizzo ri...@iet.unipi.it wrote:
usr/sbin/config assumes that the kernel config file
lives in ${src_base}/sys/${arch}/conf , which means that
if you need to build a custom kernel one needs RW
access to that directory.
Any idea on how we can enable config to work in a
generic directory ?
I scanned the source code usr.sbin/config and found that
it uses hardwired paths -- specifically, it looks for
the kernel source tree in ../.. and has multiple
hardwired paths such as ../../conf/.
There is also a somewhat undocumented access to a
file called DEFAULTS that extends the configuration you pass.
Any objections to the addition of a -s option to config(8)
to specify the location of the source tree ?
Seems like a good idea to me as long as the old behavior is kept.
of course :)
Why not just set KERNCONFDIR?
The variable does not seem to be used by usr/sbin/config
cheers
luigi
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SCHED_ULE / NetGraph interaction broken somwhere between r227874 and r229818
Hello, Andriy. You wrote 12 января 2012 г., 13:54:41: Switching to 4BSD helps. 4BSD works as usual: all CPU time is interrupts and network thread, system is responsive under heaviest load, normal operations of DNS, DHCP and hostapd. How reproducible is this result? 100% In other words, have you definitely ruled out all other factors besides the scheduler? I have two almost-identical NanoBSD images which differs in one line in kernel config -- option about scheduler. Worlds are exactly the same, only kernels were rebuilt. Alexander Motin suggests, that switching scheduler could slightly change stack consumption, which triggers switching to ng_queue instead of direct calls. Really, here is diff between md5 of all files of one and other images: blob# diff ~lev/bsd-image.md5sums ~lev/ule-image.md5sums 74c74 MD5 (./boot/kernel/kernel) = 3bb0dd757628b5065d27ee5e7fc22eb3 --- MD5 (./boot/kernel/kernel) = 5ba379d2c73e1277566f4bbcb618a9f2 618c618 MD5 (./conf/base/var/log/userlog) = a827af82c1f780687706b19c7d94b29e --- MD5 (./conf/base/var/log/userlog) = fc289b66ae6cb23f9b24b694bf12157b 15678c15678 MD5 (./var/log/userlog) = a827af82c1f780687706b19c7d94b29e --- MD5 (./var/log/userlog) = fc289b66ae6cb23f9b24b694bf12157b -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SCHED_ULE / NetGraph interaction broken somwhere between r227874 and r229818
on 12/01/2012 12:05 Lev Serebryakov said the following: Hello, Andriy. You wrote 12 января 2012 г., 13:54:41: Switching to 4BSD helps. 4BSD works as usual: all CPU time is interrupts and network thread, system is responsive under heaviest load, normal operations of DNS, DHCP and hostapd. How reproducible is this result? 100% In other words, have you definitely ruled out all other factors besides the scheduler? I have two almost-identical NanoBSD images which differs in one line in kernel config -- option about scheduler. Worlds are exactly the same, only kernels were rebuilt. Alexander Motin suggests, that switching scheduler could slightly change stack consumption, which triggers switching to ng_queue instead of direct calls. Really, here is diff between md5 of all files of one and other images: Well, I mostly meant things like uptime, load level and pattern, etc. But what mav says makes sense. Also I remember seeing some very old reports about some strange issues with SCHED_ULE and dummynet. Some links that I found: http://lists.freebsd.org/pipermail/freebsd-stable/2008-October/046332.html http://dadv.livejournal.com/139366.html#cutid1 Given the last link, I wonder if binding the ng_queue thread to a particular CPU would change anything. blob# diff ~lev/bsd-image.md5sums ~lev/ule-image.md5sums 74c74 MD5 (./boot/kernel/kernel) = 3bb0dd757628b5065d27ee5e7fc22eb3 --- MD5 (./boot/kernel/kernel) = 5ba379d2c73e1277566f4bbcb618a9f2 618c618 MD5 (./conf/base/var/log/userlog) = a827af82c1f780687706b19c7d94b29e --- MD5 (./conf/base/var/log/userlog) = fc289b66ae6cb23f9b24b694bf12157b 15678c15678 MD5 (./var/log/userlog) = a827af82c1f780687706b19c7d94b29e --- MD5 (./var/log/userlog) = fc289b66ae6cb23f9b24b694bf12157b -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SCHED_ULE / NetGraph interaction broken somwhere between r227874 and r229818
Hello, Andriy. You wrote 12 января 2012 г., 14:29:57: Well, I mostly meant things like uptime, load level and pattern, etc. These are identical too -- freshly boot system, same load (torrent client on other box), only load -- traffic, as it is router, same upload/download speeds and peer counts in torrent client. But what mav says makes sense. I'm rebuilding system with ULE and KSTACK_PAGES=6 (3 is default on i386) now. Also I remember seeing some very old reports about some strange issues with SCHED_ULE and dummynet. Some links that I found: http://lists.freebsd.org/pipermail/freebsd-stable/2008-October/046332.html http://dadv.livejournal.com/139366.html#cutid1 Given the last link, I wonder if binding the ng_queue thread to a particular CPU would change anything. It is AMD Geode 500MHz. There is no ``particular CPU,'' there is only The CPU with The Core :) -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kernel config files outside of sys/${ARCH}/conf ?
On Thu, 12 Jan 2012 11:17:39 +0100
Luigi Rizzo ri...@iet.unipi.it wrote:
On Thu, Jan 12, 2012 at 01:55:39AM -0800, Garrett Cooper wrote:
On Thu, Jan 12, 2012 at 2:06 AM, Luigi Rizzo ri...@iet.unipi.it
wrote:
On Thu, Jan 12, 2012 at 10:16:53AM +0100, Gary Jennejohn wrote:
On Thu, 12 Jan 2012 09:11:39 +0100
Luigi Rizzo ri...@iet.unipi.it wrote:
usr/sbin/config assumes that the kernel config file
lives in ${src_base}/sys/${arch}/conf , which means that
if you need to build a custom kernel one needs RW
access to that directory.
Any idea on how we can enable config to work in a
generic directory ?
I scanned the source code usr.sbin/config and found that
it uses hardwired paths -- specifically, it looks for
the kernel source tree in ../.. and has multiple
hardwired paths such as ../../conf/.
There is also a somewhat undocumented access to a
file called DEFAULTS that extends the configuration you pass.
Any objections to the addition of a -s option to config(8)
to specify the location of the source tree ?
Seems like a good idea to me as long as the old behavior is
kept.
of course :)
Why not just set KERNCONFDIR?
The variable does not seem to be used by usr/sbin/config
cheers
luigi
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
freebsd-current-unsubscr...@freebsd.org
Hi,
ZRouter.org use just full path to config file
make KERNCONF=/path/to/config buildkernel
Main difference in: zrouter.org config don't use includes, but generate
full config.
WBW
--
Alexandr Rybalko r...@dlink.ua
aka Alex RAY r...@ddteam.net
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFT] Major snd_hda rewrite
On Wed, 11 Jan 2012 21:33:17 +0200 Alexander Motin m...@freebsd.org wrote: I would like request for testing of my work on further HDA sound driver improvement. [big snip] That is how it may look now in dmesg: hdac0: Intel 5 Series/3400 Series HDA Controller mem 0xf7ef4000-0xf7ef7fff irq 22 at device 27.0 on pci0 hdacc0: VIA VT1708S_0 HDA CODEC at cad 0 on hdac0 hdaa0: VIA VT1708S_0 HDA CODEC Audio Function Group at nid 1 on hdacc0 hdacc1: Intel Ibex Peak HDA CODEC at cad 3 on hdac0 hdaa1: Intel Ibex Peak HDA CODEC Audio Function Group at nid 1 on hdacc1 pcm0: VIA VT1708S_0 HDA CODEC PCM (Analog) at nid 28,29 and 26,30,27 on hdaa0 pcm1: VIA VT1708S_0 HDA CODEC PCM (Digital) at nid 32 on hdaa0 pcm2: Intel Ibex Peak HDA CODEC PCM (DisplayPort 8ch) at nid 6 on hdaa1 Patch can be found here: http://people.freebsd.org/~mav/hda.rewrite.patch Patch was generated for 10-CURRENT, but should apply to fresh 9-STABLE and 8-STABLE branches also. The patch doesn't apply cleanly to r230008; hdac.c.rej is 15661 bytes in size (mostly the section which deletes all the manufacturer-specific defines at the top of the file). After fixing that per hand I was able to make a kernel with which sound still works. Here the relevant bits from dmesg: hdac0: NVidia (Unknown) HDA Controller mem 0xfcffc000-0xfcff irq 18 at device 0.1 on pci1 hdac1: ATI SB600 HDA Controller mem 0xfe024000-0xfe027fff irq 16 at device 20.2 on pci0 hdacc0: NVidia GT21x HDA CODEC at cad 0 on hdac0 hdaa0: NVidia GT21x HDA CODEC Audio Function Group at nid 1 on hdacc0 pcm0: NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa0 hdacc1: NVidia GT21x HDA CODEC at cad 1 on hdac0 hdaa1: NVidia GT21x HDA CODEC Audio Function Group at nid 1 on hdacc1 pcm1: NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa1 hdacc2: NVidia GT21x HDA CODEC at cad 2 on hdac0 hdaa2: NVidia GT21x HDA CODEC Audio Function Group at nid 1 on hdacc2 pcm2: NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa2 hdacc3: NVidia GT21x HDA CODEC at cad 3 on hdac0 hdaa3: NVidia GT21x HDA CODEC Audio Function Group at nid 1 on hdacc3 pcm3: NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa3 hdacc4: Realtek ALC889A HDA CODEC at cad 0 on hdac1 hdaa4: Realtek ALC889A HDA CODEC Audio Function Group at nid 1 on hdacc4 pcm4: Realtek ALC889A HDA CODEC PCM (Rear Analog 7.1/2.0) at nid 20,22,21,23 and 24,26 on hdaa4 pcm5: Realtek ALC889A HDA CODEC PCM (Front Analog) at nid 27 and 25 on hdaa4 pcm6: Realtek ALC889A HDA CODEC PCM (Rear Digital) at nid 30 and 31 on hdaa4 I particularly like that the messages now show which jack corresponds to which pcm - makes deciding which jack to use much simpler. I'm using pcm4. -- Gary Jennejohn (gj@) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFT] Major snd_hda rewrite
On 01/12/12 12:45, Mickaël Maillot wrote: DisplayPort 8ch : does it mean that we now support 8 channel PCM over DisplayPort and HDMI ? i need this feature for DTS-HDMA and TrueHD with XBMC. I've never tried that because of quite old receiver. I just hope it may work. If you have respective hardware and usual HDMI/DisplayPort audio is working for you, we could try to make multichannel work. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SCHED_ULE / NetGraph interaction broken somwhere between r227874 and r229818
Hello, Andriy. You wrote 12 января 2012 г., 14:29:57: But what mav says makes sense. It is it -- stack size. Setting KSTACK_PAGES=6 fixes situation. Feature request: warn user when ng_queue is used due to stack limitations :) I know from mav, that sometime it is unavoidable (with protocols like L2TP), but, IMHO, it is good idea to warn user when it COULD be avoided. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kernel config files outside of sys/${ARCH}/conf ?
On Thu, Jan 12, 2012 at 12:22:50PM +0200, Aleksandr Rybalko wrote:
On Thu, 12 Jan 2012 11:17:39 +0100
Luigi Rizzo ri...@iet.unipi.it wrote:
On Thu, Jan 12, 2012 at 01:55:39AM -0800, Garrett Cooper wrote:
On Thu, Jan 12, 2012 at 2:06 AM, Luigi Rizzo ri...@iet.unipi.it
wrote:
On Thu, Jan 12, 2012 at 10:16:53AM +0100, Gary Jennejohn wrote:
On Thu, 12 Jan 2012 09:11:39 +0100
Luigi Rizzo ri...@iet.unipi.it wrote:
usr/sbin/config assumes that the kernel config file
lives in ${src_base}/sys/${arch}/conf , which means that
if you need to build a custom kernel one needs RW
access to that directory.
Any idea on how we can enable config to work in a
generic directory ?
I scanned the source code usr.sbin/config and found that
it uses hardwired paths -- specifically, it looks for
the kernel source tree in ../.. and has multiple
hardwired paths such as ../../conf/.
There is also a somewhat undocumented access to a
file called DEFAULTS that extends the configuration you pass.
Any objections to the addition of a -s option to config(8)
to specify the location of the source tree ?
Seems like a good idea to me as long as the old behavior is
kept.
of course :)
Why not just set KERNCONFDIR?
The variable does not seem to be used by usr/sbin/config
cheers
luigi
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
freebsd-current-unsubscr...@freebsd.org
Hi,
ZRouter.org use just full path to config file
make KERNCONF=/path/to/config buildkernel
It does not work:
ls -l /home/luigi/FreeBSD/pico9/qemu/PICOBSD.amd64
-rw-r--r-- 1 luigi wheel 4285 Jan 12 11:32
/home/luigi/FreeBSD/pico9/qemu/PICOBSD.amd64
make KERNCONF=/home/luigi/FreeBSD/pico9/qemu/PICOBSD.amd64 buildkernel
ERROR: Missing kernel configuration file(s)
(/home/luigi/FreeBSD/pico9/qemu/PICOBSD.amd64).
As i said, the hardwired paths in config suggest that there is
a requirement that the config lives under the source tree and
cannot be in a completely arbitrary position. My tests confirm that.
So, KERNCONF=/path/to/config only works for certain values of
/path/to/config .
Of course i may be wrong but if you have direct experience
in building a kernel whose config file name is /tmp/NOT_GENERIC
please let me know how you do it.
cheers
luigi
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SCHED_ULE / NetGraph interaction broken somwhere between r227874 and r229818
Hello, Lev. You wrote 12 января 2012 г., 15:00:20: But what mav says makes sense. It is it -- stack size. Setting KSTACK_PAGES=6 fixes situation. OOOPS. Not. After another 5 minutes ng_queue again consumes 100% CPU :( -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFT] Major snd_hda rewrite
2012/1/11 Alexander Motin m...@freebsd.org Hi. I would like request for testing of my work on further HDA sound driver improvement. List of changes done this time: - Huge old hdac driver was split into three independent pieces: HDA controller driver (hdac), HDA CODEC driver (hdacc) and HDA sudio function driver (hdaa). All drivers are completely independent and talk to each other only via NewBus interfaces. Using more NewBus bells and whistles allows to properly see HDA structure with standard system instruments, such as `devinfo -v`. Biggest driver file size now is 150K, instead of 240K before, and the code is much more clean. - Support for multichannel recording was added. While I've never seen it configured by default, UAA specification tells that it is possible. Now, as specification defines, driver checks input associations for pins with sequence numbers 14 and 15, and if found (usually) -- works as before, mixing signals together. If it doesn't, it configures input association as multichannel. I've found some CODECs doing strange things when configured for multichannel recording, but I've also found successfully working examples. - Signal tracer was improved to look for cases where several DACs/ADCs in CODEC can work with the same audio signal. If such case found, driver registers additional playback/record stream (channel) for the pcm device. Having more then one stream allows to avoid vchans use and so avoid extra conversion to pre-configured vchan rate and sample format. Not many CODECs allow this, especially on playback, but some do. - New controller streams reservation mechanism was implemented. That allows to have more pcm devices then streams supported by the controller (usually 4 in each direction). Now it limits only number of _simultaneously_ transferred audio streams, that is rarely reachable and properly reported if happens. - Codec pins and GPIO signals configuration was exported via set of writable sysctls. Another sysctl dev.hdaa.X.reconfig allows to trigger driver reconfiguration in run-time. The only requirement is that all pcm devices should be closed at the moment, as they will be destroyed and recreated. This should significantly simplify process of fixing CODEC configuration. It should be possible now even to write GUI to do it with few mouse clicks. - Driver now decodes pins location and connector type names. In some cases it allows to hint user where on the system case connectors, related to the pcm device, are located. Number of channels supported by pcm device, reported now (if it is not 2), should also make search easier. - Added fix for digital mic recording on some Asus laptops/netbooks. That is how it may look now in dmesg: hdac0: Intel 5 Series/3400 Series HDA Controller mem 0xf7ef4000-0xf7ef7fff irq 22 at device 27.0 on pci0 hdacc0: VIA VT1708S_0 HDA CODEC at cad 0 on hdac0 hdaa0: VIA VT1708S_0 HDA CODEC Audio Function Group at nid 1 on hdacc0 hdacc1: Intel Ibex Peak HDA CODEC at cad 3 on hdac0 hdaa1: Intel Ibex Peak HDA CODEC Audio Function Group at nid 1 on hdacc1 pcm0: VIA VT1708S_0 HDA CODEC PCM (Analog) at nid 28,29 and 26,30,27 on hdaa0 pcm1: VIA VT1708S_0 HDA CODEC PCM (Digital) at nid 32 on hdaa0 pcm2: Intel Ibex Peak HDA CODEC PCM (DisplayPort 8ch) at nid 6 on hdaa1 Patch can be found here: http://people.freebsd.org/~**mav/hda.rewrite.patchhttp://people.freebsd.org/~mav/hda.rewrite.patch Patch was generated for 10-CURRENT, but should apply to fresh 9-STABLE and 8-STABLE branches also. Special thanks to iXsystems, Inc. for supporting this work. Comments and tests results are welcome! Hi, first thank for your work ! i'll try the patch this week end. DisplayPort 8ch : does it mean that we now support 8 channel PCM over DisplayPort and HDMI ? i need this feature for DTS-HDMA and TrueHD with XBMC. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFT] Major snd_hda rewrite
On 01/12/12 12:52, Gary Jennejohn wrote: On Wed, 11 Jan 2012 21:33:17 +0200 Alexander Motinm...@freebsd.org wrote: I would like request for testing of my work on further HDA sound driver improvement. [big snip] Patch can be found here: http://people.freebsd.org/~mav/hda.rewrite.patch Patch was generated for 10-CURRENT, but should apply to fresh 9-STABLE and 8-STABLE branches also. The patch doesn't apply cleanly to r230008; hdac.c.rej is 15661 bytes in size (mostly the section which deletes all the manufacturer-specific defines at the top of the file). That is probably because of $FreeBSD$ macro resolution. Here is version with present value from 10-CURRENT SVN (sources from CVS or STABLE will need that patch line modified respectively) and some minor additional improvements like CODEC ODs and some more sysctls: http://people.freebsd.org/~mav/hda.rewrite2.patch After fixing that per hand I was able to make a kernel with which sound still works. Here the relevant bits from dmesg: hdac0:NVidia (Unknown) HDA Controller mem 0xfcffc000-0xfcff irq 18 at device 0.1 on pci1 hdac1:ATI SB600 HDA Controller mem 0xfe024000-0xfe027fff irq 16 at device 20.2 on pci0 hdacc0:NVidia GT21x HDA CODEC at cad 0 on hdac0 hdaa0:NVidia GT21x HDA CODEC Audio Function Group at nid 1 on hdacc0 pcm0:NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa0 hdacc1:NVidia GT21x HDA CODEC at cad 1 on hdac0 hdaa1:NVidia GT21x HDA CODEC Audio Function Group at nid 1 on hdacc1 pcm1:NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa1 hdacc2:NVidia GT21x HDA CODEC at cad 2 on hdac0 hdaa2:NVidia GT21x HDA CODEC Audio Function Group at nid 1 on hdacc2 pcm2:NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa2 hdacc3:NVidia GT21x HDA CODEC at cad 3 on hdac0 hdaa3:NVidia GT21x HDA CODEC Audio Function Group at nid 1 on hdacc3 pcm3:NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa3 hdacc4:Realtek ALC889A HDA CODEC at cad 0 on hdac1 hdaa4:Realtek ALC889A HDA CODEC Audio Function Group at nid 1 on hdacc4 pcm4:Realtek ALC889A HDA CODEC PCM (Rear Analog 7.1/2.0) at nid 20,22,21,23 and 24,26 on hdaa4 pcm5:Realtek ALC889A HDA CODEC PCM (Front Analog) at nid 27 and 25 on hdaa4 pcm6:Realtek ALC889A HDA CODEC PCM (Rear Digital) at nid 30 and 31 on hdaa4 I particularly like that the messages now show which jack corresponds to which pcm - makes deciding which jack to use much simpler. Thank you for the report. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kernel config files outside of sys/${ARCH}/conf ?
On Thu, 12 Jan 2012 12:17:57 +0100
Luigi Rizzo ri...@iet.unipi.it wrote:
On Thu, Jan 12, 2012 at 12:22:50PM +0200, Aleksandr Rybalko wrote:
On Thu, 12 Jan 2012 11:17:39 +0100
Luigi Rizzo ri...@iet.unipi.it wrote:
On Thu, Jan 12, 2012 at 01:55:39AM -0800, Garrett Cooper wrote:
On Thu, Jan 12, 2012 at 2:06 AM, Luigi Rizzo
ri...@iet.unipi.it wrote:
On Thu, Jan 12, 2012 at 10:16:53AM +0100, Gary Jennejohn
wrote:
On Thu, 12 Jan 2012 09:11:39 +0100
Luigi Rizzo ri...@iet.unipi.it wrote:
usr/sbin/config assumes that the kernel config file
lives in ${src_base}/sys/${arch}/conf , which means that
if you need to build a custom kernel one needs RW
access to that directory.
Any idea on how we can enable config to work in a
generic directory ?
I scanned the source code usr.sbin/config and found that
it uses hardwired paths -- specifically, it looks for
the kernel source tree in ../.. and has multiple
hardwired paths such as ../../conf/.
There is also a somewhat undocumented access to a
file called DEFAULTS that extends the configuration you
pass.
Any objections to the addition of a -s option to config
(8) to specify the location of the source tree ?
Seems like a good idea to me as long as the old behavior is
kept.
of course :)
Why not just set KERNCONFDIR?
The variable does not seem to be used by usr/sbin/config
cheers
luigi
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
freebsd-current-unsubscr...@freebsd.org
Hi,
ZRouter.org use just full path to config file
make KERNCONF=/path/to/config buildkernel
It does not work:
ls -l /home/luigi/FreeBSD/pico9/qemu/PICOBSD.amd64
-rw-r--r-- 1 luigi wheel 4285 Jan 12
11:32 /home/luigi/FreeBSD/pico9/qemu/PICOBSD.amd64
make KERNCONF=/home/luigi/FreeBSD/pico9/qemu/PICOBSD.amd64
buildkernel
ERROR: Missing kernel configuration file(s)
(/home/luigi/FreeBSD/pico9/qemu/PICOBSD.amd64).
As i said, the hardwired paths in config suggest that there is
a requirement that the config lives under the source tree and
cannot be in a completely arbitrary position. My tests confirm that.
So, KERNCONF=/path/to/config only works for certain values of
/path/to/config .
Of course i may be wrong but if you have direct experience
in building a kernel whose config file name is /tmp/NOT_GENERIC
please let me know how you do it.
cheers
luigi
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
freebsd-current-unsubscr...@freebsd.org
Oh, yes, sorry, I forgot about Makefile.inc1 changes.
Her it is:
Index: Makefile.inc1
===
--- Makefile.inc1 (revision 229577)
+++ Makefile.inc1 (working copy)
@@ -29,6 +29,7 @@
# /usr/share/mk. These include:
# obj depend all install clean cleandepend cleanobj
+SRC_ROOT=${.CURDIR}
# You are supposed to define both of these when calling Makefile.inc1
# directly. However, some old scripts don't. Cope for the moment, but
# issue a new warning for a transition period.
@@ -215,6 +216,7 @@
CROSSENV= MAKEOBJDIRPREFIX=${OBJTREE} \
MACHINE_ARCH=${TARGET_ARCH} \
MACHINE=${TARGET} \
+ SRC_ROOT=${.CURDIR} \
CPUTYPE=${TARGET_CPUTYPE}
.if ${OSRELDATE} 700044
CROSSENV+= AR=gnu-ar RANLIB=gnu-ranlib
@@ -381,6 +383,7 @@
mtree -deU -f ${.CURDIR}/etc/mtree/BIND.include.dist \
-p ${WORLDTMP}/usr/include /dev/null
.endif
+ mkdir -p ${WORLDTMP}/legacy/usr/include/lzma /dev/null
_legacy:
@echo
@echo
-- @@
-768,12 +771,19 @@ BUILDKERNELS=
INSTALLKERNEL=
.for _kernel in ${KERNCONF}
+__absolute=${_kernel:C/^\/.*$/abs/}
.if exists(${KERNCONFDIR}/${_kernel})
BUILDKERNELS+= ${_kernel}
.if empty(INSTALLKERNEL)
INSTALLKERNEL= ${_kernel}
.endif
+.elif exists(${_kernel}) ${__absolute} == abs
+# Kernel config with absolute path
+BUILDKERNELS+= ${_kernel}
+.if empty(INSTALLKERNEL)
+INSTALLKERNEL= ${_kernel}
.endif
+.endif
.endfor
#
@@ -798,17 +808,24 @@
@echo Kernel build for ${_kernel} started on `LC_ALL=C
date` @echo
-- @echo
=== ${_kernel}
- mkdir -p ${KRNLOBJDIR}
+ mkdir -p ${KRNLOBJDIR}/${_kernel}
.if !defined(NO_KERNELCONFIG)
@echo
@echo
-- @echo
stage 1: configuring the kernel @echo
Re: [RFT] Major snd_hda rewrite
On Wed, Jan 11, 2012 at 09:33:17PM +0200, Alexander Motin wrote:
Hi.
I would like request for testing of my work on further HDA sound driver
improvement.
[...]
Patch can be found here:
http://people.freebsd.org/~mav/hda.rewrite.patch
Patch was generated for 10-CURRENT, but should apply to fresh 9-STABLE
and 8-STABLE branches also.
Patch applied cleanly to r230008 using `svn patch`.
hdacc0: NVidia GT220 HDA CODEC at cad 0 on hdac0
hdaa0: NVidia GT220 HDA CODEC Audio Function Group at nid 1 on hdacc0
pcm0: NVidia GT220 HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa0
hdacc1: NVidia GT220 HDA CODEC at cad 1 on hdac0
hdaa1: NVidia GT220 HDA CODEC Audio Function Group at nid 1 on hdacc1
pcm1: NVidia GT220 HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa1
hdacc2: NVidia GT220 HDA CODEC at cad 2 on hdac0
hdaa2: NVidia GT220 HDA CODEC Audio Function Group at nid 1 on hdacc2
pcm2: NVidia GT220 HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa2
hdacc3: NVidia GT220 HDA CODEC at cad 3 on hdac0
hdaa3: NVidia GT220 HDA CODEC Audio Function Group at nid 1 on hdacc3
pcm3: NVidia GT220 HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa3
hdacc4: IDT 92HD75BX HDA CODEC at cad 0 on hdac1
hdaa4: IDT 92HD75BX HDA CODEC Audio Function Group at nid 1 on hdacc4
pcm4: IDT 92HD75BX HDA CODEC PCM (Analog) at nid 13 and 11 on hdaa4
pcm5: IDT 92HD75BX HDA CODEC PCM (Analog) at nid 15 and 24 on hdaa4
pcm6: IDT 92HD75BX HDA CODEC PCM (Front Digital) at nid 30 on hdaa4
pcm4 (builtin speakers) and pcm5 (headphones) seem to work fine, however
I'm not getting anything out of pcm0-pcm3 (connected to a TV via HDMI),
mplayer just pauses at the beggining, trying to cat anything to
/dev/dsp{0-3}.0 gives:
pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel dead
It was the same with the old driver and I'm not sure if it's (most
likely) my misconfiguration or a driver problem.
Thanks,
Yuri
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFT] Major snd_hda rewrite
On 12.01.2012 12:18 (UTC+1), Alexander Motin wrote: On 01/12/12 12:52, Gary Jennejohn wrote: On Wed, 11 Jan 2012 21:33:17 +0200 Alexander Motinm...@freebsd.org wrote: I would like request for testing of my work on further HDA sound driver improvement. [big snip] Patch can be found here: http://people.freebsd.org/~mav/hda.rewrite.patch Patch was generated for 10-CURRENT, but should apply to fresh 9-STABLE and 8-STABLE branches also. The patch doesn't apply cleanly to r230008; hdac.c.rej is 15661 bytes in size (mostly the section which deletes all the manufacturer-specific defines at the top of the file). That is probably because of $FreeBSD$ macro resolution. Here is version with present value from 10-CURRENT SVN (sources from CVS or STABLE will need that patch line modified respectively) and some minor additional improvements like CODEC ODs and some more sysctls: http://people.freebsd.org/~mav/hda.rewrite2.patch I just patched 10.0-CURRENT (amd64) r230009 against hda.rewrite2.patch. All went fine so far. My box is now running again with following messages: hdacc0: NVidia (Unknown) HDA CODEC at cad 0 on hdac0 hdaa0: NVidia (Unknown) HDA CODEC Audio Function Group at nid 1 on hdacc0 pcm0: NVidia (Unknown) HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa0 hdacc1: NVidia (Unknown) HDA CODEC at cad 1 on hdac0 hdaa1: NVidia (Unknown) HDA CODEC Audio Function Group at nid 1 on hdacc1 pcm1: NVidia (Unknown) HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa1 hdacc2: NVidia (Unknown) HDA CODEC at cad 2 on hdac0 hdaa2: NVidia (Unknown) HDA CODEC Audio Function Group at nid 1 on hdacc2 pcm2: NVidia (Unknown) HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa2 hdacc3: NVidia (Unknown) HDA CODEC at cad 3 on hdac0 hdaa3: NVidia (Unknown) HDA CODEC Audio Function Group at nid 1 on hdacc3 pcm3: NVidia (Unknown) HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa3 hdacc4: Realtek ALC892 HDA CODEC at cad 0 on hdac1 hdaa4: Realtek ALC892 HDA CODEC Audio Function Group at nid 1 on hdacc4 pcm4: Realtek ALC892 HDA CODEC PCM (Rear Analog 7.1/2.0) at nid 20,22,23,21 and 24,26 on hdaa4 pcm5: Realtek ALC892 HDA CODEC PCM (Front Analog) at nid 27 and 25 on hdaa4 pcm6: Realtek ALC892 HDA CODEC PCM (Rear Digital) at nid 30 on hdaa4 pcm7: Realtek ALC892 HDA CODEC PCM (Onboard Digital) at nid 17 on hdaa4 I am using pcm4 with 5.1 surround sound and pulseaudio. All seems to work fine :-) The mainboard is an Asus M4A88TD-V EVO/USB3, the graphics card is a NVidia GeForce GTS 450. The Realtek ALC892 is regocnized by the driver, the NVidia HDMI sound device is not. I am looking forward to the commit of this patch! After fixing that per hand I was able to make a kernel with which sound still works. Here the relevant bits from dmesg: hdac0:NVidia (Unknown) HDA Controller mem 0xfcffc000-0xfcff irq 18 at device 0.1 on pci1 hdac1:ATI SB600 HDA Controller mem 0xfe024000-0xfe027fff irq 16 at device 20.2 on pci0 hdacc0:NVidia GT21x HDA CODEC at cad 0 on hdac0 hdaa0:NVidia GT21x HDA CODEC Audio Function Group at nid 1 on hdacc0 pcm0:NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa0 hdacc1:NVidia GT21x HDA CODEC at cad 1 on hdac0 hdaa1:NVidia GT21x HDA CODEC Audio Function Group at nid 1 on hdacc1 pcm1:NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa1 hdacc2:NVidia GT21x HDA CODEC at cad 2 on hdac0 hdaa2:NVidia GT21x HDA CODEC Audio Function Group at nid 1 on hdacc2 pcm2:NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa2 hdacc3:NVidia GT21x HDA CODEC at cad 3 on hdac0 hdaa3:NVidia GT21x HDA CODEC Audio Function Group at nid 1 on hdacc3 pcm3:NVidia GT21x HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa3 hdacc4:Realtek ALC889A HDA CODEC at cad 0 on hdac1 hdaa4:Realtek ALC889A HDA CODEC Audio Function Group at nid 1 on hdacc4 pcm4:Realtek ALC889A HDA CODEC PCM (Rear Analog 7.1/2.0) at nid 20,22,21,23 and 24,26 on hdaa4 pcm5:Realtek ALC889A HDA CODEC PCM (Front Analog) at nid 27 and 25 on hdaa4 pcm6:Realtek ALC889A HDA CODEC PCM (Rear Digital) at nid 30 and 31 on hdaa4 I particularly like that the messages now show which jack corresponds to which pcm - makes deciding which jack to use much simpler. Thank you for the report. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bus dma: a flag/quirk for page zero
On Wednesday, January 11, 2012 2:56:47 pm Andriy Gapon wrote: on 11/01/2012 19:18 Andriy Gapon said the following: Actually, I think that on x86 we don't have to do anything special for any memory allocations that we do, including the bounce pages, as the page zero is excluded from phys_avail and is not available for normal use. After some additional thinking there is probably no reason to take advantage of this fact. First, it would increase differences with other platforms. Second, it would add a hidden dependency. So it's better to be explicit here. Agreed. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFT] Major snd_hda rewrite
On 01/12/12 14:18, Yuri Pankov wrote:
On Wed, Jan 11, 2012 at 09:33:17PM +0200, Alexander Motin wrote:
I would like request for testing of my work on further HDA sound driver
improvement.
[...]
Patch can be found here:
http://people.freebsd.org/~mav/hda.rewrite.patch
Patch was generated for 10-CURRENT, but should apply to fresh 9-STABLE
and 8-STABLE branches also.
Patch applied cleanly to r230008 using `svn patch`.
hdacc0:NVidia GT220 HDA CODEC at cad 0 on hdac0
hdaa0:NVidia GT220 HDA CODEC Audio Function Group at nid 1 on hdacc0
pcm0:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa0
hdacc1:NVidia GT220 HDA CODEC at cad 1 on hdac0
hdaa1:NVidia GT220 HDA CODEC Audio Function Group at nid 1 on hdacc1
pcm1:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa1
hdacc2:NVidia GT220 HDA CODEC at cad 2 on hdac0
hdaa2:NVidia GT220 HDA CODEC Audio Function Group at nid 1 on hdacc2
pcm2:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa2
hdacc3:NVidia GT220 HDA CODEC at cad 3 on hdac0
hdaa3:NVidia GT220 HDA CODEC Audio Function Group at nid 1 on hdacc3
pcm3:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa3
hdacc4:IDT 92HD75BX HDA CODEC at cad 0 on hdac1
hdaa4:IDT 92HD75BX HDA CODEC Audio Function Group at nid 1 on hdacc4
pcm4:IDT 92HD75BX HDA CODEC PCM (Analog) at nid 13 and 11 on hdaa4
pcm5:IDT 92HD75BX HDA CODEC PCM (Analog) at nid 15 and 24 on hdaa4
pcm6:IDT 92HD75BX HDA CODEC PCM (Front Digital) at nid 30 on hdaa4
pcm4 (builtin speakers) and pcm5 (headphones) seem to work fine, however
Thank you.
I'm not getting anything out of pcm0-pcm3 (connected to a TV via HDMI),
mplayer just pauses at the beggining, trying to cat anything to
/dev/dsp{0-3}.0 gives:
pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel dead
It was the same with the old driver and I'm not sure if it's (most
likely) my misconfiguration or a driver problem.
It sounds more like a driver problem. HDMI audio is still not very well
discovered area, and, according to ALSA reading, NVidia HDMI is also not
very standard. Probably I'll finally have to buy something to
experiment. What card do you have?
--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFT] Major snd_hda rewrite
On Thu, Jan 12, 2012 at 02:57:52PM +0200, Alexander Motin wrote:
On 01/12/12 14:18, Yuri Pankov wrote:
On Wed, Jan 11, 2012 at 09:33:17PM +0200, Alexander Motin wrote:
I would like request for testing of my work on further HDA sound driver
improvement.
[...]
Patch can be found here:
http://people.freebsd.org/~mav/hda.rewrite.patch
Patch was generated for 10-CURRENT, but should apply to fresh 9-STABLE
and 8-STABLE branches also.
Patch applied cleanly to r230008 using `svn patch`.
hdacc0:NVidia GT220 HDA CODEC at cad 0 on hdac0
hdaa0:NVidia GT220 HDA CODEC Audio Function Group at nid 1 on hdacc0
pcm0:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa0
hdacc1:NVidia GT220 HDA CODEC at cad 1 on hdac0
hdaa1:NVidia GT220 HDA CODEC Audio Function Group at nid 1 on hdacc1
pcm1:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa1
hdacc2:NVidia GT220 HDA CODEC at cad 2 on hdac0
hdaa2:NVidia GT220 HDA CODEC Audio Function Group at nid 1 on hdacc2
pcm2:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa2
hdacc3:NVidia GT220 HDA CODEC at cad 3 on hdac0
hdaa3:NVidia GT220 HDA CODEC Audio Function Group at nid 1 on hdacc3
pcm3:NVidia GT220 HDA CODEC PCM (DisplayPort 8ch) at nid 5 on hdaa3
hdacc4:IDT 92HD75BX HDA CODEC at cad 0 on hdac1
hdaa4:IDT 92HD75BX HDA CODEC Audio Function Group at nid 1 on hdacc4
pcm4:IDT 92HD75BX HDA CODEC PCM (Analog) at nid 13 and 11 on hdaa4
pcm5:IDT 92HD75BX HDA CODEC PCM (Analog) at nid 15 and 24 on hdaa4
pcm6:IDT 92HD75BX HDA CODEC PCM (Front Digital) at nid 30 on hdaa4
pcm4 (builtin speakers) and pcm5 (headphones) seem to work fine, however
Thank you.
I'm not getting anything out of pcm0-pcm3 (connected to a TV via HDMI),
mplayer just pauses at the beggining, trying to cat anything to
/dev/dsp{0-3}.0 gives:
pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel
dead
It was the same with the old driver and I'm not sure if it's (most
likely) my misconfiguration or a driver problem.
It sounds more like a driver problem. HDMI audio is still not very well
discovered area, and, according to ALSA reading, NVidia HDMI is also not
very standard. Probably I'll finally have to buy something to
experiment. What card do you have?
It's a laptop with nVidia Corporation GT216 [GeForce GT 230M] (as
identified by x11/nvidia-driver).
The verbose dmesg is at:
https://www.xvoid.org/stuff/spica.dmesg
Yuri
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FS hang when creating snapshots on a UFS SU+J setup
On Wed, Jan 11, 2012 at 11:12:35PM +0530, Gautam Mani wrote: Do let me know if I can try something further. I reproduced this again and here is the core.txt crash summary if it helps. http://pastebin.com/hTGMXX6A Thanks Gautam ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
FreeBSD 9 recompile ports
Greetings all and my apologies for cross posting! There seems to be a confusion regarding the ABI change in FreeBSD 9 and if this affects the usual upgrade path which includes a full port rebuild. The relevant post is here: http://forums.freebsd.org/showthread.php?t=28831 Frankly, I am also confused because I remember a relevant discussion a few months ago in the lists. Traditionally a major RELEASE upgrade requires a full ports rebuild, however this time there is no COMPAT_FREEBSD8 in GENERIC and most upgraded systems seem to be working fine. On the other hand this is stated in UPDATING: 20110828: Bump the shared library version numbers for libraries that do not use symbol versioning, have changed the ABI compared to stable/8 and which shared library version was not bumped. Done as part of 9.0-RELEASE cycle. Your input would be appreciated! Regards, -- George Kontostanos Aicom telecoms ltd ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Very fresh (two days ago) 10-current becomes completely unresponsive under load
.. this is why someone needs to put together an automated testing framework to build, run, test and report on this. Then, the warehouse-sized space and cooling needed for a few hundred machines, all doing automated regression testing. That's how a project fixes this. :-) The alternative is people keep up to date on -HEAD, every two or so weeks, and report issues. But we know how often that happens.. Adrian 2012/1/12 Lev Serebryakov l...@freebsd.org: Hello, Lev. You wrote 12 января 2012 г., 0:33:32: I'll try to find revision, which breaks ULE + NetGraph by binary search, but it takes some time as here is 590 revisions in head/sys between previous version I used (which works Ok with ULE) and current version (which doesn't). So, it should be ~9 iterations, and every iteration takes ~1 hour and I could not spend 9 hours in row on this task. Everything is much worse, that I thought. mpd built on old systems could not work on new ones and vice versa. I need to rebuild FULL system (not only kernel), update build box, rebuild ports, build image for router. It is about 5 hours per version. More than 512 revisions to search, about 10 iterations. FML. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: atkbc not loaded with ACPI enabled in 9.0
On Tuesday, January 03, 2012 7:31:59 pm Adrian Connolly wrote:
On 2012/01/04, at 0:37, John Baldwin j...@freebsd.org wrote:
On Monday, January 02, 2012 11:39:10 pm aconnoll...@yahoo.co.jp wrote:
I am running 9.0-RC3 on an Acer Aspire One D255E netbook. I have most of
the
functionality I want with one major exception, when I enable ACPI my
integrated keyboard drivers aren't loaded. Without ACPI I can use my
keyboard
as atkbdc and atkbd get loaded, (not psm though), but I have problems with
shutdown, time settings, power settings and usb controllers.
I have tried various ways of tackling this including:
1. including nooptions NEW_PCIB in kernel configuration, rebuilding and
installing no effect
2a. including debug.acpi.disabled=pci can't mount file system2b.
including debug.acpi.disabled=bus can't mount file system 2c.
including debug.acpi.disabled=children can't mount file system2d.
including debug.acpi.disabled=hostres
no effect
3. making the edit in r228961, rebuilding the kernel and installing no
effect
I have the latest bios (v3.x), but it features very few changeable
options.
Here's the output of my dmesg -aHere's the output of my devinfo -vrHere's
the output of my devinfo -ur
Any suggestions would be greatly appreciated.
Best regards,Adrian Connolly
Hmm, none of your attachments made it to the list. Can you post them at a
URL?
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
My apologies, here are the URLs of the output,
dmesg -a http://pastebin.com/rJhddt4A
devinfo -vr http://pastebin.com/MYd8wS7F
devinfo -ur http://pastebin.com/iBr62epv
Please try this patch:
Index: sys/dev/atkbdc/atkbdc_isa.c
===
--- atkbdc_isa.c(revision 230009)
+++ atkbdc_isa.c(working copy)
@@ -87,6 +87,7 @@ static driver_t atkbdc_isa_driver = {
static struct isa_pnp_id atkbdc_ids[] = {
{ 0x0303d041, Keyboard controller (i8042) }, /* PNP0303 */
+ { 0x0320d041, Keyboard controller (i8042) }, /* PNP0320 */
{ 0 }
};
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Can you use a USB3.0 hub?
On Thursday 12 January 2012 07:15:17 Kohji Okuno wrote: Hi, Can you use a USB3.0 hub? I tried a USB3.0 hub (BUFFALO BSH4A04U3BK). And I used 8-stable and PCI-E card (BUFFALO IFC-PCIE2U3) The hub is for only japanese market. The card is NEC’s 720200 chip http://www.buffalotech.com/products/accessories/interface-card-adapters/usb -30-pci-express-interface-card/ The kernel could not recognize USB3.0 HDD that connected to this hub as the following log. But, the kernel could reconize USB2.0 HDD that connected to this hub. Regards, Kohji Okuno Hi, There is a problem with USB 3.0 HUBs, most likely something related to the XHCI route string or USB HUB set depth. I don't have a USB 3.0 analyzer, so I cannot find this out quickly. If you could help debug, would be great. Here is a patch which you can put on top of 8/9- or 10- stable: http://svn.freebsd.org/changeset/base/230032 It fixes a few issues, but not all. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ctlstat not building with clang
Building world with clang now (as of r229997) no longer compiles because
ctlstat was imported into the tree. The error is:
clang -O2 -pipe -I/usr/src/usr.bin/ctlstat/../../sys -std=gnu99
-fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow
-Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs
-Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c
/usr/src/usr.bin/ctlstat/ctlstat.c
/usr/src/usr.bin/ctlstat/ctlstat.c:149:35: error: format string is not a
string literal (potentially insecure)
[-Werror,-Wformat-security]
fprintf(error ? stderr : stdout, ctlstat_usage);
^
1 error generated.
*** Error code 1
Stop in /usr/src/usr.bin/ctlstat
How do people feel about the attached patch that turns a call to fprintf to
fputs?
Index: ctlstat.c
===
--- ctlstat.c (revision 230026)
+++ ctlstat.c (working copy)
@@ -146,7 +146,7 @@
static void
usage(int error)
{
- fprintf(error ? stderr : stdout, ctlstat_usage);
+ fputs(ctlstat_usage, error ? stderr : stdout);
}
static int
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ctlstat not building with clang
On Thu, Jan 12, 2012 at 14:59:11 -0600, Dan McGregor wrote: Building world with clang now (as of r229997) no longer compiles because ctlstat was imported into the tree. The error is: clang -O2 -pipe -I/usr/src/usr.bin/ctlstat/../../sys -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/usr.bin/ctlstat/ctlstat.c /usr/src/usr.bin/ctlstat/ctlstat.c:149:35: error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security] fprintf(error ? stderr : stdout, ctlstat_usage); ^ 1 error generated. *** Error code 1 Stop in /usr/src/usr.bin/ctlstat How do people feel about the attached patch that turns a call to fprintf to fputs? Looks fine, I just committed it. Thanks, Ken -- Kenneth Merry k...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
FYI: 9.0-RELEASE announced...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 JFYI for those of you who aren't subscribed to the announce@ mailing list... 9.0-RELEASE is, finally, announced. The announcement message is available here: http://www.freebsd.org/releases/9.0R/announce.html Lots of you noticed that the 9.0-RELEASE ISO and memstick images appeared on the FTP sites a while ago. But as pointed out this release turned out to be an example of why the official policy is that it's not truly released until the announcement email gets sent out. I had not tested using sysinstall(8) to install pre-built packages from the DVD during my initial testing since we're sorta moving away from sysinstall(8). I had just tested installing the pre-built packages using pkg_add(8). Someone noticed sysinstall(8) misbehaved before I got the images put up on Bittorrent and the fix was simply adding one file to the DVD image that the new build infrastructure omitted since bsdinstall(8) doesn't use it. So I went ahead with replacing the DVD images on the FTP site. That's also why we waited longer than normal between the images appearing on the FTP sites and the announcement - we gave extra time to try and make sure the updated images got to all the FTP mirrors. Sorry about the screw-up. If you downloaded the amd64 and/or i386 DVD images before now you might want to check the checksums with the ones posted in the release announcement. The fix to make sysinstall(8) happy about installing from the DVD images was the *only* change made to the updated images. The bad images were never available via Bittorrent so if you got the images that way you wouldn't have a bad image. On behalf of the Release Engineering Team and the FreeBSD Developers we hope you enjoy 9.0-RELEASE. - -- Ken Smith - - From there to here, from here to | kensm...@buffalo.edu there, funny things are everywhere. | - Theodor Geisel | -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8PcpsACgkQ/G14VSmup/aLFgCfar7x43ViPu44M3eF8MzvYhOU /z0AnRN1jXDT1fS0UA9J0Trd5sRQcwdy =oU1m -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Can you use a USB3.0 hub?
Hi HPS, From: Hans Petter Selasky hsela...@c2i.net Subject: Re: Can you use a USB3.0 hub? Date: Thu, 12 Jan 2012 22:23:22 +0100 On Thursday 12 January 2012 07:15:17 Kohji Okuno wrote: Hi, Can you use a USB3.0 hub? I tried a USB3.0 hub (BUFFALO BSH4A04U3BK). And I used 8-stable and PCI-E card (BUFFALO IFC-PCIE2U3) The hub is for only japanese market. The card is NEC’s 720200 chip http://www.buffalotech.com/products/accessories/interface-card-adapters/usb -30-pci-express-interface-card/ The kernel could not recognize USB3.0 HDD that connected to this hub as the following log. But, the kernel could reconize USB2.0 HDD that connected to this hub. Regards, Kohji Okuno Hi, There is a problem with USB 3.0 HUBs, most likely something related to the XHCI route string or USB HUB set depth. I don't have a USB 3.0 analyzer, so I cannot find this out quickly. If you could help debug, would be great. Here is a patch which you can put on top of 8/9- or 10- stable: http://svn.freebsd.org/changeset/base/230032 It fixes a few issues, but not all. I think your commit is wrong about UPS_PORT_POWER_SS. - #define UPS_PORT_POWER_SS 0x0200 /* super-speed only */ #define UPS_LOW_SPEED 0x0200 + #define UPS_PORT_POWER_SS 0x2000 /* super-speed only */ #define UPS_LOW_SPEED 0x0200 Now, usb3.0 HDD was not able to recognize. I have USB 3.0 analyzer(LeCroy Voyager), so I can help debug. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
