Re: build.sh kernel does not finish with endless nbctfmerge run

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

Re: build.sh kernel does not finish with endless nbctfmerge run

> 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(

Re: build.sh kernel does not finish with endless nbctfmerge run

tal 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's the pro

Re: Strange sensor names for amdzentemp(4)

gt; 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

Re: ethernet

> 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

Re: Panic on dump over fss

+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

Re: Panic on dump over fss

/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

Re: blocklist puzzle

> 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

Re: 9.99.104: panic in tcp_shutdown_wrapper

{ ... 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

Re: Doc error - sysctl

gt; | & Network Engineer | | pgoyett...@gmail.com | > +--------+--+--+ -- J. Hannken-Illjes - hann...@mailbox.org signature.asc Description: Message signed with OpenPGP

Re: pgdaemon high CPU consumption

> ``` > > 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

Re: kernel deadlock on fstchg with vnd

> 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: >>> >&g

Re: kernel deadlock on fstchg with vnd

j, 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

Re: NetBSD Xen guest freezes system + vif MAC address confusion (NetBSD 9.99.97 / Xen 4.15.2)

> 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

Re: NetBSD Xen guest freezes system + vif MAC address confusion (NetBSD 9.99.97 / Xen 4.15.2)

> 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

Re: NetBSD Xen guest freezes system + vif MAC address confusion (NetBSD 9.99.97 / Xen 4.15.2)

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

Re: panic: kernel diagnostic assertion VOP_ISLOCKET(vp) == LK_EXCLUSIVE

> 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-

Re: panic: kernel diagnostic assertion VOP_ISLOCKET(vp) == LK_EXCLUSIVE

> 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

Re: panic: kernel diagnostic assertion VOP_ISLOCKET(vp) == LK_EXCLUSIVE

> 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

Re: panic: kernel diagnostic assertion VOP_ISLOCKET(vp) == LK_EXCLUSIVE

> 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 >>>> issu

Re: panic: kernel diagnostic assertion VOP_ISLOCKET(vp) == LK_EXCLUSIVE

_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_worker() a

Re: reproducible kernel crash with quota

> 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

Re: reproducible kernel crash with quota

> 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

Re: reproducible kernel crash with quota

> 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

Re: panic: kernel diagnostic assertion VOP_ISLOCKET(vp) == LK_EXCLUSIVE

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

Re: reproducible kernel crash with quota

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

Re: Unprivileged build can't build custom kernels

bj/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

Re: null mounts seem to lose directories?

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-

Re: 9.99.86 HEAD

> 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

Re: 9.99.86 HEAD

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...@eis

Re: dump/restore out of range inode

> 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. >>

Re: dump/restore out of range inode

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

Re: dump/restore out of range inode

eted 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

Re: zfs howto

; 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

Re: Automated report: NetBSD-current/i386 test failure

/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

Re: panic on zpool create

+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 want to mou

Re: Tar extract behaviour changed

-- 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

Tar extract behaviour changed

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

Re: i386 9.99.17 build fails for NET4501 kernel

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

Re: VFS panic

. > 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 coup

Re: Kernel crash trying to use union mount

while (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

Re: panic when removing a file in current

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

Re: panic when removing a file in current

ort 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)

Re: netbsd-8 hang on tstile

ng my automatic test script hangs the 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)

Re: FFS panic

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 <bou...@antioche.eu.org> wrote: > >

Re: Fixing swap1_stop

> On 19. Aug 2017, at 14:20, Christos Zoulas <chris...@zoulas.com> 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 no

Re: Fixing swap1_stop

es a forced unmount would detach them from the file system and keep them active. Did you mean something like this? -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)

Re: ffs_vnops.c changes break kernels w/o WAPBL

*/ > + > + error = 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)

Re: 7.99.50 complete hang

> On 19 Dec 2016, at 14:31, Joerg Sonnenberger <jo...@bec.de> wrote: > > On Sun, Dec 18, 2016 at 09:55:58PM +0100, J. Hannken-Illjes wrote: >> >>> On 18 Dec 2016, at 21:49, Joerg Sonnenberger <jo...@bec.de> wrote: >>> >>> On Sun, Dec

Re: 7.99.50 complete hang

but it dead locked as soon 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

Re: repeated failure to properly shutdown

> On 22 Jul 2016, at 10:39, Robert Elz wrote: > >Date:Thu, 21 Jul 2016 16:38:57 -0700 >From:bch >Message-ID: >

Re: repeated failure to properly shutdown

.. >> 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)

Re: nbctfmerge runs for hours on custom i386 kernels

situation. Should 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)

Re: nbctfmerge runs for hours on custom i386 kernels

> On 03 Mar 2016, at 19:44, Christos Zoulas <chris...@astron.com> wrote: > > In article <5e50530c-0628-46e0-9457-440804e21...@eis.cs.tu-bs.de>, > J. Hannken-Illjes <hann...@eis.cs.tu-bs.de> wrote: >> >>> On 02 Mar 2016, at 09:11, Martin Husemann <

Re: nbctfmerge runs for hours on custom i386 kernels

ot;char" and from 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)

Re: NFS related panics and hangs

s_reqq_mtx in the whole 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 liv

Re: Killing a zombie process?

On 15 Oct 2015, at 00:21, Rhialto <rhia...@falu.nl> 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

Re: Killing a zombie process?

with one of them missing and 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. Han

Re: Killing a zombie process?

t; -print\t 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

Re: coretemp0: workqueue busy: updates stopped

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)

Re: coretemp0: workqueue busy: updates stopped

OpenBSDFreeBSD | 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)

Re: DoS attack against TCP services

... -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)

Re: DoS attack against TCP services

On 13 Mar 2015, at 13:03, Christos Zoulas chris...@zoulas.com 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_sme-sme_name =3D device_xname

Re: DoS attack against TCP services

On 13 Mar 2015, at 12:53, Christos Zoulas chris...@zoulas.com 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 doesn't come

Re: DoS attack against TCP services

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)

Re: DoS attack against TCP services

On 12 Mar 2015, at 20:00, Christos Zoulas chris...@zoulas.com 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 no longer

Re: rump i386 cross compile trouble

!= MODULE_CLASS_EXEC || error != ENOENT) + root_device != NULL) but why? Compiler bug (gcc)? Given this fragment is #ifdef DEBUG it looks like rump_server has to be linked with librumpvfs in the DEBUG case? Antti? -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig

Re: DoS attack against TCP services

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)

Re: DoS attack against TCP services

. Which thread holds proc_lock? -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)

Re: DoS attack against TCP services

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 unlocked -- what about a backtrace of thread 0.5, bt

Re: FUSE crashes on i386 and amd64

On 31 Oct 2014, at 17:09, Tom Ivar Helbekkmo t...@hamartun.priv.no 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

Re: Testing 7.0 Beta: FFS still very slow when creating files

On 25 Aug 2014, at 17:39, Taylor R Campbell riastr...@netbsd.org wrote: Date: Mon, 25 Aug 2014 15:55:53 +0200 From: J. Hannken-Illjes hann...@eis.cs.tu-bs.de GCC 4.5.4 disabled builtin memcmp as x86 has no cmpmemsi pattern. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052

Re: Testing 7.0 Beta: FFS still very slow when creating files

On 25 Aug 2014, at 15:55, J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote: On 24 Aug 2014, at 18:57, J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote: snip 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

Re: Testing 7.0 Beta: FFS still very slow when creating files

- 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 (Germany) Btw.: my test script is: #! /bin/sh mdconfig /dev/md0d 2048000 P=${!} newfs /dev/rmd0a mount -t ffs -o log /dev/md0a /mnt (cd /mnt

RiscOS FILECORE disk image needed

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)

Re: tmpfs lock error panic with mknod+S_IFMT

-- 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)

Re: i386 ddb trace stopped working with gcc48

On 21 Apr 2014, at 19:34, Christos Zoulas chris...@astron.com wrote: In article 910f0bed-9fd7-4c06-b886-e91002d03...@eis.cs.tu-bs.de, J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote: On 21 Apr 2014, at 14:39, J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote: Since i386 switched to gcc48 ddb

i386 ddb trace stopped working with gcc48

= comintr+0x53e (caller of breakpoint) dd25ef38: c0e661c0 Ideas anyone? -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)

Re: i386 ddb trace stopped working with gcc48

On 21 Apr 2014, at 14:39, J. Hannken-Illjes hann...@eis.cs.tu-bs.de 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

Re: Cannot execute elf binary ...

allocated memory region looks strange. -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)