Re: new jail(8) ignoring devfs_ruleset?

2013-02-18 Thread Harald Schmalzbauer
 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)

2013-02-18 Thread Yamagi Burmeister
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:

2013-02-18 Thread Marc Fournier

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:

2013-02-18 Thread Marc Fournier

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?

2013-02-18 Thread Harald Schmalzbauer
 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?

2013-02-18 Thread Daniel Eischen

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?

2013-02-18 Thread Jamie Gritton

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?

2013-02-18 Thread Mateusz Guzik
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?

2013-02-18 Thread Jamie Gritton



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?

2013-02-18 Thread Chris Rees
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

2013-02-18 Thread Guido Falsi

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

2013-02-18 Thread Rick Macklem
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

2013-02-18 Thread Edwin L. Culp W.
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

2013-02-18 Thread Daniel O'Connor

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

2013-02-18 Thread Edwin L. Culp W.
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

2013-02-18 Thread Daniel O'Connor

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

2013-02-18 Thread Kurt Buff
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?

2013-02-18 Thread Kevin Oberman
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