linux1394-devel

Linux 1394 somewhat unfriendly during boot?

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

Has anyone else seen this problem?
 
I have a 1394 topology with two PCs and a number of other peripherals. One
PC is the Linux box, the other is a Windows NT box with an Adaptec 1394 card
in it. If the Linux box is powered off and the Windows box is up and running
normally, and then I power on the Linux box, during the boot process on
Linux the Windows box is slowed to a crawl. The mouse will barely move,
everything is very slow. If I unplug the 1394 cable from either box (leaving
the rest of my topology intact, the Windows box speeds up again.
 
This seems like the Linux 1394 system may be pumping a lot of either packets
onto the bus, or doing a lot of bus resets. I don't have a 3A here, so I
can't really look at what is going on.
 
Does anyone know of any software for the Adaptec cards that will allow me to
just capture packets/bus operation?

Re: Linux 1394 somewhat unfriendly during boot?

[Matt P. <ma...@ls...>]

What version of NT are you running?
In the NT box, is it a Microsoft-provided 1394 driver or an OEM driver?

Some of the early (pre-Win98SE) 1394 stacks had trouble with devices that
didn't enumerate properly.  That could be what's happening, the LPS bit is set
in your SelfID, but the Link isn't responding to ConfigROM reads.  Hence,
Windows is completely baffled and continues to hammer on the Linux box until it
comes up.

Regards,

Matt

Mark Knecht wrote:

> Has anyone else seen this problem?
>
> I have a 1394 topology with two PCs and a number of other peripherals. One
> PC is the Linux box, the other is a Windows NT box with an Adaptec 1394 card
> in it. If the Linux box is powered off and the Windows box is up and running
> normally, and then I power on the Linux box, during the boot process on
> Linux the Windows box is slowed to a crawl. The mouse will barely move,
> everything is very slow. If I unplug the 1394 cable from either box (leaving
> the rest of my topology intact, the Windows box speeds up again.
>
> This seems like the Linux 1394 system may be pumping a lot of either packets
> onto the bus, or doing a lot of bus resets. I don't have a 3A here, so I
> can't really look at what is going on.
>
> Does anyone know of any software for the Adaptec cards that will allow me to
> just capture packets/bus operation?
>
> _______________________________________________
> mailing list lin...@li...
> http://lists.sourceforge.net/mailman/listinfo/linux1394-devel

--
/***********************
Matt Pujol
Product Marketing Manager
1394 and USB CoreWare technologies

LSI Logic
2001 Danfield Court
Fort Collins, Co 80525
970-206-5816
mat...@ls...
***********************/

Re: Linux 1394 somewhat unfriendly during boot?

[Manfred W. <e95...@st...>]

Mark Knecht wrote:
> This seems like the Linux 1394 system may be pumping a lot of either packets
> onto the bus, or doing a lot of bus resets.

I also observed, that when booting my linux PC (and since I compiled
1394 into the kernel, not into modules, the subsystem is loaded during
bootup) several bus resets occur. I do not know if this is bad or
unfriendly (the design of 1394 allows bus resets anytime, so it should
not hurt, if there are several bus resets), but I think one bus reset
should be enough.

I more frequently observed problems in the other direction, that
activities of other nodes caused my linux to crash. For example we have
1394-evaluation-boards from Vitana in our 1394-network, and if we press
the reset-button on this boards, my Linux pc sometimes dies (either
completly hangs up, so that I am not even able to ping it, or it starts
a reboot, or during reboot [mostly during fscheck since this takes some
time] gets a kernel panic). BTW: The Win boxes also die sometimes, but
my linux box does so more frequently.
I am sorry, that I was not yet able to find out, what conditions must
exactly be fulfilled to cause such a crash, so I cannot always reproduce
it (that is the reason why I did not yet post a bug report to the list);
but it seems that the instability grows with the number of active nodes
in the network.
I am not sure, if this is caused by a problem of the hardware (Unibrain
card) or the lowlevel driver (pcilynx) or by the higher subsystem
layers.
But I think that it is rather a software than a hardware problem,
because I yesterday tried to press the reset-button of that Vitana-board
many times during bootup and linux hang up _after_ the 1394-driver was
loaded.

Manfred Weihs

Re: Linux 1394 somewhat unfriendly during boot?

[Sebastien R. <Seb...@sy...>]

>>>>> "Manfred" == Manfred Weihs <e95...@st...> writes:

Manfred> I also observed, that when booting my linux PC (and since I compiled
Manfred> 1394 into the kernel, not into modules, the subsystem is loaded
Manfred> during bootup) several bus resets occur. I do not know if this is bad
Manfred> or unfriendly (the design of 1394 allows bus resets anytime, so it
Manfred> should not hurt, if there are several bus resets), but I think one
Manfred> bus reset should be enough.

I have not tested the ohci driver directly linked into the kernel, and so
I would not recommend using this option yet.

Manfred> I more frequently observed problems in the other direction, that
Manfred> activities of other nodes caused my linux to crash. For example we
Manfred> have 1394-evaluation-boards from Vitana in our 1394-network, and if
Manfred> we press the reset-button on this boards, my Linux pc sometimes dies
Manfred> (either completly hangs up, so that I am not even able to ping it, or
Manfred> it starts a reboot, or during reboot [mostly during fscheck since
Manfred> this takes some time] gets a kernel panic). BTW: The Win boxes also
Manfred> die sometimes, but my linux box does so more frequently.  I am sorry,
Manfred> that I was not yet able to find out, what conditions must exactly be
Manfred> fulfilled to cause such a crash, so I cannot always reproduce it
Manfred> (that is the reason why I did not yet post a bug report to the list);
Manfred> but it seems that the instability grows with the number of active
Manfred> nodes in the network.  I am not sure, if this is caused by a problem
Manfred> of the hardware (Unibrain card) or the lowlevel driver (pcilynx) or
Manfred> by the higher subsystem layers.  But I think that it is rather a
Manfred> software than a hardware problem, because I yesterday tried to press
Manfred> the reset-button of that Vitana-board many times during bootup and
Manfred> linux hang up _after_ the 1394-driver was loaded.

Yes, it is very likely to be sofware related. The linux1394 subsystem is
still very much alpha quality, that is why it is tagged as experimental
in the kernel configuration process.

-- 
Sebastien Rougeaux
RSISE, The Australian National University

Re: Linux 1394 somewhat unfriendly during boot?

[Manfred W. <e95...@st...>]

Sebastien Rougeaux wrote:
> I have not tested the ohci driver directly linked into the kernel, and so
> I would not recommend using this option yet.

1) I do not use ohci, but pcilynx.

2) I meanwhile compiled the stuff as modules, and the problem remains.
But I have now the possiblity to avoid the hang-ups of my machine by
unloading the 1394-modules before generating a bus reset und insmoding
them afterwards -> so it is definitely a bug in the driver.
Concerning the other thing I mentioned, the several bus resets on
bootup, I have not checked this yet. So I cannot tell you if it depends
on whether the driver is in the kernel or in a module. Maybe I check
this on Tuesday or Thursday (if I have time).

3) If it is not recommended to put the driver into the kernel, but
rather to put it into a module, this should be mentioned in the
documentation (/usr/src/linux/Documentation/Configure.help). If one does
not intend to update the driver more frequently than the driver, it
makes much sense to put it into the kernel, because then you do not have
to bother around with the insmod's. So if it is depreciated to compile
it into the kernel, there should be an explicit warning. BTW: Is there
any difference between kernel and module besides the moment, when the
code is loaded and activated?

> Yes, it is very likely to be sofware related. The linux1394 subsystem is
> still very much alpha quality, that is why it is tagged as experimental
> in the kernel configuration process.

ack.

Manfred Weihs

Re: Linux 1394 somewhat unfriendly during boot?

[Andreas B. <and...@mu...>]

On Fri, Jun 09, 2000 at 06:48:43PM +0200, Manfred Weihs wrote:
> Sebastien Rougeaux wrote:
> > I have not tested the ohci driver directly linked into the kernel, and so
> > I would not recommend using this option yet.
> 
> 1) I do not use ohci, but pcilynx.
> 
> 2) I meanwhile compiled the stuff as modules, and the problem remains.
> But I have now the possiblity to avoid the hang-ups of my machine by
> unloading the 1394-modules before generating a bus reset und insmoding
> them afterwards -> so it is definitely a bug in the driver.

I found some problems apparantly with PCILynx while experimenting with
the driver on a StrongARM platform.  I'm still experimenting.

> 3) If it is not recommended to put the driver into the kernel, but
> rather to put it into a module, this should be mentioned in the
> documentation (/usr/src/linux/Documentation/Configure.help). If one does
> not intend to update the driver more frequently than the driver, it
> makes much sense to put it into the kernel, because then you do not have
> to bother around with the insmod's.

If it doesn't work compiled in then that is a bug and not expected.
Of course, this doesn't usually show up on my system since I compile
as modules in order to not have to reboot constantly during
development (unless forced to :-)  However, I do try a monolithic
kernel once in a while.

-- 
 Andreas E. Bombe <and...@mu...>    DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/    http://linux1394.sourceforge.net/