On Sat, Aug 24, 2019 at 05:29:23PM -0600, Rebecca Cran wrote:
> On 2019-08-24 17:08, Konstantin Belousov wrote:
> >
> > Use gdb instead.
>
> Ah, thanks.
>
> (gdb) info line *0x8117f67c
> Line 405 of "/usr/src/sys/amd64/amd64/mp_machdep.c" starts at address
> 0x8117f674 and ends a
On 2019-08-24 17:08, Konstantin Belousov wrote:
>
> Do you happen to have NUMA node without any local memory ? (Look at the
> SRAT table). If yes, try this patch.
I've just remembered, that's one of the big differences between
ThreadRipper and EPYC: the EPYC has memory links on all four dies, whi
On 2019-08-24 17:08, Konstantin Belousov wrote:
>
> Use gdb instead.
Ah, thanks.
(gdb) info line *0x8117f67c
Line 405 of "/usr/src/sys/amd64/amd64/mp_machdep.c" starts at address
0x8117f674 and ends at
0x8117f69a
> What was the previous bootable version of the kernel ?
On 2019-08-24 14:04, Konstantin Belousov wrote:
> On Sat, Aug 24, 2019 at 11:02:20AM -0600, Warner Losh wrote:
>> forward declaring struct pcpu; in md_var.h "fixes" this, but I'm not sure
>> that's the right fix.
> More correct way to fix it is to include sys/pcpu.h before machine/md_var.h,
> same
On Sat, Aug 24, 2019 at 04:54:26PM -0600, Rebecca Cran wrote:
> On 2019-08-24 14:33, Konstantin Belousov wrote:
> > On Sat, Aug 24, 2019 at 02:22:18PM -0600, Rebecca Cran wrote:
> >> instruction pointer = 0x20: 0x811bc664
> > So what is the source line for this address ?
>
>
> I built a n
On 2019-08-24 14:33, Konstantin Belousov wrote:
> On Sat, Aug 24, 2019 at 02:22:18PM -0600, Rebecca Cran wrote:
>> instruction pointer = 0x20: 0x811bc664
> So what is the source line for this address ?
I built a new kernel and got a new panic instruction pointer address of
0x8117f
YES! YES! YES!
THANKS VERY, VERY MUCH EVERYONE, especially Greg & Evilham. It now works!!!
I had been fighting this problem for three weeks of 13.0 Current snapshots
and failed until now. I was never so glad to see that window load with the
three terminals & a clock. The rest is a piece of cake.
On Sat, Aug 24, 2019 at 2:06 PM Clay Daniels Jr.
wrote:
> Greg, thanks for the wonderful suggestion. Where should I put this line: "
> hw.syscons.disable=1 "
> I tried it in /etc/rc.conf and it booted into the console as usual with
> repeated messages:
> /etc/rc.conf hw.syscons.disable=1: not fo
On Sat, Aug 24, 2019 at 02:22:18PM -0600, Rebecca Cran wrote:
> I updated my kernel to r351461 today and now get a panic on boot.
>
>
> CPU: AMD Ryzen Threadripper 2990WX 32-Core Processor (2994.45-MHz
> K8-class CPU)
> Origin="AuthenticAMD" Id=0x800f82 Family=0x17 Model=0x8 Stepping=2
>
I updated my kernel to r351461 today and now get a panic on boot.
CPU: AMD Ryzen Threadripper 2990WX 32-Core Processor (2994.45-MHz
K8-class CPU)
Origin="AuthenticAMD" Id=0x800f82 Family=0x17 Model=0x8 Stepping=2
Features=0x178bfbff
Features2=0x7ed8320b
AMD Features=0x2e500800
AMD
F
On ds., ag. 24 2019, Clay Daniels, Jr. wrote:
Greg, thanks for the wonderful suggestion. Where should I put
this line: "
hw.syscons.disable=1 "
I tried it in /etc/rc.conf and it booted into the console as
usual with
repeated messages:
/etc/rc.conf hw.syscons.disable=1: not found
I think
Greg, thanks for the wonderful suggestion. Where should I put this line: "
hw.syscons.disable=1 "
I tried it in /etc/rc.conf and it booted into the console as usual with
repeated messages:
/etc/rc.conf hw.syscons.disable=1: not found
I could login to the console as usual, but trying to run startx
On Sat, Aug 24, 2019 at 11:02:20AM -0600, Warner Losh wrote:
> forward declaring struct pcpu; in md_var.h "fixes" this, but I'm not sure
> that's the right fix.
More correct way to fix it is to include sys/pcpu.h before machine/md_var.h,
same as all in-tree consumers of the header do, apparently.
forward declaring struct pcpu; in md_var.h "fixes" this, but I'm not sure
that's the right fix.
Warner
On Sat, Aug 24, 2019 at 10:35 AM Michael Butler
wrote:
> As follows ..
>
> Building
>
> /usr/obj/usr/src/amd64.amd64/sys/TOSHI/modules/usr/local/sys/modules/drm-current-kmod/linuxkpi/linux_com
As follows ..
Building
/usr/obj/usr/src/amd64.amd64/sys/TOSHI/modules/usr/local/sys/modules/drm-current-kmod/linuxkpi/linux_compat.o
--- linux_compat.o ---
In file included from
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_compat.c:5:
./machine/md_var.h:61:34: error: declaratio
On August 24, 2019 10:15:22 AM GMT+03:00, "Clay Daniels Jr."
wrote:
>From the kmod ports, dated 20190814
>
>
>/usr/ports/graphics/drm-current-kmod/pkg-descr
>
>"amdgpu and radeonkms are known to fail with EFI Boot"
>
>
>/usr/ports/graphics/drm-current-kmod/pkg-message
>
>"some positive reports if
On Sat, 24 Aug 2019 02:15:22 -0500
"Clay Daniels Jr." wrote:
> From the kmod ports, dated 20190814
>
>
> /usr/ports/graphics/drm-current-kmod/pkg-descr
>
> "amdgpu and radeonkms are known to fail with EFI Boot"
>
>
> /usr/ports/graphics/drm-current-kmod/pkg-message
>
> "some positive report
>From the kmod ports, dated 20190814
/usr/ports/graphics/drm-current-kmod/pkg-descr
"amdgpu and radeonkms are known to fail with EFI Boot"
/usr/ports/graphics/drm-current-kmod/pkg-message
"some positive reports if EFI is not enabled"
Any practical suggestions on getting drm-current-kmod to
18 matches
Mail list logo
