Christiano F. Haesbaert | 1 Feb 2011 01:04
Favicon
Gravatar

Re: tcpbench udp support + libevent.

On Mon, Jan 31, 2011 at 01:38:28PM -0200, Christiano F. Haesbaert wrote:
> Did some digging in POSIX and it seems to be a SO_SNDLOWAT issue.
> 
> Posix states the following:
> If a descriptor refers to a socket, the implied output function is the
> sendmsg() function supplying an amount of normal data equal to the
> current value of the SO_SNDLOWAT option for the socket. If a
> non-blocking call to the connect() function has been made for a
> socket, and the connection attempt has either succeeded or failed
> leaving a pending error, the socket shall be marked as writable.
> 
> out manpage:
> SO_SNDLOWAT is an option to set the minimum count for output operations.
>      Most output operations process all of the data supplied by the call,
>      delivering data to the protocol for transmission and blocking as
>      necessary for flow control.  Nonblocking output operations will process
>      as much data as permitted subject to flow control without blocking, but
>      will process no data if flow control does not allow the smaller of the
>      low water mark value or the entire request to be processed.
> 
> As I'm sending packets with 1472 bytes, kevent/poll is probably
> returning a writable state considering when 1024 bytes are available.
> I'll give it a try when I get home, this should be enough.
> 
> Sorry for the noise.

No, still no luck, seems like a bug to me.

--

-- 
Christiano Farina HAESBAERT
(Continue reading)

Philip Guenther | 1 Feb 2011 09:47
Picon

Re: AML PARSE ERROR

On Mon, Jan 31, 2011 at 7:04 AM, karthic kumaran <k3.karthic <at> gmail.com> wrote:
> I recently upgraded to -current because the intel graphics driver in the 4.8
> release freezes my computer. I have a Core i3 with integrated graphics,
> every time i boot my laptop with multiprocessor turned on i get an AML PARSE
> ERROR. I am running the GENERIC.MP kernel with INTELDRM_GEM.

So, you're running GENERIC.MP, but locally compiled.  What about that
INTERLDRM_GEM option you added, you wonder?  That option has had *NO
EFFECT* for over 8 months!  If you don't understand why you're
building and running a custom kernel, then you shouldn't be.  Just use
GENERIC.MP from the snapshots and save your own time and that of the
developers.

As for the error itself:

> acpiec0 at acpi0### AML PARSE ERROR (0x105b8): Undefined name:
> \\_PR_.CPU0._PPC
> error evaluating: \\_SB_.PCI0.LPCB.EC0_._REG
> acpiec _REG failed, broken BIOS

So, OpenBSD thinks the BIOS is broken.  Has HP released a BIOS update
for that machine?

Philip Guenther

k3.karthic | 1 Feb 2011 10:27
Picon

Re: AML PARSE ERROR

> So, you're running GENERIC.MP, but locally compiled.  What about that
> INTERLDRM_GEM option you added, you wonder?  That option has had *NO
> EFFECT* for over 8 months!  If you don't understand why you're
> building and running a custom kernel, then you shouldn't be.  Just use
> GENERIC.MP from the snapshots and save your own time and that of the
> developers.

I was not aware that inteldrm_gem has no effect for 8 months, in my
case x11 will freeze up if i try to run glxgears or even use mplayer
without inteldrm_gem option.

>
> As for the error itself:
>
> > acpiec0 at acpi0### AML PARSE ERROR (0x105b8): Undefined name:
> > \\_PR_.CPU0._PPC
> > error evaluating: \\_SB_.PCI0.LPCB.EC0_._REG
> > acpiec _REG failed, broken BIOS
>
> So, OpenBSD thinks the BIOS is broken.  Has HP released a BIOS update
> for that machine?
>
> Philip Guenther

No HP has not released any BIOS update, i used to run Fedora 13 on my
laptop and it gave the same complaint. However, a kernel upgrade
cleared the error. This error has not caused any problems while
working on the laptop i just wanted to know if this is a hardware
fault or not.

(Continue reading)

David Coppa | 1 Feb 2011 10:34
Picon

new umsm device: Toshiba 3G HSDPA MiniCard

This makes the umsm driver recognize the WWAN module integrated in my
Dell Latitude D630... And it works as intended, using cuaU2 as device.

Before:

spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
mtrr: Pentium Pro MTRR support
ugen0 at uhub3 port 2 "Novatel Wireless Novatel Wireless HSDPA Modem"
rev 1.10/0.00 addr 2

After:

spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
mtrr: Pentium Pro MTRR support
umsm0 at uhub3 port 2 configuration 1 interface 0 "Novatel Wireless
Novatel Wireless HSDPA Modem" rev 1.10/0.00 addr 2
ucom0 at umsm0
umsm1 at uhub3 port 2 configuration 1 interface 1 "Novatel Wireless
Novatel Wireless HSDPA Modem" rev 1.10/0.00 addr 2
ucom1 at umsm1
umsm2 at uhub3 port 2 configuration 1 interface 2 "Novatel Wireless
Novatel Wireless HSDPA Modem" rev 1.10/0.00 addr 2
ucom2 at umsm2
umsm3 at uhub3 port 2 configuration 1 interface 3 "Novatel Wireless
Novatel Wireless HSDPA Modem" rev 1.10/0.00 addr 2
ucom3 at umsm3

Here's the diff.
(Continue reading)

Stuart Henderson | 1 Feb 2011 12:34
Favicon
Gravatar

Re: new umsm device: Toshiba 3G HSDPA MiniCard

On 2011/02/01 10:34, David Coppa wrote:
> This makes the umsm driver recognize the WWAN module integrated in my
> Dell Latitude D630... And it works as intended, using cuaU2 as device.

> --- usbdevs.h	30 Jan 2011 17:28:56 -0000	1.549
> +++ usbdevs.h	1 Feb 2011 08:44:07 -0000
>  <at>  <at>  -3688,6 +3688,7  <at>  <at> 
> 
>  /* Toshiba Corp products */
>  #define	USB_PRODUCT_TOSHIBA_RT3070	0x0a07		/* RT3070 */
> +#define	USB_PRODUCT_TOSHIBA_HSDPA_MINICARD	0x1302	/* Toshiba 3G HSDPA
> == Novatel Expedite EU870D MiniCard */

This file should be as generated by 'make', no extra comments

Mark Lumsden | 1 Feb 2011 13:33

bce - not working

The bce(4) driver was removed from i386 GENERIC by Theo a few months ago because
it can only access 1GB ram. My Dell Latitude D520 has 2GB RAM and sure enough the 
driver did random things when I tried to use it back then. Ive looked at NetBSD
and they have an extra bus_dmatag_subregion() function for restricting the
memory range the driver accesses. Should this be implemented for OpenBSD? 

-mark

David Coppa | 1 Feb 2011 13:01
Picon

Re: new umsm device: Toshiba 3G HSDPA MiniCard

On Tue, Feb 1, 2011 at 12:34 PM, Stuart Henderson <stu <at> spacehopper.org> wrote:

> This file should be as generated by 'make', no extra comments

Right.

Here's the updated diff:

Index: umsm.c
===================================================================
RCS file: /cvs/src/sys/dev/usb/umsm.c,v
retrieving revision 1.71
diff -u -p -r1.71 umsm.c
--- umsm.c	25 Jan 2011 20:03:36 -0000	1.71
+++ umsm.c	1 Feb 2011 11:06:18 -0000
 <at>  <at>  -231,6 +231,8  <at>  <at>  static const struct umsm_type umsm_devs[
 	{{ USB_VENDOR_TCTMOBILE, USB_PRODUCT_TCTMOBILE_UMASS }, DEV_UMASS3},
 	{{ USB_VENDOR_TCTMOBILE, USB_PRODUCT_TCTMOBILE_UMSM }, 0},

+	{{ USB_VENDOR_TOSHIBA, USB_PRODUCT_TOSHIBA_HSDPA_MINICARD }, 0},
+
 	{{ USB_VENDOR_HP, USB_PRODUCT_HP_HS2300 }, 0},

 	{{ USB_VENDOR_CMOTECH, USB_PRODUCT_CMOTECH_CNU510 }, 0}, /* ??? */
Index: usbdevs
===================================================================
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.539
diff -u -p -r1.539 usbdevs
--- usbdevs	30 Jan 2011 17:28:05 -0000	1.539
(Continue reading)


Gmane