1. 01 7月, 2006 1 次提交
  2. 29 6月, 2006 7 次提交
  3. 28 6月, 2006 2 次提交
  4. 27 6月, 2006 11 次提交
  5. 26 6月, 2006 3 次提交
    • R
      [PATCH] ide-floppy: fix debug-only syntax error · 18cddac3
      Randy Dunlap 提交于
      Fix debug-only printk syntax error.
      Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      18cddac3
    • A
      [PATCH] IDE CD end-of media error fix · dbe217af
      Alan Cox 提交于
      This is a patch from Alan that fixes a real ide-cd.c regression causing
      bogus "Media Check" failures for perfectly valid Fedora install ISOs, on
      certain CD-ROM drives.
      
      This is a forward port to 2.6.16 (from RHEL) of the minimal changes for the
      end of media problem.  It may not be sufficient for some controllers
      (promise notably) and it does not touch the locking so the error path
      locking is as horked as in mainstream.
      
      From: Ingo Molnar <mingo@elte.hu>
      
      I have ported the patch to 2.6.17-rc4 and tested it by provoking
      end-of-media IO errors with an unaligned ISO image.  Unlike the vanilla
      kernel, the patched kernel interpreted the error condition correctly with
      512 byte granularity:
      
       hdc: command error: status=0x51 { DriveReady SeekComplete Error }
       hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
       ide: failed opcode was: unknown
       ATAPI device hdc:
         Error: Illegal request -- (Sense key=0x05)
         Illegal mode for this track or incompatible medium -- (asc=0x64, ascq=0x00)
         The failed "Read 10" packet command was:
         "28 00 00 04 fb 78 00 00 06 00 00 00 00 00 00 00 "
       end_request: I/O error, dev hdc, sector 1306080
       Buffer I/O error on device hdc, logical block 163260
       Buffer I/O error on device hdc, logical block 163261
       Buffer I/O error on device hdc, logical block 163262
      
      the unpatched kernel produces an incorrect error dump:
      
       hdc: command error: status=0x51 { DriveReady SeekComplete Error }
       hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
       ide: failed opcode was: unknown
       end_request: I/O error, dev hdc, sector 1306080
       Buffer I/O error on device hdc, logical block 163260
       hdc: command error: status=0x51 { DriveReady SeekComplete Error }
       hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
       ide: failed opcode was: unknown
       end_request: I/O error, dev hdc, sector 1306088
       Buffer I/O error on device hdc, logical block 163261
       hdc: command error: status=0x51 { DriveReady SeekComplete Error }
       hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
       ide: failed opcode was: unknown
       end_request: I/O error, dev hdc, sector 1306096
       Buffer I/O error on device hdc, logical block 163262
      
      I do not have the right type of CD-ROM drive to reproduce the end-of-media
      data corruption bug myself, but this same patch in RHEL solved it.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
      Cc: Jens Axboe <axboe@suse.de>
      Cc: Matt Mackall <mpm@selenic.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      dbe217af
    • D
      [PATCH] idetape gcc 4.1 warning fix · dcd96379
      Daniel Walker 提交于
      In both the read and write cases it will return an error if
      copy_{from/to}_user faults.  However, I let the driver try to read/write as
      much as it can just as it normally would , then finally it returns an error
      if there was one.  This was the most straight forward way to handle the
      error , since there isn't a clear way to clean up the buffers on error .
      
      I moved retval in idetape_chrdev_write() down into the actual code blocks
      since it's really once used there, and it conflicted with my ret variable.
      
      Fixes the following warning,
      
      drivers/ide/ide-tape.c: In function ‘idetape_copy_stage_from_user’:
      drivers/ide/ide-tape.c:2662: warning: ignoring return value of ‘copy_from_user’, declared with attribute warn_unused_result
      drivers/ide/ide-tape.c: In function ‘idetape_copy_stage_to_user’:
      drivers/ide/ide-tape.c:2689: warning: ignoring return value of ‘copy_to_user’, declared with attribute warn_unused_result
      Signed-off-by: NDaniel Walker <dwalker@mvista.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      dcd96379
  6. 23 6月, 2006 5 次提交
  7. 20 6月, 2006 1 次提交
    • D
      [SPARC]: Kill __irq_itoa(). · c6387a48
      David S. Miller 提交于
      This ugly hack was long overdue to die.
      
      It was a way to print out Sparc interrupts in a more freindly format,
      since IRQ numbers were arbitrary opaque 32-bit integers which vectored
      into PIL levels.  These 32-bit integers were not necessarily in the
      0-->NR_IRQS range, but the PILs they vectored to were.
      
      The idea now is that we will increase NR_IRQS a little bit and use a
      virtual<-->real IRQ number mapping scheme similar to PowerPC.
      
      That makes this IRQ printing hack irrelevant, and furthermore only a
      handful of drivers actually used __irq_itoa() making it even less
      useful.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c6387a48
  8. 01 6月, 2006 1 次提交
    • J
      [PATCH] sgiioc4: use mmio ops instead of port io · a835fa79
      Jeremy Higdon 提交于
      From: Jeremy Higdon <jeremy@sgi.com>
      
      This patch fixes a bug in sgiioc4 where it was using the default IDE port
      I/O operations instead of MMIO.
      
      The IDE part of the IOC4 chip uses MMIO to map the chip registers.
      Unfortunately, the sgiioc4 driver uses the default port IO operations,
      which happens to have worked for the past few years.  That's about to
      change, however, thus this change from inX/outX to readX/writeX.
      Signed-off-by: NJeremy Higdon <jeremy@sgi.com>
      Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a835fa79
  9. 24 5月, 2006 1 次提交
  10. 22 5月, 2006 1 次提交
  11. 16 5月, 2006 1 次提交
  12. 20 4月, 2006 3 次提交
  13. 01 4月, 2006 2 次提交
  14. 31 3月, 2006 1 次提交