possible bug in sbp2/ieee1394_transactions on 2.5.74

possible bug in sbp2/ieee1394_transactions on 2.5.74

[Georg Nikodym]

[-- Attachment #1: Type: text/plain, Size: 1646 bytes --]

So I've finally got around to taking the 2.5 plunge (ieee1394
support and reported problems therewith scared me off).

Anyway, I've enabled spin-lock debugging and my messages file is filling
with things like:

Jul  4 22:29:55 keller kernel: Call Trace:
Jul  4 22:29:55 keller kernel:  [__might_sleep+99/112] __might_sleep+0x63/0x70
Jul  4 22:29:55 keller kernel:  [hpsb_get_tlabel+87/452] hpsb_get_tlabel+0x57/0x1c4
Jul  4 22:29:55 keller kernel:  [hpsb_make_writepacket+119/236] hpsb_make_writepacket+0x77/0xec
Jul  4 22:29:55 keller kernel:  [sbp2util_allocate_write_packet+40/84] sbp2util_allocate_write_packet+0x28/0x54
Jul  4 22:29:55 keller kernel:  [sbp2_link_orb_command+80/364] sbp2_link_orb_command+0x50/0x16c
Jul  4 22:29:55 keller kernel:  [sbp2_send_command+194/208] sbp2_send_command+0xc2/0xd0
...

on every access to my FW drive.  Seems to be a result of the:

	down(&tp->count);

in drivers/ieee1394/ieee1394_transactions.c:hpsb_get_tlabel()

For my purposes it's adequate to simply turn off the spin-lock
debugging.

As an aside, if this is a real bug in sbp2, then I'm thinking that Dave
Miller's line of reasoning about mailing lists being superior to bug
databases is flawed.  I've reported this issue once, I've worked around
it and will not be reporting it again (at least until my machine breaks
and I trace the breakage to this particular issue).  Moreover, I won't
be reporting any problems elsewhere in the system that could be caught
by spin-lock debugging.  So while I too detest dealing with bugzilla and
I feel a certain affinity for Miller's position, I can't help but feel
that the status quo is sub-optimal.

-g

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]