Hi Amit,
Amit Kulkarni wrote on Tue, Sep 09, 2014 at 08:47:22PM -0500:
> A basic rule of thumb when building ports: raise your /etc/login.conf
> limits...especially datasize-cur needs to be 2G and datasize-max needs to
> be 3G. The reason being there are some ports where the linker blows up to
>
On Tue, Sep 9, 2014 at 2:13 PM, David Coppa wrote:
> On Tue, Sep 9, 2014 at 7:58 PM, Ingo Schwarze wrote:
> > Hi David,
> >
> > David Coppa wrote on Tue, Sep 09, 2014 at 07:44:47PM +0200:
> >> On Tue, Sep 9, 2014 at 7:27 PM, Ingo Schwarze wrote:
> >
> >>> i'm sorry to say it makes no difference
On Tue, Sep 09, 2014 at 03:54:48PM +0100, Stuart Henderson wrote:
> On 2014/09/09 16:38, David Coppa wrote:
> > On Tue, Sep 9, 2014 at 4:30 PM, Erling Westenvik
> > wrote:
> > > On Tue, Sep 09, 2014 at 12:38:04PM +0200, Fabian Raetz wrote:
> > >> Devices tested so far:
> > >>
> > >> Inter WiFi Lin
On 2014/09/09 14:05, Mike Larkin wrote:
> IIRC there were problems with the rl(4)/re(4) watchdog timer not being
> implemented in qemu (or implemented in a way that is incompatible with
> OpenBSD), which caused a stream of "watchdog timeouts". I've switched to
> em(4) since about a year ago so I do
On Tue, Sep 09, 2014 at 10:56:59PM +0200, Mark Kettenis wrote:
> > From: Stefan Fritsch
> > Date: Tue, 09 Sep 2014 22:41:53 +0200
> >
> > On Tuesday 09 September 2014 21:27:37, Mark Cave-Ayland wrote:
> > > > Could the PCI virtio stuff be adapted to non-x86 architectures?
> > >
> > > QEMU alread
> From: Stefan Fritsch
> Date: Tue, 09 Sep 2014 22:41:53 +0200
>
> On Tuesday 09 September 2014 21:27:37, Mark Cave-Ayland wrote:
> > > Could the PCI virtio stuff be adapted to non-x86 architectures?
> >
> > QEMU already has a virtio PCI device that can be plugged into
> > qemu-system-sparc64 (
On 2014/09/09 21:18, Mark Cave-Ayland wrote:
> On 09/09/14 19:57, Brad Smith wrote:
>
> >The Realtek hardware in that dmesg is an NE2000 PCI adapter which
> >the sparc64 kernel config indeed does not have a driver for at the
> >very moment, although it could be added. Having a QEMU driver for
> >t
On Tuesday 09 September 2014 21:27:37, Mark Cave-Ayland wrote:
> > Could the PCI virtio stuff be adapted to non-x86 architectures?
>
> QEMU already has a virtio PCI device that can be plugged into
> qemu-system-sparc64 (see Artyom's blog at
> http://tyom.blogspot.co.uk/2013/03/debiansparc64-whee
On 09/09/14 21:26, Miod Vallat wrote:
Interesting. Longer term the aim of the QEMU project is to move the
hardwired machine types into pluggable devices, e.g. you can build a whole
machine on the command line from multiple -device parameters or preload the
default machine types such as sun4u usi
On 09/09/14 20:04, Bryan Steele wrote:
Neat! :-)
It seems the GENERIC sparc64 kernel already has PCMCIA/CardBus ne(4), so
adding 'ne* at pci?' might "just work".
OpenBSD/sparc64 already supports sun4v LDOMS, so there's drivers implementing
the virtual protocols (..vnet(4)/vdsk(4)). Does QEMU s
> Interesting. Longer term the aim of the QEMU project is to move the
> hardwired machine types into pluggable devices, e.g. you can build a whole
> machine on the command line from multiple -device parameters or preload the
> default machine types such as sun4u using instructions from a file. So w
On 09/09/14 19:57, Brad Smith wrote:
The Realtek hardware in that dmesg is an NE2000 PCI adapter which
the sparc64 kernel config indeed does not have a driver for at the
very moment, although it could be added. Having a QEMU driver for
the Happy Meal MAC would provide the best level of compatibi
Hm interesting ... i can reproduce it here with an 2.4GHz AP.
The entry isn't cleared when scanning and the interface is up.
Scanning when the interface is down works correct for me.
I will take a look at it tommorow :)
2014-09-09 21:48 GMT+02:00 Stuart Henderson :
> I have just noticed one thin
On 09/09/14 19:54, Mark Kettenis wrote:
Sweet.
The RealTek 8129 should be supported by the rl(4) driver, and is
AFAICT included in the RAMDISK kernel. Not sure why it doesn't
attach. If it is easy to hook up QEMU's e1000 hardware emulation to
the emulated sparc64 hardware, that should be supp
I have just noticed one thing with this; the 5GHz AP which I powered up for
a test is still showing in my current scan result long after I turned it off
again. Caching issue somewhere?
> Date: Tue, 9 Sep 2014 19:07:30 +
> From: Miod Vallat
>
> > The RealTek 8129 should be supported by the rl(4) driver, and is
> > AFAICT included in the RAMDISK kernel. Not sure why it doesn't
> > attach. If it is easy to hook up QEMU's e1000 hardware emulation to
> > the emulated sparc64 h
On Tue, Sep 9, 2014 at 7:58 PM, Ingo Schwarze wrote:
> Hi David,
>
> David Coppa wrote on Tue, Sep 09, 2014 at 07:44:47PM +0200:
>> On Tue, Sep 9, 2014 at 7:27 PM, Ingo Schwarze wrote:
>
>>> i'm sorry to say it makes no difference for me (i'm not opposed to the
>>> diff, though).
>>>
>>> On my la
> The RealTek 8129 should be supported by the rl(4) driver, and is
> AFAICT included in the RAMDISK kernel. Not sure why it doesn't
> attach. If it is easy to hook up QEMU's e1000 hardware emulation to
> the emulated sparc64 hardware, that should be supported as well on the
> OpenBSD side.
Nothi
On Tue, Sep 09, 2014 at 07:20:09PM +0100, Mark Cave-Ayland wrote:
> Hi all,
>
> Following up from my posts at the beginning of the summer, I'm pleased to
> announce that as of today, qemu-system-sparc64 built from QEMU git master
> will successfully install OpenBSD from an .iso and boot back into
On 09/09/14 2:20 PM, Mark Cave-Ayland wrote:
Hi all,
Following up from my posts at the beginning of the summer, I'm pleased
to announce that as of today, qemu-system-sparc64 built from QEMU git
master will successfully install OpenBSD from an .iso and boot back into
it in serial mode with its de
> Date: Tue, 09 Sep 2014 19:20:09 +0100
> From: Mark Cave-Ayland
>
> Hi all,
>
> Following up from my posts at the beginning of the summer, I'm pleased
> to announce that as of today, qemu-system-sparc64 built from QEMU git
> master will successfully install OpenBSD from an .iso and boot back
-current build on amd64 fails in libkvm:
===> libkvm
cc -O2 -pipe -g -D_LIBKVM -c -fpic -DPIC /usr/src/lib/libkvm/kvm_proc2.c -o
kvm_proc2.so
cc -O2 -pipe -g -D_LIBKVM -c -p /usr/src/lib/libkvm/kvm_proc2.c -o
kvm_proc2.po
cc -O2 -pipe -g -D_LIBKVM -c /usr/src/lib/libkvm/kvm_proc2.c -o kvm_
Hi all,
Following up from my posts at the beginning of the summer, I'm pleased
to announce that as of today, qemu-system-sparc64 built from QEMU git
master will successfully install OpenBSD from an .iso and boot back into
it in serial mode with its default sun4u emulation:
$ ./qemu-system-s
Hi David,
David Coppa wrote on Tue, Sep 09, 2014 at 07:44:47PM +0200:
> On Tue, Sep 9, 2014 at 7:27 PM, Ingo Schwarze wrote:
>> i'm sorry to say it makes no difference for me (i'm not opposed to the
>> diff, though).
>>
>> On my laptop, building ports works fine, running firefox works fine,
>> b
> Date: Tue, 9 Sep 2014 19:27:42 +0200
> From: Ingo Schwarze
>
> Hi Mark,
>
> Mark Kettenis wrote on Mon, Sep 08, 2014 at 11:35:36PM +0200:
>
> > The more code & documentation I read, the more I'm convinced that
> > coordinating state changes between logical processors isn't necessary
> > and a
> Date: Tue, 9 Sep 2014 17:29:35 +0200
> From: Fabian Raetz
>
> On Tue, Sep 09, 2014 at 12:38:04PM +0200, Fabian Raetz wrote:
> > Hi,
> >
> > below is a patch for iwn(4) which hopefully fixes a problem where iwn(4)
> > does not return from a scan, if the interface is up.
>
> here's an updated
On Tue, Sep 9, 2014 at 7:27 PM, Ingo Schwarze wrote:
> i'm sorry to say it makes no difference for me (i'm not opposed to the
> diff, though).
>
> On my laptop, building ports works fine, running firefox works fine,
> but whenever i surf the web with firefox while building ports,
> the machine lo
Hi Mark,
Mark Kettenis wrote on Mon, Sep 08, 2014 at 11:35:36PM +0200:
> The more code & documentation I read, the more I'm convinced that
> coordinating state changes between logical processors isn't necessary
> and actually is responsible for the hangs people have been seeing.
>
> So here is a
On Tue, Sep 9, 2014 at 5:29 PM, Fabian Raetz wrote:
> On Tue, Sep 09, 2014 at 12:38:04PM +0200, Fabian Raetz wrote:
>> Hi,
>>
>> below is a patch for iwn(4) which hopefully fixes a problem where iwn(4)
>> does not return from a scan, if the interface is up.
>
> here's an updated version which does
Remove redundant dc_stop() / dc_reset() calls from dc_intr() and dc_watchdog()
which dc_init() already takes care of.
OK?
Index: ic/dc.c
===
RCS file: /home/cvs/src/sys/dev/ic/dc.c,v
retrieving revision 1.134
diff -u -p -u -p -r1.13
I can confirm that hdr->max_svc / hdr->pause_svc messed up with my
"Intel WiFi Link 5100" and the patch works without them.
Best Regards,
mpp
On 09/09/14 17:29, Fabian Raetz wrote:
> On Tue, Sep 09, 2014 at 12:38:04PM +0200, Fabian Raetz wrote:
>> Hi,
>>
>> below is a patch for iwn(4) which hopef
That definitely sounds like a solution that will work. I can assign all users
to a common LDAP group and define a PF rule per each of the three groups.
Thank you! I'll let you know how it works out.
James
-Original Message-
From: owner-t...@openbsd.org [mailto:owner-t...@openbsd.org]
On 2014/09/09 15:36, Nagle, Edwin (James) wrote:
> I thought about running different sshd daemons but that doesn't really
> help in my situation. User IP's can vary wildly but I can restrict
> access *to* the box using radius based on username. Problem is once
> that user connects, I need to restri
On Tue, Sep 09, 2014 at 12:38:04PM +0200, Fabian Raetz wrote:
> Hi,
>
> below is a patch for iwn(4) which hopefully fixes a problem where iwn(4)
> does not return from a scan, if the interface is up.
here's an updated version which does not
set hdr->max_svc / hdr->pause_svc.
Cristoph Zimmerman
I thought about running different sshd daemons but that doesn't really help in
my situation. User IP's can vary wildly but I can restrict access *to* the box
using radius based on username. Problem is once that user connects, I need to
restrict his outbound access based on an IP policy, which
Nagle, Edwin (James) [edwin.na...@austinenergy.com] wrote:
> Good morning,
>
> My problem is, I am separating users based on interface IP and radius, and
> therefore need to force their outbound SSH sessions to bind to the IP address
> of the interface they came in on (or at least a different IP
David Gwynne [da...@gwynne.id.au] wrote:
> can someone test this?
>
Running now.
arc0 at pci3 dev 14 function 0 "Areca ARC-1210" rev 0x00: apic 8 int 19
arc0: 4 ports, 256MB SDRAM, firmware V1.43 2007-4-17
scsibus1 at arc0: 16 targets
sd0 at scsibus1 targ 0 lun 0: SCSI3 0/direct
fixed eui.0004
Good morning,
First, I would like to thank everyone in advance for any assistance or insight
that can be provided with what I am trying to accomplish. The server I am
attempting to build is basically a bastion host server in which users can
access to SSH out to other firewalled connections. H
On 2014/09/09 16:38, David Coppa wrote:
> On Tue, Sep 9, 2014 at 4:30 PM, Erling Westenvik
> wrote:
> > On Tue, Sep 09, 2014 at 12:38:04PM +0200, Fabian Raetz wrote:
> >> Devices tested so far:
> >>
> >> Inter WiFi Link 5100 (Marcin Piotr Pawlowski)
> >> Intel Centrino Advanced-N 6205
On 2014/09/09 12:38, Fabian Raetz wrote:
> Hi,
>
> below is a patch for iwn(4) which hopefully fixes a problem where iwn(4)
> does not return from a scan, if the interface is up.
This works nicely for me, same device as one of your previous testers I think:
iwn0 at pci2 dev 0 function 0 "Intel
On Tue, Sep 9, 2014 at 4:30 PM, Erling Westenvik
wrote:
> On Tue, Sep 09, 2014 at 12:38:04PM +0200, Fabian Raetz wrote:
>> Devices tested so far:
>>
>> Inter WiFi Link 5100 (Marcin Piotr Pawlowski)
>> Intel Centrino Advanced-N 6205(Mike Burns, who also reported the
>> problem on m
On Tue, Sep 09, 2014 at 12:38:04PM +0200, Fabian Raetz wrote:
> Devices tested so far:
>
> Inter WiFi Link 5100 (Marcin Piotr Pawlowski)
> Intel Centrino Advanced-N 6205(Mike Burns, who also reported the
> problem on misc@, thanks!)
> Intel Centrino Wireless-N 2230(Fabian
Hi,
below is a patch for iwn(4) which hopefully fixes a problem where iwn(4)
does not return from a scan, if the interface is up.
This patch was backported from this FreeBSD commit
https://svnweb.freebsd.org/base?view=revision&revision=258829
-
Overhaul the iwn(4) scan infrastructure to
On 2014/09/08 23:35, Mark Kettenis wrote:
> The more code & documentation I read, the more I'm convinced that
> coordinating state changes between logical processors isn't necessary
> and actually is responsible for the hangs people have been seeing.
>
> So here is a diff that does away with it al
44 matches
Mail list logo
