From: "R. J. Wysocki" <rjwysocki@sisk.pl>
To: Grzegorz Kulewski <kangur@polcom.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.6.[45]-.*: weird behavior
Date: Sun, 4 Apr 2004 01:09:13 +0200 [thread overview]
Message-ID: <200404040109.13414.rjwysocki@sisk.pl> (raw)
In-Reply-To: <Pine.LNX.4.58.0404032341450.18910@alpha.polcom.net>
On Sunday 04 of April 2004 00:15, Grzegorz Kulewski wrote:
> On Sat, 3 Apr 2004, R. J. Wysocki wrote:
> > On Saturday 03 of April 2004 21:50, Grzegorz Kulewski wrote:
> > > On Sat, 3 Apr 2004, R. J. Wysocki wrote:
> >
> > [...]
> >
> > > Can you attach config files for both the AMD64 and the laptop?
> >
> > The config for the laptop is attached, the other one must wait. If you
> > think of what they have in common, there's not much.
>
> Ok, some questions to that config file. Why do you have:
> - scsi emulation
> - scsi
> - both generic ide options
> - large block devices (2TB)?
SCSI support is necessary for USB storage, the rest is just for fun. :-)
> Can you post:
> - distro name and version
RH9
> - dmesg or log at the end of testing - better after such kb lock if you
> can reproduce, maybe after some stressing to see if any unnormal messages
> appeared
> - lspci -v
> - lsmod
> - mount
> - hdparm hdparm -iIvtT for all drives
> - some files from /proc describing configuration if you think they are
> important.
Well, I _really_ had not much time to track this. If I'd had time, I'd
probably have checked all these things already. I don't think there are any
unusual things about what you list, though.
> Does any process sleep in D state in ps output all the time or bechaves
> strangely? If so, maybe you should find and apply the patch for kernel
> stack for each process in /proc (it was included in wolk for example) and
> check what kernel function is causing the waits (for example I found some
> usb problems causing D state lock of processes using some usb ioctls).
Good idea, I can do that.
> If it all does not help, maybe you should compile kernel with all debug
> and kernel hacking options to see if some driver does not lock the kernel
> and sleep or something like that, or possibly try to find what changeset
> between 2.6.3 and 2.6.4 broke your setup :)
Well, the patch-2.6.4.bz2 is 2.2+M big. That's _a_ _lot_ of changesets, so I
don't think I can figure out this, unless I know which one could
_potentially_ cause the effects that I observe. Please, give me a hint, if
you have any idea.
--
Rafael J. Wysocki,
SiSK
[tel. (+48) 605 053 693]
----------------------------
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
-- Richard P. Feynman
next prev parent reply other threads:[~2004-04-03 23:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-03 19:22 R. J. Wysocki
2004-04-03 19:50 ` Grzegorz Kulewski
2004-04-03 21:36 ` R. J. Wysocki
2004-04-03 22:15 ` Grzegorz Kulewski
2004-04-03 23:09 ` R. J. Wysocki [this message]
2004-04-04 11:21 ` Grzegorz Kulewski
2004-04-05 10:29 ` R. J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200404040109.13414.rjwysocki@sisk.pl \
--to=rjwysocki@sisk.pl \
--cc=kangur@polcom.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®