Re: DRM and higher screen resolutions on older hardware for current/13-ALPHA3

[Graham Perrin]

On 05/02/2021 06:09, George Michaelson wrote:

I have a Lenovo Edge 420 with the ATI/Radeon graphics card.


Please, which card, exactly?

This utility can help to gather useful information:

sysutils/hw-probe

A recent probe of my own notebook (with Radeon hardware), but please 
note that it's not a 2018 model, it's more like 2013:





The "this .ko, that blob" thing is really confusing if you've been out
of the loop for a while, and with older hardwar (its 8+ year old
laptop) its not impossible its fallen off the curve of available .ko
drivers.

Anyone have any practical guidance to which radeon.ko I want to load?
Not seeing valid Xorg with any of them and finding 640x480 tiresome.


In most cases, it should suffice to edit your rc.conf as described at 
.


If you have not already done so, try installing:

x11-drivers/xf86-video-ati

Exceptionally
=

% grep -B 1 kld_list /etc/rc.conf

# The system may fail to present sddm if kld_list is set to
# load radeonkms -- instead, load drm
kld_list="cuse fusefs drm"

# kld_list="/boot/modules/drm.ko"
# kld_list="amdgpu"
# kld_list="/boot/modules/radeonkms.ko"
# kld_list="radeonkms"
%

___
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 and higher screen resolutions on older hardware for current/13-ALPHA3

[George Michaelson]

Thanks. That's most helpful! compiling now "lets see what happens"

-G

On Fri, Feb 5, 2021 at 5:06 PM Bakul Shah  wrote:
>
>
>
> > On Feb 5, 2021, at 6:09 AM, George Michaelson  wrote:
> >
> > I have a Lenovo Edge 420 with the ATI/Radeon graphics card.
> >
> > The "this .ko, that blob" thing is really confusing if you've been out
> > of the loop for a while, and with older hardwar (its 8+ year old
> > laptop) its not impossible its fallen off the curve of available .ko
> > drivers.
> >
> > Anyone have any practical guidance to which radeon.ko I want to load?
> > Not seeing valid Xorg with any of them and finding 640x480 tiresome.
>
> In rc.conf I have
>
> kld_list="ig4 iichid amdgpu"
>
> Replace amdgpu with radeonkms. It will in turn load various
> radeon*_bin.ko modules for firmware. I don't have this
> card so this is just a guess (I am running 13.0-ALPHA3).
> Compile /usr/ports/graphics/drm-fbsd13-kmod at the same
> time as the kernel by adding
>
> PORTS_MODULES=graphics/drm-fbsd13-kmod
> PORTS_MODULES+=graphics/gpu-firmware-kmod
>
> to /etc/src.conf. AFAIK installing a package won't work.
>
> I need ig4 and iichid drivers for the touchpad.
___
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 and higher screen resolutions on older hardware for current/13-ALPHA3

[Bakul Shah]

> On Feb 5, 2021, at 6:09 AM, George Michaelson  wrote:
> 
> I have a Lenovo Edge 420 with the ATI/Radeon graphics card.
> 
> The "this .ko, that blob" thing is really confusing if you've been out
> of the loop for a while, and with older hardwar (its 8+ year old
> laptop) its not impossible its fallen off the curve of available .ko
> drivers.
> 
> Anyone have any practical guidance to which radeon.ko I want to load?
> Not seeing valid Xorg with any of them and finding 640x480 tiresome.

In rc.conf I have

kld_list="ig4 iichid amdgpu"

Replace amdgpu with radeonkms. It will in turn load various
radeon*_bin.ko modules for firmware. I don't have this
card so this is just a guess (I am running 13.0-ALPHA3).
Compile /usr/ports/graphics/drm-fbsd13-kmod at the same
time as the kernel by adding

PORTS_MODULES=graphics/drm-fbsd13-kmod
PORTS_MODULES+=graphics/gpu-firmware-kmod

to /etc/src.conf. AFAIK installing a package won't work.

I need ig4 and iichid drivers for the touchpad.
___
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"

DRM and higher screen resolutions on older hardware for current/13-ALPHA3

[George Michaelson]

I have a Lenovo Edge 420 with the ATI/Radeon graphics card.

The "this .ko, that blob" thing is really confusing if you've been out
of the loop for a while, and with older hardwar (its 8+ year old
laptop) its not impossible its fallen off the curve of available .ko
drivers.

Anyone have any practical guidance to which radeon.ko I want to load?
Not seeing valid Xorg with any of them and finding 640x480 tiresome.

-G
___
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"

debug a BCM43224 bwn WiFi in a Lenovo laptop, ALPHA3

[George Michaelson]

I have a Lenovo E420 with the BCM43224.

FreeBSD-13-ALPHA3, locally compiled kernel. (I have built the
requisite WIFI kernel with the PHY_N and DEBUG options) and now, I can
see a bwn0 instance with a blob loaded.

But when I configure it into rc.conf as the wlan0 instance and do
wpa_supplicant.conf it hangs,
and it hangs during boot, if its enabled during boot for this task.

Happy to supply all and any input as directed.

If you want this done in the send-pr I can do that too. (hoping
there's a known fix)

-G
___
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"

mrsas breaks buildkernel

[Steve Kargl]

===> mps (all)
===> mpt (all)
===> mqueue (all)
===> mrsas (all)
cc -target i386-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/i386.i386/tmp 
-B/usr/obj/usr/src/i386.i386/tmp/usr/bin  -O2 -pipe -fno-common -march=core2  
-fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -DKLD_TIED -nostdinc   
-DHAVE_KERNEL_OPTION_HEADERS -include 
/usr/obj/usr/src/i386.i386/sys/MOBILE/opt_global.h -I. -I/usr/src/sys 
-I/usr/src/sys/contrib/ck/include -fno-common -g 
-fdebug-prefix-map=./machine=/usr/src/sys/i386/include 
-fdebug-prefix-map=./x86=/usr/src/sys/x86/include 
-I/usr/obj/usr/src/i386.i386/sys/MOBILE -MD  -MF.depend.mrsas.o -MTmrsas.o 
-mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes 
-Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign 
-D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs 
-fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare 
-Wno-error-empty-body -Wno-error-parentheses-equality 
-Wno-error-unused-function -Wn
 o-error-pointer-sign -Wno-error-shift-negative-value 
-Wno-address-of-packed-member -Wno-format-zero-length   -mno-aes -mno-avx  
-std=iso9899:1999 -fgnu89-inline -c /usr/src/sys/dev/mrsas/mrsas.c -o mrsas.o
/usr/src/sys/dev/mrsas/mrsas.c:2786:67: error: shift count >= width of type 
[-Werror,-Wshift-count-overflow]
req_desc.addr.u.high = htole32((bus_addr_t)sc->ioc_init_phys_mem >> 32);
 ^  ~~
/usr/src/sys/sys/endian.h:74:32: note: expanded from macro 'htole32'
#define htole32(x)  ((uint32_t)(x))
^
1 error generated.
*** Error code 1

Stop.
make[4]: stopped in /usr/src/sys/modules/mrsas
*** Error code 1

Stop.
make[3]: stopped in /usr/src/sys/modules
*** Error code 1

Stop.
make[2]: stopped in /usr/obj/usr/src/i386.i386/sys/MOBILE
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src
-- 
Steve
___
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: gib driver problems?

[joe mcguckin]

igb0@pci0:7:0:0:class=0x02 card=0x152115d9 chip=0x15218086 rev=0x01 
hdr=0x00
vendor = 'Intel Corporation'
device = 'I350 Gigabit Network Connection'
class  = network
subclass   = ethernet
igb1@pci0:7:0:1:class=0x02 card=0x152115d9 chip=0x15218086 rev=0x01 
hdr=0x00
vendor = 'Intel Corporation'
device = 'I350 Gigabit Network Connection'
class  = network
subclass   = ethernet
igb2@pci0:7:0:2:class=0x02 card=0x152115d9 chip=0x15218086 rev=0x01 
hdr=0x00
vendor = 'Intel Corporation'
device = 'I350 Gigabit Network Connection'
class  = network
subclass   = ethernet
igb3@pci0:7:0:3:class=0x02 card=0x152115d9 chip=0x15218086 rev=0x01 
hdr=0x00
vendor = 'Intel Corporation'
device = 'I350 Gigabit Network Connection'
class  = network
subclass   = ethernet



Joe McGuckin
ViaNet Communications

j...@via.net
650-207-0372 cell
650-213-1302 office
650-969-2124 fax



> On Feb 3, 2021, at 11:36 PM, sth...@nethelp.no wrote:
> 
>> PCIID? I’m not sure how to get that information. Will the bootup info help? 
>> Here’s a picture.
> 
> You want the output from "pciconf -lv". Example from a system here:
> 
> igb0@pci0:2:0:0:class=0x02 card=0x3380103c chip=0x15218086 
> rev=0x01 hdr=0x00
>vendor = 'Intel Corporation'
>device = 'I350 Gigabit Network Connection'
>class  = network
>subclass   = ethernet
> 
> Steinar Haug, Nethelp consulting, sth...@nethelp.no

___
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 in drm or vt or deadlock on mutex or ...

[Steve Kargl]

On Thu, Feb 04, 2021 at 10:50:29AM +0100, Emmanuel Vadot wrote:
> On Wed, 3 Feb 2021 08:03:24 -0800
> Steve Kargl  wrote:
> 
> > On Wed, Feb 03, 2021 at 10:42:21AM +0200, Andriy Gapon wrote:
> > > On 03/02/2021 07:08, Steve Kargl wrote:
> > > > Fatal trap 12: page fault while in kernel mode
> > > > cpuid = 0; apic id = 00
> > > > fault virtual address   = 0xc374
> > > > fault code  = supervisor read data, page not present
> > > > instruction pointer = 0x20:0xef411f
> > > > stack pointer   = 0x28:0x4074e97c
> > > > frame pointer   = 0x28:0x4074e988
> > > > code segment= base 0x0, limit 0xf, type 0x1b
> > > > = DPL 0, pres 1, def32 1, gran 1
> > > > processor eflags= interrupt enabled, resume, IOPL = 0
> > > > current process = 91696 (chrome)
> > > > trap number = 12
> > > ...
> > > > panic: page fault
> > > > cpuid = 0
> > > > time = 1612328062
> > > > KDB: stack backtrace:
> > > > db_trace_self_wrapper(2,4074e93c,c,0,4074e800,...) at 
> > > > db_trace_self_wrapper+0x28/frame 0x4074e7d4
> > > > vpanic(f9d603,4074e80c,4074e80c,4074e834,f6e2b7,...) at 
> > > > vpanic+0x11a/frame 0x4074e7ec
> > > > panic(f9d603,fe16b8,0,f,c39b,...) at panic+0x14/frame 0x4074e800
> > > > trap_fatal(1327100,0,c95893,78f03f4,4074e860,...) at 
> > > > trap_fatal+0x347/frame 0x4074e834
> > > > trap_pfault(c374,0,0) at trap_pfault+0x30/frame 0x4074e864
> > > > trap(4074e93c,8,28,28,0,...) at trap+0x381/frame 0x4074e930
> > > > calltrap() at 0xffc0319f/frame 0x4074e930
> > > > --- trap 0xc, eip = 0xef411f, esp = 0x4074e97c, ebp = 0x4074e988 ---
> > > > vm_radix_lookup(28c7b884,2,0) at vm_radix_lookup+0x7f/frame 0x4074e988
> > > > vm_page_lookup(28c7b854,2,0) at vm_page_lookup+0x15/frame 0x4074e99c
> > > > vm_fault(24ed8d58,3488b000,2,0,4074eab0) at vm_fault+0x839/frame 
> > > > 0x4074ea48
> > > > vm_fault_quick_hold_pages(24ed8d58,34889f00,8000,2,4074eaa8,12) at 
> > > > vm_fault_quick_hold_pages+0x122/frame 0x4074ea88
> > > > vn_io_fault1(247f4380) at vn_io_fault1+0x214/frame 0x4074eb44
> > > > vn_io_fault(2f5a58e8,4074ebc8,262c1e00,0,247f4380) at 
> > > > vn_io_fault+0x1c4/frame 0x4074eb7c
> > > > dofileread(2f5a58e8,4074ebc8,,,0) at 
> > > > dofileread+0x6d/frame 0x4074ebac
> > > > sys_read(247f4380,247f4618,343fb000,247f4380,40516068,...) at 
> > > > sys_read+0x67/frame 0x4074ec00
> > > > syscall(4074ece8,3b,3b,3b,2d130d1c,...) at syscall+0x17d/frame 
> > > > 0x4074ecdc
> > > > Xint0x80_syscall() at 0xffc033f9/frame 0x4074ecdc
> > > > --- syscall (881410048), eip = 0x2d086faf, esp = 0xfa1e339c, ebp = 
> > > > 0xfa1e33c8 ---
> > > > KDB: enter: panic
> > > 
> > > This is the crash.
> > > The DRM mutex noise is just noise (but it would be good to get rid of it).
> > 
> > OK.  It only happens with drm.
> > 
> > What other info is needed to help track this down?
> > I have kernel.debug, vmcore.0, and core.txt.0, so 
> > can use kgdb if someone would like more information.
> 
>  Only happens with drm when you do what ?
> 

Well, for this panic, I tried to start chrome.
The system has also panicked with simply doing
'kldload i915kms.ko'.

-- 
Steve
___
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: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?

[Ian FREISLICH]

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

Any ideas on this bug related to aesni + sha?

[Rick Macklem]

Crypto is way out of my area of expertise.
Anyone have ideas on this?

Thanks, rick


From: Peter Eriksson 
Sent: Thursday, February 4, 2021 6:56 AM
To: Rick Macklem
Subject: Have you seen this bug?

CAUTION: This email originated from outside of the University of Guelph. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe. If in doubt, forward suspicious emails to ith...@uoguelph.ca


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

This sounds like a bug in the in-kernel crypto stuff and not NFS/krb5i per se, 
but still.. Currently we’re not afflicted by it since our FreeBSD servers don’t 
have the SHA acceleration support - but we’re starting to discuss what servers 
to get for our next generation and then it might become a problem…

- Peter

___
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: gib driver problems?

[Joe Mcguckin]

Thanks!

Joe

> On Feb 3, 2021, at 11:37 PM, sth...@nethelp.no wrote:
> 
> 
>> 
>> PCIID? I’m not sure how to get that information. Will the bootup info help? 
>> Here’s a picture.
> 
> You want the output from "pciconf -lv". Example from a system here:
> 
> igb0@pci0:2:0:0:class=0x02 card=0x3380103c chip=0x15218086 
> rev=0x01 hdr=0x00
>vendor = 'Intel Corporation'
>device = 'I350 Gigabit Network Connection'
>class  = network
>subclass   = ethernet
> 
> Steinar Haug, Nethelp consulting, sth...@nethelp.no

___
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: Failure of release build with release.sh on 14-CURRENT amd64

[Michael Gmelin]

> On 4. Feb 2021, at 10:47, Yasuhiro Kimura  wrote:
> 
> It's a bit off topic from the first question, but please let me ask
> another one.
> 
> When everything is default, devel/git and textproc/docproj are
> installed in chroot environment after building userland and installing
> it to chroot has completed. While the former is installed by using
> official package, the latter is installed by using ports tree checked
> out in chroot.
> 
> Then is there any reason doing so? Why aren't both of them installed
> by using offical package nor by using ports tree?

I would assume that this is because

- textproc/docproj is the FreeBSD Documentation Project and therefore you 
always want to have the latest version, especially when working with CURRENT 
(so it’s part of our development effort).
- git is a third party tool maintained outside of the project (we won’t change 
it as part of developing FreeBSD)

Cheers,
Michael


> 
> ---
> Yasuhiro Kimura
> ___
> 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: panic in drm or vt or deadlock on mutex or ...

[Emmanuel Vadot]

On Wed, 3 Feb 2021 08:03:24 -0800
Steve Kargl  wrote:

> On Wed, Feb 03, 2021 at 10:42:21AM +0200, Andriy Gapon wrote:
> > On 03/02/2021 07:08, Steve Kargl wrote:
> > > Fatal trap 12: page fault while in kernel mode
> > > cpuid = 0; apic id = 00
> > > fault virtual address = 0xc374
> > > fault code= supervisor read data, page not present
> > > instruction pointer   = 0x20:0xef411f
> > > stack pointer = 0x28:0x4074e97c
> > > frame pointer = 0x28:0x4074e988
> > > code segment  = base 0x0, limit 0xf, type 0x1b
> > >   = DPL 0, pres 1, def32 1, gran 1
> > > processor eflags  = interrupt enabled, resume, IOPL = 0
> > > current process   = 91696 (chrome)
> > > trap number   = 12
> > ...
> > > panic: page fault
> > > cpuid = 0
> > > time = 1612328062
> > > KDB: stack backtrace:
> > > db_trace_self_wrapper(2,4074e93c,c,0,4074e800,...) at 
> > > db_trace_self_wrapper+0x28/frame 0x4074e7d4
> > > vpanic(f9d603,4074e80c,4074e80c,4074e834,f6e2b7,...) at 
> > > vpanic+0x11a/frame 0x4074e7ec
> > > panic(f9d603,fe16b8,0,f,c39b,...) at panic+0x14/frame 0x4074e800
> > > trap_fatal(1327100,0,c95893,78f03f4,4074e860,...) at 
> > > trap_fatal+0x347/frame 0x4074e834
> > > trap_pfault(c374,0,0) at trap_pfault+0x30/frame 0x4074e864
> > > trap(4074e93c,8,28,28,0,...) at trap+0x381/frame 0x4074e930
> > > calltrap() at 0xffc0319f/frame 0x4074e930
> > > --- trap 0xc, eip = 0xef411f, esp = 0x4074e97c, ebp = 0x4074e988 ---
> > > vm_radix_lookup(28c7b884,2,0) at vm_radix_lookup+0x7f/frame 0x4074e988
> > > vm_page_lookup(28c7b854,2,0) at vm_page_lookup+0x15/frame 0x4074e99c
> > > vm_fault(24ed8d58,3488b000,2,0,4074eab0) at vm_fault+0x839/frame 
> > > 0x4074ea48
> > > vm_fault_quick_hold_pages(24ed8d58,34889f00,8000,2,4074eaa8,12) at 
> > > vm_fault_quick_hold_pages+0x122/frame 0x4074ea88
> > > vn_io_fault1(247f4380) at vn_io_fault1+0x214/frame 0x4074eb44
> > > vn_io_fault(2f5a58e8,4074ebc8,262c1e00,0,247f4380) at 
> > > vn_io_fault+0x1c4/frame 0x4074eb7c
> > > dofileread(2f5a58e8,4074ebc8,,,0) at 
> > > dofileread+0x6d/frame 0x4074ebac
> > > sys_read(247f4380,247f4618,343fb000,247f4380,40516068,...) at 
> > > sys_read+0x67/frame 0x4074ec00
> > > syscall(4074ece8,3b,3b,3b,2d130d1c,...) at syscall+0x17d/frame 0x4074ecdc
> > > Xint0x80_syscall() at 0xffc033f9/frame 0x4074ecdc
> > > --- syscall (881410048), eip = 0x2d086faf, esp = 0xfa1e339c, ebp = 
> > > 0xfa1e33c8 ---
> > > KDB: enter: panic
> > 
> > This is the crash.
> > The DRM mutex noise is just noise (but it would be good to get rid of it).
> 
> OK.  It only happens with drm.
> 
> What other info is needed to help track this down?
> I have kernel.debug, vmcore.0, and core.txt.0, so 
> can use kgdb if someone would like more information.
> 
> __ 
> steve

 Only happens with drm when you do what ?

-- 
Emmanuel Vadot  
___
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: Failure of release build with release.sh on 14-CURRENT amd64

[Yasuhiro Kimura]

It's a bit off topic from the first question, but please let me ask
another one.

When everything is default, devel/git and textproc/docproj are
installed in chroot environment after building userland and installing
it to chroot has completed. While the former is installed by using
official package, the latter is installed by using ports tree checked
out in chroot.

Then is there any reason doing so? Why aren't both of them installed
by using offical package nor by using ports tree?

---
Yasuhiro Kimura
___
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"