Re: new jail(8) ignoring devfs_ruleset?
schrieb Jamie Gritton am 16.02.2013 00:40 (localtime): > On 02/15/13 09:27, Harald Schmalzbauer wrote: >> Hello, >> >> like already posted, on 9.1-R, I highly appreciate the new jail(8) and >> jail.conf capabilities. Thanks for that extension! >> >> Accidentally I saw that "devfs_ruleset" seems to be ignored. >> If I list /dev/ I see all the hosts disk devices etc. >> I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf. >>Inside the jail, >> sysctl security.jail.devfs_ruleset returnes "1". >> But like mentioned, I can access all devices... >> >> Thanks for any help, >> >> -Harry > > devfs_ruleset is only used along with mount.devfs - do you also have > that set in jail.conf? Thanks for your response. Yes, I have mount.devfs; set. Otherwise I wouldn't have any device inside my jail. Verified - and like intended, right? Another notable discrepancy: The man page tells that devfs_rulset is "4" by default. But when I don't set devfs_rulset in jail.conf at all, inside the jail, 'sysctl security.jail.devfs_ruleset': 0 When set, like mentioned above, it returns the corresponding value, but it doesn't have any effect. How gets devfs_rulset handled? Does jail(8) do the whole job? I'd like to help finding the source, but have missed the whole new jail evolution... Inside my jails, I don't have a fstab, outside I have them defined and enabled with "mount" - and noticed the non-reverted umounting. Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: And for our next trick (Audio problems, Envy24HT driver)
On Fri, 15 Feb 2013 15:58:37 -0600 Karl Denninger wrote: > FreeBSD 9.1-STABLE #2 r244942M: Tue Feb 5 21:54:29 CST 2013 > k...@dbms.denninger.net:/usr/obj/usr/src/sys/KSD-SMP > > (custom kernel is there to support PPS for my GPS clock) > > Attempting to add a generic card that claims to have a Envy24DT chipset > in it; it identifies and loads under the snd_envy24ht driver as: > > pci6: at device 0.0 (no driver attached) > pcm0: port 0xcc00-0xcc1f,0xc880-0xc8ff irq 16 > at device 0.0 on pci6 > pcm0: [GIANT-LOCKED] > pcm0: system configuration > SubVendorID: 0x1412, SubDeviceID: 0x2403 > XIN2 Clock Source: 24.576MHz(96kHz*256) > MPU-401 UART(s) #: not implemented > ADC #: 1 and SPDIF receiver connected > DAC #: 4 > Multi-track converter type: AC'97(SDATA_OUT:packed) > S/PDIF(IN/OUT): 1/1 ID# 0x00 > GPIO(mask/dir/state): 0xff/0xff/0xff > > cat /dev/sndstat returns: > > [root@NewFS /boot/kernel]# cat /dev/sndstat > FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64) > Installed devices: > pcm0: at io 0xcc00:32,0xc880:128 irq 16 > (1p:1v/5r:1v) default > > So it appears it did attach properly. No it did not. :) It's a longer story. While the Envy family had of course a generic chip design, there wasn't a generic card design. So every Envy card is different and needs a different driver. The snd_envy24ht driver solves this problem with distinct device sections for each supported devices. See envy24ht.c line 279. If no device section could be found the card is detected as "generic" and a default device section is used. That may or may not work... So the solution would be to add a device section for your card but that's everything but easy. In an ideal world there would be a datasheet for that card, in reality it may be necessary to reverse engineer it. And there are other problems with the driver: - It's not MPSAFE (at least it's not marked MPSAFE) - Recording doesn't work - The debug mode is prone to panics - All channels supported by the Envy chip are exposed to the mixer regardless if they're connect in hardware or not. This leads to invalid channels. I've once had the idea to clean it up but never found the time. Nevertheless it still would be really nice if someone could give this driver some love. :) Ciao, Yamagi -- Homepage: www.yamagi.org XMPP: yam...@yamagi.org GnuPG/GPG: 0xEFBCCBCB ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9-STABLE -> NFS -> NetAPP:
2days, 6hrs since reboot with new kernel, server shows unreachable: # ssh mercury ssh_exchange_identification: Connection closed by remote host although runtime shows it is up: mercuryup 2+06:17, 0 users, load 0.63, 0.69, 0.70 Remote console shows: I could press return, so keyboard was still responsive, and got a new login prompt, but after typing login id, it appears to just hang … Remotely power cycled server. This is new behaviour for that server since applying patch … will see if it happens again ... On 2013-02-17, at 7:07 AM, Rick Macklem wrote: > Marc Fournier wrote: >> On 2013-02-15, at 7:21 AM, Rick Macklem wrote: >> >>> Righto. Thanks jhb and kib for looking at this. >>> >>> Btw John, PBDRY still gets set for sleeps in the sys/rpc code. >>> However, >>> as far as I can tell, it just sets TDF_SBDRY when it is already set >>> and seems harmless. (Since this code is supposed to be generic and >>> not >>> specific to NFS, maybe it should stay that way?) >>> >>> Also, since PBDRY on the sleeps sets TDF_SBDRY, I think the above >>> patch >>> is ok for stable/9 without your recent head patch. >>> >>> Maybe Marc can test the above patch? >> >> 'k, not sure what you want me to 'test', but so far, patch has been >> applied / live for ~21hrs, and no processes in state T … >> > Yes, I meant run it like you normally do and see if the hang occurs > with the patch (or other problems crop up). I suspect you have some > idea of how long it needs to run without a hang before you are convinced > the problem is fixed. > > I can't do commits until April, so there is no rush from my point of > view. (I suspect jhb@ will commit it at some point, if/when it appears > to fix the problem and seems correct.) > > Thanks for testing it, rick > >> >> >> ___ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to >> "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9-STABLE -> NFS -> NetAPP:
According to /var/log/messages, everything seems to have been running (at least against the local file system) up until the reboot: === Feb 18 12:00:00 mercury kernel: bce1: promiscuous mode disabled Feb 18 12:00:00 mercury kernel: bce1: promiscuous mode enabled Feb 18 12:13:55 mercury syslogd: kernel boot file is /boot/kernel/kernel Feb 18 12:13:55 mercury kernel: Copyright (c) 1992-2013 The FreeBSD Project. === On 2013-02-18, at 4:12 AM, Marc Fournier wrote: > > 2days, 6hrs since reboot with new kernel, server shows unreachable: > > # ssh mercury > ssh_exchange_identification: Connection closed by remote host > > although runtime shows it is up: > > mercuryup 2+06:17, 0 users, load 0.63, 0.69, 0.70 > > Remote console shows: > > > > I could press return, so keyboard was still responsive, and got a new login > prompt, but after typing login id, it appears to just hang … > > Remotely power cycled server. > > This is new behaviour for that server since applying patch … will see if it > happens again ... > > > On 2013-02-17, at 7:07 AM, Rick Macklem wrote: > >> Marc Fournier wrote: >>> On 2013-02-15, at 7:21 AM, Rick Macklem wrote: >>> > Righto. Thanks jhb and kib for looking at this. Btw John, PBDRY still gets set for sleeps in the sys/rpc code. However, as far as I can tell, it just sets TDF_SBDRY when it is already set and seems harmless. (Since this code is supposed to be generic and not specific to NFS, maybe it should stay that way?) Also, since PBDRY on the sleeps sets TDF_SBDRY, I think the above patch is ok for stable/9 without your recent head patch. Maybe Marc can test the above patch? >>> >>> 'k, not sure what you want me to 'test', but so far, patch has been >>> applied / live for ~21hrs, and no processes in state T … >>> >> Yes, I meant run it like you normally do and see if the hang occurs >> with the patch (or other problems crop up). I suspect you have some >> idea of how long it needs to run without a hang before you are convinced >> the problem is fixed. >> >> I can't do commits until April, so there is no rush from my point of >> view. (I suspect jhb@ will commit it at some point, if/when it appears >> to fix the problem and seems correct.) >> >> Thanks for testing it, rick >> >>> >>> >>> ___ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to >>> "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
intel kms, xorg and triple head?
Hello, I wasn't able to find infos about multi-head support for the new intel kms with FreeBSD 9.1 Is it possible to have xorg driving 3 displays? I know of the two-PLL-pipe limitation with intel's IvyBrindge-CPU/GPUs. But I don't know if the new driver supports possible configurations? (e.G. 2x1600x1200 + 1x1920x1200). Has anybody running xorg and 3 displays with i915kms? Or is it at least said to be supported? Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: intel kms, xorg and triple head?
On Mon, 18 Feb 2013, Harald Schmalzbauer wrote: Hello, I wasn't able to find infos about multi-head support for the new intel kms with FreeBSD 9.1 Is it possible to have xorg driving 3 displays? I know of the two-PLL-pipe limitation with intel's IvyBrindge-CPU/GPUs. But I don't know if the new driver supports possible configurations? (e.G. 2x1600x1200 + 1x1920x1200). Has anybody running xorg and 3 displays with i915kms? Or is it at least said to be supported? I barely have one display (laptop) working with KMS. Once X is up, trying to switch to a virtual console leaves you with a blank screen until you reboot. I have 2 graphics controllers in this laptop and have to cut one of them out of my xorg.conf in order for it to work. This laptop isn't meant to use both graphics controllers at the same time, so perhaps your configuration will work much better - I'd be curious to know. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: new jail(8) ignoring devfs_ruleset?
On 02/18/13 01:54, Harald Schmalzbauer wrote: schrieb Jamie Gritton am 16.02.2013 00:40 (localtime): On 02/15/13 09:27, Harald Schmalzbauer wrote: Hello, like already posted, on 9.1-R, I highly appreciate the new jail(8) and jail.conf capabilities. Thanks for that extension! Accidentally I saw that "devfs_ruleset" seems to be ignored. If I list /dev/ I see all the hosts disk devices etc. I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf. Inside the jail, sysctl security.jail.devfs_ruleset returnes "1". But like mentioned, I can access all devices... Thanks for any help, -Harry devfs_ruleset is only used along with mount.devfs - do you also have that set in jail.conf? Thanks for your response. Yes, I have mount.devfs; set. Otherwise I wouldn't have any device inside my jail. Verified - and like intended, right? Another notable discrepancy: The man page tells that devfs_rulset is "4" by default. But when I don't set devfs_rulset in jail.conf at all, inside the jail, 'sysctl security.jail.devfs_ruleset': 0 When set, like mentioned above, it returns the corresponding value, but it doesn't have any effect. How gets devfs_rulset handled? Does jail(8) do the whole job? I'd like to help finding the source, but have missed the whole new jail evolution... Inside my jails, I don't have a fstab, outside I have them defined and enabled with "mount" - and noticed the non-reverted umounting. I found the problem - I noticed you mentioned 9.1-R, and took a look at devfs(5). On CURRENT, there's a mount option "ruleset", that isn't there on 9. So I'll have to get around it by running devfs(8) after the mount. I'll work on a patch for that. - Jamie ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: new jail(8) ignoring devfs_ruleset?
On Mon, Feb 18, 2013 at 09:26:42AM -0700, Jamie Gritton wrote: > On 02/18/13 01:54, Harald Schmalzbauer wrote: > > schrieb Jamie Gritton am 16.02.2013 00:40 (localtime): > >>On 02/15/13 09:27, Harald Schmalzbauer wrote: > >>> Hello, > >>> > >>>like already posted, on 9.1-R, I highly appreciate the new jail(8) and > >>>jail.conf capabilities. Thanks for that extension! > >>> > >>>Accidentally I saw that "devfs_ruleset" seems to be ignored. > >>>If I list /dev/ I see all the hosts disk devices etc. > >>>I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf. > >>>Inside the jail, > >>>sysctl security.jail.devfs_ruleset returnes "1". > >>>But like mentioned, I can access all devices... > >>> > >>>Thanks for any help, > >>> > >>>-Harry > >> > >>devfs_ruleset is only used along with mount.devfs - do you also have > >>that set in jail.conf? > > > >Thanks for your response. > > > >Yes, I have mount.devfs; set. > >Otherwise I wouldn't have any device inside my jail. Verified - and like > >intended, right? > >Another notable discrepancy: The man page tells that devfs_rulset is "4" > >by default. > >But when I don't set devfs_rulset in jail.conf at all, inside the jail, > >'sysctl security.jail.devfs_ruleset': 0 > >When set, like mentioned above, it returns the corresponding value, but > >it doesn't have any effect. > >How gets devfs_rulset handled? Does jail(8) do the whole job? I'd like > >to help finding the source, but have missed the whole new jail evolution... > >Inside my jails, I don't have a fstab, outside I have them defined and > >enabled with "mount" - and noticed the non-reverted umounting. > > I found the problem - I noticed you mentioned 9.1-R, and took a look at > devfs(5). On CURRENT, there's a mount option "ruleset", that isn't there > on 9. > > So I'll have to get around it by running devfs(8) after the mount. I'll > work on a patch for that. > Why not MFC support for that mount option instead? -- Mateusz Guzik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: new jail(8) ignoring devfs_ruleset?
On 02/18/13 09:29, Mateusz Guzik wrote: On Mon, Feb 18, 2013 at 09:26:42AM -0700, Jamie Gritton wrote: On 02/18/13 01:54, Harald Schmalzbauer wrote: schrieb Jamie Gritton am 16.02.2013 00:40 (localtime): On 02/15/13 09:27, Harald Schmalzbauer wrote: Hello, like already posted, on 9.1-R, I highly appreciate the new jail(8) and jail.conf capabilities. Thanks for that extension! Accidentally I saw that "devfs_ruleset" seems to be ignored. If I list /dev/ I see all the hosts disk devices etc. I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf. Inside the jail, sysctl security.jail.devfs_ruleset returnes "1". But like mentioned, I can access all devices... Thanks for any help, -Harry devfs_ruleset is only used along with mount.devfs - do you also have that set in jail.conf? Thanks for your response. Yes, I have mount.devfs; set. Otherwise I wouldn't have any device inside my jail. Verified - and like intended, right? Another notable discrepancy: The man page tells that devfs_rulset is "4" by default. But when I don't set devfs_rulset in jail.conf at all, inside the jail, 'sysctl security.jail.devfs_ruleset': 0 When set, like mentioned above, it returns the corresponding value, but it doesn't have any effect. How gets devfs_rulset handled? Does jail(8) do the whole job? I'd like to help finding the source, but have missed the whole new jail evolution... Inside my jails, I don't have a fstab, outside I have them defined and enabled with "mount" - and noticed the non-reverted umounting. I found the problem - I noticed you mentioned 9.1-R, and took a look at devfs(5). On CURRENT, there's a mount option "ruleset", that isn't there on 9. So I'll have to get around it by running devfs(8) after the mount. I'll work on a patch for that. Why not MFC support for that mount option instead? That may be a better way around it, since either solution will require an MFC. It'd be nice to have a patch to jail(8) anyway, since just dropping in a new jail program is easier than dropping in a new kernel. I'll have to take a look at the devfs code and see if that was a reasonably small change. - Jamie ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Why can't gcc-4.2.1 build usable libreoffice?
On 14 February 2013 13:57, Mikhail T. wrote: > Hello! > > I just finished building editors/libreoffice with gcc-4.2.1 -- had to > edit the port's Makefile to prevent it from picking a different > compiler. Everything built and installed, but libreoffice dies on > start-up (right after flashing the splash-window): > > (gdb) where > #0 0x00080596c1aa in cppu::__getTypeEntries () >from > /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 > #1 0x00080596c333 in cppu::__queryDeepNoXInterface () >from > /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 > #2 0x00080596d4a2 in cppu::WeakImplHelper_query () >from > /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 > #3 0x0008116f2b03 in > > cppu::WeakImplHelper1::queryInterface > () >from /opt/lib/libreoffice/ure/lib/bootstrap.uno.so > #4 0x000805970347 in > cppu::OInterfaceContainerHelper::disposeAndClear () >from > /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 > #5 0x0008059705b2 in > cppu::OMultiTypeInterfaceContainerHelper::disposeAndClear () >from > /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 > #6 0x00080593309f in cppu::OComponentHelper::dispose () >from > /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 > #7 0x000805963d00 in cppu::OFactoryComponentHelper::dispose () >from > /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 > #8 0x0008116ec296 in stoc_smgr::OServiceManager::disposing () > from /opt/lib/libreoffice/ure/lib/bootstrap.uno.so > #9 0x00080596af05 in cppu::WeakComponentImplHelperBase::dispose () >from > /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 > #10 0x0008116e6244 in stoc_smgr::ORegistryServiceManager::dispose () >from /opt/lib/libreoffice/ure/lib/bootstrap.uno.so > #11 0x00080596a573 in cppu::WeakComponentImplHelperBase::release () >from > /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 > #12 0x0008059482f6 in (anonymous namespace)::createTypeRegistry () >from > /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 > #13 0x0008059487bf in > cppu::defaultBootstrap_InitialComponentContext () >from > /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 > #14 0x000805948918 in > cppu::defaultBootstrap_InitialComponentContext () >from > /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 > #15 0x00080212f883 in > desktop::Desktop::InitApplicationServiceManager () >from /opt/lib/libreoffice/program/libmergedlo.so > #16 0x00080211f362 in desktop::Desktop::Init () from > /opt/lib/libreoffice/program/libmergedlo.so > #17 0x000807622113 in InitVCL () from > /opt/lib/libreoffice/program/libvcllo.so > #18 0x000807623151 in ImplSVMain () from > /opt/lib/libreoffice/program/libvcllo.so > #19 0x0008076232d5 in SVMain () from > /opt/lib/libreoffice/program/libvcllo.so > #20 0x00080214942e in soffice_main () from > /opt/lib/libreoffice/program/libmergedlo.so > #21 0x00400773 in main () > > I do not blame the office@ team -- the port did not want to use > gcc-4.2.1, I forced it to. But I'd like to know, what is wrong with the > compiler shipped by FreeBSD-9.1 (and the only one, if WITHOUT_CLANG is > defined), that prevents building a healthy libreoffice? > > Is there a bug fixed in gcc-4.6? Or is it some (incorrect) assumption > made by libreoffice code? Thank you, Hi Mikhail, Libreoffice and openoffice have traditionally recommended that one use binary packages instead of building it from scratch. I'm sure you understand that our compiler in base is rather elderly, and that a project as insanely huge as Libreoffice is going to be highly sensitive to minute changes. As a consequence, some very narrow criteria are chosen to make maintenance of the port possible. You are welcome to try with gcc-4.6, but the last I heard it will only build with clang. Your mileage may vary, please let us know of success stories! Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
poudriere and tinderbox on current failing to build stable/8
Hi, While performing some tests with the programs in the subject I noticed that stable/8 fails. Both programs try to build stable/8 using the system cc compiler (clang on -CURRENT), which fails at building gcc, so the build stops with various errors. To work around this I configured them to build stable 8 defining the following values: CC=gcc CXX=g++ CPP=gcpp Forcing poudriere and tinderbox to use 10-CURRENT gcc binaries to perform the initial toolchain build. Is this workaround acceptable? Does it have some hidden problems which perhaps could show up later? Or does it create a correct stable/8 build without problems? If necessary I have a build log with the errors. Thanks in advance for any clarification. -- Guido Falsi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: NFSv4 + Kerberos permission denied
Janusz Bulik wrote: > Hello, > I've got a little problem with NFSv4 + Kerberos. I can do a mount with > Kerberos with a valid ticket, but read-only. > After the mount -vvv -t nfs -o nfsv4,sec=krb5 nfsserver:/ /mount_test/ > I can see: > > #klist: > Feb 6 07:22:47 Feb 6 17:22:43 nfs/nfsserver@my.domain > > #/var/heimdal/kdc.log: > 2013-02-06T07:28:26 TGS-REQ clientnfs@my.domain from IPv4:192.168.0.23 > for nfs/nfsserver@my.domain > > tcpdump: > 14:59:36.140272 IP nfsclient.61011 > 192.168.0.21.kerberos-sec: > 14:59:36.142301 IP 192.168.0.21.kerberos-sec > nfsclient.61011: > > I got "Permission denied" message when I try to mkdir or rm. As a root > mount and as a user mount (sysctl vfs.usermounts=1). > With -sec=sys it works read-write, but with -sec=krb5 read-only.. > > my /etc/exports: > V4: /export_test -sec=krb5:krb5i:krb5p -network 192.168.0.0 -mask > 255.255.255.0 > /export_test -sec=krb5:krb5i:krb5p -network 192.168.0.0 -mask > 255.255.255.0 -maproot=root -alldirs > > tried with V4: / as well. > Added all the principals needed. > Tried also with full qualified domain names. > SSH works fine with Kerberos > > > Do I need rpcsec_gss.patch? (according to > http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup) > or can I make it work somehow else? > > I used FreeBSD-9.1-RELEASE-i386-disc1 > and > FreeBSD-10.0-CURRENT-i386-20130202-r246254-release > Thanks to Elias's hard work, a bug/fix for a Kerberos function has been identified that can make the gssd fail to map a principal to a uid. (I haven't run into this bug, so I don't know what systems are affected.) See this thread: http://docs.FreeBSD.org/cgi/mid.cgi?CADtN0WKVzbKxhaLQw8y2KLhhRJC9n4ht9wyPmGQ+pHqSjQkVNw I'd suggest you apply the patch (increasing the size of buf to 1024) and then try testing with libraries built with this patch applied. Good luck with it, rick > -- > Greets > Janusz > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Sound problems with skype in FreeBSD home.encontacto.net 9.1-STABLE FreeBSD 9.1-STABLE #410 r246209M: Sat Feb 16 05:07:32 CST 2013 fr amd64
Sound works fine for all players, browsers, etc. everything except SKYPE I've user both ports and both give the same results. Rigt now I'm using: skype-2.1.0.81_1,1 I've used it for years with no problems. It quite working during Christmas vacations. Where could I start to trouble shoot this other than just erasing and rebuilding the skype ports. Thanks, just in case: cat /compat/linux/etc/alsa/pcm/pcm-oss.conf pcm.oss1 { type oss device /dev/dsp1 hint { description "Open Sound System" } } ctl.oss1 { type oss device /dev/mixer1 hint { description "Open Sound System" } # -- Bienes Raíces in Coatepec, Veracruz, Mexico http://www.facebook.com/pages/Inmobiliaria-Bienes-Raices-httpEcoManiainfo/102249989850215?sk=photos_albums ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Sound problems with skype in FreeBSD home.encontacto.net 9.1-STABLE FreeBSD 9.1-STABLE #410 r246209M: Sat Feb 16 05:07:32 CST 2013 fr amd64
On 19/02/2013, at 10:54, Edwin L. Culp W. wrote: > cat /compat/linux/etc/alsa/pcm/pcm-oss.conf > > pcm.oss1 { >type oss >device /dev/dsp1 >hint { >description "Open Sound System" >} > } > > ctl.oss1 { >type oss >device /dev/mixer1 >hint { >description "Open Sound System" >} > Why are you using /dev/dsp1 & /dev/mixer1? I would have thought using /dev/dsp and /dev/mixer would work, and if you wanted to change which sound device you're using globally then set the hw.snd.default_unit sysctl. Also, what is the output of cat /dev/sndstat ? -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Sound problems with skype in FreeBSD home.encontacto.net 9.1-STABLE FreeBSD 9.1-STABLE #410 r246209M: Sat Feb 16 05:07:32 CST 2013 fr amd64
On Mon, Feb 18, 2013 at 7:10 PM, Daniel O'Connor wrote: > > On 19/02/2013, at 10:54, Edwin L. Culp W. wrote: > > cat /compat/linux/etc/alsa/pcm/pcm-oss.conf > > > > pcm.oss1 { > >type oss > >device /dev/dsp1 > >hint { > >description "Open Sound System" > >} > > } > > > > ctl.oss1 { > >type oss > >device /dev/mixer1 > >hint { > >description "Open Sound System" > >} > > > > > Why are you using /dev/dsp1 & /dev/mixer1? > Copied from the port. No logic. I did try with dsp and mixer only and restarted skype with the same results. > I would have thought using /dev/dsp and /dev/mixer would work, and if you > wanted to change which sound device you're using globally then set the > hw.snd.default_unit sysctl. > > Also, what is the output of cat /dev/sndstat ? > # cat /dev/sndstat FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64) Installed devices: pcm0: (play) pcm1: (play/rec) default pcm2: (play) pcm3: (play) pcm4: (play) The error that shows on the screen is : Problem with audio playback. Thanks, ed -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Sound problems with skype in FreeBSD home.encontacto.net 9.1-STABLE FreeBSD 9.1-STABLE #410 r246209M: Sat Feb 16 05:07:32 CST 2013 fr amd64
On 19/02/2013, at 11:58, Edwin L. Culp W. wrote: >> On Mon, Feb 18, 2013 at 7:10 PM, Daniel O'Connor >> wrote: >> Why are you using /dev/dsp1 & /dev/mixer1? > > Copied from the port. No logic. I did try with dsp and mixer only and > restarted skype with the same results. OK >> Also, what is the output of cat /dev/sndstat ? > > # cat /dev/sndstat > FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64) > Installed devices: > pcm0: (play) > pcm1: (play/rec) default > pcm2: (play) > pcm3: (play) > pcm4: (play) > > The error that shows on the screen is : Problem with audio playback. Oh right, Skype actually generates an error.. I am not sure sorry. Note that your default audio device is HDMI audio (not sure if that is what you really want) and if you don't have something connected via HDMI I suppose that could cause the error.. Try.. sudo sysctl hw.snd.default_unit=1 (leaving the ALSA config file alone) and then restart skype. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Having a problem compiling a customized kernel
All, I'm working on troubleshooting a random network dropout in an older Acer Aspire One, and am compiling an otherwise generic kernel with the following options: options ATH_DEBUG options AH_DEBUG options ATH_DIAGAPI I started the process with 'make buildkernel KERNCONF=ATH-KERNEL', but it aborted with the following: cc -c -O -pipe -std=c99 -g -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 -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror vers.c linking kernel.debug ld:/usr/src/sys/conf/ldscript.i386:66: syntax error *** [kernel.debug] Error code 1 Stop in /usr/obj/usr/src/sys/ATH-KERNEL. *** [buildkernel] Error code 1 Stop in /usr/src. *** [buildkernel] Error code 1 Stop in /usr/src. I'm currently running 9.1-RELEASE - I had to svn the source, as I had used freebsd-update last couple of weeks to move from 7.2 to 8.0 to 8.3 to 9.0 to 9.1. Does anyone have an idea what I might have done incorrectly, or at least how I might correct the issue? Thanks, Kurt On Mon, Feb 18, 2013 at 5:43 PM, Adrian Chadd wrote: > yup > > > > adrian > > > On 18 February 2013 17:32, Kurt Buff wrote: >> BTW - those should read >> >> options ATH_DEBUG >> options AH_DEBUG >> options ATH_DIAGAPI >> >> Correct? >> >> >> On Mon, Feb 18, 2013 at 5:21 PM, Adrian Chadd wrote: >>> Just athregs -i ath0 >>> >>> And you nee da kernel with ATH_DEBUG, AH_DEBUG and ATH_DIAGAPI compiled in: >>> :) >>> >>> >>> >>> adrian >>> >>> >>> On 18 February 2013 16:37, Kurt Buff wrote: Did a make at /usr/src/tools/tools/ath, and it all compiled, and got athregs copied into /usr/loca/bin. Don't see athpeek anywhere, though. Also, I tried 'athregs -i ath0 -a' and got back 'invalid argument'. Next steps? Kurt On Mon, Feb 18, 2013 at 10:39 AM, Adrian Chadd wrote: > okay. Just copy the athregs tool to /usr/local/bin/ then, and then run it? > > oh, hm. Try "make" first, rather than "make install" > > > adrian > > On 18 February 2013 08:27, Kurt Buff wrote: >> It already exists. >> >> On Sun, Feb 17, 2013 at 10:18 PM, Adrian Chadd >> wrote: >>> try mkdir /usr/local/bin first? >>> >>> >>> >>> adrian >>> >>> On 17 February 2013 22:04, Kurt Buff wrote: Um, I'm missing something, I suppose... I cd'ed to /usr/src/tools/tools/ath, and I see an athregs directory with Makefile and dumpregs.c in it, but when cd'ed into it and did a make install just got back an error message" install -s -o root -g wheel -m 555 athregs /usr/local/bin install: athregs: No such file or directory *** [_proginstall] Error code 71 Also, I don't see anything regarding athpeek. So, what next? Kurt On Sun, Feb 17, 2013 at 12:48 PM, Adrian Chadd wrote: > Hi, > > So "hal status 3" is HAL_EIO - which means the hardware didn't respond > as expected. > > So maybe the hardware is getting all angry during reset. > > Compile up athpeek and athregs from src/tools/tools/ath/, compile your > kernel with: > > ATH_DEBUG > AH_DEBUG > ATH_DIAGAPI > > and then when it happens again, do this: > > # athregs > > which will dump out a snapshot of useful registers. > > > > Adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Why can't gcc-4.2.1 build usable libreoffice?
On Mon, Feb 18, 2013 at 12:26 PM, Chris Rees wrote: > On 14 February 2013 13:57, Mikhail T. wrote: >> Hello! >> >> I just finished building editors/libreoffice with gcc-4.2.1 -- had to >> edit the port's Makefile to prevent it from picking a different >> compiler. Everything built and installed, but libreoffice dies on >> start-up (right after flashing the splash-window): >> >> (gdb) where >> #0 0x00080596c1aa in cppu::__getTypeEntries () >>from >> /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 >> #1 0x00080596c333 in cppu::__queryDeepNoXInterface () >>from >> /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 >> #2 0x00080596d4a2 in cppu::WeakImplHelper_query () >>from >> /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 >> #3 0x0008116f2b03 in >> >> cppu::WeakImplHelper1::queryInterface >> () >>from /opt/lib/libreoffice/ure/lib/bootstrap.uno.so >> #4 0x000805970347 in >> cppu::OInterfaceContainerHelper::disposeAndClear () >>from >> /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 >> #5 0x0008059705b2 in >> cppu::OMultiTypeInterfaceContainerHelper::disposeAndClear () >>from >> /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 >> #6 0x00080593309f in cppu::OComponentHelper::dispose () >>from >> /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 >> #7 0x000805963d00 in cppu::OFactoryComponentHelper::dispose () >>from >> /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 >> #8 0x0008116ec296 in stoc_smgr::OServiceManager::disposing () >> from /opt/lib/libreoffice/ure/lib/bootstrap.uno.so >> #9 0x00080596af05 in cppu::WeakComponentImplHelperBase::dispose () >>from >> /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 >> #10 0x0008116e6244 in stoc_smgr::ORegistryServiceManager::dispose () >>from /opt/lib/libreoffice/ure/lib/bootstrap.uno.so >> #11 0x00080596a573 in cppu::WeakComponentImplHelperBase::release () >>from >> /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 >> #12 0x0008059482f6 in (anonymous namespace)::createTypeRegistry () >>from >> /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 >> #13 0x0008059487bf in >> cppu::defaultBootstrap_InitialComponentContext () >>from >> /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 >> #14 0x000805948918 in >> cppu::defaultBootstrap_InitialComponentContext () >>from >> /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 >> #15 0x00080212f883 in >> desktop::Desktop::InitApplicationServiceManager () >>from /opt/lib/libreoffice/program/libmergedlo.so >> #16 0x00080211f362 in desktop::Desktop::Init () from >> /opt/lib/libreoffice/program/libmergedlo.so >> #17 0x000807622113 in InitVCL () from >> /opt/lib/libreoffice/program/libvcllo.so >> #18 0x000807623151 in ImplSVMain () from >> /opt/lib/libreoffice/program/libvcllo.so >> #19 0x0008076232d5 in SVMain () from >> /opt/lib/libreoffice/program/libvcllo.so >> #20 0x00080214942e in soffice_main () from >> /opt/lib/libreoffice/program/libmergedlo.so >> #21 0x00400773 in main () >> >> I do not blame the office@ team -- the port did not want to use >> gcc-4.2.1, I forced it to. But I'd like to know, what is wrong with the >> compiler shipped by FreeBSD-9.1 (and the only one, if WITHOUT_CLANG is >> defined), that prevents building a healthy libreoffice? >> >> Is there a bug fixed in gcc-4.6? Or is it some (incorrect) assumption >> made by libreoffice code? Thank you, > > Hi Mikhail, > > Libreoffice and openoffice have traditionally recommended that one use > binary packages instead of building it from scratch. > > I'm sure you understand that our compiler in base is rather elderly, > and that a project as insanely huge as Libreoffice is going to be > highly sensitive to minute changes. As a consequence, some very > narrow criteria are chosen to make maintenance of the port possible. > > You are welcome to try with gcc-4.6, but the last I heard it will only > build with clang. Your mileage may vary, please let us know of > success stories! Just for the record, is find that it works fine for me with gcc-4.6. 9.1-STABLE on i386 system. Building it with the default compiler results in a successful build, but the program would simply exit after a few seconds with no error. The exist status was 0. No messages. When I built with 4.6, it builds and runs fine, at least for the things I've tried. (4.6 invoked by setting WITH_GCC.) -- R. Kevin Oberman, Network En