Updating src tree:
P src/distrib/sets/lists/comp/mi
P src/sys/arch/aarch64/aarch64/fault.c
P src/sys/dev/audio/audio.c
P src/sys/dev/audio/audiodef.h
P src/sys/dev/audio/audiovar.h
P src/tests/lib/libc/sys/t_ptrace_wait.c
Updating xsrc tree:
Killing core files:
Updating file list:
Martin Husemann transcribed 430 bytes:
> On Sat, Apr 27, 2019 at 04:18:20PM +, n...@n0.is wrote:
> > It's an T440s, so one module can be exchanged, the other is soldered
> > to the board.
> >
> > I can give exchanging the replacable one a try.
>
> I have had good experience with running
There is an ancient BSD ioctl(2) which might cover this case: FIONREAD. The
point of it back in the day was to be able to know just how much data could be
read from a file descriptor (e.g., from TTY input buffers) without blocking.
Erik Fair
On Mon, Jun 10, 2019 at 03:42:10PM +0100, Patrick Welche wrote:
> It doesn't seem to help. Another difference is that consdev com0 works
> for the biosboot, but not for efiboot, which means I can't be sure
> where nouveau gets stuck.
Maybe EFI doesn't initialize com0. With e.g.
consdev
On Wed, Jun 05, 2019 at 09:55:08AM -, Michael van Elst wrote:
> pr...@cam.ac.uk (Patrick Welche) writes:
>
> >This has changed! The above is still true with EFI, but with BIOS booting,
> >nouveau attaches successfully, and I can run xdm+twm!
>
> What happens in EFI mode when, before booting
The NetBSD-current/i386 build is working again.
The following commits were made between the last failed build and the
successful build:
2019.06.10.10.28.41 mrg src/distrib/sets/lists/comp/mi,v 1.2277
Log files can be found at:
On Mon, Jun 10, 2019 at 05:38:56PM +0900, Masanobu SAITOH wrote:
> On 2019/06/10 17:17, Thomas Klausner wrote:
> > I tried some more stuff.
> >
> > Enabling the NVME_QUIRK_DELAY_B4_CHK_RDY quirk didn't help, it paniced
> > during boot. However, forcing nvme_pci_force_intx to 1 makes it boot
> >
I tried some more stuff.
Enabling the NVME_QUIRK_DELAY_B4_CHK_RDY quirk didn't help, it paniced
during boot. However, forcing nvme_pci_force_intx to 1 makes it boot
successfully!
Should this variable default to 1, or how do we improve the situation
in general?
Cheers,
Thomas
On 2019/06/10 17:17, Thomas Klausner wrote:
> I tried some more stuff.
>
> Enabling the NVME_QUIRK_DELAY_B4_CHK_RDY quirk didn't help, it paniced
> during boot. However, forcing nvme_pci_force_intx to 1 makes it boot
> successfully!
Please show the following information:
- "FULL" dmesg
