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