Our 8.2_STABLE (amd64) system paniced the other day in what appears to be an
IPv6-related issue.
We had a tcpdump running at the time, which may or may not be related (I
suspect it, though, as we had some years of uptime on that machine before)
Our own research led to
_ioctl() at netbsd:sys_ioctl+0x11a
| syscall() at netbsd:syscall+0x1ec
| --- syscall (number 54) ---
| 7a73c9eff13a:
| db{2}>
Any idea what's going on?
Cheers
Timo Buhrmester
> A "monotonically increasing" function would guarantee a results that is
> strictly greater than any previous results.
AFAIK "monotonically increasing" and "non-decreasing" are synonyms which both
allow for constant sections, without which it could be called "strictly
increasing".
> I do get some audible artifacts with this patch
It was pointed out to me on IRC that this is not caused by
your patch, so, never mind.
> The audio device is cloned and their is no longer a limitation of one device
> per process and file descriptors may be shared among processes.
Awesome! Cloning works, the volume-going-down-with-each-open(2) problem
is gone.
I do get some audible artifacts with this patch, though, at least for
> It works so far [...]
Forgot to mention, the pc beeper does not work. Is this device correct?
crw-rw-rw- 1 root wheel 156, 0 May 16 02:19 /dev/speaker
Is it still supposed to use the real integrated beeper, or would it
synthesize a beep through the sound card?
> /usr/src/sys/dev/isa/files.isa:435: redefinition of `spkr'
It builds when removing the pertinent line from that file.
It works so far, apart from what appears to be a logarithmic decrease
in global volume with each concurrent opening of the device. I assume
this is done to avoid clipping when
I'm getting this when trying to build with your vaudio-kern patches applied:
$ ./build.sh -O /usr/obj.i386 -j3 -U -u kernel=GENERIC
===> build.sh command:./build.sh -O /usr/obj.i386 -j3 -U -u kernel=GENERIC
===> build.sh started:Mon May 16 01:24:25 CEST 2016
===> NetBSD version:
> I believe that the vaudio approach is better and wanted to start a discussion
> about in kernel-mixing and hopefully which approach (if any) should be
> included in NetBSD in future.
A third option would be taking OpenBSD's sndiod (which we have in
pkgsrc/wip); it seems rather sane and it's
On Fri, Mar 11, 2016 at 08:21:04AM +, Emmanuel Dreyfus wrote:
> On Fri, Mar 11, 2016 at 07:37:01AM +0100, Timo Buhrmester wrote:
> > It just completed one entire dump this way with no crash.
> > That hadn't happened in 6 days. Hmm.
>
> My ex
> > I use the built-in snapshot capability of dump(8), with the -X option:
> >
> > dump -0au -h 0 -X -f- ${fs} | gzip -9 > $outfile
> Thanks, I wasn't aware of that. I'll see if changes anything.
It just completed one entire dump this way with no crash.
That hadn't happened in 6 days.
> Perhaps you can get it to provide a backtrace rather than just simply
> rebooting?
I'd love to, but how? The machine is set to drop into ddb on panic, but
doesn't, or this isn't a panic.
> I use the built-in snapshot capability of dump(8), with the -X option:
>
> dump -0au -h 0 -X -f-
My 7-stable/amd64 server crashes nearly every night while my backup
routine is in progress. There's no backtrace and no crash dump is saved,
but the console reads:
> ohci1: 1 scheduling overruns
> ohci1: WARNING: addr 0x01cf not found
> ohci1: WARNING: addr 0x012c not found
> ohci1:
For a while now, I'm getting the occasional panic which I can't directly
reproduce, but it seems to correlate with long and/or memory- and/or
video-intense firefox sessions.
This is a recent -current (7.99.20 on amd64, although the problem exists as of
at least 7.99.10, likely earlier too), my
I've been offering the attached patch to try to debug the source of
the problem before the symptom you described happens. I haven't
gotten any diagnostics back from anyone yet. If you can, please try
it out and let me know.
I believe we're already discussing this on IRC, but for the record,
duplication of effort)
Cheers,
Timo Buhrmester
I'll keep digging.
The problem is that KGDB isn't prepared to deal with the non-blocking serial
port reads that matt's commit introduced in 2013 (am I really the first one to
try this on bare metal since then?)
Where the read function `com_common_getc` used to block, it will now return -1,
There is no delay between ``kgdb waiting...'' and ``fatal breakpoint trap
in supervisor mode''.
Looks like that behavior was introduced by the following commit
to src/sys/arch/i386/i386/trap.c:
revision 1.239
date: 2008-05-30 13:38:21 +0300;
information I missed that would be useful to
provide?
Timo Buhrmester
19 matches
Mail list logo
