Re: [oi-dev] nVidia GPU Driver Update for Upcoming Release??
Hi Ken Ken, With each release we've shipped the latest nVidia driver available from their website, and we're hoping to do the same with oi_151. Regarding the license terms, initially the license stated binary redistribution was for Linux. But after I left a voicemail with NVidia's corporate headquarters, one part of the license was updated to include OpenSolaris: http://www.nvidia.com/object/nv_swlicense.html Linux/FreeBSD/OpenSolaris Exception. Notwithstanding the foregoing terms of Section 2.1.1, SOFTWARE designed exclusively for use on the Linux or FreeBSD operating systems, or other operating systems derived from the source code to these operating systems, may be copied and redistributed, provided that the binary files thereof are not modified in any way (except for unzipping of compressed files). The update was half-arsed, because it states Linux/FreeBSD/OpenSolaris Exception, then later in the paragraph states Linux or FreeBSD but not OpenSolaris. But we're interpreting this liberally. They never responded to my voicemail directly, but I'd like to think the timing of the change suggests they actually listened. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Gnome discusses going Linux-only
Hmm, if this is the case, would it be safe for me to start working on UI files for a GTK 3 version of the installer? I got a Gnome 3 environment here (on Linux, of course, but still) On Fri, May 20, 2011 at 9:12 AM, Alasdair Lumsden alasdai...@gmail.comwrote: On 20 May 2011, at 15:39, Shawn Thompson wrote: If you were under a rock yesterday, you may have heard that there are now discussions on the GNOME mailing list about making the Systemd init system a dependency of GNOME 3.2 ( http://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00432.html) in order to improve its integration with the system its placed atop. Unfortunately, if this were to occur, it would effectively (unless otherwise coded) end support for non-Linux based systems. Of course this might be a problem if this were to occur, since we are of course, a non-Linux based system, and active development of Gnome 2.x has effectively ended in favour of Gnome 3.x. Hi Shawn, There's been discussion on openindiana-discuss about this. We all of course hope this doesn't come to pass; it's not in the spirit of open source, and would seem counter-productive for the GNOME team to go down this route. So it comes to this, if on the oft-chance this ''does'' occur (alongside the shockwaves it'll probably send through the world), do we have any contingency plans on what we could do to get around it? Stay on Gnome 2.x? Switch desktops entirely? Make a new GTK3-based one? If this did go ahead, there are options available, such as coding around the issue/integrating SMF support as a replacement. Forking GNOME or making a new desktop environment is beyond the scope of the project at this point, unless a flurry of committed devs appeared. At the end of the day, if GNOME disappeared tomorrow, there are other desktop environments we could adopt (as if we didn't have enough work already!) Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] nVidia GPU Driver Update for Upcoming Release??
How hard would it be to make Nouveau work under OI? On Sun, May 22, 2011 at 10:52 AM, Ken Gunderson kgund...@teamcool.netwrote: On Sun, 2011-05-22 at 13:34 +0100, Alasdair Lumsden wrote: Hi Ken Ken, With each release we've shipped the latest nVidia driver available from their website, and we're hoping to do the same with oi_151. Regarding the license terms, initially the license stated binary redistribution was for Linux. But after I left a voicemail with NVidia's corporate headquarters, one part of the license was updated to include OpenSolaris: http://www.nvidia.com/object/nv_swlicense.html Linux/FreeBSD/OpenSolaris Exception. Notwithstanding the foregoing terms of Section 2.1.1, SOFTWARE designed exclusively for use on the Linux or FreeBSD operating systems, or other operating systems derived from the source code to these operating systems, may be copied and redistributed, provided that the binary files thereof are not modified in any way (except for unzipping of compressed files). The update was half-arsed, because it states Linux/FreeBSD/OpenSolaris Exception, then later in the paragraph states Linux or FreeBSD but not OpenSolaris. But we're interpreting this liberally. They never responded to my voicemail directly, but I'd like to think the timing of the change suggests they actually listened. Cheers, Alasdair Excellent :) Speaking of 151, I've been testing 148b as daily driver on the workstation front. I've filed a couple bug reports on Redmine, but left target version blank since I wasn't sure about the bug handling workflow. Should I be setting target at 151 or would that fall under auspices of triage person? -- Ken Gunderson kgund...@teamcool.net ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] 148b Audio Issues
Howdy: No audio here on 148b. I note a couple bugs filed in Redmine, but not listed as show stoppers for 151. Shouldn't this be on the radar for 151 based release or am I missing something? Sporting two different audio devices on this Tyan K8E based test rig: 1) AC97 nVidia onboard a) previously worked w/o problem on Open/Solaris. b) wants to use audio810 driver c) plays test sound via Multimedia Systems Selector d) played a cd via Sound Juicer once, but otherwise have been unable to repeat. e) scanpci output: pci bus 0x cardnum 0x04 function 0x00: vendor 0x10de device 0x0059 nVidia Corporation CK804 AC'97 Audio Controller CardVendor 0x10f1 card 0x2865 (Tyan Computer, Tomcat K8E (S2865)) STATUS0x00b0 COMMAND 0x0007 CLASS 0x04 0x01 0x00 REVISION 0xa2 BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x00 BASE0 0xf000 SIZE 256 I/O BASE1 0xec00 SIZE 256 I/O BASE2 0xfebfd000 SIZE 4096 MEM BASEROM 0x addr 0x MAX_LAT 0x05 MIN_GNT 0x02 INT_PIN 0x01 INT_LINE 0x0b 2) Audiotrak Prodigy HD. Envy24 based PCI add in card. a) Never worked on any previous Open/Solaris b) wants to use audiohd driver c) does not play test sound via Multimedia Systems Selector d) but apparently might should work per hcl wiki note pertaining to generic Envy24. e) scanpci output: pci bus 0x0001 cardnum 0x09 function 0x00: vendor 0x1412 device 0x1724 VIA Technologies Inc. VT1720/24 [Envy24PT/HT] PCI Multi-Channel Audio Controller CardVendor 0x3137 card 0x4154 (Card unknown) STATUS0x0210 COMMAND 0x0005 CLASS 0x04 0x01 0x00 REVISION 0x01 BIST 0x00 HEADER 0x00 LATENCY 0x20 CACHE 0x00 BASE0 0xa400 SIZE 32 I/O BASE1 0xa000 SIZE 128 I/O BASEROM 0x addr 0x MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x07 That the onboard succeeds in playing test sound but I cannot get audio playback from neither Rhythmbox, Totem, or Juicer seems odd. The Audiotrak is a relatively high grade two channel card targeting more audiophile rather than gamer type end user. I'd be willing put on loan to US based driver developer if it would help polish up support for Envy24 based cards. I also have another Envy24 based card (Chaintech). -- Ken Gunderson kgund...@teamcool.net ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] nVidia GPU Driver Update for Upcoming Release??
On Sun, 2011-05-22 at 10:53 -0600, Shawn Thompson wrote: How hard would it be to make Nouveau work under OI? Can't say but given how far nouveau lags behind full support for nVidia cards that have been around for years, I should think it would be fairly monumental, fall more under xorg's scope, and OI dev effort much better spent elsewhere and just including latest drivers from nVidia. -- Ken Gunderson kgund...@teamcool.net ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] 148b Audio Issues
On Sun, May 22, 2011 at 1:18 PM, Ken Gunderson kgund...@teamcool.net wrote: Howdy: No audio here on 148b. I note a couple bugs filed in Redmine, but not listed as show stoppers for 151. Shouldn't this be on the radar for 151 based release or am I missing something? Sporting two different audio devices on this Tyan K8E based test rig: 1) AC97 nVidia onboard a) previously worked w/o problem on Open/Solaris. b) wants to use audio810 driver c) plays test sound via Multimedia Systems Selector d) played a cd via Sound Juicer once, but otherwise have been unable to repeat. e) scanpci output: pci bus 0x cardnum 0x04 function 0x00: vendor 0x10de device 0x0059 nVidia Corporation CK804 AC'97 Audio Controller CardVendor 0x10f1 card 0x2865 (Tyan Computer, Tomcat K8E (S2865)) STATUS 0x00b0 COMMAND 0x0007 CLASS 0x04 0x01 0x00 REVISION 0xa2 BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x00 BASE0 0xf000 SIZE 256 I/O BASE1 0xec00 SIZE 256 I/O BASE2 0xfebfd000 SIZE 4096 MEM BASEROM 0x addr 0x MAX_LAT 0x05 MIN_GNT 0x02 INT_PIN 0x01 INT_LINE 0x0b 2) Audiotrak Prodigy HD. Envy24 based PCI add in card. a) Never worked on any previous Open/Solaris b) wants to use audiohd driver c) does not play test sound via Multimedia Systems Selector d) but apparently might should work per hcl wiki note pertaining to generic Envy24. e) scanpci output: pci bus 0x0001 cardnum 0x09 function 0x00: vendor 0x1412 device 0x1724 VIA Technologies Inc. VT1720/24 [Envy24PT/HT] PCI Multi-Channel Audio Controller CardVendor 0x3137 card 0x4154 (Card unknown) STATUS 0x0210 COMMAND 0x0005 CLASS 0x04 0x01 0x00 REVISION 0x01 BIST 0x00 HEADER 0x00 LATENCY 0x20 CACHE 0x00 BASE0 0xa400 SIZE 32 I/O BASE1 0xa000 SIZE 128 I/O BASEROM 0x addr 0x MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x07 That the onboard succeeds in playing test sound but I cannot get audio playback from neither Rhythmbox, Totem, or Juicer seems odd. The Audiotrak is a relatively high grade two channel card targeting more audiophile rather than gamer type end user. I'd be willing put on loan to US based driver developer if it would help polish up support for Envy24 based cards. I also have another Envy24 based card (Chaintech). -- Ken Gunderson kgund...@teamcool.net Driver issues should be filed against illumos-gate (not OpenIndiana) here: http://www.illumos.org/projects/illumos-gate/issues Use cat /dev/sndstat and audiotest for diagnostics. There was an incomplete port of OSS4's Envy24 driver ( http://opensolaris.org/jive/thread.jspa?threadID=125584 ) which would need additional work. -Albert ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] nVidia GPU Driver Update for Upcoming Release??
* Shawn Thompson superfox...@gmail.com [2011-05-22 18:53]: How hard would it be to make Nouveau work under OI? In order to even be able to port Nouveau Illumos would need KMS and GEM support first. In fact the lack thereof also prevents updating the Intel driver or porting modern ATI drivers. -- Guido Berhoerster ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] 148b Audio Issues
On Sun, 2011-05-22 at 15:18 -0400, Albert Lee wrote: On Sun, May 22, 2011 at 1:18 PM, Ken Gunderson kgund...@teamcool.net wrote: Howdy: No audio here on 148b. I note a couple bugs filed in Redmine, but not listed as show stoppers for 151. Shouldn't this be on the radar for 151 based release or am I missing something? Sporting two different audio devices on this Tyan K8E based test rig: 1) AC97 nVidia onboard a) previously worked w/o problem on Open/Solaris. b) wants to use audio810 driver c) plays test sound via Multimedia Systems Selector d) played a cd via Sound Juicer once, but otherwise have been unable to repeat. e) scanpci output: pci bus 0x cardnum 0x04 function 0x00: vendor 0x10de device 0x0059 nVidia Corporation CK804 AC'97 Audio Controller CardVendor 0x10f1 card 0x2865 (Tyan Computer, Tomcat K8E (S2865)) STATUS0x00b0 COMMAND 0x0007 CLASS 0x04 0x01 0x00 REVISION 0xa2 BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x00 BASE0 0xf000 SIZE 256 I/O BASE1 0xec00 SIZE 256 I/O BASE2 0xfebfd000 SIZE 4096 MEM BASEROM 0x addr 0x MAX_LAT 0x05 MIN_GNT 0x02 INT_PIN 0x01 INT_LINE 0x0b 2) Audiotrak Prodigy HD. Envy24 based PCI add in card. a) Never worked on any previous Open/Solaris b) wants to use audiohd driver c) does not play test sound via Multimedia Systems Selector d) but apparently might should work per hcl wiki note pertaining to generic Envy24. e) scanpci output: pci bus 0x0001 cardnum 0x09 function 0x00: vendor 0x1412 device 0x1724 VIA Technologies Inc. VT1720/24 [Envy24PT/HT] PCI Multi-Channel Audio Controller CardVendor 0x3137 card 0x4154 (Card unknown) STATUS0x0210 COMMAND 0x0005 CLASS 0x04 0x01 0x00 REVISION 0x01 BIST 0x00 HEADER 0x00 LATENCY 0x20 CACHE 0x00 BASE0 0xa400 SIZE 32 I/O BASE1 0xa000 SIZE 128 I/O BASEROM 0x addr 0x MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x07 That the onboard succeeds in playing test sound but I cannot get audio playback from neither Rhythmbox, Totem, or Juicer seems odd. The Audiotrak is a relatively high grade two channel card targeting more audiophile rather than gamer type end user. I'd be willing put on loan to US based driver developer if it would help polish up support for Envy24 based cards. I also have another Envy24 based card (Chaintech). -- Ken Gunderson kgund...@teamcool.net Driver issues should be filed against illumos-gate (not OpenIndiana) here: http://www.illumos.org/projects/illumos-gate/issues Use cat /dev/sndstat and audiotest for diagnostics. Thanks, Albert. I guess I assumed Gnome's Multimedia Systems Selector test was just front end to make these calls. Definitely better to use lower level tests though: kvg@allakaket:~$ ls -l /dev|grep audio lrwxrwxrwx 1 root root7 2011-05-20 18:45 audio - sound/0 lrwxrwxrwx 1 root root 10 2011-05-20 18:45 audioctl - sound/0ctl lrwxrwxrwx 1 root root 18 2011-05-20 18:45 dsp0 - sound/audiohd:0dsp lrwxrwxrwx 1 root root 19 2011-05-20 18:45 dsp1 - sound/audio810:0dsp lrwxrwxrwx 1 root root 20 2011-05-20 18:45 mixer0 - sound/audiohd:0mixer lrwxrwxrwx 1 root root 21 2011-05-20 18:45 mixer1 - sound/audio810:0mixer lrwxrwxrwx 1 root root 40 2011-05-20 18:45 sndstat - ../devices/pseudo/audio@0:sound,sndstat0 kvg@allakaket:~$ audiotest /dev/dsp0 Sound subsystem and version: SunOS Audio 4.0 (0x00040003) Platform: SunOS 5.11 oi_148b i86pc *** Scanning sound adapter #1 *** /dev/sound/audiohd:0dsp (audio engine 0): audiohd#0 - Performing audio playback test... left OK right ...OK stereo ..OK measured sample rate 47911.00 Hz (-0.19%) *** All tests completed OK *** kvg@allakaket:~$ audiotest /dev/dsp1 Sound subsystem and version: SunOS Audio 4.0 (0x00040003) Platform: SunOS 5.11 oi_148b i86pc *** Scanning sound adapter #2 *** /dev/sound/audio810:0dsp (audio engine 1): audio810#0 - Performing audio playback test... left OK right ...OK stereo ..OK measured sample rate 47697.00 Hz (-0.63%) dsp0 reports all is fine and dandy but the test doesn't actually produce any sound. dsp1 produces sound but none of the Gnome apps, e.g. Juicer, Rhythmbox, or Totem result in any actual playback. Hence, methinks this is more OI Gnome DE related. There was an incomplete port of OSS4's Envy24 driver ( http://opensolaris.org/jive/thread.jspa?threadID=125584 ) which would need additional work. Open source drivers for Envy24 based cards have been reverse engineered and been in Linux and FreeBSD repositories for years. I don't know how closely/distantly related they may be but perhaps might at least be worth a gander. Also, although clearly communicated in my previous
[oi-dev] Change Request: Lowering dump and swap defaults AKA My dump is too big!
Hello, Currently we have bug 1024 which relates to an install blocker due to the way the installer defaults swap and dump sizes. The relevant parts are in slim_source/usr/src/lib/install_target/controller.py Line 626 in the function calc_swap_dump_size The table explains that above 1GB swap defaults to half memory size, maxed to 32GB and dump above 0.5GB is half memory size, maxed to 16GB So a machine with 32GB or more will have 16GB dump space and 16GB-32GB swap space, which is quite nasty when many of us are now using SSD as boot drives. First question, why huge space for dump files anyway? How many people use that facility? Second do we really use half memory for swap with large memory configs? I suggest that we limit dump space to a small fraction, say 256MB (its minimum according to that function) and cap swap space by default to say 4 or 8 GB. This would seem to be more reasonable defaults to me, and both can be increased if required by a particular user. With a swap default maximum of 8GB, this would reduce our minimal install size from roughly 4GB + 0.8 * RAM to roughly a max of 13 GB. In real figures, a server with 48GB RAM would require 13 GB of boot drive space versus the current 44 GB Thoughts? Deano ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Change Request: Lowering dump and swap defaults AKA My dump is too big!
Hi Deano, On 22 May 2011, at 23:02, Deano wrote: Hello, Currently we have bug 1024 which relates to an install blocker due to the way the installer defaults swap and dump sizes. The relevant parts are in slim_source/usr/src/lib/install_target/controller.py Line 626 in the function calc_swap_dump_size The table explains that above 1GB swap defaults to half memory size, maxed to 32GB and dump above 0.5GB is half memory size, maxed to 16GB So a machine with 32GB or more will have 16GB dump space and 16GB-32GB swap space, which is quite nasty when many of us are now using SSD as boot drives. Yes, I've encountered this one myself, although it was in the text installer, which uses a slightly different algorithm IIRC. First question, why huge space for dump files anyway? How many people use that facility? There was a discussion on #oi-dev recently - I personally felt that the dump device is unnecessary in most circumstances, as few people have time to send in crash dumps. If a crash is persistent, a dump device can be added. However others on the project felt the dump device is useful, as it means after a crash there is data there to work out what happened. But I think we all agreed the dump sizes can be unnecessarily large. Second do we really use half memory for swap with large memory configs? I'm no expert on the vm subsystem, but I believe Solaris doesn't allow overcommitting on virtual memory. So on Solaris you need swap to allow large mallocs even if the memory will never get used? I think that's how it works. So on large memory configs, you probably do need a lot of swap, otherwise you'll struggle to use all your RAM, as lots will be allocated but not used. I'd love someone to clear this up if thats not the case and my understanding is wrong. I suggest that we limit dump space to a small fraction, say 256MB (its minimum according to that function) and cap swap space by default to say 4 or 8 GB. This would seem to be more reasonable defaults to me, and both can be increased if required by a particular user. With a swap default maximum of 8GB, this would reduce our minimal install size from roughly 4GB + 0.8 * RAM to roughly a max of 13 GB. In real figures, a server with 48GB RAM would require 13 GB of boot drive space versus the current 44 GB I am absolutely for changing the algorithm/defaults for swap+dump to something far saner. I think a bigger dump and more swap is called for in higher memory situations, but getting the algorithm right is tricky. Do you know if the installer knows how large the zpool is at the point it calculates how large the swap should be? We could for example size swap+dump based on how much RAM there is and how large the rpool is. You could have a space-constrained swap+dump for small drives, and another for larger drives. For example if swap+dump is going to be bigger than 25% of the rpool, change to allocating a minimal dump and capping swap+dump at 25%. So on a machine with 64GB of RAM but a 50GB rpool, you'd get 12.25GB swap and 256MB dump. If the machine had 16GB RAM you'd get an 8GB swap and 4.5GB dump. Maybe we should cap the dump size at 2GB and simply recommend systems with larger kernel sizes (eg fileservers with lots of zfs filesystems) increase their dump size. I'm also wondering if we could use a sparse zvol for the dump area with no refreservation. Yes, the dump will fail if theres not enough free space, but it would allow a bigger dump to be specified and the dump would succeed if there is free space for it to do so. Lots to think about. We should definitely come to a conclusion on this before shipping 151 stable. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Change Request: Lowering dump and swap defaults AKA My dump is too big!
On Sun, May 22, 2011 at 18:02, Deano de...@rattie.demon.co.uk wrote: First question, why huge space for dump files anyway? How many people use that facility? Anyone who wants any bugs they encounter fixed. Second do we really use half memory for swap with large memory configs? It's a rough guess based on the likely compressability of the crash dump, and the likely size of the kernel image. dumpadm(1) has its own logic as to the minimum size of dump device it will even attempt to configure. I don't know how or if it and install agree. It would perhaps be reasonable to have install configure the minimum size acceptable to dumpadm. -- Rich ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Change Request: Lowering dump and swap defaults AKA My dump is too big!
On 22 May 2011, at 23:46, Richard Lowe wrote: Anyone who wants any bugs they encounter fixed. There is that - if theres disk space available for a dump device, its sensible to configure one. I do despise that its almost impossible to remove the dump device without hackery, since dumpadm won't let you have no dump device configured. Some people don't want a dump device, and we should respect that. Second do we really use half memory for swap with large memory configs? It's a rough guess based on the likely compressability of the crash dump, and the likely size of the kernel image. dumpadm(1) has its own logic as to the minimum size of dump device it will even attempt to configure. I don't know how or if it and install agree. It would perhaps be reasonable to have install configure the minimum size acceptable to dumpadm. Very interesting, definitely worth us looking into the values dumpadm uses. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Change Request: Lowering dump and swap defaults AKA My dump is too big!
On Sun, May 22, 2011 at 18:50, Alasdair Lumsden alasdai...@gmail.com wrote: On 22 May 2011, at 23:46, Richard Lowe wrote: Anyone who wants any bugs they encounter fixed. There is that - if theres disk space available for a dump device, its sensible to configure one. On UFS root filesystems we used to configure the dump device to be the swap device, we only switched because ZFS let you sensibly separate this (this is also why we're able to not run savecore by default. There's nothing that will overwrite the dump on the actual device). You should be able to: 1) Configure the system to dump to the swap device, as it used to 2) Configure savecore to run by default again (so that dumps don't get swapped over). And save the space of the extra dump device. Someone should have to investigate whether there are problems with swapping and dumping to the same zvol, as opposed to physical device. -- Rich ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] libstdc++ locale support on Solaris/OI
Hi All, When discussing the option of using gcc as the default compiler for software on OI, the lack of IEEE 1003.1-2001 support in libstdc++ was cited as a reason for sticking with Sun Studio. There's a bug open on the GCC bug tracker for it here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41495 As you can see someone has got a mostly working patch available, which potentially could be finished to address this. I posted a comment on the bug tracker, and someone responded they could be interested in working on it. I'd appreciate it if others also interested in this could provide feedback on the bug, especially Jonathan Wakely's question to which I don't know the answer: Does OpenIndiana support the new POSIX.1-2008 APIs, e.g. wctype_l and towupper_l? I also had a look at the --enable-clocale option: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/~checkout~/gcc/libstdc++-v3/docs/html/configopts.html?rev=1.21.2.10.4.3.2.2content-type=text/html --enable-clocale=OPTION Select a target-specific underlying locale package. The choices are 'ieee_1003.1-2001' to specify an X/Open, Standard Unix (IEEE Std. 1003.1-2001) model based on langinfo/iconv/catgets, 'gnu' to specify a model based on functionality from the GNU C library (langinfo/iconv/gettext) (from glibc, the GNU C library), or 'generic' to use a generic C abstraction which consists of C locale info. As part of the configuration process, the C library is probed both for sufficient vintage, and installed locale data. If either of these elements are not present, the C++ locale model default to 'generic.' On glibc-based systems of version 2.2.5 and above with installed locale files, 'gnu' is automatically selected. Does anyone know if the GNU option is viable? It specifies it takes functionality from glibc, which obviously we don't have, but then cites langinfo/iconv/gettext, the latter 2 of which we do have. And lastly, could someone confirm whether the Apache stdcxx C++ library is a viable full alternative to libstdc++ that we could use to avoid the locale issue? If so, does anyone foresee any issues of pairing gcc with libstdc++ to take over from Sun Studio as our compiler of choice for OI (I'm talking theoretically, ignoring the work involved of making everything actually compile with it). Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] libstdc++ locale support on Solaris/OI
Correction: On 23 May 2011, at 00:15, Alasdair Lumsden wrote: And lastly, could someone confirm whether the Apache stdcxx C++ library is a viable full alternative to libstdc++ that we could use to avoid the locale issue? If so, does anyone foresee any issues of pairing gcc with libstdc++ to take over from Sun Studio as our compiler of choice for OI (I'm talking theoretically, ignoring the work involved of making everything actually compile with it). Obviously that should read pairing gcc with stdcxx, rather than pairing gcc with libstdc++ which is already the default. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] 148b Audio Issues
I have an envy24 driver nearly ready to integrate, but I have held off as I don't have the hardware. If you want to send me the hardware, I can look at it. That said, the problem with the audio810 driver is not with the driver, but the Gnome configuration. You need to tell Gnome you want to use this device. The best way to do that is with the gstreamer-properties application.Using that you can select OSS audio output and the specific device to use. That should solve the problem for you. -- Garrett D'Amore On May 23, 2011, at 12:21 AM, Ken Gunderson kgund...@teamcool.net wrote: On Sun, 2011-05-22 at 15:18 -0400, Albert Lee wrote: On Sun, May 22, 2011 at 1:18 PM, Ken Gunderson kgund...@teamcool.net wrote: Howdy: No audio here on 148b. I note a couple bugs filed in Redmine, but not listed as show stoppers for 151. Shouldn't this be on the radar for 151 based release or am I missing something? Sporting two different audio devices on this Tyan K8E based test rig: 1) AC97 nVidia onboard a) previously worked w/o problem on Open/Solaris. b) wants to use audio810 driver c) plays test sound via Multimedia Systems Selector d) played a cd via Sound Juicer once, but otherwise have been unable to repeat. e) scanpci output: pci bus 0x cardnum 0x04 function 0x00: vendor 0x10de device 0x0059 nVidia Corporation CK804 AC'97 Audio Controller CardVendor 0x10f1 card 0x2865 (Tyan Computer, Tomcat K8E (S2865)) STATUS0x00b0 COMMAND 0x0007 CLASS 0x04 0x01 0x00 REVISION 0xa2 BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x00 BASE0 0xf000 SIZE 256 I/O BASE1 0xec00 SIZE 256 I/O BASE2 0xfebfd000 SIZE 4096 MEM BASEROM 0x addr 0x MAX_LAT 0x05 MIN_GNT 0x02 INT_PIN 0x01 INT_LINE 0x0b 2) Audiotrak Prodigy HD. Envy24 based PCI add in card. a) Never worked on any previous Open/Solaris b) wants to use audiohd driver c) does not play test sound via Multimedia Systems Selector d) but apparently might should work per hcl wiki note pertaining to generic Envy24. e) scanpci output: pci bus 0x0001 cardnum 0x09 function 0x00: vendor 0x1412 device 0x1724 VIA Technologies Inc. VT1720/24 [Envy24PT/HT] PCI Multi-Channel Audio Controller CardVendor 0x3137 card 0x4154 (Card unknown) STATUS0x0210 COMMAND 0x0005 CLASS 0x04 0x01 0x00 REVISION 0x01 BIST 0x00 HEADER 0x00 LATENCY 0x20 CACHE 0x00 BASE0 0xa400 SIZE 32 I/O BASE1 0xa000 SIZE 128 I/O BASEROM 0x addr 0x MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x07 That the onboard succeeds in playing test sound but I cannot get audio playback from neither Rhythmbox, Totem, or Juicer seems odd. The Audiotrak is a relatively high grade two channel card targeting more audiophile rather than gamer type end user. I'd be willing put on loan to US based driver developer if it would help polish up support for Envy24 based cards. I also have another Envy24 based card (Chaintech). -- Ken Gunderson kgund...@teamcool.net Driver issues should be filed against illumos-gate (not OpenIndiana) here: http://www.illumos.org/projects/illumos-gate/issues Use cat /dev/sndstat and audiotest for diagnostics. Thanks, Albert. I guess I assumed Gnome's Multimedia Systems Selector test was just front end to make these calls. Definitely better to use lower level tests though: kvg@allakaket:~$ ls -l /dev|grep audio lrwxrwxrwx 1 root root7 2011-05-20 18:45 audio - sound/0 lrwxrwxrwx 1 root root 10 2011-05-20 18:45 audioctl - sound/0ctl lrwxrwxrwx 1 root root 18 2011-05-20 18:45 dsp0 - sound/audiohd:0dsp lrwxrwxrwx 1 root root 19 2011-05-20 18:45 dsp1 - sound/audio810:0dsp lrwxrwxrwx 1 root root 20 2011-05-20 18:45 mixer0 - sound/audiohd:0mixer lrwxrwxrwx 1 root root 21 2011-05-20 18:45 mixer1 - sound/audio810:0mixer lrwxrwxrwx 1 root root 40 2011-05-20 18:45 sndstat - ../devices/pseudo/audio@0:sound,sndstat0 kvg@allakaket:~$ audiotest /dev/dsp0 Sound subsystem and version: SunOS Audio 4.0 (0x00040003) Platform: SunOS 5.11 oi_148b i86pc *** Scanning sound adapter #1 *** /dev/sound/audiohd:0dsp (audio engine 0): audiohd#0 - Performing audio playback test... left OK right ...OK stereo ..OK measured sample rate 47911.00 Hz (-0.19%) *** All tests completed OK *** kvg@allakaket:~$ audiotest /dev/dsp1 Sound subsystem and version: SunOS Audio 4.0 (0x00040003) Platform: SunOS 5.11 oi_148b i86pc *** Scanning sound adapter #2 *** /dev/sound/audio810:0dsp (audio engine 1): audio810#0 - Performing audio playback test... left OK right ...OK stereo ..OK measured sample rate 47697.00 Hz (-0.63%) dsp0 reports all is fine and dandy but the test doesn't actually produce any sound. dsp1 produces sound but none of the Gnome apps, e.g.
Re: [oi-dev] libstdc++ locale support on Solaris/OI
illumos doesn't have the POSIX 2008 locale APIs. I've considered adding them... it would not be too difficult, although we would need to eliminate some process global state ... are there applications that consume these? If there are, then its worth the time and effort. -- Garrett D'Amore On May 23, 2011, at 3:15 AM, Alasdair Lumsden alasdai...@gmail.com wrote: Hi All, When discussing the option of using gcc as the default compiler for software on OI, the lack of IEEE 1003.1-2001 support in libstdc++ was cited as a reason for sticking with Sun Studio. There's a bug open on the GCC bug tracker for it here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41495 As you can see someone has got a mostly working patch available, which potentially could be finished to address this. I posted a comment on the bug tracker, and someone responded they could be interested in working on it. I'd appreciate it if others also interested in this could provide feedback on the bug, especially Jonathan Wakely's question to which I don't know the answer: Does OpenIndiana support the new POSIX.1-2008 APIs, e.g. wctype_l and towupper_l? I also had a look at the --enable-clocale option: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/~checkout~/gcc/libstdc++-v3/docs/html/configopts.html?rev=1.21.2.10.4.3.2.2content-type=text/html --enable-clocale=OPTION Select a target-specific underlying locale package. The choices are 'ieee_1003.1-2001' to specify an X/Open, Standard Unix (IEEE Std. 1003.1-2001) model based on langinfo/iconv/catgets, 'gnu' to specify a model based on functionality from the GNU C library (langinfo/iconv/gettext) (from glibc, the GNU C library), or 'generic' to use a generic C abstraction which consists of C locale info. As part of the configuration process, the C library is probed both for sufficient vintage, and installed locale data. If either of these elements are not present, the C++ locale model default to 'generic.' On glibc-based systems of version 2.2.5 and above with installed locale files, 'gnu' is automatically selected. Does anyone know if the GNU option is viable? It specifies it takes functionality from glibc, which obviously we don't have, but then cites langinfo/iconv/gettext, the latter 2 of which we do have. And lastly, could someone confirm whether the Apache stdcxx C++ library is a viable full alternative to libstdc++ that we could use to avoid the locale issue? If so, does anyone foresee any issues of pairing gcc with libstdc++ to take over from Sun Studio as our compiler of choice for OI (I'm talking theoretically, ignoring the work involved of making everything actually compile with it). Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] 148b Audio Issues
On Mon, 2011-05-23 at 06:16 +0400, Garrett D'Amore wrote: I have an envy24 driver nearly ready to integrate, but I have held off as I don't have the hardware. If you want to send me the hardware, I can look at it. Shoot me a physical address offlist and I'll UPS the cards your way. That said, the problem with the audio810 driver is not with the driver, but the Gnome configuration. You need to tell Gnome you want to use this device. The best way to do that is with the gstreamer-properties application. Using that you can select OSS audio output and the specific device to use. That should solve the problem for you. Ah, but therein lies the rub - it does not I've previously specified audio810#0 and OSSv4 via Gnome's Multimedia System Selector, wh/is apparently front end launcher for gstreamer-properties, as gstreamer-properties from command line launches same UI with same selections I've previously set. The Test button on this tool produces sound via the onboard card. However, Gnome multimedia apps such as Totem Rhythmbox produce no audio playback. -- Ken Gunderson kgund...@teamcool.net ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
