I wrote:
> I'll test a kernel without that "else if" block tonight.
After discussion on IRC, what I'll try first of all is to change
callout_reset(>sc_delay, 1, ukbd_delayed_decode, sc);
to
callout_reset(>sc_delay, 0, ukbd_delayed_decode, sc);
inside the "else if" block. We only need
Brian Buhrow writes:
> hello. My recollection may be slightly wrong here since I'm
> still running NetBSD-5 in most cases, but my understanding is that
> ehci(4) connected devices are all USB-2.0 and for slower devices, the
> uhci(4) or ohci(4) hub drivers provide service.
Ah, it's not
And with even more recent sources (updated on 2020-03-04 at
02:52:55 UTC), I'm getting an error even earlier in the build:
dependall ===> external/bsd/pam-u2f/bin/pamu2fcfg
#create pamu2fcfg/explicit_bzero.d
CC=/build/netbsd-compat/tools/x86_64/sparc/bin/sparc--netbsdelf-gcc
Updating src tree:
U src/external/bsd/pam-u2f/bin/pamu2fcfg/Makefile
U src/external/bsd/pam-u2f/bin/pamu2fcfg/cmdline.c
U src/external/bsd/pam-u2f/bin/pamu2fcfg/cmdline.h
P src/external/cddl/osnet/sys/kern/printf.c
P src/external/mit/libcbor/lib/Makefile
P src/lib/Makefile
P
Andrew Doran wrote:
>On Tue, Mar 03, 2020 at 10:03:38PM +, Robert Swindells wrote:
>>
>> I just got this:
>>
>> panic: pr_phinpage_check: [vcachepl] item 0x54d19880 not part of pool
>> cpu0: Begin traceback...
>> trace fp ffc0405efc90
>> fp ffc0405efcb0 vpanic() at
On Tue, Mar 03, 2020 at 10:03:38PM +, Robert Swindells wrote:
>
> I just got this:
>
> panic: pr_phinpage_check: [vcachepl] item 0x54d19880 not part of pool
> cpu0: Begin traceback...
> trace fp ffc0405efc90
> fp ffc0405efcb0 vpanic() at ffc000240880 netbsd:vpanic+0x160
>
I just got this:
panic: pr_phinpage_check: [vcachepl] item 0x54d19880 not part of pool
cpu0: Begin traceback...
trace fp ffc0405efc90
fp ffc0405efcb0 vpanic() at ffc000240880 netbsd:vpanic+0x160
fp ffc0405efd20 panic() at ffc000240974 netbsd:panic+0x44
fp
Hi.
On Tue, Mar 03, 2020 at 08:25:25PM +1100, matthew green wrote:
> here are a few build benchmark tests on an amd ryzen 3950x
> system, to see the cumulative effect of the various fixes we've
> seen since netbsd-9, for this 16 core/ 32 thread CPU, 64GB of
> ram, separate nvme ssd for src &
hello. My recollection may be slightly wrong here since I'm still
running NetBSD-5 in most cases, but my understanding is that ehci(4)
connected devices are all USB-2.0 and for slower devices, the uhci(4) or
ohci(4) hub drivers provide service. Do these bar code scanners attach as
w...@netbsd.org (Thomas Klausner) writes:
>umass0: using SCSI over Bulk-Only
>scsibus0 at umass0: 2 targets, 1 lun per target
>sd0 at scsibus0 target 0 lun 0: disk fixed
>sd0(umass0:0:0:0): Check Condition on CDB: 0x00 00 00 00 00 00
>SENSE KEY: Not Ready
> ASC/ASCQ: Logical Unit Is
While we're talking about annoyances (sorry for hijacking the thread)
I often see something like:
umass0 at uhub4 port 3 configuration 1 interface 0
umass0: Samsung (0x4e8) D3 Station (0x6125), rev 3.00/2.02, addr 1
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, 1 lun per target
matthew green writes:
Thanks for the very interstesting data.
> below has a full summary, but the highlights:
>
> - DIAGNOSTIC costs 3-8%
This seems higher than it ought to be. I don't doubt your measurements;
I mean that probably things are being done under DIAGNOSTIC that aren't
really
On Tue, Mar 03, 2020 at 12:57:28PM +, Robert Swindells wrote:
> I don't have an answer to the hang but had been meaning to submit a
> patch for review that might help with tracking it down.
Please commit it!
Martin
In article <20200303122717.gb...@mail.duskware.de>,
Martin Husemann wrote:
>On Tue, Mar 03, 2020 at 01:29:39PM +0200, Andreas Gustafsson wrote:
>> Would it be too much to ask that imports of entire new subsystems like
>> this be at least build tested with "build.sh release"?
>
>The lossage in
Thomas Klausner wrote:
>I'm doing my backups to USB disks. Last month this worked fine, with
>9.99.48/amd64 the backup process (unison) hung twice, only
>force-reboot got me out of the first one.
>
>The process is hung in ps "D+". top says "uvn_fp".
I don't have an answer to the hang but had
Hi!
I'm doing my backups to USB disks. Last month this worked fine, with
9.99.48/amd64 the backup process (unison) hung twice, only
force-reboot got me out of the first one.
The process is hung in ps "D+". top says "uvn_fp".
Connecting to the process with gdb does not finish.
There is no big
On Tue, Mar 03, 2020 at 01:29:39PM +0200, Andreas Gustafsson wrote:
> Would it be too much to ask that imports of entire new subsystems like
> this be at least build tested with "build.sh release"?
The lossage in this case seems to depend on -j values and whether you do
incremental builds, so not
NetBSD Test Fixture wrote:
> *** [cleandir-pamu2fcfg] Error code 2
> nbmake[7]: stopped in
> /tmp/bracket/build/2020.03.03.00.47.33-i386/src/external/bsd/pam-u2f/bin
The build is still broken as of source date 2020.03.03.08.56.05:
hi folks.
here are a few build benchmark tests on an amd ryzen 3950x
system, to see the cumulative effect of the various fixes we've
seen since netbsd-9, for this 16 core/ 32 thread CPU, 64GB of
ram, separate nvme ssd for src & obj.
below has a full summary, but the highlights:
- building
This is a problem that I believe has been present for a while, but has
recently (since the new year) become worse:
I have, for a long time, been using a bar code scanner to register books
on LibraryThing, and I've been noticing that my amd64 home workstation
has had a tendency to drop a digit
20 matches
Mail list logo
