Greetings... Long time lister first time caller  :)

On the subject of kernel hangs and hangs in general.  

I have this idea and am wondering what others think the usefulness of it
might be.  Inside the file kernel/sched.c, within function schedule(), right
before the lines (line 637 in linux-2.4.3).

if( prev == next )
        goto same_process;

I thinking of writing something like 'prev->pid, next->pid, jiffies' to a
glob of kmalloc'd kernel memory.  Then write a device driver which can read
the memory glob.  In this way, I could note the last thread's pid which was
active prior to a crash.  The information can also be used for profiling
information (which thread is getting time.  Of course the crash is within
the kernel itself, making this information non-volatile would be essential.

I'm surprised there is not already a tool like this out there.  I've
searched and have not been able to find anything. I wonder if anyone has a
similar tool lying around somewhere?

Thanks,

Nat

-----Original Message-----
From: Matthew Dharm [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 13, 2001 10:36 AM
To: [EMAIL PROTECTED]
Subject: Re: [linux-usb-devel] How to diagnose kernel hangs?


On Wed, Jun 13, 2001 at 05:58:04PM +0200, Sancho Dauskardt wrote:
> 
> >A 10 second delay will cause the scsi error handler thread to fire.  This
> >should cause all sorts of things to happen, but often winds up resulting
in
> >a deadlock -- not just with usb-storage, but with lots of SCSI
controllers,
> >too.
> 10 seconds ?? Can this be changed somwhere in the Kernel easily ??
> I haven't layed my hands on one yet, but a 128MB SSFDC would take at least

> 16 (if not 32, USB_COMBO master/slave, you remember) seconds for the TUR
to 
> complete...

The timeout is set on a per-command basis.  For this command, in this
_particular_ instance, the timeout is set during the scsi probing calls --
used to be in scsi_probe.c, but I haven't looked lately.

> >  See the linux-scsi archives for some of the discussion.
> >
> >Out of curiosity, can you see command_abort() called in the dmesg if you
> >send kern.=debug to /dev/console?
> 
> Yes.
> 
> - sda

Well, it might be interesting to see the last things that appear before the
hard lockup.  It might give us a clue as to where to start looking.

Matt


-- 
Matthew Dharm                              Home:
[EMAIL PROTECTED] 
Maintainer, Linux USB Mass Storage Driver

What, are you one of those Microsoft-bashing Linux freaks?
                                        -- Customer to Greg
User Friendly, 2/10/1999

_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to