Re: HEADS UP: set_rcvar() removed from rc.subr
On Sat, 14 Jan 2012 15:30:15 +
Chris Rees wrote:
> On 14 January 2012 15:16, Rainer Hurling wrote:
> > On 14.01.2012 10:05 (UTC+1), Doug Barton wrote:
> >>
> >> Howdy,
> >>
> >> Per discussion in freebsd-rc@, I have removed set_rcvar() from
> >> rc.subr. The concept of set_rcvar() was nice in theory, but the
> >> forks it creates are a drag on the startup process, which is
> >> especially noticeable on slower systems, such as embedded ones.
> >>
> >> I have no plans to MFC this change, so it should only affect users
> >> who are actually on 10-current. If you have scripts
> >> in /usr/local/etc/rc.d (which if you have ports installed you
> >> almost certainly do) ...
> >>
> >> to make the change by hand, change this:
> >>
> >> name=foo
> >> rcvar=`set_rcvar`
> >>
> >> to:
> >>
> >> name=foo
> >> rcvar=foo_enable
> >>
> >> I didn't bump PORTREVISIONs because the change only applies to
> >> HEAD. But all of the ports are updated, so if you can't figure out
> >> how to make the change, just reinstall it.
> >>
> >>
> >> Doug
> >
> >
> > Seems that ports-mgmt/tinderbox needs an update like this:
> >
> > files/patch-etc__rc.d__tinderd
> >
> > --- etc/rc.d/tinderd.orig 2011-11-20 07:01:09.0 +0100
> > +++ etc/rc.d/tinderd 2012-01-14 16:07:38.0 +0100
> > @@ -16,7 +16,7 @@
> > . /etc/rc.subr
> >
> > name="tinderd"
> > -rcvar=`set_rcvar`
> > +rcvar=tinderd_enable
> >
> > # read settings, set default values
> > load_rc_config "${name}"
> >
>
> I'm in the process of fixing this upstream.
>
> Chris
Chris, if you're working on fixing ports' rc files, here are a few
potential "gotchas" to be aware of:
I did a little quick-and-dirty sed substitution on all of my files
under /usr/local/etc/rc.d, plugging in "$filename_enable" in place of
`set_rcvar`. This works just fine for all but a few.
Filenames containing hyphens must have underscores substituted (e.g.,
avahi-daemon, etc.).
In a few cases, the rcvar is different from the filename in other
ways. The only ones I came across in my local installation were
sa-spamd (spamd_enable) and mysql-server (mysql_enable). There are
bound to be others like this in ports.
Overall, though, it was a simple matter to fix up the scripts I had
installed already. If I can be of any assistance in tidying up the
ports tree, let me know.
Conrad
--
Conrad J. Sabatier
conr...@cox.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: HEADS UP: set_rcvar() removed from rc.subr
On 01/15/2012 00:11, Conrad J. Sabatier wrote: > Chris, if you're working on fixing ports' rc files Thanks for taking a look at this. FYI, all of the rc.d scripts that are actually in the ports tree have already been fixed. The outliers at this point are scripts that are included in the distfiles. Some of those even have patches in the tree already, and they were updated in the same sweep. While we certainly try to enforce == PROVIDE == $name for scripts that are in the tree, it can't be guaranteed that this is true for scripts that are not, so if name=foo, rcvar should be foo_enable. hth, Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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: HEADS UP: set_rcvar() removed from rc.subr
On 15 January 2012 08:11, Conrad J. Sabatier wrote:
> On Sat, 14 Jan 2012 15:30:15 +
> Chris Rees wrote:
>
>> On 14 January 2012 15:16, Rainer Hurling wrote:
>> > On 14.01.2012 10:05 (UTC+1), Doug Barton wrote:
>> >>
>> >> Howdy,
>> >>
>> >> Per discussion in freebsd-rc@, I have removed set_rcvar() from
>> >> rc.subr. The concept of set_rcvar() was nice in theory, but the
>> >> forks it creates are a drag on the startup process, which is
>> >> especially noticeable on slower systems, such as embedded ones.
>> >>
>> >> I have no plans to MFC this change, so it should only affect users
>> >> who are actually on 10-current. If you have scripts
>> >> in /usr/local/etc/rc.d (which if you have ports installed you
>> >> almost certainly do) ...
>> >>
>> >> to make the change by hand, change this:
>> >>
>> >> name=foo
>> >> rcvar=`set_rcvar`
>> >>
>> >> to:
>> >>
>> >> name=foo
>> >> rcvar=foo_enable
>> >>
>> >> I didn't bump PORTREVISIONs because the change only applies to
>> >> HEAD. But all of the ports are updated, so if you can't figure out
>> >> how to make the change, just reinstall it.
>> >>
>> >>
>> >> Doug
>> >
>> >
>> > Seems that ports-mgmt/tinderbox needs an update like this:
>> >
>> > files/patch-etc__rc.d__tinderd
>> >
>> > --- etc/rc.d/tinderd.orig 2011-11-20 07:01:09.0 +0100
>> > +++ etc/rc.d/tinderd 2012-01-14 16:07:38.0 +0100
>> > @@ -16,7 +16,7 @@
>> > . /etc/rc.subr
>> >
>> > name="tinderd"
>> > -rcvar=`set_rcvar`
>> > +rcvar=tinderd_enable
>> >
>> > # read settings, set default values
>> > load_rc_config "${name}"
>> >
>>
>> I'm in the process of fixing this upstream.
>>
>> Chris
>
> Chris, if you're working on fixing ports' rc files, here are a few
> potential "gotchas" to be aware of:
>
> I did a little quick-and-dirty sed substitution on all of my files
> under /usr/local/etc/rc.d, plugging in "$filename_enable" in place of
> `set_rcvar`. This works just fine for all but a few.
>
> Filenames containing hyphens must have underscores substituted (e.g.,
> avahi-daemon, etc.).
>
> In a few cases, the rcvar is different from the filename in other
> ways. The only ones I came across in my local installation were
> sa-spamd (spamd_enable) and mysql-server (mysql_enable). There are
> bound to be others like this in ports.
>
> Overall, though, it was a simple matter to fix up the scripts I had
> installed already. If I can be of any assistance in tidying up the
> ports tree, let me know.
Don't thank me!
http://lists.freebsd.org/pipermail/cvs-ports/2012-January/233843.html
The only ones that will cause trouble are the ones provided by
upstream, but a quick sed like the one in ports-mgmt/tinderbox will do
the trick until upstream has finished.
Chris
___
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: HEADS UP: set_rcvar() removed from rc.subr
On Sun, 15 Jan 2012 00:40:36 -0800
Doug Barton wrote:
> On 01/15/2012 00:11, Conrad J. Sabatier wrote:
>
> > Chris, if you're working on fixing ports' rc files
>
> Thanks for taking a look at this. FYI, all of the rc.d scripts that
> are actually in the ports tree have already been fixed. The outliers
> at this point are scripts that are included in the distfiles. Some of
> those even have patches in the tree already, and they were updated in
> the same sweep.
>
> While we certainly try to enforce == PROVIDE == $name for
> scripts that are in the tree, it can't be guaranteed that this is true
> for scripts that are not, so if name=foo, rcvar should be foo_enable.
>
>
> hth,
>
> Doug
Well, that's good news. I wasn't sure how far along the work on this
had come yet.
I'm amazed in retrospect at the amount of discussion that took place
over this change, especially seeing as how the rcvar is hardcoded
elsewhere in these scripts anyway (I mean, how else to do
": ${foo_enable=NO}" without introducing yet another level of
indirection?). No wonder you were feeling a little ticked off earlier.
I thought your point about the time spent editing vs. the number of
times a script will actually be run was right on target.
Keep up the good work! :-)
Conrad
--
Conrad J. Sabatier
conr...@cox.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 15/01/2012 00:17 Doug Barton said the following: > On 01/14/2012 13:25, Steve Kargl wrote: >> Remove dvd insert music cd in drive, 'cdcontrol play'. The >> drive is reading the cd and 'cdcontrol status' indicates >> that it is playing. No sound. > > The way that this was explained to me (and I'm certainly no expert) is > that in the ATA-CAM world the only way the access method used by > cdcontrol will be able to play the music is if there is a direct (wired) > connection from the cd player to the sound card, like we had back in the > 80's. :) Other tools (such as vlc, mplayer, etc.) use the cdda:// > method of access, which does not rely on the wire. > > (As I understand it) this also explains why dvds work, but cds don't. Just a note: this has nothing to do with ATA-CAM. It has always been the case for cdcontrol play. -- 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: HEADS UP: set_rcvar() removed from rc.subr
On Sun, 15 Jan 2012 08:51:53 + Chris Rees wrote: [snip] > Don't thank me! > > http://lists.freebsd.org/pipermail/cvs-ports/2012-January/233843.html Wow! Doug has been a busy boy recently! :-) > The only ones that will cause trouble are the ones provided by > upstream, but a quick sed like the one in ports-mgmt/tinderbox will do > the trick until upstream has finished. > > Chris Cool, I'll check that out, too. Thanks! -- Conrad J. Sabatier conr...@cox.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, 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. Can you add (or document, if exist) functionality of recording audio playing? ___ 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: netisr ambigios policy
Hello, Freebsd-current. You wrote 14 января 2012 г., 17:31:04: > Is this a BUG? It looks mlike could be root of my problems with ULE and NetGraph... -- // Black Lion AKA Lev Serebryakov ___ 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/11/12 21:33, 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. Special thanks to iXsystems, Inc. for supporting this work. Comments and tests results are welcome! Big thanks to everybody who tried it! As soon as no regressions were found, I've just committed slightly updated code into the HEAD branch. I plan to merge it down to 8/9-STABLE in about two months. -- 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"
FEATURE: Implement 'make config' in /usr/src
It will be nice to create nice menu that will allow user disable/enable modules to build kernel cd /usr/src make config ___ 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: FEATURE: Implement 'make config' in /usr/src
15 января 2012 г. 21:24 пользователь Коньков Евгений написал: > It will be nice to create nice menu that will allow user > disable/enable modules to build kernel > > cd /usr/src > make config > FYI, I've tried to create POC of such thing, based on port.mk files; Kernel options almost similar to port's options, so I just converted LINT to file with options, and "make config" show me them. No saving, and no options comments were there :) ANyway, it's not big task should , to make it works, based on ports-options work. It would be nice, if options could declare hteir dependencies too. > > ___ > 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" > -- Regards, Alexander Yerenkow ___ 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: 9.0 umass problem
On Sunday 15 January 2012 18:35:59 George Mitchell wrote: > I have a USB compact flash reader-writer which is normally connected to > my computer all the time but rarely contains a compact flash card. Here > is a snippet from a verbose dmesg with FreeBSD 9.0-RC3: > > > ugen0.5: at usbus0 > umass0: on > usbus0 > umass0: SCSI over Bulk-Only; quirks = 0x4101 > umass0:2:0:-1: Attached to scbus2 > (probe0:umass-sim0:0:0:0): SCSI status error > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 1 0 0 ff 0 > (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error > (probe0:umass-sim0:0:0:0): SCSI status: Check Condition > (probe0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not > present) > (probe0:umass-sim0:0:0:0): Error 6, Unretryable error > (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? > ... > (probe0:umass-sim0:0:0:0): AutoSense failed > (probe0:umass-sim0:0:0:0): Error 5, Unretryable error > GEOM: new disk da0 > pass2 at umass-sim0 bus 0 scbus2 target 0 lun 0 > pass2: Removable Direct Access SCSI-0 device > pass2: 1.000MB/s transfers > ... > (da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR > (da0:umass-sim0:0:0:0): Retrying command > (da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR > (da0:umass-sim0:0:0:0): Retrying command > (da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR > (da0:umass-sim0:0:0:0): Retrying command > (da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR > (da0:umass-sim0:0:0:0): Retrying command > (da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR > (da0:umass-sim0:0:0:0): Error 5, Retries exhausted > (da0:umass-sim0:0:0:0): got CAM status 0x4 > (da0:umass-sim0:0:0:0): fatal error, failed to attach to device > (da0:umass-sim0:0:0:0): lost device - 0 outstanding > (da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR > (da0:umass-sim0:0:0:0): Error 5, Retries exhausted > (da0:umass-sim0:0:0:0): removing device entry > Opened disk da0 -> 5 > > > Everything works normally, but the above events take about half a > minute and bring the booting-up procedure to a halt while the > retries finish. Is there a umass quirk I could enable to speed up > whatever is happening here? usbconfig -d 0.5 dump_device_desc says: > > ugen0.5: at usbus0, cfg=0 md=HOST spd=FULL > (12Mbps) pwr=ON > > bLength = 0x0012 > bDescriptorType = 0x0001 > bcdUSB = 0x0200 > bDeviceClass = 0x > bDeviceSubClass = 0x > bDeviceProtocol = 0x > bMaxPacketSize0 = 0x0040 > idVendor = 0x05e3 > idProduct = 0x0703 > bcdDevice = 0x0032 > iManufacturer = 0x > iProduct = 0x0001 > iSerialNumber = 0x > bNumConfigurations = 0x0001 > > > Here's the corresponding dmesg output from 8.2-STABLE: > > ugen0.5: at usbus0 > umass0: on > usbus0 > umass0: SCSI over Bulk-Only; quirks = 0x > umass0: Get Max Lun not supported (USB_ERR_STALLED) > umass0:2:0:-1: Attached to scbus2 > (probe0:umass-sim0:0:0:0): SCSI status error > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 1 0 0 ff 0 > (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error > (probe0:umass-sim0:0:0:0): SCSI status: Check Condition > (probe0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not > present) > (probe0:umass-sim0:0:0:0): Error 6, Unretryable error > (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? > (probe0:umass-sim0:0:0:0): SCSI status error > (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error > (probe0:umass-sim0:0:0:0): SCSI status: Check Condition > (probe0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not > present) > (probe0:umass-sim0:0:0:0): Error 6, Unretryable error > GEOM: new disk da0 > pass2 at umass-sim0 bus 0 scbus2 target 0 lun 0 > pass2: Removable Direct Access SCSI-0 device > pass2: 1.000MB/s transfers > (da0:umass-sim0:0:0:0): SCSI status error > (da0:umass-sim0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 > (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error > (da0:umass-sim0:0:0:0): SCSI status: Check Condition > (da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) > (da0:umass-sim0:0:0:0): Error 6, Unretryable error > da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 > da0: Removable Direct Access SCSI-0 device > da0: 1.000MB/s transfers > da0: Attempt to query device size failed: NOT READY, Medium not present > (da0:umass-sim0:0:0:0): SCSI status error > (da0:umass-sim0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 > (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error > (da0:umass-sim0:0:0:0): SCSI status: Check Condition > (da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) > (da0:umass-sim0:0:0:0): Error 6, Unretryable error > Opened disk da0 -> 6 > (da0:umass-sim0:0:0:0): SCSI status error > (da0:umass-sim0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 > (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error > (da0:umass-sim0:0:0:0): S
Re: [RFT] Major snd_hda rewrite
On Thu, Jan 12, 2012 at 05:04:04PM +0400, Yuri Pankov wrote:
> 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: at cad 0 on hdac0
> > > hdaa0: at nid 1 on hdacc0
> > > pcm0: at nid 5 on hdaa0
> > > hdacc1: at cad 1 on hdac0
> > > hdaa1: at nid 1 on hdacc1
> > > pcm1: at nid 5 on hdaa1
> > > hdacc2: at cad 2 on hdac0
> > > hdaa2: at nid 1 on hdacc2
> > > pcm2: at nid 5 on hdaa2
> > > hdacc3: at cad 3 on hdac0
> > > hdaa3: at nid 1 on hdacc3
> > > pcm3: at nid 5 on hdaa3
> > > hdacc4: at cad 0 on hdac1
> > > hdaa4: at nid 1 on hdacc4
> > > pcm4: at nid 13 and 11 on hdaa4
> > > pcm5: at nid 15 and 24 on hdaa4
> > > pcm6: 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
I'm getting the following panic as soon as I log into GNOME (wasn't
running it before, so I'm not sure if it's a problem with new driver
version or not, will test if needed):
panic: Stop for not allocated stream (1/0)
The full core.txt is at:
https://www.xvoid.org/stuff/core.txt.0
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"
My thoughts on "bsdconfig"
I've had some time to poke around dialog, bsdinstall, host-config by Devin Teske, even old sysinstall. Part of that poking involved a simple proof-of-concept that can be found at http://fuzzwad.org/bsdconfig/ : # tar tzvf /tmp/bsdconfig.120115.tgz -rwxr-xr-x 0 root wheel5631 Jan 14 12:53 usr/sbin/bsdconfig drwxr-xr-x 0 root wheel 0 Jan 12 12:53 usr/share/examples/bsdconfig/ -rw-r--r-- 0 root wheel1553 Jan 14 11:56 usr/share/examples/bsdconfig/bsdconfigrc drwxr-xr-x 0 root wheel 0 Jan 14 12:08 usr/libexec/bsdconfig/ -rwxr-xr-x 0 root wheel1674 Jan 14 12:17 usr/libexec/bsdconfig/notimplemented then several items in the bsdconfig menu [install docs, user add, root passwd, timezone] execute the code from bsdinstall. This menu was taken directly from sysinstall and will change somewhat. I'm leaning towards using this above as a base, and then merging sections from host-config [with Devin's permission, of course] where it makes sense, as well as using existing bsdinstall sections where it makes sense, and adding my own as-yet-unwritten code for the rest. Also...what are everyone's thoughts on making this program i18n-ready right from the start? Lot of work? Not worth the effort? Must have? Don't need? Thanks. -- Ron McDowell San Antonio TX ___ 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/15/12 22:50, Yuri Pankov wrote:
On Thu, Jan 12, 2012 at 05:04:04PM +0400, Yuri Pankov wrote:
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: at cad 0 on hdac0
hdaa0: at nid 1 on hdacc0
pcm0: at nid 5 on hdaa0
hdacc1: at cad 1 on hdac0
hdaa1: at nid 1 on hdacc1
pcm1: at nid 5 on hdaa1
hdacc2: at cad 2 on hdac0
hdaa2: at nid 1 on hdacc2
pcm2: at nid 5 on hdaa2
hdacc3: at cad 3 on hdac0
hdaa3: at nid 1 on hdacc3
pcm3: at nid 5 on hdaa3
hdacc4: at cad 0 on hdac1
hdaa4: at nid 1 on hdacc4
pcm4: at nid 13 and 11 on hdaa4
pcm5: at nid 15 and 24 on hdaa4
pcm6: 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
I'm getting the following panic as soon as I log into GNOME (wasn't
running it before, so I'm not sure if it's a problem with new driver
version or not, will test if needed):
panic: Stop for not allocated stream (1/0)
The full core.txt is at:
https://www.xvoid.org/stuff/core.txt.0
Hmm. May be it is result of double stop. Please try this patch:
--- hdaa.c (revision 230179)
+++ hdaa.c (working copy)
@@ -1351,6 +1351,8 @@
struct hdaa_widget *w;
int i;
+ if ((ch->flags & HDAA_CHN_RUNNING) == 0)
+ return;
ch->flags &= ~HDAA_CHN_RUNNING;
HDAC_STREAM_STOP(device_get_parent(devinfo->dev), devinfo->dev,
ch->dir == PCMDIR_PLAY ? 1 : 0, ch->sid);
--
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 Mon, Jan 16, 2012 at 02:08:47AM +0200, Alexander Motin wrote:
> On 01/15/12 22:50, Yuri Pankov wrote:
> > On Thu, Jan 12, 2012 at 05:04:04PM +0400, Yuri Pankov wrote:
> >> 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: at cad 0 on hdac0
> hdaa0: at nid 1 on hdacc0
> pcm0: at nid 5 on hdaa0
> hdacc1: at cad 1 on hdac0
> hdaa1: at nid 1 on hdacc1
> pcm1: at nid 5 on hdaa1
> hdacc2: at cad 2 on hdac0
> hdaa2: at nid 1 on hdacc2
> pcm2: at nid 5 on hdaa2
> hdacc3: at cad 3 on hdac0
> hdaa3: at nid 1 on hdacc3
> pcm3: at nid 5 on hdaa3
> hdacc4: at cad 0 on hdac1
> hdaa4: at nid 1 on hdacc4
> pcm4: at nid 13 and 11 on hdaa4
> pcm5: at nid 15 and 24 on hdaa4
> pcm6: 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
> >
> > I'm getting the following panic as soon as I log into GNOME (wasn't
> > running it before, so I'm not sure if it's a problem with new driver
> > version or not, will test if needed):
> >
> > panic: Stop for not allocated stream (1/0)
> >
> > The full core.txt is at:
> >
> > https://www.xvoid.org/stuff/core.txt.0
>
> Hmm. May be it is result of double stop. Please try this patch:
>
> --- hdaa.c (revision 230179)
> +++ hdaa.c (working copy)
> @@ -1351,6 +1351,8 @@
> struct hdaa_widget *w;
> int i;
>
> + if ((ch->flags & HDAA_CHN_RUNNING) == 0)
> + return;
> ch->flags &= ~HDAA_CHN_RUNNING;
> HDAC_STREAM_STOP(device_get_parent(devinfo->dev), devinfo->dev,
> ch->dir == PCMDIR_PLAY ? 1 : 0, ch->sid);
Thanks, that did the trick.
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"
WTF mergemaster VCS Id checking?
Every time I run mergemaster, I have to manually confirm all of the local changes I have done to /etc (ie., state how to merge the temporary and existing files), even files have not changed in the upstream since the last mergemaster run (for example, temproot/etc/master.passwd virtually never changes). This behaviour is annoying, but I've already gotten used to it, and thought that it's the preferred one, to force a system administrator to review, periodically, all changes in /etc. I was surprized that today, mergemaster did not mention one of my changes in /etc: *** Temp ./etc/rc.d/bgfsck and installed have the same CVS Id, deleting So it now seems that it actually is intended for mergemaster to mention only files that have changed in the upstream since the last mergemaster run, but that funtionality fails. Apparently, some upstream files have the following VCS Id: # $FreeBSD$ and that anulls version checking. Recently, a lot of files in /etc (ie., rc.d files) have received full VCS Id strings, but not all. Someone ought to touch files in the subversion repository? So in either way you look at it, something is WRONG(TM). BTW, off-topic: 1. mergemaster outputs "CVS Id", while mergemaster's manpage contains "VCS Id". One of these is WRONG(TM). Which one? 2. mergemaster outputs "Use 'i' to install merged file". TODO: add a "the". 3. The BUGS section of mergemaster's manpage is redundant. ___ 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"
