1394 Async packet corruption

Discussion in 'Windows Vista Drivers' started by Chi Ho Ng, Nov 21, 2004.

  1. Chi Ho Ng

    Chi Ho Ng Guest

    Hi everyone,

    I built a WDM driver that sits on top of the ohci1394 bus driver. The driver
    allocates multiple address ranges (using the no notification mode, in which
    the bus driver passes the 1394 request/response packets to my driver) to
    receive async write requests from our devices. It seemed that when the
    transfer rate from the devices are high (around 30 MBps), the requests and
    response passed up through the notification routines are corrupted...

    A similar problem appears when I tried using the notification mode, where
    the notification function is not called sometimes when the data transfer
    rate was high.

    I am using XP with SP1. Has anyone else seen the same problem? If so, is
    there a way to prevent this from happening?

    Thanks

    Chi
     
    Chi Ho Ng, Nov 21, 2004
    #1
    1. Advertisements

  2. Chi Ho Ng

    Guest Guest

    Once I've seen the following issue with iso packets.

    - Desktop PC <-> Sony camcorder - OK
    - Desktop PC <-> Panasonic - OK
    - Laptop <-> Sony - OK
    - Laptop <-> Panasonic - Corrupted packets

    In my case, I believe it was a hardware problem.
     
    Guest, Nov 21, 2004
    #2
    1. Advertisements

  3. Chi Ho Ng

    Udo Reuther Guest

    Hello,

    I'm experiencing a problem that could be related to yours.
    I've written a 1394 driver which receives isochronous stream data. It works
    very well on most computers.
    On *some* computers which don't seem to have something in common, the data
    which I receive im my notification routine is sometimes corrupted.
    I've made some oberservations:
    - The data is corrupted at different offsets in the packet.
    - Normally there are only some quadlets wrong.
    - These quadlets seem not be from this packet or the previous or the
    following.
    - A pattern I saw sometimes was: 7 wrong quadlets, the first some value X
    then a 0, then X again, then 0 again and so on.
    - The problem occurs only when the packets are bigger than about 2 kB.

    I tried Windows XP and XP SP1. I updated the BIOS, the chipset drivers.
    Typically I transfer about 20 MB per second or less when the problem occurs.
    We have very slow PCs which *don't* show the issue at all.

    I think maybe it happens when the 2K receive FIFO in the OHCI Lynx is
    overrun?!
    Sorry, I have no solution for you, but maybe this gives you a hint for your
    further tests.

    If you get a solution for your problem, please let me know. So will I do.

    Regards
    Udo.
     
    Udo Reuther, Dec 3, 2004
    #3
  4. Chi Ho Ng

    Raj Guest

    I use 1394 Async with

    Mdl = NULL
    FifoSListHead = NULL
    FifoSpinLock = NULL

    I dont have any issue with this option. Try this.
     
    Raj, Dec 3, 2004
    #4
  5. Chi Ho Ng

    Chi Ho Ng Guest

    Hi ,

    Thank you very much for your information. So far, what I have determined is
    that the problem starts to occur when the firewire packet size is 1K and the
    throughput is around 22MB/s. When the 1394 packet goes up to 2K, the problem
    haven't yet occured with throughput at 38MB/s.. I have a feeling that it
    might break when the throughput goes higher..

    I am currently using the raw mode, in which there is no backing store (same
    as Raj). However, I still get the corrupted packets. When I have a backing
    store (i.e. valid MDL), the notification routines for some packets are not
    called after the packet has arrived.

    It is good to hear that the problem happens on some machines but not on
    others.

    Also, when I use raw mode (async with no backing store), I find that I don't
    have to supply the response packet for receiving async-write request. I
    suspect Windows actually issues a ACK_COMPLETE to complete the async-write
    trasaction as soon as it receives a request from the other node. Hence it
    would discard the response packet even if I specify it. I tried doing some
    tests by sending async-write between two PC, and the async-write is always
    succesful regardless of the response code I specified in response packet...
    Could someone confirm if my suspicion is correct?

    Thanks

    Chi Ho
     
    Chi Ho Ng, Dec 5, 2004
    #5
  6. Chi Ho Ng

    Udo Reuther Guest

    Hello Raj,

    maybe I was not clear enough, but my problems have to do with *isoch*
    packets only. I wanted only some input to Chi, maybe his problem also has to
    with the packet size. And yes, my async routines with no backing store also
    work fine.

    Regards,
    Udo.
     
    Udo Reuther, Dec 6, 2004
    #6
  7. Chi Ho Ng

    Udo Reuther Guest

    Hello Chi,

    I can't tell you for writes, but I tested it with locks: When my driver
    builds an error response packet this (with its error code) can be seen on the
    bus. In short words: If answer a lock request packet with an error response
    this response is definitly propagated to the bus (I know because the firmware
    of our device didn't handle this correctly). Normally I would expect the
    request to time out. See the article of Bill McKenzie at wd-3.com.


    Regards,
    Udo.
     
    Udo Reuther, Dec 6, 2004
    #7
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.