[PATCH] acsi.c & usbusx2yaudio.c & usx2yhwdeppcm.c ,2.6.12.5

From: John Barkas (risc4all_at_yahoo.com)
Date: 08/30/05

  • Next message: Mark Gross: "Re: Telecom Clock driver for MPCBL0010 ATCA compute blade." 
    Date:	Tue, 30 Aug 2005 13:41:02 -0700 (PDT)
To: linux-kernel@vger.kernel.org

    I send this e-mail to you with the patches ready as
    the patch fixes are obvious.

    Hello I am Ioannis Barkas.You can contact me at
    risc4all@yahoo.com.

    There is a typo error in the comments area of
    linux-2.6.12.5\drivers\block at the file

    acsi.c

    There are two typo errors in
    linux-2.6.12.5\sound\usb\usx2y at the file

    usbusx2yaudio.c

    There is a typo error in
    linux-2.6.12.5\sound\usb\usx2y at the file

    usx2yhwdeppcm.c

    I found this bug after I had it repeated in some files
    on my HDD...That time it was clear and obvious to me
    that the kernel would suffer from this error..Luckily
    it affected only those three files.

                    
    ____________________________________________________
    Start your day with Yahoo! - make it your home page
    http://www.yahoo.com/r/hs
     

    Hello I am Ioannis Barkas.You can contact me at risc4all@yahoo.com.

    There is a typo error in the comments area of linux-2.6.12.5\drivers\block at the file

    acsi.c

    There are two typo errors in linux-2.6.12.5\sound\usb\usx2y at the file

    usbusx2yaudio.c

    There is a typo error in linux-2.6.12.5\sound\usb\usx2y at the file

    usx2yhwdeppcm.c

    I found this bug after I had it repeated in some files on my HDD...That time it was clear and obvious to me that the kernel would suffer from this error..Luckily it affected only those three files.

    --- /0/linux-2.6.12.5/drivers/block/acsi.c 2005-08-30 22:00:00.000000000 +0300
    +++ /1/linux-2.6.12.5/drivers/block/acsi.c 2005-08-30 23:00:00.000000000 +0300
    @@ -604,7 +604,7 @@
     /*
      * ACSI status phase: get the status byte from the bus
      *
    - * I've seen several times that a 0xff status is read, propably due to
    + * I've seen several times that a 0xff status is read, probably due to
      * a timing error. In this case, the procedure is repeated after the
      * next _IRQ edge.
      */

    --- /0/linux-2.6.12.5/sound/usb/usx2y/usbusx2yaudio.c 2005-08-30 22:00:00.000000000 +0300
    +++ /1/linux-2.6.12.5/sound/usb/usx2y/usbusx2yaudio.c 2005-08-30 23:00:00.739618560 +0300
    @@ -78,7 +78,7 @@
             for (i = 0; i < nr_of_packs(); i++) {
                     cp = (unsigned char*)urb->transfer_buffer + urb->iso_frame_desc[i].offset;
                     if (urb->iso_frame_desc[i].status) { /* active? hmm, skip this */
    - snd_printk("activ frame status %i. Most propably some hardware problem.\n", urb->iso_frame_desc[i].status);
    + snd_printk("activ frame status %i. Most probably some hardware problem.\n", urb->iso_frame_desc[i].status);
                             return urb->iso_frame_desc[i].status;
                     }
                     len = urb->iso_frame_desc[i].actual_length / usX2Y->stride;
    @@ -291,7 +291,7 @@
     static void usX2Y_error_sequence(usX2Ydev_t *usX2Y, snd_usX2Y_substream_t *subs, struct urb *urb)
     {
             snd_printk("Sequence Error!(hcd_frame=%i ep=%i%s;wait=%i,frame=%i).\n"
    - "Most propably some urb of usb-frame %i is still missing.\n"
    + "Most probably some urb of usb-frame %i is still missing.\n"
                        "Cause could be too long delays in usb-hcd interrupt handling.\n",
                        usb_get_current_frame_number(usX2Y->chip.dev),
                        subs->endpoint, usb_pipein(urb->pipe) ? "in" : "out", usX2Y->wait_iso_frame, urb->start_frame, usX2Y->wait_iso_frame);

    --- /0/linux-2.6.12.5/sound/usb/usx2y/usx2yhwdeppcm.c 2005-08-30 22:00:00.000000000 +0300
    +++ /1/linux-2.6.12.5/sound/usb/usx2y/usx2yhwdeppcm.c 2005-08-30 23:00:00.930579704 +0300
    @@ -72,7 +72,7 @@
             }
             for (i = 0; i < nr_of_packs(); i++) {
                     if (urb->iso_frame_desc[i].status) { /* active? hmm, skip this */
    - snd_printk("activ frame status %i. Most propably some hardware problem.\n", urb->iso_frame_desc[i].status);
    + snd_printk("activ frame status %i. Most probably some hardware problem.\n", urb->iso_frame_desc[i].status);
                             return urb->iso_frame_desc[i].status;
                     }
                     lens += urb->iso_frame_desc[i].actual_length / usX2Y->stride;

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Mark Gross: "Re: Telecom Clock driver for MPCBL0010 ATCA compute blade."

    Relevant Pages