Re: dmesg (current) MacBook Air 5,2 (2012) Intel 1.8
On 10/09/15(Thu) 14:40, Aaron Poffenberger wrote: > [...] > Sorry for the delay. It's error 15: > urtwn0: could not load firmware page 1 (error 15) So it's not related to suspend/resume it appears to be a xhci issue. Could you try connecting it on a ehci (non blue) port?
ntpd -s, constraints, and date being far off
ntpd -s doesn't work with constraints when the date is too far off. At least that's my current hypothesis. Example from latest octeon snap: octeon:~$ doas date 201409112020 Thu Sep 11 20:20:00 CEST 2014 octeon:~$ doas ntpd -v -d -s ntp engine ready constraint request to 2a00:1450:4013:c00::69 constraint request to 216.58.211.100 tls failed: 2a00:1450:4013:c00::69: connect no constraint reply from 2a00:1450:4013:c00::69 received in time, next query 900s tls failed: 216.58.211.100: connect failed: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed no constraint reply from 216.58.211.100 received in time, next query 900s no reply received in time, skipping initial time setting ^Cntp engine exiting Terminating octeon:~$ doas vi /etc/ntpd.conf # <-- comment constraints line. octeon:~$ doas ntpd -v -d -s ntp engine ready reply from 46.165.212.205: offset 31536038.233497 delay 0.033760, next query 8s set local clock to Fri Sep 11 20:22:23 CEST 2015 (offset 31536038.233497s) reply from 78.47.254.155: offset 15768019.117504 delay 31536038.275234, next query 8s reply from 81.88.24.155: offset 15768019.106225 delay 31536038.277960, next query 7s reply from 85.10.246.234: offset 15768019.118702 delay 31536038.277447, next query 6s reply from 85.10.246.234: offset 0.002484 delay 0.039208, next query 6s reply from 81.88.24.155: offset -0.010518 delay 0.041345, next query 6s reply from 46.165.212.205: offset -0.000368 delay 0.032194, next query 8s reply from 78.47.254.155: offset 0.002271 delay 0.039435, next query 8s reply from 85.10.246.234: offset 0.002595 delay 0.039722, next query 9s reply from 81.88.24.155: offset -0.009674 delay 0.041825, next query 9s ^Cntp engine exiting octeon:~$ doas vi /etc/ntpd.conf # <- enable constraints, works like magic octeon:~$ doas ntpd -v -d -s ntp engine ready constraint request to 2a00:1450:4007:806::1012 constraint request to 216.58.211.100 tls failed: 2a00:1450:4007:806::1012: connect no constraint reply from 2a00:1450:4007:806::1012 received in time, next query 900s constraint reply from 216.58.211.100: offset -1.009538 reply from 87.230.95.114: offset -0.38 delay 0.033070, next query 8s set local clock to Fri Sep 11 20:30:23 CEST 2015 (offset -0.38s) reply from 129.70.132.34: offset 0.002208 delay 0.041274, next query 7s reply from 129.250.35.250: offset -0.003325 delay 0.040867, next query 6s reply from 5.100.133.221: offset 0.021947 delay 0.046111, next query 7s reply from 129.250.35.250: offset -0.002102 delay 0.035490, next query 6s reply from 129.70.132.34: offset 0.003127 delay 0.040334, next query 5s reply from 5.100.133.221: offset 0.022393 delay 0.046518, next query 5s reply from 87.230.95.114: offset -0.001053 delay 0.031630, next query 8s reply from 129.250.35.250: offset -0.000493 delay 0.035583, next query 6s reply from 129.70.132.34: offset 0.003118 delay 0.040750, next query 9s reply from 5.100.133.221: offset 0.022552 delay 0.045970, next query 9s ^Cntp engine exiting Terminating I'm not singling out octeon, it's just very noticeable there.
Re: dmesg (current) MacBook Air 5,2 (2012) Intel 1.8
On 09/11/15 08:54, Aaron Poffenberger wrote: On 09/11/15 04:12, Martin Pieuchot wrote: On 10/09/15(Thu) 14:40, Aaron Poffenberger wrote: [...] Sorry for the delay. It's error 15: urtwn0: could not load firmware page 1 (error 15) So it's not related to suspend/resume it appears to be a xhci issue. Could you try connecting it on a ehci (non blue) port? I hadn't noticed the xhci ports in the dmesg. I always believed it to be an early 2012 model with USB 2.0. According to the specs online both ports are 3.0. But the one I was using is a charging port, powered in sleep mode. I thought I tested this NIC in the unpowered port but perhaps that was the run0 I was trying (too small, no reception). After a couple of tries in the un-powered port the urtwn0 is restarting more reliably. I'll let it run that way today. Could also be a wonky port. Twice yesterday I had an axe0 plugged into the powered port for 10/100 access. Unplugged twice while running (no suspend) to ill effect. The first time the system rebooted, the second time it hung. Any thoughts? Could the fact it's powered have any impact? Apparently it's not the powered port. I just got error 15 with urtwn in the other USB port. Unfortunately this laptop doesn't expose any USB 2.0 ports for me to test with. Any further suggestions are welcome.
vlan related panic on Sept 9th snap
hello,
I have a setup with two carp nodes, I was replacing one of these with
new hardware (old was i386, new is amd64) and installed latest snapshot
and then copied over all the relevant files from the old node, changing
things which differed (vr -> em). I shut the old host down, and booted
the new host. Once it gets to starting network it panics. ddb led me to
believe it was vlan related, so I moved all hostname.* files out of the
way which were not related to the physical interfaces. At that point the
machine boots.
since the trace showed some arp things in the ddb trace I thought that
perhaps something was being cached somewhere, so on a whim I tried
incrementing the IP on one of the vlan interfaces by one in single user
mode and then doing sh /etc/netstart vlan666 all of a sudden it worked.
Thinking I'd solved it I did the same for all vlan interfaces and exited
single user mode, and it paniced. I tried a few more times, swapping IPs
or starting a vlan at a time, sometimes I'd get one up, once I even got
all vlans up in single user mode but when going multiuser it would
panic. My last attempt now even in single user mode it panics for each
vlan I try.
ddb info for two panics, ifconfig and hostname* files as well as a dmesg
below.
thanks,
.jh
First panic (during multiuser boot)
starting network
uvm_fault(0xff007f6d13c0, 0x8, 0, 2) -> e
kernel: page fault trap, code=0
Stopped at if_ref+0x8: lock incl 0x8(%rdi)
ddb{1}> ps
PID PPID PGRPUID S FLAGS WAIT COMMAND
*28769 12596 31290 0 7 0x3ifconfig
12596 31290 31290 0 30x8b pause sh
31290 1 31290 0 30x8b pause sh
19920 0 0 0 3 0x14200 pgzerozerothread
25482 0 0 0 3 0x14200 aiodoned aiodoned
13982 0 0 0 3 0x14200 syncerupdate
17550 0 0 0 3 0x14200 cleaner cleaner
31713 0 0 0 3 0x14200 reaperreaper
31674 0 0 0 3 0x14200 pgdaemon pagedaemon
2400 0 0 0 3 0x14200 bored crypto
23244 0 0 0 3 0x14200 pftm pfpurge
15871 0 0 0 3 0x14200 mmctsksdmmc1
3329 0 0 0 3 0x14200 mmctsksdmmc0
21406 0 0 0 3 0x14200 usbtskusbtask
15224 0 0 0 3 0x14200 usbatsk usbatsk
6868 0 0 0 3 0x40014200idle1
17764 0 0 0 3 0x14200 bored sensors
29990 0 0 0 3 0x14200 bored softnet
3936 0 0 0 3 0x14200 bored systqmp
26693 0 0 0 3 0x14200 bored systq
11761 0 0 0 7 0x40014200idle0
1 0 1 0 30x82 wait init
0 -1 0 0 3 0x10200 scheduler swapper
ddb{1}> trace
if_ref() at if_ref+0x8
vlan_start() at vlan_start+0x107
if_enqueue() at if_enqueue+0x11a
ether_output() at ether_output+0x16e
arprequest() at arprequest+0x11d
arp_rtrequest() at arp_rtrequest+0x154
rtrequest1() at rtrequest1+0x656
rt_ifa_add() at rt_ifa_add+0x10b
in_ifinit() at in_ifinit+0x101
in_control() at in_control+0x457
ifioctl() at ifioctl+0x175
sys_ioctl() at sys_ioctl+0x18b
syscall() at syscall+0x358
--- syscall (number 54) ---
end of kernel
end trace frame: 0x136f3db4f5c0, count: -13
0x136f3d915d6a:
ddb{1}> show registers
rdi0
rsi 0x7
rbp 0x80002125e820
rbx 0xff006f2c6c00
rdx0
rcx 0xff006f2c6c00
rax0
r8 0x608
r9 0x1
r10 0x1
r11 0x8120vlan_start
r12 0x8012e800
r13 0x3
r14 0x80073048
r15 0x8012e800
rip 0x811f3978if_ref+0x8
cs 0x8
rflags 0x10282__ALIGN_SIZE+0xf282
rsp 0x80002125e810
ss 0x10
if_ref+0x8: lock incl 0x8(%rdi)
A later panic while trying sh /etc/netstart vlan20 in single user mode
# sh /etc/netstart vlan20
uvm_fault(0xff007f6d12d0, 0x8, 0, 2) -> e
kernel: page fault trap, code=0
Stopped at if_ref+0x8: lock incl 0x8(%rdi)
ddb{0}> trace
if_ref() at if_ref+0x8
vlan_start() at vlan_start+0x107
if_enqueue() at if_enqueue+0x11a
ether_output() at ether_output+0x16e
arprequest() at arprequest+0x11d
arp_rtrequest() at arp_rtrequest+0x154
rtrequest1() at rtrequest1+0x656
rt_ifa_add() at rt_ifa_add+0x10b
in_ifinit() at in_ifinit+0x101
in_control() at
Extra keyboard keys not being recognized
System : OpenBSD 5.8 Machine : amd64 I'm trying to set the multimedia keys of my keyboard to de something. It have three simple keys with shutdown, internet and mail figures on it. It is a standard keyboard, a very simple one. First I tried to detect them using xev(1), but when I press the keys, nothing happens. Someone on irc, pointed me to try usbhidaction(1), and run usbhidctl to detect the keys. Running usbhidctl first made me note that sometimes the command fails, and gives: usbhidctl: USB_GET_REPORT (probably not supported by device): Bad address but when it works I get: Keyboard.Num_Lock=1 Keyboard.Caps_Lock=0 Keyboard.Scroll_Lock=0 Keyboard.Keyboard_LeftControl=0 Keyboard.Keyboard_LeftShift=0 Keyboard.Keyboard_LeftAlt=0 Keyboard.Keyboard_Left_GUI=0 Keyboard.Keyboard_RightControl=0 Keyboard.Keyboard_RightShift=0 Keyboard.Keyboard_RightAlt=0 Keyboard.Keyboard_Right_GUI=0 Keyboard.Keyboard_Return_(ENTER)=1 [0] Keyboard.No_Event=1 [1] Keyboard.No_Event=1 [2] Keyboard.No_Event=1 [3] Keyboard.No_Event=1 [4] Keyboard.No_Event=1 [5] So, where is the keys... In this process, I noted another bug that could be related(?), my Scroll Lock LED don't turn on, the key is recognized by xev(1) (... keycode 78 (keysym 0xff14, Scroll_Lock)...), and works well out of X, which means it is working but not by wsconsctĺ neither by usbhidctl, see: Only Caps_Lock on: $ usbhidctl -f /dev/wskbd | grep Lock Keyboard.Num_Lock=0 Keyboard.Caps_Lock=1 Keyboard.Scroll_Lock=0 $ wsconsctl | grep led keyboard.ledstate=1 Ok, Caps_Lock is good, now, only Num_Lock on: $ wsconsctl | grep led keyboard.ledstate=2 $ usbhidctl -f /dev/wskbd | grep Lock Keyboard.Num_Lock=1 Keyboard.Caps_Lock=0 Keyboard.Scroll_Lock=0 Why wsconsctl is detecting it as two keys? With Caps_Lock + Num_Lock on I get ledstate=3, as all the keys was on. Is these errors related? Can someone help me to solve? My keyboard wsconsctl related output: $ wsconsctl | grep keyboard keyboard.type=pc-xt keyboard.bell.pitch=400 keyboard.bell.period=100 keyboard.bell.volume=50 keyboard.bell.pitch.default=400 keyboard.bell.period.default=100 keyboard.bell.volume.default=50 keyboard.repeat.del1=400 keyboard.repeat.deln=100 keyboard.repeat.del1.default=400 keyboard.repeat.deln.default=100 keyboard.ledstate=2 keyboard.encoding=br keyboard1.type=usb keyboard1.bell.pitch=400 keyboard1.bell.period=100 keyboard1.bell.volume=50 keyboard1.bell.pitch.default=400 keyboard1.bell.period.default=100 keyboard1.bell.volume.default=50 keyboard1.repeat.del1=400 keyboard1.repeat.deln=100 keyboard1.repeat.del1.default=400 keyboard1.repeat.deln.default=100 keyboard1.ledstate=2 keyboard1.encoding=br So I have these strange behaviours with my keyboard, It also have some other little problem, it takes too much time to toggle Caps Lock when I'm in Xorg. This makes me think the problem is on X, at least the problem of Scroll Lock not working. Now the part of the extra multimedia keys, I can't guess... __ all the info attached, yon can also see it here: http://sprunge.us/KgLG Thanks, I would love any help... -- Regards Henrique Lengler
Re: dmesg (current) MacBook Air 5,2 (2012) Intel 1.8
On 09/11/15 04:12, Martin Pieuchot wrote: On 10/09/15(Thu) 14:40, Aaron Poffenberger wrote: [...] Sorry for the delay. It's error 15: urtwn0: could not load firmware page 1 (error 15) So it's not related to suspend/resume it appears to be a xhci issue. Could you try connecting it on a ehci (non blue) port? I hadn't noticed the xhci ports in the dmesg. I always believed it to be an early 2012 model with USB 2.0. According to the specs online both ports are 3.0. But the one I was using is a charging port, powered in sleep mode. I thought I tested this NIC in the unpowered port but perhaps that was the run0 I was trying (too small, no reception). After a couple of tries in the un-powered port the urtwn0 is restarting more reliably. I'll let it run that way today. Could also be a wonky port. Twice yesterday I had an axe0 plugged into the powered port for 10/100 access. Unplugged twice while running (no suspend) to ill effect. The first time the system rebooted, the second time it hung. Any thoughts? Could the fact it's powered have any impact?
