2ND ATTEMPT - NEW DATA - Linux 1394 somewhat unfriendly during bo ot?

[Mark K. <mk...@co...>]

(2ND ATTEMPT - Sunday's e-mail failed due to length of attachments.)
=A0
Hi all,
=A0=A0 Contained herein is some data I've collected concerning how my =
Linux
system is acting during a warm boot. Basic status of the system is:
=A0
1) Linux PC using CVS code tree for both ieee1394 & libraw1394
2) 1394 support compiled into kernel
3) Five 1394 devices on the bus, Linux PC is the only 400Mb device. (On
purpose!)
=A0
=A0=A0 When I reboot this PC, sometimes it boots 'friendly', meaning my =
other
PC, a Windoze box, does not especially react to the fact that the =
reboot is
happening. Many times, however, that PC reacts noticeably by slowing =
down to
a crawl for what appears to be 5-10 seconds. Even the mouse on that =
system
acts badly when the Linux box is rebooting. I think the data in the =
attached
files shows generally what is going on.
=A0
=A0=A0 In all cases, the other four 1394 devices are powered up and =
ready to go,
and there is no 'intended' bus traffic taking place. No applications =
are
running. I don't think the camera device is transmitting anything. The =
CR-RW
& RDK aren't doing anything.
=A0
=A0=A0 I'm placing the simple version of the text for you to look at in =
the
attachment 'e-mail-text.txt' and the more complete version of the boot
sequences in 'boot-sequence.txt' so that email line length limiters =
don't
make it too hard to read.
=A0
=A0=A0 In e-mail-text.txt, notice that in the friendly sequence we are =
the only
400Mb device, and that we generated the bus reset. However, in the
unfriendly sequence, we did not generate the bus reset, but device 0 =
did. At
the end of the unfriendly sequence in this file you see the =
'unsolicited
response packet', which starts off the next set of bus resets and =
Self-ID
sequences. This goes on for quite awhile, and then eventually calms =
down.
(See=A0SHORT-boot-sequence.txt) (Notice that the two sequences are =
actually
quite different much earlier on...)
=A0
=A0=A0 I am concerned about whether some of this might be caused by way =
I built
and installed the new kernel. LILO=A0is possibly not reading the right
system.map file for this revision of the kernel. Comments on this are =
very
welcome. I have multiple kernels installed in lilo.conf, but it does =
not
seem to me that after a reboot the System.Map link is always pointing =
at the
one that is currently running, and the line in the message file doesn't =
seem
to me that it is reading the right one. I may rebuild this system with =
a
single kernel just to ensure that this is not the issue.
=A0
=A0=A0 If anyone has ideas about other experiments I could do, I =
welcome those
also.
=A0
With best regards,
Mark