date:20181115

RE: UEFI GOP: screen goes blank during boot after loader is finished

2018-11-15 Thread Matt Churchyard

-Original Message-
From: owner-freebsd-virtualizat...@freebsd.org 
 On Behalf Of Warner Losh
Sent: 15 November 2018 02:57
To: Kyle Evans 
Cc: FreeBSD Current ; Rodney W. Grimes 
; freebsd-virtualizat...@freebsd.org
Subject: Re: UEFI GOP: screen goes blank during boot after loader is finished

On Wed, Nov 14, 2018 at 4:00 PM Kyle Evans  wrote:

> On Wed, Nov 14, 2018 at 4:55 PM Subbsd  wrote:
> >
> > On Thu, Nov 15, 2018 at 1:33 AM Kyle Evans  wrote:
> > >
> > > On Wed, Nov 14, 2018 at 4:30 PM Kyle Evans  wrote:
> > > >
> > > > On Wed, Nov 14, 2018 at 4:23 PM Subbsd  wrote:
> > > > >
> > > > > On Thu, Nov 15, 2018 at 1:05 AM Subbsd  wrote:
> > > > > >
> > > > > > On Thu, Nov 15, 2018 at 12:21 AM Rebecca Cran <
> rebe...@bluestop.org> wrote:
> > > > > > >
> > > > > > > On November 14, 2018 at 2:18:04 PM, Subbsd 
> > > > > > > (sub...@gmail.com)
> wrote:
> > > > > > >>
> > > > > > >>
> > > > > > >> My current host: FreeBSD 13.0-CURRENT r340319 and the 
> > > > > > >> problem
> is
> > > > > > >> still present.
> > > > > > >
> > > > > > > Rod was asking about the guest OS version, not the host though.
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > I apologize, it seemed to me that I wrote earlier) Guest version:
> > > > > >
> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0
> /FreeBSD-13.0-CURRENT-amd64-20181101-r339979-disc1.iso.xz
> > > > >
> > > > > Hm, it seems the problem is 'boot_serial' which is sets to YES 
> > > > > by
> default in gop
> > > > >
> > > > > set boot_serial=NO
> > > > > boot
> > > > >
> > > > > solve this issue
> > > >
> > > > Huh? This is perhaps going to be a stupid question, but where is 
> > > > boot_serial=YES getting set? Loader will not set it by itself 
> > > > and
> UEFI
> > > > doesn't respect /boot.config, so this must be explicitly set in 
> > > > /boot/loader.conf or /boot/defaults/loader.conf, but it's not 
> > > > clear
> to
> > > > me what's putting it there.
> > >
> > >
> http://src.illumos.org/source/xref/freebsd-head/usr.sbin/bhyveload/bhy
> veload.c#832
> > > is the only place I can see immediately that this might be 
> > > happening, but do UEFI boots go through bhyveload? I'm ignorant here.
> >
> > This is UEFI GOP methodvia bootrom/uefi-firmware, no bhyveload:
> >
> > bhyve -AHP -s 0:0,hostbridge -s 31:0,lpc -s 
> > 4:0,ahci-cd,/tmp/FreeBSD-13.0-CURRENT-amd64-20181101-r339979-disc1.i
> > so -c 1 -m 1024M -s 29,fbuf,tcp=0.0.0.0:5900,w=1024,h=768,wait -l 
> > bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd freebsd1
> >
> > https://snag.gy/0MH7zU.jpg
> > https://snag.gy/kF5cxZ.jpg
> > https://snag.gy/htHMG0.jpg
> > https://snag.gy/vK1ALN.jpg
> > https://snag.gy/qKNPGU.jpg
>
> What does your /boot/loader.conf look like?
>

>What is the ConOut evifar look like? We set serial when the UEFI env says to 
>do  so.

>Warner

I can confirm that 11.2-REL boots fine but 12.0-BETA4 goes blank just after the 
loader, using the exact same bhyve configuration. (This is on an 11.2 host)
A few lines are output just before going blank but I can't catch what they say.

I'm using the official ISO files with no other configuration so it does seem 
that 12.0 will currently not boot under UEFI-GOP bhyve.

I can check the efivars if someone lets me know how.

Matt
___
freebsd-virtualizat...@freebsd.org mailing list 
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-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: UEFI GOP: screen goes blank during boot after loader is finished

2018-11-15 Thread Rebecca Cran

On Wednesday, 14 November 2018 19:56:56 MST Warner Losh wrote:

> What is the ConOut evifar look like? We set serial when the UEFI env says
> to do  so.

Booting with:

sudo bhyve -A -P -c 2 -H -m 4G -s 0:0,hostbridge -s 31:0,lpc -s 2,ahci-
cd,FreeBSD-12.0-BETA4-amd64-disc1.iso -s 
29,fbuf,tcp=0.0.0.0:5900,w=800,h=600,wait -l bootrom,/usr/local/share/uefi-
firmware/BHYVE_UEFI.fd -u vm5

dh in the shell shows:

7D: ConsoleOut SimpleTextOut GraphicsOutput(GraphicsOutput)
PCIIO DevicePath(PciRoot (0x0)/Pci(0x1D,0x0))

84: StdErr ConsoleOut ConsoleIn SimpleTextOut SimpleTextInEx SimpleTextIn 
DevicePath(t(115200,8,N,1)/VenVt100Plus())

89: SimpleTextOut SimpleTextInEx SimpleTextIn DevicePath(Uart(115200,8,N,1)/
VenPcAnsi())

-- 
Rebecca


___
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: [regression] drm-stable-kmod doesn't work in i386 jail on amd64 host

2018-11-15 Thread Jan Beich

Jan Beich  writes:

> I often test Firefox on 10.4 i386 and sometimes play games via Wine.
> Both require working OpenGL for COMPAT_FREEBSD32. My GPU is Skylake
> which worked fine a few weegs ago i.e., before r338990.
>
> Any clue?

I've opened https://github.com/FreeBSDDesktop/kms-drm/issues/99 but so
far no response. Would a sample would help?

$ cc -o test test.c
$ cc -m32 -o test32 test.c

$ pciconf -l | fgrep 0:0:2:0
vgapci1@pci0:0:2:0: class=0x03 card=0x79681462 chip=0x19128086 rev=0x06 
hdr=0x00
$ /poudriere/jails/112i386/usr/sbin/pciconf -l
pciconf: ioctl(PCIOCGETCONF): Operation not permitted

$ ./test 0 0 2 0
vendor=0x8086, device=0x1912, subvendor=0x1462, subdevice=0x7968, revid=0x6
$ ./test32 0 0 2 0
test32: PCIOCGETCONF failed: Operation not permitted
$ sudo ./test32 0 0 2 0
test32: PCIOCGETCONF failed: Operation not permitted

$ cat test.c
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main(int argc, char **argv)
{
/* Based on drmParsePciDeviceInfo() from 
graphics/libdrm/files/patch-xf86drm.c */
struct pci_conf_io pc;
struct pci_match_conf patterns[1];
struct pci_conf results[1];

if (argc < 5) {
printf("usage: %s\n", argv[0]);
return 1;
}

int fd = open("/dev/pci", O_RDONLY, 0);
if (fd < 0)
err(1, "open(/dev/pci) failed");

bzero(&patterns, sizeof(patterns));
patterns[0].pc_sel.pc_domain = atoi(argv[1]);
patterns[0].pc_sel.pc_bus = atoi(argv[2]);
patterns[0].pc_sel.pc_dev = atoi(argv[3]);
patterns[0].pc_sel.pc_func = atoi(argv[4]);
patterns[0].flags = PCI_GETCONF_MATCH_DOMAIN | PCI_GETCONF_MATCH_BUS
  | PCI_GETCONF_MATCH_DEV | PCI_GETCONF_MATCH_FUNC;
bzero(&pc, sizeof(struct pci_conf_io));
pc.num_patterns = 1;
pc.pat_buf_len = sizeof(patterns);
pc.patterns = patterns;
pc.match_buf_len = sizeof(results);
pc.matches = results;

if (ioctl(fd, PCIOCGETCONF, &pc) || pc.status == PCI_GETCONF_ERROR) {
close(fd);
err(1, "PCIOCGETCONF failed");
}
close(fd);

printf("vendor=%#x, device=%#x, subvendor=%#x, subdevice=%#x, revid=%#x\n", 
   results[0].pc_vendor, results[0].pc_device, 
   results[0].pc_subvendor, results[0].pc_subdevice,
   results[0].pc_revid);

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: Panic on kern_event.c

2018-11-15 Thread Mark Johnston

On Thu, Nov 08, 2018 at 05:05:03PM +0100, Sylvain GALLIANO wrote:
> Hi,
> 
> I replaced
> << printf("XXX knote %p already in tailq  status:%x kq_count:%d  [%p %p]
> %u\n",kn,kn->kn_status,kq->kq_count,kn->kn_tqe.tqe_next,kn->kn_tqe.tqe_prev,__LINE__);
> by
> >> panic("XXX knote %p already in tailq  status:%x kq_count:%d  [%p %p]
> %u\n",kn,kn->kn_status,kq->kq_count,kn->kn_tqe.tqe_next,kn->kn_tqe.tqe_prev,__LINE__);
> 
> Here is the stack during panic:
> panic: XXX knote 0xf801e1c6ddc0 already in tailq  status:1 kq_count:2
> [0 0xf8000957a978]  2671
> 
> cpuid = 0
> time = 1541688832
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2c/frame
> 0xfe0412258fd0
> kdb_backtrace() at kdb_backtrace+0x53/frame 0xfe04122590a0
> vpanic() at vpanic+0x277/frame 0xfe0412259170
> doadump() at doadump/frame 0xfe04122591d0
> knote_enqueue() at knote_enqueue+0xf2/frame 0xfe0412259210
> kqueue_register() at kqueue_register+0xaed/frame 0xfe0412259340
> kqueue_kevent() at kqueue_kevent+0x13c/frame 0xfe04122595b0
> kern_kevent_fp() at kern_kevent_fp+0x66/frame 0xfe0412259610
> kern_kevent() at kern_kevent+0x17f/frame 0xfe0412259700
> kern_kevent_generic() at kern_kevent_generic+0xfe/frame 0xfe0412259780
> sys_kevent() at sys_kevent+0xaa/frame 0xfe0412259810
> syscallenter() at syscallenter+0x4e3/frame 0xfe04122598f0
> amd64_syscall() at amd64_syscall+0x1b/frame 0xfe04122599b0
> fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe04122599b0
> --- syscall (560, FreeBSD ELF64, sys_kevent), rip = 0x406e3bfa, rsp =
> 0x7fffdf7e9db8, rbp = 0x7fffdf7e9e00 ---
> KDB: enter: panic
> 
> 
> you can get kernel.debug + vmcore at:
> https://drive.google.com/drive/folders/1MbqJQm12-KOYDbb4-9uNRTnAdsNqLaIP?usp=sharing

Could you please give the following patch a try?

If possible, could you also ktrace one of the active syslog-ng processes
for some time, perhaps 15 seconds, and share the kdump?  I have been
trying to reproduce the problem without any luck.

diff --git a/sys/kern/kern_event.c b/sys/kern/kern_event.c
index d9c670e29d60..9ef7c53361bf 100644
--- a/sys/kern/kern_event.c
+++ b/sys/kern/kern_event.c
@@ -224,6 +224,7 @@ SYSCTL_UINT(_kern, OID_AUTO, kq_calloutmax, CTLFLAG_RW,
 #define KQ_LOCK(kq) do {   \
mtx_lock(&(kq)->kq_lock);   \
 } while (0)
+#defineKQ_LOCKPTR(kq)  (&(kq)->kq_lock)
 #define KQ_FLUX_WAKEUP(kq) do {
\
if (((kq)->kq_state & KQ_FLUXWAIT) == KQ_FLUXWAIT) {\
(kq)->kq_state &= ~KQ_FLUXWAIT; \
@@ -687,8 +688,11 @@ filt_timerexpire(void *knx)
struct kq_timer_cb_data *kc;
 
kn = knx;
+   KQ_OWNED(kn->kn_kq);
kn->kn_data++;
-   KNOTE_ACTIVATE(kn, 0);  /* XXX - handle locking */
+
+   if (!kn_in_flux(kn) || (kn->kn_status & KN_SCAN) != 0)
+   KNOTE_ACTIVATE(kn, 1);
 
if ((kn->kn_flags & EV_ONESHOT) != 0)
return;
@@ -753,7 +757,7 @@ filt_timerattach(struct knote *kn)
kn->kn_flags |= EV_CLEAR;   /* automatically set */
kn->kn_status &= ~KN_DETACHED;  /* knlist_add clears it */
kn->kn_ptr.p_v = kc = malloc(sizeof(*kc), M_KQUEUE, M_WAITOK);
-   callout_init(&kc->c, 1);
+   callout_init_mtx(&kc->c, KQ_LOCKPTR(kn->kn_kq), 0);
filt_timerstart(kn, to);
 
return (0);
@@ -772,8 +776,10 @@ filt_timerstart(struct knote *kn, sbintime_t to)
kc->next = to + sbinuptime();
kc->to = to;
}
+   KQ_LOCK(kn->kn_kq);
callout_reset_sbt_on(&kc->c, kc->next, 0, filt_timerexpire, kn,
PCPU_GET(cpuid), C_ABSOLUTE);
+   KQ_UNLOCK(kn->kn_kq);
 }
 
 static void
@@ -826,7 +832,6 @@ filt_timertouch(struct knote *kn, struct kevent *kev, 
u_long type)
KQ_LOCK(kq);
if (kn->kn_status & KN_QUEUED)
knote_dequeue(kn);
-
kn->kn_status &= ~KN_ACTIVE;
kn->kn_data = 0;
KQ_UNLOCK(kq);
@@ -1843,6 +1848,7 @@ kqueue_scan(struct kqueue *kq, int maxevents, struct 
kevent_copyops *k_ops,
}
 
TAILQ_INSERT_TAIL(&kq->kq_head, marker, kn_tqe);
+   marker->kn_status |= KN_QUEUED;
influx = 0;
while (count) {
KQ_OWNED(kq);
@@ -1861,8 +1867,10 @@ kqueue_scan(struct kqueue *kq, int maxevents, struct 
kevent_copyops *k_ops,
}
 
TAILQ_REMOVE(&kq->kq_head, kn, kn_tqe);
+   KASSERT((kn->kn_status & KN_QUEUED) != 0,
+   ("knote %p not queued", kn));
+   kn->kn_status &= ~KN_QUEUED;
if ((kn->kn_status & KN_DISABLED) == KN_DISABLED) {
-   kn->kn_status &= ~KN_QUEUED;

Re: UEFI GOP: screen goes blank during boot after loader is finished

2018-11-15 Thread Marcelo Araujo

Hi,

I have the same issue on FreeBSD-HEAD as host and with FreeBSD-HEAD as
guest.

Em sex, 16 de nov de 2018 às 03:10, Rebecca Cran via freebsd-virtualization
 escreveu:

> On Wednesday, 14 November 2018 19:56:56 MST Warner Losh wrote:
>
> > What is the ConOut evifar look like? We set serial when the UEFI env says
> > to do  so.
>
> Booting with:
>
> sudo bhyve -A -P -c 2 -H -m 4G -s 0:0,hostbridge -s 31:0,lpc -s 2,ahci-
> cd,FreeBSD-12.0-BETA4-amd64-disc1.iso -s
> 29,fbuf,tcp=0.0.0.0:5900,w=800,h=600,wait -l
> bootrom,/usr/local/share/uefi-
> firmware/BHYVE_UEFI.fd -u vm5
>
> dh in the shell shows:
>
> 7D: ConsoleOut SimpleTextOut GraphicsOutput(GraphicsOutput)
> PCIIO DevicePath(PciRoot (0x0)/Pci(0x1D,0x0))
>
> 84: StdErr ConsoleOut ConsoleIn SimpleTextOut SimpleTextInEx SimpleTextIn
> DevicePath(t(115200,8,N,1)/VenVt100Plus())
>
> 89: SimpleTextOut SimpleTextInEx SimpleTextIn
> DevicePath(Uart(115200,8,N,1)/
> VenPcAnsi())
>
> --
> Rebecca
>
>
> ___
> freebsd-virtualizat...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
> To unsubscribe, send any mail to "
> freebsd-virtualization-unsubscr...@freebsd.org"
>


-- 

-- 
Marcelo Araujo(__)ara...@freebsd.org
\\\'',)http://www.FreeBSD.org    \/  \ ^
Power To Server. .\. /_)
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

2018-11-15 Thread Rebecca Cran

On Wednesday, 14 November 2018 12:41:53 MST Stefan Ehmann wrote:
> On 11/14/18 5:41 AM, Conrad Meyer wrote:

> > Ok I'll go ahead and commit that too.
> 
> Applied to 12.0-BETA, Ryzen 7 2700 values are now in the 30-55C range.
> Looks reasonable.

Much better here, too:

dev.amdtemp.3.core0.sensor0: 38.1C
dev.amdtemp.3.sensor_offset: -27
dev.amdtemp.2.core0.sensor0: 39.0C
dev.amdtemp.2.sensor_offset: -27
dev.amdtemp.1.core0.sensor0: 37.5C
dev.amdtemp.1.sensor_offset: -27
dev.amdtemp.0.core0.sensor0: 40.1C
dev.amdtemp.0.sensor_offset: -27

Thanks!
Rebecca


___
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: UEFI GOP: screen goes blank during boot after loader is finished

2018-11-15 Thread Warner Losh

On Thu, Nov 15, 2018 at 12:10 PM Rebecca Cran  wrote:

> On Wednesday, 14 November 2018 19:56:56 MST Warner Losh wrote:
>
> > What is the ConOut evifar look like? We set serial when the UEFI env says
> > to do  so.
>
> Booting with:
>
> sudo bhyve -A -P -c 2 -H -m 4G -s 0:0,hostbridge -s 31:0,lpc -s 2,ahci-
> cd,FreeBSD-12.0-BETA4-amd64-disc1.iso -s
> 29,fbuf,tcp=0.0.0.0:5900,w=800,h=600,wait -l
> bootrom,/usr/local/share/uefi-
> firmware/BHYVE_UEFI.fd -u vm5
>
> dh in the shell shows:
>
> 7D: ConsoleOut SimpleTextOut GraphicsOutput(GraphicsOutput)
> PCIIO DevicePath(PciRoot (0x0)/Pci(0x1D,0x0))
>
> 84: StdErr ConsoleOut ConsoleIn SimpleTextOut SimpleTextInEx SimpleTextIn
> DevicePath(t(115200,8,N,1)/VenVt100Plus())
>
> 89: SimpleTextOut SimpleTextInEx SimpleTextIn
> DevicePath(Uart(115200,8,N,1)/
> VenPcAnsi())
>

If I read that right, then the ConOut variable first has the video device
listed, then the serial port (this wasn't the form I expected to see it in,
so I'm not sure thats the case). In either event, we should get console
output on both the serial and the video at least until the /etc/rc script
starts...

Warner
___
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: UEFI GOP: screen goes blank during boot after loader is finished

Re: UEFI GOP: screen goes blank during boot after loader is finished

Re: [regression] drm-stable-kmod doesn't work in i386 jail on amd64 host

Re: Panic on kern_event.c

Re: UEFI GOP: screen goes blank during boot after loader is finished

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

Re: UEFI GOP: screen goes blank during boot after loader is finished

7 matches

Site Navigation

Mail list logo

Footer information