On Feb 28, 4:46pm, hann...@eis.cs.tu-bs.de (J. Hannken-Illjes) wrote:
-- Subject: Re: DoS attack against TCP services
| 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
In article cak4o1wwm2txkpdo_dhdmw-wxii_nlf+dypzc6turtdmz+-5...@mail.gmail.com,
Justin Cormack jus...@specialbusservice.com wrote:
On 28 February 2015 at 11:17, Patrick Welche pr...@cam.ac.uk wrote:
The surprise is that when building rump, gcc complains with:
On 28 Feb 2015, at 16:28, Christos Zoulas chris...@zoulas.com wrote:
On Feb 28, 11:37am, 6b...@6bone.informatik.uni-leipzig.de
(6b...@6bone.informatik.uni-leipzig.de) wrote:
-- Subject: Re: DoS attack against TCP services
| On Fri, 13 Feb 2015, Christos Zoulas wrote:
|
| I tried
The surprise is that when building rump, gcc complains with:
/usr/src/sys/rump/net/lib/libnet/../../../../net/route.c:1010:21: error:
initializer element is not constant
static const struct in_addr inmask32 = {.s_addr = INADDR_BROADCAST};
^
On Fri, 13 Feb 2015, Christos Zoulas wrote:
I tried adding show callout to crash(8) but it is not useful because the
pointers move too quickly. OTOH, next time this happens you can enter ddb
on your machine and type show callout and see if that sheds any light
to the expired and not fired
On 28 February 2015 at 11:17, Patrick Welche pr...@cam.ac.uk wrote:
The surprise is that when building rump, gcc complains with:
/usr/src/sys/rump/net/lib/libnet/../../../../net/route.c:1010:21: error:
initializer element is not constant
static const struct in_addr inmask32 = {.s_addr =
On Feb 28, 11:37am, 6b...@6bone.informatik.uni-leipzig.de
(6b...@6bone.informatik.uni-leipzig.de) wrote:
-- Subject: Re: DoS attack against TCP services
| On Fri, 13 Feb 2015, Christos Zoulas wrote:
|
| I tried adding show callout to crash(8) but it is not useful because the
| pointers move
On Sat, Feb 28, 2015 at 10:38:56PM +0100, Joerg Sonnenberger wrote:
On Sat, Feb 28, 2015 at 01:16:11PM -0500, Christos Zoulas wrote:
On Feb 28, 5:46pm, pr...@cam.ac.uk (Patrick Welche) wrote:
-- Subject: Re: rump and htonl() in constants
| Yes - I have DBG=-g -O0 in Makefile.rump
|
On Sat, Feb 28, 2015 at 04:08:34PM +, Christos Zoulas wrote:
In article
cak4o1wwm2txkpdo_dhdmw-wxii_nlf+dypzc6turtdmz+-5...@mail.gmail.com,
Justin Cormack jus...@specialbusservice.com wrote:
On 28 February 2015 at 11:17, Patrick Welche pr...@cam.ac.uk wrote:
The surprise is that when
On Sat, Feb 28, 2015 at 01:16:11PM -0500, Christos Zoulas wrote:
On Feb 28, 5:46pm, pr...@cam.ac.uk (Patrick Welche) wrote:
-- Subject: Re: rump and htonl() in constants
| Yes - I have DBG=-g -O0 in Makefile.rump
|
| I thought that would help trying to step through a rump kernel in gdb -
On Feb 28, 5:46pm, pr...@cam.ac.uk (Patrick Welche) wrote:
-- Subject: Re: rump and htonl() in constants
| Yes - I have DBG=-g -O0 in Makefile.rump
|
| I thought that would help trying to step through a rump kernel in gdb - not
| a good idea? (removing now)
|
| I suppose that is why no one
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
Regards
Uwe
On Feb 28, 7:39pm, 6b...@6bone.informatik.uni-leipzig.de
(6b...@6bone.informatik.uni-leipzig.de) wrote:
-- Subject: Re: DoS attack against TCP services
| On Sat, 28 Feb 2015, J. Hannken-Illjes wrote:
|
| This one looks bad. Which thread holds proc_lock?
|
|
| Helps this?
|
|
If DRM/KMS has been flaky for you, please try again in HEAD!
NetBSD 7.99.5 (GENERIC) #0: Sat Feb 28 10:26:18 EST 2015 GENERIC amd64
Radeon HD6450
radeon0 at pci1 dev 0 function 0: vendor 1002 product 6779 (rev. 0x00)
...
drm: initializing kernel modesetting (CAICOS 0x1002:0x6779
On 28 Feb 2015, at 18:20, 6b...@6bone.informatik.uni-leipzig.de wrote:
On Sat, 28 Feb 2015, Christos Zoulas wrote:
Good idea. You can use crash, ps and see what each process is holding...
christos
Here the output from crash and ps
gate# crash
Crash version 7.0_BETA, image version
On Sat, 28 Feb 2015, Christos Zoulas wrote:
Yes, that's a good start but we need to find which process that
lwp belongs to.
I'm not sure what the best course of action is. The machine is still
running. Should you try to get the information from the current system or
force a dump and analyze
On Sat, 28 Feb 2015, Christos Zoulas wrote:
Good idea. You can use crash, ps and see what each process is holding...
christos
Here the output from crash and ps
gate# crash
Crash version 7.0_BETA, image version 7.99.5.
WARNING: versions differ, you may not be able to examine this image.
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
On 28 February 2015 at 17:46, Patrick Welche pr...@cam.ac.uk wrote:
Hmm, I hadnt seen that. Maybe define an HTONL macro that uses shifts
and masks ifdef little endian so it is all done at compile time?
Are you trying to compile without optimization?
Yes - I have DBG=-g -O0 in Makefile.rump
On Thu, 26 Feb 2015, John D. Baker wrote:
Yes, this works. With a minimal xorg.conf:
Section Device
Option NoAccel True
Identifier Card0
Driver radeon
EndSection
Xorg works very well.
To clarify, with the NoAccel option, basic
20 matches
Mail list logo
