Alexander Leidinger | 1 Dec 09:32 2009
Picon

Re: UNIX domain sockets on nullfs still broken?

Quoting Ivan Voras <ivoras <at> freebsd.org> (from Mon, 30 Nov 2009  
16:14:40 +0100):

> xorquewasp <at> googlemail.com wrote:
>> On 2009-11-30 15:43:01, Ivan Voras wrote:
>>> xorquewasp <at> googlemail.com wrote:
>>>> 76030 initial thread STRU  struct sockaddr { AF_LOCAL,  
>>>> /tmp/jack-11001/default/jack_0 }
>>>> 76030 initial thread NAMI  "/tmp/jack-11001/default/jack_0"
>>>> 76030 initial thread RET   connect -1 errno 61 Connection refused
>>> I would expect to see this result from the jail since it's  
>>> obviously a Bad Idea, but does it work from the same (host) machine

It is not a bad idea, at least not if we talk about mounting something  
from JailA to JailB. Think about the MySQL socket. I have a jail with  
MySQL, and I have a jail which wants to connect to it. I do not want  
to allow network connections between those jails (be it for  
performance reasons, or that I do not want to involve a network  
connection, or that I do not want to give the MySQL jail an IP at all  
or whatever).

Solution: give access to the socket via the FS. Ideally by putting the  
socket in its own directory and mounting this directory over to the  
jail. A workaround for this scenario is below.

>>> without the jail in between (i.e. just the nullfs, no jails)?
>>
>> Hm, yes, you're right. It does work without a jail involved.
>>
>> What's the sane solution, then, when the only method of communication
(Continue reading)

Alexander Best | 1 Dec 14:22 2009
Picon

i386_set_ioperm(2)/i386_get_ioperm(2) replacement after switch from x86 to amd64

hi there,

i recently switch from x86 to amd64. right now i'm looking for a way to
replace i386_set_ioperm(2) and i386_get_ioperm(2) (which are x86 specific).
any suggestions?

* full /dev/io access is rather nasty
* the app i'm developing is using inb/outb opcodes through inline assembly in
order to access the parallel port. i tried using ppi(4), but that slows down
things dramatically (see:
http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029188.html)

cheers.
alex
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"

Kostik Belousov | 1 Dec 15:13 2009
Picon

Re: i386_set_ioperm(2)/i386_get_ioperm(2) replacement after switch from x86 to amd64

On Tue, Dec 01, 2009 at 02:22:23PM +0100, Alexander Best wrote:
> hi there,
> 
> i recently switch from x86 to amd64. right now i'm looking for a way to
> replace i386_set_ioperm(2) and i386_get_ioperm(2) (which are x86 specific).
> any suggestions?
> 
> * full /dev/io access is rather nasty
> * the app i'm developing is using inb/outb opcodes through inline assembly in
> order to access the parallel port. i tried using ppi(4), but that slows down
> things dramatically (see:
> http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029188.html)

FreeBSD 8.0 supports these syscalls on amd64.
xorquewasp | 1 Dec 15:17 2009

Re: UNIX domain sockets on nullfs still broken?

On 2009-12-01 09:32:56, Alexander Leidinger wrote:
> 
> My workaround with MySQL is to have the jail and the socket in the  
> same FS (I would prefer to have them on separate FS). Then you can do  
> a hardlink of the socket into the jail (obviously after each restart  
> of the software, but this can be scripted). This works for me.
> 

Interesting. I'll try it. Thanks.

Regards,
xw
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"

Alexander Best | 1 Dec 16:21 2009
Picon

Re: i386_set_ioperm(2)/i386_get_ioperm(2) replacement after switch from x86 to amd64

i'm getting this during compilation/linking:

undefined reference to `i386_set_ioperm'

do i need to link against some x86 compat lib?

alex

ps: also the ioperm manuals are not getting installed on amd64 it seems.

Kostik Belousov schrieb am 2009-12-01:
> On Tue, Dec 01, 2009 at 02:22:23PM +0100, Alexander Best wrote:
> > hi there,

> > i recently switch from x86 to amd64. right now i'm looking for a
> > way to
> > replace i386_set_ioperm(2) and i386_get_ioperm(2) (which are x86
> > specific).
> > any suggestions?

> > * full /dev/io access is rather nasty
> > * the app i'm developing is using inb/outb opcodes through inline
> >   assembly in
> > order to access the parallel port. i tried using ppi(4), but that
> > slows down
> > things dramatically (see:
> > http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029188.html)

> FreeBSD 8.0 supports these syscalls on amd64.
_______________________________________________
(Continue reading)

Linda Messerschmidt | 1 Dec 16:22 2009
Picon

Re: UNIX domain sockets on nullfs still broken?

On Mon, Nov 30, 2009 at 10:14 AM, Ivan Voras <ivoras <at> freebsd.org> wrote:
>> What's the sane solution, then, when the only method of communication
>> is unix domain sockets?
>
> It is a security problem. I think the long-term solution would be to add a
> sysctl analogous to security.jail.param.securelevel to handle this.

Out of curiosity, why is allowing accessing to a Unix domain socket in
a filesystem to which a jail has explicitly been allowed access more
or less secure than allowing access to a file or a devfs node in a
filesystem to which a jail has explicitly been allowed access?
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"

Kostik Belousov | 1 Dec 16:50 2009
Picon

Re: i386_set_ioperm(2)/i386_get_ioperm(2) replacement after switch from x86 to amd64

On Tue, Dec 01, 2009 at 04:21:39PM +0100, Alexander Best wrote:
> i'm getting this during compilation/linking:
> 
> undefined reference to `i386_set_ioperm'
Libc wrappers for these syscalls are not provided by amd64 libc.
Use sysarch(2) to execute them.

> 
> do i need to link against some x86 compat lib?
You cannot link 32bit library to amd64 binary.

> 
> alex
> 
> ps: also the ioperm manuals are not getting installed on amd64 it seems.
> 
> Kostik Belousov schrieb am 2009-12-01:
> > On Tue, Dec 01, 2009 at 02:22:23PM +0100, Alexander Best wrote:
> > > hi there,
> 
> > > i recently switch from x86 to amd64. right now i'm looking for a
> > > way to
> > > replace i386_set_ioperm(2) and i386_get_ioperm(2) (which are x86
> > > specific).
> > > any suggestions?
> 
> > > * full /dev/io access is rather nasty
> > > * the app i'm developing is using inb/outb opcodes through inline
> > >   assembly in
> > > order to access the parallel port. i tried using ppi(4), but that
(Continue reading)

Ravi Shankar | 1 Dec 23:00 2009
Picon

Regarding enabling IOAPIC on Intel Dual core processor based boards having Broadcom controller

Hi,

 We are using Freebsd6.2 bases OS on our LV 5200 Series Intel Dual Core Xeon
bases processor(Wolfdale-DP-ULV). In the carrier board hosting the processor
we have BCM5703 controller.
Currently we are using only one core in 32 bit mode and planning to use dual
core where we need to enable IOAPIC. When IOAPIC is not enabled I see the
bcm/bge driver is attached to IRQ10 and everything works fine, but when I
enable IOAPIC I still see the boot msgs show that bge is attached to irq10
but the Broadcom controller does not come up. I found interrupt storm on
irq17 ( remember without IOAPIC enable there are not IRQ assignments beyond
IRQ16),looks like the controller is interrupting on 17 while driver waits on
10.

  When I stop and loader and assign it manually using config command "set
hw.pci8.9.INTA.irq=”17”" , everything works fine. Would be great if some one
can throw some light on this IRQ mapping when IOAPIC is enabled and possible
fix ( Software or BIOS?)

Thanks,
Ravi

--

-- 
Thanks,
Ravi
"The most influential person who will talk to you all day is you, so
you should be very careful about what you say to you!"
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
(Continue reading)

Ravi Shankar | 2 Dec 00:11 2009
Picon

Regarding enabling IOAPIC on Intel Dual core processor based boards having Broadcom controller

Hi,

 We are using Freebsd6.2 bases OS on our LV 5200 Series Intel Dual Core Xeon bases
processor(Wolfdale-DP-ULV). In the carrier board hosting the processor we have BCM5703 controller.
Currently we are using only one core in 32 bit mode and planning to use dual core where we need to enable
IOAPIC. When IOAPIC is not enabled I see the bcm/bge driver is attached to IRQ10 and everything works fine,
but when I enable IOAPIC I still see the boot msgs show that bge is attached to irq10 but the Broadcom
controller does not come up. I found interrupt storm on irq17 ( remember without IOAPIC enable there are
not IRQ assignments beyond IRQ16),looks like the controller is interrupting on 17 while driver waits on 10.

  When I stop and loader and assign it manually using config command "set hw.pci8.9.INTA.irq=”17”" ,
everything works fine. Would be great if some one can throw some light on this IRQ mapping when IOAPIC is
enabled and possible fix ( Software or BIOS?)

NOTE: Other devices ( Intel controller (em driver)) are working fine only this BCM5703 is having issues
with IOAPIC

Thanks,
Ravi

      
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"

Andriy Gapon | 2 Dec 10:59 2009
Picon

Re: ukbd attachment and root mount

on 28/11/2008 15:12 Andriy Gapon said the following:
> on 27/11/2008 15:23 Andriy Gapon said the following:
>> I increased debug level in uhub and also switched mouse and keyboard
>> ports hoping that order might matter. It didn't.
>>
>> Here's fresh usbdevs output snippet:
>> Controller /dev/usb2:
>> addr 1: full speed, self powered, config 1, UHCI root hub(0x0000),
>> Intel(0x0000), rev 1.00
>>   uhub2
>>  port 1 addr 3: low speed, power 100 mA, config 1, USB Keyboard(0x0101),
>> CHESEN(0x0a81), rev 1.10
>>    ukbd0
>>    uhid0
>>  port 2 addr 2: low speed, power 98 mA, config 1, USB-PS/2 Optical
>> Mouse(0xc040), Logitech(0x046d), rev 24.30
>>    ums0
>>
>> And here's a new snippet from cold explore dmesg:
>> uhub2: uhub_explore: port 1 status 0x0100 0x0001
>> + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> + So, hm, it looks like a change in connection status is reported but
>> current status is reported as not connected.
>> + I wonder why?

Just wanted to followup on this and let you know that the issue seems to be
resolved in stable/8, I think that early usb takeover change might have fixed it.
The change is not in 8.0.

> For now I am blaming this on the keyboard. My wild un-educated guess is
(Continue reading)


Gmane