linux1394-devel

RE: Linux 1394 somewhat unfriendly during boot?

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

Matt,
 
NT 4.0
Adaptec Driver from the retail pack, Microsoft doesn't support 1394 under NT
4.0 to the best of my knowledge. Not until Windows 2K
I haven't bothered to look on Adaptec's site for anything newer yet. I'll
poke around this afternoon and see what I find.
 
Interesting idea that it is the Windows box and not the Linux box causing
the problem. I'll see if I can figure out how to determine this...
 
Thanks,
Mark

-----Original Message-----
From: Matt Pujol [mailto:ma...@ls...]
Sent: Friday, May 19, 2000 9:44 AM
To: Mark Knecht
Cc: Linux1394 Developer's Reflector (E-mail)
Subject: Re: Linux 1394 somewhat unfriendly during boot?


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?

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

Manfred,
   Thanks for the info. There's some good stuff there.

   I think one important point you make is the compile option - kernel vs.
modules. I am compiled into the kernel and that means the loading of the
driver stack is earlier. I could certainly take it out, but I think in the
end it is not practical to have end-user types doing insmod's. I know,
'cause I'm an in user type and I don't know how to do it!!

   I may make a version of the kernel with module based loading this
weekend. Could you send back the instructions for doing the insmod steps so
that I get it right?

   I agree that some of the stability problem seems more apparent when I
build larger topologies. I intend to look into this more later.

   I am also seeing inconsistent identification of devices. Sometimes the
GUID's show up, sometimes they don't. I'd like to get my hands on a real
analyzer (3A or something) but they are too expensive for play. I understood
that there used to be some TI software for doing this with PCI-Lynx. Is
anyone in possession of that?

   More later, I'm sure.

Thanks,
Mark

-----Original Message-----
From: Manfred Weihs [mailto:e95...@st...]
Sent: Friday, May 19, 2000 11:12 AM
To: lin...@li...
Subject: Re: Linux 1394 somewhat unfriendly during boot?


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

_______________________________________________
mailing list lin...@li...
http://lists.sourceforge.net/mailman/listinfo/linux1394-devel

Re: Linux 1394 somewhat unfriendly during boot?

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

Mark Knecht wrote:
>    I think one important point you make is the compile option - kernel vs.
> modules. I am compiled into the kernel and that means the loading of the
> driver stack is earlier. I could certainly take it out, but I think in the
> end it is not practical to have end-user types doing insmod's. I know,
> 'cause I'm an in user type and I don't know how to do it!!

I think you misunderstood me. I wrote that I also compiled it into the
kernel and _not_ into modules. I did this, because I did not want to
bother around with that insmod's. But because of the mentioned stablity
problems I consider to put it into models and only load them, when I
really need them (or to plug off the 1394 cable and only plug in on
demand...).
But I think, that that makes not much difference, it only affects the
timing, when the driver is loaded.

>    I may make a version of the kernel with module based loading this
> weekend. Could you send back the instructions for doing the insmod steps so
> that I get it right?

I think, you will get two modules, one for the low-level-driver
(pciylynx.o or ohci.o or something like that) and one for the
higher-level (hardware-independent) subsystem functionality (maybe it's
called ieee1394.o?, look into /lib/modules) and you will have to insmod
both (I think first the lowlevel-driver, try it!).

>    I agree that some of the stability problem seems more apparent when I
> build larger topologies. I intend to look into this more later.

And we also see, that we are still far away from putting it into stable
kernel releases (2.2 or 2.4). But as cold comfort: That is also true for
the windows drivers; the only difference is, that here (on linux) it is
explicitly marked as experimental code, whereas MS claims that they have
stable code and sells beta-software as final releases...

Manfred

RE: Linux 1394 somewhat unfriendly during boot?

[James G. <jamesg@Filanet.com>]

Hi,

Many 1394 cards come up with LPS on (and send the link_active bit in
their self-id), and return ack_pending to async requests. Both the
Adaptec NT4.0 driver and the MS driver stacks attempt to read the config
rom during enumeration. Since the link returns ack_pending, these
drivers must wait for a split-transaction timeout, and then they retry
several times (in case it is a slow device they're talking to) before
giving up. So, it can take quite a while in this case for the
enumerating driver to "figure out" that the Link (and software) is not
really there yet.

Anyway, sounds like this is what you're seeing. Actually, it sounds like
there is a bug in the Adaptec NT 4.0 driver, since OHCI based cards
should come up with LPS off (Adaptec driver probably doesn't check
link_active bit before trying to enumerate a node).

I guess I would recommend Win2K and an OHCI card for testing with other
PCs. Adaptec is not actively supporting their 1394 cards or drivers
anymore.

Cheers,
--James

>From: Mark Knecht <mk...@co...>
>To: "Linux1394 Developer's Reflector (E-mail)"
><lin...@li...>
>Subject: RE: Linux 1394 somewhat unfriendly during boot?
>Date: Fri, 19 May 2000 09:56:53 -0700
>charset="iso-8859-1"
>
>Matt,
> 
>NT 4.0
>Adaptec Driver from the retail pack, Microsoft doesn't support 1394
under NT
>4.0 to the best of my knowledge. Not until Windows 2K
>I haven't bothered to look on Adaptec's site for anything newer yet.
I'll
>poke around this afternoon and see what I find.
> 
>Interesting idea that it is the Windows box and not the Linux box
causing
>the problem. I'll see if I can figure out how to determine this...
> 
>Thanks,
>Mark

RE: Linux 1394 somewhat unfriendly during boot?

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

Hi all,
   I am ONLY using the 1394 subsystem compiled into the kernel and it is
work great for me. I am not seeing any problems and have it installed on 5
machines, all with different processors &  motherboards.

   My tests include all of the applications that folks here have been
writing except for Franck's networking drivers. I have not tried them as of
yet. (Sorry Franck!!)

Mark

-----Original Message-----
From: Andreas Bombe [mailto:and...@mu...]
Sent: Saturday, June 10, 2000 11:22 AM
To: Manfred Weihs
Cc: Seb...@sy...;
lin...@li...
Subject: Re: Linux 1394 somewhat unfriendly during boot?


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/

_______________________________________________
mailing list lin...@li...
http://lists.sourceforge.net/mailman/listinfo/linux1394-devel