On Mon, Jan 20, 2020 at 03:41:33PM -0800, Rob Newberry wrote:
> Below are patches -- one to "dosfs.c" to fix the overflow problem,
> one to "efiblock.c" to add the "deal with no disklabel" feature. I
> don't know the proper way to propose or advocate for these, but I'm
> sharing them here in the
> On Jan 20, 2020, at 3:44 PM, Christos Zoulas wrote:
>
> In article <20200120185023.gd28...@homeworld.netbsd.org>,
> Andrew Doran wrote:
>> Fix committed with sys/kern/kern_rwlock.c rev 1.62. I didn't see the
>> problem as I am running with LOCKDEBUG.
>>
>> Apologies for the disruption.
>
Updating src tree:
P src/distrib/sets/lists/comp/mi
P src/distrib/sets/lists/man/mi
P src/distrib/sets/lists/modules/mi
P src/doc/CHANGES
P src/doc/TODO.smpnet
P src/share/man/man4/Makefile
cvs update: `src/share/man/man4/fpa.4' is no longer in the repository
P src/share/man/man5/networks.5
P
Hi, everyone.
I've been playing with efiboot on Raspberry Pi. I've added the ability to load
a kernel, DTB file and RAM disk directly from an SD card that has a single FAT
partition and no disklabel. (This makes it a little easier to do some
development on my Mac and not need to worry about
Folks --
I'm planning to remove the "le at pci" attachment ... it has long since been
supplanted by the pcn(4) driver, which supports a lot more PCnet-PCI chips, and
also does direct DMA from memory rather than copying to/from a fixed buffer.
If you're using "le at pci", please stop and switch
На 2020-01-20 в 18:50, Andrew Doran написа:
> Fix committed with sys/kern/kern_rwlock.c rev 1.62. I didn't see the
> problem as I am running with LOCKDEBUG.
>
> Apologies for the disruption.
All good now, thanks.
> Andrew
Hi,
Thanks for your quick fix.
It works fine for my laptop now.
On January 21, 2020 3:50:23 AM GMT+09:00, Andrew Doran wrote:
>Fix committed with sys/kern/kern_rwlock.c rev 1.62. I didn't see the
>problem as I am running with LOCKDEBUG.
>
>Apologies for the disruption.
>
>Andrew
--
Ryo
Fix committed with sys/kern/kern_rwlock.c rev 1.62. I didn't see the
problem as I am running with LOCKDEBUG.
Apologies for the disruption.
Andrew
pr...@cam.ac.uk (Patrick Welche) writes:
>2 rather different -current/amd64 computers happily run with Friday's code,
>but freeze with an hour ago's Jan 20 09:17 GMT code, e.g.:
>[ 5.390862] boot device: wd0
>[ 5.390862] root on wd0a dumps on wd0b
>[ 154.958077] fatal breakpoint trap
I believe I have the same issue on a Virtualbox VM, although the
system gets stuck after "root on dk0 dumps on dk1", no breakpoints or
anything else. 9.99.38 kernel boots just fine.
On Mon, Jan 20, 2020 at 2:29 PM Patrick Welche wrote:
>
> 2 rather different -current/amd64 computers happily run
On Mon, 20 Jan 2020 at 12:29, Patrick Welche wrote:
>
> 2 rather different -current/amd64 computers happily run with Friday's code,
> but freeze with an hour ago's Jan 20 09:17 GMT code, e.g.:
>
> [ 5.390862] boot device: wd0
> [ 5.390862] root on wd0a dumps on wd0b
> [ 154.958077]
2 rather different -current/amd64 computers happily run with Friday's code,
but freeze with an hour ago's Jan 20 09:17 GMT code, e.g.:
[ 5.390862] boot device: wd0
[ 5.390862] root on wd0a dumps on wd0b
[ 154.958077] fatal breakpoint trap in supervisor mode
The fatal breakpoint
Hi,
With sources updated overnight my AMD64 9.99.39 laptop stops the boot
process after reporting the root device (dk1) before reporting the
swap device (dk2). I can't break into debugger at this moment yet, but
if I touch the power button it stops gracefully, so it is not
completely dead. It
Hi, sorry for my bad English... This problem is SOLVED in 9.0-RC1 in uefi mode:X -configuremv /root/xorg.conf.new /etc/X11/xorg.confnano /etc/X11/xorg.confand replace Driver "intel" to "modesetting" or "wsfb". Thanks to All! -- Dmitry15:52, 25 декабря 2019 г., Dmitry Postolov :These settings did
Hi All!
On 11/4/19 8:00 PM, Martin Husemann wrote:
On Mon, Nov 04, 2019 at 08:52:31PM +0200, Yorick Hardy wrote:
This might be more pango fallout:
https://blogs.gnome.org/mclasen/2019/05/25/pango-future-directions/
"Using Harfbuzz for font loading means that we will lose support
for
15 matches
Mail list logo
