1. 20 Aug, 2008 19 commits
    • Andre Schenk's avatar
      USB: ftdi_sio: Add USB Product Id for ELV HS485 · 6191b186
      Andre Schenk authored
      commit b5894a50 upstream
      
      USB product id registration for the ELV HS485 USB adapter (www.elv.de) to
      their home automation bus system. Applies to 2.6.26.
      Signed-off-by: default avatarAndre Schenk <andre@melior.s.bawue.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      6191b186
    • Frederik Kriewitz's avatar
      USB: ftdi_sio: add support for Luminance Stellaris Evaluation/Development Kits · 6f035e79
      Frederik Kriewitz authored
      commit a00c3cad upstream
      
      The Patch adds support for Luminance Stellaris Evaluation/Development
      Kits (FTDI 2232C based).
      The PIDs were missing.
      
      Successfully tested with a Stellaris LM3S8962 Evaluation kit.
      Signed-off-by: default avatarFrederik Kriewitz <frederik@kriewitz.eu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      6f035e79
    • Alan Stern's avatar
      usb-serial: don't release unregistered minors · bb457a98
      Alan Stern authored
      commit 0282b7f2 upstream
      
      This patch (as1121) fixes a bug in the USB serial core.  When a device
      is unregistered, the core will give back its minors -- even if the
      device hasn't been assigned any!
      
      The patch reserves the highest minor value (255) to mean that no minor
      was assigned.  It also removes some dead code and does a small style
      fixup.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      bb457a98
    • Dave Jones's avatar
      USB: usb-storage: quirk around v1.11 firmware on Nikon D4 · 092634b6
      Dave Jones authored
      commit b9a097f2 upstream
      
      usb-storage: quirk around v1.11 firmware on Nikon D40
      
      https://bugzilla.redhat.com/show_bug.cgi?id=454028
      Just as in earlier firmware versions, we need to perform this
      quirk for the latest version too.
      
      Speculatively do the entry for the D80 too, as they seem to
      have the same firmware problems historically.
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      092634b6
    • Alan Stern's avatar
      usb-storage: unusual_devs entries for iRiver T10 and Datafab CF+SM reader · 5f8cce5f
      Alan Stern authored
      commit 368ee646 upstream
      
      This patch (as1115) adds unusual_devs entries with the IGNORE_RESIDE
      flag for the iRiver T10 and the Simple Tech/Datafab CF+SM card
      reader.  Apparently these devices provide reasonable residue values
      for READ and WRITE operations, but not for others like INQUIRY or READ
      CAPACITY.
      
      This fixes the iRiver T10 problem reported in Bugzilla #11125.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      5f8cce5f
    • Alan Stern's avatar
      USB: fix interface unregistration logic · 6fc7a3db
      Alan Stern authored
      commit 1a21175a upstream
      
      
      This patch (as1122) fixes a bug: When an interface is unregistered,
      its children (sysfs files and endpoint devices) are unregistered after
      it instead of before.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Tested-by: default avatarKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      6fc7a3db
    • Tollef Fog Heen's avatar
      USB: pl2023: Remove USB id (4348:5523) handled by ch341 · 18480457
      Tollef Fog Heen authored
      commit 8c809681 upstream
      
      USB ID 4348:5523 is handled by the ch341 driver.  Remove it from the
      pl2023 driver.
      
      Reverts 002e8f2c.
      Signed-off-by: default avatarTollef Fog Heen <tfheen@err.no>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      18480457
    • Jean Delvare's avatar
      matrox maven: fix a broken error path · 8226ee76
      Jean Delvare authored
      commit 5ede40f8 upstream
      
      I broke an error path with d03c21ec,
      sorry about that.
      
      The machine will crash if the i2c_attach_client() or maven_init_client()
      calls fail, although nobody has yet reported this happening.
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      Acked-by: default avatarKrzysztof Helt <krzysztof.h1@wp.pl>
      Cc: Petr Vandrovec <VANDROVE@vc.cvut.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      8226ee76
    • David Miller's avatar
      radeonfb: fix accel engine hangs · 1a71e43a
      David Miller authored
      commit 969830b2 upstream
      
      Some chips appear to have the 2D engine hang during screen redraw,
      typically in a sequence of copyarea operations. This appear to be
      solved by adding a flush of the engine destination pixel cache
      and waiting for the engine to be idle before issuing the accel
      operation. The performance impact seems to be fairly small.
      
      Here is a trace on an RV370 (PCI device ID 0x5b64), it records the
      RBBM_STATUS register, then the source x/y, destination x/y, and
      width/height used for the copy:
      
      ----------------------------------------
      radeonfb_prim_copyarea: STATUS[00000140] src[210:70] dst[210:60] wh[a0:10]
      radeonfb_prim_copyarea: STATUS[00000140] src[2b8:70] dst[2b8:60] wh[88:10]
      radeonfb_prim_copyarea: STATUS[00000140] src[348:70] dst[348:60] wh[40:10]
      radeonfb_prim_copyarea: STATUS[80020140] src[390:70] dst[390:60] wh[88:10]
      radeonfb_prim_copyarea: STATUS[8002613f] src[40:80] dst[40:70] wh[28:10]
      radeonfb_prim_copyarea: STATUS[80026139] src[a8:80] dst[a8:70] wh[38:10]
      radeonfb_prim_copyarea: STATUS[80026133] src[e8:80] dst[e8:70] wh[80:10]
      radeonfb_prim_copyarea: STATUS[8002612d] src[170:80] dst[170:70] wh[30:10]
      radeonfb_prim_copyarea: STATUS[80026127] src[1a8:80] dst[1a8:70] wh[8:10]
      radeonfb_prim_copyarea: STATUS[80026121] src[1b8:80] dst[1b8:70] wh[88:10]
      radeonfb_prim_copyarea: STATUS[8002611b] src[248:80] dst[248:70] wh[68:10]
      ----------------------------------------
      
      When things are going fine the copies complete before the next ROP is
      even issued, but all of a sudden the 2D unit becomes active (bit 17 in
      RBBM_STATUS) and the FIFO retry (bit 13) and FIFO pipeline busy (bit
      14) are set as well.  The FIFO begins to backup until it becomes full.
      
      What happens next is the radeon_fifo_wait() times out, and we access
      the chip illegally leading to a bus error which usually wedges the
      box.  None of this makes it to the console screen, of course :-)
      radeon_fifo_wait() should be modified to reset the accelerator when
      this timeout happens instead of programming the chip anyways.
      
      ----------------------------------------
      radeonfb: FIFO Timeout !
      ERROR(0): Cheetah error trap taken afsr[0010080005000000] afar[000007f900800e40] TL1(0)
      ERROR(0): TPC[595114] TNPC[595118] O7[459788] TSTATE[11009601]
      ERROR(0): TPC<radeonfb_copyarea+0xfc/0x248>
      ERROR(0): M_SYND(0),  E_SYND(0), Privileged
      ERROR(0): Highest priority error (0000080000000000) "Bus error response from system bus"
      ERROR(0): D-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000]
      ERROR(0): D-cache data0[0000000000000000] data1[0000000000000000] data2[0000000000000000] data3[0000000000000000]
      ERROR(0): I-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000] u[0000000000000000] l[00\
      
      ERROR(0): I-cache INSN0[0000000000000000] INSN1[0000000000000000] INSN2[0000000000000000] INSN3[0000000000000000]
      ERROR(0): I-cache INSN4[0000000000000000] INSN5[0000000000000000] INSN6[0000000000000000] INSN7[0000000000000000]
      ERROR(0): E-cache idx[800e40] tag[000000000e049f4c]
      ERROR(0): E-cache data0[fffff8127d300180] data1[00000000004b5384] data2[0000000000000000] data3[0000000000000000]
      Ker:xnel panic - not syncing: Irrecoverable deferred error trap.
      ----------------------------------------
      
      Another quirk is that these copyarea calls will not happen until the
      first drivers/char/vt.c:redraw_screen() occurs.  This will only happen
      if you 1) VC switch or 2) run "consolechars" or 3) unblank the screen.
      
      This seems to happen because until a redraw_screen() the screen scrolling
      method used by fbcon is not finalized yet.  I've seen this with other fb
      drivers too.
      
      So if all you do is boot straight into X you will never see this bug on
      the relevant chips.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      1a71e43a
    • Oleg Nesterov's avatar
      posix-timers: fix posix_timer_event() vs dequeue_signal() race · 24bad46e
      Oleg Nesterov authored
      commit ba661292 upstream
      
      The bug was reported and analysed by Mark McLoughlin <markmc@redhat.com>,
      the patch is based on his and Roland's suggestions.
      
      posix_timer_event() always rewrites the pre-allocated siginfo before sending
      the signal. Most of the written info is the same all the time, but memset(0)
      is very wrong. If ->sigq is queued we can race with collect_signal() which
      can fail to find this siginfo looking at .si_signo, or copy_siginfo() can
      copy the wrong .si_code/si_tid/etc.
      
      In short, sys_timer_settime() can in fact stop the active timer, or the user
      can receive the siginfo with the wrong .si_xxx values.
      
      Move "memset(->info, 0)" from posix_timer_event() to alloc_posix_timer(),
      change send_sigqueue() to set .si_overrun = 0 when ->sigq is not queued.
      It would be nice to move the whole sigq->info initialization from send to
      create path, but this is not easy to do without uglifying timer_create()
      further.
      
      As Roland rightly pointed out, we need more cleanups/fixes here, see the
      "FIXME" comment in the patch. Hopefully this patch makes sense anyway, and
      it can mask the most bad implications.
      Reported-by: default avatarMark McLoughlin <markmc@redhat.com>
      Signed-off-by: default avatarOleg Nesterov <oleg@tv-sign.ru>
      Cc: Mark McLoughlin <markmc@redhat.com>
      Cc: Oliver Pinter <oliver.pntr@gmail.com>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      24bad46e
    • Oleg Nesterov's avatar
      posix-timers: do_schedule_next_timer: fix the setting of ->si_overrun · 88be1c98
      Oleg Nesterov authored
      commit 54da1174 upstream
      
      do_schedule_next_timer() sets info->si_overrun = timr->it_overrun_last,
      this discards the already accumulated overruns.
      Signed-off-by: default avatarOleg Nesterov <oleg@tv-sign.ru>
      Cc: Mark McLoughlin <markmc@redhat.com>
      Cc: Oliver Pinter <oliver.pntr@gmail.com>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      88be1c98
    • Petr Tesarik's avatar
      ide-cd: fix endianity for the error message in cdrom_read_capacity · 0c920358
      Petr Tesarik authored
      commit 938bb03d uptream
      
      Aesthetic regards aside, commit e8e7b9eb
      still leaves a bug in the error message, because it uses the unconverted
      big-endian value for printk.
      
      Fix this by using a local variable in machine byte order. The result is
      correct, more readable, and also produces slightly shorter code on i386.
      Signed-off-by: default avatarPetr Tesarik <ptesarik@suse.cz>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: <stable@kernel.org>
      Acked-by: default avatarBorislav Petkov <petkovbb@gmail.com>
      [bart: __u32 -> u32]
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      0c920358
    • Tom Zanussi's avatar
      relay: fix "full buffer with exactly full last subbuffer" accounting problem · d6d033c7
      Tom Zanussi authored
      commit 32194450 upstream
      
      In relay's current read implementation, if the buffer is completely full
      but hasn't triggered the buffer-full condition (i.e. the last write
      didn't cross the subbuffer boundary) and the last subbuffer is exactly
      full, the subbuffer accounting code erroneously finds nothing available.
      This patch fixes the problem.
      Signed-off-by: default avatarTom Zanussi <tzanussi@gmail.com>
      Cc: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Cc: Mathieu Desnoyers <compudj@krystal.dyndns.org>
      Cc: Andrea Righi <righi.andrea@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      d6d033c7
    • Ondrej Zajicek's avatar
      vt8623fb: fix kernel oops · 1d1150e2
      Ondrej Zajicek authored
      commit 594a8819 upstream
      
      commit 20e061fb
        Author: Ondrej Zajicek <santiago@crfreenet.org>
        Date:   Mon Apr 28 02:15:18 2008 -0700
      
            fbdev: framebuffer_alloc() fixes
      
            Correct the dev arg of framebuffer_alloc() in arkfb, s3fb and vt8623fb.
      
      causes a null-pointer deref because "info->dev is NULL, info was just
      kzallocated".
      Signed-off-by: default avatarOndrej Zajicek <santiago@crfreenet.org>
      Reported-by: default avatar"MadLoisae@gmx.net" <MadLoisae@gmx.net>
      Tested-by: default avatar"MadLoisae@gmx.net" <MadLoisae@gmx.net>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      1d1150e2
    • HighPoint Linux Team's avatar
      SCSI: hptiop: add more PCI device IDs · cdc884a8
      HighPoint Linux Team authored
      commit dd07428b upstream
      
      Add PCI device ID for new adapter models.
      Signed-off-by: default avatarHighPoint Linux Team <linux@highpoint-tech.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      cdc884a8
    • Tim Wright's avatar
      SCSI: block: Fix miscalculation of sg_io timeout in CDROM_SEND_PACKET handler. · 5290b82b
      Tim Wright authored
      commit ad337591 upstream
      
      It seems cdrwtool in the udftools has been unusable on "modern" kernels
      for some time. A Google search reveals many people with the same issue
      but no solution (cdrwtool fails to format the disk). After spending some
      time tracking down the issue, it comes down to the following:
      
      The udftools still use the older CDROM_SEND_PACKET interface to send
      things like FORMAT_UNIT through to the drive. They should really be
      updated, but that's another story. Since most distros are using libata
      now, the cd or dvd burner appears as a SCSI device, and we wind up in
      block/scsi_ioctl.c. Here, the code tries to take the "struct
      cdrom_generic_command" and translate it and stuff it into a "struct
      sg_io_hdr" structure so it can pass it to the modern sg_io() routine
      instead. Unfortunately, there is one error, or rather an omission in the
      translation. The timeout that is passed in in the "struct
      cdrom_generic_command" is in HZ=100 units, and this is modified and
      correctly converted to jiffies by use of clock_t_to_jiffies(). However,
      a little further down, this cgc.timeout value in jiffies is simply
      copied into the sg_io_hdr timeout, which should be in milliseconds.
      Since most modern x86 kernels seems to be getting build with HZ=250, the
      timeout that is passed to sg_io and eventually converted to the
      timeout_per_command member of the scsi_cmnd structure is now four times
      too small. Since cdrwtool tries to set the timeout to one hour for the
      FORMAT_UNIT command, and it takes about 20 minutes to format a 4x CDRW,
      the SCSI error-handler kicks in after the FORMAT_UNIT completes because
      it took longer than the incorrectly-calculated timeout.
      
      [jejb: fix up whitespace]
      Signed-off-by: default avatarTim Wright <timw@splhi.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      5290b82b
    • James Bottomley's avatar
      SCSI: scsi_transport_spi: fix oops in revalidate · e957c8b1
      James Bottomley authored
      commit e8bac9e0 upstream
      
      The class_device->device conversion is causing an oops in revalidate
      because it's assuming that the device_for_each_child iterator will only
      return struct scsi_device children.  The conversion made all former
      class_devices children of the device as well, so this assumption is
      broken.  Fix it.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      e957c8b1
    • James Bottomley's avatar
      SCSI: ses: fix VPD inquiry overrun · e563ea63
      James Bottomley authored
      commit 671a99c8 upstream
      
      There are a few kerneloops.org reports like this one:
      
      http://www.kerneloops.org/search.php?search=ses_match_to_enclosure
      
      That seem to imply we're running off the end of the VPD inquiry data
      (although at 512 bytes, it should be long enough for just about
      anything).  we should be using correctly sized buffers anyway, so put
      those in and hope this oops goes away.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      e563ea63
    • KOSAKI Motohiro's avatar
      mlock() fix return values · 84d21376
      KOSAKI Motohiro authored
      commit a477097d upstream
      
      Halesh says:
      
      Please find the below testcase provide to test mlock.
      
      Test Case :
      ===========================
      
      #include <sys/resource.h>
      #include <stdio.h>
      #include <sys/stat.h>
      #include <sys/types.h>
      #include <unistd.h>
      #include <sys/mman.h>
      #include <fcntl.h>
      #include <errno.h>
      #include <stdlib.h>
      
      int main(void)
      {
        int fd,ret, i = 0;
        char *addr, *addr1 = NULL;
        unsigned int page_size;
        struct rlimit rlim;
      
        if (0 != geteuid())
        {
         printf("Execute this pgm as root\n");
         exit(1);
        }
      
        /* create a file */
        if ((fd = open("mmap_test.c",O_RDWR|O_CREAT,0755)) == -1)
        {
         printf("cant create test file\n");
         exit(1);
        }
      
        page_size = sysconf(_SC_PAGE_SIZE);
      
        /* set the MEMLOCK limit */
        rlim.rlim_cur = 2000;
        rlim.rlim_max = 2000;
      
        if ((ret = setrlimit(RLIMIT_MEMLOCK,&rlim)) != 0)
        {
         printf("Cant change limit values\n");
         exit(1);
        }
      
        addr = 0;
        while (1)
        {
        /* map a page into memory each time*/
        if ((addr = (char *) mmap(addr,page_size, PROT_READ |
      PROT_WRITE,MAP_SHARED,fd,0)) == MAP_FAILED)
        {
         printf("cant do mmap on file\n");
         exit(1);
        }
      
        if (0 == i)
          addr1 = addr;
        i++;
        errno = 0;
        /* lock the mapped memory pagewise*/
        if ((ret = mlock((char *)addr, 1500)) == -1)
        {
         printf("errno value is %d\n", errno);
         printf("cant lock maped region\n");
         exit(1);
        }
        addr = addr + page_size;
       }
      }
      ======================================================
      
      This testcase results in an mlock() failure with errno 14 that is EFAULT,
      but it has nowhere been specified that mlock() will return EFAULT.  When I
      tested the same on older kernels like 2.6.18, I got the correct result i.e
      errno 12 (ENOMEM).
      
      I think in source code mlock(2), setting errno ENOMEM has been missed in
      do_mlock() , on mlock_fixup() failure.
      
      SUSv3 requires the following behavior frmo mlock(2).
      
      [ENOMEM]
          Some or all of the address range specified by the addr and
          len arguments does not correspond to valid mapped pages
          in the address space of the process.
      
      [EAGAIN]
          Some or all of the memory identified by the operation could not
          be locked when the call was made.
      
      This rule isn't so nice and slighly strange.  but many people think
      POSIX/SUS compliance is important.
      Reported-by: default avatarHalesh Sadashiv <halesh.sadashiv@ap.sony.com>
      Tested-by: default avatarHalesh Sadashiv <halesh.sadashiv@ap.sony.com>
      Signed-off-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      84d21376
  2. 06 Aug, 2008 21 commits