Re: Getting screen to lock on suspend with Lenovo Thinkpad X1 Carbon
On 03.09.19 21:09:11, Trey Sizemore wrote: > (...) > Thank you. I should have said, I have the following: > > bsd# cat /etc/apm/suspend > > > #!/bin/sh > pkill -USR1 xidle > > and that file is executable. Maybe xidle isn't running at the time you suspend your laptop? Please check if there is a process with name "xidle" which listens to USR1 by typing this pkill command in a shell and see if it looks your screen like you expect.
Re: ping time fluctuates, any idea?
Hello, > On 9/09/2019, at 8:45 PM, Jihyun Yu wrote: > > It seems that time from ping command fluctuates. Here's a output from ping > command. > [...snip ping with negative rtt...] This is symptomatic of unsynchronized time stamp counters (TSC). I would expect that setting: # sysctl kern.timecounter.hardware=acpihpet0 would fix your ping results, and probably improve your ntpd(8) performance, too. There has been some work in this area on -current. best, Richard. PS. Please make sure to include a complete dmesg next time - half a dmesg is like half a photograph! > 00=2828 01=a1a1 02=f7f7 03=2020 04=d9d9 05=5b5b 06=0b0b 07=3030 > isa0 at pcib0 > isadma0 at isa0 > com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo > pckbc0 at isa0 port 0x60/5 irq 1 irq 12 > pckbd0 at pckbc0 (kbd slot) > wskbd0 at pckbd0: console keyboard, using wsdisplay0 > pcppi0 at isa0 port 0x61 > spkr0 at pcppi0 > wbsio0 at isa0 port 0x2e/2: NCT6776F rev 0x33 > lm1 at wbsio0 port 0x290/8: NCT6776F > pci13 at mainbus0 bus 255 > "Intel E5 QPI Link" rev 0x07 at pci13 dev 8 function 0 not configured > vendor "Intel", unknown product 0x3c83 (class system subclass > miscellaneous, rev 0x07) at pci13 dev 8 function 3 not configured > vendor "Intel", unknown product 0x3c84 (class system subclass > miscellaneous, rev 0x07) at pci13 dev 8 function 4 not configured > "Intel E5 QPI Link" rev 0x07 at pci13 dev 9 function 0 not configured > vendor "Intel", unknown product 0x3c93 (class system subclass > miscellaneous, rev 0x07) at pci13 dev 9 function 3 not configured > vendor "Intel", unknown product 0x3c94 (class system subclass > miscellaneous, rev 0x07) at pci13 dev 9 function 4 not configured > "Intel E5 PCU" rev 0x07 at pci13 dev 10 function 0 not configured > "Intel E5 PCU" rev 0x07 at pci13 dev 10 function 1 not configured > "Intel E5 PCU" rev 0x07 at pci13 dev 10 function 2 not configured > "Intel E5 PCU" rev 0x07 at pci13 dev 10 function 3 not configured > "Intel E5 Scratch" rev 0x07 at pci13 dev 11 function 0 not configured > "Intel E5 Scratch" rev 0x07 at pci13 dev 11 function 3 not configured > "Intel E5 Unicast" rev 0x07 at pci13 dev 12 function 0 not configured > "Intel E5 Unicast" rev 0x07 at pci13 dev 12 function 1 not configured > "Intel E5 Unicast" rev 0x07 at pci13 dev 12 function 2 not configured > "Intel E5 SAD" rev 0x07 at pci13 dev 12 function 6 not configured > "Intel E5 SAD" rev 0x07 at pci13 dev 12 function 7 not configured > "Intel E5 Unicast" rev 0x07 at pci13 dev 13 function 0 not configured > "Intel E5 Unicast" rev 0x07 at pci13 dev 13 function 1 not configured > "Intel E5 Unicast" rev 0x07 at pci13 dev 13 function 2 not configured > "Intel E5 Broadcast" rev 0x07 at pci13 dev 13 function 6 not configured > "Intel E5 Home Agent" rev 0x07 at pci13 dev 14 function 0 not configured > "Intel E5 Home Agent" rev 0x07 at pci13 dev 14 function 1 not configured > "Intel E5 TA" rev 0x07 at pci13 dev 15 function 0 not configured > "Intel E5 RAS" rev 0x07 at pci13 dev 15 function 1 not configured > "Intel E5 TAD" rev 0x07 at pci13 dev 15 function 2 not configured > "Intel E5 TAD" rev 0x07 at pci13 dev 15 function 3 not configured > "Intel E5 TAD" rev 0x07 at pci13 dev 15 function 4 not configured > "Intel E5 TAD" rev 0x07 at pci13 dev 15 function 5 not configured > "Intel E5 TAD" rev 0x07 at pci13 dev 15 function 6 not configured > "Intel E5 Thermal" rev 0x07 at pci13 dev 16 function 0 not configured > "Intel E5 Thermal" rev 0x07 at pci13 dev 16 function 1 not configured > "Intel E5 Error" rev 0x07 at pci13 dev 16 function 2 not configured > "Intel E5 Error" rev 0x07 at pci13 dev 16 function 3 not configured > "Intel E5 Thermal" rev 0x07 at pci13 dev 16 function 4 not configured > "Intel E5 Thermal" rev 0x07 at pci13 dev 16 function 5 not configured > "Intel E5 Error" rev 0x07 at pci13 dev 16 function 6 not configured > "Intel E5 Error" rev 0x07 at pci13 dev 16 function 7 not configured > "Intel E5 DDRIO" rev 0x07 at pci13 dev 17 function 0 not configured > "Intel E5 R2PCIE" rev 0x07 at pci13 dev 19 function 0 not configured > "Intel E5 PCIE Monitor" rev 0x07 at pci13 dev 19 function 1 not configured > "Intel E5 QPI" rev 0x07 at pci13 dev 19 function 4 not configured > "Intel E5 QPI Link Monitor" rev 0x07 at pci13 dev 19 function 5 not > configured > "Intel E5 QPI Link Monitor" rev 0x07 at pci13 dev 19 function 6 not > configured > vmm0 at mainbus0: VMX/EPT > uhub4 at uhub0 port 1 configuration 1 interface 0 "Intel Rate Matching Hub" > rev 2.00/0.00 addr 2 > uhub5 at uhub3 port 1 configuration 1 interface 0 "Intel Rate Matching Hub" > rev 2.00/0.00 addr 2 > vscsi0 at root > scsibus4 at vscsi0: 256 targets > softraid0 at root > scsibus5 at softraid0: 256 targets > root on sd0a (74fd07b06a4f30a1.a) swap on sd0b dump on sd0b > > > Thanks, > Jihyun Yu
Re: athn bugs: usbd_free_xfer and fail HT-MCS
New issue prompted today: athn0: device time out athn0: firmware command 0x11 timed out athn0: could not remove station 1 (-address-) from table athn0: firmware command 0x14 timed out athn0: firmware command 0x15 timed out I was unable to reconnect. Solved after physically removing the usb adapter and restarting the network (sh /etc/network), unlike the previous issue, which was only solved after rebooting the system. Sometimes the interface mode keeps changing between OFDM48 and OFDM58, even though I've forced the mode in hostname.athn0. Please let me know how I can bring more useful informations (debug) to solve these issues i athn, hopefully before the new release.
Re: How to debug hanging machines / proc: table is full
On Mon, Sep 09, 2019 at 05:42:02PM +0200, Raimo Niskanen wrote:
> On Wed, Jul 31, 2019 at 05:46:08PM +0200, Raimo Niskanen wrote:
> > On Mon, Jul 29, 2019 at 01:20:58PM +, Stuart Henderson wrote:
> > > On 2019-07-29, Raimo Niskanen wrote:
> > > > A new hang, I tried to invstigate:
> > > >
> > > > At July 19 the last log entry from my 'ps' log was from 14:55, which is
> > > > also the time on the 'systat vmstat' screen when it froze. Then the
> > > > machine
> > > > hums along but just after midnight at 00:42:01 the first "/bsd: process:
> > > > table is full" entry appears. That message repeats until I rebooted it
> > > > today at July 29 10:48.
> > > >
> > > > I had a terminal with top running. It was still updating. It showed
> > > > about
> > > > 98% sys and 2% spin on one of 4 CPUs, the others 100% idle. Then (after
> > > > the process table had gotten full) it had 1282 idle processes and 1 on
> > > > processor, which was 'top' itself.
> > > > Memory: Real: 456M/1819M act/tot Free: 14G Cache: 676M Swap: 0K/16G.
> > > >
> > > > I had 8 shells under tmux ready for debugging. 'ls worked.
> > > > 'systat' on one hung. 'top' on another failed with "cannot fork".
> > > > 'exec ps ajxww" printed two lines with /sbin/init and /sbin/slaac
> > > > and then hung. 'exec reboot' did not succeed. Neither did a short
> > > > power
> > > > button, that at least caused a printout "stopping daemon nginx(failed)",
> > > > but got no further. I had to do a hard power off.
> > > >
> > > > My theory now is that our daily tests right before 14:55 started a
> > > > process
> > > > (this process is the top 'top' process with 10:14 execution time) that
> > > > triggers a lock or other contention problem in the kernel which causes
> > > > one CPU to spin in the system, and blocks processes from dying.
> > > > About 10 hours later the process table gets full.
> > > >
> > > > Any, ANY ideas of how to proceed would be appreciated!
> > > >
> > > > Best Regards
> > >
> > > Did you notice any odd waitchan's (WAIT in top output)?
> > >
> > > Maybe set ddb.console=1 in sysctl.conf and reboot (if not already
> > > set), then try to break into DDB during a hang and see how things look
> > > in ps there. (Test breaking into DDB before a hang first so you know
> > > that you can do it .. you can just "c" to continue).
> > >
> > > There might also be clues in things like "sh malloc" or "sh all pools".
> > >
> > > Perhaps you could also get clues from running a kernel built with
> > > 'option WITNESS', you may get some messages in dmesg, or it adds commands
> > > to ddb like "show locks", "show all locks", "show witness" (see ddb(4) for
> > > details).
> >
> > I have enabled Witness, it went so-so. We'll see what it catches.
> >
> > I downloaded 6.5 amd64 src.tar.gz and sys.tar.gz, unpacked them,
> > applied all patches for stable 001-006 and built a kernel with:
> > include "arch/amd64/conf/GENERIC"
> > optionMULTIPROCESSOR
> > optionMP_LOCKDEBUG
> > optionWITNESS
> >
> > Then I activated in /etc/sysctl.conf:
> > ddb.console=1
> > kern.witness.locktrace=1
> > kern.witness.watch=3
> >
> > For fun, I pressed Ctrl+Alt+Esc at the console, got a ddb> prompt and typed
> > "show witness". It printed lots of info, I scrolled down to the end, but
> > during the printout there was an UVM fault:
> >
> > Spin locks:
> > /usr/src/sys/
> > :
> > bla bla bla
> > :
> > uvm_fault(0x81e03b50, 0x800022368360, 0, 1) -> e
> > kernel: page fault trap, code=0
> > Faulted in DDB: continuing...
> >
> > Then I typed "cont" and it panicked.
> > If anybody want details I took a picture.
> >
> > Have I combined too many debugging options, or is this sh*t that happens?
> >
> > Nevertheless, now the machine is running again, with Witness...
> >
> > I'll be back.
>
> I have encountered some kind of stop, oddly enought not a panic - it
> just sat in ddb and I missed it for a week (or more). Then I did not
> remember what I had planned to do so I "improvised" X-| , but anyway:
>
> ddb{0}> ps
> shows about 350 processes from cron, half of them in state netlock, half
Sorry, that should have been about 1350 processes...
> in state piperd. Then I have my test processes beam.smp: 6 in netlock, 6
> in piperd, about 70 in fsleep, 3 in poll, 3 in select, 4 in kqread.
> Then about 100 more ordinary looking processes...
>
> ddb{0}> trace
> db_enter()...
> softclock(0)...
> softintr_dispatch(0)...
> Xsoftclock(0,0,1388,)...
> acpicpu_idle()...
> shed_idle(81ceff0)...
> end trace frame: 0x0, count: -6
>
> ddb{0}> show locks
> exclusive kernel_lock _lock r = 0 (0x81e37b10) locked @
> /usr/src/sys/arch/amd64/amd64/softintr.c:87
> #0 witness_lock+0x41f
> #1 softintr_dispatc+0x56
> #2 Xsoftclock+0x1f
> #3 acpicpu_idle+0x271
> #4 sched_idle+0x235
> #5 proc_trampoline+0x1c
>
> ddb{0}> show nfsnode
> size 5476515891122113356 flag 0 vnode 0xd080c7d8 accstamp
arpwatch on OpenBSD vm misinterpreting data?
TLDR; - Arpwatch new station alert showed arp spoofing attempt. Cloud hosting provider is adamant that arpwatch is misinterpreting data. OpenBSD 6.5 vm running in a cloud hosting provider: WEB# uname -a OpenBSD WEB 6.5 GENERIC.MP#3 amd64 Arpwatch installed: WEB# pkg_info arpwatch | grep Information Information for inst:arpwatch-2.1a15p19 Received arpwatch notification: WEB# grep arpwatch /var/log/daemon Aug 29 10:43:57 WEB arpwatch: new station 2.2.3.12 00:00:00:00:00:01 Checked arp table and found the mac address matched that of the default gateway. WEB# arp -a Host Ethernet AddressNetif ExpireFlags 2.2.2.100:00:00:00:00:01vio0 9m30s web22:22:22:22:22:22vio0 permanent l I proceeded to look at pf (host firewall) logs. While I don't log drops there were a number of requests to tcp80 and tcp443. Parsing relayd logs showed none of the requests passed protocol security filtering. Beyond this, I have no way to determine if this arp spoofing was successful. Thus I reached out to my hosting provider with this information and their response was: "We have protections in place to defend against such things and therefore this style of attack can not be performed on our network. The data you are seeing here is a bit misleading. Thank you for your report." I've only been a customer for a few months and during that time there have been no alerts generated by arpwatch. However I don't understand how the data is misleading. This is because arpwatch runs in an environment I manage and is found to be quite useful. Thus I requested more context as to why the data is misleading and their response was: "It is misinterpreting data. This attack is not possible on our network and arpwatch is not relevant to our platform or how it operates." Support is clearly adamant that their hosting environment is impervious. However none of this makes any sense to me. The host is a basic install with no custom or one-off configurations. Later watching arp traffic showed typical conversations between the host and default gateway. No other arp traffic was observed. WEB# tcpdump -lnettt -i vio0 arp I'm interested to hear feedback from misc@ as I didn't get a response from the arpwatch list. Is there a log or config I should check? Perhaps another utility to consider? Is my cloud hosting provider misinterpreting data? Do you suppose they had unplanned & unannounced maintenance? Anything else? Thanks, Paul
Re: Iked and PKCS7
Hello, You can convert it to PEM format using openssl pkcs7. -- Cordialement, Pierre BARDOU -Message d'origine- De : owner-m...@openbsd.org De la part de Tristan Pilat Envoyé : lundi 9 septembre 2019 10:03 À : misc@openbsd.org Objet : Iked and PKCS7 Hello all, It's the first time I'm trying to set up a site-to-site IKEv2 VPN with a non OpenBSD device at the other side. I've been asked to provide a CSR, then they sent me a PKCS7 certificate in return. Is there any way to install this kind of certificate with iked? If so, how do I proceed? Thank you for your help. Cheers, -- Tristan _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
Re: How to debug hanging machines / proc: table is full
On Wed, Jul 31, 2019 at 05:46:08PM +0200, Raimo Niskanen wrote:
> On Mon, Jul 29, 2019 at 01:20:58PM +, Stuart Henderson wrote:
> > On 2019-07-29, Raimo Niskanen wrote:
> > > A new hang, I tried to invstigate:
> > >
> > > At July 19 the last log entry from my 'ps' log was from 14:55, which is
> > > also the time on the 'systat vmstat' screen when it froze. Then the
> > > machine
> > > hums along but just after midnight at 00:42:01 the first "/bsd: process:
> > > table is full" entry appears. That message repeats until I rebooted it
> > > today at July 29 10:48.
> > >
> > > I had a terminal with top running. It was still updating. It showed
> > > about
> > > 98% sys and 2% spin on one of 4 CPUs, the others 100% idle. Then (after
> > > the process table had gotten full) it had 1282 idle processes and 1 on
> > > processor, which was 'top' itself.
> > > Memory: Real: 456M/1819M act/tot Free: 14G Cache: 676M Swap: 0K/16G.
> > >
> > > I had 8 shells under tmux ready for debugging. 'ls worked.
> > > 'systat' on one hung. 'top' on another failed with "cannot fork".
> > > 'exec ps ajxww" printed two lines with /sbin/init and /sbin/slaac
> > > and then hung. 'exec reboot' did not succeed. Neither did a short power
> > > button, that at least caused a printout "stopping daemon nginx(failed)",
> > > but got no further. I had to do a hard power off.
> > >
> > > My theory now is that our daily tests right before 14:55 started a process
> > > (this process is the top 'top' process with 10:14 execution time) that
> > > triggers a lock or other contention problem in the kernel which causes
> > > one CPU to spin in the system, and blocks processes from dying.
> > > About 10 hours later the process table gets full.
> > >
> > > Any, ANY ideas of how to proceed would be appreciated!
> > >
> > > Best Regards
> >
> > Did you notice any odd waitchan's (WAIT in top output)?
> >
> > Maybe set ddb.console=1 in sysctl.conf and reboot (if not already
> > set), then try to break into DDB during a hang and see how things look
> > in ps there. (Test breaking into DDB before a hang first so you know
> > that you can do it .. you can just "c" to continue).
> >
> > There might also be clues in things like "sh malloc" or "sh all pools".
> >
> > Perhaps you could also get clues from running a kernel built with
> > 'option WITNESS', you may get some messages in dmesg, or it adds commands
> > to ddb like "show locks", "show all locks", "show witness" (see ddb(4) for
> > details).
>
> I have enabled Witness, it went so-so. We'll see what it catches.
>
> I downloaded 6.5 amd64 src.tar.gz and sys.tar.gz, unpacked them,
> applied all patches for stable 001-006 and built a kernel with:
> include "arch/amd64/conf/GENERIC"
> option MULTIPROCESSOR
> option MP_LOCKDEBUG
> option WITNESS
>
> Then I activated in /etc/sysctl.conf:
> ddb.console=1
> kern.witness.locktrace=1
> kern.witness.watch=3
>
> For fun, I pressed Ctrl+Alt+Esc at the console, got a ddb> prompt and typed
> "show witness". It printed lots of info, I scrolled down to the end, but
> during the printout there was an UVM fault:
>
> Spin locks:
> /usr/src/sys/
> :
> bla bla bla
> :
> uvm_fault(0x81e03b50, 0x800022368360, 0, 1) -> e
> kernel: page fault trap, code=0
> Faulted in DDB: continuing...
>
> Then I typed "cont" and it panicked.
> If anybody want details I took a picture.
>
> Have I combined too many debugging options, or is this sh*t that happens?
>
> Nevertheless, now the machine is running again, with Witness...
>
> I'll be back.
I have encountered some kind of stop, oddly enought not a panic - it
just sat in ddb and I missed it for a week (or more). Then I did not
remember what I had planned to do so I "improvised" X-| , but anyway:
ddb{0}> ps
shows about 350 processes from cron, half of them in state netlock, half
in state piperd. Then I have my test processes beam.smp: 6 in netlock, 6
in piperd, about 70 in fsleep, 3 in poll, 3 in select, 4 in kqread.
Then about 100 more ordinary looking processes...
ddb{0}> trace
db_enter()...
softclock(0)...
softintr_dispatch(0)...
Xsoftclock(0,0,1388,)...
acpicpu_idle()...
shed_idle(81ceff0)...
end trace frame: 0x0, count: -6
ddb{0}> show locks
exclusive kernel_lock _lock r = 0 (0x81e37b10) locked @
/usr/src/sys/arch/amd64/amd64/softintr.c:87
#0 witness_lock+0x41f
#1 softintr_dispatc+0x56
#2 Xsoftclock+0x1f
#3 acpicpu_idle+0x271
#4 sched_idle+0x235
#5 proc_trampoline+0x1c
ddb{0}> show nfsnode
size 5476515891122113356 flag 0 vnode 0xd080c7d8 accstamp 1099511681152
(I think the size looks strange)
Then I tried show map and got a protection fault trap, gave up and
rebooted.
That was it! Next time I will try:
trace
ps
show malloc
show all pools
show locks
show all locks
unless anyone has got more or better suggestions...
Best Regards
--
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
Iked and PKCS7
Hello all, It's the first time I'm trying to set up a site-to-site IKEv2 VPN with a non OpenBSD device at the other side. I've been asked to provide a CSR, then they sent me a PKCS7 certificate in return. Is there any way to install this kind of certificate with iked? If so, how do I proceed? Thank you for your help. Cheers, -- Tristan
Re: 6.6-beta (RAMDISK_CD) #281 hangs on fsck
Hi David,
Awesome! Thank you for the quick fix.
Will report back once the snapshot is there.
Mischa
> On 9 Sep 2019, at 11:39, David Gwynne wrote:
>
> This should be fixed in -current now. A snapshot should pick it up in a day
> or so. Sorry for the inconvenience.
>
> Cheers,
> dlg
>
>> On 9 Sep 2019, at 11:08 am, Luke Small wrote:
>>
>> Yay!
>> -Luke
>>
>>
>> On Sun, Sep 8, 2019 at 8:07 PM David Gwynne wrote:
>> I think I see the problem. We're going to try and test this locally and will
>> hopefully have something committed in a few hours time.
>>
>> dlg
>>
>>> On 9 Sep 2019, at 10:33, Luke Small wrote:
>>>
>>> I have mfii too:
>>> dmesg | grep mfii:
>>>
>>> mfii0 at pci11 dev 0 function 0 "Symbios Logic MegaRAID SAS2208" rev 0x05:
>>> msi
>>> mfii0: "LSI MegaRAID SAS 9271-8i", firmware 23.28.0-0010, 1024MB cache
>>> scsibus1 at mfii0: 64 targets
>>> scsibus2 at mfii0: 256 targets
>>>
On 8.9.2019. 18:19, Luke Small wrote:
> It doesn't work for me on the
> ftp.hostserver.de/archive/2019-08-29-0105/amd64/
> bsd.rd!
Hi,
do you maybe have mfii on that box ?
I'm having same problem as Mischa and i have mfii. with bsd.rd fsck
stops with this command
Which disk is the root disk? ('?' for details) [sd0] sd0
Checking root filesystem (fsck -fp /dev/sd0a)...
On other boxes without mfii bsd.rd and sysupgrade works just fine..
between 27.08 and 29.8 i saw this commit
Changes by: d...@cvs.openbsd.org 2019/08/27 22:55:51
Modified files:
sys/dev/pci: mfii.c
Log message:
implement a DV_POWERDOWN handler to flush cache and shutdown the controller
this has been in snaps for the last week without issue, and has
been running in production on a bunch of my boxes for a week before
that, also without issue.
>>
>
pppoe no carrier
hi everyone i have setup pppoe and the interface comes up fine, the pppoedev is connected to a fritzbox modem and zen internet is the provider speaking to one of their advisers i was told that all i had to do was connect to one of the lan ports on the fritzbox then i could do the pppoe from my firewall when i reboot the firewall with the pppoe configuration , ifconfig shows the interface up and it shows a PADI being sent but no carrier on the pppoe interface, is there anyone who has a similar setup and can give me pointers, in particular is there anything in the fritzboz i should disable ? shadrock
Re: 6.6-beta (RAMDISK_CD) #281 hangs on fsck
This should be fixed in -current now. A snapshot should pick it up in a day or
so. Sorry for the inconvenience.
Cheers,
dlg
> On 9 Sep 2019, at 11:08 am, Luke Small wrote:
>
> Yay!
> -Luke
>
>
> On Sun, Sep 8, 2019 at 8:07 PM David Gwynne wrote:
> I think I see the problem. We're going to try and test this locally and will
> hopefully have something committed in a few hours time.
>
> dlg
>
> > On 9 Sep 2019, at 10:33, Luke Small wrote:
> >
> > I have mfii too:
> > dmesg | grep mfii:
> >
> > mfii0 at pci11 dev 0 function 0 "Symbios Logic MegaRAID SAS2208" rev 0x05:
> > msi
> > mfii0: "LSI MegaRAID SAS 9271-8i", firmware 23.28.0-0010, 1024MB cache
> > scsibus1 at mfii0: 64 targets
> > scsibus2 at mfii0: 256 targets
> >
> >> On 8.9.2019. 18:19, Luke Small wrote:
> >>> It doesn't work for me on the
> >>> ftp.hostserver.de/archive/2019-08-29-0105/amd64/
> >>> bsd.rd!
> >>
> >>
> >> Hi,
> >>
> >> do you maybe have mfii on that box ?
> >>
> >> I'm having same problem as Mischa and i have mfii. with bsd.rd fsck
> >> stops with this command
> >>
> >> Which disk is the root disk? ('?' for details) [sd0] sd0
> >> Checking root filesystem (fsck -fp /dev/sd0a)...
> >>
> >> On other boxes without mfii bsd.rd and sysupgrade works just fine..
> >>
> >> between 27.08 and 29.8 i saw this commit
> >>
> >> Changes by: d...@cvs.openbsd.org 2019/08/27 22:55:51
> >>
> >> Modified files:
> >> sys/dev/pci: mfii.c
> >>
> >> Log message:
> >> implement a DV_POWERDOWN handler to flush cache and shutdown the controller
> >>
> >> this has been in snaps for the last week without issue, and has
> >> been running in production on a bunch of my boxes for a week before
> >> that, also without issue.
> >>
> >>
> >>
>
Re: recent troubles with iwn(4)
On Mon, Sep 09, 2019 at 10:26:37AM +0100, Raf Czlonka wrote: > Your email prompted me today to have a look at what is happening > while the laptop loses connectivity - it's been disconnected for 3 > days after about 30 minutes of being connected (enough time to run > 'pkg_add -u'). After putting the interface into debug modes: > > # ifconfig iwn0 debug > > /var/log/messages shows: > > iwn0: AUTH -> SCAN > iwn0: end active scan > iwn0: - [...] > iwn0: - 12:34:56:12:34:56 11 +212 54M ess privacy rsn "MYNWID2"! > iwn0: + 12:34:56:12:34:57 44 +203 54M ess privacy rsn "MYNWID5" > iwn0: - [...] > iwn0: SCAN -> AUTH > iwn0: sending auth to 12:34:56:12:34:57 on channel 44 mode 11a This small part of the log is not useful by itself, unfortunately. You need to show debug output where iwn left RUN state in the first place. > What seems strange there is the mode - after a very brief look, it > seems like the laptop is "stuck" trying to use 11a mode. > > After forcing the 11n mode: > > # ifconfig iwn0 mode 11n > > it connects instantaneously: This command resets everything and the condition which triggered the problem is now gone. It connected fine to your 2 GHz AP. You have only shown failing connection attempts to your 5 GHz AP. Did your 5 GHz AP ever actually work with iwn?
Re: recent troubles with iwn(4)
On Sun, Sep 08, 2019 at 09:31:55PM BST, Bryan Stenson wrote: > Hi all - > > I'm writing to "misc" rather than "bugs" as I'm not yet sure this is a > bug. I'm hoping to help triage this with assistance from this list. > > I'm running -CURRENT and the iwn(4) driver for my wireless card. Over > the past year, this has been working great, but recently (within the > last month or so), I've had issues where the NIC just stops working > after a few hours of usage. I don't have a solid steps for > reproduction. > > I realize "stops working" is not a very accurate account here...but > I'm confused on how to get more descriptive information of the > problem. When it stops, "ifconfig" shows iwn0 with an IP address, but > I'm unable to ping. Additionally, I'm not seeing any > warnings/messages in "dmesg" about the device...so I'm confused. > > A simple "ifconfig iwn0 down; sh /etc/netstart iwn0" seems to fix the > problem, but I haven't had to do that in the past...it just feels like > a recent change (iwn(4) work?) has put me in this state. > Hi Bryan, I've noticed exactly the same(?) behaviour since about July but hadn't used the machine enough and, despite some changes to the iwn(4) and/or ieee80211, I thought it might have had something to do with the new AP I got. Your email prompted me today to have a look at what is happening while the laptop loses connectivity - it's been disconnected for 3 days after about 30 minutes of being connected (enough time to run 'pkg_add -u'). After putting the interface into debug modes: # ifconfig iwn0 debug /var/log/messages shows: iwn0: AUTH -> SCAN iwn0: end active scan iwn0: - [...] iwn0: - 12:34:56:12:34:56 11 +212 54M ess privacy rsn "MYNWID2"! iwn0: + 12:34:56:12:34:57 44 +203 54M ess privacy rsn "MYNWID5" iwn0: - [...] iwn0: SCAN -> AUTH iwn0: sending auth to 12:34:56:12:34:57 on channel 44 mode 11a What seems strange there is the mode - after a very brief look, it seems like the laptop is "stuck" trying to use 11a mode. After forcing the 11n mode: # ifconfig iwn0 mode 11n it connects instantaneously: iwn0: SCAN -> INIT iwn0: begin active scan iwn0: INIT -> SCAN iwn0: end active scan iwn0: AP 12:34:56:12:34:56 "MYNWID5" score 52 iwn0: best AP 12:34:56:12:34:57 "MYNWID2" score 52 iwn0: switching to network "MYNWID2" iwn0: [...] iwn0: + 12:34:56:12:34:56 11 +216 54M ess privacy rsn "MYNWID2" iwn0: - 12:34:56:12:34:57 44+0 54M ess privacy rsn "MYNWID5"! iwn0: [...] iwn0: SCAN -> AUTH iwn0: sending auth to 12:34:56:12:34:56 on channel 11 mode 11g iwn0: AUTH -> ASSOC iwn0: sending assoc_req to 12:34:56:12:34:56 on channel 11 mode 11g iwn0: ASSOC -> RUN iwn0: associated with 12:34:56:12:34:56 ssid "MYNWID2" channel 11 start MCS 0 short preamble long slot time HT enabled iwn0: missed beacon threshold set to 7 beacons, beacon interval is 100 TU iwn0: received msg 1/4 of the 4-way handshake from 12:34:56:12:34:56 iwn0: sending msg 2/4 of the 4-way handshake to 12:34:56:12:34:56 iwn0: received msg 3/4 of the 4-way handshake from 12:34:56:12:34:56 iwn0: sending msg 4/4 of the 4-way handshake to 12:34:56:12:34:56 iwn0: sending action to 12:34:56:12:34:56 on channel 11 mode 11n MYNWID2 and MYNWID5 are the two NWIDs I use - 2.4 and 5GHz respectively. I use the same hostname.if on all of my laptops: join MYNWID5 wpakey ... join MYNWID2 wpakey ... [...] dhcp BTW, after reboot (upgrade to a new snapshot) and ~1h run, it disconnected again. Any thoughts, Stefan? Regards, Raf
Re: recent troubles with iwn(4)
On Sun, Sep 08, 2019 at 08:31:55PM +, Bryan Stenson wrote: > Hi all - > > I'm writing to "misc" rather than "bugs" as I'm not yet sure this is a > bug. I'm hoping to help triage this with assistance from this list. > > I'm running -CURRENT and the iwn(4) driver for my wireless card. Over > the past year, this has been working great, but recently (within the > last month or so), I've had issues where the NIC just stops working > after a few hours of usage. I don't have a solid steps for > reproduction. > > I realize "stops working" is not a very accurate account here...but > I'm confused on how to get more descriptive information of the > problem. When it stops, "ifconfig" shows iwn0 with an IP address, but > I'm unable to ping. Additionally, I'm not seeing any > warnings/messages in "dmesg" about the device...so I'm confused. > > A simple "ifconfig iwn0 down; sh /etc/netstart iwn0" seems to fix the > problem, but I haven't had to do that in the past...it just feels like > a recent change (iwn(4) work?) has put me in this state. > > I'm really wanting to help here. How can I run the iwn(4) in debug > mode, or increase logging verbosity? And/or, should I try to capture > packets via tcpdump? And/or, can I run an older bsd.mp (without > having to downgrade packages to older versions) in order to try and > "bisect" where the problem may have been introduced? Please enable debugging with 'ifconfig iwn0 debug' and when the problem reoccurs check whether you can find any relevant information in the file /var/log/messages.
ping time fluctuates, any idea?
It seems that time from ping command fluctuates. Here's a output from ping
command.
# ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.058 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.035 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=255 time=0.047 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=255 time=0.050 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=255 time=0.047 ms
64 bytes from 127.0.0.1: icmp_seq=5 ttl=255 time=0.052 ms
64 bytes from 127.0.0.1: icmp_seq=6 ttl=255 time=0.051 ms
64 bytes from 127.0.0.1: icmp_seq=7 ttl=255 time=0.034 ms
64 bytes from 127.0.0.1: icmp_seq=8 ttl=255 time=0.054 ms
64 bytes from 127.0.0.1: icmp_seq=9 ttl=255 time=0.052 ms
64 bytes from 127.0.0.1: icmp_seq=10 ttl=255 time=0.035 ms
64 bytes from 127.0.0.1: icmp_seq=11 ttl=255 time=0.051 ms
64 bytes from 127.0.0.1: icmp_seq=12 ttl=255 time=0.033 ms
64 bytes from 127.0.0.1: icmp_seq=13 ttl=255 time=0.048 ms
64 bytes from 127.0.0.1: icmp_seq=14 ttl=255 time=0.053 ms
64 bytes from 127.0.0.1: icmp_seq=15 ttl=255 time=0.049 ms
64 bytes from 127.0.0.1: icmp_seq=16 ttl=255 time=0.050 ms
64 bytes from 127.0.0.1: icmp_seq=17 ttl=255 time=0.051 ms
64 bytes from 127.0.0.1: icmp_seq=18 ttl=255 time=587.470 ms
64 bytes from 127.0.0.1: icmp_seq=19 ttl=255 time=0.047 ms
64 bytes from 127.0.0.1: icmp_seq=20 ttl=255 time=0.063 ms
64 bytes from 127.0.0.1: icmp_seq=21 ttl=255 time=0.066 ms
64 bytes from 127.0.0.1: icmp_seq=22 ttl=255 time=0.052 ms
64 bytes from 127.0.0.1: icmp_seq=23 ttl=255 time=0.055 ms
64 bytes from 127.0.0.1: icmp_seq=24 ttl=255 time=0.035 ms
64 bytes from 127.0.0.1: icmp_seq=25 ttl=255 time=0.034 ms
64 bytes from 127.0.0.1: icmp_seq=26 ttl=255 time=0.057 ms
64 bytes from 127.0.0.1: icmp_seq=27 ttl=255 time=0.057 ms
64 bytes from 127.0.0.1: icmp_seq=28 ttl=255 time=0.057 ms
64 bytes from 127.0.0.1: icmp_seq=29 ttl=255 time=0.057 ms
64 bytes from 127.0.0.1: icmp_seq=30 ttl=255 time=0.058 ms
64 bytes from 127.0.0.1: icmp_seq=31 ttl=255 time=0.059 ms
64 bytes from 127.0.0.1: icmp_seq=32 ttl=255 time=0.058 ms
64 bytes from 127.0.0.1: icmp_seq=33 ttl=255 time=0.057 ms
64 bytes from 127.0.0.1: icmp_seq=34 ttl=255 time=0.055 ms
64 bytes from 127.0.0.1: icmp_seq=35 ttl=255 time=-587.359 ms
At first, I suspect that system time fluctuates for some reasons. To test
it, I wrote a simple python scripts to detect local time changes.
# cat test.py
import time
def milliseconds():
return int(round(time.time() * 1000))
prev = milliseconds()
while True:
cur = milliseconds()
dt = cur - prev
if dt < 0:
print("prev=%s, cur=%s, diff=%s" % (prev, cur, dt))
prev = cur
# python3 test.py
I validated the script with `rdate` command, and it works as expected.
However it does not print logs on ping time fluctuations.
Any hint to troubleshoot the issue? Here's my dmesg.
00=2828 01=a1a1 02=f7f7 03=2020 04=d9d9 05=5b5b 06=0b0b 07=3030
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
wbsio0 at isa0 port 0x2e/2: NCT6776F rev 0x33
lm1 at wbsio0 port 0x290/8: NCT6776F
pci13 at mainbus0 bus 255
"Intel E5 QPI Link" rev 0x07 at pci13 dev 8 function 0 not configured
vendor "Intel", unknown product 0x3c83 (class system subclass
miscellaneous, rev 0x07) at pci13 dev 8 function 3 not configured
vendor "Intel", unknown product 0x3c84 (class system subclass
miscellaneous, rev 0x07) at pci13 dev 8 function 4 not configured
"Intel E5 QPI Link" rev 0x07 at pci13 dev 9 function 0 not configured
vendor "Intel", unknown product 0x3c93 (class system subclass
miscellaneous, rev 0x07) at pci13 dev 9 function 3 not configured
vendor "Intel", unknown product 0x3c94 (class system subclass
miscellaneous, rev 0x07) at pci13 dev 9 function 4 not configured
"Intel E5 PCU" rev 0x07 at pci13 dev 10 function 0 not configured
"Intel E5 PCU" rev 0x07 at pci13 dev 10 function 1 not configured
"Intel E5 PCU" rev 0x07 at pci13 dev 10 function 2 not configured
"Intel E5 PCU" rev 0x07 at pci13 dev 10 function 3 not configured
"Intel E5 Scratch" rev 0x07 at pci13 dev 11 function 0 not configured
"Intel E5 Scratch" rev 0x07 at pci13 dev 11 function 3 not configured
"Intel E5 Unicast" rev 0x07 at pci13 dev 12 function 0 not configured
"Intel E5 Unicast" rev 0x07 at pci13 dev 12 function 1 not configured
"Intel E5 Unicast" rev 0x07 at pci13 dev 12 function 2 not configured
"Intel E5 SAD" rev 0x07 at pci13 dev 12 function 6 not configured
"Intel E5 SAD" rev 0x07 at pci13 dev 12 function 7 not configured
"Intel E5 Unicast" rev 0x07 at pci13 dev 13 function 0 not configured
"Intel E5 Unicast" rev 0x07 at pci13 dev 13 function 1 not configured
"Intel E5 Unicast" rev 0x07 at pci13 dev 13 function 2 not configured
"Intel E5 Broadcast" rev 0x07 at pci13 dev 13 function 6 not configured
"Intel E5 Home Agent" rev
Re: recent troubles with iwn(4)
On Sun, Sep 08, 2019 at 08:31:55PM +, Bryan Stenson wrote: > Hi all - > > I'm writing to "misc" rather than "bugs" as I'm not yet sure this is a > bug. I'm hoping to help triage this with assistance from this list. > > I'm running -CURRENT and the iwn(4) driver for my wireless card. Over > the past year, this has been working great, but recently (within the > last month or so), I've had issues where the NIC just stops working > after a few hours of usage. I don't have a solid steps for > reproduction. > > I realize "stops working" is not a very accurate account here...but > I'm confused on how to get more descriptive information of the > problem. When it stops, "ifconfig" shows iwn0 with an IP address, but > I'm unable to ping. Additionally, I'm not seeing any > warnings/messages in "dmesg" about the device...so I'm confused. The iwn driver on my host runnning 6.4 stable writes to /var/log/messages (as well as the system message buffer). Is there nothing in the log files on your system? --Paul
