Update floppy58 and miniroot58 to *59.fs in www/
... to bring in line with sparc64.html (Didn't update vax.html as it's been discontinued) Thanks Tom Index: www/alpha.html === RCS file: /home/OpenBSD/cvs/www/alpha.html,v retrieving revision 1.276 diff -u -p -u -r1.276 alpha.html --- www/alpha.html 8 Apr 2016 01:58:04 - 1.276 +++ www/alpha.html 8 Jun 2016 21:06:37 - @@ -242,7 +242,7 @@ There are several installation media pro look at the http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/alpha/conf/RAMDISKBIG?rev=HEAD";>RAMDISKBIG kernel configuration file. - Floppy A (floppy58.fs) + Floppy A (floppy59.fs) This 1.44MB floppy image supports the following alpha hardware: @@ -262,7 +262,7 @@ There are several installation media pro look at the http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/alpha/conf/RAMDISK?rev=HEAD";>RAMDISK kernel configuration file. - Floppy B (floppyB58.fs) + Floppy B (floppyB59.fs) This 1.44MB floppy image supports the following alpha hardware: Index: www/amd64.html === RCS file: /home/OpenBSD/cvs/www/amd64.html,v retrieving revision 1.262 diff -u -p -u -r1.262 amd64.html --- www/amd64.html 8 Apr 2016 01:58:04 - 1.262 +++ www/amd64.html 8 Jun 2016 21:07:00 - @@ -109,11 +109,11 @@ There are several installation media pro For the latest list of drivers available on this image, take a look at the http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64/conf/RAMDISK_CD?rev=HEAD";>RAMDISK_CD kernel configuration file. - Disk Image (miniroot58.fs) + Disk Image (miniroot59.fs) The same installer as the CD, but in a form suitable for creating bootable hard drives or USB flash drives. - Floppy A (floppy58.fs) + Floppy A (floppy59.fs) This 1.44MB floppy image contains the most common drivers. It is designed to cover the most typical PC. As a general rule, you will Index: www/i386.html === RCS file: /home/OpenBSD/cvs/www/i386.html,v retrieving revision 1.740 diff -u -p -u -r1.740 i386.html --- www/i386.html 8 Apr 2016 01:58:04 - 1.740 +++ www/i386.html 8 Jun 2016 21:07:04 - @@ -136,11 +136,11 @@ There are several installation media pro For the latest list of drivers available on this image, take a look at the http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/conf/RAMDISK_CD?rev=HEAD";>RAMDISK_CD kernel configuration file. - Disk Image (miniroot58.fs) + Disk Image (miniroot59.fs) The same installer as the CD, but in a form suitable for creating bootable hard drives or USB flash drives. - Floppy (floppy58.fs) + Floppy (floppy59.fs) This 1.44MB floppy image contains the most common drivers. It is designed to cover the most typical PC. As a general rule, you will Index: www/sparc.html === RCS file: /home/OpenBSD/cvs/www/sparc.html,v retrieving revision 1.226 diff -u -p -u -r1.226 sparc.html --- www/sparc.html 8 Apr 2016 01:58:04 - 1.226 +++ www/sparc.html 8 Jun 2016 21:07:19 - @@ -535,7 +535,7 @@ kernel configuration file. boot cdrom 5.7/sparc/bsd.rd - Floppy (floppy58.fs) + Floppy (floppy59.fs) Booting off the floppy provides a small ffs filesystem with a kernel containing drivers for the most popular devices found on SPARC machines. @@ -547,7 +547,7 @@ kernel configuration file. boot floppy - Miniroot (miniroot58.fs) + Miniroot (miniroot59.fs) The miniroot provides the same installation environment as the bootable CD, and is intended for easy bootstrap if there is already an operating system
Spelling correction for www/armv7.html
Thanks Tom Index: www/armv7.html === RCS file: /home/OpenBSD/cvs/www/armv7.html,v retrieving revision 1.26 diff -u -p -u -r1.26 armv7.html --- www/armv7.html 29 May 2016 14:44:33 - 1.26 +++ www/armv7.html 9 Jun 2016 08:14:00 - @@ -62,8 +62,8 @@ bundles various platforms sharing the AR fact that there are many System on a Chips (SoC) around, OpenBSD/armv7 differentiates between various SoCs and may have a different level of support between them. All devices based on the -i.MX6 are refered to as imx, all devices based on A1x/A20 are -refered to as sunxi. The boards with an OMAP 3/4 SoC are +i.MX6 are referred to as imx, all devices based on A1x/A20 are +referred to as sunxi. The boards with an OMAP 3/4 SoC are subdivided into am335x (for BeagleBone), beagle (for BeagleBoard) and panda (for PandaBoard).
Re: Update floppy58 and miniroot58 to *59.fs in www/
On Wed, Jun 08, 2016 at 09:15:29PM +0100, Tom Cosgrove wrote: > ... to bring in line with sparc64.html fixed, thanks!
Re: Spelling correction for www/armv7.html
fixed, thanks.
Re: pool related crashes, but "kernel did no panic"
On Tue, May 31, 2016 at 7:16 PM, Theo de Raadt wrote: >> is exactly 80 characters long (such a long printf violates "80 chars" >> rule, isn't it?). > > there is no hard and fast rule for that at all; printing extra newlines > has other downsides such as the screen scrolling sooner. Hi. I finally have a trace with pfsync related panic. See here http://article.gmane.org/gmane.os.openbsd.bugs/23666
misc arm kernel output wonder
Hi,
is the toolchain somehow excessively naive only on arm, or is the output like
this to be expected, and what other archs are also running with?
I'm pointing at the bhi looping back to "mov r3, #0" instead of straight to
"str r3, [r1]" as ridiculous by the compiler even if no additional flags given,
any chance to improve here?
example:
/*
* Called from armv7_boot.S during boot,
* this was the first C code that's run,
* now we have _bootstrap_early() before us,
* and this is where we jump to main() from.
*/
__dead void
armv7_bootstrap(struct armv7_bootinfo *bi)
{
/* zero .bss */
while (bi->_bss < bi->__ebss)
*bi->_bss++ = 0;
cpu_drain_writebuf();
c023c8c0 :
c023c8c0: e1a0c00dmov ip, sp
c023c8c4: e1a09000mov r9, r0
c023c8c8: e92dd800stmdb sp!, {fp, ip, lr, pc}
c023c8cc: e24cb004sub fp, ip, #4 ; 0x4
c023c8d0: e24dd030sub sp, sp, #48 ; 0x30
c023c8d4: e590104cldr r1, [r0, #76]
c023c8d8: e5903050ldr r3, [r0, #80]
c023c8dc: e1530001cmp r3, r1
c023c8e0: 9a05bls c023c8fc
c023c8e4: e3a03000mov r3, #0 ; 0x0
c023c8e8: e4813004str r3, [r1], #4
c023c8ec: e5992050ldr r2, [r9, #80]
c023c8f0: e589104cstr r1, [r9, #76]
c023c8f4: e1520001cmp r2, r1
c023c8f8: 8af9bhi c023c8e4
c023c8fc: f57ff04fdsb sy
c023c900: f57ff06fisb sy
-Artturi
Re: MBIM Patch (Round 3)
On 2016/06/08 15:08, Gerhard Roth wrote: > I would be glad to hear from some people trying this with a real MBIM > device. So I have a Dell-branded Sierra MC8805, but I don't seem able to get it to recognise my SIM card (which I can see from my Huawei umsm). # ifconfig umb0 pin apn x # ifconfig umb0 umb0: flags=8810 mtu 1500 index 19 priority 0 roaming disabled registration unknown state down cell-class none SIM not initialized PIN required APN x status: down Any suggestions of where I can poke? Jun 9 15:22:31 zoo apmd: system resumed from sleep Jun 9 15:22:31 zoo /bsd: uvideo0 at uhub4 port 5 configuration 1 interface 0 "Sonix Technology Co., Ltd. USB 2.0 Camera" rev 2.00/1.00 addr 2 Jun 9 15:22:31 zoo /bsd: video0 at uvideo0 Jun 9 15:22:32 zoo /bsd: usbd_fill_iface_data: bad max packet size Jun 9 15:22:32 zoo /bsd: usbd_fill_iface_data: bad max packet size Jun 9 15:22:32 zoo /bsd: ugen0 at uhub4 port 6 "Sierra Wireless, Incorporated Dell Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card" rev 2.00/0.00 addr 3 Jun 9 15:22:32 zoo /bsd: ugen0: setting configuration index 0 failed Jun 9 15:22:32 zoo /bsd: ugen0 detached Jun 9 15:22:43 zoo /bsd: umb0 at uhub4 port 6 configuration 2 interface 12 "Sierra Wireless, Incorporated Dell Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card" rev 2.00/0.06 addr 3 Jun 9 15:22:43 zoo /bsd: umb0: ctrl_len=4096, maxpktlen=4064, cap=0x20 Jun 9 15:22:43 zoo /bsd: umb0: ctrl-ifno#12: ep-ctrl=2, data-ifno#13: ep-rx=1, ep-tx=1 Jun 9 15:22:43 zoo /bsd: umb0: -> snd MBIM_OPEN_MSG (tid 1) Jun 9 15:22:43 zoo /bsd: umb0: sent MBIM_OPEN_MSG (tid 1) Jun 9 15:22:43 zoo /bsd:0: 01 00 00 00 10 00 00 00 01 00 00 00 00 10 00 00 Jun 9 15:22:43 zoo /bsd: umb0: vers 1.0 Jun 9 15:22:44 zoo /bsd: umb0: notification error: IOERROR Jun 9 15:22:51 zoo last message repeated 305 times Jun 9 15:22:51 zoo /bsd: umb0: notification error: CANCELLED Jun 9 15:22:51 zoo /bsd: umb0 detached Jun 9 15:23:02 zoo /bsd: umb0 at uhub4 port 6 configuration 2 interface 12 "Sierra Wireless, Incorporated Dell Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card" rev 2.00/0.06 addr 3 Jun 9 15:23:02 zoo /bsd: umb0: ctrl_len=4096, maxpktlen=4064, cap=0x20 Jun 9 15:23:02 zoo /bsd: umb0: ctrl-ifno#12: ep-ctrl=2, data-ifno#13: ep-rx=1, ep-tx=1 Jun 9 15:23:02 zoo /bsd: umb0: -> snd MBIM_OPEN_MSG (tid 1) Jun 9 15:23:02 zoo /bsd: umb0: sent MBIM_OPEN_MSG (tid 1) Jun 9 15:23:02 zoo /bsd:0: 01 00 00 00 10 00 00 00 01 00 00 00 00 10 00 00 Jun 9 15:23:02 zoo /bsd: umb0: vers 1.0 Jun 9 15:24:06 zoo /bsd: umb0: -> set MBIM_CID_PIN (tid 2) Jun 9 15:24:06 zoo /bsd: umb0: sent MBIM_COMMAND_MSG (tid 2) Jun 9 15:24:06 zoo /bsd:0: 03 00 00 00 50 00 00 00 02 00 00 00 01 00 00 00 Jun 9 15:24:06 zoo /bsd: 16: 00 00 00 00 a2 89 cc 33 bc bb 8b 4f b6 b0 13 3e Jun 9 15:24:06 zoo /bsd: 32: c2 aa e6 df 04 00 00 00 01 00 00 00 20 00 00 00 Jun 9 15:24:06 zoo /bsd: 48: 02 00 00 00 00 00 00 00 18 00 00 00 08 00 00 00 Jun 9 15:24:06 zoo /bsd: 64: 00 00 00 00 00 00 00 00 30 00 30 00 30 00 30 00
Re: MBIM Patch (Round 3)
On 2016/06/09 15:29, Stuart Henderson wrote: > On 2016/06/08 15:08, Gerhard Roth wrote: > > I would be glad to hear from some people trying this with a real MBIM > > device. > > So I have a Dell-branded Sierra MC8805, but I don't seem able to > get it to recognise my SIM card (which I can see from my Huawei > umsm). aha, it needs a command (and same for some HP-branded ones)... https://sigquit.wordpress.com/2015/02/
Re: MBIM Patch (Round 3)
On Thu, 9 Jun 2016 15:29:34 +0100 Stuart Henderson wrote: > On 2016/06/08 15:08, Gerhard Roth wrote: > > I would be glad to hear from some people trying this with a real MBIM > > device. > > So I have a Dell-branded Sierra MC8805, but I don't seem able to > get it to recognise my SIM card (which I can see from my Huawei > umsm). You're not even getting anywhere near SIM card information. See below. > > # ifconfig umb0 pin apn x > # ifconfig umb0 > umb0: flags=8810 mtu 1500 > index 19 priority 0 > roaming disabled registration unknown > state down cell-class none > SIM not initialized PIN required > APN x > status: down > > Any suggestions of where I can poke? > > Jun 9 15:22:31 zoo apmd: system resumed from sleep > Jun 9 15:22:31 zoo /bsd: uvideo0 at uhub4 port 5 configuration 1 interface 0 > "Sonix Technology Co., Ltd. USB 2.0 Camera" rev 2.00/1.00 addr 2 > Jun 9 15:22:31 zoo /bsd: video0 at uvideo0 > Jun 9 15:22:32 zoo /bsd: usbd_fill_iface_data: bad max packet size > Jun 9 15:22:32 zoo /bsd: usbd_fill_iface_data: bad max packet size > Jun 9 15:22:32 zoo /bsd: ugen0 at uhub4 port 6 "Sierra Wireless, > Incorporated Dell Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card" rev > 2.00/0.00 addr 3 > Jun 9 15:22:32 zoo /bsd: ugen0: setting configuration index 0 failed > Jun 9 15:22:32 zoo /bsd: ugen0 detached > Jun 9 15:22:43 zoo /bsd: umb0 at uhub4 port 6 configuration 2 interface 12 > "Sierra Wireless, Incorporated Dell Wireless 5570 HSPA+ (42Mbps) Mobile > Broadband Card" rev 2.00/0.06 addr 3 > Jun 9 15:22:43 zoo /bsd: umb0: ctrl_len=4096, maxpktlen=4064, cap=0x20 > Jun 9 15:22:43 zoo /bsd: umb0: ctrl-ifno#12: ep-ctrl=2, data-ifno#13: > ep-rx=1, ep-tx=1 > Jun 9 15:22:43 zoo /bsd: umb0: -> snd MBIM_OPEN_MSG (tid 1) > Jun 9 15:22:43 zoo /bsd: umb0: sent MBIM_OPEN_MSG (tid 1) > Jun 9 15:22:43 zoo /bsd:0: 01 00 00 00 10 00 00 00 01 00 00 00 00 10 > 00 00 > Jun 9 15:22:43 zoo /bsd: umb0: vers 1.0 This is the first MBIM message sent the the device. > Jun 9 15:22:44 zoo /bsd: umb0: notification error: IOERROR > Jun 9 15:22:51 zoo last message repeated 305 times Normally, the device would reply with a MBIM_OPEN_DONE message on the control pipe. And it should inform us that this reply is ready for fetching by a UCDC_N_RESPONSE_AVAILABLE message on the interrupt pipe. Apparently it tries to send something on the interrupt pipe, but we fail to receive it (306 IOERRORs within 7 seconds). I have no idea what makes the interrupt pipe fail. > Jun 9 15:22:51 zoo /bsd: umb0: notification error: CANCELLED > Jun 9 15:22:51 zoo /bsd: umb0 detached > Jun 9 15:23:02 zoo /bsd: umb0 at uhub4 port 6 configuration 2 interface 12 > "Sierra Wireless, Incorporated Dell Wireless 5570 HSPA+ (42Mbps) Mobile > Broadband Card" rev 2.00/0.06 addr 3 > Jun 9 15:23:02 zoo /bsd: umb0: ctrl_len=4096, maxpktlen=4064, cap=0x20 > Jun 9 15:23:02 zoo /bsd: umb0: ctrl-ifno#12: ep-ctrl=2, data-ifno#13: > ep-rx=1, ep-tx=1 > Jun 9 15:23:02 zoo /bsd: umb0: -> snd MBIM_OPEN_MSG (tid 1) > Jun 9 15:23:02 zoo /bsd: umb0: sent MBIM_OPEN_MSG (tid 1) > Jun 9 15:23:02 zoo /bsd:0: 01 00 00 00 10 00 00 00 01 00 00 00 00 10 > 00 00 > Jun 9 15:23:02 zoo /bsd: umb0: vers 1.0 > Jun 9 15:24:06 zoo /bsd: umb0: -> set MBIM_CID_PIN (tid 2) > Jun 9 15:24:06 zoo /bsd: umb0: sent MBIM_COMMAND_MSG (tid 2) > Jun 9 15:24:06 zoo /bsd:0: 03 00 00 00 50 00 00 00 02 00 00 00 01 00 > 00 00 > Jun 9 15:24:06 zoo /bsd: 16: 00 00 00 00 a2 89 cc 33 bc bb 8b 4f b6 b0 > 13 3e > Jun 9 15:24:06 zoo /bsd: 32: c2 aa e6 df 04 00 00 00 01 00 00 00 20 00 > 00 00 > Jun 9 15:24:06 zoo /bsd: 48: 02 00 00 00 00 00 00 00 18 00 00 00 08 00 > 00 00 > Jun 9 15:24:06 zoo /bsd: 64: 00 00 00 00 00 00 00 00 30 00 30 00 30 00 > 30 00
Re: MBIM Patch (Round 3)
On Thu, 9 Jun 2016 16:19:14 +0100 Stuart Henderson wrote:
> On 2016/06/09 15:29, Stuart Henderson wrote:
> > On 2016/06/08 15:08, Gerhard Roth wrote:
> > > I would be glad to hear from some people trying this with a real MBIM
> > > device.
> >
> > So I have a Dell-branded Sierra MC8805, but I don't seem able to
> > get it to recognise my SIM card (which I can see from my Huawei
> > umsm).
>
> aha, it needs a command (and same for some HP-branded ones)...
> https://sigquit.wordpress.com/2015/02/
Hmm, so you need somthing similar to umb_cmd() where you have to
use UUID d1a30bc2-f97a-6e43-bf65-c7e24fb0f0d3 instead of
'umb_uuid_basic_connect'. It is clear that 'op' is MBIM_CMDOP_SET.
But what value to use for 'cid' (command-id)? Somewhere it says '1',
but '1' is MBIM_CID_DEVICE_CAPS. Well, could be anyway.
And what's inside the payload ('data', 'len')? I'm not sure.
Re: MBIM Patch (Round 3)
On 2016/06/09 16:19, Stuart Henderson wrote: > On 2016/06/09 15:29, Stuart Henderson wrote: > > On 2016/06/08 15:08, Gerhard Roth wrote: > > > I would be glad to hear from some people trying this with a real MBIM > > > device. > > > > So I have a Dell-branded Sierra MC8805, but I don't seem able to > > get it to recognise my SIM card (which I can see from my Huawei > > umsm). > > aha, it needs a command (and same for some HP-branded ones)... > https://sigquit.wordpress.com/2015/02/ > By the way, for anyone interested, on the APU2 it's the middle mPCIe connector (mPCIe 2, J13) that the SIM holder is routed to.
Re: MBIM Patch (Round 3)
On Thu, 9 Jun 2016 17:37:54 +0200 Gerhard Roth wrote:
> On Thu, 9 Jun 2016 16:19:14 +0100 Stuart Henderson
> wrote:
> > On 2016/06/09 15:29, Stuart Henderson wrote:
> > > On 2016/06/08 15:08, Gerhard Roth wrote:
> > > > I would be glad to hear from some people trying this with a real MBIM
> > > > device.
> > >
> > > So I have a Dell-branded Sierra MC8805, but I don't seem able to
> > > get it to recognise my SIM card (which I can see from my Huawei
> > > umsm).
> >
> > aha, it needs a command (and same for some HP-branded ones)...
> > https://sigquit.wordpress.com/2015/02/
>
> Hmm, so you need somthing similar to umb_cmd() where you have to
> use UUID d1a30bc2-f97a-6e43-bf65-c7e24fb0f0d3 instead of
> 'umb_uuid_basic_connect'. It is clear that 'op' is MBIM_CMDOP_SET.
>
> But what value to use for 'cid' (command-id)? Somewhere it says '1',
> but '1' is MBIM_CID_DEVICE_CAPS. Well, could be anyway.
>
> And what's inside the payload ('data', 'len')? I'm not sure.
Decoding the bytes from
https://lists.freedesktop.org/archives/libmbim-devel/2015-August/000626.html
03 00 00 00 3D 00 00 00 07 00 00 00 01 00 00 00 00 00 00 00 D1 A3 0B C2
^type ^len^tid^nfrag ^currfrag ^UUID
F9 7A 6E 43 BF 65 C7 E2 4F B0 F0 D3 01 00 00 00 01 00 00 00 0D 00 00 00
^cid^op == SET ^infolen
01 0C 00 00 02 14 00 01 00 5F 55 00 00
^info
So:
- CID is in fact 1
- payload is { 0x01, 0x0c, 0x00, 0x00, 0x02, 0x14, 0x00, 0x01, 0x00, 0x5f,
0x55, 0x00, 0x00 }
But: this payload is only 13 bytes but the length field says 14 bytes (0x0d).
So maybe the guy missed to paste the last byte of the payload. Appending
another null byte would be a good start :)
Re: MBIM Patch (Round 3)
Hi Gerhard, Gerhard Roth wrote on Wed, Jun 08, 2016 at 03:08:52PM +0200: > +.\" Copyright (c) 2016 genua mbH > + * Copyright (c) 2016 genua mbH These kinds of Copyright notices without the name of the actual author are misleading. The purpose of a Copyright notice is to inform the reader who enjoys rights with respect to the Works; while they are not legally required to establish Copyright and purely of advisory nature, it is hard in practice, often almost impossible, to find out who holds rights without them. So putting incorrect or incomplete information in Copyright notices defeats the very purpose of these notices. Please never do that. According to international law, specifically Article 6bis of the Berne Convention (1886, last amended 1979), even when transferring all the economic rights, the original author of a Works always retains the Moral Rights, including the following: "Independently of the author's economic rights, and even after the transfer of the said rights, the author shall have the right to claim authorship of the work and to object to any distortion, mutilation or other modification of, or other derogatory action in relation to, the said work, which would be prejudicial to his honor or reputation." So not naming the author in the Copyright notice effectively subverts the author's most fundamental inalienable right: Being known as the author - without which the other moral rights against derogatory action etc. lose most of their power. At the very least, the name of the author must be included, for example as follows: Copyright (c) 2016 genua mbH This software was written by Gerhard Roth. But actually, company names on ISC software licences are silly. The ISC license is specifically designed to grant all rights under Copyright that can legally be granted except one: To relicense. But relicensing never has any effect since that ISC license already grants all rights; relicensing under a different license could only grant less rights, which would have no legal effect but might confuse people unaware of the original grant of the ISC license. The ISC license only explicitly reserves one right: To be known as the author. And that cannot ever be given away (see Article 6bis above). So technically, if genua mbH insists on "(C) genua mbH", what they are actually saying is this: "Look, in the future, we might wish to decide to attempt to deceive people into believing that this software is less free than it actually is, so we reserve the right to relicense under a less free license; or we mistrust the author and fear that he himself might attempt this deception, so we legally bar the author from re-releasing his own code." In my book, both would make them look somewhat silly. So please get their OK for: Copyright (c) 2016 Gerhard Roth. If they want acknowledgement for supporting the development, which would only be fair if they did support it, that acknowledgement does not belong inside, but after the license, for example: * Copyright (c) 2016 Gerhard Roth. * * Permission to use, copy, modify, and distribute this software for any * [...] * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. * * Development of this software was supported by genua mbH. Of course, if you have a working contract with them, they may be allowed to insist on the silly line "Copyright (c) 2016 genua mbH" if they want to. But even if they try to forbid you from adding This software was written by Gerhard Roth. they cannot prevent that. Even if your working contract would say that you transfer all your rights including the Moral Rights, that part of it would be null and void. Note that the form you used might be considered legal in the U.S. because the U.S. still doesn't fully implement the Berne Convention, after all those 130 years. Last time i checked, the U.S. still allowed companies to strip authors of rights that are inalienable by international law. But in most other countries, in particular those that respect international law, and specifically in Germany, your version of the Copyright notice seriously misrepresents the legal situation. And none of my proposed versions is illegal in the U.S., by the way. Yours, Ingo
Re: MBIM Patch (Round 3)
On Thu, 09 Jun 2016 at 19:04:27 +0200, Ingo Schwarze wrote: > Hi Gerhard, > > Gerhard Roth wrote on Wed, Jun 08, 2016 at 03:08:52PM +0200: > > > +.\" Copyright (c) 2016 genua mbH > > + * Copyright (c) 2016 genua mbH > > These kinds of Copyright notices without the name of the actual author > are misleading. The purpose of a Copyright notice is to inform the > reader who enjoys rights with respect to the Works; while they are > not legally required to establish Copyright and purely of advisory > nature, it is hard in practice, often almost impossible, to find out > who holds rights without them. So putting incorrect or incomplete > information in Copyright notices defeats the very purpose of these > notices. Please never do that. Can we stop all this bullshit bikeshedding and just get this driver imported? This is getting so ridiculous. I'm amazed Gerhard has stuck with it this long. There is tons of code in our tree that has a copyright line of a corporate entity. "The NetBSD Foundation, Inc.", "Carnegie-Mellon University", etc. Your argument makes no sense and you are in no position to tell Gerhard to force him to go get the code re-licensed (which makes no sense anyway, as he probably wrote it on company time).
Re: MBIM Patch (Round 3)
On Thu, Jun 09, 2016 at 12:21:26PM -0500, joshua stein wrote: > On Thu, 09 Jun 2016 at 19:04:27 +0200, Ingo Schwarze wrote: > > Hi Gerhard, > > > > Gerhard Roth wrote on Wed, Jun 08, 2016 at 03:08:52PM +0200: > > > > > +.\" Copyright (c) 2016 genua mbH > > > + * Copyright (c) 2016 genua mbH > > > > These kinds of Copyright notices without the name of the actual author > > are misleading. The purpose of a Copyright notice is to inform the > > reader who enjoys rights with respect to the Works; while they are > > not legally required to establish Copyright and purely of advisory > > nature, it is hard in practice, often almost impossible, to find out > > who holds rights without them. So putting incorrect or incomplete > > information in Copyright notices defeats the very purpose of these > > notices. Please never do that. > > Can we stop all this bullshit bikeshedding and just get this driver > imported? This is getting so ridiculous. I'm amazed Gerhard has > stuck with it this long. > > There is tons of code in our tree that has a copyright line of a > corporate entity. "The NetBSD Foundation, Inc.", "Carnegie-Mellon > University", etc. Your argument makes no sense and you are in no > position to tell Gerhard to force him to go get the code re-licensed > (which makes no sense anyway, as he probably wrote it on company > time). One of the best e-mails i've seen recently on this thread ... I think some initial code shaping is fine before importing, but i also see no point to rewrite the whole driver in a mailing list.
Re: MBIM Patch (Round 3)
On 09.06.2016 17:52, Gerhard Roth wrote: But: this payload is only 13 bytes but the length field says 14 bytes (0x0d). Studid me. Can't even read single digit hex values anymore :(
Re: MBIM Patch (Round 3)
On 09.06.2016 19:04, Ingo Schwarze wrote: Hi Gerhard, Gerhard Roth wrote on Wed, Jun 08, 2016 at 03:08:52PM +0200: +.\" Copyright (c) 2016 genua mbH + * Copyright (c) 2016 genua mbH These kinds of Copyright notices without the name of the actual author are misleading. The purpose of a Copyright notice is to inform the reader who enjoys rights with respect to the Works; while they are not legally required to establish Copyright and purely of advisory nature, it is hard in practice, often almost impossible, to find out who holds rights without them. So putting incorrect or incomplete information in Copyright notices defeats the very purpose of these notices. Please never do that. According to international law, specifically Article 6bis of the Berne Convention (1886, last amended 1979), even when transferring all the economic rights, the original author of a Works always retains the Moral Rights, including the following: "Independently of the author's economic rights, and even after the transfer of the said rights, the author shall have the right to claim authorship of the work and to object to any distortion, mutilation or other modification of, or other derogatory action in relation to, the said work, which would be prejudicial to his honor or reputation." So not naming the author in the Copyright notice effectively subverts the author's most fundamental inalienable right: Being known as the author - without which the other moral rights against derogatory action etc. lose most of their power. At the very least, the name of the author must be included, for example as follows: Copyright (c) 2016 genua mbH This software was written by Gerhard Roth. But actually, company names on ISC software licences are silly. The ISC license is specifically designed to grant all rights under Copyright that can legally be granted except one: To relicense. But relicensing never has any effect since that ISC license already grants all rights; relicensing under a different license could only grant less rights, which would have no legal effect but might confuse people unaware of the original grant of the ISC license. The ISC license only explicitly reserves one right: To be known as the author. And that cannot ever be given away (see Article 6bis above). So technically, if genua mbH insists on "(C) genua mbH", what they are actually saying is this: "Look, in the future, we might wish to decide to attempt to deceive people into believing that this software is less free than it actually is, so we reserve the right to relicense under a less free license; or we mistrust the author and fear that he himself might attempt this deception, so we legally bar the author from re-releasing his own code." In my book, both would make them look somewhat silly. So please get their OK for: Copyright (c) 2016 Gerhard Roth. If they want acknowledgement for supporting the development, which would only be fair if they did support it, that acknowledgement does not belong inside, but after the license, for example: * Copyright (c) 2016 Gerhard Roth. * * Permission to use, copy, modify, and distribute this software for any * [...] * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. * * Development of this software was supported by genua mbH. Of course, if you have a working contract with them, they may be allowed to insist on the silly line "Copyright (c) 2016 genua mbH" if they want to. But even if they try to forbid you from adding This software was written by Gerhard Roth. they cannot prevent that. Even if your working contract would say that you transfer all your rights including the Moral Rights, that part of it would be null and void. Note that the form you used might be considered legal in the U.S. because the U.S. still doesn't fully implement the Berne Convention, after all those 130 years. Last time i checked, the U.S. still allowed companies to strip authors of rights that are inalienable by international law. But in most other countries, in particular those that respect international law, and specifically in Germany, your version of the Copyright notice seriously misrepresents the legal situation. And none of my proposed versions is illegal in the U.S., by the way. Yours, Ingo Please don't tell me how to licence the code. As you are not the author and as you don't have any rights on it, this is none of your business. Either OpenBSD accepts it this way or it rejects it. But the copyright notice won't change. EOT
Re: MBIM Patch (Round 3)
Hi Joshua, joshua stein wrote on Thu, Jun 09, 2016 at 12:21:26PM -0500: > On Thu, 09 Jun 2016 at 19:04:27 +0200, Ingo Schwarze wrote: >> Gerhard Roth wrote on Wed, Jun 08, 2016 at 03:08:52PM +0200: >>> +.\" Copyright (c) 2016 genua mbH >>> + * Copyright (c) 2016 genua mbH >> These kinds of Copyright notices without the name of the actual author >> are misleading. The purpose of a Copyright notice is to inform the >> reader who enjoys rights with respect to the Works; while they are >> not legally required to establish Copyright and purely of advisory >> nature, it is hard in practice, often almost impossible, to find out >> who holds rights without them. So putting incorrect or incomplete >> information in Copyright notices defeats the very purpose of these >> notices. Please never do that. > Can we stop all this bullshit bikeshedding and just get this driver > imported? Just to be clear: I didn't intend to say that the exact wording of Copyright notices should prevent import (unless the license is unacceptable of course, which is clearly not the case here). Of course, i'm in no position to comment on kernel code. > This is getting so ridiculous. I do not consider making Copyright notices and licences as clear and complete as possible "ridiculous". The finer details are of course not as important as the code itself, but even getting the details right makes things better. It is not all that difficult. With the ISC license, the purpose of the Copyright line is to name the author because he or she retains the Moral Rights. All other (economic) rights are freely licensed to the public. I consider it important that everybody be aware of this one simple idea. It is central to the way OpenBSD attributes and licenses its software. Yes, this fundamental idea is quite different from the way for example NetBSD or the FSF do it. Also note that failing to mention the author in a Copyright notice is not a choice of "how to licence the code", but an omission in a statement of fact. The author is free to choose the license terms (and to transfer economic rights, of course). It is the redistibutor's (the OpenBSD project's) responsibility to make it clear who owns rights on the code it distributes. Sometimes, you only get that out of the CVS logs. Again, that certainly doesn't hinder import, but i consider it somewhat unfortunate when it happens. My remaining answers concern details of less, mostly historical, importance: [...] > There is tons of code in our tree that has a copyright line of a > corporate entity. Sure, but those are mostly historical leftovers, and some also contain slight defects. The most common case is probably this one: * Copyright (c) 1989, 1993 * The Regents of the University of California. All rights reserved. Note that the UCB CSRG had very serious issues in U.S. courts, so they definitely had to focus on U.S. law and were naturally less concerned with the Berne Convention. Besides, even those files usually say something like this: * This code is derived from software contributed to Berkeley by * Kevin Fall. And yet besides, the original BSD licenses (four and even three clauses) were not as free as the ISC license; they put some material conditions on the redistributor, however easy to comply with. * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in the *documentation and/or other materials provided with the distribution. * 3. Neither the name of the University nor the names of its contributors *may be used to endorse or promote products derived from this software *without specific prior written permission. In that case, it does matter slightly who holds the economic rights. For the ISC license, it matters much less. > "The NetBSD Foundation, Inc.", "Carnegie-Mellon University", etc. Both are U.S. legal entities, so maybe they do indeed intend to violate international law and strip authors of inalienable rights. Of course, internationally, that is null and void, and we should add the author names when missing (outside the license, of course). Obviously, it's not a high priority for existing code, but we can at least make new files get it right. > Your argument makes no sense Do you mean to say that owning some ISC-licensed code may provide some benefit to a company? Which one, exactly? > and you are in no position to tell Gerhard to force him Of course i'm not trying to force anything. > to go get the code re-licensed (which makes no sense anyway, as he > probably wrote it on company time). Even when working on company time, the Copyright originates in him. In the working contract, the company may have reserved the right to have the economic rights transferred, but exercising that right makes no sense for code that is intended to be put under an ISC license. No re-licensing is involved here. The question is only whether the co
Re: MBIM Patch (Round 3)
On Wed, Jun 08, 2016 at 03:08:52PM +0200, Gerhard Roth wrote: > I would be glad to hear from some people trying this with a real MBIM > device. I have a Sierra Wireless EM7455 MBIM device that I purchased with my ThinkPad X260. I am very excited for this driver to make it into OpenBSD. I am a little bit unclear as to how to connect to AT&T wireless in the United States thus far but I want to rule out an error in how I am using the driver. Perhaps I have a similar issue to what sthen@ has. I have been watching the driver discussion on the list and applied the most recent complete patch and then did the following sequence: ifconfig umb0 pin 1234 apn broadband ifconfig umb0 inet 0.0.0.1 0.0.0.2 route add -ifp umb0 default 0.0.0.2 ifconfig umb0 up I don't have a PIN set on this SIM card which seems to be needed? I'm not sure if it's different elsewhere but I've never had a SIM card with a PIN set before here. The output of ifconfig umb0: umb0: flags=8811 mtu 1500 index 4 priority 0 roaming disabled registration not registered state open cell-class none SIM not initialized PIN valid (3 attempts left) device EM7455 IMEI 014582000 firmware SWI9X30C_02.08. APN broadband groups: egress status: down inet 0.0.0.1 --> 0.0.0.2 netmask 0xff00 >From the console: umb0: state going up from 'down' to 'open' umb0: PIN2 state locked (3 attempts left) umb0: SIM not initialized (PIN missing) umb0: SIM not initialized (PIN missing) umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE umb0: state change time out umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE umb0: state change time out umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE umb0: state change time out umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE umb0: state change time out umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE umb0: state change time out umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE umb0: state change time out umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE umb0: state change time out umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE I'm not totally clear as to whether I have the right firmware by default. I haven't booted up Windows on this system at all and there is different firmware for some carriers (AT&T, Verizon, Spring) listed from Sierra Wireless for this model. Perhaps I need to try with Verizon and see what happens. I also tried with several other apn values that work in some circumstances (wap.cingular, phone) with identical results. Any ideas? Thank you! Bryan OpenBSD 6.0-beta (GENERIC.MP) #1: Wed Jun 8 08:11:28 PDT 2016 r...@x.example.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17024274432 (16235MB) avail mem = 16503767040 (15739MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xb7c01000 (66 entries) bios0: vendor LENOVO version "R02ET44W (1.17 )" date 01/25/2016 bios0: LENOVO 20F6CTO1WW acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP UEFI SSDT SSDT ECDT HPET APIC MCFG SSDT SSDT DBGP DBG2 BOOT BATB SSDT SSDT MSDM DMAR ASF! FPDT UEFI acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) EXP8(S4) PXSX(S4) XHCI(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz, 1097.89 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 23MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz, 926.72 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PTcpu1: failed to identify ,SENSOR,ARATcpu2 at mainbus0 cpu1: 256KB 64b/line 8-way L2 cache : apid 1 (application processor) cpu1: smt 0, core 1, package 0 cpu2: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz, 897.90 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS
Re: opendev(3) tweak
On Tue, Mar 15, 2016 at 12:32:16PM -0600, Theo de Raadt wrote:
> I am simply saying that pledge before opendev() makes no sense,
> because opendev() does not gaurantee the type of descriptor it is
> opening.
I noticed that this patch is still uncommitted since nobody ok'd it.
Sorry about that. Freshly generated patch below.
ok tb@
$ ktrace fdisk /dev/tty
Abort trap (core dumped)
$ kdump | tail
28663 fdiskCALL open(0x17b1f512f220,0)
28663 fdiskNAMI "/dev/tty"
28663 fdiskRET open 3
28663 fdiskCALL fstat(3,0x7f7f07f0)
28663 fdiskSTRU struct stat { dev=1040, ino=1280, mode=crw-rw-rw- ,
nlink=1, uid=0<"root">, gid=0<"wheel">, rdev=256, atime=1465498384<"Jun 9
20:53:04 2016">.697276353, mtime=1465498384<"Jun 9 20:53:04 2016">.697276353,
ctime=1465498384<"Jun 9 20:53:04 2016">.697276353, size=0, blocks=0,
blksize=65536, flags=0x0, gen=0x0 }
28663 fdiskRET fstat 0
28663 fdiskCALL ioctl(3,DIOCGPDINFO,0x17b1f5135160)
28663 fdiskPLDG ioctl, "ioctl", errno 1 Operation not permitted
28663 fdiskPSIG SIGABRT SIG_DFL code <-538976289>
28663 fdiskNAMI "fdisk.core"
Index: fdisk.c
===
RCS file: /var/cvs/src/sbin/fdisk/fdisk.c,v
retrieving revision 1.100
diff -u -p -r1.100 fdisk.c
--- fdisk.c 28 Mar 2016 16:55:09 - 1.100
+++ fdisk.c 28 Apr 2016 08:05:27 -
@@ -85,10 +85,6 @@ main(int argc, char *argv[])
struct dos_mbr dos_mbr;
struct mbr mbr;
- /* "proc exec" for man page display */
- if (pledge("stdio rpath wpath disklabel proc exec", NULL) == -1)
- err(1, "pledge");
-
while ((ch = getopt(argc, argv, "iegpuvf:c:h:s:l:b:y")) != -1) {
const char *errstr;
@@ -168,6 +164,10 @@ main(int argc, char *argv[])
disk.name = argv[0];
DISK_open(i_flag || u_flag || e_flag);
+
+ /* "proc exec" for man page display */
+ if (pledge("stdio rpath wpath disklabel proc exec", NULL) == -1)
+ err(1, "pledge");
error = MBR_read(0, &dos_mbr);
if (error)
Re: Set prio when bypassing pf(4)
* Mike Belopuhov [2016-06-08 22:49]: > We have discussed this here with henning and benno and think that > this diff should go in. OK mikeb heh, ROP (relayed ok protocol)? :) quite surprised that there is equipment blocking traffic based on prio... pretty broken. but fighting windmills isn't too rewarding, either. re default 3, that is nicely in the middle and otoh i was looking at other implementations and their defaults and that was quite common. afaict most switches with just 4 queues map 0+1 / 2+3 / 4+5 / 6+7. so, indeed, ok. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual & Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: MBIM Patch (Round 3)
On 09.06.2016 21:35, Bryan Vyhmeister wrote: On Wed, Jun 08, 2016 at 03:08:52PM +0200, Gerhard Roth wrote: I would be glad to hear from some people trying this with a real MBIM device. I have a Sierra Wireless EM7455 MBIM device that I purchased with my ThinkPad X260. I am very excited for this driver to make it into OpenBSD. I am a little bit unclear as to how to connect to AT&T wireless in the United States thus far but I want to rule out an error in how I am using the driver. Perhaps I have a similar issue to what sthen@ has. I have been watching the driver discussion on the list and applied the most recent complete patch and then did the following sequence: ifconfig umb0 pin 1234 apn broadband ifconfig umb0 inet 0.0.0.1 0.0.0.2 route add -ifp umb0 default 0.0.0.2 ifconfig umb0 up If you're using the latest version of the driver, the 'ifconfig ubm0 inet ...' isn't required anymore. But you probably have to set the default route after the interface is up. I don't have a PIN set on this SIM card which seems to be needed? I'm not sure if it's different elsewhere but I've never had a SIM card with a PIN set before here. The output of ifconfig umb0: umb0: flags=8811 mtu 1500 index 4 priority 0 roaming disabled registration not registered state open cell-class none SIM not initialized PIN valid (3 attempts left) device EM7455 IMEI 014582000 firmware SWI9X30C_02.08. APN broadband groups: egress status: down inet 0.0.0.1 --> 0.0.0.2 netmask 0xff00 Hmm, around here apart from some special company bulk contracts, almost all SIM cards require PINs. But since yours says "PIN valid" it clearly is content without one. But the "SIM not initialized" is a bit strange. From the console: umb0: state going up from 'down' to 'open' umb0: PIN2 state locked (3 attempts left) umb0: SIM not initialized (PIN missing) umb0: SIM not initialized (PIN missing) umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE umb0: state change time out umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE umb0: state change time out umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE umb0: state change time out umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE umb0: state change time out umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE umb0: state change time out umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE umb0: state change time out umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE umb0: state change time out umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE I'm not totally clear as to whether I have the right firmware by default. I haven't booted up Windows on this system at all and there is different firmware for some carriers (AT&T, Verizon, Spring) listed from Sierra Wireless for this model. Perhaps I need to try with Verizon and see what happens. I also tried with several other apn values that work in some circumstances (wap.cingular, phone) with identical results. Any ideas? Thank you! No, I don't think that you have problems with the correct APN at this stage. The driver is trying to turn on the radio and doesn't get a response on the radio state. Are you sure you haven't turned it off with the rfkill switch? Or maybe this device refuses to accept radio commands and wants to auto-control the radio. You could try this by commenting out the "break" statement in umb_ub() in the UBM_S_RADIO case and see what happens: case UMB_S_RADIO: umb_cmd(sc, MBIM_CID_SUBSCRIBER_READY_STATUS, MBIM_CMDOP_QRY, NULL, 0); // break; case UMB_S_SIMREADY: umb_packet_service(sc, 1); break; This way, it will send a command to turn the radio on, but also continue to send the next command (register packet service) which would otherwise be delayed until the device confirms that the radio is on. If that doesn't help, please set UMB_DEBUG and set umb_debug to 5. Bryan OpenBSD 6.0-beta (GENERIC.MP) #1: Wed Jun 8 08:11:28 PDT 2016 r...@x.example.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17024274432 (16235MB) avail mem = 16503767040 (15739MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xb7c01000 (66 entries) bios0: vendor LENOVO version "R02ET44W (1.17 )" date 01/25/2016 bios0: LENOVO 20F6CTO1WW acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP UEFI SSDT SSDT ECDT HPET APIC MCFG SSDT SSDT DBGP DBG2 BOOT BATB SSDT SSDT MSDM DMAR ASF! FPDT UEFI acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) EXP8(S4) PXSX(S4) XHCI(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz, 1097.89 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,P
Re: MBIM Patch (Round 3)
On 2016/06/09 12:35, Bryan Vyhmeister wrote: > On Wed, Jun 08, 2016 at 03:08:52PM +0200, Gerhard Roth wrote: > > I would be glad to hear from some people trying this with a real MBIM > > device. > > I have a Sierra Wireless EM7455 MBIM device that I purchased with my > ThinkPad X260. I am very excited for this driver to make it into > OpenBSD. I am a little bit unclear as to how to connect to AT&T wireless > in the United States thus far but I want to rule out an error in how I > am using the driver. Perhaps I have a similar issue to what sthen@ has. > I have been watching the driver discussion on the list and applied the > most recent complete patch and then did the following sequence: You're getting further than me. Though, looking at list posts, it does seem that Lenovo is another vendor which requires the command being referred to as "fcc auth" in order to connect, at least in some of their cards. > ifconfig umb0 pin 1234 apn broadband > ifconfig umb0 inet 0.0.0.1 0.0.0.2 > route add -ifp umb0 default 0.0.0.2 > ifconfig umb0 up > > I don't have a PIN set on this SIM card which seems to be needed? I'm > not sure if it's different elsewhere but I've never had a SIM card with > a PIN set before here. The output of ifconfig umb0: > > umb0: flags=8811 mtu 1500 > index 4 priority 0 > roaming disabled registration not registered > state open cell-class none > SIM not initialized PIN valid (3 attempts left) ^ This suggests that you don't need to enter a PIN, otherwise you would get "PIN required" instead of "PIN valid". > device EM7455 IMEI 014582000 firmware SWI9X30C_02.08. > APN broadband > groups: egress > status: down > inet 0.0.0.1 --> 0.0.0.2 netmask 0xff00 > > From the console: > > umb0: state going up from 'down' to 'open' > umb0: PIN2 state locked (3 attempts left) There are several PINs and unlock codes (PIN1 PIN2 PUK1 PUK2) on a SIM card. A SIM can be setup so that a PIN1 is required to make calls etc, or not required. PIN2 is for configuration (setting call restrictions, editing the restricted numbers list, etc). Too many bad attempts to enter a PIN1 will result in the SIM being locked and requiring the PUK1 to unlock. In most cases these are fairly easy to obtain from the operator. Too many bad attempts to enter a PIN2 will result in the SIM being locked and requiring the PUK2 to unlock. These are usually harder to obtain from the operator and at least require more checks. >From a phone or older-type WWAN device with AT command set (or probably the vendor tools on Windows, and maybe libmbim on linux) you can control which PINs the card asks for. You'll need to know what a PIN is before you can lock it. Most operators have a default PIN that they use (different ones for different operators) though theoretically they could use a different one per SIM. If PIN1 is unlocked (no matter whether PIN2 is locked or not), you shouldn't need to use a PIN to connect. > umb0: SIM not initialized (PIN missing) > umb0: SIM not initialized (PIN missing) The description in the spec for the state which triggers this message is, "The operation failed because the device is in the process of initializing. Retry the operation after the ReadyState of the device changes to MBIMSubscriberReadyStateInitialized." Spec may differ from real-world devices, but from my reading of the spec it doesn't seem to me that this indicates "PIN missing". I think you should rebuild with UMB_DEBUG (one simple way is to just add "#define UMB_DEBUG" before #ifdef UMB_DEBUG in if_umb.c) and see if you get more information. It's probably worth changing the 'umb_debug = 0' to 2 or 4 while debugging too (this can be done using DDB, but if you want to capture any possible messages starting at boot then you probably want to chagne it in the code).
Re: MBIM Patch (Round 3)
> Date: Wed, 8 Jun 2016 15:08:52 +0200 > From: Gerhard Roth > > Here comes the next version of the MBIM driver. > > Changes since last version: > > - incorporated suggestions from mpi@ > > - renamed to "umb" > Only file "mbim.h" which contains MBIM protocol related stuff > continues to use "mbim" as prefix. > > - No longer takes fake addresses nor does it try to restore them > > > I would be glad to hear from some people trying this with a real MBIM > device. Sierra Wireless EM7345 4G LTE here. This devices currently attached as umodem(4). But I did add its vendor id and device id to umb_devs, which makes it partially attach: umb0 at uhub0 port 4 "Sierra Wireless Inc. Sierra Wireless EM7345 4G LTE" rev 2.00/17.29 addr 2 umb0: switching to config #1 umb0: ignoring invalid segment size 1500 umb0: ctrl_len=512, maxpktlen=8192, cap=0x4 umb0: no control interface found (this is with UMB_DEBUG enabled) It seems this device needs some additional poking to select alternate interface settings. Currently playing around with that. But in case you're curious, the lsusb -v output for this device is: Bus 000 Device 002: ID 1199:a001 Sierra Wireless, Inc. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize064 idVendor 0x1199 Sierra Wireless, Inc. idProduct 0xa001 bcdDevice 17.29 iManufacturer 1 Sierra Wireless Inc. iProduct2 Sierra Wireless EM7345 4G LTE iSerial 3 013937004372999 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 229 bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 100mA Interface Association: bLength 8 bDescriptorType11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 13 bFunctionProtocol 0 iFunction 4 Sierra Wireless EM7345 4G LTE Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 13 bInterfaceProtocol 0 iInterface 5 Sierra Wireless EM7345 4G LTE (NCM) CDC Header: bcdCDC 1.20 CDC Union: bMasterInterface0 bSlaveInterface 1 CDC NCM: bcdNcmVersion1.00 bmNetworkCapabilities 0x00 CDC Ethernet: iMacAddress 6 11121314 bmEthernetStatistics0x wMaxSegmentSize 2048 wNumberMCFilters0x bNumberPowerFilters 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 4 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 14 bInterfaceProtocol 0 iInterface 7 Sierra Wireless EM7345 4G LTE (MBIM) CDC Header: bcdCDC 1.20 CDC Union: bMasterInterface0 bSlaveInterface 1 CDC MBIM: bcdMBIMVersion 1.00 wMaxControlMessage 512 bNumberFilters 32 bMaxFilterSize 192 wMaxSegmentSize 1500 bmNetworkCapabilities 0x04 UNRECOGNIZED CDC: 08 24 1c 00 01 01 94 05 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 4 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass10 CDC Data bInterfaceSubClass
Re: MBIM Patch (Round 3)
On 2016/06/09 22:59, Mark Kettenis wrote: > It seems this device needs some additional poking to select alternate > interface settings. Currently playing around with that. But in case > you're curious, the lsusb -v output for this device is: Oh lsusb -v, that is a good idea, and interesting. With a kernel containing umb: Bus 001 Device 003: ID 413c:81a3 Dell Computer Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x413c Dell Computer Corp. idProduct 0x81a3 bcdDevice0.06 iManufacturer 1 (error) iProduct2 (error) iSerial 3 (error) bNumConfigurations 2 Device Status: 0x6544 (Bus Powered) Test Mode Debug Mode (By the way I have tried it on a netbook as well as the APU2, and have similar results, though it's a bit fiddly to move it between them so I won't fetch lsusb from there unless requested). It's much longer without: Bus 001 Device 003: ID 413c:81a3 Dell Computer Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x413c Dell Computer Corp. idProduct 0x81a3 bcdDevice0.06 iManufacturer 1 Sierra Wireless, Incorporated iProduct2 Dell Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card iSerial 3 bNumConfigurations 2 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 204 bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber2 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 00 ** UNRECOGNIZED: 04 24 02 02 ** UNRECOGNIZED: 05 24 06 00 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x000c 1x 12 bytes bInterval 32 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber3 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 00 ** UNRECOGNIZED: 04 24 02 02 ** UNRECOGNIZED: 05 24 06 00 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x000c 1x 12 bytes bInterval 32 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDesc
Re: MBIM Patch (Round 3)
> Date: Thu, 9 Jun 2016 22:59:28 +0200 (CEST) > From: Mark Kettenis > > > Date: Wed, 8 Jun 2016 15:08:52 +0200 > > From: Gerhard Roth > > > > I would be glad to hear from some people trying this with a real MBIM > > device. > > Sierra Wireless EM7345 4G LTE here. This devices currently attached > as umodem(4). But I did add its vendor id and device id to umb_devs, > which makes it partially attach: > > umb0 at uhub0 port 4 "Sierra Wireless Inc. Sierra Wireless EM7345 4G LTE" rev > 2.00/17.29 addr 2 > umb0: switching to config #1 > umb0: ignoring invalid segment size 1500 > umb0: ctrl_len=512, maxpktlen=8192, cap=0x4 > umb0: no control interface found > > (this is with UMB_DEBUG enabled) > > It seems this device needs some additional poking to select alternate > interface settings. With the appropriate alternate settings for the communication interface and data interface (1 and 2) hardcoded in the driver, this works! umb0: flags=8851 mtu 1500 index 5 priority 0 roaming disabled registration home network state up cell-class LTE rssi -79dBm speed 47.7Mps up 95.4Mps down SIM initialized PIN valid (3 attempts left) subscriber-id ICC-id YY provider NL KPN device XMM7160_V1.2_MB IMEI Z firmware FIH7160_V1.2_WW APN umts.xs4all.nl groups: egress status: active inet 83.161.163.248 --> 83.161.163.1 netmask 0xff00
Re: MBIM Patch (Round 3)
On 09.06.2016 23:42, Mark Kettenis wrote: Date: Thu, 9 Jun 2016 22:59:28 +0200 (CEST) From: Mark Kettenis Date: Wed, 8 Jun 2016 15:08:52 +0200 From: Gerhard Roth I would be glad to hear from some people trying this with a real MBIM device. Sierra Wireless EM7345 4G LTE here. This devices currently attached as umodem(4). But I did add its vendor id and device id to umb_devs, which makes it partially attach: umb0 at uhub0 port 4 "Sierra Wireless Inc. Sierra Wireless EM7345 4G LTE" rev 2.00/17.29 addr 2 umb0: switching to config #1 umb0: ignoring invalid segment size 1500 umb0: ctrl_len=512, maxpktlen=8192, cap=0x4 umb0: no control interface found (this is with UMB_DEBUG enabled) It seems this device needs some additional poking to select alternate interface settings. With the appropriate alternate settings for the communication interface and data interface (1 and 2) hardcoded in the driver, this works! Great! Although another example of a device violating the MBIM spec which clearly states that alternate settings 0 and 1 have to be used. umb0: flags=8851 mtu 1500 index 5 priority 0 roaming disabled registration home network state up cell-class LTE rssi -79dBm speed 47.7Mps up 95.4Mps down SIM initialized PIN valid (3 attempts left) subscriber-id ICC-id YY provider NL KPN device XMM7160_V1.2_MB IMEI Z firmware FIH7160_V1.2_WW APN umts.xs4all.nl groups: egress status: active inet 83.161.163.248 --> 83.161.163.1 netmask 0xff00
Re: MBIM Patch (Round 3)
> From: Gerhard Roth > Date: Thu, 9 Jun 2016 23:48:23 +0200 > > On 09.06.2016 23:42, Mark Kettenis wrote: > >> Date: Thu, 9 Jun 2016 22:59:28 +0200 (CEST) > >> From: Mark Kettenis > >> > >>> Date: Wed, 8 Jun 2016 15:08:52 +0200 > >>> From: Gerhard Roth > >>> > >>> I would be glad to hear from some people trying this with a real MBIM > >>> device. > >> > >> Sierra Wireless EM7345 4G LTE here. This devices currently attached > >> as umodem(4). But I did add its vendor id and device id to umb_devs, > >> which makes it partially attach: > >> > >> umb0 at uhub0 port 4 "Sierra Wireless Inc. Sierra Wireless EM7345 4G LTE" > >> rev 2.00/17.29 addr 2 > >> umb0: switching to config #1 > >> umb0: ignoring invalid segment size 1500 > >> umb0: ctrl_len=512, maxpktlen=8192, cap=0x4 > >> umb0: no control interface found > >> > >> (this is with UMB_DEBUG enabled) > >> > >> It seems this device needs some additional poking to select alternate > >> interface settings. > > > > With the appropriate alternate settings for the communication > > interface and data interface (1 and 2) hardcoded in the driver, this > > works! > > Great! > > Although another example of a device violating the MBIM spec which > clearly states that alternate settings 0 and 1 have to be used. Which version of the spec are you looking at? Because my copy (Revision 1.0 Errata-1) clearly status alternate settings 1 and 2 have to be used ;). It does violate the spec for the maximumsegment size though.
Re: MBIM Patch (Round 3)
On 2016/06/10 00:10, Mark Kettenis wrote: > > From: Gerhard Roth > > Date: Thu, 9 Jun 2016 23:48:23 +0200 > > > > On 09.06.2016 23:42, Mark Kettenis wrote: > > >> Date: Thu, 9 Jun 2016 22:59:28 +0200 (CEST) > > >> From: Mark Kettenis > > >> > > >>> Date: Wed, 8 Jun 2016 15:08:52 +0200 > > >>> From: Gerhard Roth > > >>> > > >>> I would be glad to hear from some people trying this with a real MBIM > > >>> device. > > >> > > >> Sierra Wireless EM7345 4G LTE here. This devices currently attached > > >> as umodem(4). But I did add its vendor id and device id to umb_devs, > > >> which makes it partially attach: > > >> > > >> umb0 at uhub0 port 4 "Sierra Wireless Inc. Sierra Wireless EM7345 4G > > >> LTE" rev 2.00/17.29 addr 2 > > >> umb0: switching to config #1 > > >> umb0: ignoring invalid segment size 1500 > > >> umb0: ctrl_len=512, maxpktlen=8192, cap=0x4 > > >> umb0: no control interface found > > >> > > >> (this is with UMB_DEBUG enabled) > > >> > > >> It seems this device needs some additional poking to select alternate > > >> interface settings. > > > > > > With the appropriate alternate settings for the communication > > > interface and data interface (1 and 2) hardcoded in the driver, this > > > works! > > > > Great! > > > > Although another example of a device violating the MBIM spec which > > clearly states that alternate settings 0 and 1 have to be used. > > Which version of the spec are you looking at? Because my copy > (Revision 1.0 Errata-1) clearly status alternate settings 1 and 2 have > to be used ;). There are different sections, 3.2 for dual-mode (NCM1.0 / MBIM) devices talks about various alternate settings for NCM1.0 and for MBIM, then 6.6 which is only dealing with MBIM just talks about 0 and 1 ..
Re: MBIM Patch (Round 3)
On 10.06.2016 00:22, Stuart Henderson wrote: On 2016/06/10 00:10, Mark Kettenis wrote: From: Gerhard Roth Date: Thu, 9 Jun 2016 23:48:23 +0200 On 09.06.2016 23:42, Mark Kettenis wrote: Date: Thu, 9 Jun 2016 22:59:28 +0200 (CEST) From: Mark Kettenis Date: Wed, 8 Jun 2016 15:08:52 +0200 From: Gerhard Roth I would be glad to hear from some people trying this with a real MBIM device. Sierra Wireless EM7345 4G LTE here. This devices currently attached as umodem(4). But I did add its vendor id and device id to umb_devs, which makes it partially attach: umb0 at uhub0 port 4 "Sierra Wireless Inc. Sierra Wireless EM7345 4G LTE" rev 2.00/17.29 addr 2 umb0: switching to config #1 umb0: ignoring invalid segment size 1500 umb0: ctrl_len=512, maxpktlen=8192, cap=0x4 umb0: no control interface found (this is with UMB_DEBUG enabled) It seems this device needs some additional poking to select alternate interface settings. With the appropriate alternate settings for the communication interface and data interface (1 and 2) hardcoded in the driver, this works! Great! Although another example of a device violating the MBIM spec which clearly states that alternate settings 0 and 1 have to be used. Which version of the spec are you looking at? Because my copy (Revision 1.0 Errata-1) clearly status alternate settings 1 and 2 have to be used ;). There are different sections, 3.2 for dual-mode (NCM1.0 / MBIM) devices talks about various alternate settings for NCM1.0 and for MBIM, then 6.6 which is only dealing with MBIM just talks about 0 and 1 .. That's how I looked at it, too. But it seems that some vendors look at it differently ;) So we should find a solution where we don't need to use the currently hard-coded MBIM_INTERFACE_ALTSETTING (== 1) anymore.
Re: MBIM Patch (Round 3)
On Thu, Jun 09, 2016 at 09:58:10PM +0100, Stuart Henderson wrote: > You're getting further than me. > > Though, looking at list posts, it does seem that Lenovo is another > vendor which requires the command being referred to as "fcc auth" > in order to connect, at least in some of their cards. That would not be surprising at all. At this point this "fcc auth" would have to be hardcoded into the driver as well it sounds like? > There are several PINs and unlock codes (PIN1 PIN2 PUK1 PUK2) > on a SIM card. A SIM can be setup so that a PIN1 is required to > make calls etc, or not required. PIN2 is for configuration > (setting call restrictions, editing the restricted numbers > list, etc). > > Too many bad attempts to enter a PIN1 will result in the SIM > being locked and requiring the PUK1 to unlock. In most cases > these are fairly easy to obtain from the operator. > > Too many bad attempts to enter a PIN2 will result in the SIM > being locked and requiring the PUK2 to unlock. These are > usually harder to obtain from the operator and at least > require more checks. > > From a phone or older-type WWAN device with AT command set > (or probably the vendor tools on Windows, and maybe libmbim > on linux) you can control which PINs the card asks for. > You'll need to know what a PIN is before you can lock it. > Most operators have a default PIN that they use (different > ones for different operators) though theoretically they > could use a different one per SIM. > > If PIN1 is unlocked (no matter whether PIN2 is locked or not), > you shouldn't need to use a PIN to connect. > > > umb0: SIM not initialized (PIN missing) > > umb0: SIM not initialized (PIN missing) > > The description in the spec for the state which triggers this > message is, > > "The operation failed because the device is > in the process of initializing. Retry the > operation after the ReadyState of the device > changes to MBIMSubscriberReadyStateInitialized." > > Spec may differ from real-world devices, but from my reading > of the spec it doesn't seem to me that this indicates "PIN > missing". > > I think you should rebuild with UMB_DEBUG (one simple way > is to just add "#define UMB_DEBUG" before #ifdef UMB_DEBUG > in if_umb.c) and see if you get more information. It's > probably worth changing the 'umb_debug = 0' to 2 or 4 > while debugging too (this can be done using DDB, but if > you want to capture any possible messages starting at > boot then you probably want to chagne it in the code). Thanks for the explanation on how all the PIN codes work. I wasn't aware it was so complex. I'm compiling a new kernel right now with UMB_DEBUG so we will see what happens there. Bryan
Re: MBIM Patch (Round 3)
On Thu, Jun 09, 2016 at 10:31:58PM +0200, Gerhard Roth wrote: > If you're using the latest version of the driver, the 'ifconfig ubm0 inet > ...' isn't required anymore. > > But you probably have to set the default route after the interface is > up. Good to know. Thanks! > Hmm, around here apart from some special company bulk contracts, > almost all SIM cards require PINs. But since yours says "PIN valid" > it clearly is content without one. But the "SIM not initialized" > is a bit strange. That seemed odd to me as well. > No, I don't think that you have problems with the correct APN at this > stage. The driver is trying to turn on the radio and doesn't get a > response on the radio state. > > Are you sure you haven't turned it off with the rfkill switch? There is no physical switch on the X260 that I'm aware of and the WWAN card is enabled in the BIOS. > Or maybe this device refuses to accept radio commands and wants to > auto-control the radio. You could try this by commenting out the > "break" statement in umb_ub() in the UBM_S_RADIO case and see > what happens: > > case UMB_S_RADIO: > umb_cmd(sc, MBIM_CID_SUBSCRIBER_READY_STATUS, > MBIM_CMDOP_QRY, NULL, 0); > // break; > case UMB_S_SIMREADY: > umb_packet_service(sc, 1); > break; > > This way, it will send a command to turn the radio on, but also > continue to send the next command (register packet service) which > would otherwise be delayed until the device confirms that the radio > is on. I commented out break as above and that made no difference. > If that doesn't help, please set UMB_DEBUG and set umb_debug to 5. I'm compiling a new kernel new with UMB_DEBUG and will provide the output. Bryan
Typo in comment in arm/undefined.c
Thanks Tom Index: sys/arch/arm/arm/undefined.c === RCS file: /home/OpenBSD/cvs/src/sys/arch/arm/arm/undefined.c,v retrieving revision 1.7 diff -u -p -u -r1.7 undefined.c --- sys/arch/arm/arm/undefined.c31 Jan 2016 00:14:50 - 1.7 +++ sys/arch/arm/arm/undefined.c10 Jun 2016 00:15:04 - @@ -192,7 +192,7 @@ undefinedinstruction(trapframe_t *frame) /* * According to the datasheets you only need to look at bit 27 of the -* instruction to tell the difference between and undefined +* instruction to tell the difference between an undefined * instruction and a coprocessor instruction following an undefined * instruction trap. */
Re: MBIM Patch (Round 3)
On Thu, Jun 09, 2016 at 10:31:58PM +0200, Gerhard Roth wrote: > If that doesn't help, please set UMB_DEBUG and set umb_debug to 5. I left that break commented out which perhaps I shouldn't have but below is the output when I set an apn and bring umb0 up. OpenBSD 6.0-beta (GENERIC.MP) #0: Thu Jun 9 16:28:43 PDT 2016 r...@x.brycv.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17024274432 (16235MB) avail mem = 16503758848 (15739MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xb7c01000 (66 entries) bios0: vendor LENOVO version "R02ET44W (1.17 )" date 01/25/2016 bios0: LENOVO 20F6CTO1WW acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP UEFI SSDT SSDT ECDT HPET APIC MCFG SSDT SSDT DBGP DBG2 BOOT BATB SSDT SSDT MSDM DMAR ASF! FPDT UEFI acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) EXP8(S4) PXSX(S4) XHCI(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz, 2485.30 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 23MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz, 2494.16 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz, 2494.16 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz, 2494.16 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG0) acpiprt2 at acpi0: bus -1 (PEG1) acpiprt3 at acpi0: bus -1 (PEG2) acpiprt4 at acpi0: bus 2 (EXP1) acpiprt5 at acpi0: bus 4 (EXP3) acpiprt6 at acpi0: bus -1 (EXP4) acpiprt7 at acpi0: bus -1 (EXP5) acpiprt8 at acpi0: bus -1 (EXP8) acpicpu0 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PUBS, resource for XHCI acpipwrres1 at acpi0: PG00, resource for PEG0 acpipwrres2 at acpi0: PG01, resource for PEG1 acpipwrres3 at acpi0: PG02, resource for PEG2 acpipwrres4 at acpi0: WRST acpipwrres5 at acpi0: WRST acpitz0 at acpi0: critical temperature is 128 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB "LEN0071" at acpi0 not configured "LEN2014" at acpi0 not configured "INT3F0D" at acpi0 not configured acpibat0 at acpi0: BAT0 model "45N1113" serial 4020 type LION oem "LGC" acpibat1 at acpi0: BAT1 model "45N1738" serial 2903 type LION oem "LGC" acp
tetris(6): clear row zero when eliding a row
The tetris playing field has an extra row on top of the visible rows. It is possible and not an error to place a tile in such a way that it occupies a square of this invisible row (the game ends when the next tile starts out on an already occupied square). The problem with this is that there's a bug in the function eliding rows: it never clears the extra row. This means that once a square in the extra row is occupied, it remains occupied. In other words, the column becomes unusable for game play. This is helpful if one of the two columns at the border of the playing field is concerned (you will be able to can clear future rows quicker) and deadly otherwise (you soon won't be able to clear rows anymore). So let's clear that extra row whenever a row is elided. Index: tetris.c === RCS file: /var/cvs/src/games/tetris/tetris.c,v retrieving revision 1.30 diff -u -p -r1.30 tetris.c --- tetris.c7 Mar 2016 12:07:57 - 1.30 +++ tetris.c10 Jun 2016 03:09:10 - @@ -105,6 +105,7 @@ elide(void) tsleep(); while (--base != 0) board[base + B_COLS] = board[base]; + memset(&board[1], 0, B_COLS - 2); scr_update(); tsleep(); break;
Re: Uninitialised variable in sys/arch/armv7/exynos/crosec.c
On Wed, Jun 08, 2016 at 08:51:28PM +0100, Tom Cosgrove wrote: > Hi > > I can't test this :) but it might bite someone who was trying to hack > in this area. > > Thanks > > Tom Thanks, committed. I'm not aware of anyone with a working exynos setup so this can't break anything. > > > Index: sys/arch/armv7/exynos/crosec.c > === > RCS file: /home/OpenBSD/cvs/src/sys/arch/armv7/exynos/crosec.c,v > retrieving revision 1.1 > diff -u -p -u -r1.1 crosec.c > --- sys/arch/armv7/exynos/crosec.c26 Jan 2015 02:48:24 - 1.1 > +++ sys/arch/armv7/exynos/crosec.c8 Jun 2016 19:52:58 - > @@ -222,7 +222,7 @@ cros_ec_command_inptr(struct cros_ec_sof > int ret; > > delay(5); > - cros_ec_send_command(sc, EC_CMD_GET_COMMS_STATUS, 0, > + ret = cros_ec_send_command(sc, EC_CMD_GET_COMMS_STATUS, > 0, > NULL, 0, > (uint8_t **)&resp, sizeof(*resp)); > if (ret < 0) >
