Project

General

Profile

Actions

Bug #218

closed

cvsync hangs in sbwait / kgdb doesn't work

Added by corecode over 15 years ago. Updated about 15 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

hey,

i just tried to update my box and ran into some issues:

1. when running cvsync, it does some negotiating (so the tcp connection
works) but then hangs with "sbwait". it is not possible to ^C or ^]
it, a kill -9 works though.

when i wanted to debug this, another issue popped up:
2. kgdb doesn't work anymore (with /dev/mem): it tries to read
CPU_prvdata but fails reading from 0xff800000. this somehow worked
before, and it works in 1.4-release/gdb -k. so something in the kernel
must have changed since. because of this i couldn't debug 1)

clues?

cheers
simon

Actions #1

Updated by corecode over 15 years ago

On 27.06.2006, at 14:20, Simon 'corecode' Schubert wrote:

1. when running cvsync, it does some negotiating (so the tcp
connection works) but then hangs with "sbwait". it is not possible to
^C or ^] it, a kill -9 works though.

okay, bug found + fixed, will commit shortly.

when i wanted to debug this, another issue popped up:
2. kgdb doesn't work anymore (with /dev/mem): it tries to read
CPU_prvdata but fails reading from 0xff800000. this somehow worked
before, and it works in 1.4-release/gdb -k. so something in the
kernel must have changed since. because of this i couldn't debug 1)

this is still current, tho.

cheers
simon

Actions #2

Updated by dillon over 15 years ago

:> when i wanted to debug this, another issue popped up:
:> 2. kgdb doesn't work anymore (with /dev/mem): it tries to read=20
:> CPU_prvdata but fails reading from 0xff800000. this somehow worked=20
:> before, and it works in 1.4-release/gdb -k. so something in the=20
:> kernel must have changed since. because of this i couldn't debug 1)
:
:this is still current, tho.

I've encountered this too.  I'll try to get it fixed today.  I think
it is due to the bounds check code in /dev/mem.
-Matt
Actions

Also available in: Atom PDF