pkgsrc build but not 100% sure of that.
While flushing dirty blocks on a device node new dirty blocks appeared.
In theory this should not happen -- but the vflush will retry anyway.
If you see it one or two times there is no real problem.
--
J. Hannken-Illjes - hann...@mailbox.org
Oops, forgot to "cvs update" -- all builds are working for me.
Sorry for the noise ...
--
J. Hannken-Illjes - hann...@mailbox.org
> On 31. Mar 2024, at 12:14, J. Hannken-Illjes wrote:
>
>> On 31. Mar 2024, at 11:23, Ryo ONODERA wrote:
>>
>> chris...@a
> On 31. Mar 2024, at 11:23, Ryo ONODERA wrote:
>
> chris...@astron.com (Christos Zoulas) writes:
>
>> In article <4b5a66e1-7a3e-48ce-9ace-f9249e75f...@mailbox.org>,
>> J. Hannken-Illjes wrote:
>>> I also added an abort() when _dwarf_get_reloc_size(
number of func types = 65411
and running the merge with CTFMERGE_DEBUG_LEVEL=2 I get
ERROR: nbctfmerge: Second pass for 5978 ((anon)) == 13434
--
J. Hannken-Illjes - hann...@mailbox.org
> On 30. Mar 2024, at 15:23, Christos Zoulas wrote:
>
> I don't think that'
degC
> cpu0 ccd1 temperature:37.500 degc
> #
The string originates from sys/arch/x86/pci/amdzentemp.c line 471.
In this context CCD is a synonym for Core Complex Die.
--
J. Hannken-Illjes - hann...@mailbox.org
> On 23. Dec 2023, at 16:17, xuser wrote:
>
> Does any one know how to have two ip addresses on one interface?
ifconfig IF inet ADDR alias
--
J. Hannken-Illjes - hann...@mailbox.org
+0x184
> [ 6216.0201020] bdev_strategy() at netbsd:bdev_strategy+0x81
> [ 6216.0201020] fss_bs_thread() at netbsd:fss_bs_thread+0x32c
> [ 6216.0201020] cpu0: End traceback...
>
> [ 6216.0201020] dumping to dev 168,1 (offset=8, size=1048576):
> [ 6216.0201020] dump device bad
Could yo
/mnt/fs3
> /sbin/dump -0af - /mnt/fs3 | /usr/bin/bzip2 >
> /mnt/fs4/backups/current/home.dump.bz2
There is no need to mount the snapshot, the simplest way to dump is:
/sbin/dump -0af - -x /var/tmp /home | ...
Dump will take and release the snapshot for you, see "man dump&qu
> group "external" on $ext_if {
>pass stateful out final all
>
>ruleset "blocklistd"
>
> ...
Looks like your ruleset "blocklistd" never fires as the rule above is "final
all".
--
J. Hannken-Illjes - hann...@mailbox.org
signature.asc
Description: Message signed with OpenPGP
witch (op) {
... and Syzcaller (https://syzkaller.appspot.com/netbsd) has a
bunch of new tcp related crashes starting ~2 days before ...
--
J. Hannken-Illjes - hann...@mailbox.org
signature.asc
Description: Message signed with OpenPGP
gt; | & Network Engineer | | pgoyett...@gmail.com |
> +--------+--+--+
--
J. Hannken-Illjes - hann...@mailbox.org
signature.asc
Description: Message signed with OpenPGP
> ```
>
> Thread view:
>
>
> ```
> PID LID USERNAME PRI STATE TIME WCPUCPU NAME COMMAND
>0 173 root 126 CPU/1 96:57 98.93% 98.93% pgdaemon [system]
> ```
Looks a lot like kern/55707: ZFS seems to trigger a lot of xcalls
Last action propo
> On 29. May 2022, at 23:57, Manuel Bouyer wrote:
>
> On Sun, May 29, 2022 at 01:18:16PM +0200, J. Hannken-Illjes wrote:
>>> On 29. May 2022, at 08:30, Michael van Elst wrote:
>>>
>>> bou...@antioche.eu.org (Manuel Bouyer) writes:
>>>
>>&
vdevgone(bmaj, mn, mn, VBLK);
1771 if (mn != myminor) /* XXX avoid to kill own vnode */
1772 vdevgone(cmaj, mn, mn, VCHR);
1773 }
The "skip myself" on lines 1771/1772 is responsible for this behaviour.
--
J. Hannken-Illjes - hann...@mailbox.org
signature.asc
Description: Message signed with OpenPGP
> On 27. May 2022, at 16:24, Manuel Bouyer wrote:
>
> On Fri, May 27, 2022 at 02:52:55PM +0200, J. Hannken-Illjes wrote:
>>> On 27. May 2022, at 14:41, Matthias Petermann wrote:
>>>
>>> Hello Jürgen,
>>>
>>> Am 27.05.2022 um 14:14 schrieb
> On 27. May 2022, at 14:41, Matthias Petermann wrote:
>
> Hello Jürgen,
>
> Am 27.05.2022 um 14:14 schrieb J. Hannken-Illjes:
>> Stack trace of thread vnconfig (1239) and from ddb "call fstrans_dump"
>> should give even more details.
>
> here is th
e VM. Anyway, Once I try to
> "xl console" I did only get a fragment:
>
> ```
> ganymed$ doas xl console net
> [ 1.000] cpu_rng: rdrand
> [ 1.000] entropy: ready
> [ 1.000] Copyright (c) 1996, 1997, 1998, 1999,
> ```
>
> At the "1999," the Dom0 became frozen, again.
>
> Kind regards
> Matthias
>
Stack trace of thread vnconfig (1239) and from ddb "call fstrans_dump"
should give even more details.
--
J. Hannken-Illjes - hann...@mailbox.org
signature.asc
Description: Message signed with OpenPGP
> On 23. Apr 2022, at 14:45, Takahiro Kambe wrote:
>
> Hi,
>
> In message <029c86d6-e0d2-4c98-8798-4bdc39ba0...@mailbox.org>
> on Sat, 23 Apr 2022 10:22:13 +0200,
> "J. Hannken-Illjes" wrote:
>>> On 23. Apr 2022, at 10:15, J. Hannken-
> On 23. Apr 2022, at 10:15, J. Hannken-Illjes wrote:
> Please try the attached diff (with mount option "discard").
... and remove the "#define TRIMDEBUG" from the top of ffs_alloc.c first ...
--
J. Hannken-Illjes - hann...@mailbox.org
signature.asc
Description: Message signed with OpenPGP
> On 23. Apr 2022, at 05:17, Takahiro Kambe wrote:
>
> Hi,
>
> In message <15bebcc1-4756-46ad-a424-e5232065b...@mailbox.org>
> on Fri, 22 Apr 2022 19:39:35 +0200,
> "J. Hannken-Illjes" wrote:
>>> #5 0x80e69314 in VOP_FD
> On 22. Apr 2022, at 16:25, Takahiro Kambe wrote:
>
> Hi,
>
> In message
> on Fri, 22 Apr 2022 09:44:48 +0200,
> "J. Hannken-Illjes" wrote:
>>>> Thanks - I can confirm that a kernel from yesterday doesn't have the
>>>>
/spec_vnops.c", line 1252
> cpu3: Begin traceback...
> vpanic() at netbsd:vpanic+0x183
> kern_assert() at netbsd:kern_assert+0x4b
> spec_fdiscard() at netbsd:spec_fdiscard+0xaa
> VOP_FDISCARD() at netbsd:VOP_FDISCARD+0x3d
> ffs_discardcb() at netbsd:ffs_discardcb+0x2e
> workqueue_worke
> On 21. Apr 2022, at 00:36, 6b...@6bone.informatik.uni-leipzig.de wrote:
>
> On Wed, 20 Apr 2022, J. Hannken-Illjes wrote:
>
>> Date: Wed, 20 Apr 2022 22:19:30 +0200
>> From: J. Hannken-Illjes
>> To: 6b...@6bone.informatik.uni-leipzig.de
>> Cc: cur
> On 20. Apr 2022, at 22:10, 6b...@6bone.informatik.uni-leipzig.de wrote:
>
> On Tue, 19 Apr 2022, J. Hannken-Illjes wrote:
>
>> Date: Tue, 19 Apr 2022 11:07:48 +0200
>> From: J. Hannken-Illjes
>> To: 6b...@6bone.informatik.uni-leipzig.de
>> Cc: cur
> On 19. Apr 2022, at 08:38, 6b...@6bone.informatik.uni-leipzig.de wrote:
>
> On Thu, 14 Apr 2022, J. Hannken-Illjes wrote:
>
>> Date: Thu, 14 Apr 2022 13:09:02 +0200
>> From: J. Hannken-Illjes
>> To: 6b...@6bone.informatik.uni-leipzig.de
>> Cc: cur
n_lock(vp, LK_EXCLUSIVE | LK_RETRY);
> VOP_CLOSE(vp, oflags, kauth_cred_get());
> - vrele(vp);
> + vput(vp);
> return NULL;
> }
Already committed by Taylor R Campbell as sequencer.c Rev. 1.79
on 2022/04/16 11:13:10.
--
J. Hannken-Illjes - hann...@mailbox.org
signature.asc
Description: Message signed with OpenPGP
attached diff should help, since 2012-01-30
group quota got enabled on the user quota file.
As a workaround you could try to name the quota files in /etc/fstab
like "groupquota=XXX/quota.group".
>
> Maybe someone can fix the problem.
>
>
> Thank you for your efforts
>
>
> Regards
> Uwe
--
J. Hannken-Illjes - hann...@mailbox.org
quota_oldfiles.c.diff
Description: Binary data
signature.asc
Description: Message signed with OpenPGP
/current/obj/sparc/sys/arch/sparc/compile/DAVID
>
> ERROR: Failed to make debuginstall in
> "/r0/build/current/obj/sparc/sys/arch/sparc/compile/DAVID"
> *** BUILD ABORTED ***
For me the attached diff works. It skips the install
outside ${NETBSDSRCDIR}.
--
J. Hannken-Illjes - hann...@mailbox.org
Makefile.kern.inc.diff
Description: Binary data
signature.asc
Description: Message signed with OpenPGP
ox/nb9-i386-trunk/data 124G 158G 79.2G
> /sandbox/nb9-i386-trunk/data
> ...
Using the attached script I see no problems. What are you
doing between the "mount -t tmpfs", "mount -t null" and this "ls"?
--
J. Hannken-Illjes - hann...@eis.cs.tu-
> On 1. Jul 2021, at 21:04, David Holland wrote:
>
> On Thu, Jul 01, 2021 at 07:54:33PM +0200, J. Hannken-Illjes wrote:
>> lookup_fastforward -> lookup_parsepath -> VOP_PARSEPATH -> ... ->
>> fstrans_start
>
> Bleh. I had a feeling we were going to en
lock is missing. So either
- make sure the vnode is locked so fstrans_start will no loner block.
or
- add FSTRANS=NO to vop_parsepath, file kern/vnode_if.src and allow unlocked
vnodes:
vop_parsepath {
+ FSTRANS=NO
IN struct vnode *dvp;
David?
--
J. Hannken-Illjes - hann..
> On 6. Jun 2021, at 10:10, Patrick Welche wrote:
>
> On Sat, Jun 05, 2021 at 06:45:24PM +0200, J. Hannken-Illjes wrote:
>> Patrick,
>>
>> please try the attached diff so the "spcl.c_addr" test
>> no longer runs off the spcl record.
>>
&
Patrick,
please try the attached diff so the "spcl.c_addr" test
no longer runs off the spcl record.
"blks" is used for multi-tape checkpointing and examining
TS_INODE/TS_ADDR records should be sufficient as the are
the only records that support holes in data.
--
J. H
gt;
> c_type==6 = TS_CLRI map of inodes deleted since last dump
>
> (a bit odd:
> (gdb) print needswap
> $11 = 0
> (gdb) print iswap32(u_spcl.s_spcl.c_count)
> $10 = 1505558528
> )
>
> Still puzzled...
This trace makes no sense, bitmaps (CLRI and BITS) don't have holes
and therefore ignore the "c_addr" array. I have no idea how dumping
a bitmap ends in the hole processing of flushtape().
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig
signature.asc
Description: Message signed with OpenPGP
ce back in the PR is correct, it makes it
> almost totally though the mkdir call and crashes in the log create step
> after the directory node is created. I am trying not to speculate too
> much here, but the code may fail to handle the group in the exports
> line.
>
>
>
>
>
>
> --
> Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig
zfs_context.h.diff
Description: Binary data
signature.asc
Description: Message signed with OpenPGP
motional reaction to everything that is said to you.
> True power is sitting back and observing everything with logic.
> If words control you that means everyone else can control you.
> Breathe and allow things to pass.
>
> --- Bruce Lee
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig
signature.asc
Description: Message signed with OpenPGP
/rump/include/rump/rump.h,v 1.72
This commit seems to be the cause ...
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig
signature.asc
Description: Message signed with OpenPGP
zfs_mount+0xcf
> VFS_MOUNT() at VFS_MOUNT+0x4d
> mount_domount() at mount_domount+0xdf
> do_sys_mount() at do_sys_mount+0x580
> sys___mount50() at sys___mount50+0x33
> syscall() at syscall+0x157
> --- syscall (number 410) ---
> 7d6364687aba:
For some reason locking the directory we w
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig
> On 22. Oct 2019, at 07:26, Martin Husemann wrote:
>
> The current state silently breaks existing valid setups ("valid" of course
> in my view, as I personally ran into one that I created myself).
It br
e" set overrides the symlink "/etc/unbound"
with a directory and therefore unbound fails to start.
Is this a bug in "tar" or is there a switch to get the old behaviour back?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
#! /bin/sh
uname
Any chance we can build x86 kernels without DIAGNOSTIC again?
Does it need a PR?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig
> On 15. Oct 2019, at 17:56, John D. Baker wrote:
>
> On Tue, 15 Oct 2019, Ryo ONODERA wrote:
>
>> If the problem is the compi
ack...
> Undefined instruction 0xe7ff in kernel at 0x80023534 (LR 0x80265358 SP
> 0x9ac
> 8dd58)
> Stopped in pid 621.1 (getty) at netbsd:cpu_Debugger:und 0xe7ff
> db{1}>
>
> This is a -current kernel from sources updated about an hour ago,
> userland is a
(dvp != udvp && (dvp->v_type == VDIR) &&
(mp = dvp->v_mountedhere)) {
if (vfs_busy(mp))
continue;
vput(dvp);
which looks wrong. Please show your mounted file systems.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig
signature.asc
Description: Message signed with OpenPGP
moving files, which will trigger the panic.
>
> Is it really motivated with that panic? The system is running without issues
> on that same file system and NetBSD 7.
You could backport this change to -7 fsck_ffs, the patch (attached) is small.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs
ly short sysmlinks.
>
> Johnny
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email: b...@softjar.se || Reading murder books
> pdp is alive! || tryin' to stay hip" - B. Idol
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
he same
> way. This i plain ffs, no wapbl.
>
> Any idea ?
Please enter DDB and "call fstrans_dump(0)" to see which thread blocks
the transition (it will have "... shared N ..." with N > 0).
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
Manuel,
does it help to run clri from fsdb?
We definitely need an assertion of "blocks == 0" on inode deletion.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
> On 15. Jan 2018, at 09:11, Manuel Bouyer wrote:
>
> Hello,
> I get a recuring pa
> On 19. Aug 2017, at 14:20, Christos Zoulas wrote:
>
> On Aug 19, 1:04pm, hann...@eis.cs.tu-bs.de ("J. Hannken-Illjes") wrote:
> -- Subject: Re: Fixing swap1_stop
>
> | A long time ago forced unmounts tried to change open block device nodes
> | to anonymous
d unmounts tried to change open block device nodes
to anonymous (not attached to a file system) nodes. This was racy and
has been removed.
With the recent changes to the VFS subsystem it should be possible to
bring this behaviour back and instead of destroying open device nodes
a forced unmount wo
spec_fsync(v);
> + if (error)
>
> --
> |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
> |\ / jdbaker[snail]mylinuxisp[flyspeck]comOpenBSD FreeBSD
> | X No HTML/proprietary data in email. BSD just sits there and works!
> |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
>
Committed with slightly modification -- thanks!
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
> On 19 Dec 2016, at 14:31, Joerg Sonnenberger wrote:
>
> On Sun, Dec 18, 2016 at 09:55:58PM +0100, J. Hannken-Illjes wrote:
>>
>>> On 18 Dec 2016, at 21:49, Joerg Sonnenberger wrote:
>>>
>>> On Sun, Dec 18, 2016 at 09:45:00PM +0100, Joerg Sonnenber
on as it tries to
>> write to binary packages. This worked fine with a kernel from the ~Dec 8
>> sources.
>
> Comparing the ident output makes me suspect the vnode changes on Dec
> 14th. Juergen?
Please revert sys/kern/vfs_vnode.c to Rev 1.62 to make sure it is the
resu
state it would be just before a shutdown that
> crashes as you can make it).
>
> (Even if gdb were printing mnt_flag in hex (unlikely) the 0x20 bit
> is set and that's MNT_UNION.)
>
> kre
>
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
..
>> Jul 20 23:55:59 kamloops /netbsd: tmpfs_unmount() at
>> netbsd:tmpfs_unmount+0x2f
>
> For some reason this condition is met:
> wapbl_vphaswapbl(vp)
>
> but why?
The contents of this "struct vnode", especially its "v_tag"
and "v_mount" could help.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
With a -current kernel, options DEBUG, LOCKDEBUG and INTRDEBUG I get
a protection fault on shutdown. Somehow the "is_pic" entry contains
garbage.
Machine is IBM xSeries 336, arch is amd64.
Dmesg attached, any ideas anyone?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Br
ould be fixed now with Revision 1.4 of
external/bsd/elftoolchain/dist/libdwarf/libdwarf_elf_init.c
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
> On 03 Mar 2016, at 19:44, Christos Zoulas wrote:
>
> In article <5e50530c-0628-46e0-9457-440804e21...@eis.cs.tu-bs.de>,
> J. Hannken-Illjes wrote:
>>
>>> On 02 Mar 2016, at 09:11, Martin Husemann wrote:
>>>
>>> On Tue, Mar 01, 2016 at 05
an i386 object:
DEBUG: NO stabs: .stab=-1, .stabstr=0
DEBUG: DWARF version: 4
DEBUG: DWARF emitter: long long int
DEBUG: CU name: long long int
DEBUG: die 29 <0x1d>: create_one
DEBUG: die 29: creating base type
DEBUG: die 29: name "long long int" remapped to "long long"
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
e syssrc
> tarball, this looks wrong. It also immediately causes the suspicion
> that the list isn't in fact protected at all.
This file (fs/nfs/client/nfs_clvnops.c) is part of a second (dead) nfs
implementation from FreeBSD. It is not part of any kernel.
Our nfs lives in sy
On 15 Oct 2015, at 00:21, Rhialto wrote:
> On Wed 14 Oct 2015 at 09:39:40 +0200, J. Hannken-Illjes wrote:
>> Looks like a deadlock, two threads in tstile.
>>
>> Please take a backtrace (with arguments) of these threads.
>
> I've got a whole lot more in ts
see if the problem remains ?
>>
>> Good idea, I'll try that later!
>
> "Interesting" results: it built packages overnight (from around 22:30 to
> 12:13, so for nearly 14 hours), then, when I didn't look, it rebooted.
With panic?
--
J. Hannken-Illjes -
2>/dev/null | /usr/bin/xargs /bin/rm -f
>
> No zombies involved, though.
Looks like a deadlock, two threads in tstile.
Please take a backtrace (with arguments) of these threads.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
signature.asc
Description: Message signed with OpenPGP using GPGMail
stop enqueueing more work if a device is busy.
Protect this counter with a new short time lock "sme_work_mtx" and
keep "sme_mtx" as long time lock.
Removes a deadlock where an active event holds "sme_mtx", the callout
"sme_events_check" blocks on "sme_mtx" and callout processing stops.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
Darwin/MacOS X
> |\ / jdbaker[snail]mylinuxisp[flyspeck]comOpenBSDFreeBSD
> | X No HTML/proprietary data in email. BSD just sits there and works!
> |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
>
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
On 13 Mar 2015, at 16:33, Christos Zoulas wrote:
> On Mar 13, 4:12pm, hann...@eis.cs.tu-bs.de ("J. Hannken-Illjes") wrote:
> -- Subject: Re: DoS attack against TCP services
>
> | > Can't it just try to acquire the lock and if it fails it spams, and
> | &g
On 13 Mar 2015, at 14:57, Christos Zoulas wrote:
> On Mar 13, 1:08pm, hann...@eis.cs.tu-bs.de ("J. Hannken-Illjes") wrote:
> -- Subject: Re: DoS attack against TCP services
>
> | This was just an idea ... Maybe
> |
> | ...xs..timeout * sc->maxunits + 10
> |
On 13 Mar 2015, at 13:03, Christos Zoulas wrote:
> On Mar 13, 1:00pm, hann...@eis.cs.tu-bs.de ("J. Hannken-Illjes") wrote:
> -- Subject: Re: DoS attack against TCP services
>
> | This would be simple, changing dev/ic/ciss.c like:
> |
> | sc->sc_sm
On 13 Mar 2015, at 12:53, Christos Zoulas wrote:
> On Mar 13, 11:19am, hann...@eis.cs.tu-bs.de ("J. Hannken-Illjes") wrote:
> -- Subject: Re: DoS attack against TCP services
>
> | The mutex involved is the sme_mtx protecting the struct sysmon_envsys, so
> | our problem
gt;sme_events_timeout = 30
ccb->ccb_xs->timeout= 20 / sc->maxunits
to become safe.
Hope I got this right so far ...
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
On 12 Mar 2015, at 20:00, Christos Zoulas wrote:
> On Mar 12, 12:20pm, hann...@eis.cs.tu-bs.de ("J. Hannken-Illjes") wrote:
> -- Subject: Re: DoS attack against TCP services
>
> | Now we have a deadlock, softlck/0 waits for the mutex and therefore
> | callouts will n
de looks wrong in many aspects:
- Sleeping up to 60 seconds in a function used by a callout is wrong.
- Examining variables here we get: tick = 1, etick = 16000,
tohz = 6000 and i = 599. As tick is constant (us per hz)
this loop might run for 599*60 seconds!
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
s load failed" spam with
> opt
> ions DEBUG
>
>
> - if (modclass != MODULE_CLASS_EXEC || error != ENOENT)
> + if ((modclass != MODULE_CLASS_EXEC || error != ENOENT) &&
> + root_device != NULL)
>
> but why? Compiler bug
On 28 Feb 2015, at 19:39, 6b...@6bone.informatik.uni-leipzig.de wrote:
> On Sat, 28 Feb 2015, J. Hannken-Illjes wrote:
>>
>> This one looks bad. Which thread holds proc_lock?
>>
>
> Helps this?
>
> https://www.ipv6.uni-leipzig.de/proc_lock.png
Looks unlo
200 fe882df11860 softclk/0 tstile
This one looks bad. Which thread holds proc_lock?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
e (negative times).
> This would indicate something broken with interrupts... Let me see where we
> can add some debugging...
Anyone holding "proc_lock"? I had a similar problem with fstrans where
it was a deadlock with proc_lock preventing timer_intr() to succeed and
therefore all timers stopped working.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
On 31 Oct 2014, at 17:09, Tom Ivar Helbekkmo wrote:
> I'm experimenting with MooseFS on NetBSD/i386 and /amd64, current as of
> September 9th.
Please update -- hopefully fixed with Rev. 1.34 of fs/puffs/puffs_node.c
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
On 25 Aug 2014, at 15:55, J. Hannken-Illjes wrote:
> On 24 Aug 2014, at 18:57, J. Hannken-Illjes wrote:
>
>
>
>> I tried to bisect and got an increase in time from ~15 secs to ~24 secs
>> between the time stamps '2012-09-18 06:00 UTC' '2012-09-18 09:0
On 25 Aug 2014, at 17:39, Taylor R Campbell wrote:
> Date: Mon, 25 Aug 2014 15:55:53 +0200
> From: "J. Hannken-Illjes"
>
> GCC 4.5.4 disabled builtin memcmp as x86 has no cmpmemsi pattern.
>
> See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052, Comment
On 24 Aug 2014, at 18:57, J. Hannken-Illjes wrote:
> I tried to bisect and got an increase in time from ~15 secs to ~24 secs
> between the time stamps '2012-09-18 06:00 UTC' '2012-09-18 09:00 UTC'.
>
> Someone should redo this test as this interval is the imp
18 06:00 UTC' '2012-09-18 09:00 UTC'.
Someone should redo this test as this interval is the import of the
compiler (GCC 4.5.3 -> 4.5.4) and I had to rebuild tools. I cant
believe this to be a compiler problem.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (G
Subject says it all:
I'm looking for a RiscOS FILECORE disk image that is mountable and
readable on NetBSD with
vnconfig -rc vnd0 image
mount -r -t filecore /dev/vnd0d /mnt
ls -la /mnt
...
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
reate a bad sector on tmpfs -- see do_sys_mknodat() for
details. More analysis when cvs.netbsd.org is back again.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
On 21 Apr 2014, at 19:34, Christos Zoulas wrote:
> In article <910f0bed-9fd7-4c06-b886-e91002d03...@eis.cs.tu-bs.de>,
> J. Hannken-Illjes wrote:
>> On 21 Apr 2014, at 14:39, J. Hannken-Illjes wrote:
>>
>>> Since i386 switched to gcc48 ddb trace no longer work
On 21 Apr 2014, at 14:39, J. Hannken-Illjes wrote:
> Since i386 switched to gcc48 ddb trace no longer works:
>
> fatal breakpoint trap in supervisor mode
> trap type 1 code 0 eip c02802f4 cs 8 eflags 202 cr2 bbbab0c4 ilevel 8 esp 800
> curlwp 0xc5a9fd20 pid 0 lid 2 lowest ks
277cc1<= comintr+0x53e (caller of breakpoint)
dd25ef38: c0e661c0
Ideas anyone?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
ated memory region looks strange.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
86 matches
Mail list logo
