Re: panic in sctp_del_addr_from_vrf() ?
ah, it's should be fixed now as per r250300. changes that caused this panic have been backed out. kit --- On Tue, 5/7/13, kit wrote: From: kit Subject: Re: panic in sctp_del_addr_from_vrf() ? To: "Andrey Smagin" , freebsd-current@freebsd.org Date: Tuesday, May 7, 2013, 8:59 AM not sure why. for my case, padaligining one of the rwlocks solved it. you may want to try the patch attached and see if it works for you. anyway, i'm filing a PR if nobody has done so already. thanks kit On Sat, May 04, 2013 at 09:22:23PM +0400, Andrey Smagin wrote: > > I have panic like your but in sctp_add_addr_to_vrf. I think need PR. My > panic screenshoot http://vvtlan.ru/panic1.jpg and second one > http://vvtlan.ru/panic2.jpg > > Суббота, 4 мая 2013, 20:55 +08:00 от kit : > > > got this panic when network interfaces were being unconfigured during > system shutdown. has anyone seen this? should i file a PR? > > thanks > kit > > test.yahoo.com dumped core - see /home/crash/vmcore.2 > > Sat May 4 20:43:55 MYT 2013 > > FreeBSD test.yahoo.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r250229: Sat May > 4 20:30:17 MYT 2013 kt...@test.yahoo.com:/tmp/obj/usr/src/sys/SHUTTLE > amd64 > > panic: page fault > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > . > <118>Writing entropy file:. > <118>. > <118>Terminated > <118>May 4 20:42:00 test syslogd: exiting on signal 15 > > Fatal trap 12: page fault while in kernel mode > cpuid = 4; apic id = 04 > fault virtual address = 0x8c > fault code = supervisor read data, page not present > instruction pointer = 0x20:0x8066e71c > stack pointer = 0x28:0xff82187fb5d0 > frame pointer = 0x28:0xff82187fb620 > code segment = base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 474 (wpa_supplicant) > trap number = 12 > panic: page fault > cpuid = 4 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xff82187fb190 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xff82187fb240 > panic() at panic+0x155/frame 0xff82187fb2c0 > trap_fatal() at trap_fatal+0x37a/frame 0xff82187fb320 > trap_pfault() at trap_pfault+0x257/frame 0xff82187fb3c0 > trap() at trap+0x43a/frame 0xff82187fb510 > calltrap() at calltrap+0x8/frame 0xff82187fb510 > --- trap 0xc, rip = 0x8066e71c, rsp = 0xff82187fb5d0, rbp = > 0xff82187fb620 --- > sctp_del_addr_from_vrf() at sctp_del_addr_from_vrf+0x7c/frame > 0xff82187fb620 > rt_newaddrmsg_fib() at rt_newaddrmsg_fib+0x44/frame 0xff82187fb6e0 > rtinit1() at rtinit1+0x57b/frame 0xff82187fb860 > in_scrubprefix() at in_scrubprefix+0x376/frame 0xff82187fb900 > rip_ctlinput() at rip_ctlinput+0x143/frame 0xff82187fb930 > pfctlinput() at pfctlinput+0x5c/frame 0xff82187fb960 > ifioctl() at ifioctl+0x7f2/frame 0xff82187fba20 > kern_ioctl() at kern_ioctl+0x22e/frame 0xff82187fba90 > sys_ioctl() at sys_ioctl+0x142/frame 0xff82187fbae0 > amd64_syscall() at amd64_syscall+0x2b4/frame 0xff82187fbbf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xff82187fbbf0 > --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x80122c26a, rsp = > 0x7fffdb18, rbp = 0x7fffdb90 --- > Uptime: 4m55s > > ___ > 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" > > > > Отправлено из мобильной Почты Mail.Ru ___ 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: panic in sctp_del_addr_from_vrf() ?
not sure why. for my case, padaligining one of the rwlocks solved it. you may want to try the patch attached and see if it works for you. anyway, i'm filing a PR if nobody has done so already. thanks kit On Sat, May 04, 2013 at 09:22:23PM +0400, Andrey Smagin wrote: > > I have panic like your but in sctp_add_addr_to_vrf. I think need PR. My > panic screenshoot http://vvtlan.ru/panic1.jpg and second one > http://vvtlan.ru/panic2.jpg > > Суббота, 4 мая 2013, 20:55 +08:00 от kit : > > > got this panic when network interfaces were being unconfigured during > system shutdown. has anyone seen this? should i file a PR? > > thanks > kit > > test.yahoo.com dumped core - see /home/crash/vmcore.2 > > Sat May 4 20:43:55 MYT 2013 > > FreeBSD test.yahoo.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r250229: Sat May > 4 20:30:17 MYT 2013 kt...@test.yahoo.com:/tmp/obj/usr/src/sys/SHUTTLE > amd64 > > panic: page fault > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > . > <118>Writing entropy file:. > <118>. > <118>Terminated > <118>May 4 20:42:00 test syslogd: exiting on signal 15 > > Fatal trap 12: page fault while in kernel mode > cpuid = 4; apic id = 04 > fault virtual address = 0x8c > fault code = supervisor read data, page not present > instruction pointer = 0x20:0x8066e71c > stack pointer = 0x28:0xff82187fb5d0 > frame pointer = 0x28:0xff82187fb620 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 474 (wpa_supplicant) > trap number = 12 > panic: page fault > cpuid = 4 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xff82187fb190 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xff82187fb240 > panic() at panic+0x155/frame 0xff82187fb2c0 > trap_fatal() at trap_fatal+0x37a/frame 0xff82187fb320 > trap_pfault() at trap_pfault+0x257/frame 0xff82187fb3c0 > trap() at trap+0x43a/frame 0xff82187fb510 > calltrap() at calltrap+0x8/frame 0xff82187fb510 > --- trap 0xc, rip = 0x8066e71c, rsp = 0xff82187fb5d0, rbp = > 0xff82187fb620 --- > sctp_del_addr_from_vrf() at sctp_del_addr_from_vrf+0x7c/frame > 0xff82187fb620 > rt_newaddrmsg_fib() at rt_newaddrmsg_fib+0x44/frame 0xff82187fb6e0 > rtinit1() at rtinit1+0x57b/frame 0xff82187fb860 > in_scrubprefix() at in_scrubprefix+0x376/frame 0xff82187fb900 > rip_ctlinput() at rip_ctlinput+0x143/frame 0xff82187fb930 > pfctlinput() at pfctlinput+0x5c/frame 0xff82187fb960 > ifioctl() at ifioctl+0x7f2/frame 0xff82187fba20 > kern_ioctl() at kern_ioctl+0x22e/frame 0xff82187fba90 > sys_ioctl() at sys_ioctl+0x142/frame 0xff82187fbae0 > amd64_syscall() at amd64_syscall+0x2b4/frame 0xff82187fbbf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xff82187fbbf0 > --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x80122c26a, rsp = > 0x7fffdb18, rbp = 0x7fffdb90 --- > Uptime: 4m55s > > ___ > 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" > > > > Отправлено из мобильной Почты Mail.Ru ___ 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: Audio Hints, T520?
On 05/06/13 04:49, Kevin Oberman wrote: On Sun, May 5, 2013 at 7:43 PM, Sean Bruno wrote: On Mon, 2013-05-06 at 03:25 +0200, Michael Schmiedgen wrote: Was trying to get the microphone working, but it seems to not quite be working. I got the same problem with my X220. Before the last Lenovo HDA quirk commits everything worked fine, but I had to set the default sound unit to 1. Now I do not need to set the sound unit, audio output works out of the box but recording does not work anymore. I fiddled with nid config but got bored after the fifth reboot. Ok, this smells like a recent regression. Could be. I'm running 9-STABLE, not current, on my T520. I can only say that the hints I provided work fine on my T520 on 9-stable. Sorry for making noise. Now it works for me. Only thing is I booted Windows in between, nothing else. Now Skype test call works, before it did not. Cheers Michael ___ 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: Problem with firewire disks with recent -CURRENT.
> > What happens if you re-add the xpt_periph variable to sbp_do_attach() ? > > ref: > http://svnweb.freebsd.org/base/head/sys/dev/firewire/sbp.c?r1=249468&r2=249467&pathrev=249468&diff_format=f > > see line 1089 > > Sean Tried that. No change, still get the same panic: mutex sbp not owned at /usr/src/sys/cam/cam_xpt.c:4549 . Richard ___ 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: Audio Hints, T520? [restating the problem]
On Mon, 2013-05-06 at 15:50 -0400, Zaphod Beeblebrox wrote: > On Mon, May 6, 2013 at 11:27 AM, Sean Bruno > wrote: > > Using a 4 position (combined headphone/mic) head set with the > T520 and > *no* device hints WORKS for recording and playback. > > Its the onboard microphone that is not working for me. No > device hints > provided in this thread have solved the onboard mic issue. > Audio > playback through the laptop speakers works just fine. > > > This would be a question for the hardware hacks among us ... is this > one of the onboard microphones that isn't? By that I mean ... one > where it uses the existing builtin speakers and some fancy DSP work to > construct a microphone? > > I don't think so. I see a "Stereo Mic" placement at the bottom of my screen that I seem to remember working. Sean p.s. example is not my laptop, but matches my layout: http://imageshack.us/a/img835/7921/t520i7.jpg signature.asc Description: This is a digitally signed message part
[head tinderbox] failure on arm/arm
TB --- 2013-05-06 18:20:17 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-05-06 18:20:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64
TB --- 2013-05-06 18:20:17 - starting HEAD tinderbox run for arm/arm
TB --- 2013-05-06 18:20:17 - cleaning the object tree
TB --- 2013-05-06 18:20:17 - /usr/local/bin/svn stat /src
TB --- 2013-05-06 18:20:22 - At svn revision 250303
TB --- 2013-05-06 18:20:23 - building world
TB --- 2013-05-06 18:20:23 - CROSS_BUILD_TESTING=YES
TB --- 2013-05-06 18:20:23 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-05-06 18:20:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-05-06 18:20:23 - SRCCONF=/dev/null
TB --- 2013-05-06 18:20:23 - TARGET=arm
TB --- 2013-05-06 18:20:23 - TARGET_ARCH=arm
TB --- 2013-05-06 18:20:23 - TZ=UTC
TB --- 2013-05-06 18:20:23 - __MAKE_CONF=/dev/null
TB --- 2013-05-06 18:20:23 - cd /src
TB --- 2013-05-06 18:20:23 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Mon May 6 18:20:27 UTC 2013
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Mon May 6 21:18:05 UTC 2013
TB --- 2013-05-06 21:18:05 - generating LINT kernel config
TB --- 2013-05-06 21:18:05 - cd /src/sys/arm/conf
TB --- 2013-05-06 21:18:05 - /usr/bin/make -B LINT
TB --- 2013-05-06 21:18:05 - cd /src/sys/arm/conf
TB --- 2013-05-06 21:18:05 - /usr/sbin/config -m LINT
TB --- 2013-05-06 21:18:05 - building LINT kernel
TB --- 2013-05-06 21:18:05 - CROSS_BUILD_TESTING=YES
TB --- 2013-05-06 21:18:05 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-05-06 21:18:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-05-06 21:18:05 - SRCCONF=/dev/null
TB --- 2013-05-06 21:18:05 - TARGET=arm
TB --- 2013-05-06 21:18:05 - TARGET_ARCH=arm
TB --- 2013-05-06 21:18:05 - TZ=UTC
TB --- 2013-05-06 21:18:05 - __MAKE_CONF=/dev/null
TB --- 2013-05-06 21:18:05 - cd /src
TB --- 2013-05-06 21:18:05 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Mon May 6 21:18:05 UTC 2013
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
~ ^ ~
/src/sys/arm/mv/common.c:1765:21: warning: comparison of unsigned expression >=
0 is always true [-Wtautological-compare]
if (wintab->remap >= 0 && win_cpu_can_remap(i) != 1) {
~ ^ ~
/src/sys/arm/mv/common.c:884:1: error: unused function 'decode_win_sdram_fixup'
[-Werror,-Wunused-function]
decode_win_sdram_fixup(void)
^
4 warnings and 1 error generated.
*** [common.o] Error code 1
Stop in /obj/arm.arm/src/sys/LINT.
*** [buildkernel] Error code 1
Stop in /src.
*** Error code 1
Stop in /src.
TB --- 2013-05-06 21:33:25 - WARNING: /usr/bin/make returned exit code 1
TB --- 2013-05-06 21:33:25 - ERROR: failed to build LINT kernel
TB --- 2013-05-06 21:33:25 - 9268.09 user 1640.77 system 11587.39 real
http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full
___
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: Audio Hints, T520? [restating the problem]
On Mon, May 6, 2013 at 11:27 AM, Sean Bruno wrote: > Using a 4 position (combined headphone/mic) head set with the T520 and > *no* device hints WORKS for recording and playback. > > Its the onboard microphone that is not working for me. No device hints > provided in this thread have solved the onboard mic issue. Audio > playback through the laptop speakers works just fine. This would be a question for the hardware hacks among us ... is this one of the onboard microphones that isn't? By that I mean ... one where it uses the existing builtin speakers and some fancy DSP work to construct a microphone? ___ 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: Problem with firewire disks with recent -CURRENT.
On Sun, 2013-05-05 at 13:31 -0500, rmt...@servalan.servalan.com wrote: > Tried upgrading one of my machines to -CURRENT yesterday and got the > following panic when the sbp code did its probing of all the firewire > devices: > > > sbp0: on firewire0 > sbp0: sbp_show_sdev_info: sbp0:0:0: ordered:1 type:14 EUI:00048304ee01f418 > node: > 1 speed:2 maxrec:8 > sbp0: sbp_show_sdev_info: sbp0:0:0 'DAT Optic Inc ' 'Master ' '40' > sbp0: sbp_show_sdev_info: sbp0:0:1: ordered:1 type:14 EUI:00048304ee01f418 > node: > 1 speed:2 maxrec:8 > sbp0: sbp_show_sdev_info: sbp0:0:1 'DAT Optic Inc ' 'Master ' '40' > sbp0: sbp_show_sdev_info: sbp0:1:0: ordered:1 type:1 EUI:00d080043f208713 > node:0 > speed:2 maxrec:8 > sbp0: sbp_show_sdev_info: sbp0:1:0 'EXABYTE ' 'VXA-3a ' '000201' > sbp1: on firewire1 > panic: mutex sbp not owned at /usr/src/sys/cam/cam_xpt.c:4549 > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xff81fe6837f0 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xff81fe6838a0 > vpanic() at vpanic+0x126/frame 0xff81fe6838e0 > panic() at panic+0x43/frame 0xff81fe683940 > __mtx_assert() at __mtx_assert+0xc2/frame 0xff81fe683950 > xpt_compile_path() at xpt_compile_path+0xa1/frame 0xff81fe6839a0 > xpt_create_path() at xpt_create_path+0x5b/frame 0xff81fe6839f0 > sbp_do_attach() at sbp_do_attach+0xe8/frame 0xff81fe683a30 > fwohci_txd() at fwohci_txd+0x378/frame 0xff81fe683a90 > fwohci_task_dma() at fwohci_task_dma+0x5d4/frame 0xff81fe683b30 > taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame 0xff81fe683b80 > taskqueue_thread_loop() at taskqueue_thread_loop+0x9b/frame 0xff81fe683bb0 > fork_exit() at fork_exit+0x84/frame 0xff81fe683bf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xff81fe683bf0 > --- trap 0, rip = 0, rsp = 0xff81fe683cb0, rbp = 0 --- > > (alas, it happened too early to get an actual core file, but dcons let me get > the console data logged to another machine.) > > I'm guessing the recent changes to cam_xpt and friends in mid-April might > be to blame... > > ___ > 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" What happens if you re-add the xpt_periph variable to sbp_do_attach() ? ref: http://svnweb.freebsd.org/base/head/sys/dev/firewire/sbp.c?r1=249468&r2=249467&pathrev=249468&diff_format=f see line 1089 Sean signature.asc Description: This is a digitally signed message part
Re: Audio Hints, T520? [restating the problem]
On Fri, 2013-05-03 at 21:14 -0700, Sean Bruno wrote: > Speaker/headphones working great on Current. > > Was trying to get the microphone working, but it seems to not quite be > working. > > By "not" working, there is no audio detected when recording. Is there > something in here that looks like a thing that I should adjust? > > http://people.freebsd.org/~sbruno/t520_sysctl_hdaa.txt > > Sean Using a 4 position (combined headphone/mic) head set with the T520 and *no* device hints WORKS for recording and playback. Its the onboard microphone that is not working for me. No device hints provided in this thread have solved the onboard mic issue. Audio playback through the laptop speakers works just fine. Sean signature.asc Description: This is a digitally signed message part
Re: kernel panic with _autoload_ nvidia driver
On Mon, May 06, 2013 at 06:16:34PM +0400, Stas Timokhin wrote: S> > S> > Can you please try the attached patch to kernel? S> > S> Test of patch with nvidia-driver-310.44_1 (builded by clang from S> > S> -CURRENT) passed successfully - booting module from /boot/loader.conf S> > S> is OK. S> > Sorry if I wasn't clear before. S> > Can you please test nvidia-driver-310.44_1 without any additional patches? S> > The nvidia-driver-310.44_1 itself contains import bugfix comparing to S> > nvidia-driver-310.44. S> nvidia-driver 310.44_1 work OK without your patch. Good. This means that _1 fixes this issue, too. -- Totus tuus, Glebius. ___ 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 panic with _autoload_ nvidia driver
Hello ! S> > Can you please try the attached patch to kernel? S> Test of patch with nvidia-driver-310.44_1 (builded by clang from S> -CURRENT) passed successfully - booting module from /boot/loader.conf S> is OK. Sorry if I wasn't clear before. Can you please test nvidia-driver-310.44_1 without any additional patches? The nvidia-driver-310.44_1 itself contains import bugfix comparing to nvidia-driver-310.44. nvidia-driver 310.44_1 work OK without your patch. ___ 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: Root on zfs fails to mount: "illegal option -- L"
Thank you for the answer. BOTH problems were indeed related to /etc/rc.d/mountlate, as they both disappeared after deleting mountlate. I then re-did an installworld & mergemaster, rebooted and system is fine now. I probably overlooked doing the installworld on host after having updated the jail environments. Thanks and Regards. - 10-Current-amd64-using ccache-portstree merged with marcuscom.gnome3 & xorg.devel -- View this message in context: http://freebsd.1045724.n5.nabble.com/Root-on-zfs-fails-to-mount-illegal-option-L-tp5809037p5809145.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ 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: Audio Hints, T520?
> >> provided by Kevin Oberman: > >> hint.hdac.0.cad0.nid35.config="as=2" > >> hint.hdac.0.cad0.nid27.config="as=2 seq=15" > > > > No success with these settings. There is no change to my ability to > > record with audacity. > > Sorry, on your system hdac.0 is HDMI audio. Try hdac.1 instead. > Hrm ... I set: hint.hdac.1.cad0.nid35.config="as=2" hint.hdac.1.cad0.nid27.config="as=2 seq=15" I see that the devices have been "merged" together now: $ mixer -f /dev/mixer0 Mixer vol is currently set to 100:100 Mixer pcm is currently set to 100:100 $ mixer -f /dev/mixer1 Mixer vol is currently set to 100:100 Mixer pcm is currently set to 100:100 $ mixer -f /dev/mixer2 Mixer vol is currently set to 95:95 Mixer pcm is currently set to 100:100 Mixer speaker is currently set to 100:100 Mixer mic is currently set to 61:61 Mixer rec is currently set to 52:52 Mixer monitor is currently set to 42:42 Recording source: mic $ mixer -f /dev/mixer3 mixer: /dev/mixer3: No such file or directory > Here are two pcm devices, one for each mic. Hints from above should join > them into one. Otherwise ,ake sure that you've tried to record from > both. And adjust rec volume on second one. > It doesn't look like the laptop is seeing any input from the onboard microphone. Connecting my cell phone headset to the jack on the laptop *works*. The laptop is not seeing any input from the onboard microphone. Sean signature.asc Description: This is a digitally signed message part
panic: pfsync_insert_state: st->sync_state == PFSYNC_S_NONE
Hi
We just experienced the following panic on r249172
It was coincident with a panic on our other router using carp+pfsync.
Unread portion of the kernel message buffer:
panic: pfsync_insert_state: st->sync_state == PFSYNC_S_NONE
cpuid = 12
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xff846b3c2950
vpanic() at vpanic+0xe9/frame 0xff846b3c2990
kassert_panic() at kassert_panic+0xd5/frame 0xff846b3c2a80
pfsync_insert_state() at pfsync_insert_state+0x10c/frame 0xff846b3c2ab0
pf_state_insert() at pf_state_insert+0x86a/frame 0xff846b3c2b30
pf_test_rule() at pf_test_rule+0x11a2/frame 0xff846b3c3040
pf_test() at pf_test+0x2216/frame 0xff846b3c3730
pf_check_in() at pf_check_in+0x27/frame 0xff846b3c3750
pfil_run_hooks() at pfil_run_hooks+0xd7/frame 0xff846b3c37f0
ip_input() at ip_input+0x2b7/frame 0xff846b3c3840
netisr_dispatch_src() at netisr_dispatch_src+0x153/frame 0xff846b3c38b0
ether_demux() at ether_demux+0x1c0/frame 0xff846b3c38e0
ether_nh_input() at ether_nh_input+0x277/frame 0xff846b3c3920
netisr_dispatch_src() at netisr_dispatch_src+0x153/frame 0xff846b3c3990
ether_demux() at ether_demux+0x83/frame 0xff846b3c39c0
ether_nh_input() at ether_nh_input+0x277/frame 0xff846b3c3a00
netisr_dispatch_src() at netisr_dispatch_src+0x153/frame 0xff846b3c3a70
igb_rxeof() at igb_rxeof+0x394/frame 0xff846b3c3ae0
igb_msix_que() at igb_msix_que+0xe9/frame 0xff846b3c3b20
intr_event_execute_handlers() at intr_event_execute_handlers+0x6a/frame
0xff846b3c3b50
ithread_loop() at ithread_loop+0x99/frame 0xff846b3c3ba0
fork_exit() at fork_exit+0x139/frame 0xff846b3c3bf0
fork_trampoline() at fork_trampoline+0xe/frame 0xff846b3c3bf0
--- trap 0, rip = 0, rsp = 0xff846b3c3cb0, rbp = 0 ---
#0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:264
264 if (textdump && textdump_pending) {
(kgdb) #0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:264
#1 0x80450076 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:447
#2 0x80450583 in vpanic (fmt=,
ap=) at /usr/src/sys/kern/kern_shutdown.c:754
#3 0x80450775 in kassert_panic (
fmt=0x806cb190 "%s: st->sync_state == PFSYNC_S_NONE")
at /usr/src/sys/kern/kern_shutdown.c:642
#4 0x8056573c in pfsync_insert_state (st=0xfe02adb98128)
at /usr/src/sys/netpfil/pf/if_pfsync.c:1645
#5 0x8056b6ba in pf_state_insert (kif=,
skw=0x0, sks=0xfe02c8caf688, s=0xfe02adb98128)
at /usr/src/sys/netpfil/pf/pf.c:1120
#6 0x8056ce32 in pf_test_rule (rm=0xff846b3c3690,
sm=0xff846b3c3688, direction=1, kif=0xfe0030dbd800,
m=0xfe0205416400, off=20, pd=0xff846b3c34c0,
am=0xff846b3c3698, rsm=0xff846b3c3680, inp=0x0)
at /usr/src/sys/netpfil/pf/pf.c:3513
#7 0x80570196 in pf_test (dir=1, ifp=,
m0=0xff846b3c37b8, inp=0x0) at /usr/src/sys/netpfil/pf/pf.c:5772
#8 0x80575d07 in pf_check_in (arg=,
m=0xff846b3c37b8, ifp=,
dir=, inp=)
at /usr/src/sys/netpfil/pf/pf_ioctl.c:3478
#9 0x805268a7 in pfil_run_hooks (ph=0x809f2fc0,
mp=0xff846b3c3810, ifp=0xfe0030f47800, dir=1, inp=0x0)
at /usr/src/sys/net/pfil.c:84
#10 0x80547717 in ip_input (m=0xfe0205416400)
at /usr/src/sys/netinet/ip_input.c:503
#11 0x80525853 in netisr_dispatch_src (proto=1, source=0,
m=) at /usr/src/sys/net/netisr.c:1013
#12 0x8051a9a0 in ether_demux (ifp=0xfe0030f47800,
m=0xfe0205416400) at /usr/src/sys/net/if_ethersubr.c:851
#13 0x8051acd7 in ether_nh_input (m=)
at /usr/src/sys/net/if_ethersubr.c:646
#14 0x80525853 in netisr_dispatch_src (proto=9, source=0,
m=) at /usr/src/sys/net/netisr.c:1013
#15 0x8051a863 in ether_demux (ifp=0xfe0030968000,
m=0xfe0205416400) at /usr/src/sys/net/if_ethersubr.c:760
#16 0x8051acd7 in ether_nh_input (m=)
at /usr/src/sys/net/if_ethersubr.c:646
#17 0x80525853 in netisr_dispatch_src (proto=9, source=0,
m=) at /usr/src/sys/net/netisr.c:1013
#18 0x80301294 in igb_rxeof (que=0xfe0030819a00, count=499,
done=0x0) at /usr/src/sys/dev/e1000/if_igb.c:4732
#19 0x803016a9 in igb_msix_que (arg=)
at /usr/src/sys/dev/e1000/if_igb.c:1590
#20 0x80425d2a in intr_event_execute_handlers (
p=, ie=0xfe0030883500)
at /usr/src/sys/kern/kern_intr.c:1263
#21 0x804273c9 in ithread_loop (arg=0xfe003088f0e0)
at /usr/src/sys/kern/kern_intr.c:1276
#22 0x804230f9 in fork_exit (
callout=0x80427330 , arg=0xfe003088f0e0,
frame=0xff846b3c3c00) at /usr/src/sys/kern/kern_fork.c:991
#23 0x805ff39e in fork_trampoline ()
at /usr/src/sys/amd64/amd64/exception.S:602
#24 0x in ?? ()
Ian
--
Ian Freislich
_
Re: files disappearing from ls on NFS
Hartmut Brandt wrote:
> Hi Rick,
>
> the patch doesn't help. So how can I help to fix that? Of course, I
> can use the work-around with oldnfs, but ...
>
Well, I plan on going through the readdir code and seeing if I can spot
a case that would break for small RPC replies. If I can find something,
I'll email you a patch for testing. (I can't seem to reproduce the problem
here.)
The mysterious part for me is why it has shown up recently, because there
hasn't been any recent change committed that seems like it could cause this.
(Maybe it is just a co-incidence that it showed up recently and the bug has
been there all along?)
I'll admit my worst fear is that is somehow caused by the switch to clang for
certain arches. If that is the case, it could take a long time to isolate.
rick
> harti
>
> -Original Message-
> From: Rick Macklem [mailto:rmack...@uoguelph.ca]
> Sent: Saturday, May 04, 2013 11:33 PM
> To: Brandt, Hartmut
> Cc: curr...@freebsd.org; Andrzej Tobola
> Subject: Re: files disappearing from ls on NFS
>
> Hartmut Brandt wrote:
> > On Fri, 3 May 2013, Rick Macklem wrote:
> >
> > RM>Ok, if you succeed in isolating the commit, that would be great.
> >
> > Hmm. I'm somewhat stuck. clang from yesterday can't compile clang
> > from
> > a month ago...
> >
> > harti
> >
> Oh well. You could try this patch (which is the one to fix readdir for
> union mounts), since I can see that VOP_VPTOCNP() will also be broken
> without it. (I can't see how that would break "ls", but it breaks
> __getcwd() and friends, so maybe it can affect "ls" somehow?)
>
> It's a cut/paste under windows, so I'm afraid the whitespace will be
> messed up, but it's pretty simple to apply by hand.
>
> Index: nfs_clvnops.c
> ===
> --- nfs_clvnops.c (revision 249568)
> +++ nfs_clvnops.c (working copy)
> @@ -2221,6 +2221,7 @@
> !NFS_TIMESPEC_COMPARE(&np->n_mtime, &vattr.va_mtime)) {
> mtx_unlock(&np->n_mtx);
> NFSINCRGLOBAL(newnfsstats.direofcache_hits);
> + *ap->a_eofflag = 1;
> return (0);
> } else
> mtx_unlock(&np->n_mtx); @@ -2233,8 +2234,10 @@
> tresid = uio->uio_resid;
> error = ncl_bioread(vp, uio, 0, ap->a_cred);
>
> - if (!error && uio->uio_resid == tresid)
> + if (!error && uio->uio_resid == tresid) {
> NFSINCRGLOBAL(newnfsstats.direofcache_misses);
> + *ap->a_eofflag = 1;
> + }
> return (error);
> }
>
> I haven't yet succeeded in reproducing the problem, but will be poking
> at it some more, rick
>
> > RM>
> > RM>rick
> > RM>
> > RM>> harti
> > RM>>
> > RM>> On Fri, 3 May 2013, Rick Macklem wrote:
> > RM>>
> > RM>> RM>Hartmut Brandt wrote:
> > RM>> RM>> Hi,
> > RM>> RM>>
> > RM>> RM>> I've updated one of my -current machines this week
> > (previous
> > RM>> update
> > RM>> RM>> was in
> > RM>> RM>> february). Now I see a strange effect (it seems only on
> > NFS
> > RM>> mounts):
> > RM>> RM>> ls or
> > RM>> RM>> even echo * will list only some files (strange enough the
> > first
> > RM>> files
> > RM>> RM>> from
> > RM>> RM>> the normal, alphabetically ordered list). If I change
> > something
> > RM>> in the
> > RM>> RM>> directory (delete a file or create a new one) for some
> > time
> > the
> > RM>> RM>> complete
> > RM>> RM>> listing will appear but after sime time (seconds to a
> > minute
> > or
> > RM>> so)
> > RM>> RM>> again
> > RM>> RM>> only part of the files is listed.
> > RM>> RM>>
> > RM>> RM>> A ktrace on ls /usr/src/lib/libc/gen shows that
> > getdirentries is
> > RM>> RM>> called
> > RM>> RM>> only once (returning 4096). For a full listing
> > getdirentries
> > is
> > RM>> called
> > RM>> RM>> 5
> > RM>> RM>> times with the last returning 0.
> > RM>> RM>>
> > RM>> RM>> I can still open files that are not listed if I know their
> > name,
> > RM>> RM>> though.
> > RM>> RM>>
> > RM>> RM>> The NFS server is a Windows 2008 server with an OpenText
> > NFS
> > RM>> Server
> > RM>> RM>> which
> > RM>> RM>> works without problems to all the other FreeBSD machines.
> > RM>> RM>>
> > RM>> RM>> So what could that be?
> > RM>> RM>>
> > RM>> RM>Someone else reported missing files returned via "ls"
> > recently,
> > RM>> when
> > RM>> RM>they used a small readdirsize (below 8K). I haven't yet had
> > a
> > RM>> change to try
> > RM>> RM>and reproduce it or do any snooping around.
> > RM>> RM>
> > RM>> RM>There haven't been any recent changes to readdir in the NFS
> > client,
> > RM>> RM>except a trivial one that adds a check for vnode type being
> > VDIR,
> > RM>> RM>so I don't see that it can be a recent NFS change.
> > RM>> RM>
> > RM>> RM>If you can increase the readdirsize, try that to see if it
> > avoids
> > RM>> RM>the problem. "nfsstat -m" shows you what the mount options
> > end
> > up
> > RM>> RM>being after doing the mount. The server might be limiting
> > the
> > RM>> readdirsize
> > RM>> RM>to 4K, so you should check, even if you specify a large
> > value
> > for
> > RM>> RM>the mount.
> > RM>> RM>
> > RM>> RM>rick
> > RM>> RM>
> > RM>
Re: Audio Hints, T520?
On 06.05.2013 15:12, Sean Bruno wrote: On Mon, 2013-05-06 at 09:27 +0300, Alexander Motin wrote: From information provided by Sean I can't see why added quirk for playback may affect recording in any way. More likely I would guess that change from two playback pcm/dsp devices to one, while still having two record ones, made hw.snd.default_unit less usable (because there is no choice of output devices for it any more). Respective two input pcm/dsp device may require to be chosen manually in recording application. Or you can try additional hints to join both mics in one dsp/pcm device, provided by Kevin Oberman: hint.hdac.0.cad0.nid35.config="as=2" hint.hdac.0.cad0.nid27.config="as=2 seq=15" No success with these settings. There is no change to my ability to record with audacity. Sorry, on your system hdac.0 is HDMI audio. Try hdac.1 instead. PS: When checking mixer, remember that there is separate mixer for every pcm/dsp device. Sean. you've provided output only for one. I guess that other (internal) microphone is on another pcm device/mixer. All the mixer settings: $ mixer -f /dev/mixer2 Mixer vol is currently set to 95:95 Mixer pcm is currently set to 100:100 Mixer speaker is currently set to 100:100 Mixer mic is currently set to 100:100 Mixer rec is currently set to 67:67 Recording source: mic $ mixer -f /dev/mixer3 Mixer rec is currently set to 1:1 Mixer monitor is currently set to 42:42 Recording source: monitor Here are two pcm devices, one for each mic. Hints from above should join them into one. Otherwise ,ake sure that you've tried to record from both. And adjust rec volume on second one. -- 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: Audio Hints, T520?
On Mon, 2013-05-06 at 09:27 +0300, Alexander Motin wrote: > From information provided by Sean I can't see why added quirk for > playback may affect recording in any way. More likely I would guess > that > change from two playback pcm/dsp devices to one, while still having > two > record ones, made hw.snd.default_unit less usable (because there is > no > choice of output devices for it any more). Respective two input > pcm/dsp > device may require to be chosen manually in recording application. Or > you can try additional hints to join both mics in one dsp/pcm device, > provided by Kevin Oberman: > hint.hdac.0.cad0.nid35.config="as=2" > hint.hdac.0.cad0.nid27.config="as=2 seq=15" No success with these settings. There is no change to my ability to record with audacity. > > PS: When checking mixer, remember that there is separate mixer for > every > pcm/dsp device. Sean. you've provided output only for one. I guess > that > other (internal) microphone is on another pcm device/mixer. All the mixer settings: $ mixer -f /dev/mixer0 Mixer vol is currently set to 100:100 Mixer pcm is currently set to 100:100 $ mixer -f /dev/mixer1 Mixer vol is currently set to 100:100 Mixer pcm is currently set to 100:100 $ mixer -f /dev/mixer2 Mixer vol is currently set to 95:95 Mixer pcm is currently set to 100:100 Mixer speaker is currently set to 100:100 Mixer mic is currently set to 100:100 Mixer rec is currently set to 67:67 Recording source: mic $ mixer -f /dev/mixer3 Mixer rec is currently set to 1:1 Mixer monitor is currently set to 42:42 Recording source: monitor Sean signature.asc Description: This is a digitally signed message part
Re: kernel panic with _autoload_ nvidia driver
On Mon, May 06, 2013 at 04:16:28PM +0400, Stas Timokhin wrote: S> > d>This problems appears about 4-6 months ago after updating of S> > -CURRENT host. S> > d> Unable to boot host with nvidia_load="YES" in loader.conf because panic. S> > d> But when nvidia driver loads manually via kldload, everything OK. S> > d> Nvidia driver version is 310.44 at this moment, but problem was and on S> > d> earlier version too. S> > d> Here is output of debugging (full version at S> > d> http://www.stasyan.com/devel/kern_crash_nvidia_autoload.txt) S> > Can you please try the attached patch to kernel? S> Test of patch with nvidia-driver-310.44_1 (builded by clang from S> -CURRENT) passed successfully - booting module from /boot/loader.conf S> is OK. Sorry if I wasn't clear before. Can you please test nvidia-driver-310.44_1 without any additional patches? The nvidia-driver-310.44_1 itself contains import bugfix comparing to nvidia-driver-310.44. -- Totus tuus, Glebius. ___ 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 panic with _autoload_ nvidia driver
Hello ! d>This problems appears about 4-6 months ago after updating of -CURRENT host. d> Unable to boot host with nvidia_load="YES" in loader.conf because panic. d> But when nvidia driver loads manually via kldload, everything OK. d> Nvidia driver version is 310.44 at this moment, but problem was and on d> earlier version too. d> Here is output of debugging (full version at d> http://www.stasyan.com/devel/kern_crash_nvidia_autoload.txt) Can you please try the attached patch to kernel? Test of patch with nvidia-driver-310.44_1 (builded by clang from -CURRENT) passed successfully - booting module from /boot/loader.conf is OK. Thank you ! ___ 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: Audio Hints, T520?
On Mon, 2013-05-06 at 11:31 +0400, Gleb Smirnoff wrote: > A very lame explanation then: may be Sean plugs simple 3-contact > minijack into > the socket, to get sound output via headset? But this jack plugged > disables > internal mic. I haven't been using any headset to this point. So, its the onboard microphone only and speakers. Sean signature.asc Description: This is a digitally signed message part
Re: x11/nvidia-driver-173 build failed on CURRENT
[redirecting to ports@, where this belongs]
On 2013-05-06 08:19, sig6247 wrote:
...
cc -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"173.14.35\"
-D__KERNEL__ -DNVRM -UDEBUG -U_DEBUG -DNDEBUG -O -Werror -D_KERNEL -DKLD_MODULE -nostdinc
-I/wrkdirs/usr/ports/x11/nvidia-driver-173/work/NVIDIA-FreeBSD-x86-173.14.35/src -I. -I@
-I@/contrib/altq -fno-common -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float
-ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector
-Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions
-Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare
-Wno-error-empty-body -Wno-error-parentheses-equality -c nvidia_os.c
nvidia_os.c:28:23: error: function declared with regparm(0) attribute was
previously declared without the regparm attribute
RM_STATUS NV_API_CALL os_alloc_contig_pages(
^
/wrkdirs/usr/ports/x11/nvidia-driver-173/work/NVIDIA-FreeBSD-x86-173.14.35/src/nv-freebsd.h:145:11:
note: previous declaration is here
RM_STATUS os_alloc_contig_pages(void **, U032);
^
Please try the attached patch. I am not sure if there are more driver
versions that include these inconsisent prototypes, but if anybody is
aware of them, we can adjust the ${NVVERSION} check a little.
-Dimitry
Index: x11/nvidia-driver/Makefile
===
--- x11/nvidia-driver/Makefile (revision 317139)
+++ x11/nvidia-driver/Makefile (working copy)
@@ -70,6 +70,10 @@
EXTRA_PATCHES+= ${FILESDIR}/security-patch-CVE-2012-4225
.endif
+.if ${NVVERSION} == 1731435
+EXTRA_PATCHES+= ${FILESDIR}/build-patch-nv_api_call
+.endif
+
OPTIONS_DEFINE= FREEBSD_AGP ACPI_PM LINUX DOCS
OPTIONS_DEFAULT= LINUX
Index: x11/nvidia-driver/files/build-patch-nv_api_call
===
--- x11/nvidia-driver/files/build-patch-nv_api_call (revision 0)
+++ x11/nvidia-driver/files/build-patch-nv_api_call (working copy)
@@ -0,0 +1,13 @@
+--- src/nv-freebsd.h.orig 2013-05-06 13:13:49.0 +0200
src/nv-freebsd.h 2013-05-06 13:16:38.0 +0200
+@@ -142,8 +142,8 @@
+
+ MALLOC_DECLARE(M_NVIDIA);
+
+-RM_STATUS os_alloc_contig_pages(void **, U032);
+-void os_free_contig_pages(void *, U032);
++RM_STATUS NV_API_CALL os_alloc_contig_pages(void **, U032);
++void NV_API_CALL os_free_contig_pages(void *, U032);
+
+ /*
+ * Enable/Disable support for FreeBSD's AGP GART driver. Please note that
___
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: Root on zfs fails to mount: "illegal option -- L"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 5/6/13 12:56 AM, Beeblebrox wrote: > After latest world / kernel update (r250260 Sun May 5, amd64) I > cannot mount root - message is: Addditional ABI support: linux > Clearing /tmp Updating motd *Mounting late file systems:mount: > illegal option -- L* Mounting /etc/fstab filesystems failed, > startup aborted System then falls into single-user mode. I believe that you have a stale mount(8) binary compared to your rc.d scripts. Did you do a full 'make buildworld' and 'make installworld' before doing mergemaster? You can probably remove /etc/rc.d/mountlate for now and use mergemaster -i to install it back later. [...] > I get consistent system freezes / screen blackouts after folders > mounting stage, and can only get around the issue by selecting > "safe mode" at the BTX loader. No idea here. What changes have you made before this happens? Cheers, -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJRh2pBAAoJEG80Jeu8UPuzc+4IALB+kAPQaoK4ZSv8Qy5KIFSE A4oaN5nuf5yQ0FqviaxXsnmOpJtFFFQh5mBek/qp4nNDjt67R2xnJeqLnU+U5yin Sz4chaX3r0MhwCFZMMN5+NWj5q/hZgdrQA8hMx27IT1wicmeS53DOoPFCyC2muop l87Cxr71E3OwJSs3FZ+FQRFEl2duu//rWoxhGTRx9R2CB8+iQtQpEuBak+9M/8u1 EALCBsxNHBr+83Mrz+oG3NmYzX8GI3PzDJvPhg/NZlB5RRCkqinopQVB5HMO3Op8 A8AXD+XSEKTnTMV5OfyMnimoSf2lDKd3aB9pdvu5npiq4rtzohoFcR/X7eYtVJc= =VeYq -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: Root on zfs fails to mount: "illegal option -- L"
Is this startup error message related to the problem? starting devd devd: can't open devctl device /dev/devctl: device busy /etc/rc: warning: failed to start devd crw--- 1 root wheel May 6 /dev/devctl - 10-Current-amd64-using ccache-portstree merged with marcuscom.gnome3 & xorg.devel -- View this message in context: http://freebsd.1045724.n5.nabble.com/Root-on-zfs-fails-to-mount-illegal-option-L-tp5809037p5809043.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ 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: Root on zfs fails to mount: "illegal option -- L"
Is this startup error message related to the problem? starting devd devd: can't open devctl device /dev/devctl: device busy /etc/rc: warning: failed to start devd crw--- 1 root wheel May 6 /dev/devctl - 10-Current-amd64-using ccache-portstree merged with marcuscom.gnome3 & xorg.devel -- View this message in context: http://freebsd.1045724.n5.nabble.com/Root-on-zfs-fails-to-mount-illegal-option-L-tp5809037p5809042.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ 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"
Root on zfs fails to mount: "illegal option -- L"
After latest world / kernel update (r250260 Sun May 5, amd64) I cannot mount root - message is: Addditional ABI support: linux Clearing /tmp Updating motd *Mounting late file systems:mount: illegal option -- L* Mounting /etc/fstab filesystems failed, startup aborted System then falls into single-user mode. * I have renamed /etc/fstab, so there is no fstab involvement in this error. # zfs list -> bsds /, bsds/var /var, bsds/usr /usr Other datasets in this zpool have been disabled by canmount=off. # df shows all existing zfs datasets mounted. bsds / devfs /dev bsds/usr /usr bsds/var /var I get consistent system freezes / screen blackouts after folders mounting stage, and can only get around the issue by selecting "safe mode" at the BTX loader. I suspect this is a mis-configured /etc/rc.d/ or /usr/local/etc/rc.d problem? Regards. - 10-Current-amd64-using ccache-portstree merged with marcuscom.gnome3 & xorg.devel -- View this message in context: http://freebsd.1045724.n5.nabble.com/Root-on-zfs-fails-to-mount-illegal-option-L-tp5809037.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ 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 panic with _autoload_ nvidia driver
On Mon, May 06, 2013 at 11:27:33AM +0400, Gleb Smirnoff wrote: T> On Sun, May 05, 2013 at 10:01:00AM +0400, de...@stasyan.com wrote: T> d>Hello ! T> d> T> d>This problems appears about 4-6 months ago after updating of -CURRENT host. T> d> Unable to boot host with nvidia_load="YES" in loader.conf because panic. T> d> But when nvidia driver loads manually via kldload, everything OK. T> d> Nvidia driver version is 310.44 at this moment, but problem was and on T> d> earlier version too. T> d> T> d> Here is output of debugging (full version at T> d> http://www.stasyan.com/devel/kern_crash_nvidia_autoload.txt) T> T> Can you please try the attached patch to kernel? Before testing patch, can you please confirm that you are running r316497 of the ports/x11/nvidia-driver or that DISTVERSION=310.44, PORTREVISION=1? -- Totus tuus, Glebius. ___ 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: Audio Hints, T520?
On Sun, May 05, 2013 at 07:45:45PM -0700, Kevin Oberman wrote: K> I have a T520. It has an internal mic. Not USB. It also has a standard K> headphone/mic jack. It works with a headset with a mic. It's a four contact K> jack: Left, right, mic, and common. A cell-phone headset will work fine. K> K> Have you tried the hints I supplied? They worked for me. A very lame explanation then: may be Sean plugs simple 3-contact minijack into the socket, to get sound output via headset? But this jack plugged disables internal mic. -- Totus tuus, Glebius. ___ 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 panic with _autoload_ nvidia driver
On Sun, May 05, 2013 at 10:01:00AM +0400, de...@stasyan.com wrote:
d>Hello !
d>
d>This problems appears about 4-6 months ago after updating of -CURRENT
host.
d> Unable to boot host with nvidia_load="YES" in loader.conf because panic.
d> But when nvidia driver loads manually via kldload, everything OK.
d> Nvidia driver version is 310.44 at this moment, but problem was and on
d> earlier version too.
d>
d> Here is output of debugging (full version at
d> http://www.stasyan.com/devel/kern_crash_nvidia_autoload.txt)
Can you please try the attached patch to kernel?
--
Totus tuus, Glebius.
Index: kern/kern_sysctl.c
===
--- kern/kern_sysctl.c (revision 249327)
+++ kern/kern_sysctl.c (working copy)
@@ -1406,7 +1406,7 @@ static int
sysctl_root(SYSCTL_HANDLER_ARGS)
{
struct sysctl_oid *oid;
- int error, indx, lvl;
+ int error, indx, lvl, giantlocked;
SYSCTL_ASSERT_XLOCKED();
@@ -1488,10 +1488,13 @@ sysctl_root(SYSCTL_HANDLER_ARGS)
oid->oid_running++;
SYSCTL_XUNLOCK();
- if (!(oid->oid_kind & CTLFLAG_MPSAFE))
+ if (!(oid->oid_kind & CTLFLAG_MPSAFE)) {
+ giantlocked = 1;
mtx_lock(&Giant);
+ } else
+ giantlocked = 0;
error = oid->oid_handler(oid, arg1, arg2, req);
- if (!(oid->oid_kind & CTLFLAG_MPSAFE))
+ if (giantlocked)
mtx_unlock(&Giant);
KFAIL_POINT_ERROR(_debug_fail_point, sysctl_running, error);
___
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"
