Feature request: hostname.default

[Lars Engblom]

When needing to move a disk over from one computer to another, you quite 
often end up with hostname.X having the wrong name. Often it can be 
difficult to know what the interface will be called before booting up 
openbsd. As many servers are just accessable with ssh (and not through 
keyboard and screen) this is causing some problem at migrations.


Please consider to add support for a hostname.default. If no hostname.X 
is matching the interface, this file would be used as last resource 
before giving up configuring the interface.

Re: Feature request: hostname.default

[Stefan Sperling]

On Wed, Nov 12, 2014 at 10:11:23AM +0200, Lars Engblom wrote:
> Please consider to add support for a hostname.default. If no hostname.X is
> matching the interface, this file would be used as last resource before
> giving up configuring the interface.

Before configuring _which_ interface?

Re: Freeze when coredump in unexistant directory in tmpfs

[Pedro Martelletto]

hi!

the fix consists of disallowing file allocations on directories that
have been removed (tn_links == 0). failure to enforce such a check can
lead to the violation of the assumption that removed directories should
not contain directory entries -- thus the triggered assertion:

http://ambientworks.net/tmp/tmpfs_alloc_file.diff 


thanks for the report!

-p.

> On 11 Nov 2014, at 13:34, Peter J. Philipp  wrote:
> 
> On Tue, Nov 11, 2014 at 12:02:57PM +0100, S??bastien Marie wrote:
>> Hi,
>> 
>> I run -current on amd64.
>> 
>> When a program generate a coredump in unexistant directory (cwd before
>> rmdir) in a tmpfs mount, my system freeze.
>> 
>> Under a tmpfs mount-point:
>> 
>> $ cat coreme.c
>> #include 
>> 
>> int main()
>> {
>>  abort();
>> }
>> 
>> $ cc -o coreme coreme.c
>> $ mkdir testdir
>> $ cd testdir
>> $ D="${PWD%testdir}"
>> $ rmdir "$PWD"
>> $ $D/coreme
>> $ cd
>> ### freeze ###
>> 
>> The freeze occurs only on tmpfs directory (ffs was tested, and seems not 
>> affected).
>> 
>> Thanks.
>> -- 
>> S??bastien Marie
> 
> Splendid you found the panic condition that I lost the panic string to and
> reported in another thread.  It looks almost exactly similar.  Your system
> is panic'ing not freezeing up, only it doesn't switch into DDB from X on 
> your system.  I have made the work for you by photographing the panic strings
> and converting them to ascii.
> 
> http://americas.centroid.eu/private/tmpfs-panic/IMG_0740.JPG
> http://americas.centroid.eu/private/tmpfs-panic/IMG_0741.JPG
> http://americas.centroid.eu/private/tmpfs-panic/IMG_0742.JPG
> http://americas.centroid.eu/private/tmpfs-panic/IMG_0743.JPG
> http://americas.centroid.eu/private/tmpfs-panic/IMG_0744.JPG
> http://americas.centroid.eu/private/tmpfs-panic/IMG_0745.JPG
> http://americas.centroid.eu/private/tmpfs-panic/IMG_0746.JPG
> http://americas.centroid.eu/private/tmpfs-panic/IMG_0747.JPG
> http://americas.centroid.eu/private/tmpfs-panic/panic-backtrace.txt
> 
> here then the backtrace and dmesg of my system (It's 5.6-stable).
> 
> panic: kernel diagnostic assertion 
> "TAILQ_EMPTY(&node->tn_spec.tn_dir.tn_dir)" f
> ailed: file "../../../../tmpfs/tmpfs_subr.c", line 256
> Stopped at Debugger+0x9: leave
> 
> ddb{4}> tr
> Debugger() at Debugger+0x9
> panic() at panic+0xfe
> __assert() at __assert+0x25
> tmpfs_free_node() at tmpfs_free_node+0x16d
> tmpfs_reclaim() at tmpfs_reclaim+0x8a
> VOP_RECLAIM() at VOP_RECLAIM+0x38
> vclean() at vclean+0x8d
> vgonel() at vgonel+0x40
> vrecycle() at vrecycle+0x1a
> tmpfs_inactive at tmpfs_inactive+0x6c
> VOP_INACTIVE() at VOP_INACTIVE+0x35
> vrele() at vrele+0x65
> sys_chdir() at sys_chdir+0x7c
> syscall() at syscall+0x297
> --- syscall (number 12) ---
> end trace frame: 0x0, count: -14
> acpi_pdirpa+0x418fda:
> ddb{4}
> 
> 
> Thanks!
> 
> -peter
> 
> OpenBSD 5.6 (MERCURY.MP) #0: Sat Nov  1 12:18:31 CET 2014
>r...@mercury.centroid.eu:/usr/src/sys/arch/amd64/compile/MERCURY.MP
> real mem = 34006806528 (32431MB)
> avail mem = 33092767744 (31559MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec1f0 (91 entries)
> bios0: vendor American Megatrends Inc. version "1504" date 10/04/2013
> bios0: ASUS All Series
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC FPDT LPIT SSDT SSDT MCFG HPET SSDT SSDT BGRT
> acpi0: wakeup devices PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) 
> PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) 
> PXSX(S4) RP08(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) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3498.46 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,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM
> 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.2.4, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3497.98 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,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (application proc

Re: Freeze when coredump in unexistant directory in tmpfs

[David Coppa]

On Wed, Nov 12, 2014 at 10:21 AM, Pedro Martelletto
 wrote:
> hi!
>
> the fix consists of disallowing file allocations on directories that
> have been removed (tn_links == 0). failure to enforce such a check can
> lead to the violation of the assumption that removed directories should
> not contain directory entries -- thus the triggered assertion:
>
> http://ambientworks.net/tmp/tmpfs_alloc_file.diff 
> 
>
> thanks for the report!
>
> -p.

Please, someone should commit this to our tree...

Ciao,
David
-- 
"If you try a few times and give up, you'll never get there. But if
you keep at it... There's a lot of problems in the world which can
really be solved by applying two or three times the persistence that
other people will."
-- Stewart Nelson

Re: Envy driver halts while playback with M-Audio Audiophile 2496

[Alexandre Ratchov]

On Sat, Nov 08, 2014 at 02:00:15AM +0200, Veikko wrote:
> Hello,
> 
> I have a M-Audio Audiophile 2496 audiocard which I use with the envy driver.
> 
> The problem is that frequently (every 20 mins or so) while
> playback the audio seizes in a sample.
> 
> After the seize, this shows in the system message buffer:
> 
> envy0: input DMA halt timeout
> envy0: output DMA halt timeout
> 
> I'm able to stop the freeze with "audioctl play.rate=48000".
> 

Hi,

Do you suspend/resume the machine? Besindes envy hanging, to these
20 mins correspond to something else? any power-management setting
or similar?

Do the hangs occur if you use the GENERIC kernel (not MP)?

-- Alexandre

Re: Feature request: hostname.default

[Stefan Sperling]

On Wed, Nov 12, 2014 at 03:26:02PM +0200, Lars Engblom wrote:
> I guess you mean the case of having several network interfaces. Let all of
> the unconfigured interfaces get the IP settings from hostname.default and
> write this in the documentation. It is easier to plug in just one cable than
> having to guess all the names of the interfaces (em0, bge0, re0, rl0 etc).

One problem with this idea is that you can't have the same IP on multiple
interfaces and expect things to work.

A recent discussed on misc@ made this quite clear:
http://marc.info/?l=openbsd-misc&m=141564884907430&w=2

Re: Feature request: hostname.default

[Reyk Floeter]

On Wed, Nov 12, 2014 at 03:13:37PM +0100, Stefan Sperling wrote:
> On Wed, Nov 12, 2014 at 03:26:02PM +0200, Lars Engblom wrote:
> > I guess you mean the case of having several network interfaces. Let all of
> > the unconfigured interfaces get the IP settings from hostname.default and
> > write this in the documentation. It is easier to plug in just one cable than
> > having to guess all the names of the interfaces (em0, bge0, re0, rl0 etc).
> 
> One problem with this idea is that you can't have the same IP on multiple
> interfaces and expect things to work.
> 

You can put every interface in a different rdomain and use the same IPv4
address (but sshd would only listen on rdomain 0 by default).

You can have the same scoped IPv6 address on multiple interfaces.

> A recent discussed on misc@ made this quite clear:
> http://marc.info/?l=openbsd-misc&m=141564884907430&w=2
> 

;)

Reyk

Re: Feature request: hostname.default

[rjc]

On Wed, Nov 12, 2014 at 09:13:37AM EST, Stefan Sperling wrote:

> On Wed, Nov 12, 2014 at 03:26:02PM +0200, Lars Engblom wrote:
>
> > I guess you mean the case of having several network interfaces. Let
> > all of the unconfigured interfaces get the IP settings from
> > hostname.default and write this in the documentation. It is easier
> > to plug in just one cable than having to guess all the names of the
> > interfaces (em0, bge0, re0, rl0 etc).
>
> One problem with this idea is that you can't have the same IP on
> multiple interfaces and expect things to work.
>
> A recent discussed on misc@ made this quite clear:
> http://marc.info/?l=openbsd-misc&m=141564884907430&w=2

The scope there was even broader:

PH> That is not supported.  You MUST NOT have IPs in the same range on
PH> different interfaces.

I think I know what the OP has in mind - having a "default" IP address
configuration which gets assigned to an interface where "media" is
present.

The only way I see this working is with only a single Ethernet adaptor
has the cable plugged in - otherwise it gets messy.

One way or another, this shouldn't be too difficult to script and run
from /etc/rc.firsttime.

rjc

Re: Feature request: hostname.default

[Stuart Henderson]

On 2014/11/12 09:49, rjc wrote:
> On Wed, Nov 12, 2014 at 09:13:37AM EST, Stefan Sperling wrote:
> 
> > On Wed, Nov 12, 2014 at 03:26:02PM +0200, Lars Engblom wrote:
> >
> > > I guess you mean the case of having several network interfaces. Let
> > > all of the unconfigured interfaces get the IP settings from
> > > hostname.default and write this in the documentation. It is easier
> > > to plug in just one cable than having to guess all the names of the
> > > interfaces (em0, bge0, re0, rl0 etc).
> >
> > One problem with this idea is that you can't have the same IP on
> > multiple interfaces and expect things to work.
> >
> > A recent discussed on misc@ made this quite clear:
> > http://marc.info/?l=openbsd-misc&m=141564884907430&w=2
> 
> The scope there was even broader:
> 
> PH> That is not supported.  You MUST NOT have IPs in the same range on
> PH> different interfaces.
> 
> I think I know what the OP has in mind - having a "default" IP address
> configuration which gets assigned to an interface where "media" is
> present.
> 
> The only way I see this working is with only a single Ethernet adaptor
> has the cable plugged in - otherwise it gets messy.

It's messy anyway. You have to know which are normal network adapters
and which are not - some obvious examples are enc0, pflog0, lo0

> One way or another, this shouldn't be too difficult to script and run
> from /etc/rc.firsttime.

Yep. Much better idea.

Re: Feature request: hostname.default

[Reyk Floeter]

On Wed, Nov 12, 2014 at 03:10:01PM +, Stuart Henderson wrote:
> On 2014/11/12 09:49, rjc wrote:
> > On Wed, Nov 12, 2014 at 09:13:37AM EST, Stefan Sperling wrote:
> > 
> > > On Wed, Nov 12, 2014 at 03:26:02PM +0200, Lars Engblom wrote:
> > >
> > > > I guess you mean the case of having several network interfaces. Let
> > > > all of the unconfigured interfaces get the IP settings from
> > > > hostname.default and write this in the documentation. It is easier
> > > > to plug in just one cable than having to guess all the names of the
> > > > interfaces (em0, bge0, re0, rl0 etc).
> > >
> > > One problem with this idea is that you can't have the same IP on
> > > multiple interfaces and expect things to work.
> > >
> > > A recent discussed on misc@ made this quite clear:
> > > http://marc.info/?l=openbsd-misc&m=141564884907430&w=2
> > 
> > The scope there was even broader:
> > 
> > PH> That is not supported.  You MUST NOT have IPs in the same range on
> > PH> different interfaces.
> > 
> > I think I know what the OP has in mind - having a "default" IP address
> > configuration which gets assigned to an interface where "media" is
> > present.
> > 
> > The only way I see this working is with only a single Ethernet adaptor
> > has the cable plugged in - otherwise it gets messy.
> 
> It's messy anyway.

I agree but...

> You have to know which are normal network adapters
> and which are not - some obvious examples are enc0, pflog0, lo0
> 

...any interface that is not listed by 'ifconfig -C'.

> > One way or another, this shouldn't be too difficult to script and run
> > from /etc/rc.firsttime.
> 
> Yep. Much better idea.
> 

Reyk

Re: Feature request: hostname.default

[Ted Unangst]

On Wed, Nov 12, 2014 at 10:11, Lars Engblom wrote:
> When needing to move a disk over from one computer to another, you quite
> often end up with hostname.X having the wrong name. Often it can be
> difficult to know what the interface will be called before booting up
> openbsd. As many servers are just accessable with ssh (and not through
> keyboard and screen) this is causing some problem at migrations.
> 
> Please consider to add support for a hostname.default. If no hostname.X
> is matching the interface, this file would be used as last resource
> before giving up configuring the interface.

You can fake this yourself by creating a hostname.vether0 that shells
out to whatever script you like, which will then configure the system.

urtwn(4) is unstable

[S]

Synopsis:   urtwn(4) is unstable
Category:   kernel
Environment:

System  : OpenBSD 5.6
Details : OpenBSD 5.6-current (GENERIC.MP) #555: Wed Nov 12 
00:58:05 MST 2014
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64

Description:

When using the snapshot from November 2 and 5.5, my ASUS USB-N10 using
the urtwn(4) driver would stop working after a reboot (halt -p then
power on caused no problems).
After upgrading to the November 12 snapshot, I found that it stopped
working after a cold boot during a package upgrade, and again while
browsing the web.
"urtwn0: device timeout" appears in dmesg and the status LED on the
device turns off until netstart is run again.

How-To-Repeat:

Reboot with device attached.

Fix:

Remove and re-attach device, then run sh /etc/netstart.

dmesg:
OpenBSD 5.6-current (GENERIC.MP) #555: Wed Nov 12 00:58:05 MST 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4174360576 (3980MB)
avail mem = 4059410432 (3871MB)
warning: no entropy supplied by boot loader
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe6fd0 (59 entries)
bios0: vendor LENOVO version "78CN25WW(V2.03)" date 11/19/2013
bios0: LENOVO 20236
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC UEFI ASF! HPET APIC MCFG SSDT BOOT ASPT DBGP FPDT 
MSDM SSDT SSDT
acpi0: wakeup devices P0P1(S0) EHC1(S3) EHC2(S3) XHC_(S3) HDEF(S0) PXSX(S3) 
PXSX(S3) PXSX(S3) PXSX(S3) PXSX(S3) RP05(S0) PXSX(S3) RP06(S0) PXSX(S3) 
RP07(S0) PXSX(S3) [...]
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) i3-3110M CPU @ 2.40GHz, 2394.90 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i3-3110M CPU @ 2.40GHz, 2394.56 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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) i3-3110M CPU @ 2.40GHz, 2394.56 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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) i3-3110M CPU @ 2.40GHz, 2394.56 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf000, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 1 (RP01)
acpiprt3 at acpi0: bus 2 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus -1 (RP04)
acpiprt6 at acpi0: bus -1 (RP05)
acpiprt7 at acpi0: bus -1 (RP06)
acpiprt8 at acpi0: bus -1 (RP07)
acpiprt9 at acpi0: bus -1 (RP08)
acpiprt10 at acpi0: bus -1 (PEG0)
acpiprt11 at acpi0: bus -1 (PEG1)
acpiprt12 at acpi0: bus -1 (PEG2)
acpiprt13 at acpi0: bus -1 (PEG3)
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
acpitz0 at acpi0: critical temperature is 127 degC
acpibtn0 at acpi0: PWRB
acpibat0 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit online
acpibtn1 at acpi0: LID0
acpivideo0 at acpi0: VGA_
acpivideo1 at acpi0: VGA_
acpivideo2 at acpi0: GFX0
acpivout0 at acpivideo2: DD02
cpu0: Enhanced SpeedStep 2394 MHz: speeds: 2400, 2300, 2200, 2100, 2000, 1900, 
1800, 1700, 1600, 1500, 1400, 1300, 1200 MHz
pci0 at mainbus0 bus

Re: urtwn(4) is unstable

[Stefan Sperling]

On Wed, Nov 12, 2014 at 05:36:26PM +, S wrote:
> >Synopsis:urtwn(4) is unstable
> >Category:kernel
> >Environment:
>   System  : OpenBSD 5.6
>   Details : OpenBSD 5.6-current (GENERIC.MP) #555: Wed Nov 12 
> 00:58:05 MST 2014
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   When using the snapshot from November 2 and 5.5, my ASUS USB-N10 using
>   the urtwn(4) driver would stop working after a reboot (halt -p then
>   power on caused no problems).
>   After upgrading to the November 12 snapshot, I found that it stopped
>   working after a cold boot during a package upgrade, and again while
>   browsing the web.
>   "urtwn0: device timeout" appears in dmesg and the status LED on the
>   device turns off until netstart is run again.

xhci(4) might factor in here.
See http://undeadly.org/cgi?action=article&sid=20141110153505

> xhci0 at pci0 dev 20 function 0 "Intel 7 Series xHCI" rev 0x04: msi
> usb0 at xhci0: USB revision 3.0
> uhub0 at usb0 "Intel xHCI root hub" rev 3.00/1.00 addr 1

> urtwn0 at uhub0 port 2 "Realtek 802.11n WLAN Adapter" rev 2.00/2.00 addr 3
> urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R, address 10:c3:7b:c8:2c:55

Re: urtwn(4) is unstable

[S]

On 11/12/14 18:09, Stefan Sperling wrote:

On Wed, Nov 12, 2014 at 05:36:26PM +, S wrote:

Synopsis:   urtwn(4) is unstable
Category:   kernel
Environment:

System  : OpenBSD 5.6
Details : OpenBSD 5.6-current (GENERIC.MP) #555: Wed Nov 12 
00:58:05 MST 2014
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64

Description:

When using the snapshot from November 2 and 5.5, my ASUS USB-N10 using
the urtwn(4) driver would stop working after a reboot (halt -p then
power on caused no problems).
After upgrading to the November 12 snapshot, I found that it stopped
working after a cold boot during a package upgrade, and again while
browsing the web.
"urtwn0: device timeout" appears in dmesg and the status LED on the
device turns off until netstart is run again.

xhci(4) might factor in here.
See http://undeadly.org/cgi?action=article&sid=20141110153505


xhci0 at pci0 dev 20 function 0 "Intel 7 Series xHCI" rev 0x04: msi
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 "Intel xHCI root hub" rev 3.00/1.00 addr 1
urtwn0 at uhub0 port 2 "Realtek 802.11n WLAN Adapter" rev 2.00/2.00 addr 3
urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R, address 10:c3:7b:c8:2c:55



Yes, that's quite likely. My bug report may have been a bit early since 
I'm now seeing a similar problem with my USB mouse where it stops 
working at seemingly random times until it is re-attached.

Re: urtwn(4) is unstable

[S]

On 11/12/14 18:18, S wrote:
Yes, that's quite likely. My bug report may have been a bit early 
since I'm now seeing a similar problem with my USB mouse where it 
stops working at seemingly random times until it is re-attached.


Follow-up, dmesg with XHCI_DEBUG (sorry for the delay):

OpenBSD 5.6-current (GENERIC.MP) #555: Wed Nov 12 00:58:05 MST 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4174360576 (3980MB)
avail mem = 4059410432 (3871MB)
warning: no entropy supplied by boot loader
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe6fd0 (59 entries)
bios0: vendor LENOVO version "78CN25WW(V2.03)" date 11/19/2013
bios0: LENOVO 20236
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC UEFI ASF! HPET APIC MCFG SSDT BOOT ASPT DBGP FPDT 
MSDM SSDT SSDT
acpi0: wakeup devices P0P1(S0) EHC1(S3) EHC2(S3) XHC_(S3) HDEF(S0) PXSX(S3) 
PXSX(S3) PXSX(S3) PXSX(S3) PXSX(S3) RP05(S0) PXSX(S3) RP06(S0) PXSX(S3) 
RP07(S0) PXSX(S3) [...]
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) i3-3110M CPU @ 2.40GHz, 2394.90 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i3-3110M CPU @ 2.40GHz, 2394.56 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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) i3-3110M CPU @ 2.40GHz, 2394.56 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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) i3-3110M CPU @ 2.40GHz, 2394.56 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf000, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 1 (RP01)
acpiprt3 at acpi0: bus 2 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus -1 (RP04)
acpiprt6 at acpi0: bus -1 (RP05)
acpiprt7 at acpi0: bus -1 (RP06)
acpiprt8 at acpi0: bus -1 (RP07)
acpiprt9 at acpi0: bus -1 (RP08)
acpiprt10 at acpi0: bus -1 (PEG0)
acpiprt11 at acpi0: bus -1 (PEG1)
acpiprt12 at acpi0: bus -1 (PEG2)
acpiprt13 at acpi0: bus -1 (PEG3)
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
acpitz0 at acpi0: critical temperature is 127 degC
acpibtn0 at acpi0: PWRB
acpibat0 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit online
acpibtn1 at acpi0: LID0
acpivideo0 at acpi0: VGA_
acpivideo1 at acpi0: VGA_
acpivideo2 at acpi0: GFX0
acpivout0 at acpivideo2: DD02
cpu0: Enhanced SpeedStep 2394 MHz: speeds: 2400, 2300, 2200, 2100, 2000, 1900, 
1800, 1700, 1600, 1500, 1400, 1300, 1200 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 3G Host" rev 0x09
vga1 at pci0 dev 2 function 0 "Intel HD Graphics 4000" rev 0x09
intagp at vga1 not configured
inteldrm0 at vga1
drm0 at inteldrm0
drm: Memory usable by graphics device = 2048M
inteldrm0: 1366x768
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
xhci0 at pci0 dev 20 function 0 "Intel 7 Series xHCI" rev 0x04: msi
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 "Intel xHCI root hub" rev 3.00/1.00 addr 1
"Intel 7 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured
ehci0 at pci0 dev 26 function 0 "Intel 7 Series USB" rev 0x04: apic 0 int 16
ehci0: timed out waiting for BIOS
usb1 at ehci0: 

Re: Feature request: hostname.default

[Lars Engblom]

On 11/12/2014 11:19 AM, Stefan Sperling wrote:

On Wed, Nov 12, 2014 at 10:11:23AM +0200, Lars Engblom wrote:

Please consider to add support for a hostname.default. If no hostname.X is
matching the interface, this file would be used as last resource before
giving up configuring the interface.

Before configuring _which_ interface?


I guess you mean the case of having several network interfaces. Let all 
of the unconfigured interfaces get the IP settings from hostname.default 
and write this in the documentation. It is easier to plug in just one 
cable than having to guess all the names of the interfaces (em0, bge0, 
re0, rl0 etc).


After the first boot one can easily find out the names with ifconfig and 
then for example 'mv /etc/hostname.default /etc/hostname.em0'

Re: Feature request: hostname.default

[Theo de Raadt]

> On 11/12/2014 11:19 AM, Stefan Sperling wrote:
> > On Wed, Nov 12, 2014 at 10:11:23AM +0200, Lars Engblom wrote:
> >> Please consider to add support for a hostname.default. If no hostname.X is
> >> matching the interface, this file would be used as last resource before
> >> giving up configuring the interface.
> > Before configuring _which_ interface?
>
> I guess you mean the case of having several network interfaces. Let all 
> of the unconfigured interfaces get the IP settings from hostname.default 
> and write this in the documentation. It is easier to plug in just one 
> cable than having to guess all the names of the interfaces (em0, bge0, 
> re0, rl0 etc).
>
> After the first boot one can easily find out the names with ifconfig and 
> then for example 'mv /etc/hostname.default /etc/hostname.em0'

Two paragraphs written without any critical thought.

We won't be doing that...