1. 05 12月, 2008 1 次提交
  2. 04 12月, 2008 7 次提交
    • U
      netx-eth: initialize per device spinlock · 2cc002c4
      Uwe Kleine-König 提交于
      The spinlock used in the netx-eth driver was never properly initialized.
      This was noticed using CONFIG_DEBUG_SPINLOCK=y
      Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2cc002c4
    • I
      tcp: make urg+gso work for real this time · f8269a49
      Ilpo Järvinen 提交于
      I should have noticed this earlier... :-) The previous solution
      to URG+GSO/TSO will cause SACK block tcp_fragment to do zig-zig
      patterns, or even worse, a steep downward slope into packet
      counting because each skb pcount would be truncated to pcount
      of 2 and then the following fragments of the later portion would
      restore the window again.
      
      Basically this reverts "tcp: Do not use TSO/GSO when there is
      urgent data" (33cf71ce). It also removes some unnecessary code
      from tcp_current_mss that didn't work as intented either (could
      be that something was changed down the road, or it might have
      been broken since the dawn of time) because it only works once
      urg is already written while this bug shows up starting from
      ~64k before the urg point.
      
      The retransmissions already are split to mss sized chunks, so
      only new data sending paths need splitting in case they have
      a segment otherwise suitable for gso/tso. The actually check
      can be improved to be more narrow but since this is late -rc
      already, I'll postpone thinking the more fine-grained things.
      Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f8269a49
    • B
      enc28j60: Fix sporadic packet loss (corrected again) · 5176da7e
      Baruch Siach 提交于
      Packet data read from the RX buffer the when the RSV is at the end of the RX
      buffer does not warp around. This causes packet loss, as the actual data is
      never read. Fix this by calculating the right packet data location.
      
      Thanks to Shachar Shemesh for suggesting the fix.
      Signed-off-by: NBaruch Siach <baruch@tkos.co.il>
      Acked-by: NClaudio Lanconelli <lanconelli.claudio@eptar.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5176da7e
    • P
      hysdn: fix writing outside the field on 64 bits · bd091410
      Pascal Terjan 提交于
      ifa_local is assumed to be unsigned long which lead to writing the address
      at dev->dev_addr-2 instead of +2
      
      noticed thanks to gcc:
      
      drivers/isdn/hysdn/hysdn_net.c: In function `net_open':
      drivers/isdn/hysdn/hysdn_net.c:91: warning: array subscript is below array bounds
      Signed-off-by: NPascal Terjan <pterjan@mandriva.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bd091410
    • W
      b1isa: fix b1isa_exit() to really remove registered capi controllers · 1c594c05
      Wilfried Klaebe 提交于
      On "/etc/init.d/capiutils stop", this oops happened.
      
      The oops happens on reading /proc/capi/controllers because
      capi_ctrl->procinfo is called for the wrongly not unregistered
      controller, which points to b1isa_procinfo(), which was removed on
      module unload.
      
      b1isa_exit() did not call b1isa_remove() for its controllers because
      io[0] == 0 on module unload despite having been 0x340 on module load.
      
      Besides, just removing the controllers that where added on module
      load time and not those that were added later via b1isa_add_card() is
      wrong too - the place where all added cards are found is isa_dev[].
      
      relevant dmesg lines:
      
      [    0.000000] Linux version 2.6.27.4 (w@shubashi) (gcc version 4.3.2 (Debian 4.3.2-1) ) #3 Thu Oct 30 16:49:03 CET 2008
      
      [   67.403555] CAPI Subsystem Rev 1.1.2.8
      [   68.529154] capifs: Rev 1.1.2.3
      [   68.563292] capi20: Rev 1.1.2.7: started up with major 68 (middleware+capifs)
      [   77.026936] b1: revision 1.1.2.2
      [   77.049992] b1isa: revision 1.1.2.3
      [   77.722655] kcapi: Controller [001]: b1isa-340 attached
      [   77.722671] b1isa: AVM B1 ISA at i/o 0x340, irq 5, revision 255
      [   81.272669] b1isa-340: card 1 "B1" ready.
      [   81.272683] b1isa-340: card 1 Protocol: DSS1
      [   81.272689] b1isa-340: card 1 Linetype: point to multipoint
      [   81.272695] b1isa-340: B1-card (3.11-03) now active
      [   81.272702] kcapi: card [001] "b1isa-340" ready.
      
      [  153.721281] kcapi: card [001] down.
      [  154.151889] BUG: unable to handle kernel paging request at e87af000
      [  154.152081] IP: [<e87af000>]
      [  154.153292] *pde = 2655b067 *pte = 00000000
      [  154.153307] Oops: 0000 [#1]
      [  154.153360] Modules linked in: rfcomm l2cap ppdev lp ipt_MASQUERADE tun capi capifs kernelcapi ac battery nfsd exportfs nfs lockd nfs_acl sunrpc sit tunnel4 bridge stp llc ipt_REJECT ipt_LOG xt_tcpudp xt_state iptable_filter iptable_mangle iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack ip_tables x_tables nls_utf8 isofs nls_base zlib_inflate loop ipv6 netconsole snd_via82xx dvb_usb_dib0700 gameport dib7000p dib7000m dvb_usb snd_ac97_codec ac97_bus dvb_core mt2266 snd_pcm tuner_xc2028 dib3000mc dibx000_common mt2060 dib0070 snd_page_alloc snd_mpu401_uart snd_seq_midi snd_seq_midi_event btusb snd_rawmidi bluetooth snd_seq snd_timer snd_seq_device snd via686a i2c_viapro soundcore i2c_core parport_pc parport button dm_mirror dm_log dm_snapshot floppy sg ohci1394 uhci_hcd ehci_hcd 8139too mii ieee1394 usbcore sr_mod cdrom sd_mod thermal processor fan [last unloaded: b1]
      [  154.153360]
      [  154.153360] Pid: 4132, comm: capiinit Not tainted (2.6.27.4 #3)
      [  154.153360] EIP: 0060:[<e87af000>] EFLAGS: 00010286 CPU: 0
      [  154.153360] EIP is at 0xe87af000
      [  154.153360] EAX: e6b9ccc8 EBX: e6b9ccc8 ECX: e87a0c67 EDX: e87af000
      [  154.153360] ESI: e142bbc0 EDI: e87a56e0 EBP: e0505f0c ESP: e0505ee4
      [  154.153360]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
      [  154.153360] Process capiinit (pid: 4132, ti=e0504000 task=d1196cf0 task.ti=e0504000)
      [  154.153360] Stack: e879f650 00000246 e0505ef4 c01472eb e0505f0c 00000246 e7001780 fffffff4
      [  154.153360]        fffffff4 e142bbc0 e0505f48 c01a56c6 00000400 b805e000 d102dc80 e142bbe0
      [  154.153360]        00000000 e87a56e0 00000246 e12617ac 00000000 00000000 e1261760 fffffffb
      [  154.153360] Call Trace:
      [  154.153360]  [<e879f650>] ? controller_show+0x20/0x90 [kernelcapi]
      [  154.153360]  [<c01472eb>] ? trace_hardirqs_on+0xb/0x10
      [  154.153360]  [<c01a56c6>] ? seq_read+0x126/0x2f0
      [  154.153360]  [<c01a55a0>] ? seq_read+0x0/0x2f0
      [  154.153360]  [<c01c033c>] ? proc_reg_read+0x5c/0x90
      [  154.153360]  [<c0189919>] ? vfs_read+0x99/0x140
      [  154.153360]  [<c01c02e0>] ? proc_reg_read+0x0/0x90
      [  154.153360]  [<c0189a7d>] ? sys_read+0x3d/0x70
      [  154.153360]  [<c0103c3d>] ? sysenter_do_call+0x12/0x35
      [  154.153360]  =======================
      [  154.153360] Code:  Bad EIP value.
      [  154.153360] EIP: [<e87af000>] 0xe87af000 SS:ESP 0068:e0505ee4
      [  154.153360] ---[ end trace 23750b6c2862de94 ]---
      Signed-off-by: NWilfried Klaebe <linux-kernel@lebenslange-mailadresse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Acked-by: NKarsten Keil <kkeil@suse.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1c594c05
    • O
      can: Fix CAN_(EFF|RTR)_FLAG handling in can_filter · d253eee2
      Oliver Hartkopp 提交于
      Due to a wrong safety check in af_can.c it was not possible to filter
      for SFF frames with a specific CAN identifier without getting the
      same selected CAN identifier from a received EFF frame also.
      
      This fix has a minimum (but user visible) impact on the CAN filter
      API and therefore the CAN version is set to a new date.
      
      Indeed the 'old' API is still working as-is. But when now setting
      CAN_(EFF|RTR)_FLAG in can_filter.can_mask you might get less traffic
      than before - but still the stuff that you expected to get for your
      defined filter ...
      
      Thanks to Kurt Van Dijck for pointing at this issue and for the review.
      Signed-off-by: NOliver Hartkopp <oliver@hartkopp.net>
      Acked-by: NKurt Van Dijck <kurt.van.dijck@eia.be>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d253eee2
    • R
  3. 03 12月, 2008 26 次提交
  4. 02 12月, 2008 6 次提交
    • L
      Linux 2.6.28-rc7 · 061e41fd
      Linus Torvalds 提交于
      061e41fd
    • L
      Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6 · 0d815142
      Linus Torvalds 提交于
      * 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6: (25 commits)
        em28xx: remove backward compat macro added on a previous fix
        V4L/DVB (9748): em28xx: fix compile warning
        V4L/DVB (9743): em28xx: fix oops audio
        V4L/DVB (9742): em28xx-alsa: implement another locking schema
        V4L/DVB (9732): sms1xxx: use new firmware for Hauppauge WinTV MiniStick
        V4L/DVB (9691): gspca: Move the video device to a separate area.
        V4L/DVB (9690): gspca: Lock the subdrivers via module_get/put.
        V4L/DVB (9689): gspca: Memory leak when disconnect while streaming.
        V4L/DVB (9668): em28xx: fix a race condition with hald
        V4L/DVB (9664): af9015: don't reconnect device in USB-bus
        V4L/DVB (9647): em28xx: void having two concurrent control URB's
        V4L/DVB (9646): em28xx: avoid allocating/dealocating memory on every control urb
        V4L/DVB (9645): em28xx: Avoid memory leaks if registration fails
        V4L/DVB (9639): Make dib0700 remote control support work with firmware v1.20
        V4L/DVB (9635): v4l: s2255drv fix firmware test on big-endian
        V4L/DVB (9634): Make sure the i2c gate is open before powering down tuner
        V4L/DVB (9632): make em28xx aux audio input work
        V4L/DVB (9631): Make s2api work for ATSC support
        V4L/DVB (9627): em28xx: Avoid i2c register error for boards without eeprom
        V4L/DVB (9608): Fix section mismatch warning for dm1105 during make
        ...
      0d815142
    • A
      drivers/gpu/drm/i915/i915_irq.c: fix warning · 9c84ba4e
      Andrew Morton 提交于
      drivers/gpu/drm/i915/i915_irq.c: In function 'i915_disable_pipestat':
      drivers/gpu/drm/i915/i915_irq.c:101: warning: control may reach end of non-void function 'i915_pipestat' being inlined
      
      Cc: Dave Airlie <airlied@linux.ie>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9c84ba4e
    • J
      i82875p_edac: fix module remove · 09a81269
      Jarkko Lavinen 提交于
      Fix module removal bugs of i82875p_edac.  Also i82975x_edac code seems to
      have the same module removal bugs as in i82875p_edac.
      
      The problems were:
      
      1. In module removal i82875p_remove_one() is never called.
      
         Variable i82875p_registered is newer changed from 1, which
         guarantees i82875p_remove_one() is not called (and even if it were
         called, it would be called in wrong order).
      
         As a result, the edac_mc workque is not stopped and keeps probing.
         If kernel debugging options are not enabled, user may not notice
         anything going wrong.
      
         if debugging options are enabled and I do "rmmod i82875p_edac", I
         get:
      
            edac debug: edac_pci_workq_function() checking
            BUG: unable to handle kernel paging request at f882d16f
            ...
            call trace:
             [<f8834df3>] ? edac_mc_workq_function+0x55/0x7e [edac_core]
             [<c0233974>] ? run_workqueue+0xd7/0x1a5
             [<c023392f>] ? run_workqueue+0x92/0x1a5
             [<f8834d9e>] ? edac_mc_workq_function+0x0/0x7e [edac_core]
             [<c0233af9>] ? worker_thread+0xb7/0xc3
             [<c0236a7b>] ? autoremove_wake_function+0x0/0x33
             [<c0233a42>] ? worker_thread+0x0/0xc3
             [<c0236809>] ? kthread+0x3b/0x61
             [<c02367ce>] ? kthread+0x0/0x61
             [<c0204587>] ? kernel_thread_helper+0x7/0x10
      
         Fix for this is to get rid of needles variable i82875p_registered
         altogether and run i82875p_remove_one() *before*
         pci_unregister_driver().
      
      2. edac_mc_del_mc() uses mci after freeing mci
      
         edac_mc_del_mc() calls calls edac_remove_sysfs_mci_device().  The
         kobject refcount of mci drops to 0 and mci is freed.  After this
         mci is accessed via debug print and i82875p_remove_one() still
         uses mci->pvt and tries to free mci again with edac_mc_free().
      
         The fix for this is add kobject_get(&mci->edac_mci_kobj) after
         edac_mc_alloc(). Then the mci is still available after returning
         from edac_mc_del_mc() with refcount 1, and mci->pvt is still
         available. When i82875p_remove_one() finally calls edac_mc_free(),
         this will cause kobject_put() and mci is released properly.
      Signed-off-by: NJarkko Lavinen <jlavi@iki.fi>
      Cc: Doug Thompson <norsk5@yahoo.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      09a81269
    • J
      i82875p_edac: fix overflow device resource setup · 307d1144
      Jarkko Lavinen 提交于
      When I do "modprobe i82875p_edac" on my Asus P4C800 MB on kernels 2.6.26
      or later, the module load fails due to BAR 0 collision.  On 2.6.25 the
      module loads just fine.
      
      The overflow device on the MB seems to be hidden and its resources are not
      allocated at normal PCI bus init.  Log shows the missing resource problem:
      
        EDAC DEBUG: i82875p_probe1()
        PCI: 0000:00:06.0 reg 10 32bit mmio: [fecf0000, fecf0fff]
        pci 0000:00:06.0: device not available because of BAR 0
      [0xfecf0000-0xfecf0fff] collisions
        EDAC i82875p: i82875p_setup_overfl_dev(): Failed to enable overflow
      device
      
      The patch below fixes this by calling pci_bus_assign_resources() after
      the overflow device is revealed and added to the bus. With this patch
      I am again able to load and use the module.
      Signed-off-by: NJarkko Lavinen <jlavi@iki.fi>
      Cc: Doug Thompson <norsk5@yahoo.com>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      307d1144
    • D
      fbdev: fix FB console blanking · bca404af
      Dmitry Baryshkov 提交于
      The commit aef7db4b fixed the problem with
      recursive locking in fb blanking code if blank is caused by user setting
      the /sys/class/graphics/fb*/blank.  However this broke the fbcon timeout
      blanking.
      
      If you use a driver that defines ->fb_blank operation and at the same time
      that driver relies on other driver (e.g.  backlight or lcd class) to blank
      the screen, when the fbcon times out and tries to blank the fb, it will
      call only fb driver blanker and won't notify the other driver.  Thus FB
      output is disabled, but the screen isn't blanked.
      
      Restore fbcon blanking and at the same time apply the proper fix for the
      above problem: if fbcon_blank is called with FBINFO_FLAG_USEREVENT, we are
      already called through notification from fb_blank, thus we don't have to
      blank the fb again.
      Signed-off-by: NDmitry Baryshkov <dbaryshkov@gmail.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bca404af