[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux1394-devel
Subject:    Re: sbp2: sbp2util_node_write_no_wait failed
From:       Michael Brade <brade () informatik ! uni-muenchen ! de>
Date:       2005-11-05 15:57:04
Message-ID: 200511051657.04491.brade () informatik ! uni-muenchen ! de
[Download RAW message or body]

On Saturday 05 November 2005 13:57, you wrote:
> Michael Brade wrote:
> > Ok, fair enough, however, you didn't tell me yet what to do next...
>
> I hope my lack of insight didn't come across as lack of manners. :-)
LOL, not in the least.

> It is mysterious though why it happens only with writes, not with reads.
Ok, I will try to do some more aggressive reading then, let's see if I can 
reproduce this error then as well.

> BTW, when you replaced the Prolific based enclosure by an Oxford 911
> based one, did you check what's actually on the bridge board? Some
> Prolific firmwares show strings in their config ROM that look similar to
> what a OXFW911 firmware would show.
Yup, I checked, there was a PL-3507 chip on it, no Oxford(compatible) chips. 
If that's not what you mean, I still have the firmware image around and I can 
send it to you if you want.

> Google shows 158 hits for "aborting sbp2 command" +
> "sbp2util_node_write_no_wait failed" but 1370 hits for "aborting sbp2
> command" alone.
Mmh. I guess I should have tried that as well :-} I skimmed through a few of 
them, and it seems either it's an older report (< 2.6.14) and/or 
serialize_io=1 cured the problem. I actually tried it with 2.6.13 at first 
and got the exact same messages as well (only "aborting sbp2 command", no 
write_no_wait errors). I didn't report them though since I saw that there was 
a new kernel with some changes in the sbp2 at that time. After the upgrade 
the error changed and that's where we are now. So I'd tend to think those old 
reports without the write_no_wait failure might not be valid anymore.

> At least the particular problem that tlables may be exhausted when sbp2
> tries to ring the doorbell is now a well-known problem, thanks to your
> really good debugging work. You are right, we should try the best to
> solve this problem right now, given that you and your system are now
> available for testing. What I said above was because I am afraid of the
> consequences of my idea of a solution. Maybe a more relaxed attitude
> would be more productive. :-)
Hehe, if you say so ;-)

> I will work on the workqueue idea during 2nd half of next week. (At
> least I hope to be able to do so.) 
Great, take your time! I'm looking forward to trying your solution.

> Of course if you or anybody else has 
> something to contribute or has an idea for a better approach, the better.
I wish I had... I have problems understanding the tlabel code and its 
connections already, I really lack too much of the basics regarding kernel 
development and SCSI/IEEE1394/SBP2 :-(

Cheers,
-- 
Michael Brade;                 KDE Developer, Student of Computer Science
  |-mail: echo brade !#|tr -d "c oh"|s\e\d 's/e/\@/2;s/$/.org/;s/bra/k/2'
  °--web: http://www.kde.org/people/michaelb.html

KDE 3: The Next Generation in Desktop Experience

[Attachment #3 (application/pgp-signature)]
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
mailing list linux1394-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux1394-devel

[prev in list] [next in list] [prev in thread] [next in thread]