Hi,
I've tested the second diff (containing the bug fix and I get a lock
order reversal on bootup. On the first patch I was getting the same
lock order reversal while using X and sometimes (only sometimes) would
crash X.
witness: lock order reversal:
1st 0xfd83fef05248 uobjlk (&uobj->vmobj
Tom Murphy wrote:
> Hi,
>
> Here's an updated diff from Omar Polo's addition of group-last
> command to cwm. I've been using it without issues and it's
> really handy to be able to switch back to the previous
> workspace you were on with it.
>
&
Hi,
Here's an updated diff from Omar Polo's addition of group-last
command to cwm. I've been using it without issues and it's
really handy to be able to switch back to the previous
workspace you were on with it.
Many thanks to Omar Polo for doing all the original work. I've
just updat
Hi,
I noticed the kernel was just printing out the generic hex device id
rather than the name of my keyboard so I did some checking and
there is a vendor id for "Gear Head" keyboards. These keyboards are
sometimes resold under different names like Octogen or Sanoxy, but
they are r
Hi Stefan,
Thanks very much for the 11n support in athn(4)! Here's mine:
athn0 at pci5 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2 int 16
athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:24:c8:4f
I did some netperf tests between OpenBSD athn(4) in hostap mode (11n)
and a Linux
Mark Kettenis wrote:
> I'm looking for people with one of the following unsupported Intel
> wireless chips:
>
> Intel Centrino Wireless-N 2200 (shows up as Wireless-N 2000 in dmesg)
> Intel Centrino Wireless-N 135
> Intel Centrino Wireless-N 105
>
> If you have one of these, please try the attach
Stefan,
Your patch works well on my system:
ral0 at pci0 dev 14 function 0 "Ralink RT2661" rev 0x00: irq 10, address
00:14:85:d5:39:bb
ral0: MAC/BBP RT2661D, RF RT2529 (MIMO XR)
Only problem is downloading from the net is extremely slow. Benchmarks
have it at 512 KB/sec as opposed t
You guys might want to add a note to current.html that from October
13 2011, the NAT updates have made it impossible to not use an address
family in a nat-to statement.
The following statement fails now:
match out on egress from ($int_if:network) nat-to (egress)
Gives the error:
/etc/pf.conf:74
Many thanks to oga@ for this. I have been using this patch for at least
a month now and not had any issues.
Relevant bits of dmesg:
pchb0 at pci0 dev 0 function 0 "NVIDIA nForce3 250 PCI Host" rev 0xa1
mmuagp0 at pchb0: 1 Miscellaneous Control unit(s) found
agp0 at mmuagp0: aperture at 0xf000
Hi,
I originally sent this to misc@ but it probably got lost in all
the noise, so here it is again.
I went through the PR database and found a case where someone was
having problems with the MAC address being different between dmesg/
kernel time and later. I did not find that to be an issue a
Janne Johansson wrote:
>> 2011/4/3 Claudio Jeker
>>
>> bce(4) was turned off because of limitations in the DMA engine that allows
>> the chip to access only 1G of memory. On systems with more then 1G of
>> memory hilarity ensued.
>>
>> Now I rewrote the driver to use bcopy() to copy the mbufs into
On 21/05/10 18:42, Giovanni Bechis wrote:
> Il 21/05/2010 19.31, Tom Murphy ha scritto:
>>Is there any update on this? Is it possible to get the chipset
>> working?
>>
> At least latest version breaks this chip (found on IBM x40):
> ath0 at pci1 dev 2 function 0 &
On Wed, May 05, 2010 at 02:37:54PM +0200, Giovanni Bechis wrote:
> On 05/05/10 13:25, Tom Murphy wrote:
> >My guess is the device isn't supported or WPA/WPA2 isn't working yet
> >for it? Haven't tried with an open/unencrypted access or WEP point yet
> >
Hi Luis,
The patch works on my system. ifconfig ath0 up doesn't lock the system
I enabled debug and it does an active scan where it sends probes to
ff:ff:ff:ff:ff:ff on a bunch of channels, gets a beacon from my AP, then
when it tries to send an auth to my AP, I get: "ath0: device timeout".
On Mon, Apr 26, 2010 at 03:38:19PM +0100, Luis Henriques wrote:
> On Mon, Apr 26, 2010 at 7:57 AM, Tom Murphy wrote:
> > Hi Luis,
> >
> > Yes, that is correct. Do you need the rf value from the patched kernel?
> > I basically patched the latest -CURRENT (cvs tre
On Sun, Apr 25, 2010 at 10:49:26PM +0100, Luis Henriques wrote:
> On Sun, Apr 25, 2010 at 08:29:35PM +0100, Tom Murphy wrote:
> > Luis,
> >
> > I have an Asus EEE with uses an AR5424 chipset:
> >
> > ath0 at pci3 dev 0 function 0 "Atheros AR5424" rev
Luis,
I have an Asus EEE with uses an AR5424 chipset:
ath0 at pci3 dev 0 function 0 "Atheros AR5424" rev 0x01: apic 1 int 18 (irq 10)
ath0: AR5424 14.2 phy 7.0 rf 0.0, WOR0W, address 00:15:af:b5:36:7f
I tried the latest patch you posted and it locks OpenBSD completely up
when bringing the ne
Here is the combined diff from these sources:
http://www.mail-archive.com/tech@openbsd.org/msg01261.html
http://www.mail-archive.com/m...@openbsd.org/msg83528.html
Applied against most recent -current checkout:
--- rt2661.c.orig Mon Jan 18 11:51:03 2010
+++ rt2661.cMon Jan 18 12:11:55
There's also this patch:
http://www.mail-archive.com/tech@openbsd.org/msg01261.html
I'm going to apply it and the original and do some testing.
Tom
Marco Peereboom wrote:
> Has this been tested on all variants of the chip?
Well, not by me, but other people on misc mentioned it fixed ral(4)
issues for them. I only have a RT2661 and a RT2860 (the patch does
not touch RT2860).
I still do get the odd wireless dropout now and then, but it basical
Hi,
I'd like to point out that Roland Dreier's patch as detailed
here: http://www.mail-archive.com/m...@openbsd.org/msg83528.html
Works great on my little Soekris 5501 with a RT2661. (dmesg attached
to end of this email.)
I do still get the odd wireless drop for 15-20 seconds, but it
no long
21 matches
Mail list logo
