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.

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

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

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

2020-09-14 Thread Hans Petter Selasky
ng 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 showin

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

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

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

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

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:

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

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),

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

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

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

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 =

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

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

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

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

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

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

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 ___

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.

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

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

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

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),

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

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

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

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

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

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

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

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

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

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.

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:

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

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

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

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

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 =

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

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

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

[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

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 =

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

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

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

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

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

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

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

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

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 t

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

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

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?

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

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

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

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

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

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)

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

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

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

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

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 ---

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

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

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 (

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

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

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

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

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)

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

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

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

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

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

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 @@

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

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

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

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

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 === ---

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. Yo

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 ___

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

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

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

Re: Someone broke USB

2019-07-06 Thread Hans Petter Selasky
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

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

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

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

  1   2   3   4   5   6   7   8   9   >