Hello. I agree with Mouse, except that I also think it would be very
helpful and useful to have a serial console on USB only devices. I wonder
if we could make the console a virtual device which is attached dynamically
to a USB serial port if and when available. that would let the
Updating src tree:
P src/share/man/man4/speaker.4
P src/sys/arch/arm/sunxi/sunxi_nand.c
P src/sys/arch/sparc64/dev/ffb.c
P src/sys/arch/sparc64/sparc64/autoconf.c
P src/sys/arch/x86/x86/fpu.c
P src/sys/dev/pci/ciss_pci.c
P src/sys/dev/pci/machfb.c
P src/sys/dev/pci/radeonfb.c
P
> That said, what would it take to wire the NetBSD console to a USB
> serial adapter?
"Too much". USB is horrible from this persective; you need quite a lot
of infrastructure to do, well, pretty much anything over USB. Take a
look at the code sometime. In the particular case of the console,
> Date: Sun, 5 Jul 2020 11:45:48 +0100
> From: Chavdar Ivanov
>
> panic: fpudna from userland, ip 0x7c16e87b95ca, trapframe 0xce01527ec000
> cpu0: Begin traceback...
> vpanic() at netbsd:vpanic+0x152
> snprintf() at netbsd:snprintf
> fpu_set_default_cw() at netbsd:fpu_set_default_cw
> cpu0:
So, in my ongoing NetBSD on a MacBook saga
NetBSD-7.2 boots fine from USB on the MacBook Pro (MacBook7,1) (with the
help of rEFIT on a second USB stick).
NetBSD-8.2 and newer, including the most recent -current, hangs during
boot and the kernel messages appear to have torn video:
USB storage device transfers freeze when usbdevs is run: hardware bug
or software bug?
While I was doing a "gzcat < *.gz > /dev/rsd2d", where sd2 was a USB
memory stick, I happened to run "usbdevs -dv" and the writes to the USB
device froze, and indeed the writing process was stuck in the kernel
On 05.07.2020 19:42, Robert Elz wrote:
> Date:Tue, 30 Jun 2020 13:43:00 +0200
> From:Kamil Rytarowski
> Message-ID:
>
> I had been ignoring this discussion, but on cleaning up some
> unread list e-mail, I saw this nonsense, and this is just going too far.
>
> |
On Mon, Jul 06, 2020 at 12:42:55AM +0700, Robert Elz wrote:
> Actually, that one is a possible solution. dlclose() is not required
> to do anything at all. While having it never do anything isn't what
> we'd want, having it do nothing if there is a pending atexit function
> from the dynamic
Date:Tue, 30 Jun 2020 13:43:00 +0200
From:Kamil Rytarowski
Message-ID:
I had been ignoring this discussion, but on cleaning up some
unread list e-mail, I saw this nonsense, and this is just going too far.
| This is an extension and extensions are allowed.
That's
Thank you for the detailed response (I can't claim to understand
completely, of course.). A saved kernel from 9.99.68 still lets me
work with the machine as before; I updated it yesterday and got
another - perhaps identical - panic when downloading mail with
Thunderbird
panic: fpudna from
10 matches
Mail list logo
