Re: USB suspend/resume race

2014-05-26 Thread Mattieu Baptiste
On Mon, May 26, 2014 at 1:51 PM, Martin Pieuchot mpieuc...@nolizard.orgwrote:

 On 26/05/14(Mon) 13:46, Martin Pieuchot wrote:
  It is currently possible to trigger a race between the thread doing
  DVACT_QUIESCE and the USB thread exploring the buses.
 
  This race is really easy to reproduce if you have a lot of controllers
  and you try to suspend just after resuming.  In the best case, it blows
  your kernel during suspend, in the worst case it blows it at resume :)
 
  So here's a diff to avoid such race by deferring the action of detaching
  the root hub to the USB thread doing exploration.
 
  I'd appreciate if people having troubles with suspend/resume could try
  this diff an report back.

 Previous diff was lacking the header chunk, please use this one instead.



Hi Martin,

This seems to fix the freezes I encounter since some time when suspending
my laptop.

Thanks


Re: inteldrm/radeondrm suspend/resume diff

2014-03-13 Thread Mattieu Baptiste
On Thu, Mar 13, 2014 at 12:23 PM, Marc Peters m...@mpeters.org wrote:

 On 03/13/14 10:31, Mark Kettenis wrote:
  Date: Wed, 12 Mar 2014 22:54:06 +0100 (CET)
  From: Mark Kettenis mark.kette...@xs4all.nl
 
  The recent inteldrm suspend/resume regression thread pointed out
  that suspend/resume was quite horribly broken and only worked somewhat
  if you didn't heavily use the 3D acceleration stuff.  Here's a diff
  that should fix most of the problems, by making sure userland programs
  are properly blocked if they try to use drm while we're suspending or
  resuming the machine.
 
  I would like to see this diff tested some more by people who actually
  use all that eye candy.  The thing to watch for is hangs when you try
  to suspend your machine.
 
  Thanks,
 
  Mark
 
  P.S. This seems to make hibernation (ZZZ) work with both inteldrm(4)
  and radeondrm(4) on my t400.
 
  Here's a slightly better diff that should eleminate a (largely
  theoretical) deadlock.  If you didn't test yet, try this version
  instead.

 suspend/resume is working. After waking up, Jira in Chrome is no more
 dead slow, as it was before.

 Hibernating is not working at all at my T530 (crypto softraid on SSD
 with Swap inside the softraid). I don't know, if it was working before,
 but i usually use suspend. Maybe my swap partition (16G) is to few for
 the RAM, didn't really check yet.



This patch also fixes the problem for me. After multiple suspend/resume
cycles, X no longer eats the CPU on my T510 with:

vga1 at pci0 dev 2 function 0 Intel HD Graphics rev 0x02
intagp0 at vga1
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: 1366x768





siop(4) man page correction

2011-02-07 Thread Mattieu Baptiste
Hi all,

According to src/sys/dev/ic/siop.c rev 1.6, siop(4) supports U160
SCSI. So it should be:

--- siop.4.orig Mon Feb  7 10:12:39 2011
+++ siop.4  Mon Feb  7 10:13:58 2011
@@ -85,11 +85,7 @@
 .Tn SCSI )
 .It
 53c1010 (PCI 64bit, dual Ultra3-Wide
-.Tn SCSI .
-.Em NOTE :
-at this time
-.Nm
-supports at most Ultra2-Wide with this chip)
+.Tn SCSI )
 .It
 53c1510D (dual Ultra2-Wide
 .Tn SCSI )


-- 
Mattieu Baptiste
/earth is 102% full ... please delete anyone you can.



Re: siop(4) man page correction

2011-02-07 Thread Mattieu Baptiste
On Mon, Feb 7, 2011 at 5:12 PM, Kenneth R Westerback
kwesterb...@rogers.com wrote:

 Ultra2-Wide is U160. Ultra3 is U320. As I recall. So the page seems
 correct to me. Unless you have evidence that U320 is supported.

To me, Ultra2-Wide is different from U160 (Ultra3). And U160 is a
different beast than U320 (Ultra4).
Anyway, do you know any siop(4) adapter that is U320 capable?

See:
- 53c896 is Ultra2:
http://www.alldatasheet.com/datasheet-pdf/pdf/167155/ETC1/LSI53C896.html
- 53c1010 is U160, also known as Ultra3:
http://www.datasheetarchive.com/pdf/getfile.php?dir=Datasheets-308file=41220.pdfscan=

You can also check the NetBSD esiop(4) man page:
http://netbsd.gw.com/cgi-bin/man-cgi?esiop+4.sparc64+NetBSD-current

-- 
Mattieu Baptiste
/earth is 102% full ... please delete anyone you can.



permit daily(8) to use DUID in /etc/fstab for ROOTBACKUP

2011-03-18 Thread Mattieu Baptiste
Hi all,

This diff enables daily(8) to use DUID instead of pathname in
/etc/fstab for backing up root filesystem.
I'm not a shell expert... comments are welcome.

Index: daily
===
RCS file: /cvs/src/etc/daily,v
retrieving revision 1.68
diff -u -r1.68 daily
--- daily   22 Sep 2010 13:01:10 -  1.68
+++ daily   18 Mar 2011 15:15:57 -
@@ -97,11 +97,22 @@
rootbak=`awk '$2 == /altroot  $1 ~ /^\/dev\//  $3 == ffs  \
$4 ~ /xx/ \
{ print substr($1, 6) }'  /etc/fstab`
-   if [ -z $rootbak ]; then
-   echo No xx ffs /altroot device found in the fstab(5).
-   break
+   if [ ! -z $rootbak ]; then
+   bakdisk=${rootbak%[a-p]}
+   else
+   duid=`awk '$2 == /altroot  $1 ~ /^.*\..*/  \
+   $3 == ffs  $4 ~ /xx/ \
+   { print substr($1, 1, 18) }'  /etc/fstab`
+   if [ -z $duid ]; then
+   echo No xx ffs /altroot device found in the fstab(5).
+   break
+   fi
+   duiddisk=`echo $duid | awk '{ print substr($1, 1, 16) }'`
+   bakdisk=`sysctl -n hw.disknames | \
+   sed -e 's/.*[,=]\(.*\):'$duiddisk'.*/\1/'`
+   rootbak=`echo $duid | \
+   awk '{ print '$bakdisk'substr($1, 18, 1) }'`
fi
-   bakdisk=${rootbak%[a-p]}
sysctl -n hw.disknames | grep -Fqw $bakdisk || break
bakpart=${rootbak#$bakdisk}
baksize=`disklabel $bakdisk 2/dev/null | \



-- 
Mattieu Baptiste
/earth is 102% full ... please delete anyone you can.



Re: Quick sanity test for sili(4)/ahci(4) diff

2011-05-06 Thread Mattieu Baptiste
/SATA rev 0x03
pciide0 at jmb1: DMA, channel 0 wired to native-PCI, channel 1 wired
to native-PCI
pciide0: using apic 6 int 19 for native-PCI interrupt
atapiscsi0 at pciide0 channel 0 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0: PHILIPS, DVDR1628P1, Q1.1 ATAPI
5/cdrom removable
cd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 disabled (no drives)
ppb5 at pci0 dev 28 function 7 Intel 3400 PCIE rev 0x06: apic 6 int 19
pci6 at ppb5 bus 2
re0 at pci6 dev 0 function 0 Realtek 8168 rev 0x03: RTL8168D/8111D
(0x2800), apic 6 int 19, address 48:5b:39:46:e1:d5
rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 2
ehci1 at pci0 dev 29 function 0 Intel 3400 USB rev 0x06: apic 6 int 23
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1
ppb6 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0xa6
pci7 at ppb6 bus 7
pcib0 at pci0 dev 31 function 0 Intel P55 LPC rev 0x06
ahci1 at pci0 dev 31 function 2 Intel 3400 AHCI rev 0x06: apic 6 int
21, AHCI 1.3
scsibus2 at ahci1: 32 targets
sd1 at scsibus2 targ 0 lun 0: ATA, C300-CTFDDAC064M, 0002 SCSI3
0/direct fixed naa.500a075102fbf57c
sd1: 61057MB, 512 bytes/sec, 125045424 sec total
sd2 at scsibus2 targ 1 lun 0: ATA, WDC WD10EALS-002, 05.0 SCSI3
0/direct fixed naa.50014ee2af255ab6
sd2: 953869MB, 512 bytes/sec, 1953525168 sec total
ichiic0 at pci0 dev 31 function 3 Intel 3400 SMBus rev 0x06: apic 6 int 18
iic0 at ichiic0
spdmem0 at iic0 addr 0x50: 2GB DDR3 SDRAM PC3-10600
spdmem1 at iic0 addr 0x52: 2GB DDR3 SDRAM PC3-10600
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lm0 at isa0 port 0x290/8: W83627DHG
mtrr: Pentium Pro MTRR support
uhub2 at uhub0 port 1 Intel Rate Matching Hub rev 2.00/0.00 addr 2
uhub3 at uhub1 port 1 Intel Rate Matching Hub rev 2.00/0.00 addr 2
uhidev0 at uhub3 port 7 configuration 1 interface 0 Logitech USB-PS/2
Optical Mouse rev 2.00/22.00 addr 3
uhidev0: iclass 3/1
ums0 at uhidev0: 8 buttons, Z dir
wsmouse0 at ums0 mux 0
uvideo0 at uhub3 port 8 configuration 1 interface 0 Logitech QuickCam
Pro 9000 rev 2.00/0.08 addr 4
video0 at uvideo0
uaudio0 at uhub3 port 8 configuration 1 interface 2 Logitech QuickCam
Pro 9000 rev 2.00/0.08 addr 4
uaudio0: audio rev 1.00, 2 mixer controls
audio1 at uaudio0
vscsi0 at root
scsibus3 at vscsi0: 256 targets
softraid0 at root
root on sd1a swap on sd1b dump on sd1b



--
Mattieu Baptiste
/earth is 102% full ... please delete anyone you can.



Re: pool_debug and network throughput on Alix

2013-01-22 Thread Mattieu Baptiste
Yes, i'm seeing that too on a Soekris net5501.

Mattieu Baptiste
/earth is 102% full ... please delete anyone you can.
Le 22 janv. 2013 12:41, Stuart Henderson s...@spacehopper.org a écrit :

 Seeing some odd behaviour on an alix firewall and wondering if
 other people see the same, or it's something odd with my setup.
 I'm testing by running tcpbench on two other machines, with the
 traffic routed through the alix, ethernet-ethernet, not natted.

 With pool_debug enabled (sysctl kern.pool_debug=1) as is default
 in -current, I'm seeing a reasonably stable 63Mb/s and kern.netlivelocks
 raises by around 3.5 per second.

 With pool_debug *disabled* the top speed raises but it's really
 unstable; tcpbench reported rates from around 1.5Mb/s up to 75Mb/s
 and a much lower overall average. netlivelocks raises by ~10.5/second.

 Is anyone else seeing anything like this?



Re: pppx(4) and a pppx interface group

2013-02-03 Thread Mattieu Baptiste
On Fri, Feb 1, 2013 at 10:17 PM, Stuart Henderson s...@spacehopper.orgwrote:

 In gmane.os.openbsd.misc, Mattieu Baptiste wrote:
  Hi,
 
  I'm testing npppd with pppx(4).
 
  As i'm understanding npppd, a new pppx(4) interface is created for every
  new session. Thus, new /dev/pppxN nodes must be created for the sessions
  that we intend to have.
 
  But at this point, filtering with PF needs special handling for every
  pppx(4) interface. How about adding these interfaces to a pppx
 interface
  group, by adding the if_addgroup() call ?
 
  What do you think ?

 This makes sense to me, and the diff below seems to work:



Hello Stuart,

Thanks, this works as expected.




 Index: if_pppx.c
 ===
 RCS file: /cvs/src/sys/net/if_pppx.c,v
 retrieving revision 1.15
 diff -u -p -r1.15 if_pppx.c
 --- if_pppx.c   19 Sep 2012 17:50:17 -  1.15
 +++ if_pppx.c   1 Feb 2013 21:15:47 -
 @@ -874,6 +874,7 @@ pppx_add_session(struct pppx_dev *pxd, s
 pipex_timer_start();

 if_attach(ifp);
 +   if_addgroup(ifp, pppx);
 if_alloc_sadl(ifp);

  #if NBPFILTER  0




-- 
Mattieu Baptiste
/earth is 102% full ... please delete anyone you can.


Re: More Canon scanners (usbdevs, uscanner.c)

2010-11-23 Thread Mattieu Baptiste
On Sat, Jul 1, 2006 at 12:38 PM, Miod Vallat m...@online.fr wrote:
 This diff add support for more Canon scanners in -current (from
 NetBSD). Tested on i386 with a CanoScan Lide 30:

 Applied. Thanks!

 Miod


Hi all,

Don't know what I drank at this time but it wasn't good at all for my brain.

I'd like to know if people are able to use their Canon scanner with
xsane via uscanner, because I can't with my Canon Lide 30.

So... if people have the same problems that I'm facing with Canon
scanners, I propose to completely revert the uscanner.c commit (rev
1.21).
Or if it's just with my device, I propose this patch which let me scan
content with xsane:


Index: uscanner.c
===
RCS file: /cvs/src/sys/dev/usb/uscanner.c,v
retrieving revision 1.43
diff -u -p -r1.43 uscanner.c
--- uscanner.c  24 Sep 2010 08:33:59 -  1.43
+++ uscanner.c  23 Nov 2010 20:36:35 -
@@ -94,7 +94,6 @@ static const struct uscan_info uscanner_
  {{ USB_VENDOR_CANON, USB_PRODUCT_CANON_N656U }, 0 },
  {{ USB_VENDOR_CANON, USB_PRODUCT_CANON_N670U }, 0 },
  {{ USB_VENDOR_CANON, USB_PRODUCT_CANON_N1220U }, 0 },
- {{ USB_VENDOR_CANON, USB_PRODUCT_CANON_N1240U }, 0 },

   /* Kye */
  {{ USB_VENDOR_KYE, USB_PRODUCT_KYE_VIVIDPRO }, 0 },



-- 
Mattieu Baptiste
/earth is 102% full ... please delete anyone you can.



Re: More Canon scanners (usbdevs, uscanner.c)

2010-11-23 Thread Mattieu Baptiste
On Tue, Nov 23, 2010 at 10:51 PM, Miod Vallat m...@online.fr wrote:

 Could this be caused by changes in the kernel and/or in xsane? Did you
 try e.g. an older xsane against a kernel which attaches your hardware as
 uscanner, and against a kernel with the uscanner.c chunk reverted?

In fact, if my memory serves me right, I've never been able to use my
scanner with uscanner (I have this device since years).

I always had to disable uscanner at boot time, let the device attach
as ugen, and run xsane. Then xsane works like a charm.

When this devices attaches as uscanner, xsane is not able to detect the scanner.

-- 
Mattieu Baptiste
/earth is 102% full ... please delete anyone you can.



Re: More Canon scanners (usbdevs, uscanner.c)

2010-11-25 Thread Mattieu Baptiste
On Thu, Nov 25, 2010 at 2:28 PM, Mark Kettenis mark.kette...@xs4all.nl
wrote:


 Just nuke it.  It'll be sitting in the attick if anybody wants it back.


Ok, here is a proposed diff that can also be found at:
http://www.brimbelle.org/mattieu/stuff/uscanner.diff

Compile tested on amd64.


Index: sys/dev/usb/uscanner.c
===
RCS file: sys/dev/usb/uscanner.c
diff -N sys/dev/usb/uscanner.c
--- sys/dev/usb/uscanner.c  24 Sep 2010 08:33:59 -  1.43
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,687 +0,0 @@
-/* $OpenBSD: uscanner.c,v 1.43 2010/09/24 08:33:59 yuo Exp $ */
-/* $NetBSD: uscanner.c,v 1.40 2003/01/27 00:32:44 wiz Exp $*/
-
-/*
- * Copyright (c) 2000 The NetBSD Foundation, Inc.
- * All rights reserved.
- *
- * This code is derived from software contributed to The NetBSD Foundation
- * by Lennart Augustsson (lenn...@augustsson.net) at
- * Carlstedt Research  Technology
- * and Nick Hibma (n_hi...@qubesoft.com).
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
- * 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.
- *
- * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
- * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED
- * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR
- * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
- * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
- * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
- * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
- * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
- * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
- * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
THE
- * POSSIBILITY OF SUCH DAMAGE.
- */
-
-
-#include sys/param.h
-#include sys/systm.h
-#include sys/kernel.h
-#include sys/malloc.h
-#include sys/device.h
-#include sys/tty.h
-#include sys/file.h
-#include sys/selinfo.h
-#include sys/proc.h
-#include sys/vnode.h
-#include sys/poll.h
-#include sys/conf.h
-
-#include dev/usb/usb.h
-#include dev/usb/usbdi.h
-#include dev/usb/usbdi_util.h
-
-#include dev/usb/usbdevs.h
-
-#ifdef USCANNER_DEBUG
-#define DPRINTF(x) do { if (uscannerdebug) printf x; } while (0)
-#define DPRINTFN(n,x)  do { if (uscannerdebug(n)) printf x; } while (0)
-intuscannerdebug = 0;
-#else
-#define DPRINTF(x)
-#define DPRINTFN(n,x)
-#endif
-
-struct uscan_info {
-   struct usb_devno devno;
-   u_int flags;
-#define USC_KEEP_OPEN 1
-};
-
-/* Table of scanners that may work with this driver. */
-static const struct uscan_info uscanner_devs[] = {
-  /* Acer Peripherals */
- {{ USB_VENDOR_ACERP, USB_PRODUCT_ACERP_ACERSCAN_320U }, 0 },
- {{ USB_VENDOR_ACERP, USB_PRODUCT_ACERP_ACERSCAN_640U }, 0 },
- {{ USB_VENDOR_ACERP, USB_PRODUCT_ACERP_ACERSCAN_620U }, 0 },
- {{ USB_VENDOR_ACERP, USB_PRODUCT_ACERP_ACERSCAN_C310U }, 0 },
-
-  /* AGFA */
- {{ USB_VENDOR_AGFA, USB_PRODUCT_AGFA_SNAPSCAN1236U }, 0 },
- {{ USB_VENDOR_AGFA, USB_PRODUCT_AGFA_SNAPSCAN1212U }, 0 },
- {{ USB_VENDOR_AGFA, USB_PRODUCT_AGFA_SNAPSCAN1212U2 }, 0 },
- {{ USB_VENDOR_AGFA, USB_PRODUCT_AGFA_SNAPSCANTOUCH }, 0 },
- {{ USB_VENDOR_AGFA, USB_PRODUCT_AGFA_SNAPSCANE40 }, 0 },
- {{ USB_VENDOR_AGFA, USB_PRODUCT_AGFA_SNAPSCANE50 }, 0 },
- {{ USB_VENDOR_AGFA, USB_PRODUCT_AGFA_SNAPSCANE20 }, 0 },
- {{ USB_VENDOR_AGFA, USB_PRODUCT_AGFA_SNAPSCANE25 }, 0 },
- {{ USB_VENDOR_AGFA, USB_PRODUCT_AGFA_SNAPSCANE26 }, 0 },
- {{ USB_VENDOR_AGFA, USB_PRODUCT_AGFA_SNAPSCANE52 }, 0 },
-
-  /* Avision */
- {{ USB_VENDOR_AVISION, USB_PRODUCT_AVISION_1200U }, 0 },
-
-  /* Canon */
- {{ USB_VENDOR_CANON, USB_PRODUCT_CANON_N656U }, 0 },
- {{ USB_VENDOR_CANON, USB_PRODUCT_CANON_N670U }, 0 },
- {{ USB_VENDOR_CANON, USB_PRODUCT_CANON_N1220U }, 0 },
- {{ USB_VENDOR_CANON, USB_PRODUCT_CANON_N1240U }, 0 },
-
-  /* Kye */
- {{ USB_VENDOR_KYE, USB_PRODUCT_KYE_VIVIDPRO }, 0 },
-
-  /* HP */
- {{ USB_VENDOR_HP, USB_PRODUCT_HP_2200C }, 0 },
- {{ USB_VENDOR_HP, USB_PRODUCT_HP_3300C }, 0 },
- {{ USB_VENDOR_HP, USB_PRODUCT_HP_3400CSE }, 0 },
- {{ USB_VENDOR_HP, USB_PRODUCT_HP_4100C }, 0 },
- {{ USB_VENDOR_HP, USB_PRODUCT_HP_4200C }, 0 },
- {{ USB_VENDOR_HP, USB_PRODUCT_HP_4300C }, 0 },
- {{ USB_VENDOR_HP, USB_PRODUCT_HP_S20 }, 0 },
- {{ USB_VENDOR_HP, USB_PRODUCT_HP_5200C }, 0 },
- {{ USB_VENDOR_HP, USB_PRODUCT_HP_6200C }, 0 },
- {{ USB_VENDOR_HP, USB_PRODUCT_HP_6300C }, 0 },
-
-  /* 

Re: VLAN + bridge regression

2014-12-01 Thread Mattieu Baptiste
On Thu, Nov 13, 2014 at 5:50 PM, Rafael Zalamena rzalam...@gmail.com wrote:

 Conclusion: (short answer)
 The problem with moving the vlan_input chunk is that we have to do tag
 re-insertion in some cases, might break QinQ and it looks to be a more
 intrusive code change than it is with this diff.


Hi,
Is there any chance the fix will be committed ? It's working
flawlessly for me. I've been testing it during the last 15 days.

-- 
Mattieu Baptiste
/earth is 102% full ... please delete anyone you can.



Re: Possible em(4) fix

2015-10-05 Thread Mattieu Baptiste
On Mon, Oct 5, 2015 at 10:45 PM, Mark Kettenis  wrote:
> Several people seem to complain on misc@ that they're seeing watchdog
> timeouts on em(4).  But none of them bother to submit a proper bug
> report to bugs@.  Anyway, here is a diff that might fix the issue.
> Please test, even if you're not experiencing any problems.

Hi Mark,

After a few tests, I'm able to better report what I encounter.
As I said in the other thread, I'm experiencing the bug on
-current/amd64 (not on a snapshot).
It's easily reproducible when watching big movies from an NFS mount point.
When "watchdog timeout" appears, the box froze : I cannot even cleanly reboot.

My interface is:
em0 at pci2 dev 0 function 0 "Intel 82571EB" rev 0x06: apic 6 int 16

Full dmesg follows.

After reverting em(4) to 09/25, as Stuart suggested, everything is OK.
Your diff is also working for me : I cannot reproduce the bug after an
hour of stress test.


OpenBSD 5.8-current (GENERIC.MP) #16: Mon Oct  5 23:16:03 CEST 2015
matt...@kronenbourg.brimbelle.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8571518976 (8174MB)
avail mem = 8307621888 (7922MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf0710 (68 entries)
bios0: vendor American Megatrends Inc. version "2003" date 12/14/2010
bios0: ASUSTeK Computer INC. P7P55D
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET DMAR ASPT OSFR
acpi0: wakeup devices P0P4(S4) BR1E(S4) UAR1(S4) PS2K(S4) PS2M(S4)
EUSB(S4) USB0(S4) USB1(S4) USB2(S4) USB3(S4) USBE(S4) USB4(S4)
USB5(S4) USB6(S4) BR21(S4) BR22(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5 CPU 660 @ 3.33GHz, 3374.31 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 160MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 4 (application processor)
cpu1: Intel(R) Core(TM) i5 CPU 660 @ 3.33GHz, 3373.90 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 2, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i5 CPU 660 @ 3.33GHz, 3373.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,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 5 (application processor)
cpu3: Intel(R) Core(TM) i5 CPU 660 @ 3.33GHz, 3373.90 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 2, package 0
ioapic0 at mainbus0: apid 6 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 1, remapped to apid 6
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 7 (BR1E)
acpiprt2 at acpi0: bus -1 (BR21)
acpiprt3 at acpi0: bus -1 (BR22)
acpiprt4 at acpi0: bus -1 (BR23)
acpiprt5 at acpi0: bus 1 (P0P1)
acpiprt6 at acpi0: bus -1 (P0P3)
acpiprt7 at acpi0: bus -1 (P0P5)
acpiprt8 at acpi0: bus -1 (P0P6)
acpiprt9 at acpi0: bus 6 (BR20)
acpiprt10 at acpi0: bus 5 (BR24)
acpiprt11 at acpi0: bus 4 (BR25)
acpiprt12 at acpi0: bus 3 (BR26)
acpiprt13 at acpi0: bus 2 (BR27)
acpiec0 at acpi0
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
acpicpu2 at acpi0: C1(@1 halt!)
acpicpu3 at acpi0: C1(@1 halt!)
aibs0 at acpi0 GGRP GITM SITM
acpibtn0 at acpi0: PWRB
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core Host" rev 0x12
ppb0 at pci0 dev 1 function 0 "Intel Core PCIE" rev 0x12: msi
pci1 at ppb0 bus 1
radeondrm0 at pci1 dev 0 function 0 "ATI Radeon HD 4670" rev 0x00
drm0 at radeondrm0
radeondrm0: msi
azalia0 at pci1 dev 0 function 1 "ATI Radeon HD 4000 HD Audio" rev 0x00: msi
azalia0: no supported codecs
ehci0 at pci0 dev 26 function 0 "Intel 3400 USB" rev 0x06: apic 6 int 16
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 

Re: KASSERT() @ pf_test() is back

2016-03-07 Thread Mattieu Baptiste
On Mon, Mar 7, 2016 at 10:03 AM, Alexandr Nedvedicky
 wrote:
> Hello Mattieu,
>
> Mark Patruck reported panic on KASSERT() in pf_test() yesterday . I've crafted
> patch below. Can you try it out?
>
> I think we need to apply pf_pkt_addr_changed() on broadcast packets seen by 
> bridge
> as well.
>
> thanks a lot
> and sorry for inconveniences

Hi Alexandr,
I don't know if both are necessary but, with your patch and the one
from Martin, the box survives after reboot. Thanks!
Do you want I test just with your patch?



Re: KASSERT() @ pf_test() is back

2016-03-06 Thread Mattieu Baptiste
On Sun, Mar 6, 2016 at 10:22 PM, Martin Pieuchot <m...@openbsd.org> wrote:
> On 06/03/16(Sun) 19:57, Mattieu Baptiste wrote:
>> [...]
>> As discussed in january, with the patches committed, -current still
>> panics for me:
>> http://www.brimbelle.org/mattieu/stuff/panic_statekey/panic10.jpg
>> http://www.brimbelle.org/mattieu/stuff/panic_statekey/panic11.jpg
>> http://www.brimbelle.org/mattieu/stuff/panic_statekey/panic12.jpg
>>
>> Here is a dmesg from the last time I built a kernel, before the
>> patches were committed:
>
> Could you also paste the content of your /etc/hostname.* and "route -n show"
> for this system?

Yes, sure:

$ cat /etc/hostname.bridge0
add em0
add re0
up

$ cat /etc/hostname.em0
dhcp
rtsol
inet6 2a01:e35:8aee:3fb1::24 64
up

$ cat /etc/hostname.re0
wol

$ route -n show
Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
default192.168.42.1   UGS4 3075 - 8 em0
127/8  127.0.0.1  UGRS   00 32768 8 lo0
127.0.0.1  127.0.0.1  UHl00 32768 1 lo0
192.168.42/24  192.168.42.24  UC 3 6078 - 4 em0
192.168.42.1   00:0d:b9:33:8e:8c  UHLc   2  395 - 4 em0
192.168.42.10  68:05:ca:09:38:ac  UHLc   3   38 - 4 em0
192.168.42.16  68:05:ca:09:38:ac  UHLc   0  400 - 4 em0
192.168.42.24  00:15:17:8a:8f:d2  UHLl   0  222 - 1 em0
192.168.42.255 192.168.42.24  UHb0 9078 - 1 em0
224/4  127.0.0.1  URS0 3434 32768 8 lo0

Internet6:
DestinationGateway
Flags   Refs  Use   Mtu  Prio Iface
::/104 ::1UGRS
  00 32768 8 lo0
::/96  ::1UGRS
  00 32768 8 lo0
defaultfe80::20d:b9ff:fe33:8e8c%em0   UG
 18  912 -56 em0
::1::1UHl
  55 32768 1 lo0
::127.0.0.0/104::1UGRS
  00 32768 8 lo0
::224.0.0.0/100::1UGRS
  00 32768 8 lo0
::255.0.0.0/104::1UGRS
  00 32768 8 lo0
:::0.0.0.0/96  ::1UGRS
  00 32768 8 lo0
2002::/24  ::1UGRS
  00 32768 8 lo0
2002:7f00::/24 ::1UGRS
  00 32768 8 lo0
2002:e000::/20 ::1UGRS
  00 32768 8 lo0
2002:ff00::/24 ::1UGRS
  00 32768 8 lo0
2a01:e35:8aee:3fb1::/642a01:e35:8aee:3fb1::24 UCP
  14 - 4 em0
2a01:e35:8aee:3fb1::/64
2a01:e35:8aee:3fb1:215:17ff:fe8a:8fd2 UCP00 -
4 em0
2a01:e35:8aee:3fb1::1  00:0d:b9:33:8e:8c  UHLc
  0 1275 - 4 em0
2a01:e35:8aee:3fb1::24 00:15:17:8a:8f:d2  UHLl
  00 - 1 em0
2a01:e35:8aee:3fb1:215:17ff:fe8a:8fd2 00:15:17:8a:8f:d2
UHLl   00 - 1 em0
2a01:e35:8aee:3fb1:dc59:37be:5b19:dd1b 00:15:17:8a:8f:d2
UHLl   0 4886 - 1 em0
fe80::/10  ::1UGRS
  01 32768 8 lo0
fe80::%em0/64  fe80::215:17ff:fe8a:8fd2%em0   UC
  15 - 4 em0
fe80::20d:b9ff:fe33:8e8c%em0   00:0d:b9:33:8e:8c  UHLc
  1 3313 - 4 em0
fe80::215:17ff:fe8a:8fd2%em0   00:15:17:8a:8f:d2  UHLl
  0  384 - 1 em0
fe80::1%lo0fe80::1%lo0UHl
  00 32768 1 lo0
fec0::/10  ::1UGRS
  00 32768 8 lo0
ff01::/16  ::1UGRS
  01 32768 8 lo0
ff01::%em0/32  fe80::215:17ff:fe8a:8fd2%em0   UC
  03 - 4 em0
ff01::%lo0/32  ::1UC
  01 32768 4 lo0
ff02::/16  ::1UGRS
  01 32768 8 lo0
ff02::%em0/32  fe80::215:17ff:fe8a:8fd2%em0   UC
  03 - 4 em0
ff02::%lo0/32      ::1UC
  01 32768 4 lo0


-- 
Mattieu Baptiste
"/earth is 102% full ... please delete anyone you can."



Re: KASSERT() @ pf_test() is back

2016-03-06 Thread Mattieu Baptiste
On Sun, Mar 6, 2016 at 11:33 PM, Martin Pieuchot <m...@openbsd.org> wrote:
> On 06/03/16(Sun) 22:35, Mattieu Baptiste wrote:
>> On Sun, Mar 6, 2016 at 10:22 PM, Martin Pieuchot <m...@openbsd.org> wrote:
>> > On 06/03/16(Sun) 19:57, Mattieu Baptiste wrote:
>> >> [...]
>> >> As discussed in january, with the patches committed, -current still
>> >> panics for me:
>> >> http://www.brimbelle.org/mattieu/stuff/panic_statekey/panic10.jpg
>> >> http://www.brimbelle.org/mattieu/stuff/panic_statekey/panic11.jpg
>> >> http://www.brimbelle.org/mattieu/stuff/panic_statekey/panic12.jpg
>> >>
>> >> Here is a dmesg from the last time I built a kernel, before the
>> >> patches were committed:
>> >
>> > Could you also paste the content of your /etc/hostname.* and "route -n 
>> > show"
>> > for this system?
>>
>> Yes, sure:
>>
>> $ cat /etc/hostname.bridge0
>> add em0
>> add re0
>> up
>
> Hahaha, my favorite!  Could you try the diff below and tell me if it
> helps?

Sorry, it panics again:
https://www.brimbelle.org/mattieu/stuff/panic_statekey/panic13.jpg


-- 
Mattieu Baptiste
"/earth is 102% full ... please delete anyone you can."



Re: KASSERT() @ pf_test() is back

2016-03-06 Thread Mattieu Baptiste
On Fri, Mar 4, 2016 at 2:31 PM, Alexandr Nedvedicky
 wrote:
> Hello Stuart,
>
> thanks for testing it. I'll commit it today.
>

Hi Alexandr,
As discussed in january, with the patches committed, -current still
panics for me:
http://www.brimbelle.org/mattieu/stuff/panic_statekey/panic10.jpg
http://www.brimbelle.org/mattieu/stuff/panic_statekey/panic11.jpg
http://www.brimbelle.org/mattieu/stuff/panic_statekey/panic12.jpg

Here is a dmesg from the last time I built a kernel, before the
patches were committed:
OpenBSD 5.9 (GENERIC.MP) #41: Thu Feb 11 22:18:29 CET 2016
matt...@kronenbourg.brimbelle.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8571518976 (8174MB)
avail mem = 8307548160 (7922MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf0710 (68 entries)
bios0: vendor American Megatrends Inc. version "2003" date 12/14/2010
bios0: ASUSTeK Computer INC. P7P55D
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET DMAR ASPT OSFR
acpi0: wakeup devices P0P4(S4) BR1E(S4) UAR1(S4) PS2K(S4) PS2M(S4)
EUSB(S4) USB0(S4) USB1(S4) USB2(S4) USB3(S4) USBE(S4) USB4(S4)
USB5(S4) USB6(S4) BR21(S4) BR22(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5 CPU 660 @ 3.33GHz, 3374.41 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 160MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 4 (application processor)
cpu1: Intel(R) Core(TM) i5 CPU 660 @ 3.33GHz, 3373.89 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 2, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i5 CPU 660 @ 3.33GHz, 3373.89 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 5 (application processor)
cpu3: Intel(R) Core(TM) i5 CPU 660 @ 3.33GHz, 3373.90 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 2, package 0
ioapic0 at mainbus0: apid 6 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 1, remapped to apid 6
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 7 (BR1E)
acpiprt2 at acpi0: bus -1 (BR21)
acpiprt3 at acpi0: bus -1 (BR22)
acpiprt4 at acpi0: bus -1 (BR23)
acpiprt5 at acpi0: bus 1 (P0P1)
acpiprt6 at acpi0: bus -1 (P0P3)
acpiprt7 at acpi0: bus -1 (P0P5)
acpiprt8 at acpi0: bus -1 (P0P6)
acpiprt9 at acpi0: bus 6 (BR20)
acpiprt10 at acpi0: bus 5 (BR24)
acpiprt11 at acpi0: bus 4 (BR25)
acpiprt12 at acpi0: bus 3 (BR26)
acpiprt13 at acpi0: bus 2 (BR27)
acpiec0 at acpi0
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
acpicpu2 at acpi0: C1(@1 halt!)
acpicpu3 at acpi0: C1(@1 halt!)
aibs0 at acpi0 GGRP GITM SITM
acpibtn0 at acpi0: PWRB
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core Host" rev 0x12
ppb0 at pci0 dev 1 function 0 "Intel Core PCIE" rev 0x12: msi
pci1 at ppb0 bus 1
radeondrm0 at pci1 dev 0 function 0 "ATI Radeon HD 4670" rev 0x00
drm0 at radeondrm0
radeondrm0: msi
azalia0 at pci1 dev 0 function 1 "ATI Radeon HD 4000 HD Audio" rev 0x00: msi
azalia0: no supported codecs
ehci0 at pci0 dev 26 function 0 "Intel 3400 USB" rev 0x06: apic 6 int 16
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
azalia1 at pci0 dev 27 function 0 "Intel 3400 HD Audio" rev 0x06: msi
azalia1: codecs: VIA/0x4441
audio0 at azalia1
ppb1 at pci0 dev 28 function 0 "Intel 3400 PCIE" rev 0x06: msi
pci2 at ppb1 bus 6
em0 at pci2 dev 0 function 0 "Intel 82571EB" rev 0x06: apic 6 int 16,
address 00:15:17:8a:8f:d2
em1 at pci2 dev 0 function 1 "Intel 82571EB" rev 0x06: apic 6 int 17,
address 00:15:17:8a:8f:d3
ppb2 at pci0 

Re: arm: pmap uvm_fault findings

2016-07-27 Thread Mattieu Baptiste
> So, I found a suspicious place, added printfs, triggered the bug again
> and voila, I think I got it.

[...]

> There are more places in that pmap where we explicitly check for zero
> and not for being valid.  Unfortunately this place was missed.
>
> Patrick
>
> diff --git a/sys/arch/arm/arm/pmap7.c b/sys/arch/arm/arm/pmap7.c
> index 0d32bf9..e965c48 100644
> --- a/sys/arch/arm/arm/pmap7.c
> +++ b/sys/arch/arm/arm/pmap7.c
> @@ -1155,7 +1155,7 @@ pmap_page_remove(struct vm_page *pg)
> KDASSERT(l2b != NULL);
>
> ptep = >l2b_kva[l2pte_index(pv->pv_va)];
> -   if (l2pte_valid(*ptep)) {
> +   if (*ptep != 0) {
> pte = *ptep;
>
> /* inline pmap_is_current(pm) */
>

With this patch, my BBB no longer trigers uvm_fault in trying to
compile arm-none-eabi-gcc-linaro.

-- 
Mattieu Baptiste
"/earth is 102% full ... please delete anyone you can."