Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

2020-09-20 Thread Hans Petter Selasky

On 2020-09-20 10:05, Rainer Hurling wrote:

Hi monochrome,

back to keyboard, it tried newest CURRENT (r365920) on my box and even
with newest sources the error occurs.

After looking around somewhat more, I found some hints about Virtualbox
kernel module having problems with r365488. Unfortunately, I am not able
to find the thread again :(

What seems to help as a workaround is to disable the loading of
VirtualBox in /boot/loader.conf

#vboxdrv_load="YES"

and in /etc/rc.conf

#vboxnet_enable="YES"
#vboxguest_enable="YES"


So probably, this page fault is not restricted to AMD Ryzen?



Possibly you need to rebuild that kernel module. Maybe the FreeBSD 
version was not bumped correctly.


--HPS

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Wake from sleep kinda broken-ish? (ThinkPad Carbon X1 6th gen)

2020-09-16 Thread Hans Petter Selasky

On 2020-09-16 10:51, Eirik Øverby wrote:

On 9/16/20 9:07 AM, Li-Wen Hsu wrote:

On Wed, Sep 16, 2020 at 2:30 PM Andriy Gapon  wrote:


On 15/09/2020 23:13, Eirik Øverby wrote:

On 9/15/20 9:50 PM, Andriy Gapon wrote:

On 15/09/2020 22:36, Eirik Øverby wrote:

Now, since I updated from r365358 to r365688, I have not once been able to wake 
from sleep.


Is that the only thing that changed?
Any port / package upgrades?


There have been updates to packages, yes - but it didn't even occur to me that 
these could impact the resume process at such an early stage. Not sure which 
that would be; obviously the drm module has been rebuilt each time I upgraded, 
but I don't have any other kernel modules installed from packages.


Which version of drm module are you using?


13.0-CURRENT FreeBSD 13.0-CURRENT #7 r365688
drm-devel-kmod-5.4.62.g20200905_1

Built against the running kernel sources, of course.



Yes, I specifically had drm modules in mind.


I also use X1C 6th and it was working perfectly after updating BIOS to
1.30 (which I'm currently using) in Sep. 2018 [1]. I don't remember
any suspend/resume failures. But since late 2019, it has exactly the
same symptom as yours. Suspending is fine, but upon resuming, there is
about a 50% probability that the power LDE continues pulsating with
all other LDEs like FnLock and CapsLock are on like the machine is
awake.


Right-o.


To make sure suspend/resume is not blocked by USB you can try setting:

sysctl hw.usb.no_suspend_wait=1

--HPS


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: USB sound devices with FreeBSD-CURRENT

2020-09-15 Thread Hans Petter Selasky

On 2020-09-13 16:30, Hans Petter Selasky wrote:

On 2020-09-13 16:13, Graham Perrin wrote:

pcm3:  (rec)
pcm4:  (play/rec)


Or:

-R /dev/dsp4 -P /dev/dsp4

-f /dev/dsp4

You can also add these parameters run-time via the GUI for virtual_oss.



As a follow up to this discussion I've lowered the default buffer 
latency to 8ms, which is the default for all USB devices.


https://svnweb.freebsd.org/changeset/ports/548703

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: ioctl argument type [Was Re: svn commit: r359968 - head/sys/kern]

2020-09-14 Thread Hans Petter Selasky

On 2020-09-14 09:44, Xin LI wrote:

Hi,

I have seen Chromium trigger the warning (I run -CURRENT with INVARIANTS)
and looked into the code history a little bit.

It seems that the command was changed to u_long in r36846
<https://svnweb.freebsd.org/base?view=revision=36846> with a
follow up commit of r38517
<https://svnweb.freebsd.org/base?view=revision=38517> , possibly
because ioctl was defined to take an unsigned long command before FreeBSD.

Internally, we have truncated it to 32-bit since 2005 (r140406
<https://svnweb.freebsd.org/base?view=revision=140406>), and this
recent change made it a silent behavior.  POSIX, on the other hand, defined
<https://pubs.opengroup.org/onlinepubs/9699919799/functions/ioctl.html>
ioctl as taking an int as its second parameter, but neither Linux (glibc in
particular, despite its documentation says
<https://www.gnu.org/software/libc/manual/html_node/IOCTLs.html>
differently) nor macOS appear to define it that way, but Solaris seems
<https://docs.oracle.com/cd/E23824_01/html/821-1463/ioctl-2.html> to be
defining it as an int.

What was the motivation to keep the prototype definition as

  int
  ioctl(int fd, unsigned long request, ...);

instead of:

  int
  ioctl(int fd, int request, ...);

Other than to make existing code happy?  Alternatively, will it be a good
idea to give compiler some hints (e.g. by using __attribute__(enable_if))
to emit errors, if we insist keeping the existing signature?


On Wed, Apr 15, 2020 at 6:21 AM Hans Petter Selasky 
wrote:


Author: hselasky
Date: Wed Apr 15 13:20:51 2020
New Revision: 359968
URL: https://svnweb.freebsd.org/changeset/base/359968

Log:
   Cast all ioctl command arguments through uint32_t internally.

   Hide debug print showing use of sign extended ioctl command argument
   under INVARIANTS. The print is available to all and can easily fill
   up the logs.

   No functional change intended.

   MFC after:1 week
   Sponsored by: Mellanox Technologies

Modified:
   head/sys/kern/sys_generic.c

Modified: head/sys/kern/sys_generic.c

==
--- head/sys/kern/sys_generic.c Wed Apr 15 13:13:46 2020(r359967)
+++ head/sys/kern/sys_generic.c Wed Apr 15 13:20:51 2020(r359968)
@@ -652,18 +652,19 @@ int
  sys_ioctl(struct thread *td, struct ioctl_args *uap)
  {
 u_char smalldata[SYS_IOCTL_SMALL_SIZE]
__aligned(SYS_IOCTL_SMALL_ALIGN);
-   u_long com;
+   uint32_t com;
 int arg, error;
 u_int size;
 caddr_t data;

+#ifdef INVARIANTS
 if (uap->com > 0x) {
 printf(
 "WARNING pid %d (%s): ioctl sign-extension ioctl
%lx\n",
 td->td_proc->p_pid, td->td_name, uap->com);
-   uap->com &= 0x;
 }
-   com = uap->com;
+#endif
+   com = (uint32_t)uap->com;

 /*
  * Interpret high order word to find amount of data to be



Hi,

Using unsigned long is not cross platform compatible, especially when 
you have 32-bit compat shim layers.


On 64-bit platforms long is usually 64-bit and on 32-bit platforms long 
is usually 32-bit.


You've brought up a good question with a good history line.

Maybe we should just "#if 0" the INVARIANTS check and remove that code?

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: USB sound devices with FreeBSD-CURRENT

2020-09-13 Thread Hans Petter Selasky

On 2020-09-13 16:13, Graham Perrin wrote:

pcm3:  (rec)
pcm4:  (play/rec)


Or:

-R /dev/dsp4 -P /dev/dsp4

-f /dev/dsp4

You can also add these parameters run-time via the GUI for virtual_oss.

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: USB sound devices with FreeBSD-CURRENT

2020-09-13 Thread Hans Petter Selasky

On 2020-09-13 16:13, Graham Perrin wrote:

   -f /dev/dsp0 \


Try:

-f /dev/dsp3

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: USB sound devices with FreeBSD-CURRENT

2020-09-13 Thread Hans Petter Selasky

On 2020-09-13 11:21, Graham Perrin wrote:


1. Chromium simply does not play AV content e.g. 
 – after 
a click to play, there's a moment of visual motion but no playback


2. if Firefox media.cubeb.backend set to oss then behaviour is the same 
as Chromium


3. if Firefox media.cubeb.backend is not set (audio backend defaults to 
pulse-rust) then playback occurs through IDT 92HD81B1X (Analog) – not USB.


Try to configure a smaller audio buffer size in virtual_oss . Sometimes 
devices request a very small audio buffer .


--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: bridge/igb panic: sleepq_add: td 0xfffffe01bbce5300 to sleep on wchan 0xffffffff8157d9a0 with sleeping prohibited

2020-09-11 Thread Hans Petter Selasky

On 2020-09-11 14:08, Hans Petter Selasky wrote:

I think this is another variant of:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232362


Also adding this one for the record:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240609

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: bridge/igb panic: sleepq_add: td 0xfffffe01bbce5300 to sleep on wchan 0xffffffff8157d9a0 with sleeping prohibited

2020-09-11 Thread Hans Petter Selasky

On 2020-09-11 13:47, xto...@mm.st wrote:

xto...@mm.st wrote:
Updating from latest CURRENT snapshot 
(FreeBSD-13.0-CURRENT-amd64-20200910-1544934ffb2) to r365620 broke the 
bridges with igb (I350-T2) for me.  Booting to kernel.old and/or 
commenting the entries in rc.conf helps.


rc.conf:

cloned_interfaces="bridge0 bridge1 tap0 tap1 tap2 tap3"
ifconfig_em0="inet ..."
ifconfig_igb0="up"
ifconfig_igb1="up"
ifconfig_bridge0="addm igb0 addm tap0 addm tap1"
ifconfig_bridge1="addm igb1 addm tap2 addm tap3"


NICs (em0 is on-board, igb0/igb1 is addon I350-T2 card):

em0:  mem 0x92d0-0x92d1 
at device 31.6 numa-domain 0 on pci0

em0: Using 1024 TX descriptors and 1024 RX descriptors
em0: Using an MSI interrupt
em0: Ethernet address: e0:d5:5e:6c:aa:36
em0: netmap queues/slots: TX 1/1024, RX 1/1024
igb0:  mem 
0xfbb0-0xfbbf,0xfbc84000-0xfbc87fff at device 0.0 numa-domain 
0 on pci16

igb0: Using 1024 TX descriptors and 1024 RX descriptors
igb0: Using 8 RX queues 8 TX queues
igb0: Using MSI-X interrupts with 9 vectors
igb0: Ethernet address: a0:36:9f:0a:cf:42
igb0: netmap queues/slots: TX 8/1024, RX 8/1024
igb1:  mem 
0xfba0-0xfbaf,0xfbc8-0xfbc83fff at device 0.1 numa-domain 
0 on pci16

igb1: Using 1024 TX descriptors and 1024 RX descriptors
igb1: Using 8 RX queues 8 TX queues
igb1: Using MSI-X interrupts with 9 vectors
igb1: Ethernet address: a0:36:9f:0a:cf:43
igb1: netmap queues/slots: TX 8/1024, RX 8/1024


panic:

panic: sleepq_add: td 0xfe01bbce5300 to sleep on wchan 
0x8157d9a0 with sleeping prohibited

cpuid = 16
time = 1599808542
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe01ba658c40

vpanic() at vpanic+0x182/frame 0xfe01ba658c90
panic() at panic+0x43/frame 0xfe01ba658cf0
sleepq_add() at sleepq_add+0x359/frame 0xfe01ba658d40
_sleep() at _sleep+0x20c/frame 0xfe01ba658df0
pause_sbt() at pause_sbt+0xfe/frame 0xfe01ba658e20
e1000_reset_hw_82580() at e1000_reset_hw_82580+0x1c8/frame 
0xfe01ba658e60

em_if_stop() at em_if_stop+0x1b/frame 0xfe01ba658e80
iflib_stop() at iflib_stop+0xbd/frame 0xfe01ba658ed0
iflib_if_ioctl() at iflib_if_ioctl+0x397/frame 0xfe01ba658f40
bridge_mutecaps() at bridge_mutecaps+0x145/frame 0xfe01ba658fb0
bridge_ioctl_add() at bridge_ioctl_add+0x468/frame 0xfe01ba659000
bridge_ioctl() at bridge_ioctl+0x32b/frame 0xfe01ba6590d0
in_control() at in_control+0x322/frame 0xfe01ba659180
ifioctl() at ifioctl+0x3e8/frame 0xfe01ba659250
kern_ioctl() at kern_ioctl+0x28e/frame 0xfe01ba6592c0
sys_ioctl() at sys_ioctl+0x127/frame 0xfe01ba659390
amd64_syscall() at amd64_syscall+0x140/frame 0xfe01ba6594b0
fast_syscall_common() at fast_syscall_common+0xf8/frame 
0xfe01ba6594b0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8004b4aba, rsp = 
0x7fffe2b8, rbp = 0x7fffe360 ---

Uptime: 14s
Dumping 3794 out of 97961 
MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%






Hi,

I think this is another variant of:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232362

--HPS

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: suspend/resume versus OpenZFS on USB

2020-09-05 Thread Hans Petter Selasky

On 2020-09-05 11:00, Graham Perrin wrote:

On 04/09/2020 09:01, Hans Petter Selasky wrote:

On 2020-09-04 01:42, Graham Perrin wrote:
This week for the first time I toyed with OpenZFS on a USB device: a 
mobile hard disk drive connected to the dock of an HP EliteBook 8570p.


A light test, with the pool imported but not writing to the dataset 
at suspend time.


At resume time (22:31), the device was still physically connected but 
the pool suffered an I/O failure (and the keyboard and trackball on 
USB were unusable).

…

We need output from "procstat -akk" to see where ZFS/USB is hanging.

--HPS


For test purposes I reproduced the behaviour with a different device, a 
USB flash drive (connected to the same dock).


Attached:

2020-09-05 09:27:55 procstat -akk.txt

– output from procstat -akk

2020-09-05 09:17:59 suspend 09:26:49 resume.txt

– the output in context.

Thank you

Graham




Hi,

USB is not hanging.

It looks like a problem with USB resume, that no devices are recognized, 
until you re-plug them ...


--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: suspend/resume versus OpenZFS on USB

2020-09-04 Thread Hans Petter Selasky

On 2020-09-04 01:42, Graham Perrin wrote:
This week for the first time I toyed with OpenZFS on a USB device: a 
mobile hard disk drive connected to the dock of an HP EliteBook 8570p.


A light test, with the pool imported but not writing to the dataset at 
suspend time.


At resume time (22:31), the device was still physically connected but 
the pool suffered an I/O failure (and the keyboard and trackball on USB 
were unusable).


Sep  3 22:31:03 momh167-gjp4-8570p ZFS[11239]: vdev state changed, 
pool_guid=$8076233369858608335 vdev_guid=$13893535540375859253
Sep  3 22:31:03 momh167-gjp4-8570p ZFS[11243]: pool I/O failure, 
zpool=$Transcend error=$28
Sep  3 22:31:03 momh167-gjp4-8570p ZFS[11247]: pool I/O failure, 
zpool=$Transcend error=$28
Sep  3 22:31:03 momh167-gjp4-8570p ZFS[11251]: pool I/O failure, 
zpool=$Transcend error=$28
Sep  3 22:31:03 momh167-gjp4-8570p ZFS[11255]: pool I/O failure, 
zpool=$Transcend error=$28
Sep  3 22:31:03 momh167-gjp4-8570p ZFS[11259]: catastrophic pool I/O 
failure, zpool=$Transcend


I cleared pool errors (after which the keyboard and trackball became 
usable), exported the pool, physically disconnected the drive, restarted 
the OS, reconnected, imported and – luckily – cleared the remaining 
metadata errors through a scrub.


Please, might something be done to improve suspend/resume reliability 
with storage on USB?


Might I/O failures be less likely if I connect the drive to the notebook 
instead of its dock?


TIA



More from /var/log/messages at https://pastebin.com/CqRYbFZm

Other relevant info below.

root@momh167-gjp4-8570p:~ # date ; uptime ; uname -v
Thu Sep  3 22:45:07 BST 2020
10:45PM  up 6 mins, 6 users, load averages: 0.20, 0.27, 0.13
FreeBSD 13.0-CURRENT #63 r364768: Tue Aug 25 20:08:23 BST 2020 
root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG

root@momh167-gjp4-8570p:~ # zpool status -v
   pool: copperbowl
  state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
     still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
     the pool may no longer be accessible by software that does not 
support

     the features. See zpool-features(5) for details.
   scan: scrub repaired 0B in 01:39:31 with 0 errors on Thu Sep  3 
01:12:21 2020

config:

     NAME  STATE READ WRITE CKSUM
     copperbowl    ONLINE   0 0 0
   ada0p4.eli  ONLINE   0 0 0

errors: No known data errors
root@momh167-gjp4-8570p:~ # zpool import Transcend && zfs load-key 
Transcend/VirtualBox

Enter passphrase for 'Transcend/VirtualBox':
root@momh167-gjp4-8570p:~ # zpool status -v Transcend
   pool: Transcend
  state: ONLINE
status: One or more devices has experienced an error resulting in data
     corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
     entire pool from backup.
    see: https://zfsonlinux.org/msg/ZFS-8000-8A
   scan: scrub repaired 0B in 00:15:33 with 0 errors on Wed Sep  2 
22:38:56 2020

config:

     NAME    STATE READ WRITE CKSUM
     Transcend   ONLINE   0 0 0
   da0p1 ONLINE   0 0 0

errors: Permanent errors have been detected in the following files:

     :<0x0>
     :<0x3d>
root@momh167-gjp4-8570p:~ # zpool scrub Transcend
root@momh167-gjp4-8570p:~ # zfs version
zfs-0.8.0-1
zfs-kmod-0.8.0-1
root@momh167-gjp4-8570p:~ # zpool status -v Transcend
   pool: Transcend
  state: ONLINE
   scan: scrub repaired 0B in 00:17:53 with 0 errors on Thu Sep  3 
23:03:57 2020

config:

     NAME    STATE READ WRITE CKSUM
     Transcend   ONLINE   0 0 0
   da0p1 ONLINE   0 0 0

errors: No known data errors
root@momh167-gjp4-8570p:~ # zfs get 
compression,compressratio,encryption,used,referenced,mountpoint 
Transcend Transcend/VirtualBox

NAME  PROPERTY   VALUE SOURCE
Transcend compression    zstd  local
Transcend compressratio  1.70x -
Transcend encryption off default
Transcend used   76.4G -
Transcend referenced 76.4G -
Transcend mountpoint /Volumes/t500 local
Transcend/VirtualBox  compression    zstd inherited from Transcend
Transcend/VirtualBox  compressratio  1.00x -
Transcend/VirtualBox  encryption aes-256-gcm   -
Transcend/VirtualBox  used   200K  -
Transcend/VirtualBox  referenced 200K  -
Transcend/VirtualBox  mountpoint /Volumes/t500/VirtualBox inherited 
from Transcend
root@momh167-gjp4-8570p:~ # ls -hl 
/Volumes/t500/VirtualBox/Windows/Windows.vdi
-rw---  1 grahamperrin  grahamperrin    69G Sep  3 16:58 

Re: Strange USB loop

2020-08-25 Thread Hans Petter Selasky

On 2020-08-25 07:03, bob prohaska wrote:

On Tue, Aug 25, 2020 at 12:46:01AM +0200, Hans Petter Selasky wrote:

On 2020-08-24 18:37, bob prohaska wrote:

After updating to
FreeBSD 13.0-CURRENT (GENERIC) #5 r364475: Mon Aug 24 06:47:29 PDT 2020
on a Pi3 it was necessary to disconnect the mouse, keyboard and usb-serial


You are after:

https://svnweb.freebsd.org/changeset/base/364433

You may want to try a kernel before:

r364379


Can you try r364346 ?


A kernel for
FreeBSD 13.0-CURRENT (GENERIC) #6 r364378: Tue Aug 25 00:46:27 PDT 2020
compiled and installed without incident, but the problem persists. This
time I plugged the keyboard into the hub and got a stream of
uhub_reattach_port: giving up port reset - device vanished
which didn't stop when the keyboard was removed. If the keyboard is
moved to the Pi's internal USB connectors the keyboard is recognized
and works, but the once-per-second "...device vanished" messages continue.

Attempts to repeat this behavior were frustrating. After a few iterations
the error message was triggered by plugging in an FTDI usb-serial adapter,
but the messages stopped when it was unplugged.

The hub is
Bus /dev/usb Device /dev/ugen1.4: ID 05e3:0610 Genesys Logic, Inc. 4-port hub

The disk adapter is
Bus /dev/usb Device /dev/ugen1.5: ID 152d:1561 JMicron Technology Corp. / 
JMicron USA Technology Corp. JMS561U two ports SATA 6Gb/s bridge

Are either of these known troublmakers?


--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Strange USB loop

2020-08-24 Thread Hans Petter Selasky

On 2020-08-24 18:37, bob prohaska wrote:

After updating to
FreeBSD 13.0-CURRENT (GENERIC) #5 r364475: Mon Aug 24 06:47:29 PDT 2020
on a Pi3 it was necessary to disconnect the mouse, keyboard and usb-serial


You are after:

https://svnweb.freebsd.org/changeset/base/364433

You may want to try a kernel before:

r364379

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Kernel crash during video transcoding

2020-08-21 Thread Hans Petter Selasky

On 2020-08-16 22:23, Alexandre Levy wrote:

Any suggestions ?


Are there any simple steps to reproduce this?

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Kernel crash during video transcoding

2020-08-17 Thread Hans Petter Selasky

On 2020-08-16 22:23, Alexandre Levy wrote:

(kgdb) p *m
$2 = {plinks = {q = {tqe_next = 0x578491b51dd60510, tqe_prev =
0xd78c11bd9dde8518}, s = {ss = {sle_next = 0x578491b51dd60510}}, memguard =
{p = 6306325585301210384,
   v = 15531808720989095192}, uma = {slab = 0x578491b51dd60510, zone =
0xd78c11bd9dde8518}}, listq = {tqe_next = 0xd78c11bd9dde8518, tqe_prev =
0x265bc92017d7aa38},
   object = 0x2659c92217d5aa3a, pindex = 2758957463725517354, phys_addr =
2758957463725517354, md = {pv_list = {tqh_first = 0x2e49c1321fc5a22a,
tqh_last = 0x3e4bd1300fc7b228},
 pv_gen = 265794104, pat_mode = 1046204704}, ref_count = 257405624,
busy_lock = 1054593440, a = {{flags = 4757, queue = 48 '0', act_count = 134
'\206'}, _bits = 2251297429},
   order = 98 'b', pool = 204 '\314', flags = 75 'K', oflags = 105 'i',
psind = -107 '\225', segind = 18 '\022', valid = 48 '0', dirty = 134 '\206'}


This "m" structure looks freed.

It looks like a use after free issue.

Can you enter this in GDB:

set print pretty on

Then dump some more structures you can get hold of?

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Kernel crash during video transcoding

2020-08-16 Thread Hans Petter Selasky

On 2020-08-16 17:28, Alexandre Levy wrote:

Now at intel_freebsd.c:193 (frame #17) the driver calls
vm_page_busy_acquire(m, VM_ALLOC_WAITFAIL). 'm' is the page grabbed from
vm_obj of the calling frame.


Can you check if "m" is NULL at this point?

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Kernel crash during video transcoding

2020-08-10 Thread Hans Petter Selasky

Hi,

On 2020-08-10 12:59, Alexandre Levy wrote:

Looking at the code, the error happens during the call to VM_OBJECT_WLOCK
(memory page locking for write ?) in the intel_freebsd.c (see [1] below).
I'm out for a few days but I'll try to dig more into it when I'm back next
weekend although I have no experience in the drm-devel-kmod codebase. In
the meantime if you have any suggestions on debugging this further I'm
happy to follow them.


The problem is likely that the vm_obj is NULL.

I think I recall that this function is special and can only be called 
from a certain context, unlike in Linux. Will need the full backtrace 
with line numbers in order to debug this.


--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Kernel crash during video transcoding

2020-08-10 Thread Hans Petter Selasky

On 2020-08-10 12:59, Alexandre Levy wrote:

I could reproduce with GENERIC kernel and i915 kms compiled with DEBUG and
I got this additional info (still no crash dump though) :


If you have the debugger enabled, you will need to type "dump" in the 
crash handler to get the core-dump.


--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: somewhat reproducable vimage panic

2020-08-10 Thread Hans Petter Selasky

On 2020-07-23 21:26, Bjoern A. Zeeb wrote:
That’ll probably work;  still, the deferred teardown work seems wrong to 
me;  I haven’t investigated;  the patch kind-of says exactly that as 
well: if “wait until deferred stuff is done” is all we are doing, why 
can we not do it on the spot then?


Hi Bjoern,

Trying to move the discussion over to Phabricator at:
https://reviews.freebsd.org/D24914

The answer to your question I believe is this commit:

https://svnweb.freebsd.org/base/head/sys/netinet/in_mcast.c?revision=333175=markup

It affects both IPv4 and IPv6.

I know that sometimes multicast entries can be freed from timer 
callbacks. I think having a task, probably one is enough, for network 
related configuration is acceptable. With D24914 there will be two 
threads to teardown which is probably overkill, but anyway makes a solid 
solution for now.


I don't know why Stephen didn't think about draining those tasks. I know 
some people are not actively using VIMAGE and that might be the reason.


--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Kernel crash during video transcoding

2020-08-10 Thread Hans Petter Selasky

On 2020-08-10 10:41, Alexandre Levy wrote:

I'm recompiling the kernel using GENERIC at the moment but I'm not sure how
to enable debugging in i915 kms, there is no compile option for that, am I
missing something ?


Type:

make config

Before building the i915kms port, then there should be a DEBUG option 
you can select.


--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Kernel crash during video transcoding

2020-08-10 Thread Hans Petter Selasky

Hi,

On 2020-08-10 00:19, Alexandre Levy wrote:

Hi,

I installed the port drm-devel-kmod for Plex to be able to transcode videos
using the integrated GPU of my Intel Celeron G5900.

I'm running r364031 and the kernel is compiled with GENERIC-NODEBUG profile.

Transcoding has been working fine for quite a while now but one video
transcoding is causing a kernel panic that is reproducible all the time
with that particular video. It seems like it's caused by the i915kms module
(call of i915_gms_fault() in the stack) :


If you compile the kernel using GENERIC and then enable debugging in the 
i915 kms and reproduce, we might get a more clear picture!


It is a so called NULL pointer you've experienced.

--HPS



Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0xdf
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80bdd2b4
stack pointer   = 0x0:0xfe00d2be56d0
frame pointer   = 0x0:0xfe00d2be56d0
code segment= base 0x0, limit 0xf, type 0x1b
 = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 4611 (Plex Transcoder)
trap number = 12
panic: page fault
cpuid = 0
time = 1596976796
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe00d2be5390
vpanic() at vpanic+0x182/frame 0xfe00d2be53e0
panic() at panic+0x43/frame 0xfe00d2be5440
trap_fatal() at trap_fatal+0x387/frame 0xfe00d2be54a0
trap_pfault() at trap_pfault+0x4f/frame 0xfe00d2be54f0
trap() at trap+0x271/frame 0xfe00d2be5600
calltrap() at calltrap+0x8/frame 0xfe00d2be5600
--- trap 0xc, rip = 0x80bdd2b4, rsp = 0xfe00d2be56d0, rbp =
0xfe00d2be56d0 ---
_rw_wowned() at _rw_wowned+0x4/frame 0xfe00d2be56d0
vm_page_busy_acquire() at vm_page_busy_acquire+0x141/frame
0xfe00d2be5710
remap_io_mapping() at remap_io_mapping+0x120/frame 0xfe00d2be5760
i915_gem_fault() at i915_gem_fault+0x25f/frame 0xfe00d2be57d0
linux_cdev_pager_populate() at linux_cdev_pager_populate+0x11b/frame
0xfe00d2be5840
vm_fault() at vm_fault+0x3d1/frame 0xfe00d2be5950
vm_fault_trap() at vm_fault_trap+0x60/frame 0xfe00d2be5990
trap_pfault() at trap_pfault+0x19c/frame 0xfe00d2be59e0
trap() at trap+0x3f1/frame 0xfe00d2be5af0
calltrap() at calltrap+0x8/frame 0xfe00d2be5af0
--- trap 0xc, rip = 0x80296659a, rsp = 0x7fffbd38, rbp = 0x80fc0 ---
KDB: enter: panic

I don't see any crash dump in /var/crash despite having the right
configuration and I should have enough space on my swap device (128GB USB
drive) :

$ cat /etc/rc.conf | grep dump
dumpdev="AUTO"

$ swapinfo
Device  1K-blocks UsedAvail Capacity
/dev/gpt/crash0 1213070960 121307096 0%

$ cat /etc/fstab
/dev/gpt/crash0 noneswapsw  0   0

$ dumpon -l
gpt/crash0

Not sure why no dump was generated, is it because the kernel was compiled
with the GENERIC-NODEBUG profile ? However I see various KDB options in the
GENERIC profile that are inherited by GENERIC-NODEBUG.

Happy to recompile the kernel with GENERIC profile if it's required.

Thank you.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: somewhat reproducable vimage panic

2020-08-04 Thread Hans Petter Selasky

On 2020-07-25 21:21, John-Mark Gurney wrote:

So far so good...  I am getting these on occasion:
in6_purgeaddr: err=65, destination address delete failed


Maybe you could add a "kdb_backtrace()" call when that error happens?

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: KiCad is horrible on CURRENT

2020-07-29 Thread Hans Petter Selasky

On 2020-07-29 09:52, Poul-Henning Kamp wrote:

I updated to current three days ago:

13.0-CURRENT #0 r363533M: Sun Jul 26 08:39:48 UTC 2020

When I start cad/kicad (which I have not done in some time), the
gui is horribly lagging and often downright confused about
the cursors whereabouts.

I've tried switching between "fall-back" and "accellerated"
in kicad, but there does not seem to be any qualitative
difference.

One of the few diagnostics I see related to this is:

07:33:34: Debug: window wxScrolledWindow(0x81a3f8000, ) lost focus even 
though it didn't have it

I have no idea if this is a kicad, Xorg or libinput related.

In my Xorg log I have a lot of (rate-limited):

 SynPS/2 Synaptics TouchPad: kernel bug: Touch jump detected and 
discarded.



Try to install "xev" and see if the log is full of events.

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: somewhat reproducable vimage panic

2020-07-27 Thread Hans Petter Selasky

On 2020-07-25 21:21, John-Mark Gurney wrote:

Yeah, agreed. I think hselasky has a better fix:
https://reviews.freebsd.org/D24914

I just saw his e-mail in a different thread.

I'm testing out this patch now, and let people know how it goes.. It'll
be nice to not have to worry about these panics..

So far so good...  I am getting these on occasion:
in6_purgeaddr: err=65, destination address delete failed

But that's more that the patch prevented a panic.

The other issue that I'm now seeing is that because we don't forcefully
clear out the multicast task, it can take a good 20+ seconds from the
time a jail is destroyed to the interface appearing again in vnet0.
Pretty sure this is related to the dmesg from above...


Hi,

D24914 just ensures proper draining. Feel free to accept the patch if 
you think I should submit it. It fixes some problems seen at work too!


--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Current panics on connecting disks to a LSI-3108 controller

2020-07-14 Thread Hans Petter Selasky

On 2020-07-14 02:39, Willem Jan Withagen wrote:

I guess that there are reason not to do this by default.


I've seen the exact same panic.

+1 for fixing it :-)

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: slow USB 3.0 on -current

2020-07-13 Thread Hans Petter Selasky

On 2020-07-13 03:02, John-Mark Gurney wrote:

MB means megabytes.. I would use Mbps for bits...  so, on Win10 and
NetBSD, I'm able to get 100 MBytes/sec on Win10/NetBSD, and FreeBSD,
I'm only getting a tenth the capability of gige at 9-10 MBytes/sec...

I'll note that fetch reports numbers of MBps, which is one of the tools
I've been using for testing.


Hi,

Could you have a look at the traffic pattern, when using iperf?

usbdump -i usbusX -f Y

Where X and Y are the numbers after ugen .

Many of the network USB drivers are single buffered, because that's what 
older USB host controllers support. Then the IRQ rate 8000 for USB 
2.0/3.0 and 1000 for USB 1.0, limits the number of packets per second.


--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: slow USB 3.0 on -current

2020-07-12 Thread Hans Petter Selasky

On 2020-07-12 00:44, John-Mark Gurney wrote:

Hello,

I'm having issues getting good ethernet performance from a USB ethernet
adapter (ure) under FreeBSD on an HP EliteDesk 705 G2 Mini[1].  It's an
AMD PRO A10-8700B based system using the AMD A78 FCH chipset.

Under FreeBSD -current (r362596), 12.1-R and 11.4-R, the RealTek USB
adapter only gets around 10MB/sec performance.  During the transfer,
the CPU usage is only around 3-5%, so it's definitely not CPU bound.

I have tested Windows 10 and NetBSD 9.0 performance, and both provide
100MB/sec+ w/o troubles.

I have attached dmesg from both FreeBSD -current and NetBSD 9.0.

Any hints on how to fix this?

This may be related, but I'm also having issues w/ booting when I have
both a SD USB 2.0 card reader AND the ure plugged into USB 3.0 ports.

If I move the SD card reader to USB 2.0, the umass device will attach
and work.  I have also attached a clip of the dmesg from that
happening.

Has anyone else seen this issue?  Ideas or thoughts on how to resolve
the performance issues?


Hi,

Can you check the output from ifconfig. What is the actual link speed. I 
suspect it has something to do with the MII bus code/implementation.


Also check output from "vmstat -i" during usage to see if the number of 
IRQ/s is low.


--HPS

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: OverDrive 1000 head -r360311 -> r363021 upgrade: USB & Ethernet disappeared, "usb_needs_explore_all: no devclass" (Now: artifact.ci bisect)

2020-07-11 Thread Hans Petter Selasky

On 2020-07-11 10:32, Mark Millard via freebsd-arm wrote:

Author: hselasky
Date: Mon Jul  6 08:50:11 2020
New Revision: 362953


This revision is likely not involved.

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Panic on mlx5en.

2020-06-16 Thread Hans Petter Selasky

On 2020-06-16 13:36, Santiago Martinez wrote:


While here, do you know if there is any ongoing effort to add NETMAP 
support to mlx?


Not for FreeBSD.

You might want to look at RoCE and infiniband support for userspace. It 
should support raw ethernet queues aswell.


--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Panic on mlx5en.

2020-06-15 Thread Hans Petter Selasky

On 2020-06-15 15:49, Santiago Martinez wrote:
Hi Hans Petter,  At the moment I'm running r362037 but can reinstall, 
patch/rebuild as needed as is just a lab machine.


This revision is not good. There are two things you can try:

1) Try a kernel newer than r362139.

2) Copy sys/sys/tree.h from 12-stable and put it into the 13-current 
tree at the same location and re-build the kernel.


--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Panic on mlx5en.

2020-06-15 Thread Hans Petter Selasky

On 2020-06-15 15:49, Santiago Martinez wrote:
Hi Hans Petter,  At the moment I'm running r362037 but can reinstall, 
patch/rebuild as needed as is just a lab machine.


One more question: Did you check if the firmware is up-to-date on the 
card? Are you able to extract the mce.N.xxx. sysctl from 12.x ?


sysctl -a | grep fw

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Panic on mlx5en.

2020-06-15 Thread Hans Petter Selasky

On 2020-06-15 15:31, Santiago Martinez wrote:

Hi Peter, yes Im using the latest one.



Can you tell me which version you are at?

--HPS

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Panic on mlx5en.

2020-06-15 Thread Hans Petter Selasky

On 2020-06-15 11:12, Santiago Martinez wrote:
Hi everyone, while doing some tests for an MRSAS panic I hit another one 
on mlx5en.


The device is a LenovoSR655 with 2xMellanox NIC.

1 - Mellanox CX-4 Lx 10/25GbE SFP28 2-port OCP Ethernet Adapter
2 - Mellanox CX-4 Lx 10/25GbE SFP28 2-port PCIe Ethernet Adapter

This only happens only with current, tried different snapshots and the 
same in all.

On 12.1 works without a problem.

Trace (please not that is OCR+ manual corrections):

Tracing pid 2288 tid 182178 td @8xfeB385fe6500
kdb_enter() at kbd_inter+0x37/frame 0xfe0386030ba0
vpanic() at vpanic+0x19e/frame 0xfe0386030bf0
panic() at panic+0x43/frame 0xfe038630c50
trap_fatal() at trap_fatal+0x387/frame 0xfe0386030cb0
trap() at trap+0x80/frame Bxfe0386030dc0
calltrap() at calltrap+0x80/frame Bxfed386830dc0
--- trap 0x9, rip = 0xfff8275c060, rsp = 0xfe0386030e90, rbp = 
0xfe0386030e90 ---
linux_root_RB_INSERT_COLOR() at linux_root_RB_INSERT COLOR+0x40/frame 
0xfe0386030f60

give_pages() at give pages+0x163/frame 0xfe0386830f20
mlx5_satisfy_startup_pages() at mlx5_satisfy_startup_pages+0x76/frame 
0xfe0386030f60

mlx5_load_one () at mlx5_load_one+0x6b7/frame 0xfe0386031080
init_one() at init_one+0x12d5/frame 0xfe03860310f0
linux_pci_attach_device() at linux_pci_attach device+0x573/frame 
0xfe0386031150

device_attach() at device_attach+0x3ca/frame 0xfe0386031190
device_probe_and_attach() at device_probe_and_attach+0x70/frame 
0xfe03860311c0

pci_driver_added() at pci_driver_added+0xf6/frame 0xfe0386031200
devclass_driver_added() at devclass_driver_added+0x39/frame 
0xfe0386031240

devclass_add_driver() at devclass_add_driver+0x147/frame 0xfe0386031280
_linux_pci_register_driver() at _linux_pci_register_driver+0xc9/frame 
0xfe03860312a0




Are you using the latest version of kernel & mlx5en as of today? There 
was a regression issue with the rbtree.h implementation which recently 
was fixed.


--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: panic: page fault head/amd64 @r361830

2020-06-05 Thread Hans Petter Selasky

On 2020-06-05 15:41, David Wolfskill wrote:

My build machine had no issues with the upgrade from r361784 to r361830,
but my laptop panicked during the transition from single- to multi-user
mode, just after bpf was attached.

Rebooting from the old kernel worked; trying to boot from r361830
failed again with similar symptoms, and the laptop normally runs
stable/12 (r361761 yesterday; r361831 today), so it seems to be an
issue in head.

The build machine isn't a DHCP client, and doesn't run ipfw; the laptop
differs (in both respects).

The backtrace (from the core.txt file:

...
<118>Mounting local filesystems:
linprocfs registered
<118>.
<118>ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib 
/usr/local/lib/R/lib /usr/local/lib/compat /usr/local/lib/gcc9 /usr/l
ocal/lib/graphviz /usr/local/lib/mysql /usr/local/lib/perl5/5.30/mach/CORE 
/usr/local/lib/qt5 /usr/local/llvm80/lib /usr/local/llvm90/lib
/usr/local/share/chromium
<118>32-bit compatibility ldconfig path: /usr/lib32 /usr/lib32/compat 
/usr/local/lib32/compat
<118>Setting hostname: localhost.
<118>Setting up harvesting: 
PURE_RDRAND,[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED
<118>Feeding entropy: .
<6>wlan0: bpf attached

<6>wlan0: bpf attached

Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 03
fault virtual address   = 0x0
fault code  = supervisor read instruction, page not present
instruction pointer = 0x20:0x0
stack pointer   = 0x28:0xfe0fc08c3b08
frame pointer   = 0x28:0xfe0fc08c3b80
code segment= base 0x0, limit 0xf, type 0x1b
 = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (iwn0 net80211 taskq)
trap number = 12
panic: page fault
cpuid = 3
time = 1591362374
KDB: stack backtrace:
db_trace_self_wrapper() at 0x804a4afb = 
db_trace_self_wrapper+0x2b/frame 0xfe0fc08c37b0
vpanic() at 0x80b93452 = vpanic+0x182/frame 0xfe0fc08c3800
panic() at 0x80b93203 = panic+0x43/frame 0xfe0fc08c3860
trap_fatal() at 0x81069b07 = trap_fatal+0x387/frame 0xfe0fc08c38c0
trap_pfault() at 0x81069ba9 = trap_pfault+0x99/frame 0xfe0fc08c3920
trap() at 0x810691a5 = trap+0x2a5/frame 0xfe0fc08c3a30
calltrap() at 0x8103edb8 = calltrap+0x8/frame 0xfe0fc08c3a30
--- trap 0xc, rip = 0, rsp = 0xfe0fc08c3b08, rbp = 0xfe0fc08c3b80 ---
??() at 0/frame 0xfe0fc08c3b80
taskqueue_thread_loop() at 0x80bf3214 = 
taskqueue_thread_loop+0x94/frame 0xfe0fc08c3bb0
fork_exit() at 0x80b503c0 = fork_exit+0x80/frame 0xfe0fc08c3bf0
fork_trampoline() at 0x8103fdfe = fork_trampoline+0xe/frame 
0xfe0fc08c3bf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic

__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55  __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct 
pcpu,
(kgdb) #0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1  doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:394
#2  0x804a1eaa in db_dump (dummy=,
 dummy2=, dummy3=, dummy4=)
 at /usr/src/sys/ddb/db_command.c:575
#3  0x804a1c6c in db_command (last_cmdp=,
 cmd_table=, dopager=1) at /usr/src/sys/ddb/db_command.c:482
#4  0x804a19dd in db_command_loop ()
 at /usr/src/sys/ddb/db_command.c:535
#5  0x804a4c48 in db_trap (type=, code=)
 at /usr/src/sys/ddb/db_main.c:253
#6  0x80bdde34 in kdb_trap (type=3, code=0, tf=)
 at /usr/src/sys/kern/subr_kdb.c:699
#7  0x810696b8 in trap (frame=0xfe0fc08c36e0)
 at /usr/src/sys/amd64/amd64/trap.c:578
#8  
#9  kdb_enter (why=0x8122ff12 "panic", msg=)
 at /usr/src/sys/kern/subr_kdb.c:486
#10 0x80b9346e in vpanic (fmt=, ap=)
 at /usr/src/sys/kern/kern_shutdown.c:902
#11 0x80b93203 in panic (
 fmt=0x81c7f298  "\326/\037\201\377\377\377\377")
 at /usr/src/sys/kern/kern_shutdown.c:839
#2  0x804a1eaa in db_dump (dummy=,
 dummy2=, dummy3=, dummy4=)
 at /usr/src/sys/ddb/db_command.c:575
#3  0x804a1c6c in db_command (last_cmdp=,
 cmd_table=, dopager=1) at /usr/src/sys/ddb/db_command.c:482
#4  0x804a19dd in db_command_loop ()
 at /usr/src/sys/ddb/db_command.c:535
#5  0x804a4c48 in db_trap (type=, code=)
 at /usr/src/sys/ddb/db_main.c:253
#6  0x80bdde34 in kdb_trap (type=3, code=0, tf=)
 at /usr/src/sys/kern/subr_kdb.c:699
#7  0x810696b8 in trap (frame=0xfe0fc08c36e0)
 at /usr/src/sys/amd64/amd64/trap.c:578
#8  
#9  kdb_enter (why=0x8122ff12 "panic", msg=)
 at /usr/src/sys/kern/subr_kdb.c:486
#10 0x80b9346e in vpanic (fmt=, ap=)
 at /usr/src/sys/kern/kern_shutdown.c:902
#11 0x80b93203 in panic (
 fmt=0x81c7f298  

Re: Resume almost never works Dell XPS 9370

2020-06-05 Thread Hans Petter Selasky

On 2020-06-05 06:56, Malcolm Matalka wrote:

I'm using the i915kms driver and resuming from suspend almost never
works.  What I get is a blank screen with a rectangle cursor in the top
right, like what the screen looks like for that split second when X11
starts.  It is then stuck and I have to force shutdown with the physical
button.

I am not sure but I feel like this happens more frequently after I've
been running bhyve but I can't guarantee that's actually causally
related.

The only special thing I do that I'm aware of is I turn off my usb when
I suspend and back on when I resume, I don't know if this is possibly
related.

usbconfig list | cut -f 1 -d ':' | xargs -n1 -I'{}' usbconfig '{}' power_save

Any tips on what to do?



Which version of kernel and kms driver are you using?

--HPS

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: acpi timer reads all ones [Was: efirtc + atrtc at the same time]

2020-05-27 Thread Hans Petter Selasky

On 2020-05-27 23:38, John Baldwin wrote:

No.  I get that constantly on a desktop that never suspends/resumes.
It only started after upgrading to 12.0.


If you have time, could you investigate why the USB host controllers 
Root HUB PCI register flips to -1U ? Which cause these spurious events 
... Maybe some kind of PCI power save feature which is not timed 
correctly ...


--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: acpi timer reads all ones [Was: efirtc + atrtc at the same time]

2020-05-27 Thread Hans Petter Selasky

On 2020-05-27 15:41, Justin Hibbits wrote:

On Wed, 27 May 2020 06:27:16 -0700
John Baldwin  wrote:


On 5/27/20 2:39 AM, Andriy Gapon wrote:

On 27/05/2020 11:13, Andriy Gapon wrote:

I added more diagnostics and it seems to support the idea that the
problem is related to I/O cycles and bridges.

ACPI timer suddenly starts returning 0x and that lasts for
tens of microseconds before the timer goes back to returning
normal values with an expected increase.
AMD provides a proprietary way to access ACPI registers via MMIO
(0xfed808xx). That mechanism is unaffected, ACPI timer register
always returns good values.

The problem seems to happen when restoring configuration of a
particular PCI bridge.  What's interesting is that the bridge
decodes one memory range and one I/O range.

Looking at pci_cfg_restore() I wonder if it is wise to restore
PCIR_COMMAND so early.  Could it be that after the resume the
bridge is configured with a wrong I/O range (e.g., too wide) and
by writing PCIR_COMMAND we enable that decoding. So, the bridge
steals I/O cycles destined for ACPI support hardware.  If there is
nothing behind the bridge to handle those ports, then we get those
bad readings. Once the bridge configuration is fully restored, the
I/O handling goes back to normal.


 From what I see, this looks like a BIOS bug.
Upon resume, it swaps window configurations of pcib1 and pcib2
(until FreeBSD restores them).  pcib1 originally does not have an
I/O window.  So, BIOS programs both base and limit of pcib2 I/O
window to zero.   When FreeBSD writes its command register to
enable I/O decoding it starts claiming 0x0 - 0xFFF I/O port range.
That covers the ACPI ports at 0x8xx.

Some printf-s.
 From (verbose) boot time:
pcib1:   domain0
pcib1:   secondary bus 1
pcib1:   subordinate bus   1
pcib1:   memory decode 0xfea0-0xfeaf
pcib2:   domain0
pcib2:   secondary bus 2
pcib2:   subordinate bus   2
pcib2:   I/O decode0xf000-0x
pcib2:   memory decode 0xfe90-0xfe9f

My printf-s from resume time:
pcib1: old I/O base (low): 0xf1
pcib1: old I/O base (high): 0x0
pcib1: old I/O limit (low): 0x1
pcib1: old I/O limit (high): 0x0
pcib2: old I/O base (low): 0x1
pcib2: old I/O base (high): 0x0
pcib2: old I/O limit (low): 0x1
pcib2: old I/O limit (high): 0x0


The "solution" I think is to have resume be multi-pass and to resume
all the bridges first before trying to resume leaf devices (including
timers), but that's a fair bit of work.  It might be that we just
need to resume timer interrupts later after the new-bus resume (I
think we currently do it before?), though the reason for that was to
allow resume methods in devices to sleep (I'm not sure if any do).



That sounds like a good fit for https://reviews.freebsd.org/D203 .
Someone (TM) just needs to take it over the finish line... 6 years
later.


Is this perhaps related to:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


iflib and options RSS is a no go for igbX

2020-05-26 Thread Hans Petter Selasky

Hi,

I just found a bug where outgoing TCP connections over igb0 doesn't work 
because likely the software computed hash is wrong, so the incoming 
packets get dropped because they are received on the wrong queue.


It is the management port, so I'm just using this hack for now:

dev.igb.0.iflib.override_nrxqs=1
dev.igb.0.iflib.override_ntxqs=1

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: r359627 is panicked with 'softdep_setup_blkfree: not free'

2020-04-06 Thread Hans Petter Selasky

On 2020-04-06 14:50, Masachika ISHIZUKA wrote:

   I'm using r359627M. (r359627 with mount_udf2).
   It is panicked with 'softdep_setup_blkfree: not free'.

   Panic log was stored as follows.


   Sorry, this panic was my mistake.
   I forgot to update drm-current-kmod.

old% pkg info drm-current-kmod
[snip]
Annotations:
FreeBSD_version: 1300084 <--- old
[snip]

old# pkg install -f drm-current-kmod
new% pkg info drm-current-kmod
[snip]
Annotations:
FreeBSD_version: 1300088
[snip]

   This works fine.


   The panic was occured again.
   Crash dump was the same.
   To reinstall drm-current-kmod was not fixed this issue.



Issue probably will go away if you boot to single-user-mode and run fsck 
-y before booting the system. Regardless, kernel should not panic.


--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: USB microphones with FreeBSD-CURRENT

2020-03-28 Thread Hans Petter Selasky

On 2020-03-28 07:31, Graham Perrin wrote:

I can't get web browsers to recognise USB microphones.

USB output (e.g. to my headphones) is OK.

USB input (e.g. from the microphone part of the headphones) is not.

Any suggestions?

 From :



What are the mixer values?

mixer -f /dev/mixerN

Are you sure the volume is set high enough?

--HPS

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: panic: Assertion in_epoch(net_epoch_preempt) failed, r357793

2020-02-12 Thread Hans Petter Selasky

On 2020-02-12 18:22, Gleb Smirnoff wrote:


Hans already checked in his patch. Great!



You're welcome. Glad it worked.

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: panic: Assertion in_epoch(net_epoch_preempt) failed, r357793

2020-02-12 Thread Hans Petter Selasky

On 2020-02-12 10:10, y...@mm.st wrote:

Hans Petter Selasky wrote:

Hi,

Does the attached patch fix the issue?


It seems to help, yes, at least no panic right after the boot.


Let us know if this happens again. There is currently some ongoing work 
in this area.


https://svnweb.freebsd.org/changeset/base/357800

--HPS

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: panic: Assertion in_epoch(net_epoch_preempt) failed, r357793

2020-02-12 Thread Hans Petter Selasky

Hi,

Does the attached patch fix the issue?

--HPS
Index: sys/net/iflib.c
===
--- sys/net/iflib.c	(revision 357799)
+++ sys/net/iflib.c	(working copy)
@@ -6060,6 +6060,7 @@
 		gtask = >ifc_txqs[qid].ift_task;
 		tqg = qgroup_if_io_tqg;
 		fn = _task_fn_tx;
+		GROUPTASK_INIT(gtask, 0, fn, q);
 		break;
 	case IFLIB_INTR_RX:
 		q = >ifc_rxqs[qid];
@@ -6066,6 +6067,7 @@
 		gtask = >ifc_rxqs[qid].ifr_task;
 		tqg = qgroup_if_io_tqg;
 		fn = _task_fn_rx;
+		NET_GROUPTASK_INIT(gtask, 0, fn, q);
 		break;
 	case IFLIB_INTR_IOV:
 		q = ctx;
@@ -6072,11 +6074,11 @@
 		gtask = >ifc_vflr_task;
 		tqg = qgroup_if_config_tqg;
 		fn = _task_fn_iov;
+		GROUPTASK_INIT(gtask, 0, fn, q);
 		break;
 	default:
 		panic("unknown net intr type");
 	}
-	GROUPTASK_INIT(gtask, 0, fn, q);
 	if (irq != NULL) {
 		err = iflib_irq_set_affinity(ctx, irq, type, qid, gtask, tqg,
 		q, name);
@@ -6136,7 +6138,7 @@
 	iflib_fast_intr_rxtx, NULL, info, name);
 	if (err != 0)
 		return (err);
-	GROUPTASK_INIT(gtask, 0, fn, q);
+	NET_GROUPTASK_INIT(gtask, 0, fn, q);
 	res = irq->ii_res;
 	taskqgroup_attach(tqg, gtask, q, dev, res, name);
 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: easy way to work around a lack of a direct map on i386

2020-02-01 Thread Hans Petter Selasky

On 2020-01-31 13:31, Konstantin Belousov wrote:

On Fri, Jan 31, 2020 at 10:13:58AM +0100, Hans Petter Selasky wrote:

On 2020-01-31 00:37, Konstantin Belousov wrote:

On Thu, Jan 30, 2020 at 11:23:02PM +, Rick Macklem wrote:

Hi,

The current code for KERN_TLS uses PHYS_TO_DMAP()
to access unmapped external pages on m_ext.ext_pgs
mbufs.
I also need to do this to implement RPC-over-TLS.

The problem is that some arches, like i386, don't
support PHYS_TO_DMAP().

Since it appears that there will be at most 4 pages on
one of these mbufs, my thinking was...
- Acquire four pages of kva from the kernel_map during
booting.
- Then just use pmap_qenter() to fill in the physical page
mappings for long enough to copy the data.

Does this sound reasonable?
Is there a better way?


Use sfbufs, they should work on all arches.  In essence, they provide MI
interface to DMAP where possible.  I do not remember did I bumped the
limit for i386 after 4/4 went in.

There is currently no limits for sfbufs use per subsystem, but I think it
is not very likely to cause too much troubles.  Main rule is to not sleep
waiting for more sfbufs if you already own one..


In the DRM-KMS LinuxKPI we have:

void *
kmap(vm_page_t page)
{
#ifdef LINUXKPI_HAVE_DMAP
 vm_offset_t daddr;

 daddr = PHYS_TO_DMAP(VM_PAGE_TO_PHYS(page));

 return ((void *)daddr);
#else
 struct sf_buf *sf;

 sched_pin();
 sf = sf_buf_alloc(page, SFB_NOWAIT | SFB_CPUPRIVATE);
 if (sf == NULL) {
 sched_unpin();
 return (NULL);
 }
 return ((void *)sf_buf_kva(sf));
#endif
}

void
kunmap(vm_page_t page)
{
#ifdef LINUXKPI_HAVE_DMAP
 /* NOP */
#else
 struct sf_buf *sf;

 /* lookup SF buffer in list */
 sf = sf_buf_alloc(page, SFB_NOWAIT | SFB_CPUPRIVATE);

 /* double-free */
 sf_buf_free(sf);
 sf_buf_free(sf);

 sched_unpin();
#endif
}

I think that is the fastest way to do this.


So the kmap address is only valid on the CPU that called the function ?
This is strange, I was not able to find mention of it in references to
kmap.


Yes, only on the current CPU. See the SFB_CPUPRIVATE flag.

--HPS

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: [HEADS UP] EPOCH breakage in [USB/PCI] network drivers after r357004

2020-01-31 Thread Hans Petter Selasky

Hi,

The USB WLAN drivers are now fixed, but there are some more to go, and 
Gleb has put up a patch for review:


https://reviews.freebsd.org/D23408

After those drivers have been resolved I will rebase:

https://reviews.freebsd.org/D23348

Which then will contain a list of remaining network driver EPOCH issues.

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: easy way to work around a lack of a direct map on i386

2020-01-31 Thread Hans Petter Selasky

On 2020-01-31 00:37, Konstantin Belousov wrote:

On Thu, Jan 30, 2020 at 11:23:02PM +, Rick Macklem wrote:

Hi,

The current code for KERN_TLS uses PHYS_TO_DMAP()
to access unmapped external pages on m_ext.ext_pgs
mbufs.
I also need to do this to implement RPC-over-TLS.

The problem is that some arches, like i386, don't
support PHYS_TO_DMAP().

Since it appears that there will be at most 4 pages on
one of these mbufs, my thinking was...
- Acquire four pages of kva from the kernel_map during
   booting.
- Then just use pmap_qenter() to fill in the physical page
   mappings for long enough to copy the data.

Does this sound reasonable?
Is there a better way?


Use sfbufs, they should work on all arches.  In essence, they provide MI
interface to DMAP where possible.  I do not remember did I bumped the
limit for i386 after 4/4 went in.

There is currently no limits for sfbufs use per subsystem, but I think it
is not very likely to cause too much troubles.  Main rule is to not sleep
waiting for more sfbufs if you already own one..


In the DRM-KMS LinuxKPI we have:

void *
kmap(vm_page_t page)
{
#ifdef LINUXKPI_HAVE_DMAP
vm_offset_t daddr;

daddr = PHYS_TO_DMAP(VM_PAGE_TO_PHYS(page));

return ((void *)daddr);
#else
struct sf_buf *sf;

sched_pin();
sf = sf_buf_alloc(page, SFB_NOWAIT | SFB_CPUPRIVATE);
if (sf == NULL) {
sched_unpin();
return (NULL);
}
return ((void *)sf_buf_kva(sf));
#endif
}

void
kunmap(vm_page_t page)
{
#ifdef LINUXKPI_HAVE_DMAP
/* NOP */
#else
struct sf_buf *sf;

/* lookup SF buffer in list */
sf = sf_buf_alloc(page, SFB_NOWAIT | SFB_CPUPRIVATE);

/* double-free */
sf_buf_free(sf);
sf_buf_free(sf);

sched_unpin();
#endif
}

I think that is the fastest way to do this.

--HPS

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


[HEADS UP] EPOCH breakage in [USB/PCI] network drivers after r357004

2020-01-28 Thread Hans Petter Selasky

Hi,

Currently 8 of 10 USB WLAN drivers are broken and multiple PCI ones too. 
I have some patches, which I would like to have more attention that try 
to address these issues. The patches are currently being worked on.


1) https://reviews.freebsd.org/D23348
2) https://reviews.freebsd.org/D23347

If you have some comments please sign up!

I hope all issues will be addressed by end of week.

--HPS


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Powerd Panic

2020-01-24 Thread Hans Petter Selasky

On 2020-01-24 14:38, Cy Schubert wrote:

In message <629a6d48-cf47-e76b-81a0-db29d2400...@selasky.org>, Hans Petter
Sela
sky writes:

Hi,

I think this patch will fix your issue. Can you check?
https://svnweb.freebsd.org/changeset/base/357050

Look like td->td_oncpu is invalid.



 pc = cpuid_to_pcpu[td->td_oncpu]; /* pcpu_find(td->td_oncpu); */

 rm_tracker_add(pc, tracker);




And thanks for running -current ;-)


That patch is already there. All my machines are at r357066.



OK,

so maybe there are more corner cases to that patch.

Adding Mark.

Could you compile a kernel with debugging symbols, get a core dump and then:

print td->td_oncpu
print pc

from kgdb83 ?

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Powerd Panic

2020-01-24 Thread Hans Petter Selasky

Hi,

I think this patch will fix your issue. Can you check?
https://svnweb.freebsd.org/changeset/base/357050

Look like td->td_oncpu is invalid.



pc = cpuid_to_pcpu[td->td_oncpu]; /* pcpu_find(td->td_oncpu); */

rm_tracker_add(pc, tracker);




And thanks for running -current ;-)

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: panic: Assertion in_epoch(net_epoch_preempt) failed at ... src/sys/net/if.c:3694

2020-01-24 Thread Hans Petter Selasky

On 2020-01-24 09:59, Hans Petter Selasky wrote:

On 2020-01-24 09:41, Masachika ISHIZUKA wrote:

21.01.2020, 20:10, "Nick Hibma" :

That (with the return added, thanks Cy) worked like a charm.

Got committed in r357038.
Thank you for the report!


   Hi.

   My machine was panicked on r357061 with in_epoch in netisr.c.
   I can not capture screen.


   Screenshot was uploaded to 
https://www.ish.org/files/panic-r357061.jpeg




Looks like the WLAN subsystem needs some patches for EPOCH().

Gleb, did you do a "grep -r" for relevant functions before committing 
the recent EPOCH changes?


Can you try these two patches:
https://reviews.freebsd.org/D23347
https://reviews.freebsd.org/D23348


--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: panic: Assertion in_epoch(net_epoch_preempt) failed at ... src/sys/net/if.c:3694

2020-01-24 Thread Hans Petter Selasky

On 2020-01-24 09:41, Masachika ISHIZUKA wrote:

21.01.2020, 20:10, "Nick Hibma" :

That (with the return added, thanks Cy) worked like a charm.

Got committed in r357038.
Thank you for the report!


   Hi.

   My machine was panicked on r357061 with in_epoch in netisr.c.
   I can not capture screen.


   Screenshot was uploaded to https://www.ish.org/files/panic-r357061.jpeg



Looks like the WLAN subsystem needs some patches for EPOCH().

Gleb, did you do a "grep -r" for relevant functions before committing 
the recent EPOCH changes?


--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Powerd Panic

2020-01-24 Thread Hans Petter Selasky

On 2020-01-24 08:01, Cy Schubert wrote:

Let's try this again, this time with a subject line. It's late, almost bed
time and I'm forgetting subject lines. 

Hi,

Has anyone seen this before? It started happening on two of my machines
this evening. Both machines are AMD (not intel). In both cases powerd was
caught with its hand in the cookie jar.

Fatal trap 12: page fault while in kernel mode^M
cpuid = 3; apic id = 03^M
fault virtual address   = 0x90^M
fault code  = supervisor read data, page not present^M
instruction pointer = 0x20:0x8068b018^M
stack pointer   = 0x28:0xfe0066ff99e0^M
frame pointer   = 0x28:0xfe0066ff99e0^M
code segment= base 0x0, limit 0xf, type 0x1b^M
 = DPL 0, pres 1, long 1, def32 0, gran 1^M
processor eflags= interrupt enabled, resume, IOPL = 0^M
current process = 2781 (powerd)^M
trap number = 12^M
panic: page fault^M
cpuid = 3^M
time = 1579843504^M
KDB: stack backtrace:^M
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe0066ff9650^M
vpanic() at vpanic+0x185/frame 0xfe0066ff96b0^M
panic() at panic+0x43/frame 0xfe0066ff9710^M
trap_fatal() at trap_fatal+0x386/frame 0xfe0066ff9770^M
trap_pfault() at trap_pfault+0x4f/frame 0xfe0066ff97e0^M
trap() at trap+0x288/frame 0xfe0066ff9910^M
calltrap() at calltrap+0x8/frame 0xfe0066ff9910^M
--- trap 0xc, rip = 0x8068b018, rsp = 0xfe0066ff99e0, rbp =
0xfe
0066ff99e0 ---^M
_rm_rlock() at _rm_rlock+0x58/frame 0xfe0066ff99e0^M
sysctl_root_handler_locked() at sysctl_root_handler_locked+0xde/frame
0xfe00
66ff9a20^M
sysctl_root() at sysctl_root+0x249/frame 0xfe0066ff9aa0^M
userland_sysctl() at userland_sysctl+0x178/frame 0xfe0066ff9b50^M
sys___sysctl() at sys___sysctl+0x5f/frame 0xfe0066ff9c00^M
amd64_syscall() at amd64_syscall+0x3a3/frame 0xfe0066ff9d30^M
fast_syscall_common() at fast_syscall_common+0x101/frame
0xfe0066ff9d30^M
--- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x2c034f9a, rsp =
0x7f
ffeb38, rbp = 0x7fffeb70 ---^M
Uptime: 2h12m24s^M
Dumping 2496 out of 8167 MB: (CTRL-C to abort) ..1%..11%..21%..31%..41%..51%
..61
%..71%..81%..91%^M
Dump complete^M



Fatal trap 12: page fault while in kernel mode^M
cpuid = 3; apic id = 03^M
fault virtual address   = 0x90^M
fault code  = supervisor read data, page not present^M
instruction pointer = 0x20:0x8068b018^M
stack pointer   = 0x28:0xfe004d2a79e0^M
frame pointer   = 0x28:0xfe004d2a79e0^M
code segment= base 0x0, limit 0xf, type 0x1b^M
 = DPL 0, pres 1, long 1, def32 0, gran 1^M
processor eflags= interrupt enabled, resume, IOPL = 0^M
current process = 2849 (powerd)^M
trap number = 12^M
panic: page fault^M
cpuid = 3^M
time = 1579847814^M
KDB: stack backtrace:^M
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe004d2a7650^M
vpanic() at vpanic+0x185/frame 0xfe004d2a76b0^M
panic() at panic+0x43/frame 0xfe004d2a7710^M
trap_fatal() at trap_fatal+0x386/frame 0xfe004d2a7770^M
trap_pfault() at trap_pfault+0x4f/frame 0xfe004d2a77e0^M
trap() at trap+0x288/frame 0xfe004d2a7910^M
calltrap() at calltrap+0x8/frame 0xfe004d2a7910^M
--- trap 0xc, rip = 0x8068b018, rsp = 0xfe004d2a79e0, rbp =
0xfe
004d2a79e0 ---^M
_rm_rlock() at _rm_rlock+0x58/frame 0xfe004d2a79e0^M
sysctl_root_handler_locked() at sysctl_root_handler_locked+0xde/frame
0xfe00
4d2a7a20^M
sysctl_root() at sysctl_root+0x249/frame 0xfe004d2a7aa0^M
userland_sysctl() at userland_sysctl+0x178/frame 0xfe004d2a7b50^M
sys___sysctl() at sys___sysctl+0x5f/frame 0xfe004d2a7c00^M
amd64_syscall() at amd64_syscall+0x3a3/frame 0xfe004d2a7d30^M
fast_syscall_common() at fast_syscall_common+0x101/frame
0xfe004d2a7d30^M
--- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x800434f9a, rsp =
0x7
fffeb38, rbp = 0x7fffeb70 ---^M
Uptime: 2h57m35s^M
Dumping 1823 out of 5095 MB: (CTRL-C to abort) ..1%..11%..21%..31%..41%..51%
..61
%..71%..81%..91%^M
Dump complete^M



Can you show regular dmesg. Maybe some driver failed loading, and some 
sysctls were leftover!


--HPS

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Can't reattach USB devices (Lenovo bug?)

2020-01-20 Thread Hans Petter Selasky

On 2020-01-20 13:12, Evilham wrote:

Hello,

at first I thought I had found a regression in CURRENT (2020-01-19), and 
now I'm not so sure since, before reporting I rolled back a recent BIOS 
upgrade and that got rid of the issue.


First of all, the hardware: Lenovo ThinkPad A485 (AMD Ryzen processor).

The issue (BIOS v1.28[1]) being that any USB device: would work on first 
plug, but if unplugged and plugged again, it wouldn't work (see dmesg 
below).


Downgrading to BIOS v1.24 results in the issue disappearing.

How should this be dealt with? Could this be something FreeBSD needs 
better support for? or is it entirely on Lenovo?

If the former, how can I help provide more information/testing(*)?
If the latter, should I inform Lenovo of the issue? If anyone has 
experience with that, I'd appreciate pointers as to how to provide them 
with information in a way that makes it somewhat likely that things get 
solved.


[1]: BIOS Release notes: 
https://download.lenovo.com/pccbbs/mobiles/r0wuj60w.txt
(*): Helping spot bugs and provide information/testing is why I'm 
running CURRENT after all


Just FTR: I also experienced random kernel panics [2] with versions 
v1.22 and v1.16 of the BIOS, so maybe Lenovo is being 
unreasonable/unreliable about BIOS upgrades.
In any case I am curious as to how other OS deal with this class of 
issues and how FreeBSD could (if possible at all) work better in these 
cases.


[2]: Kernel panic solved by BIOS upgrade (to v1.24) see: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239351


Also FTR, this was the contents of dmesg with BIOS v1.28 and CURRENT as 
of 2020-01-19:
(notice there are multiple disconnect and reconnect attempts of 
different devices)


ugen1.2:  at usbus1 (disconnected)
uhub4: at uhub1, port 1, addr 1 (disconnected)
ugen1.3:  at usbus1 (disconnected)
ukbd0: at uhub4, port 2, addr 2 (disconnected)
ukbd0: detached
uhid0: at uhub4, port 2, addr 2 (disconnected)
uhid0: detached
ugen1.4:  at usbus1 (disconnected)
uhub5: at uhub4, port 4, addr 3 (disconnected)
ugen1.5:  at usbus1 
(disconnected)

uhid1: at uhub5, port 1, addr 4 (disconnected)
uhid1: detached
ums0: at uhub5, port 1, addr 4 (disconnected)
ums0: detached
ukbd1: at uhub5, port 1, addr 4 (disconnected)
ukbd1: detached
uhub5: detached
uhub4: detached
ugen1.2:  at usbus1
uhub4 on uhub1
uhub4:  on usbus1
acpi_ec0: EcCommand: no response to 0x84
uhub4: 4 ports with 4 removable, self powered
acpi_ec0: EcCommand: no response to 0x84
acpi_ec0: EcCommand: no response to 0x84
acpi_ec0: GPE query failed: AE_NO_HARDWARE_RESPONSE


^^^ my best guess is this is ACPI related :-(

ACPI has own debugging flags and options.

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: M_TEMP trouble in 13.0-CURRENT #0 r355131M

2020-01-09 Thread Hans Petter Selasky

On 2020-01-09 16:16, Mark Johnston wrote:

Sorry, I committed a different patch in r356555 before seeing this.


I thought of your version first too.

You can decide, I think my version is more clean.

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: M_TEMP trouble in 13.0-CURRENT #0 r355131M

2020-01-09 Thread Hans Petter Selasky

On 2020-01-09 16:16, Mark Johnston wrote:

Also you should audit the code for zero-sized allocations, because upon
alloc, zero-sized is not counted, while on free it is.

Can you explain further?  A zero-sized allocation should be rounded up to
16 bytes in all paths.



If the zero-sized allocation is rounded to 16-bytes, I don't see any 
problem.


Thank you!

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: M_TEMP trouble in 13.0-CURRENT #0 r355131M

2020-01-09 Thread Hans Petter Selasky

Hi Jeff and Konstantin,

You have a logical breakage after the domainset patches for malloc. The 
size used for allocation statistics is not the same like for freeing 
causing messed up "vmstat -m".


Also you should audit the code for zero-sized allocations, because upon 
alloc, zero-sized is not counted, while on free it is.


See attached patch.

--HPS
diff --git a/sys/kern/kern_malloc.c b/sys/kern/kern_malloc.c
index eba9fc3e1ef..aab33873741 100644
--- a/sys/kern/kern_malloc.c
+++ b/sys/kern/kern_malloc.c
@@ -669,8 +669,10 @@ malloc_domain(size_t size, int *indxp, struct malloc_type *mtp, int domain,
 	krequests[size >> KMEM_ZSHIFT]++;
 #endif
 	va = uma_zalloc_domain(zone, NULL, domain, flags);
-	if (va != NULL)
+	if (__predict_true(va != NULL)) {
 		size = zone->uz_size;
+		malloc_type_zone_allocated(mtp, size, indx);
+	}
 	*indxp = indx;
 
 	return ((void *) va);
@@ -699,7 +701,8 @@ malloc_domainset(size_t size, struct malloc_type *mtp, struct domainset *ds,
 			ret = malloc_domain(size, , mtp, domain, flags);
 		} while (ret == NULL &&
 		vm_domainset_iter_policy(, ) == 0);
-		malloc_type_zone_allocated(mtp, ret == NULL ? 0 : size, indx);
+		if (__predict_false(ret == NULL))
+			malloc_type_zone_allocated(mtp, 0, indx);
 	} else {
 		/* Policy is handled by kmem. */
 		ret = malloc_large(, ds, flags);
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: M_TEMP trouble in 13.0-CURRENT #0 r355131M

2020-01-09 Thread Hans Petter Selasky

On 2020-01-09 11:12, Hans Petter Selasky wrote:

On 2020-01-09 10:59, Poul-Henning Kamp wrote:

I noticed yesterday that M_TEMP stats are screwed up, and rebooted my
laptop for reasons of safety.

However, it's back again now:

 critter phk> vmstat -m | grep temp
 temp 18446744073709546036 18014398509476380K   -   963239  
16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536


FreeBSD critter.freebsd.dk 13.0-CURRENT FreeBSD 13.0-CURRENT #0 
r355131M: Wed Nov 27 16:44:48 UTC 2019 
r...@critter.freebsd.dk:/usr/obj/freebsd/src/amd64.amd64/sys/GENERIC-NODEBUG  
amd64


I mentioned this on IRC yesterday and noted I had a "disk full" on
a tmpfs mount, but that can now be disregarded as a false lead.

On this kernel I have had an instance where X got killed for
out-of-swap, at a time where that certainly should not have been
the case.

Am I the only one seeing this ?



Hi,

2**64 - 18446744073709546036
ans =  6144

Someone likely freed to M_TEMP which were not supposed to free there.

You could use dtrace to narrow this down and you can also add a 
kdb_backtrace() for the first couple of users of free() when the stats 
is negative.


Else:

grep -r M_TEMP /usr/src/sys

And do an audit.

--HPS


I actually see the same (r356321M), but I think it is not harmful:

 temp 18446744073709545743 18014398509476107K   -89826 
16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536


--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: M_TEMP trouble in 13.0-CURRENT #0 r355131M

2020-01-09 Thread Hans Petter Selasky

On 2020-01-09 10:59, Poul-Henning Kamp wrote:

I noticed yesterday that M_TEMP stats are screwed up, and rebooted my
laptop for reasons of safety.

However, it's back again now:

 critter phk> vmstat -m | grep temp
 temp 18446744073709546036 18014398509476380K   -   963239  
16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536

FreeBSD critter.freebsd.dk 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r355131M: Wed 
Nov 27 16:44:48 UTC 2019 
r...@critter.freebsd.dk:/usr/obj/freebsd/src/amd64.amd64/sys/GENERIC-NODEBUG  
amd64

I mentioned this on IRC yesterday and noted I had a "disk full" on
a tmpfs mount, but that can now be disregarded as a false lead.

On this kernel I have had an instance where X got killed for
out-of-swap, at a time where that certainly should not have been
the case.

Am I the only one seeing this ?



Hi,

2**64 - 18446744073709546036
ans =  6144

Someone likely freed to M_TEMP which were not supposed to free there.

You could use dtrace to narrow this down and you can also add a 
kdb_backtrace() for the first couple of users of free() when the stats 
is negative.


Else:

grep -r M_TEMP /usr/src/sys

And do an audit.

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: head -r356109 on 32-bit powerpc (old PowerMac): Memory modified after free during late-stage of boot, most recently used by bus-sc

2019-12-29 Thread Hans Petter Selasky

On 2019-12-29 22:53, Mark Millard via freebsd-hackers wrote:

0xd2630510: at uma_zalloc_arg+0x1b4
0xd2630540: at malloc+0xfc
0xd2630580: at alloc_bounce_pages+0x7c
0xd26305c0: at bus_dmamap_create+0x1e8


Do you know what drivers are using bounce pages?

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: drm-current-kmod panics

2019-12-19 Thread Hans Petter Selasky

On 2019-12-19 20:12, Cy Schubert wrote:

In message , Hans Petter
Sela
sky writes:

On 2019-12-19 19:40, Cy Schubert wrote:

In message , Hans Petter
Sela
sky writes:

On 2019-12-19 17:50, Cy Schubert wrote:

Has anyone else had these since Dec 9?

<4>WARN_ON(!mutex_is_locked(>lock))WARN_ON(!mutex_is_locked(>
lock))
panic: page fault
cpuid = 1
time = 1576772837
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe007c98b930
vpanic() at vpanic+0x17e/frame 0xfe007c98b990
panic() at panic+0x43/frame 0xfe007c98b9f0
trap_fatal() at trap_fatal+0x386/frame 0xfe007c98ba50
trap_pfault() at trap_pfault+0x4f/frame 0xfe007c98bac0
trap() at trap+0x41b/frame 0xfe007c98bbf0
calltrap() at calltrap+0x8/frame 0xfe007c98bbf0
--- trap 0xc, rip = 0x242c52, rsp = 0x7fffbe70, rbp = 0x7fffbe90

--

-

Uptime: 59m7s

It is triggered through random keystrokes or mouse movements.


Looks like a double fault.

Did you recompile drm-current-kmod with the latest kernel sources?


Yes.




Are you able to get a full backtrace?


(kgdb) #0  __curthread () at /opt/src/svn-current/sys/amd64/include/pcpu_aux
.h:5
5
#1  doadump (textdump=1) at /opt/src/svn-current/sys/kern/kern_shutdown.c:39
2
#2  0x80690a2a in kern_reboot (howto=260)
 at /opt/src/svn-current/sys/kern/kern_shutdown.c:479
#3  0x80690ec6 in vpanic (fmt=, ap=)
 at /opt/src/svn-current/sys/kern/kern_shutdown.c:908
#4  0x80690ce3 in panic (fmt=)
 at /opt/src/svn-current/sys/kern/kern_shutdown.c:835
#5  0x80a31c06 in trap_fatal (frame=0xfe007c98bc00, eva=2928416)
 at /opt/src/svn-current/sys/amd64/amd64/trap.c:926
#6  0x80a31c5f in trap_pfault (frame=0xfe007c98bc00,
 usermode=, signo=, ucode=)
 at /opt/src/svn-current/sys/amd64/amd64/trap.c:743
#7  0x80a3144b in trap (frame=0xfe007c98bc00)
 at /opt/src/svn-current/sys/amd64/amd64/trap.c:347
#8  
#9  0x00242c52 in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffbe70
(kgdb)

I also tried drm-legacy-kmod this morning before heading off to work. It
wouldn't panic but a hard hang. At least drm-current-kmod panics. I suspect
some of

It's interesting to note that though the first occurrence of this panic
occurred on Dec 9, it is more frequent now.

-rw---  1 root  wheel  476 Dec  9 18:53 /var/crash/info.0
-rw---  1 root  wheel  517 Dec 16 12:28 /var/crash/info.1
-rw---  1 root  wheel  473 Dec 18 10:26 /var/crash/info.2
-rw---  1 root  wheel  476 Dec 18 12:35 /var/crash/info.3
-rw---  1 root  wheel  476 Dec 19 08:31 /var/crash/info.4

My workload hasn't changed. Random mouse clicks or key presses trigger it.




Can you try to get the very latest FreeBSD SVN (r355915)

First rebuild the kernel and then rebuild the module. Also make sure you 
do "porsnap fetch update" to get the latest drm-current-kmod port.


--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: drm-current-kmod panics

2019-12-19 Thread Hans Petter Selasky

On 2019-12-19 19:40, Cy Schubert wrote:

In message , Hans Petter
Sela
sky writes:

On 2019-12-19 17:50, Cy Schubert wrote:

Has anyone else had these since Dec 9?

<4>WARN_ON(!mutex_is_locked(>lock))WARN_ON(!mutex_is_locked(>
lock))
panic: page fault
cpuid = 1
time = 1576772837
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe007c98b930
vpanic() at vpanic+0x17e/frame 0xfe007c98b990
panic() at panic+0x43/frame 0xfe007c98b9f0
trap_fatal() at trap_fatal+0x386/frame 0xfe007c98ba50
trap_pfault() at trap_pfault+0x4f/frame 0xfe007c98bac0
trap() at trap+0x41b/frame 0xfe007c98bbf0
calltrap() at calltrap+0x8/frame 0xfe007c98bbf0
--- trap 0xc, rip = 0x242c52, rsp = 0x7fffbe70, rbp = 0x7fffbe90 --

-

Uptime: 59m7s

It is triggered through random keystrokes or mouse movements.


Looks like a double fault.

Did you recompile drm-current-kmod with the latest kernel sources?


Yes.




Are you able to get a full backtrace?

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: drm-current-kmod panics

2019-12-19 Thread Hans Petter Selasky

On 2019-12-19 17:50, Cy Schubert wrote:

Has anyone else had these since Dec 9?

<4>WARN_ON(!mutex_is_locked(>lock))WARN_ON(!mutex_is_locked(>
lock))
panic: page fault
cpuid = 1
time = 1576772837
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe007c98b930
vpanic() at vpanic+0x17e/frame 0xfe007c98b990
panic() at panic+0x43/frame 0xfe007c98b9f0
trap_fatal() at trap_fatal+0x386/frame 0xfe007c98ba50
trap_pfault() at trap_pfault+0x4f/frame 0xfe007c98bac0
trap() at trap+0x41b/frame 0xfe007c98bbf0
calltrap() at calltrap+0x8/frame 0xfe007c98bbf0
--- trap 0xc, rip = 0x242c52, rsp = 0x7fffbe70, rbp = 0x7fffbe90 ---
Uptime: 59m7s

It is triggered through random keystrokes or mouse movements.


Looks like a double fault.

Did you recompile drm-current-kmod with the latest kernel sources?

--HPS

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: any scheduler/ipi/wakeup bug fixed in the last year?

2019-12-11 Thread Hans Petter Selasky

I wonder if there have been any bug fixes in that area over the past year or so.
Any help and pointers are welcome.


Hi,

A long time ago I fixed an issue for ARM:

http://svnweb.freebsd.org/changeset/base/265913

I've always wondered why x86 does some fixed amount of idle spins before 
going to sleep.


--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: CAM breaks USB [was Re: USB causing boot to hang]

2019-12-06 Thread Hans Petter Selasky

On 2019-12-07 01:09, Alexander Motin wrote:

On 06.12.2019 18:41, Steve Kargl wrote:

On Fri, Dec 06, 2019 at 06:15:32PM -0500, Alexander Motin wrote:

On 06.12.2019 17:52, Steve Kargl wrote:

On Fri, Dec 06, 2019 at 03:33:09PM -0700, Warner Losh wrote:

On Fri, Dec 6, 2019 at 3:31 PM Steve Kargl 
wrote:

The problem seems to be caused 355010.  This is a commit to
fix CAM, which seems to break USB.


Yes. mav@ made this change...


src/UPDATING seems to be missing an entry about CAM breaking USB.


And also that moon is made of cheese. :-\


Not sure what you mean.


I mean that if we are going to write there random fairy-tales, then I
prefer my moon.

If serious, then my change did not change semantics of any existing
tunables, only the way some of them are implemented, so there was
nothing to write in UPDATING.


You made a change, and the commit log
even notes that there could be an issue.  Yet, you want a user
to waste half a day finding the root cause of the problem.


I am sorry that you wasted your time, but quick and ungrounded blames is
the last thing I want to read on Friday evening after the long day.


The commit message for 355010 states:

Devices appearing on USB bus later may still require setting
kern.cam.boot_delay, but hopefully those are minority.

There is no statement about "where" kern.cam.boot_delay should be set.
There is no statement about "what"  value(s) kern.cam.boot_delay should be.


If you never needed it before, you still don't need it.


Prior to 355010 the system just boots up.  After 355010
the system hangs.  Will  kern.cam.boot_delay paper over
whatever (latent?) bug you've exposed?


My change affected the timing of system boot process, allowing system to
continue booting some further, not waiting for CAM to scan its buses and
disks.  If the problem is reproducible even without USB storage, then
CAM probably does not wait for it, so it is not the problem I first
thought about.


If system hangs even without any USB disk attached, then I don't see a
relation between CAM and USB here.  My change could affect some timings
of the boot process, but without closer debugging it is hard to guess
something.  To be sure whether USB is related I would try to disable all
USB controllers either in BIOS or with set of loader tunables like
hint.ehci.0.disabled=1 , hint.ohci.0.disabled=1 ,
hint.xhci.0.disabled=1, ...


Yep.  Completely disabling USB allows the system to boot.  I don't
see how this would be unexpected as umass using cam.


umass uses CAM, but you've told the problem happens even without umass,
that is why I told that I don't see any relation.  Does disabling of
_all_ USB fixes the problem?  Have you tried to narrow it down to
specific controller or device?

Is there anything special in your system?  Are you running GENERIC
kernel?  If not, then what do you have changed?

If your kernel includes VERBOSE_SYSINIT as GENERIC does, I would try to
set debug.verbose_sysinit=1 and see how far the boot process goes and at
which stage it may is hanging (if we guess that hang is related to the
stage and not asynchronous).



Hi,

There is an option you can compile into the kernel which will allow the 
keyboard to enter the debugger.


options ALT_BREAK_TO_DEBUGGER

Sounds to me like either a leaked refcount or that one thread is 
spinning blocking execution of other threads.


--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: r355097 make buildkernel: ports module graphics/gpu-firmware-kmod (all): could not find bsd.sysdir.mk

2019-11-26 Thread Hans Petter Selasky

On 2019-11-26 05:54, Warner Losh wrote:

So when I committed the sysdir stuff I forgot to add it to the install
list. I've fixed it now. Either upgrade, or just copy src/share/mk/
bsd.sysdir.mk to /usr/share/mk

Warner


Or:

make -m /usr/src/share/mk

--HPS

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: unkillable process consuming 100% cpu

2019-11-13 Thread Hans Petter Selasky

On 2019-11-13 15:52, Steve Kargl wrote:

 at /usr/src/sys/amd64/amd64/trap.c:743
#7  0x808b0468 in trap (frame=0xfe00b460e0c0)
 at /usr/src/sys/amd64/amd64/trap.c:407
#8  
#9  0x in ?? ()
#10 0x817d2c0f in radeon_ttm_tt_to_gtt (ttm=0xf80061eeb248)
 at 
/usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/radeon/radeon_ttm.c:720
#11 radeon_ttm_tt_set_userptr (ttm=0xf80061eeb248, addr=1,
 flags=2147483647)


Hi,

I don't see any function call here. Can you try to double check the 
backtrace?


Which version of FreeBSD is this?

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: unkillable process consuming 100% cpu

2019-11-13 Thread Hans Petter Selasky

On 2019-11-13 01:30, Steve Kargl wrote:

On Tue, Nov 12, 2019 at 06:48:22PM +0100, Hans Petter Selasky wrote:

On 2019-11-12 18:31, Steve Kargl wrote:

Can you open the radeonkms.ko in gdb83 from ports and type:

l *(radeon_gem_busy_ioctl+0x30)


% /boot/modules/radeonkms.ko
(gdb) l  *(radeon_gem_busy_ioctl+0x30)
0xa12b0 is in radeon_gem_busy_ioctl 
(/usr/ports/graphics/drm-current-kmod/work/kms-drm-2d2852e/drivers/gpu/drm/radeon/radeon_gem.c:453).
448 
/usr/ports/graphics/drm-current-kmod/work/kms-drm-2d2852e/drivers/gpu/drm/radeon/radeon_gem.c:
 No such file or directory.
(gdb)


Like expected.



I installed the 2nd seqlock.diff, rebuilt drm-current-kmod-4.16.g20191023,
rebooting, and have been pounding on the system with workloads that are
similar to what the system was doing during the lockups.  So far, I
cannot ge the system lock-up.  Looks like your patch fixes (or at
least helps).  Thanks for taking a look at the problem.



Can you apply the kdb.diff on top and check dmesg for prints?

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: unkillable process consuming 100% cpu

2019-11-12 Thread Hans Petter Selasky

On 2019-11-12 18:31, Steve Kargl wrote:

Can you open the radeonkms.ko in gdb83 from ports and type:

l *(radeon_gem_busy_ioctl+0x30)


% /boot/modules/radeonkms.ko
(gdb) l  *(radeon_gem_busy_ioctl+0x30)
0xa12b0 is in radeon_gem_busy_ioctl 
(/usr/ports/graphics/drm-current-kmod/work/kms-drm-2d2852e/drivers/gpu/drm/radeon/radeon_gem.c:453).
448 
/usr/ports/graphics/drm-current-kmod/work/kms-drm-2d2852e/drivers/gpu/drm/radeon/radeon_gem.c:
 No such file or directory.
(gdb)


Like expected.

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: unkillable process consuming 100% cpu

2019-11-11 Thread Hans Petter Selasky

On 2019-11-08 23:09, Steve Kargl wrote:

Here's 'procstat -kk' for the stuck process with the long line wrapped.


Can you run this command a couple of times and see if the backtrace changes?

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: unkillable process consuming 100% cpu

2019-11-11 Thread Hans Petter Selasky

On 2019-11-11 11:44, Hans Petter Selasky wrote:

Seems like we can optimise away one more write memory barrier.

If you are building from ports, simply:

cd work/kms-drm*
cat seqlock.diff | patch -p1



Hi,

Here is one more debug patch you can try. See if you get that print 
added in the patch in dmesg.


--HPS

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index a6e0a16ae..0697d70f4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -31,6 +31,8 @@
 #include "amdgpu_vm.h"
 #include "amdgpu_amdkfd.h"
 
+#include 
+
 /* Special VM and GART address alignment needed for VI pre-Fiji due to
  * a HW bug.
  */
@@ -236,6 +238,12 @@ static int amdgpu_amdkfd_remove_eviction_fence(struct amdgpu_bo *bo,
 		*ef_count = 0;
 	}
 
+	if (resv != NULL &&
+	(struct thread *)SX_OWNER(resv->lock.base.sx.sx_lock) != curthread) {
+		printf("Called unlocked\n");
+		kdb_backtrace();
+	}
+
 	old = reservation_object_get_list(resv);
 	if (!old)
 		return 0;
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: unkillable process consuming 100% cpu

2019-11-11 Thread Hans Petter Selasky

Seems like we can optimise away one more write memory barrier.

If you are building from ports, simply:

cd work/kms-drm*
cat seqlock.diff | patch -p1

--HPS
diff --git a/linuxkpi/gplv2/include/linux/reservation.h b/linuxkpi/gplv2/include/linux/reservation.h
index b975f792c..0ce922a0e 100644
--- a/linuxkpi/gplv2/include/linux/reservation.h
+++ b/linuxkpi/gplv2/include/linux/reservation.h
@@ -94,7 +94,7 @@ reservation_object_init(struct reservation_object *obj)
 {
 	ww_mutex_init(>lock, _ww_class);
 
-	__seqcount_init(>seq, reservation_seqcount_string, _seqcount_class);
+	seqcount_init(>seq);
 	RCU_INIT_POINTER(obj->fence, NULL);
 	RCU_INIT_POINTER(obj->fence_excl, NULL);
 	obj->staged = NULL;
diff --git a/linuxkpi/gplv2/include/linux/seqlock.h b/linuxkpi/gplv2/include/linux/seqlock.h
index e86351810..115ad5e68 100644
--- a/linuxkpi/gplv2/include/linux/seqlock.h
+++ b/linuxkpi/gplv2/include/linux/seqlock.h
@@ -1,410 +1,148 @@
 #ifndef __LINUX_SEQLOCK_H
-#define __LINUX_SEQLOCK_H
-/*
- * Reader/writer consistent mechanism without starving writers. This type of
- * lock for data where the reader wants a consistent set of information
- * and is willing to retry if the information changes. There are two types
- * of readers:
- * 1. Sequence readers which never block a writer but they may have to retry
- *if a writer is in progress by detecting change in sequence number.
- *Writers do not wait for a sequence reader.
- * 2. Locking readers which will wait if a writer or another locking reader
- *is in progress. A locking reader in progress will also block a writer
- *from going forward. Unlike the regular rwlock, the read lock here is
- *exclusive so that only one locking reader can get it.
- *
- * This is not as cache friendly as brlock. Also, this may not work well
- * for data that contains pointers, because any writer could
- * invalidate a pointer that a reader was following.
- *
- * Expected non-blocking reader usage:
- * 	do {
- *	seq = read_seqbegin();
- * 	...
- *  } while (read_seqretry(, seq));
- *
- *
- * On non-SMP the spin locks disappear but the writer still needs
- * to increment the sequence variables because an interrupt routine could
- * change the state of the data.
- *
- * Based on x86_64 vsyscall gettimeofday 
- * by Keith Owens and Andrea Arcangeli
- */
+#define	__LINUX_SEQLOCK_H
 
 #include 
 #include 
-#include 
 #include 
 #include 
+#include 
 #include 
 
-
-/*
- * Version using sequence counter only.
- * This can be used when code has its own mutex protecting the
- * updating starting before the write_seqcountbeqin() and ending
- * after the write_seqcount_end().
- */
 typedef struct seqcount {
-	unsigned sequence;
-#ifdef CONFIG_DEBUG_LOCK_ALLOC
-	struct lockdep_map dep_map;
-#endif
+	volatile unsigned sequence;
 } seqcount_t;
 
-
-#define lockdep_init_map(a, b, c, d)
-
-static inline void __seqcount_init(seqcount_t *s, const char *name,
-	  struct lock_class_key *key)
+static inline void
+seqcount_init(seqcount_t *s)
 {
-	/*
-	 * Make sure we are not reinitializing a held lock:
-	 */
-	lockdep_init_map(>dep_map, name, key, 0);
 	s->sequence = 0;
 }
 
-#ifdef CONFIG_DEBUG_LOCK_ALLOC
-# define SEQCOUNT_DEP_MAP_INIT(lockname) \
-		.dep_map = { .name = #lockname } \
-
-# define seqcount_init(s)\
-	do {		\
-		static struct lock_class_key __key;	\
-		__seqcount_init((s), #s, &__key);	\
-	} while (0)
+#define	__seqcount_init(a,b,c) \
+	seqcount_init(a)
 
-static inline void seqcount_lockdep_reader_access(seqcount_t *s)
-{
-	seqcount_t *l = (seqcount_t *)s;
-	unsigned long flags;
-
-	local_irq_save(flags);
-	seqcount_acquire_read(>dep_map, 0, 0, _RET_IP_);
-	seqcount_release(>dep_map, 1, _RET_IP_);
-	local_irq_restore(flags);
+#define	SEQCNT_ZERO(lockname) {			\
+	.sequence = 0\
 }
 
-#else
-# define SEQCOUNT_DEP_MAP_INIT(lockname)
-# define seqcount_init(s) __seqcount_init(s, NULL, NULL)
-# define seqcount_lockdep_reader_access(x)
-#endif
-
-#define SEQCNT_ZERO(lockname) { .sequence = 0, SEQCOUNT_DEP_MAP_INIT(lockname)}
-
-
-/**
- * __read_seqcount_begin - begin a seq-read critical section (without barrier)
- * @s: pointer to seqcount_t
- * Returns: count to be passed to read_seqcount_retry
- *
- * __read_seqcount_begin is like read_seqcount_begin, but has no smp_rmb()
- * barrier. Callers should ensure that smp_rmb() or equivalent ordering is
- * provided before actually loading any of the variables that are to be
- * protected in this critical section.
- *
- * Use carefully, only in critical code, and comment how the barrier is
- * provided.
- */
-static inline unsigned __read_seqcount_begin(seqcount_t *s)
+static inline unsigned
+__read_seqcount_begin(seqcount_t *s)
 {
 	unsigned ret;
 
 repeat:
-	ret = READ_ONCE(s->sequence);
+	ret = s->sequence;
 	if (unlikely(ret & 1)) {
 		cpu_relax();
 		goto repeat;
 	}
-	return ret;
+	return (ret);
 }
 
-/**
- * raw_read_seqcount - Read the raw seqcount
- * @s: pointer to seqcount_t
- * Returns: count 

Re: unkillable process consuming 100% cpu

2019-11-11 Thread Hans Petter Selasky

On 2019-11-11 10:34, Hans Petter Selasky wrote:

Hi,

Can you open the radeonkms.ko in gdb83 from ports and type:

l *(radeon_gem_busy_ioctl+0x30)



Hi,

I suspect there is a memory race in the seqlock framework. Can you try 
the attached patch and re-build?


Is this issue easily reproducible?

--HPS
diff --git a/linuxkpi/gplv2/include/linux/reservation.h b/linuxkpi/gplv2/include/linux/reservation.h
index b975f792c..0ce922a0e 100644
--- a/linuxkpi/gplv2/include/linux/reservation.h
+++ b/linuxkpi/gplv2/include/linux/reservation.h
@@ -94,7 +94,7 @@ reservation_object_init(struct reservation_object *obj)
 {
 	ww_mutex_init(>lock, _ww_class);
 
-	__seqcount_init(>seq, reservation_seqcount_string, _seqcount_class);
+	seqcount_init(>seq);
 	RCU_INIT_POINTER(obj->fence, NULL);
 	RCU_INIT_POINTER(obj->fence_excl, NULL);
 	obj->staged = NULL;
diff --git a/linuxkpi/gplv2/include/linux/seqlock.h b/linuxkpi/gplv2/include/linux/seqlock.h
index e86351810..940bd8e90 100644
--- a/linuxkpi/gplv2/include/linux/seqlock.h
+++ b/linuxkpi/gplv2/include/linux/seqlock.h
@@ -1,410 +1,149 @@
 #ifndef __LINUX_SEQLOCK_H
-#define __LINUX_SEQLOCK_H
-/*
- * Reader/writer consistent mechanism without starving writers. This type of
- * lock for data where the reader wants a consistent set of information
- * and is willing to retry if the information changes. There are two types
- * of readers:
- * 1. Sequence readers which never block a writer but they may have to retry
- *if a writer is in progress by detecting change in sequence number.
- *Writers do not wait for a sequence reader.
- * 2. Locking readers which will wait if a writer or another locking reader
- *is in progress. A locking reader in progress will also block a writer
- *from going forward. Unlike the regular rwlock, the read lock here is
- *exclusive so that only one locking reader can get it.
- *
- * This is not as cache friendly as brlock. Also, this may not work well
- * for data that contains pointers, because any writer could
- * invalidate a pointer that a reader was following.
- *
- * Expected non-blocking reader usage:
- * 	do {
- *	seq = read_seqbegin();
- * 	...
- *  } while (read_seqretry(, seq));
- *
- *
- * On non-SMP the spin locks disappear but the writer still needs
- * to increment the sequence variables because an interrupt routine could
- * change the state of the data.
- *
- * Based on x86_64 vsyscall gettimeofday 
- * by Keith Owens and Andrea Arcangeli
- */
+#define	__LINUX_SEQLOCK_H
 
 #include 
 #include 
-#include 
 #include 
 #include 
+#include 
 #include 
 
-
-/*
- * Version using sequence counter only.
- * This can be used when code has its own mutex protecting the
- * updating starting before the write_seqcountbeqin() and ending
- * after the write_seqcount_end().
- */
 typedef struct seqcount {
-	unsigned sequence;
-#ifdef CONFIG_DEBUG_LOCK_ALLOC
-	struct lockdep_map dep_map;
-#endif
+	volatile unsigned sequence;
 } seqcount_t;
 
-
-#define lockdep_init_map(a, b, c, d)
-
-static inline void __seqcount_init(seqcount_t *s, const char *name,
-	  struct lock_class_key *key)
+static inline void
+seqcount_init(seqcount_t *s)
 {
-	/*
-	 * Make sure we are not reinitializing a held lock:
-	 */
-	lockdep_init_map(>dep_map, name, key, 0);
 	s->sequence = 0;
 }
 
-#ifdef CONFIG_DEBUG_LOCK_ALLOC
-# define SEQCOUNT_DEP_MAP_INIT(lockname) \
-		.dep_map = { .name = #lockname } \
-
-# define seqcount_init(s)\
-	do {		\
-		static struct lock_class_key __key;	\
-		__seqcount_init((s), #s, &__key);	\
-	} while (0)
+#define	__seqcount_init(a,b,c) \
+	seqcount_init(a)
 
-static inline void seqcount_lockdep_reader_access(seqcount_t *s)
-{
-	seqcount_t *l = (seqcount_t *)s;
-	unsigned long flags;
-
-	local_irq_save(flags);
-	seqcount_acquire_read(>dep_map, 0, 0, _RET_IP_);
-	seqcount_release(>dep_map, 1, _RET_IP_);
-	local_irq_restore(flags);
+#define	SEQCNT_ZERO(lockname) {			\
+	.sequence = 0\
 }
 
-#else
-# define SEQCOUNT_DEP_MAP_INIT(lockname)
-# define seqcount_init(s) __seqcount_init(s, NULL, NULL)
-# define seqcount_lockdep_reader_access(x)
-#endif
-
-#define SEQCNT_ZERO(lockname) { .sequence = 0, SEQCOUNT_DEP_MAP_INIT(lockname)}
-
-
-/**
- * __read_seqcount_begin - begin a seq-read critical section (without barrier)
- * @s: pointer to seqcount_t
- * Returns: count to be passed to read_seqcount_retry
- *
- * __read_seqcount_begin is like read_seqcount_begin, but has no smp_rmb()
- * barrier. Callers should ensure that smp_rmb() or equivalent ordering is
- * provided before actually loading any of the variables that are to be
- * protected in this critical section.
- *
- * Use carefully, only in critical code, and comment how the barrier is
- * provided.
- */
-static inline unsigned __read_seqcount_begin(seqcount_t *s)
+static inline unsigned
+__read_seqcount_begin(seqcount_t *s)
 {
 	unsigned ret;
 
 repeat:
-	ret = READ_ONCE(s->sequence);
+	ret = s->sequence;
 	if (unli

Re: unkillable process consuming 100% cpu

2019-11-11 Thread Hans Petter Selasky

Hi,

Can you open the radeonkms.ko in gdb83 from ports and type:

l *(radeon_gem_busy_ioctl+0x30)

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: radeon panics kernels

2019-10-03 Thread Hans Petter Selasky

On 2019-10-03 22:26, Steve Kargl wrote:

On Thu, Oct 03, 2019 at 03:05:27PM +0200, Hans Petter Selasky wrote:


If you leave the port debug knob for drm-current-kmod AS-IS, I think you
can get away with:

make DEBUG_FLAGS="-g"

Then re-load the vmcore file in GDB/KGDB from ports (!) and add the
symbol files for the modules loaded. Then get the backtrace using bt
command.

BTW: Did you try drm-devel-kmod for 13-current?



Took a bit of trial and error.  If I skip the panic
and trap frames (#0 through #8). I find the backtrace
that follows by sig.  If I move to frame #11, I see

(kgdb) frame 11
#11 r100_mm_rreg_slow (rdev=0xf80135766a70, reg=)
 at 
/usr/ports/graphics/drm-current-kmod/work/kms-drm-2d2852e/drivers/gpu/drm/radeon/r100.c:4114
4114writel(reg, ((void __iomem *)rdev->rmmio) + RADEON_MM_INDEX);
(kgdb) p rdev->rmmio
$3 = (void *) 0x0

So, your guess of a NULL pointer seems correct.


Can you do:

set print pretty on
print *rdev

--HPS

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: radeon panics kernels

2019-10-03 Thread Hans Petter Selasky

On 2019-10-03 14:59, Steve Kargl wrote:

On Thu, Oct 03, 2019 at 09:17:32AM +0200, Hans Petter Selasky wrote:

On 2019-10-02 23:19, Steve Kargl wrote:

troutmask.apl.washington.edu dumped core - see /var/crash/vmcore.7

Wed Oct  2 14:12:38 PDT 2019



This looks like a simple NULL pointer.

Can you re-compile the drm ports module with debugging symbols and then
reproduce?



Yes.  Is there a ports knob, ie., 'make -DEBUG' for the
drm ports?  Or, do I need to add CFLAGS+=-g to the Makefile?

BTW, this is what I have installed

drm-current-kmod-4.16.g20190927 DRM modules for the linuxkpi-based KMS
drm-kmod-g20190710 Metaport of DRM modules
gpu-firmware-kmod-g20190825Firmware modules for the linuxkpi-based KMS


If you leave the port debug knob for drm-current-kmod AS-IS, I think you 
can get away with:


make DEBUG_FLAGS="-g"

Then re-load the vmcore file in GDB/KGDB from ports (!) and add the 
symbol files for the modules loaded. Then get the backtrace using bt 
command.


BTW: Did you try drm-devel-kmod for 13-current?

--HPS

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: radeon panics kernels

2019-10-03 Thread Hans Petter Selasky

On 2019-10-02 23:19, Steve Kargl wrote:

troutmask.apl.washington.edu dumped core - see /var/crash/vmcore.7

Wed Oct  2 14:12:38 PDT 2019



This looks like a simple NULL pointer.

Can you re-compile the drm ports module with debugging symbols and then 
reproduce?


--HPS


FreeBSD troutmask.apl.washington.edu 13.0-CURRENT FreeBSD 13.0-CURRENT r352812 
HPC  amd64

panic: page fault

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 10
fault virtual address = 0x0
fault code  = supervisor write data, page not present
instruction pointer = 0x20:0x8177ba1c
stack pointer = 0x28:0xfe00b437ff50
frame pointer = 0x28:0xfe00b437ff70
code segment  = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process  = 782 (X:rcs0)
trap number  = 12
panic: page fault
cpuid = 0
time = 1570050659
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00b437fc00
vpanic() at vpanic+0x19d/frame 0xfe00b437fc50
panic() at panic+0x43/frame 0xfe00b437fcb0
trap_fatal() at trap_fatal+0x394/frame 0xfe00b437fd10
trap_pfault() at trap_pfault+0x4f/frame 0xfe00b437fd70
trap() at trap+0x2a1/frame 0xfe00b437fe80
calltrap() at calltrap+0x8/frame 0xfe00b437fe80
--- trap 0xc, rip = 0x8177ba1c, rsp = 0xfe00b437ff50, rbp = 
0xfe00b437ff70 ---
r100_mm_rreg_slow() at r100_mm_rreg_slow+0x3c/frame 0xfe00b437ff70
radeon_fence_activity() at radeon_fence_activity+0x103/frame 0xfe00b437ffd0
radeon_fence_signaled() at radeon_fence_signaled+0x59/frame 0xfe00b4380010
radeon_sa_bo_new() at radeon_sa_bo_new+0x251/frame 0xfe00b4380170
radeon_ib_get() at radeon_ib_get+0x2f/frame 0xfe00b43801b0
radeon_cs_ioctl() at radeon_cs_ioctl+0x25d/frame 0xfe00b4380630
drm_ioctl_kernel() at drm_ioctl_kernel+0xf5/frame 0xfe00b4380680
drm_ioctl() at drm_ioctl+0x27a/frame 0xfe00b4380770
linux_file_ioctl() at linux_file_ioctl+0x298/frame 0xfe00b43807d0
kern_ioctl() at kern_ioctl+0x284/frame 0xfe00b4380840
sys_ioctl() at sys_ioctl+0x158/frame 0xfe00b4380910
amd64_syscall() at amd64_syscall+0x275/frame 0xfe00b4380a30
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe00b4380a30
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x200cc95ca, rsp = 
0x7fffbfffde98, rbp = 0x7fffbfffdec0 ---
Uptime: 5d1h10m44s
Dumping 1764 out of 16327 MB:..1%..11% (CTRL-C to abort) 
..21%..31%..41%..51%..61%..71%..81%..91%

__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55  __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu,
(kgdb) #0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1  doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:392
#2  0x805e26aa in kern_reboot (howto=260)
 at /usr/src/sys/kern/kern_shutdown.c:479
#3  0x805e2b09 in vpanic (fmt=, ap=)
 at /usr/src/sys/kern/kern_shutdown.c:908
#4  0x805e2903 in panic (fmt=)
 at /usr/src/sys/kern/kern_shutdown.c:835
#5  0x808b8884 in trap_fatal (frame=0xfe00b437fe90, eva=0)
 at /usr/src/sys/amd64/amd64/trap.c:925
#6  0x808b88df in trap_pfault (frame=0xfe00b437fe90,
 usermode=, signo=, ucode=)
 at /usr/src/sys/amd64/amd64/trap.c:743
#7  0x808b7f71 in trap (frame=0xfe00b437fe90)
 at /usr/src/sys/amd64/amd64/trap.c:407
#8  
#9  0x8177ba1c in r100_mm_rreg_slow () from /boot/modules/radeonkms.ko
#10 0x817ba613 in radeon_fence_activity ()
from /boot/modules/radeonkms.ko
#11 0x817ba6e9 in radeon_fence_signaled ()
from /boot/modules/radeonkms.ko
#12 0x817d2601 in radeon_sa_bo_new () from /boot/modules/radeonkms.ko
#13 0x817c1a4f in radeon_ib_get () from /boot/modules/radeonkms.ko
#14 0x817ad6ed in radeon_cs_ioctl () from /boot/modules/radeonkms.ko
#15 0x818a82f5 in drm_ioctl_kernel () from /boot/modules/drm.ko
#16 0x818a858a in drm_ioctl () from /boot/modules/drm.ko
#17 0x807cf568 in linux_file_ioctl_sub (fp=,
 filp=, fop=, cmd=, data=0x0,
 td=)
 at /usr/src/sys/compat/linuxkpi/common/src/linux_compat.c:965
#18 linux_file_ioctl (fp=, cmd=,
 data=, cred=, td=)
 at /usr/src/sys/compat/linuxkpi/common/src/linux_compat.c:1558
#19 0x80643694 in fo_ioctl (fp=, com=3223348326,
 data=0x8185dd5c, active_cred=0xf8001be3a001,
 td=) at /usr/src/sys/sys/file.h:341
#20 kern_ioctl (td=0xf8001be3a000, fd=, com=3223348326,
 data=0x8185dd5c 
"/usr/ports/graphics/drm-current-kmod/work/kms-drm-2d2852e/drivers/gpu/drm/radeon/r100.c")
 at /usr/src/sys/kern/sys_generic.c:804
#21 0x80643398 in sys_ioctl (td=0xf8001be3a000,
 uap=0xf8001be3a3c8) at /usr/src/sys/kern/sys_generic.c:712
#22 0x808b92e5 in syscallenter (td=0xf8001be3a000)
 at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:144
#23 

Re: r351680 kernel panic in login

2019-09-21 Thread Hans Petter Selasky

On 2019-09-21 07:55, KIRIYAMA Kazuhiko wrote:

Hi,

I've installed r351680 in my note PC. But kernel panic at
login:

Kernel page fault with the following non-sleepable locks held:
exclusive sleep mutex axe0 (axe0) r = (0xf80003989ea0) locked 0 
/usr/src/sys/dev/usb/usb_transfer.c:2266
stack backtrace:
#0 0x80c3dac3 at winess_debugger+0x73
#1 0x80c3eae2 at winess_warn+0x442
#2 0x81191943 at trap_pfault+0x53
#3 0x81198f42 at trap+0x2b2
#4 0x8116886c at caltrap+0x8
#5 0x82f0dd82 at axe_bulk_read_callback+0x142
#6 0x80a1e52a at usbd_callback_wrapoer+0x7aa
#7 0x80a1c273 at usb_command_wrapper+0xb3
#8 0x80a1b0ae at usb_callback_proc+0x8e
#9 0x80a15dd5 at usb_process+0xe5
#10 0x80b8f794 at fork_exit+0x84
#11 0x811698ae at gork_trampoline+0xe


Fatal trap12: page fault while in kernel mode
cpuid = 3; apic id = 86
fault virtual address  = 0x0
fault code = supervisor write data,page not present
instruction pointer= 0x20:0x82f0df41
stack pointer  = 0x28:0xfe513a40
frame pointer  = 0x28:0xfe513a80
code segment   = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags   = interrupt enabled, resume, IOPL = 0
current process= 15 (usbus0)
trap number= 12
panic: page fault
cpuid = 3
time = 1568969574
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe513700
vpanic() at vpanic+0x19d/frame 0xfe513750
panic() at panic+0x43/frame 0xfe5137b0
trap_fatal() at trap_fatal+0x39c/frame 0xfe513810
trap_pfault() at trap_pfault+0x62/frame 0xfe513860
trap() at trap+0x2b2/frame 0xfe513970
calltrap() at calltrap+0x8/frame 0xfe513970
--- trap 0xc, rip = 0x82f0d41, rsp = 0xfe513a40, rbp = 
0xfe513a80 ---
axe_rxeof() at axa_rxeof+0x151/frame 0xfe513a80
axe_bulk_read_callback() at axe_bulk_read_callback+0x142/frame 
0xfe513af0
usbd_callback_wrapper() at usbd_callback_wrapper+0x7aa/fram 0xfe513b30
usb_command_wrapper() at usb_command_wrapper+0xb3/frame 0xfe513b50
usb_callback_proc() at usb_callback_proc+0x8e/frame 0xfe513b70
usb_process() at usb_process+0xe5/frame 0xfe513bb0
fork_exit() at fork_exit+0x84/frame 0xfe513bf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe513bf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KBD: enter: panic
[ thread pid 15 tid 100047 ]
Stopped at  kbd_enter+0x3b: movq   $0,kbd_why
db>

I've rebooted and at single user mode I saved sevral specs
in usb as follows:

# umane -a
FreeBSD  13.0-CURRENT FreeBSD 13.0-CURRENT #0 r351680: Fri Sep 13 13:37:15 JST 
2019 admin@tbedfc:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
# dmesg
---<>---
Copyright (c) 1992-2019 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 13.0-CURRENT #0 r351680: Fri Sep 13 13:37:15 JST 2019
 admin@tbedfc:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on LLVM 
8.0.1)
WARNING: WITNESS option enabled, expect reduced performance.
VT(efifb): resolution 800x600
CPU: Intel(R) Atom(TM) x5-Z8350  CPU @ 1.44GHz (1439.99-MHz K8-class CPU)
   Origin="GenuineIntel"  Id=0x406c4  Family=0x6  Model=0x4c  Stepping=4
   
Features=0xbfebfbff
   
Features2=0x43d8e3bf
   AMD Features=0x28100800
   AMD Features2=0x101
   Structured Extended Features=0x2282
   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
   TSC: P-state invariant, performance statistics
real memory  = 4294967296 (4096 MB)
avail memory = 3974008832 (3789 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: 
WARNING: L1 data cache covers fewer APIC IDs than a core (0 < 1)
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 4 core(s)
random: registering fast source Intel Secure Key RNG
random: fast provider: "Intel Secure Key RNG"
random: unblocking device.
ioapic0  irqs 0-114
Launching APs: 2 3 1
Timecounter "TSC" frequency 1439990442 Hz quality 1000
random: entropy device external interface
[ath_hal] loaded
kbd1 at kbdmux0
000.46 [4335] netmap_init   netmap: loaded module
module_register_init: MOD_LOAD (vesa, 0x811b9cc0, 0) error 19
nexus0
efirtc0: 
efirtc0: registered as a time-of-day clock, resolution 1.00s
cryptosoft0: 
acpi0: 
acpi0: Power Button (fixed)
unknown: I/O range not supported
cpu0:  on acpi0
attimer0:  port 0x40-0x43,0x50-0x53 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
atrtc0:  port 0x70-0x77 on acpi0
atrtc0: Warning: Couldn't map I/O.
atrtc0: registered as a time-of-day clock, 

Source tree has many empty directories?

2019-09-10 Thread Hans Petter Selasky

Hi Developers,

My -head source tree might be dirty over the years, but there appears to 
be some empty directories. Can these just be removed?


--HPS

find . -type d -empty
./sys/fs/nandfs
./sys/mips/gxemul
./sys/gnu/dts/include/dt-bindings/genpd
./sys/modules/drm/r128
./sys/modules/drm/sis
./sys/modules/drm/via
./sys/modules/drm/drm
./sys/modules/drm/mach64
./sys/modules/drm/mga
./sys/modules/drm/tdfx
./sys/modules/drm/savage
./sys/modules/if_tun
./sys/modules/nandfs
./sys/modules/nand
./sys/modules/nandsim
./sys/modules/drm2/drm2
./sys/modules/drm2/radeonkmsfw/ARUBA_me
./sys/modules/drm2/radeonkmsfw/VERDE_ce
./sys/modules/drm2/radeonkmsfw/TURKS_pfp
./sys/modules/drm2/radeonkmsfw/HAINAN_mc
./sys/modules/drm2/radeonkmsfw/CAYMAN_pfp
./sys/modules/drm2/radeonkmsfw/HAINAN_me
./sys/modules/drm2/radeonkmsfw/BARTS_pfp
./sys/modules/drm2/radeonkmsfw/CAICOS_mc
./sys/modules/drm2/radeonkmsfw/CAICOS_me
./sys/modules/drm2/radeonkmsfw/CEDAR_pfp
./sys/modules/drm2/radeonkmsfw/RV710_pfp
./sys/modules/drm2/radeonkmsfw/RV630_pfp
./sys/modules/drm2/radeonkmsfw/R600_rlc
./sys/modules/drm2/radeonkmsfw/TAHITI_ce
./sys/modules/drm2/radeonkmsfw/RV670_pfp
./sys/modules/drm2/radeonkmsfw/BARTS_mc
./sys/modules/drm2/radeonkmsfw/ARUBA_rlc
./sys/modules/drm2/radeonkmsfw/RV635_pfp
./sys/modules/drm2/radeonkmsfw/BARTS_me
./sys/modules/drm2/radeonkmsfw/CYPRESS_pfp
./sys/modules/drm2/radeonkmsfw/PALM_pfp
./sys/modules/drm2/radeonkmsfw/HAINAN_rlc
./sys/modules/drm2/radeonkmsfw/RV710_me
./sys/modules/drm2/radeonkmsfw/OLAND_pfp
./sys/modules/drm2/radeonkmsfw/RV730_me
./sys/modules/drm2/radeonkmsfw/OLAND_ce
./sys/modules/drm2/radeonkmsfw/R200_cp
./sys/modules/drm2/radeonkmsfw/RV770_me
./sys/modules/drm2/radeonkmsfw/REDWOOD_pfp
./sys/modules/drm2/radeonkmsfw/SUMO2_pfp
./sys/modules/drm2/radeonkmsfw/JUNIPER_rlc
./sys/modules/drm2/radeonkmsfw/PITCAIRN_pfp
./sys/modules/drm2/radeonkmsfw/PITCAIRN_ce
./sys/modules/drm2/radeonkmsfw/SUMO_rlc
./sys/modules/drm2/radeonkmsfw/REDWOOD_me
./sys/modules/drm2/radeonkmsfw/TAHITI_pfp
./sys/modules/drm2/radeonkmsfw/CEDAR_me
./sys/modules/drm2/radeonkmsfw/SUMO_uvd
./sys/modules/drm2/radeonkmsfw/VERDE_rlc
./sys/modules/drm2/radeonkmsfw/HAINAN_ce
./sys/modules/drm2/radeonkmsfw/CAICOS_pfp
./sys/modules/drm2/radeonkmsfw/R300_cp
./sys/modules/drm2/radeonkmsfw/BTC_rlc
./sys/modules/drm2/radeonkmsfw/CAYMAN_rlc
./sys/modules/drm2/radeonkmsfw/CEDAR_rlc
./sys/modules/drm2/radeonkmsfw/RV610_pfp
./sys/modules/drm2/radeonkmsfw/VERDE_mc
./sys/modules/drm2/radeonkmsfw/VERDE_me
./sys/modules/drm2/radeonkmsfw/RV730_pfp
./sys/modules/drm2/radeonkmsfw/CYPRESS_rlc
./sys/modules/drm2/radeonkmsfw/R700_rlc
./sys/modules/drm2/radeonkmsfw/RS780_pfp
./sys/modules/drm2/radeonkmsfw/RV770_pfp
./sys/modules/drm2/radeonkmsfw/R600_pfp
./sys/modules/drm2/radeonkmsfw/RV710_uvd
./sys/modules/drm2/radeonkmsfw/JUNIPER_me
./sys/modules/drm2/radeonkmsfw/OLAND_rlc
./sys/modules/drm2/radeonkmsfw/ARUBA_pfp
./sys/modules/drm2/radeonkmsfw/TAHITI_mc
./sys/modules/drm2/radeonkmsfw/TAHITI_me
./sys/modules/drm2/radeonkmsfw/HAINAN_pfp
./sys/modules/drm2/radeonkmsfw/REDWOOD_rlc
./sys/modules/drm2/radeonkmsfw/RS780_me
./sys/modules/drm2/radeonkmsfw/CYPRESS_uvd
./sys/modules/drm2/radeonkmsfw/RV635_me
./sys/modules/drm2/radeonkmsfw/R600_me
./sys/modules/drm2/radeonkmsfw/R420_cp
./sys/modules/drm2/radeonkmsfw/PITCAIRN_rlc
./sys/modules/drm2/radeonkmsfw/PALM_me
./sys/modules/drm2/radeonkmsfw/OLAND_mc
./sys/modules/drm2/radeonkmsfw/OLAND_me
./sys/modules/drm2/radeonkmsfw/JUNIPER_pfp
./sys/modules/drm2/radeonkmsfw/TAHITI_rlc
./sys/modules/drm2/radeonkmsfw/RV620_pfp
./sys/modules/drm2/radeonkmsfw/SUMO2_me
./sys/modules/drm2/radeonkmsfw/CAYMAN_mc
./sys/modules/drm2/radeonkmsfw/TURKS_mc
./sys/modules/drm2/radeonkmsfw/PITCAIRN_mc
./sys/modules/drm2/radeonkmsfw/SUMO_pfp
./sys/modules/drm2/radeonkmsfw/CAYMAN_me
./sys/modules/drm2/radeonkmsfw/TURKS_me
./sys/modules/drm2/radeonkmsfw/PITCAIRN_me
./sys/modules/drm2/radeonkmsfw/RS600_cp
./sys/modules/drm2/radeonkmsfw/RV610_me
./sys/modules/drm2/radeonkmsfw/RV620_me
./sys/modules/drm2/radeonkmsfw/TAHITI_uvd
./sys/modules/drm2/radeonkmsfw/RV630_me
./sys/modules/drm2/radeonkmsfw/R100_cp
./sys/modules/drm2/radeonkmsfw/SUMO_me
./sys/modules/drm2/radeonkmsfw/RS690_cp
./sys/modules/drm2/radeonkmsfw/RV670_me
./sys/modules/drm2/radeonkmsfw/CYPRESS_me
./sys/modules/drm2/radeonkmsfw/R520_cp
./sys/modules/drm2/radeonkmsfw/VERDE_pfp
./sys/modules/drm2/i915kms
./sys/modules/drm2/radeonkms
./sys/modules/if_tap
./sys/dev/nand
./crypto/heimdal/lib/sqlite
./usr.bin/send-pr
./sbin/nandfs
./sbin/newfs_nandfs
./tools/tools/nanobsd/gateworks/Files/root
./tools/tools/nanobsd/gateworks/cfg/ssh
./tools/tools/nanobsd/rescue/Pkg
./contrib/traceroute/lbl
./contrib/ipfilter/net
./contrib/ipfilter/ipsd/Celler
./contrib/netbsd-tests/dev/usb/libhid
./contrib/netbsd-tests/dev/usb/t_hid
./contrib/netbsd-tests/crypto/libcrypto/x509v3
./contrib/netbsd-tests/crypto/libcrypto/rsa
./contrib/netbsd-tests/crypto/libcrypto/rc2

Re: Kernel-Crash when working with ubt0

2019-08-26 Thread Hans Petter Selasky

Do you have a backtrace?

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Huawei mobile/wifi gadgets: HOWTO

2019-08-16 Thread Hans Petter Selasky

On 2019-08-16 11:07, Poul-Henning Kamp wrote:

The remaining issue is: How to get FreeBSD do send the magic string?


FreeBSD USB has several quirks for these devices:

See for example:


/sys/dev/usb/usb_msctest.c:usb_msc_auto_quirk(struct usb_device *udev, uint8_t 
iface_index)
/sys/dev/usb/usb_msctest.h:usb_error_t usb_msc_auto_quirk(struct usb_device 
*udev,
/sys/dev/usb/usb_device.c:  err = usb_msc_auto_quirk(udev, 0);


And:

usbconfig dump_quirk_names | grep -i UQ_MSC

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Boot still broken from r349133-r349160 - Was re:(Problem with USB after r349133)

2019-08-13 Thread Hans Petter Selasky

Hi,

After tearing ACPI apart, there appears to be an issue like following:

1) AcpiUtAcquireMutex() doesn't support recursion, but also fails to 
report an error when such a condition is occurring. Here is the 
backtrace of the illegal mutex recursion.


> AcpiUtAcquireMutex() at AcpiUtAcquireMutex+0x1fc/frame 0x834815d0
> AcpiWalkNamespace() at AcpiWalkNamespace+0x8a/frame 0x83481640
> AcpiNsInitializeObjects() at AcpiNsInitializeObjects+0x9b/frame 
0x834816c0

> AcpiExLoadTableOp() at AcpiExLoadTableOp+0x21c/frame 0x83481730
> AcpiExOpcode_6A_0T_1R() at AcpiExOpcode_6A_0T_1R+0x22e/frame 
0x83481790

> AcpiDsExecEndOp() at AcpiDsExecEndOp+0x1dc/frame 0x83481830
> AcpiPsParseLoop() at AcpiPsParseLoop+0x75a/frame 0x83481880
> AcpiPsParseAml() at AcpiPsParseAml+0xfd/frame 0x834818d0
> AcpiPsExecuteMethod() at AcpiPsExecuteMethod+0x27d/frame 
0x83481940

> AcpiNsEvaluate() at AcpiNsEvaluate+0x336/frame 0x834819b0
> AcpiEvaluateObject() at AcpiEvaluateObject+0x223/frame 0x83481a10
> AcpiEvaluateObjectTyped() at AcpiEvaluateObjectTyped+0xe0/frame 
0x83481aa0

> acpi_EvaluateOSC() at acpi_EvaluateOSC+0xef/frame 0x83481b90
> acpi_cpu_attach() at acpi_cpu_attach+0x432/frame 0x83481cb0
> DEVICE_ATTACH() at DEVICE_ATTACH+0x87/frame 0x83481cf0
> device_attach() at device_attach+0xb9/frame 0x83481d80
> device_probe_and_attach() at device_probe_and_attach+0x106/frame 
0x83481dc0

> bus_generic_attach() at bus_generic_attach+0x2c/frame 0x83481df0
> acpi_probe_children() at acpi_probe_children+0x77/frame 
0x83481e30

> acpi_attach() at acpi_attach+0xbfe/frame 0x83482050
> DEVICE_ATTACH() at DEVICE_ATTACH+0x87/frame 0x83482090
> device_attach() at device_attach+0xb9/frame 0x83482120
> device_probe_and_attach() at device_probe_and_attach+0x106/frame 
0x83482160

> bus_generic_attach() at bus_generic_attach+0x2c/frame 0x83482190
> nexus_acpi_attach() at nexus_acpi_attach+0x59/frame 0x834821b0
> DEVICE_ATTACH() at DEVICE_ATTACH+0x87/frame 0x834821f0
> device_attach() at device_attach+0xb9/frame 0x83482280
> device_probe_and_attach() at device_probe_and_attach+0x106/frame 
0x834822c0
> bus_generic_new_pass() at bus_generic_new_pass+0xb5/frame 
0x83482300

> BUS_NEW_PASS() at BUS_NEW_PASS+0x87/frame 0x83482340
> bus_set_pass() at bus_set_pass+0x8f/frame 0x83482360
> root_bus_configure() at root_bus_configure+0xe/frame 0x83482370
> configure() at configure+0x11/frame 0x83482390
> mi_startup() at mi_startup+0x2dc/frame 0x834823f0
> btext() at btext+0x2c
> ACPI Error: AE_ALREADY_ACQUIRED, During WalkNamespace 
(20190703/nsinit-232)



The illegal mutex recursion ends up leaking a lock, which later on 
causes a boot deadlock due to accesses to ACPI hanging forever.



2) This patch works around the issue.

> diff --git a/sys/contrib/dev/acpica/components/utilities/utmutex.c 
b/sys/contrib/dev/acpica/components/utilities/utmutex.c

> index 4853bf5c3a6..33a67a731c6 100644
> --- a/sys/contrib/dev/acpica/components/utilities/utmutex.c
> +++ b/sys/contrib/dev/acpica/components/utilities/utmutex.c
> @@ -378,6 +378,16 @@ AcpiUtAcquireMutex (
>
>  ThisThreadId = AcpiOsGetThreadId ();
>
> +if (AcpiGbl_MutexInfo[MutexId].ThreadId == ThisThreadId)
> +{
> +   ACPI_ERROR ((AE_INFO,
> +   "Mutex [%s] already acquired by this thread [%u]",
> +   AcpiUtGetMutexName (MutexId),
> +   (UINT32) ThisThreadId));
> +
> +   return (AE_ALREADY_ACQUIRED);
> +}
> +
>  #ifdef ACPI_MUTEX_DEBUG
>  {
>  UINT32

--HPS

On 2019-08-01 15:58, Scott Long wrote:

I’m 99% sure that the boot breakage is due to this commit:

Author: jkim
Date: Tue Jul  9 18:02:36 2019
New Revision: 349863
URL: https://svnweb.freebsd.org/changeset/base/349863

Log:
  MFV:  r349861

  Import ACPICA 20190703.

I have two systems now that are affected, and both of them
are “fixed” by reverting this.  I don’t know the root cause yet,
see my email to the svn-src-all mailing list.





___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: follow up: strange problem with external USB disks

2019-07-28 Thread Hans Petter Selasky

On 2019-07-27 13:51, Gary Jennejohn wrote:

On Sat, 27 Jul 2019 13:05:01 +0200
Hans Petter Selasky  wrote:


On 2019-07-26 11:56, Gary Jennejohn wrote:

On Fri, 26 Jul 2019 11:25:33 +0200
Gary Jennejohn  wrote:
   

I'm having a very strange problem with external USB disks in
HEAD.  I see the problem with a kernel from July 12th and also
with one from today.
  

[snip]

Since I'm running a custom kernel I'll try running GENERIC to
see what happens and report back.
  


OK, so with GENERIC the error doesn't occur.  Guess I'm missing
something in my custom kernel configuration.
   


Does it work with GENERIC nodebug ?



Do you mean without "makeoptions DEBUG=-g" or without "options
USB_DEBUG"?  Or something else?



I mean:
sys/amd64/conf/GENERIC-NODEBUG


--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: follow up: strange problem with external USB disks

2019-07-27 Thread Hans Petter Selasky

On 2019-07-26 11:56, Gary Jennejohn wrote:

On Fri, 26 Jul 2019 11:25:33 +0200
Gary Jennejohn  wrote:


I'm having a very strange problem with external USB disks in
HEAD.  I see the problem with a kernel from July 12th and also
with one from today.


[snip]

Since I'm running a custom kernel I'll try running GENERIC to
see what happens and report back.



OK, so with GENERIC the error doesn't occur.  Guess I'm missing
something in my custom kernel configuration.



Does it work with GENERIC nodebug ?

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Problem with USB after r349133

2019-07-22 Thread Hans Petter Selasky

On 2019-07-22 17:23, Nick Wolff wrote:

Sorry for email spam but I was wrong. Just gets stuck now during reproping
a pci device after init happens(this is actually a trueos build which is
why you see openrc). That device it's getting stuck on is "Sky Lake-E CBDMA
Registers" which shouldn't have a driver attached.
https://drive.google.com/file/d/19NFI0Dcupu3ZcVxbcr2vYFZ-iDqiIzkx/view?usp=sharing

Though it maybe something else getting stuck at this point and that just
happens to be the last thing on the screen.



There was a recent change to add an ACPI wrapper for the USB HUB driver, 
but that was a bit premature and introduced some bugs. For now the ACPI 
USB HUB wrapper is not enabled by default. Do you experience issues with 
the latest -current ?


--HPS

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Someone broke USB

2019-07-08 Thread Hans Petter Selasky

On 2019-07-08 22:08, Steve Kargl wrote:

On Mon, Jul 08, 2019 at 09:08:17PM +0200, Hans Petter Selasky wrote:

Hi Steve,

Can you revert all prior patches and try this one instead.



With the new patch, none of the USB devices are found.
I'll be away from the laptop for a few hours.



I've put the USB ACPI code into an own module, which is not enabled by 
default. So USB should be back to normal for now.


https://svnweb.freebsd.org/changeset/base/349851

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Someone broke USB

2019-07-08 Thread Hans Petter Selasky

Hi Steve,

Can you revert all prior patches and try this one instead.

--HPS
Index: sys/dev/usb/usb_hub_acpi.c
===
--- sys/dev/usb/usb_hub_acpi.c	(revision 349802)
+++ sys/dev/usb/usb_hub_acpi.c	(working copy)
@@ -80,24 +80,6 @@
 #include 
 #include 
 
-static UINT32 acpi_uhub_find_rh_cb(ACPI_HANDLE ah, UINT32 nl, void *ctx, void **status);
-static ACPI_STATUS acpi_uhub_find_rh(device_t dev, ACPI_HANDLE * ah);
-static ACPI_STATUS
-acpi_usb_hub_port_probe_cb(ACPI_HANDLE ah, UINT32 lv, void *ctx, void **rv);
-static ACPI_STATUS acpi_usb_hub_port_probe(device_t dev, ACPI_HANDLE ah);
-static int acpi_uhub_root_probe(device_t dev);
-static int acpi_uhub_probe(device_t dev);
-static int acpi_uhub_root_attach(device_t dev);
-static int acpi_uhub_attach(device_t dev);
-static int acpi_uhub_detach(device_t dev);
-static int
-acpi_uhub_read_ivar(device_t dev, device_t child, int idx,
-uintptr_t *res);
-static int
-acpi_uhub_child_location_string(device_t parent, device_t child,
-char *buf, size_t buflen);
-static int acpi_uhub_parse_upc(device_t dev, unsigned int port, ACPI_HANDLE ah);
-
 struct acpi_uhub_softc {
 	struct uhub_softc usc;
 	uint8_t	nports;
@@ -104,27 +86,25 @@
 	ACPI_HANDLE *porthandle;
 };
 
-UINT32
-acpi_uhub_find_rh_cb(ACPI_HANDLE ah, UINT32 nl, void *ctx, void **status){
+static UINT32
+acpi_uhub_find_rh_cb(ACPI_HANDLE ah, UINT32 nl, void *ctx, void **status)
+{
 	ACPI_DEVICE_INFO *devinfo;
-	UINT32 ret = AE_OK;
+	UINT32 ret;
 
 	*status = NULL;
 	devinfo = NULL;
 
 	ret = AcpiGetObjectInfo(ah, );
-
-	if (ACPI_FAILURE(ret)) {
-		return ret;
+	if (ACPI_SUCCESS(ret)) {
+		if ((devinfo->Valid & ACPI_VALID_ADR) &&
+		(devinfo->Address == 0)) {
+			ret = AE_CTRL_TERMINATE;
+			*status = ah;
+		}
+		AcpiOsFree(devinfo);
 	}
-	if ((devinfo->Valid & ACPI_VALID_ADR) &&
-	(devinfo->Address == 0)) {
-		ret = AE_CTRL_TERMINATE;
-		*status = ah;
-	}
-	AcpiOsFree(devinfo);
-
-	return ret;
+	return (ret);
 }
 
 static int
@@ -134,14 +114,17 @@
 
 	buf.Pointer = NULL;
 	buf.Length = ACPI_ALLOCATE_BUFFER;
+
 	if (AcpiEvaluateObject(ah, "_UPC", NULL, ) == AE_OK) {
 		UINT64 porttypenum, conn;
 		const char *connectable;
-		const char *typelist[] = {"TypeA", "MiniAB", "Express",
+		const char *typelist[] = {
+			"TypeA", "MiniAB", "Express",
 			"USB3-A", "USB3-B", "USB-MicroB",
 			"USB3-MicroAB", "USB3-PowerB",
 			"TypeC-USB2", "TypeC-Switch",
-		"TypeC-nonSwitch"};
+			"TypeC-nonSwitch"
+		};
 		const char *porttype;
 		const int last = sizeof(typelist) / sizeof(typelist[0]);
 		ACPI_OBJECT *obj = buf.Pointer;
@@ -162,7 +145,7 @@
 	}
 	AcpiOsFree(buf.Pointer);
 
-	return 0;
+	return (0);
 }
 
 static int
@@ -172,6 +155,7 @@
 
 	buf.Pointer = NULL;
 	buf.Length = ACPI_ALLOCATE_BUFFER;
+
 	if (AcpiEvaluateObject(ah, "_PLD", NULL, ) == AE_OK) {
 		ACPI_OBJECT *obj;
 		unsigned char *resbuf;
@@ -235,15 +219,12 @@
 		}
 	skip:
 		AcpiOsFree(buf.Pointer);
-		
 	}
-
-
-	return 0;
+	return (0);
 }
 
-ACPI_STATUS
-acpi_uhub_find_rh(device_t dev, ACPI_HANDLE * ah)
+static ACPI_STATUS
+acpi_uhub_find_rh(device_t dev, ACPI_HANDLE *ah)
 {
 	device_t grand;
 	ACPI_HANDLE gah;
@@ -250,130 +231,133 @@
 
 	*ah = NULL;
 	grand = device_get_parent(device_get_parent(dev));
-	if ((gah = acpi_get_handle(grand)) == NULL) {
-		return AE_ERROR;
-	}
-	return AcpiWalkNamespace(ACPI_TYPE_DEVICE, gah, 1,
-	acpi_uhub_find_rh_cb, NULL, dev, ah);
+
+	if ((gah = acpi_get_handle(grand)) == NULL)
+		return (AE_ERROR);
+
+	return (AcpiWalkNamespace(ACPI_TYPE_DEVICE, gah, 1,
+	acpi_uhub_find_rh_cb, NULL, dev, ah));
 }
 
-ACPI_STATUS
+static ACPI_STATUS
 acpi_usb_hub_port_probe_cb(ACPI_HANDLE ah, UINT32 lv, void *ctx, void **rv)
 {
 	ACPI_DEVICE_INFO *devinfo;
 	device_t dev = ctx;
 	struct acpi_uhub_softc *sc = device_get_softc(dev);
+	UINT32 ret;
 
-	if (usb_debug)
-		device_printf(dev, "%s\n", acpi_name(ah));
-
-	AcpiGetObjectInfo(ah, );
-	if ((devinfo->Valid & ACPI_VALID_ADR) &&
-	(devinfo->Address > 0) &&
-	(devinfo->Address <= (uint64_t)sc->nports)) {
-		sc->porthandle[devinfo->Address - 1] = ah;
-		acpi_uhub_parse_upc(dev, devinfo->Address, ah);
-		acpi_uhub_parse_pld(dev, devinfo->Address, ah);
-	} else {
-		device_printf(dev, "Skiping invalid devobj %s\n",
-		acpi_name(ah));
+	ret = AcpiGetObjectInfo(ah, );
+	if (ACPI_SUCCESS(ret)) {
+		if ((devinfo->Valid & ACPI_VALID_ADR) &&
+		(devinfo->Address > 0) &&
+		(devinfo->Address <= (uint64_t)sc->nports)) {
+			sc->porthandle[devinfo->Address - 1] = ah;
+			acpi_uhub_parse_upc(dev, devinfo->Address, ah);
+			acpi_uhub_parse_pld(dev, devinfo->Address, ah);
+		}
+		AcpiOsFree(devinfo);
 	}
-	AcpiOsFree(devinfo);
-	return AE_OK;
+	return (AE_OK);
 }
 
-ACPI_STATUS
+static ACPI_STATUS
 acpi_usb_hub_port_probe(device_t dev, ACPI_HANDLE ah)
 {
-	return AcpiWalkNamespace(ACPI_TYPE_DEVICE,
+	return (AcpiWalkNamespace(ACPI_TYPE_DEVICE,
 	ah, 1,
 	acpi_usb_hub_port_probe_cb,
-	NULL, 

Re: Someone broke USB

2019-07-08 Thread Hans Petter Selasky

On 2019-07-08 19:30, Steve Kargl wrote:

Setting hw.usb.explore_wait=500 in /boot/loader.conf
allowed the laptop to find the mouse and external
hard drive.  It seems at least for my laptop that
250 is too conservative.


I think there is a race on some shared variables inside the ACPI wrapper 
that was committed. Looking into it.


For example if I attach an external USB HUB to my machine it panics :-(

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Someone broke USB

2019-07-08 Thread Hans Petter Selasky

On 2019-07-08 19:24, Steve Kargl wrote:

Yes, the new sysctl is added.

% sysctl -a | grep usb | grep explore
hw.usb.explore_wait: 250


What happens if you set this sysctl to 1000 ?

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Someone broke USB

2019-07-08 Thread Hans Petter Selasky

On 2019-07-08 19:03, Steve Kargl wrote:

On Mon, Jul 08, 2019 at 11:50:31AM +0200, Hans Petter Selasky wrote:

Hi Steve,

Can you test this patch?

I made a slight variant which delay the explore threads instead of the
main thread running all the sysinits.

--HPS


With this patch, the kernel does not find any
USB devices.



Did you double check the patch was compiled?

Do you see the new sysctl added?

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Someone broke USB

2019-07-08 Thread Hans Petter Selasky

On 2019-07-08 12:06, Gary Jennejohn wrote:

On Mon, 8 Jul 2019 11:50:31 +0200
Hans Petter Selasky  wrote:


Hi Steve,

Can you test this patch?

I made a slight variant which delay the explore threads instead of the main 
thread running all the sysinits.



Shouldn't the patch set bus->explore_delay to 1 only if ms != 0?


I think it doesn't matter. The code is only supposed to be run once.

--HPS

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Someone broke USB

2019-07-08 Thread Hans Petter Selasky

Hi Steve,

Can you test this patch?

I made a slight variant which delay the explore threads instead of the 
main thread running all the sysinits.


--HPS
Index: sys/dev/usb/controller/usb_controller.c
===
--- sys/dev/usb/controller/usb_controller.c	(revision 349802)
+++ sys/dev/usb/controller/usb_controller.c	(working copy)
@@ -105,6 +105,10 @@
 SYSCTL_INT(_hw_usb, OID_AUTO, no_shutdown_wait, CTLFLAG_RWTUN,
 _no_shutdown_wait, 0, "No USB device waiting at system shutdown.");
 
+static int usb_explore_wait = 250;
+SYSCTL_INT(_hw_usb, OID_AUTO, explore_wait, CTLFLAG_RWTUN,
+_explore_wait, 0, "Delay in milliseconds between initial root HUB explore.");
+
 static devclass_t usb_devclass;
 
 static device_method_t usb_methods[] = {
@@ -373,6 +377,13 @@
 	if (bus->no_explore != 0)
 		return;
 
+	if (bus->explore_delay == 0) {
+		int ms = device_get_unit(bus->bdev) * usb_explore_wait;
+		bus->explore_delay = 1;
+		if (ms != 0)
+			usb_pause_mtx(>bus_mtx, howmany(ms * hz, 1000));
+	}
+
 	if (udev != NULL) {
 		USB_BUS_UNLOCK(bus);
 		uhub_explore_handle_re_enumerate(udev);
Index: sys/dev/usb/usb_bus.h
===
--- sys/dev/usb/usb_bus.h	(revision 349802)
+++ sys/dev/usb/usb_bus.h	(working copy)
@@ -131,6 +131,7 @@
 	uint8_t	do_probe;		/* set if USB should be re-probed */
 	uint8_t no_explore;		/* don't explore USB ports */
 	uint8_t dma_bits;		/* number of DMA address lines */
+	uint8_t explore_delay;		/* set if USB explore did initial delay */
 };
 
 #endif	/* _USB_BUS_H_ */
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Someone broke USB

2019-07-07 Thread Hans Petter Selasky

On 2019-07-07 22:36, Steve Kargl wrote:

On Sun, Jul 07, 2019 at 09:10:00PM +0200, Hans Petter Selasky wrote:

On 2019-07-07 20:58, Steve Kargl wrote:

I assume the pause goes after "max--;" statement.  I also
assume you want the info with the sysctl removed from
/boot/loader.conf.


You can play with it and see what happens.



Built kernel with pause() added, and commented out the
sysctl in /boot/loader.conf.  One reboot took a long
time to get to the a login prompt, but all of my USB
devices were found.  A few reboots appeared to hang
after probing the USB mouse (or perhaps I was too
impatient).

On a side note, it seems the wpi0 mapped to wlan0
is now unstable.  Luckily, I have an ath(4) pccard
that I can use instead of the builtin wifi of the
laptop.  The joys of current. :-)



It sounds like we have a race there and that a wait between the probes 
solves it.


Can you try the attached patch on top of -current:

--HPS
Index: sys/dev/usb/usb_hub.c
===
--- sys/dev/usb/usb_hub.c	(revision 349802)
+++ sys/dev/usb/usb_hub.c	(working copy)
@@ -2274,18 +2274,19 @@
 }
 
 /**
- *	usb_needs_explore_all
+ *	usb_needs_explore_all_flags
  *
  * This function is called whenever a new driver is loaded and will
  * cause that all USB buses are re-explored.
  **/
-void
-usb_needs_explore_all(void)
+static void
+usb_needs_explore_all_flags(int flags)
 {
 	struct usb_bus *bus;
 	devclass_t dc;
 	device_t dev;
 	int max;
+	int x;
 
 	DPRINTFN(3, "\n");
 
@@ -2297,9 +2298,9 @@
 	/*
 	 * Explore all USB buses in parallel.
 	 */
-	max = devclass_get_maxunit(dc);
-	while (max >= 0) {
-		dev = devclass_get_device(dc, max);
+	max = devclass_get_maxunit(dc) + 1;
+	for (x = 0; x < max; x++) {
+		dev = devclass_get_device(dc, x);
 		if (dev) {
 			bus = device_get_softc(dev);
 			if (bus) {
@@ -2306,10 +2307,17 @@
 usb_needs_explore(bus, 1);
 			}
 		}
-		max--;
+		if (flags & 1)
+			pause("W", hz / max);
 	}
 }
 
+void
+usb_needs_explore_all(void)
+{
+	usb_needs_explore_all_flags(0);
+}
+
 /**
  *	usb_needs_explore_init
  *
@@ -2324,7 +2332,7 @@
 	 * being called:
 	 */
 	if (cold == 0)
-		usb_needs_explore_all();
+		usb_needs_explore_all_flags(1);
 	else
 		DPRINTFN(-1, "Cold variable is still set!\n");
 }
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Someone broke USB

2019-07-07 Thread Hans Petter Selasky

On 2019-07-07 20:58, Steve Kargl wrote:

I assume the pause goes after "max--;" statement.  I also
assume you want the info with the sysctl removed from
/boot/loader.conf.


You can play with it and see what happens.

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Someone broke USB

2019-07-07 Thread Hans Petter Selasky

On 2019-07-07 18:58, Hans Petter Selasky wrote:

On 2019-07-07 18:54, Steve Kargl wrote:

This a 7720 line, 262KB file, do you want me to send it
to you in private email or put in my home directory on
freefall (i.e.,ka...@freefall.freebsd.org).


Send it to the people CC'ed, except the list.



Hi,

I'm wondering if there is a race by default, that wee need to explore 
the root HUBs in a certain order?


Can you try to reverse the order in usb_needs_explore_all() in 
sys/dev/usb and put a pause("W", hz); call between each iteration?


--HPS


void
usb_needs_explore_all(void)
{
struct usb_bus *bus;
devclass_t dc;
device_t dev;
int max;

DPRINTFN(3, "\n");

dc = usb_devclass_ptr;
if (dc == NULL) {
DPRINTFN(0, "no devclass\n");
return;
}
/*
 * Explore all USB buses in parallel.
 */
max = devclass_get_maxunit(dc);
while (max >= 0) {
dev = devclass_get_device(dc, max);
if (dev) {
bus = device_get_softc(dev);
if (bus) {
usb_needs_explore(bus, 1);
}
}
max--;
}
}

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Someone broke USB

2019-07-07 Thread Hans Petter Selasky

On 2019-07-07 18:54, Steve Kargl wrote:

This a 7720 line, 262KB file, do you want me to send it
to you in private email or put in my home directory on
freefall (i.e.,ka...@freefall.freebsd.org).


Send it to the people CC'ed, except the list.

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Someone broke USB

2019-07-07 Thread Hans Petter Selasky

On 2019-07-07 10:05, Steve Kargl wrote:

On Sat, Jul 06, 2019 at 04:14:53PM -0700, Steve Kargl wrote:

On Sat, Jul 06, 2019 at 03:08:13PM -0600, Ian Lepore wrote:


It seems almost certain to be r349161 that causes the problem.



I've backed out the change, and the buildkernel is currently
running.  It won't finish for an hour or so (old hardware and
rebuilding another project).



I can confirm that r349161 is the cause of my problem.



Hi,

Can you try the latest -current with:
debug.acpi.disabled="usb"

In /boot/loader.conf ?

Also can you dump the ACPI tables:
acpidump -dt > dump.txt

In the failing and working case can you show the differences in output from:
devinfo

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Someone broke USB

2019-07-06 Thread Hans Petter Selasky

Hi Takanori,

Can you have a look at the issues reported in this thread?

Are the ACPI functions you call thread safe? USB will enumerate multiple 
busses at the same time.


--HPS

On 2019-07-06 23:08, Ian Lepore wrote:

On Sat, 2019-07-06 at 14:06 -0700, Steve Kargl wrote:

On Sat, Jul 06, 2019 at 10:50:59PM +0200, Hans Petter Selasky wrote:

On 2019-07-06 21:41, Steve Kargl wrote:

On Sat, Jul 06, 2019 at 08:33:39PM +0200, Hans Petter Selasky
wrote:

On 2019-07-06 20:23, Steve Kargl wrote:

So, how does one get usb working, again?

-- Steve


Can you show dmesg?



It looks like the enumeration of busses and devices has changed.
grepping for uhub and usbus of the working and broken dmesg.boot
gives



Are you able to bisect the commit introducing the bad behaviour?



I'll give it a shot.  I have two revision number to work with.



It seems almost certain to be r349161 that causes the problem.




___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Someone broke USB

2019-07-06 Thread Hans Petter Selasky

On 2019-07-06 21:41, Steve Kargl wrote:

On Sat, Jul 06, 2019 at 08:33:39PM +0200, Hans Petter Selasky wrote:

On 2019-07-06 20:23, Steve Kargl wrote:

So, how does one get usb working, again?

-- Steve


Can you show dmesg?



It looks like the enumeration of busses and devices has changed.
grepping for uhub and usbus of the working and broken dmesg.boot
gives



Are you able to bisect the commit introducing the bad behaviour?

--HPS

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Someone broke USB

2019-07-06 Thread Hans Petter Selasky

On 2019-07-06 20:23, Steve Kargl wrote:

So, how does one get usb working, again?

-- Steve


Can you show dmesg?

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Problem with USB after r349133

2019-07-05 Thread Hans Petter Selasky

On 2019-07-05 17:38, Thomas Laus wrote:

I upgraded to CURRENT r349575 this week and my Dell Inspiron laptop
stops processing the rc.conf with this message that repeats until I
perform a hard power button reset, ctl-alt-del has no effect:

Root mount waiting for USBUS7 USBUS6  USBUS0.

I booted my kernel.old and everything is fine at r349133.  I performed
another CURRENT update today to r349765 and got the same result.  Has
there been any significant changes to the USB probing and mounting in
the last few weeks.  All of my desktops are not seeing this problem, it
is only my Dell laptop.



There has been very few USB changes, except for ACPI USB support in:

https://svnweb.freebsd.org/changeset/base/349161
https://svnweb.freebsd.org/changeset/base/349251

--HPS

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


  1   2   3   4   5   6   7   8   9   >