Re: cu connection trap "crash"

2015-08-09 Thread Dan Becker
On Sat, Aug 8, 2015 at 9:20 PM, Philip Guenther  wrote:

> On Sat, Aug 8, 2015 at 3:36 PM, Dan Becker  wrote:
> >> On Saturday, August 8, 2015, Dan Becker  wrote:
> >>>
> >>> When connecting to a serial port with a usb to serial adapter.
> Unplugging
> >>> the usb connection without closing the session causes my system to drop
> >>> to ddb.
> ...
> > $ cat /var/run/dmesg.boot
> > OpenBSD 5.7 (GENERIC.MP) #881: Sun Mar  8 11:04:17 MDT 2015
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> I'm 98% certain that this was fixed in April or so, and thus fixed in
> -current and will be fixed in 5.8.
>
> If not, well, it's now too late to debug and fix it before 5.8 is
> frozen.  So, you should upgrade to 5.8 soon after it comes out and
> verify whether this is resolved there.  If not, report it again then,
> with fresh dmesg and backtrace, so that it can be addressed when
> there's time in the 5.9 cycle...
>
>
> Philip Guenther
>


Will do.

-- 
--Dan



Re: cu connection trap "crash"

2015-08-08 Thread Philip Guenther
On Sat, Aug 8, 2015 at 3:36 PM, Dan Becker  wrote:
>> On Saturday, August 8, 2015, Dan Becker  wrote:
>>>
>>> When connecting to a serial port with a usb to serial adapter. Unplugging
>>> the usb connection without closing the session causes my system to drop
>>> to ddb.
...
> $ cat /var/run/dmesg.boot
> OpenBSD 5.7 (GENERIC.MP) #881: Sun Mar  8 11:04:17 MDT 2015
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

I'm 98% certain that this was fixed in April or so, and thus fixed in
-current and will be fixed in 5.8.

If not, well, it's now too late to debug and fix it before 5.8 is
frozen.  So, you should upgrade to 5.8 soon after it comes out and
verify whether this is resolved there.  If not, report it again then,
with fresh dmesg and backtrace, so that it can be addressed when
there's time in the 5.9 cycle...


Philip Guenther



Re: cu connection trap "crash"

2015-08-08 Thread Dan Becker
On Sat, Aug 8, 2015 at 2:12 PM, Philip Guenther  wrote:

> On Saturday, August 8, 2015, Dan Becker  wrote:
>
>> When connecting to a serial port with a usb to serial adapter. Unplugging
>> the usb connection without closing the session causes my system to drop to
>> ddb.
>>
>> Can someone else try to verify this ?
>>
>> No flags, simply 'cu /dev/cuaU0 '
>>
>> http://1drv.ms/1Dy9w4J
>>
>> ddb screenie ^
>
>
> dmesg?
>
>

inline... disk wasn't mounted properly because this is probably the 4th
time I repeated the process to make sure I could :)


$ cat
/var/run/dmesg.boot
OpenBSD 5.7 (GENERIC.MP) #881: Sun Mar  8 11:04:17 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4160286720 (3967MB)
avail mem = 4045619200 (3858MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xfb4c0 (43 entries)
bios0: vendor FUJITSU // Phoenix Technologies Ltd. version "Version 1.15"
date 07/05/2011
bios0: FUJITSU LIFEBOOK S751
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC SSDT SSDT HPET APIC MCFG ASF! TCPA SSDT SSDT
UEFI UEFI UEFI
acpi0: wakeup devices UAR1(S3) HDEF(S4) PCE0(S4) PCE3(S3) GLAN(S4) LID_(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2494.69 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,A
ES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
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 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2494.34 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,A
ES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2494.34 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,A
ES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2494.34 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,A
ES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P2)
acpiprt2 at acpi0: bus 1 (PCE0)
acpiprt3 at acpi0: bus 10 (PCE2)
acpiprt4 at acpi0: bus 11 (PCE3)
acpiprt5 at acpi0: bus 12 (PCE7)
acpiec0 at acpi0
acpicpu0 at acpi0: C2, C1, PSS
acpicpu1 at acpi0: C2, C1, PSS
acpicpu2 at acpi0: C2, C1, PSS
acpicpu3 at acpi0: C2, C1, PSS
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: CMB1 model "CP483691-01" serial 02A-Z110813001293Z type
LION oem "Fujitsu"
acpibat1 at acpi0: CMB2 not present
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: PWRB
acpibtn2 at acpi0: SLPB
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: LCD_
cpu0: Enhanced SpeedStep 2494 MHz: speeds: 2501, 2500, 2000, 1800, 1600,
1400, 1200, 1000, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 2G Host" rev 0x09
vga1 at pci0 dev 2 function 0 "Intel HD Graphics 3000" rev 0x09
intagp at vga1 not configured
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: 1366x768
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel 6 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured
puc0 at pci0 dev 22 function 3 "Intel 6 Series KT" rev 0x04: ports: 1 com
com4 at puc0 port 0 apic 2 int 19: ns16550a, 16 byte fifo
com4: probed fifo depth: 0 bytes
em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x04: msi, address
b0:99:28:cb:b6:d3
ehci0 at pci0 dev 26 function 0 "Intel 6 Series USB" rev 0x04: apic 2 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
azalia0 at pci0 dev 2

Re: cu connection trap "crash"

2015-08-08 Thread Dan Becker
On Sat, Aug 8, 2015 at 2:12 PM, Philip Guenther  wrote:

> On Saturday, August 8, 2015, Dan Becker  wrote:
>
>> When connecting to a serial port with a usb to serial adapter. Unplugging
>> the usb connection without closing the session causes my system to drop to
>> ddb.
>>
>> Can someone else try to verify this ?
>>
>> No flags, simply 'cu /dev/cuaU0 '
>>
>> http://1drv.ms/1Dy9w4J
>>
>> ddb screenie ^
>
>
> dmesg?
>
>
Attachment

-- 
--Dan

[demime 1.01d removed an attachment of type application/octet-stream which had 
a name of dmesg.boot]



Re: cu connection trap "crash"

2015-08-08 Thread Philip Guenther
On Saturday, August 8, 2015, Dan Becker  wrote:

> When connecting to a serial port with a usb to serial adapter. Unplugging
> the usb connection without closing the session causes my system to drop to
> ddb.
>
> Can someone else try to verify this ?
>
> No flags, simply 'cu /dev/cuaU0 '
>
> http://1drv.ms/1Dy9w4J
>
> ddb screenie ^


dmesg?



cu connection trap "crash"

2015-08-08 Thread Dan Becker
When connecting to a serial port with a usb to serial adapter. Unplugging
the usb connection without closing the session causes my system to drop to
ddb.

Can someone else try to verify this ?

No flags, simply 'cu /dev/cuaU0 '

http://1drv.ms/1Dy9w4J

ddb screenie ^

-- 
--Dan