Re: call for testing: MSI for msk(4)
On Tue, Sep 23, 2014 at 01:58:59PM -0400, Brad Smith wrote: > On 31/12/13 12:06 AM, Brad Smith wrote: > >On 16/05/13 5:55 PM, Jérémie Courrèges-Anglas wrote: > >>Hi, > >> > >>I've been using msk(4) with MSI on my laptop since a few days, with no > >>apparent problem. > >> > >>mskc0 at pci2 dev 0 function 0 "Marvell Yukon 88E8040" rev 0x13, > >>Yukon-2 FE+ rev. A0 (0x0): msi > >>msk0 at mskc0 port A: address 00:24:54:xx:xx:xx > >>eephy0 at msk0 phy 0: 88E3016 10/100 PHY, rev. 0 > >> > >>Other systems all seem to use MSI, but it would be cool if people with > >>different chips could test it. > > > >Any other msk(4) users? It has also been tested with EC 8052/EC Ultra > >8058 controllers and working. I don't see any indication of any issues > >or errata regarding MSI operation in either of the FreeBSD or Linux > >drivers. > > Fast Ethernet controller.. > > mskc0 at pci3 dev 0 function 0 "Marvell Yukon 88E8036" rev 0x16, Yukon-2 > FE rev. A1 (0x1): msi > msk0 at mskc0 port A: address 00:13:a9:fa:5a:52 > eephy0 at msk0 phy 0: 88E3082 10/100 PHY, rev. 3 > > Gigabit controllers.. > > mskc0 at pci3 dev 0 function 0 "Marvell Yukon 88E8058" rev 0x13, Yukon-2 EC > Ultra rev. B0 (0x3): msi > msk0 at mskc0 port A: address 00:1b:63:ad:0b:ee > eephy0 at msk0 phy 0: 88E1149 Gigabit PHY, rev. 1 > > mskc0 at pci2 dev 0 function 0 "Marvell Yukon 88E8053" rev 0x20, Yukon-2 EC > rev. A3 (0x2): msi > msk0 at mskc0 port A: address 00:50:43:00:7b:46 > eephy0 at msk0 phy 0: 88E Gigabit PHY, rev. 2 > > mskc0 at pci3 dev 0 function 0 "Marvell Yukon 88E8052" rev 0x21, Yukon-2 > EC rev. A3 (0x2): msi > msk0 at mskc0 port A: address 00:18:f3:6c:44:da > eephy0 at msk0 phy 0: 88E Gigabit PHY, rev. 2 > > > At this point I'd like to see this commited for wider spread testng > and if anything does come up as usual it can be reverted. > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > My card mskc0 at pci1 dev 0 function 0 "Marvell Yukon 88E8053" rev 0x22, Yukon-2 EC rev. A3 (0x2): msi msk0 at mskc0 port A: address 00:19:e3:38:6c:56 eephy0 at msk0 phy 0: 88E Gigabit PHY, rev. 2 doesn't seem to like this change. Whenever I try to fetch a large file with ftp, connectivity is lost after a few moments and I get the following console message: Oct 3 07:04:47 miraculix /bsd: msk0: watchdog timeout Oct 3 07:06:41 miraculix /bsd: msk0: watchdog timeout Oct 3 07:08:36 miraculix /bsd: msk0: watchdog timeout Oct 3 07:20:46 miraculix /bsd: msk0: watchdog timeout Oct 3 07:21:49 miraculix /bsd: msk0: watchdog timeout This message first appeared when I was using a kernel including this change and it doesn't show up when I revert if_msk.c to revision 1.106. Both the GENERIC and GENERIC.MP kernels from the latest snapshot show this behavior. The dmesg of GENERIC is attached, as well as a pcidump. In case this is of importance, I use a trunk failover configuration with msk as master and athn as fallback. # pcidump -v Domain /dev/pci0: 0:0:0: Intel 82945GM Host 0x: Vendor ID: 8086 Product ID: 27a0 0x0004: Command: 0006 Status: 2090 0x0008: Class: 06 Subclass: 00 Interface: 00 Revision: 03 0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00 0x0010: BAR empty () 0x0014: BAR empty () 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 8086 Product ID: 7270 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00 0x00e0: Capability 0x09: Vendor Specific 0:2:0: Intel 82945GM Video 0x: Vendor ID: 8086 Product ID: 27a2 0x0004: Command: 0007 Status: 0090 0x0008: Class: 03 Subclass: 00 Interface: 00 Revision: 03 0x000c: BIST: 00 Header Type: 80 Latency Timer: 00 Cache Line Size: 00 0x0010: BAR mem 32bit addr: 0xb038/0x0008 0x0014: BAR io addr: 0x20e0/0x0008 0x0018: BAR mem prefetchable 32bit addr: 0xa000/0x1000 0x001c: BAR mem 32bit addr: 0xb040/0x0004 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 8086 Product ID: 7270 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 01 Line: 0b Min Gnt: 00 Max Lat: 00 0x0090: Capability 0x05: Message Signaled Interrupts (MSI) 0x00d0: Capability 0x01: Power Management 0:2:1: Intel 82945GM Video 0x: Vendor ID: 8086 Product ID: 27a6 0x0004: Command: 0007 Status: 0090 0x0008: Class: 03 Subclass: 80 Interface: 00 Revision: 03 0x000c: BIST: 00 Header Type: 80 Latency Timer
Re: armv7: banana pi, Allwinner A20 board
On Thu, Oct 02, 2014 at 10:01:59PM +, Alexey Suslikov wrote: > SASANO Takayoshi mx5.nisiq.net> writes: > > > > Try this[1] kernel and have a look if it has the same issue or not. > > > > Kernel did not started... U-Boot says checksum is ok, so maybe > > .umg file is not corrupted. > > When using > > OpenBSD 5.6 (RAMDISK-SUNXI) #3: Sun Aug 31 18:46:49 EDT 2014 > > could you drop into config (pass -c to boot) and try to "disable echi"? ITYM 'disable ehci' there.. Landry
Re: armv7: banana pi, Allwinner A20 board
SASANO Takayoshi mx5.nisiq.net> writes: > > Try this[1] kernel and have a look if it has the same issue or not. > > Kernel did not started... U-Boot says checksum is ok, so maybe > .umg file is not corrupted. When using OpenBSD 5.6 (RAMDISK-SUNXI) #3: Sun Aug 31 18:46:49 EDT 2014 could you drop into config (pass -c to boot) and try to "disable echi"?
Re: armv7: banana pi, Allwinner A20 board
Hi, > Try this[1] kernel and have a look if it has the same issue or not. Kernel did not started... U-Boot says checksum is ok, so maybe .umg file is not corrupted. Regards, -- SASANO Takayoshi U-Boot SPL 2014.04-10694-g2ae8b32-dirty (Oct 01 2014 - 17:40:04) Board: Bananapi DRAM: 1024 MiB CPU: 96000Hz, AXI/AHB/APB: 3/2/2 spl: not an uImage at 1600 U-Boot 2014.04-10694-g2ae8b32-dirty (Oct 01 2014 - 17:40:04) Allwinner Technology CPU: Allwinner A20 (SUN7I) Board: Bananapi I2C: ready DRAM: 1 GiB MMC: SUNXI SD/MMC: 0 *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Net: dwmac.1c5 Hit any key to stop autoboot: 0 reading uEnv.txt 116 bytes read in 16 ms (6.8 KiB/s) Loaded environment from uEnv.txt Running uenvcmd ... reading bsd.umg 9584704 bytes read in 473 ms (19.3 MiB/s) ## Booting kernel from Legacy Image at 6000 ... Image Name: boot Image Type: ARM Linux Kernel Image (uncompressed) Data Size:9584640 Bytes = 9.1 MiB Load Address: 4080 Entry Point: 4080 Verifying Checksum ... OK Loading Kernel Image ... OK Starting kernel ... (halt here)
Re: armv7: banana pi, Allwinner A20 board
iirc this is the core of the issue: The L1 Section descriptors access permissions are still the old ones, not the v7 versions. arm/include/pmap.h: #define L1_S_PROT_U (L1_S_AP(AP_U)) #define L1_S_PROT_W (L1_S_AP(AP_W)) #define L1_S_PROT_MASK (L1_S_PROT_U|L1_S_PROT_W) #define L1_S_PROT(ku, pr) ku) == PTE_USER) ? L1_S_PROT_U : 0) | \ (((pr) & VM_PROT_WRITE) ? L1_S_PROT_W : 0)) arm/include/pte.h: #define L1_S_AP(x) ((x) << 10) /* access permissions */ #define L1_S_V7_AP(x) x) & 0x4) << 13) | (((x) & 3) << 10)) /* AP */ \Patrick > Am 02.10.2014 um 21:16 schrieb Patrick Wildt : > > Hi, > > I remember that there has been an issue, only seen on Cortex-A7/A15, like the > Allwinner A20. > > The fix for that issue is somewhere here[0]. > > Try this[1] kernel and have a look if it has the same issue or not. > > I do not have an A20, so I can’t test it, sorry. But I’ll probably buy > this[2][3] one once it’s available. > > \Patrick > > [0] > https://github.com/bitrig/bitrig/commit/f1932308435a4b2c3daf0e880dc0adc829f5803d > [1] https://www.blueri.se/bitrig/armv7/20140925/bsd.rd.SUNXI.umg > [2] > http://www.allnet.de/at/allnet-brand/produkte/neuheiten/p/banana-pi-router-board/ > [3] http://www.sinovoip.com.cn/ecp_view.asp?id=554 > >> Am 02.10.2014 um 20:56 schrieb SASANO Takayoshi : >> >> Hello, >> >> I tried bsd.rd.SUNXI.umg snapshot on Banana Pi, cheap Allwinner A20 >> board like Raspberry Pi (see http://www.lemaker.org/). >> >> It booted but something wrong. Arch Linux (for Banana Pi) works fine >> so I think the board is not broken. >> >> This is my first OpenBSD/armv7 experience and I don't know what is >> happening. What can I do for solving this problem? >> >> -- >> SASANO Takayoshi >> >> [uEnv.txt] >> mmcboot=mmc rescan; fatload mmc 0 0x6000 bsd.umg && bootm 0x6000; >> bootargs=sd0a:/bsd; >> uenvcmd=run mmcboot; >> >> >> [1st try - hang up] >> U-Boot SPL 2014.04-10694-g2ae8b32-dirty (Oct 01 2014 - 17:40:04) >> Board: Bananapi >> DRAM: 1024 MiB >> CPU: 96000Hz, AXI/AHB/APB: 3/2/2 >> spl: not an uImage at 1600 >> >> >> U-Boot 2014.04-10694-g2ae8b32-dirty (Oct 01 2014 - 17:40:04) Allwinner >> Technology >> >> CPU: Allwinner A20 (SUN7I) >> Board: Bananapi >> I2C: ready >> DRAM: 1 GiB >> MMC: SUNXI SD/MMC: 0 >> *** Warning - bad CRC, using default environment >> >> In:serial >> Out: serial >> Err: serial >> Net: dwmac.1c5 >> Hit any key to stop autoboot: 0 >> reading uEnv.txt >> 116 bytes read in 16 ms (6.8 KiB/s) >> Loaded environment from uEnv.txt >> Running uenvcmd ... >> reading bsd.umg >> 7387788 bytes read in 367 ms (19.2 MiB/s) >> ## Booting kernel from Legacy Image at 6000 ... >> Image Name: boot >> Image Type: ARM Linux Kernel Image (uncompressed) >> Data Size:7387724 Bytes = 7 MiB >> Load Address: 4080 >> Entry Point: 4080 >> Verifying Checksum ... OK >> Loading Kernel Image ... OK >> >> Starting kernel ... >> >> >> OpenBSD/sunxi booting ... >> arg0 0x0 arg1 0x10bb arg2 0x4100 >> atag core flags 0 pagesize 0 rootdev 0 >> atag cmdline [sd0a:/bsd;] >> atag mem start 0x4000 size 0x4000 >> bootfile: sd0a:/bsd; >> bootargs: >> memory size derived from u-boot >> bootconf.mem[0].address = 4000 pages 262144/0x4000 >> Allocating page tables >> freestart = 0x40f0c000, free_pages = 258292 (0x0003f0f4) >> IRQ stack: p0x40f3a000 v0xc0f3a000 >> ABT stack: p0x40f3b000 v0xc0f3b000 >> UND stack: p0x40f3c000 v0xc0f3c000 >> SVC stack: p0x40f3d000 v0xc0f3d000 >> Creating L1 page table at 0x40f0c000 >> Mapping kernel >> Constructing L2 page tables >> undefined page pmap [ using 169296 bytes of bsd ELF symbol table ] >> Copyright (c) 1982, 1986, 1989, 1991, 1993 >> The Regents of the University of California. All rights reserved. >> Copyright (c) 1995-2014 OpenBSD. All rights reserved. http://www.OpenBSD.org >> >> OpenBSD 5.6 (RAMDISK-SUNXI) #3: Sun Aug 31 18:46:49 EDT 2014 >> r...@pandaes.in.nickh.org:/usr/src/sys/arch/armv7/compile/RAMDISK-SUNXI >> real mem = 1073741824 (1024MB) >> avail mem = 1036165120 (988MB) >> warning: no entropy supplied by boot loader >> mainbus0 at root >> cortex0 at mainbus0 >> ampintc0 at cortex0 nirq 160 >> cpu0 at mainbus0: ARM Cortex A7 rev 4 (ARMv7 core) >> cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled >> cpu0: 32KB(32b/l,2way) I-cache, 32KB(64b/l,4way) wr-back D-cache >> sunxi0 at mainbus0: A20 >> sxipio0 at sunxi0 >> sxiccmu0 at sunxi0 >> sxitimer0 at sunxi0: ticktimer 100hz @ 32KHz >> sxitimer1 at sunxi0: stattimer 128hz @ 32KHz >> sxitimer2 at sunxi0: cntrtimer @ 32KHz >> sxidog0 at sunxi0 >> sxirtc0 at sunxi0 >> sxiuart0 at sunxi0: console >> sxiuart1 at sunxi0 >> sxiuart2 at sunxi0 >> sxiuart3 at sunxi0 >> sxiuart4 at sunxi0 >> sxiuart5 at sunxi0 >> sxiuart6 at sunxi0 >> sxiuart7 at sunxi
Re: armv7: banana pi, Allwinner A20 board
Hi, I remember that there has been an issue, only seen on Cortex-A7/A15, like the Allwinner A20. The fix for that issue is somewhere here[0]. Try this[1] kernel and have a look if it has the same issue or not. I do not have an A20, so I can’t test it, sorry. But I’ll probably buy this[2][3] one once it’s available. \Patrick [0] https://github.com/bitrig/bitrig/commit/f1932308435a4b2c3daf0e880dc0adc829f5803d [1] https://www.blueri.se/bitrig/armv7/20140925/bsd.rd.SUNXI.umg [2] http://www.allnet.de/at/allnet-brand/produkte/neuheiten/p/banana-pi-router-board/ [3] http://www.sinovoip.com.cn/ecp_view.asp?id=554 > Am 02.10.2014 um 20:56 schrieb SASANO Takayoshi : > > Hello, > > I tried bsd.rd.SUNXI.umg snapshot on Banana Pi, cheap Allwinner A20 > board like Raspberry Pi (see http://www.lemaker.org/). > > It booted but something wrong. Arch Linux (for Banana Pi) works fine > so I think the board is not broken. > > This is my first OpenBSD/armv7 experience and I don't know what is > happening. What can I do for solving this problem? > > -- > SASANO Takayoshi > > [uEnv.txt] > mmcboot=mmc rescan; fatload mmc 0 0x6000 bsd.umg && bootm 0x6000; > bootargs=sd0a:/bsd; > uenvcmd=run mmcboot; > > > [1st try - hang up] > U-Boot SPL 2014.04-10694-g2ae8b32-dirty (Oct 01 2014 - 17:40:04) > Board: Bananapi > DRAM: 1024 MiB > CPU: 96000Hz, AXI/AHB/APB: 3/2/2 > spl: not an uImage at 1600 > > > U-Boot 2014.04-10694-g2ae8b32-dirty (Oct 01 2014 - 17:40:04) Allwinner > Technology > > CPU: Allwinner A20 (SUN7I) > Board: Bananapi > I2C: ready > DRAM: 1 GiB > MMC: SUNXI SD/MMC: 0 > *** Warning - bad CRC, using default environment > > In:serial > Out: serial > Err: serial > Net: dwmac.1c5 > Hit any key to stop autoboot: 0 > reading uEnv.txt > 116 bytes read in 16 ms (6.8 KiB/s) > Loaded environment from uEnv.txt > Running uenvcmd ... > reading bsd.umg > 7387788 bytes read in 367 ms (19.2 MiB/s) > ## Booting kernel from Legacy Image at 6000 ... > Image Name: boot > Image Type: ARM Linux Kernel Image (uncompressed) > Data Size:7387724 Bytes = 7 MiB > Load Address: 4080 > Entry Point: 4080 > Verifying Checksum ... OK > Loading Kernel Image ... OK > > Starting kernel ... > > > OpenBSD/sunxi booting ... > arg0 0x0 arg1 0x10bb arg2 0x4100 > atag core flags 0 pagesize 0 rootdev 0 > atag cmdline [sd0a:/bsd;] > atag mem start 0x4000 size 0x4000 > bootfile: sd0a:/bsd; > bootargs: > memory size derived from u-boot > bootconf.mem[0].address = 4000 pages 262144/0x4000 > Allocating page tables > freestart = 0x40f0c000, free_pages = 258292 (0x0003f0f4) > IRQ stack: p0x40f3a000 v0xc0f3a000 > ABT stack: p0x40f3b000 v0xc0f3b000 > UND stack: p0x40f3c000 v0xc0f3c000 > SVC stack: p0x40f3d000 v0xc0f3d000 > Creating L1 page table at 0x40f0c000 > Mapping kernel > Constructing L2 page tables > undefined page pmap [ using 169296 bytes of bsd ELF symbol table ] > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > Copyright (c) 1995-2014 OpenBSD. All rights reserved. http://www.OpenBSD.org > > OpenBSD 5.6 (RAMDISK-SUNXI) #3: Sun Aug 31 18:46:49 EDT 2014 >r...@pandaes.in.nickh.org:/usr/src/sys/arch/armv7/compile/RAMDISK-SUNXI > real mem = 1073741824 (1024MB) > avail mem = 1036165120 (988MB) > warning: no entropy supplied by boot loader > mainbus0 at root > cortex0 at mainbus0 > ampintc0 at cortex0 nirq 160 > cpu0 at mainbus0: ARM Cortex A7 rev 4 (ARMv7 core) > cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled > cpu0: 32KB(32b/l,2way) I-cache, 32KB(64b/l,4way) wr-back D-cache > sunxi0 at mainbus0: A20 > sxipio0 at sunxi0 > sxiccmu0 at sunxi0 > sxitimer0 at sunxi0: ticktimer 100hz @ 32KHz > sxitimer1 at sunxi0: stattimer 128hz @ 32KHz > sxitimer2 at sunxi0: cntrtimer @ 32KHz > sxidog0 at sunxi0 > sxirtc0 at sunxi0 > sxiuart0 at sunxi0: console > sxiuart1 at sunxi0 > sxiuart2 at sunxi0 > sxiuart3 at sunxi0 > sxiuart4 at sunxi0 > sxiuart5 at sunxi0 > sxiuart6 at sunxi0 > sxiuart7 at sunxi0 > sxie0 at sunxi0, address 02:99:03:c2:d2:6e > ukphy0 at sxie0 phy 0: Generic IEEE 802.3u media interface, rev. 5: OUI > 0x000732, model 0x0011 > ukphy1 at sxie0 phy 1: Generic IEEE 802.3u media interface, rev. 5: OUI > 0x000732, model 0x0011 > ahci0 at sunxi0 AHCI 1.1 > scsibus0 at ahci0: 32 targets > ehci0 at sunxi0 > usb0 at ehci0: USB revision 2.0 > uhub0 at usb0 "Allwinner EHCI root hub" rev 2.00/1.00 addr 1 > ehci1 at sunxi0 > usb1 at ehci1: USB revision 2.0 > uhub1 at usb1 "Allwinner EHCI root hub" rev 2.00/1.00 addr 1 > (hang up here) > > > [2nd try - ddb invoked] > U-Boot SPL 2014.04-10694-g2ae8b32-dirty (Oct 01 2014 - 17:40:04) > Board: Bananapi > DRAM: 1024 MiB > CPU: 96000Hz, AXI/AHB/APB: 3/2/2 > spl: not an uImage at 1600 > > > U-Boot 2014.04-10694
armv7: banana pi, Allwinner A20 board
Hello, I tried bsd.rd.SUNXI.umg snapshot on Banana Pi, cheap Allwinner A20 board like Raspberry Pi (see http://www.lemaker.org/). It booted but something wrong. Arch Linux (for Banana Pi) works fine so I think the board is not broken. This is my first OpenBSD/armv7 experience and I don't know what is happening. What can I do for solving this problem? -- SASANO Takayoshi [uEnv.txt] mmcboot=mmc rescan; fatload mmc 0 0x6000 bsd.umg && bootm 0x6000; bootargs=sd0a:/bsd; uenvcmd=run mmcboot; [1st try - hang up] U-Boot SPL 2014.04-10694-g2ae8b32-dirty (Oct 01 2014 - 17:40:04) Board: Bananapi DRAM: 1024 MiB CPU: 96000Hz, AXI/AHB/APB: 3/2/2 spl: not an uImage at 1600 U-Boot 2014.04-10694-g2ae8b32-dirty (Oct 01 2014 - 17:40:04) Allwinner Technology CPU: Allwinner A20 (SUN7I) Board: Bananapi I2C: ready DRAM: 1 GiB MMC: SUNXI SD/MMC: 0 *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Net: dwmac.1c5 Hit any key to stop autoboot: 0 reading uEnv.txt 116 bytes read in 16 ms (6.8 KiB/s) Loaded environment from uEnv.txt Running uenvcmd ... reading bsd.umg 7387788 bytes read in 367 ms (19.2 MiB/s) ## Booting kernel from Legacy Image at 6000 ... Image Name: boot Image Type: ARM Linux Kernel Image (uncompressed) Data Size:7387724 Bytes = 7 MiB Load Address: 4080 Entry Point: 4080 Verifying Checksum ... OK Loading Kernel Image ... OK Starting kernel ... OpenBSD/sunxi booting ... arg0 0x0 arg1 0x10bb arg2 0x4100 atag core flags 0 pagesize 0 rootdev 0 atag cmdline [sd0a:/bsd;] atag mem start 0x4000 size 0x4000 bootfile: sd0a:/bsd; bootargs: memory size derived from u-boot bootconf.mem[0].address = 4000 pages 262144/0x4000 Allocating page tables freestart = 0x40f0c000, free_pages = 258292 (0x0003f0f4) IRQ stack: p0x40f3a000 v0xc0f3a000 ABT stack: p0x40f3b000 v0xc0f3b000 UND stack: p0x40f3c000 v0xc0f3c000 SVC stack: p0x40f3d000 v0xc0f3d000 Creating L1 page table at 0x40f0c000 Mapping kernel Constructing L2 page tables undefined page pmap [ using 169296 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2014 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.6 (RAMDISK-SUNXI) #3: Sun Aug 31 18:46:49 EDT 2014 r...@pandaes.in.nickh.org:/usr/src/sys/arch/armv7/compile/RAMDISK-SUNXI real mem = 1073741824 (1024MB) avail mem = 1036165120 (988MB) warning: no entropy supplied by boot loader mainbus0 at root cortex0 at mainbus0 ampintc0 at cortex0 nirq 160 cpu0 at mainbus0: ARM Cortex A7 rev 4 (ARMv7 core) cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled cpu0: 32KB(32b/l,2way) I-cache, 32KB(64b/l,4way) wr-back D-cache sunxi0 at mainbus0: A20 sxipio0 at sunxi0 sxiccmu0 at sunxi0 sxitimer0 at sunxi0: ticktimer 100hz @ 32KHz sxitimer1 at sunxi0: stattimer 128hz @ 32KHz sxitimer2 at sunxi0: cntrtimer @ 32KHz sxidog0 at sunxi0 sxirtc0 at sunxi0 sxiuart0 at sunxi0: console sxiuart1 at sunxi0 sxiuart2 at sunxi0 sxiuart3 at sunxi0 sxiuart4 at sunxi0 sxiuart5 at sunxi0 sxiuart6 at sunxi0 sxiuart7 at sunxi0 sxie0 at sunxi0, address 02:99:03:c2:d2:6e ukphy0 at sxie0 phy 0: Generic IEEE 802.3u media interface, rev. 5: OUI 0x000732, model 0x0011 ukphy1 at sxie0 phy 1: Generic IEEE 802.3u media interface, rev. 5: OUI 0x000732, model 0x0011 ahci0 at sunxi0 AHCI 1.1 scsibus0 at ahci0: 32 targets ehci0 at sunxi0 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "Allwinner EHCI root hub" rev 2.00/1.00 addr 1 ehci1 at sunxi0 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 "Allwinner EHCI root hub" rev 2.00/1.00 addr 1 (hang up here) [2nd try - ddb invoked] U-Boot SPL 2014.04-10694-g2ae8b32-dirty (Oct 01 2014 - 17:40:04) Board: Bananapi DRAM: 1024 MiB CPU: 96000Hz, AXI/AHB/APB: 3/2/2 spl: not an uImage at 1600 U-Boot 2014.04-10694-g2ae8b32-dirty (Oct 01 2014 - 17:40:04) Allwinner Technology CPU: Allwinner A20 (SUN7I) Board: Bananapi I2C: ready DRAM: 1 GiB MMC: SUNXI SD/MMC: 0 *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Net: dwmac.1c5 Hit any key to stop autoboot: 0 reading uEnv.txt 116 bytes read in 16 ms (6.8 KiB/s) Loaded environment from uEnv.txt Running uenvcmd ... reading bsd.umg 7387788 bytes read in 370 ms (19 MiB/s) ## Booting kernel from Legacy Image at 6000 ... Image Name: boot Image Type: ARM Linux Kernel Image (uncompressed) Data Size:7387724 Bytes = 7 MiB Load Address: 4080 Entry Point: 4080 Verifying Checksum ... OK Loading Kernel Image ... OK Starting kernel ... OpenBSD/sunxi booting ... arg0 0x0 arg1 0x10bb arg2 0x4100 atag core flags 0 pagesize 0 rootdev 0 atag cmdline [sd0a:/bsd;] atag mem start 0x4000 size 0x4000 b
Re: USB stack change needed for xhci(4)
On Thu, Oct 02, 2014 at 12:20:14PM +0200, Martin Pieuchot wrote:
> Our USB stack contains a hack needed for ehci(4) and ohci(4) that
> breaks xhci(4). The diff below moves this hack in these drivers,
> and makes it possible to have a working xhci(4) in GENERIC.
>
> I'd like this diff to be tested on as much machines as possible, because
> the code path it touches is very sensible. This also matters if you are
> using uhci(4)!
>
> Please test and report back.
Tested umass on x61s (amd64 MP) and everything seems to be working just
fine.
I also read the diff and I'm okay with it going in.
>
> Thanks,
> Martin
>
> Index: ehci.c
> ===
> RCS file: /cvs/src/sys/dev/usb/ehci.c,v
> retrieving revision 1.168
> diff -u -p -r1.168 ehci.c
> --- ehci.c1 Sep 2014 08:13:02 - 1.168
> +++ ehci.c2 Oct 2014 09:30:28 -
> @@ -99,6 +99,7 @@ struct ehci_pipe {
> u_int8_t ehci_reverse_bits(u_int8_t, int);
>
> usbd_status ehci_open(struct usbd_pipe *);
> +int ehci_setaddr(struct usbd_device *, int);
> void ehci_poll(struct usbd_bus *);
> void ehci_softintr(void *);
> int ehci_intr1(struct ehci_softc *);
> @@ -215,7 +216,7 @@ void ehci_dump_exfer(struct ehci_xfer *
>
> struct usbd_bus_methods ehci_bus_methods = {
> .open_pipe = ehci_open,
> - .dev_setaddr = usbd_set_address,
> + .dev_setaddr = ehci_setaddr,
> .soft_intr = ehci_softintr,
> .do_poll = ehci_poll,
> .allocx = ehci_allocx,
> @@ -603,6 +604,40 @@ ehci_pcd(struct ehci_softc *sc, struct u
> xfer->status = USBD_NORMAL_COMPLETION;
>
> usb_transfer_complete(xfer);
> +}
> +
> +/*
> + * Work around the half configured control (default) pipe when setting
> + * the address of a device.
> + *
> + * Because a single QH is setup per endpoint in ehci_open(), and the
> + * control pipe is configured before we could have set the address
> + * of the device or read the wMaxPacketSize of the endpoint, we have
> + * to re-open the pipe twice here.
> + */
> +int
> +ehci_setaddr(struct usbd_device *dev, int addr)
> +{
> + /* Root Hub */
> + if (dev->depth == 0)
> + return (0);
> +
> + /* Re-establish the default pipe with the new max packet size. */
> + ehci_close_pipe(dev->default_pipe);
> + if (ehci_open(dev->default_pipe))
> + return (EINVAL);
> +
> + if (usbd_set_address(dev, addr))
> + return (1);
> +
> + dev->address = addr;
> +
> + /* Re-establish the default pipe with the new address. */
> + ehci_close_pipe(dev->default_pipe);
> + if (ehci_open(dev->default_pipe))
> + return (EINVAL);
> +
> + return (0);
> }
>
> void
> Index: ohci.c
> ===
> RCS file: /cvs/src/sys/dev/usb/ohci.c,v
> retrieving revision 1.139
> diff -u -p -r1.139 ohci.c
> --- ohci.c10 Aug 2014 11:18:57 - 1.139
> +++ ohci.c2 Oct 2014 09:33:03 -
> @@ -88,6 +88,7 @@ usbd_status ohci_alloc_std_chain(struct
> struct ohci_soft_td **);
>
> usbd_status ohci_open(struct usbd_pipe *);
> +int ohci_setaddr(struct usbd_device *, int);
> void ohci_poll(struct usbd_bus *);
> void ohci_softintr(void *);
> void ohci_waitintr(struct ohci_softc *, struct usbd_xfer *);
> @@ -232,7 +233,7 @@ struct ohci_pipe {
>
> struct usbd_bus_methods ohci_bus_methods = {
> .open_pipe = ohci_open,
> - .dev_setaddr = usbd_set_address,
> + .dev_setaddr = ohci_setaddr,
> .soft_intr = ohci_softintr,
> .do_poll = ohci_poll,
> .allocx = ohci_allocx,
> @@ -2003,6 +2004,40 @@ ohci_open(struct usbd_pipe *pipe)
> bad0:
> return (USBD_NOMEM);
>
> +}
> +
> +/*
> + * Work around the half configured control (default) pipe when setting
> + * the address of a device.
> + *
> + * Because a single ED is setup per endpoint in ohci_open(), and the
> + * control pipe is configured before we could have set the address
> + * of the device or read the wMaxPacketSize of the endpoint, we have
> + * to re-open the pipe twice here.
> + */
> +int
> +ohci_setaddr(struct usbd_device *dev, int addr)
> +{
> + /* Root Hub */
> + if (dev->depth == 0)
> + return (0);
> +
> + /* Re-establish the default pipe with the new max packet size. */
> + ohci_device_ctrl_close(dev->default_pipe);
> + if (ohci_open(dev->default_pipe))
> + return (EINVAL);
> +
> + if (usbd_set_address(dev, addr))
> + return (1);
> +
> + dev->address = addr;
> +
> + /* Re-establish the default pipe with the new address. */
> + ohci_device_ctrl_close(dev->default_pipe);
> + if (ohci_open(dev->default_pipe))
> + return (EINVAL);
> +
> + return (0);
> }
>
> /*
> Index: usb_subr.c
> ===
Re: Enable DWARF line decoding in ddb
To correct the instructions slightly... On Sun, Sep 28, 2014 at 11:00 PM, Matthew Dempsky wrote: ... > # Build new boot(8) > cd ../../stand/boot > make install Change that last line to make obj && make depend && make && make install > # Install new boot(8) > cp /usr/mdec/boot /boot > installboot -v /boot /usr/mdec/biosboot sd0 That should be installboot -v sd0 /usr/mdec/biosboot /boot (and if your boot drive isn't sd0 then change the line as appropriate, of course.) Philip Guenther
SPARC64: suggested fixes for OF interface
Hi all, From my work on running OpenBSD under OpenBIOS/QEMU, I found a couple of bugs in the NetBSD OF bindings for SPARC64 which also seem to be relevant to OpenBSD. I've applied patches to OpenBIOS to compensate for these bugs which allows OpenBSD to boot under QEMU, but thought that as there is interest here it would be worth documenting them for the sake of correctness. 1) OF_close has the wrong number of return arguments src/sys/arch/sparc64/stand/ofwboot/Locore.c specifies the OF_close has args.nreturns == 1. From the IEEE1275 specification we can see that the "close" word doesn't return any arguments, and so args.nreturns should be set to 0. OpenBIOS currently compensates for this and issues a warning when debugging is enabled. 2) OF_test_method takes a phandle not an ihandle, and also returns 0 on success src/sys/arch/sparc64/sparc64/ofw_machdep.c calls OF_test_method with an ihandle instead of an phandle as detailed in the Open Firmware working group proposal at http://www.openfirmware.org/1275/proposals/Closed/Accepted/270-it.txt (WARNING: the above link is currently down, however Google still has a cached version available). Similarly the Forth word signature looks like this: test-method ( method-cstr phandle -- missing-flag? ) This means that missing-flag? should be true if the method is missing and false if it is present, which indicates that the check to determine the existence of SUNW,retain in ofw_machdep.c is the wrong way around, i.e. the result comparison should be == 0 rather than != 0. What happens at the moment is that calling OF_test_method with an ihandle causes an exception and so the client inferface returns -1 to indicate failure. However since the result is checked for != 0 then this is taken to indicate that SUNW,retain exists which is why this currently works on some real PROMs. It's worth mentioning that this fixes test-method on E250/E450 systems and so the NetBSD folks were able to remove the is_e250 hack after testing on real hardware. For interested parties the corresponding NetBSD diff can be found at http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/sparc64/sparc64/ofw_machdep.c.diff?r1=1.41&r2=1.42&f=h. ATB, Mark.
Re: mpe patch: use rt_ifa_{add,del}
On 01/10/14(Wed) 21:54, Rafael Zalamena wrote:
> This new diff aims to simplify the mpe(4) device and also to improve
> the old code that handled the installation of MPLS interface routes.
>
> I followed what mpi@ said:
>
> On Tue, Sep 30, 2014 at 11:00:25AM +0200, Martin Pieuchot wrote:
> > Hello Rafael,
> >
> > On 14/09/14(Sun) 23:49, Rafael Zalamena wrote:
> > > The following patch is just a preparation for the code that is coming to
> > > implement the wire network interface (the VPLS datapath) to work on
> > > OpenBSD.
> > >
> > > This code turns the mpe code that handles route and labels into some
> > > general
> > > use functions that will be called by mpe and wire.
> >
> > Would it be possible to use the new rt_ifa_add() and rt_ifa_del() instead
> > of
> > keeping what is basically a copy of the old rtinit()?
> >
> > In your case you want to use the lladdr's ifa and you can check for
> > RTF_MPLS in the flags to add the corresponding MPLS_OP_POP value.
> >
> > --- patch snipped ---
>
> Code change:
> * Moved label address from softc to lladdr ifa
I'm afraid this is not what we want. The rest of your diff looks fine
but moving the storage to be represented as a 'destination address'
might make sense, but not attached on the lladdr ifa.
> * Changed rt_ifa_add to default RTF_MPLS routes to do a POP and only
> use rdomain 0 (MPLS only works on domain 0, and it doesn't make sense
> other actions when creating MPLS route to an interface)
> * Removed old code that installed mpe MPLS routes
> * Conflicting labels verification is now done by routing (see rt_ifa_add())
This looks ok.
> This was tested in the setup described in:
> http://2011.eurobsdcon.org/papers/jeker/MPLS.pdf
>
> Here is the diff:
> diff --git sys/net/if_mpe.c sys/net/if_mpe.c
> index 74039dc..8580ef3 100644
> --- sys/net/if_mpe.c
> +++ sys/net/if_mpe.c
> @@ -61,7 +61,6 @@ int mpeioctl(struct ifnet *, u_long, caddr_t);
> void mpestart(struct ifnet *);
> int mpe_clone_create(struct if_clone *, int);
> int mpe_clone_destroy(struct ifnet *);
> -int mpe_newlabel(struct ifnet *, int, struct shim_hdr *);
>
> LIST_HEAD(, mpe_softc) mpeif_list;
> struct if_clone mpe_cloner =
> @@ -84,13 +83,19 @@ mpe_clone_create(struct if_clone *ifc, int unit)
> {
> struct ifnet*ifp;
> struct mpe_softc*mpeif;
> + struct sockaddr_mpls*smpls;
> int s;
>
> if ((mpeif = malloc(sizeof(*mpeif),
> M_DEVBUF, M_NOWAIT|M_ZERO)) == NULL)
> return (ENOMEM);
>
> - mpeif->sc_shim.shim_label = 0;
> + smpls = malloc(sizeof(*smpls), M_IFADDR, M_NOWAIT | M_ZERO);
> + if (smpls == NULL) {
> + free(mpeif, M_DEVBUF, 0);
> + return (ENOMEM);
> + }
> +
> mpeif->sc_unit = unit;
> ifp = &mpeif->sc_if;
> snprintf(ifp->if_xname, sizeof ifp->if_xname, "mpe%d", unit);
> @@ -110,6 +115,10 @@ mpe_clone_create(struct if_clone *ifc, int unit)
> bpfattach(&ifp->if_bpf, ifp, DLT_LOOP, sizeof(u_int32_t));
> #endif
>
> + smpls->smpls_family = AF_MPLS;
> + smpls->smpls_len = sizeof(*smpls);
> + ifp->if_lladdr->ifa_dstaddr = smplstosa(smpls);
> +
> s = splnet();
> LIST_INSERT_HEAD(&mpeif_list, mpeif, sc_list);
> splx(s);
> @@ -127,6 +136,7 @@ mpe_clone_destroy(struct ifnet *ifp)
> LIST_REMOVE(mpeif, sc_list);
> splx(s);
>
> + free(ifp->if_lladdr->ifa_dstaddr, M_IFADDR, 0);
> if_detach(ifp);
> free(mpeif, M_DEVBUF, 0);
> return (0);
> @@ -278,7 +288,7 @@ int
> mpeioctl(struct ifnet *ifp, u_long cmd, caddr_t data)
> {
> int error;
> - struct mpe_softc*ifm;
> + struct sockaddr_mpls*smpls;
> struct ifreq*ifr;
> struct shim_hdr shim;
>
> @@ -303,14 +313,13 @@ mpeioctl(struct ifnet *ifp, u_long cmd, caddr_t data)
> ifp->if_mtu = ifr->ifr_mtu;
> break;
> case SIOCGETLABEL:
> - ifm = ifp->if_softc;
> + smpls = satosmpls(ifp->if_lladdr->ifa_dstaddr);
> shim.shim_label =
> - ((ntohl(ifm->sc_shim.shim_label & MPLS_LABEL_MASK)) >>
> + ((ntohl(smpls->smpls_label & MPLS_LABEL_MASK)) >>
> MPLS_LABEL_OFFSET);
> error = copyout(&shim, ifr->ifr_data, sizeof(shim));
> break;
> case SIOCSETLABEL:
> - ifm = ifp->if_softc;
> if ((error = copyin(ifr->ifr_data, &shim, sizeof(shim
> break;
> if (shim.shim_label > MPLS_LABEL_MAX ||
> @@ -319,36 +328,29 @@ mpeioctl(struct ifnet *ifp, u_long cmd, caddr_t data)
> break;
> }
> shim.shim_label = htonl(shim.shim_label << MPLS_LABEL_OFFSET);
> - if (ifm->sc_shim.shim_label == shim.shim_label)
> - break;
> - LIS
Re: [Patch] mbsrtowcs and wcsrtombs can receive src in NULL
On Thu, Oct 02, 2014 at 05:58:43AM -0500, Vladimir Támara Patiño wrote: > POSIX doesn't specify behavior for wcsrtombs and mbsrtowcs when the > source parameter is NULL. > http://pubs.opengroup.org/onlinepubs/009695399/functions/mbsrtowcs.html > http://pubs.opengroup.org/onlinepubs/009695399/functions/wcsrtombs.html > > However segfaulting in such cases, as happens with this example, > IMHO, is not desirable. It's perferctly acceptable for buggy applications to crash sooner rather than later. I don't think code which uses a NULL src will have any chance of surviving much longer even with your change. > The attached patch solves this by setting errno in EINVAL and > returning (size_t)-1 when the source parameter is NULL or points > to NULL, also includes this information in the man page. We can't just invent new meanings for errors codes. mbsrtowcs already defines EINVAL as "ps points to an object that contains an invalid conversion state".
[Patch] mbsrtowcs and wcsrtombs can receive src in NULL
POSIX doesn't specify behavior for wcsrtombs and mbsrtowcs when the
source parameter is NULL.
http://pubs.opengroup.org/onlinepubs/009695399/functions/mbsrtowcs.html
http://pubs.opengroup.org/onlinepubs/009695399/functions/wcsrtombs.html
However segfaulting in such cases, as happens with this example,
IMHO, is not desirable.
--- nullsrc.c
#include
#include
#include
#include
int main() {
char *msrc = NULL;
char mdst[100];
wchar_t *wsrc = NULL;
wchar_t wdst[100];
size_t s;
mbstate_t mbst;
bzero(&mbst, sizeof(mbst));
mbsinit(&mbst);
s = wcsrtombs(mdst, (const wchar_t **)&wsrc, 5, &mbst);
printf("fixed wcsrtombs without encoding\n");
s = mbsrtowcs(wdst, (const char **)&msrc, 5, &mbst);
printf("fixed mbsrtowcs without encoding\n");
setlocale(LC_ALL, "POSIX.UTF-8");
s = wcsrtombs(mdst, (const wchar_t **)&wsrc, 5, &mbst);
printf("fixed wcsrtombs with UTF-8\n");
s = mbsrtowcs(wdst, (const char **)&msrc, 5, &mbst);
printf("fixed mbsrtowcs with UTF-8\n");
return 0;
}
---
cc -g -o nullsrc nullsrc.c
gdb nullsrc
...
(gdb) run
Starting program: /home/vtamara/tmp/nullsrc
Program received signal SIGSEGV, Segmentation fault.
_citrus_none_ctype_wcsnrtombs (dst=0x7f7bee90 "",
src=0x7f7bee80, nwc=18446744073709551615, len=5,
pspriv=0x7f7bee00)
at /usr/src/lib/libc/citrus/citrus_none.c:155
155 wchar_t wc = (*src)[i];
---
The attached patch solves this by setting errno in EINVAL and
returning (size_t)-1 when the source parameter is NULL or points
to NULL, also includes this information in the man page.
--
Dios, gracias por tu amor infinito.
--
Vladimir Támara Patiño. http://vtamara.pasosdeJesus.org/
http://www.pasosdejesus.org/dominio_publico_colombia.html
diff -u src56-orig/lib/libc/citrus/citrus_none.c
src/lib/libc/citrus/citrus_none.c
--- src56-orig/lib/libc/citrus/citrus_none.cThu Mar 7 13:12:31 2013
+++ src/lib/libc/citrus/citrus_none.c Wed Oct 1 12:45:17 2014
@@ -93,6 +93,10 @@
/* dst may be NULL */
/* pspriv appears to be unused */
+ if (src == NULL || *src == NULL) {
+ errno = EINVAL;
+ return ((size_t)-1);
+ }
if (dst == NULL)
return strnlen(*src, nmc);
@@ -138,6 +142,10 @@
/* dst may be NULL */
/* pspriv appears to be unused */
+ if (src == NULL || *src == NULL) {
+ errno = EINVAL;
+ return ((size_t)-1);
+ }
if (dst == NULL) {
for (i = 0; i < nwc; i++) {
wchar_t wc = (*src)[i];
diff -u src56-orig/lib/libc/citrus/citrus_utf8.c
src/lib/libc/citrus/citrus_utf8.c
--- src56-orig/lib/libc/citrus/citrus_utf8.cFri Sep 19 13:07:15 2014
+++ src/lib/libc/citrus/citrus_utf8.c Wed Oct 1 12:44:01 2014
@@ -194,6 +194,10 @@
us = (struct _utf8_state *)pspriv;
+ if (src == NULL || *src == NULL) {
+ errno = EINVAL;
+return ((size_t)-1);
+}
if (dst == NULL) {
/*
* The fast path in the loop below is not safe if an ASCII
@@ -346,6 +350,10 @@
return ((size_t)-1);
}
+ if (src == NULL || *src == NULL) {
+ errno = EINVAL;
+return ((size_t)-1);
+}
if (dst == NULL) {
for (i = o = 0; i < nwc; i++, o += r) {
wchar_t wc = (*src)[i];
diff -u src56-orig/lib/libc/locale/mbsrtowcs.3 src/lib/libc/locale/mbsrtowcs.3
--- src56-orig/lib/libc/locale/mbsrtowcs.3 Tue Jun 4 22:39:22 2013
+++ src/lib/libc/locale/mbsrtowcs.3 Wed Oct 1 13:34:47 2014
@@ -151,8 +151,8 @@
is a null pointer, the value returned is the number of elements to contain
the whole string converted, except for a terminating null wide character.
.It (size_t)-1
-The array indirectly pointed to by
.Fa src
+is NULL or points to NULL or to an array that
contains a byte sequence forming invalid character.
In this case,
.Va errno
@@ -167,9 +167,8 @@
functions may return the following errors:
.Bl -tag -width Er
.It Bq Er EILSEQ
-The pointer pointed to by
.Fa src
-points to an invalid or incomplete multibyte character.
+is NULL or points to NULL or to an invalid or incomplete multibyte character.
.It Bq Er EINVAL
.Fa ps
points to an invalid or uninitialized mbstate_t object.
diff -u src56-orig/lib/libc/locale/wcsrtombs.3 src/lib/libc/locale/wcsrtombs.3
--- src56-orig/lib/libc/locale/wcsrtombs.3 Tue Jun 4 22:39:22 2013
+++ src/lib/libc/locale/wcsrtombs.3 Wed Oct 1 13:37:31 2014
@@ -153,7 +153,7 @@
will not be null-terminated.
.It (size_t)-1
.Fa src
-points to the string containing invalid wide character.
+is NULL or points to NULL or to a string containing invalid wide character.
In this case,
.Va errno
is set to indicate the error.
@@
Re: Local routes and loopback or p2p interfaces
On Thu, Oct 02, 2014 at 10:31:04AM +0200, Martin Pieuchot wrote:
> Most of the local routes added on a system contain the link-layer
> address of the interface they are attached too. It is like that
> because these routes must be compatible with the cloned routes for
> ARP or ND.
>
> But for loopback or point-to-point interfaces it is different since
> the 'gateway' of such routes contain 127.0.0.1. So there's no reason
> to flag such route with RTF_LLINFO. Diff below does that, as a result
> you won't see an incomplete entry in arp(8) for loopback addresses.
>
> -127.0.0.1 127.0.0.1 UHLl 10 32768 1 lo0
> +127.0.0.1 127.0.0.1 UHl10 32768 1 lo0
>
> ok?
Yes please I was wondering about the 'L' on those routes. OK.
> Index: net/route.c
> ===
> RCS file: /cvs/src/sys/net/route.c,v
> retrieving revision 1.184
> diff -u -p -r1.184 route.c
> --- net/route.c 1 Oct 2014 08:38:29 - 1.184
> +++ net/route.c 2 Oct 2014 08:09:58 -
> @@ -1202,6 +1202,7 @@ void
> rt_ifa_addloop(struct ifaddr *ifa)
> {
> struct rtentry *rt;
> + u_int flags = RTF_HOST|RTF_LOCAL;
>
> /*
>* If the configured address correspond to the magical "any"
> @@ -1225,11 +1226,13 @@ rt_ifa_addloop(struct ifaddr *ifa)
> break;
> }
>
> + if (!ISSET(ifa->ifa_ifp->if_flags, (IFF_LOOPBACK|IFF_POINTOPOINT)))
> + flags |= RTF_LLINFO;
> +
> /* If there is no loopback entry, allocate one. */
> rt = rtalloc1(ifa->ifa_addr, 0, ifa->ifa_ifp->if_rdomain);
> - if (rt == NULL || (rt->rt_flags & (RTF_HOST|RTF_LLINFO|RTF_LOCAL)) == 0)
> - rt_ifa_add(ifa, RTF_UP| RTF_HOST | RTF_LLINFO | RTF_LOCAL,
> - ifa->ifa_addr);
> + if (rt == NULL || !ISSET(rt->rt_flags, flags));
> + rt_ifa_add(ifa, RTF_UP | flags, ifa->ifa_addr);
> if (rt)
> rt->rt_refcnt--;
> }
> @@ -1241,6 +1244,7 @@ void
> rt_ifa_delloop(struct ifaddr *ifa)
> {
> struct rtentry *rt;
> + u_int flags = RTF_HOST|RTF_LOCAL;
>
> /*
>* We do not add local routes for such address, so do not bother
> @@ -1262,6 +1266,9 @@ rt_ifa_delloop(struct ifaddr *ifa)
> break;
> }
>
> + if (!ISSET(ifa->ifa_ifp->if_flags, (IFF_LOOPBACK|IFF_POINTOPOINT)))
> + flags |= RTF_LLINFO;
> +
> /*
>* Before deleting, check if a corresponding local host
>* route surely exists. With this check, we can avoid to
> @@ -1271,9 +1278,8 @@ rt_ifa_delloop(struct ifaddr *ifa)
>* to a shared medium.
>*/
> rt = rtalloc1(ifa->ifa_addr, 0, ifa->ifa_ifp->if_rdomain);
> - if (rt != NULL && (rt->rt_flags & (RTF_HOST|RTF_LLINFO|RTF_LOCAL)) != 0)
> - rt_ifa_del(ifa, RTF_HOST | RTF_LLINFO | RTF_LOCAL,
> - ifa->ifa_addr);
> + if (rt != NULL && ISSET(rt->rt_flags, flags))
> + rt_ifa_del(ifa, flags, ifa->ifa_addr);
> if (rt)
> rt->rt_refcnt--;
> }
>
--
:wq Claudio
USB stack change needed for xhci(4)
Our USB stack contains a hack needed for ehci(4) and ohci(4) that
breaks xhci(4). The diff below moves this hack in these drivers,
and makes it possible to have a working xhci(4) in GENERIC.
I'd like this diff to be tested on as much machines as possible, because
the code path it touches is very sensible. This also matters if you are
using uhci(4)!
Please test and report back.
Thanks,
Martin
Index: ehci.c
===
RCS file: /cvs/src/sys/dev/usb/ehci.c,v
retrieving revision 1.168
diff -u -p -r1.168 ehci.c
--- ehci.c 1 Sep 2014 08:13:02 - 1.168
+++ ehci.c 2 Oct 2014 09:30:28 -
@@ -99,6 +99,7 @@ struct ehci_pipe {
u_int8_t ehci_reverse_bits(u_int8_t, int);
usbd_statusehci_open(struct usbd_pipe *);
+intehci_setaddr(struct usbd_device *, int);
void ehci_poll(struct usbd_bus *);
void ehci_softintr(void *);
intehci_intr1(struct ehci_softc *);
@@ -215,7 +216,7 @@ voidehci_dump_exfer(struct ehci_xfer *
struct usbd_bus_methods ehci_bus_methods = {
.open_pipe = ehci_open,
- .dev_setaddr = usbd_set_address,
+ .dev_setaddr = ehci_setaddr,
.soft_intr = ehci_softintr,
.do_poll = ehci_poll,
.allocx = ehci_allocx,
@@ -603,6 +604,40 @@ ehci_pcd(struct ehci_softc *sc, struct u
xfer->status = USBD_NORMAL_COMPLETION;
usb_transfer_complete(xfer);
+}
+
+/*
+ * Work around the half configured control (default) pipe when setting
+ * the address of a device.
+ *
+ * Because a single QH is setup per endpoint in ehci_open(), and the
+ * control pipe is configured before we could have set the address
+ * of the device or read the wMaxPacketSize of the endpoint, we have
+ * to re-open the pipe twice here.
+ */
+int
+ehci_setaddr(struct usbd_device *dev, int addr)
+{
+ /* Root Hub */
+ if (dev->depth == 0)
+ return (0);
+
+ /* Re-establish the default pipe with the new max packet size. */
+ ehci_close_pipe(dev->default_pipe);
+ if (ehci_open(dev->default_pipe))
+ return (EINVAL);
+
+ if (usbd_set_address(dev, addr))
+ return (1);
+
+ dev->address = addr;
+
+ /* Re-establish the default pipe with the new address. */
+ ehci_close_pipe(dev->default_pipe);
+ if (ehci_open(dev->default_pipe))
+ return (EINVAL);
+
+ return (0);
}
void
Index: ohci.c
===
RCS file: /cvs/src/sys/dev/usb/ohci.c,v
retrieving revision 1.139
diff -u -p -r1.139 ohci.c
--- ohci.c 10 Aug 2014 11:18:57 - 1.139
+++ ohci.c 2 Oct 2014 09:33:03 -
@@ -88,6 +88,7 @@ usbd_status ohci_alloc_std_chain(struct
struct ohci_soft_td **);
usbd_statusohci_open(struct usbd_pipe *);
+intohci_setaddr(struct usbd_device *, int);
void ohci_poll(struct usbd_bus *);
void ohci_softintr(void *);
void ohci_waitintr(struct ohci_softc *, struct usbd_xfer *);
@@ -232,7 +233,7 @@ struct ohci_pipe {
struct usbd_bus_methods ohci_bus_methods = {
.open_pipe = ohci_open,
- .dev_setaddr = usbd_set_address,
+ .dev_setaddr = ohci_setaddr,
.soft_intr = ohci_softintr,
.do_poll = ohci_poll,
.allocx = ohci_allocx,
@@ -2003,6 +2004,40 @@ ohci_open(struct usbd_pipe *pipe)
bad0:
return (USBD_NOMEM);
+}
+
+/*
+ * Work around the half configured control (default) pipe when setting
+ * the address of a device.
+ *
+ * Because a single ED is setup per endpoint in ohci_open(), and the
+ * control pipe is configured before we could have set the address
+ * of the device or read the wMaxPacketSize of the endpoint, we have
+ * to re-open the pipe twice here.
+ */
+int
+ohci_setaddr(struct usbd_device *dev, int addr)
+{
+ /* Root Hub */
+ if (dev->depth == 0)
+ return (0);
+
+ /* Re-establish the default pipe with the new max packet size. */
+ ohci_device_ctrl_close(dev->default_pipe);
+ if (ohci_open(dev->default_pipe))
+ return (EINVAL);
+
+ if (usbd_set_address(dev, addr))
+ return (1);
+
+ dev->address = addr;
+
+ /* Re-establish the default pipe with the new address. */
+ ohci_device_ctrl_close(dev->default_pipe);
+ if (ohci_open(dev->default_pipe))
+ return (EINVAL);
+
+ return (0);
}
/*
Index: usb_subr.c
===
RCS file: /cvs/src/sys/dev/usb/usb_subr.c,v
retrieving revision 1.109
diff -u -p -r1.109 usb_subr.c
--- usb_subr.c 1 Oct 2014 08:29:01 - 1.109
+++ usb_subr.c 2 Oct 2014 09:24:18 -
@@ -901,8 +901,8 @@ usbd_probe_and_attach(struct device *par
"error=%s\n", parent->dv_xname, port,
Local routes and loopback or p2p interfaces
Most of the local routes added on a system contain the link-layer
address of the interface they are attached too. It is like that
because these routes must be compatible with the cloned routes for
ARP or ND.
But for loopback or point-to-point interfaces it is different since
the 'gateway' of such routes contain 127.0.0.1. So there's no reason
to flag such route with RTF_LLINFO. Diff below does that, as a result
you won't see an incomplete entry in arp(8) for loopback addresses.
-127.0.0.1 127.0.0.1 UHLl 10 32768 1 lo0
+127.0.0.1 127.0.0.1 UHl10 32768 1 lo0
ok?
Index: net/route.c
===
RCS file: /cvs/src/sys/net/route.c,v
retrieving revision 1.184
diff -u -p -r1.184 route.c
--- net/route.c 1 Oct 2014 08:38:29 - 1.184
+++ net/route.c 2 Oct 2014 08:09:58 -
@@ -1202,6 +1202,7 @@ void
rt_ifa_addloop(struct ifaddr *ifa)
{
struct rtentry *rt;
+ u_int flags = RTF_HOST|RTF_LOCAL;
/*
* If the configured address correspond to the magical "any"
@@ -1225,11 +1226,13 @@ rt_ifa_addloop(struct ifaddr *ifa)
break;
}
+ if (!ISSET(ifa->ifa_ifp->if_flags, (IFF_LOOPBACK|IFF_POINTOPOINT)))
+ flags |= RTF_LLINFO;
+
/* If there is no loopback entry, allocate one. */
rt = rtalloc1(ifa->ifa_addr, 0, ifa->ifa_ifp->if_rdomain);
- if (rt == NULL || (rt->rt_flags & (RTF_HOST|RTF_LLINFO|RTF_LOCAL)) == 0)
- rt_ifa_add(ifa, RTF_UP| RTF_HOST | RTF_LLINFO | RTF_LOCAL,
- ifa->ifa_addr);
+ if (rt == NULL || !ISSET(rt->rt_flags, flags));
+ rt_ifa_add(ifa, RTF_UP | flags, ifa->ifa_addr);
if (rt)
rt->rt_refcnt--;
}
@@ -1241,6 +1244,7 @@ void
rt_ifa_delloop(struct ifaddr *ifa)
{
struct rtentry *rt;
+ u_int flags = RTF_HOST|RTF_LOCAL;
/*
* We do not add local routes for such address, so do not bother
@@ -1262,6 +1266,9 @@ rt_ifa_delloop(struct ifaddr *ifa)
break;
}
+ if (!ISSET(ifa->ifa_ifp->if_flags, (IFF_LOOPBACK|IFF_POINTOPOINT)))
+ flags |= RTF_LLINFO;
+
/*
* Before deleting, check if a corresponding local host
* route surely exists. With this check, we can avoid to
@@ -1271,9 +1278,8 @@ rt_ifa_delloop(struct ifaddr *ifa)
* to a shared medium.
*/
rt = rtalloc1(ifa->ifa_addr, 0, ifa->ifa_ifp->if_rdomain);
- if (rt != NULL && (rt->rt_flags & (RTF_HOST|RTF_LLINFO|RTF_LOCAL)) != 0)
- rt_ifa_del(ifa, RTF_HOST | RTF_LLINFO | RTF_LOCAL,
- ifa->ifa_addr);
+ if (rt != NULL && ISSET(rt->rt_flags, flags))
+ rt_ifa_del(ifa, flags, ifa->ifa_addr);
if (rt)
rt->rt_refcnt--;
}
