Skip to content

L
linux
Switch branch/tag
  1. 20 Dec, 2007 5 commits
    • Al Viro's avatar
      [TG3]: Endianness bugfix. · 286e310f
      Al Viro authored 
      tg3_nvram_write_block_unbuffered() is reading data from nvram into
allocated buffer before overwriting a part of it with user-supplied
data.  Then it feeds the entire page back to nvram.  It should be
storing the words it had read as little-endian, not as host-endian.
Note that tg3_set_eeprom() does exactly that for padding the same
data to full words before it gets passed down to tg3_nvram_write_block()
and then to tg3_nvram_write_block_unbuffered().

Moreover, when we get to sending the entire thing back to nvram, we
go through it word-by-word, doing essentially
	writel(swab32(le32_to_cpu(word)), ...)
so if we want them to reach the card in host-independent endianness,
we'd better really have all that buffer filled with fixed-endian.
For user-supplied part we obviously do have that (it's an array of
octets memcpy'd in), ditto for padding of user-supplied part to word
boundaries (taken care of in tg3_set_eeprom()).  The rest of the
buffer gets filled by tg3_nvram_write_block_unbuffered() and it would
damn better be consistent with that (and with tg3_get_eeprom(), while
we are at it - there we also convert the words read from nvram to
little-endian before returning the buffer to user).

The bug should get triggered on big-endian boxen when set_eeprom is done
for less than entire page.  Then the words that should've been unaffected
at all will actually get byteswapped in place in nvram.
Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      286e310f
    • Al Viro's avatar
      [TG3]: Endianness annotations. · b9fc7dc5
      Al Viro authored 
      Fixed misannotations, introduced a new helper - tg3_nvram_read_le().
It gets __le32 * instead of u32 * and puts there the value converted
to little-endian.  A lot of callers of tg3_nvram_read() were doing
that; converted them to tg3_nvram_read_le().

At that point the driver is practically endian-clean; the only remaining
place is an actual bug, AFAICS; will be dealt with in the next patch.
Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b9fc7dc5
    • Cyrill Gorcunov's avatar
      NET: mac80211: fix inappropriate memory freeing · 20880e89
      Cyrill Gorcunov authored 
      Fix inappropriate memory freeing in case of requested rate_control_ops was
not found.  In this case the list head entity is going to be accidentally
wasted.
Signed-off-by: default avatarCyrill Gorcunov <gorcunov@gmail.com>
Acked-by: default avatarMichael Wu <flamingice@sourmilk.net>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      20880e89
    • Johannes Berg's avatar
      mac80211: fix header ops · 3333590e
      Johannes Berg authored 
      When using recvfrom() on a SOCK_DGRAM packet socket, I noticed that the MAC
address passed back for wireless frames was always completely wrong. The
reason for this is that the header parse function assigned to our virtual
interfaces is a function parsing an 802.11 rather than 802.3 header. This
patch fixes it by keeping the default ethernet header operations assigned.
Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      3333590e
    • Michael Wu's avatar
      mac80211: Drop out of associated state if link is lost · 2d192d95
      Michael Wu authored 
      There is no point in staying in IEEE80211_ASSOCIATED if there is no
sta_info entry to receive frames with.
Signed-off-by: default avatarMichael Wu <flamingice@sourmilk.net>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2d192d95
  3. 19 Dec, 2007 19 commits
  5. 18 Dec, 2007 16 commits
    • Boaz Harrosh's avatar
      [SCSI] initio: bugfix for accessors patch · a169e637
      Boaz Harrosh authored 
      patch: [SCSI] initio: convert to use the data buffer accessors had a
small but fatal bug in that it didn't increment the pointer into the
initio scatterlist descriptors as it looped over the block generated
ones. Fixed here.
Signed-off-by: default avatarBoaz Harrosh <bharrosh@panasas.com>
Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
      a169e637
    • FUJITA Tomonori's avatar
      [SCSI] st: fix kernel BUG at include/linux/scatterlist.h:59! · cd81621c
      FUJITA Tomonori authored 
      This is caused by a missing scatterlist initialisation (it only shows
up when sg list handling debugging is turned on).
Signed-off-by: default avatarFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Kai Makisara <Kai.Makisara@kolumbus.fi>
Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
      cd81621c
    • Alan Cox's avatar
      [SCSI] initio: fix conflict when loading driver · 99f1f534
      Alan Cox authored 
      > I have a scanner connected to a Initio INI-950 SCSI card and I recently
> upgraded from SuSE 10.2 to 10.3.  The new kernel doesn't see any of my
> devices.  I get the following in /var/log/messages:
>
> ACPI: PCI Interrupt 0000:00:0a.0[A] -> GSI 17 (level, low) -> IRQ 16
> initio: I/O port range 0x0 is busy.
> ACPI: PCI interrupt for device 0000:00:0a.0 disabled

Humm not a collision - thats a bug in the driver updating.  Looks like the
changes I made and combined with Christoph's lost a line somewhere when I
was merging it all.
Signed-off-by: default avatarAlan Cox <alan@redhat.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
      99f1f534
    • Tony Battersby's avatar
      [SCSI] sym53c8xx: fix "irq X: nobody cared" regression · cedefa13
      Tony Battersby authored 
      The patch described by the following excerpt from ChangeLog-2.6.24-rc1
eventually causes a "irq X: nobody cared" error after a while:

commit 99c9e0a1
Author: Matthew Wilcox <matthew@wil.cx>
Date:   Fri Oct 5 15:55:12 2007 -0400

    [SCSI] sym53c8xx: Make interrupt handler capable of returning IRQ_NONE

After this happens, the kernel disables the IRQ, causing the SCSI card
to stop working until the next reboot.  The problem is caused by the
interrupt handler returning IRQ_NONE instead of IRQ_HANDLED after
handling an interrupt-on-the-fly (INTF) condition.  The following patch
fixes the problem.
Signed-off-by: default avatarTony Battersby <tonyb@cybernetics.com>
Acked-by: default avatarMatthew Wilcox <willy@linux.intel.com>
Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
      cedefa13
    • James Bottomley's avatar
      [SCSI] dpt_i2o: driver is only 32 bit so don't set 64 bit DMA mask · c80ddf00
      James Bottomley authored 
      This fixes a potential corruption bug where the truncation would cause
reading or writing to the wrong memory area on machines with >4GB of
main memory.

Cc: Stable Kernel Tree <stable@kernel.org>
Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
      c80ddf00
    • Tony Battersby's avatar
      [SCSI] sym53c8xx: fix free_irq() regression · 7ee2413c
      Tony Battersby authored 
      The following commit changed the pointer passed to request_irq(), but
failed to change the pointer passed to free_irq():

commit 99c9e0a1
Author: Matthew Wilcox <matthew@wil.cx>
Date:   Fri Oct 5 15:55:12 2007 -0400

    [SCSI] sym53c8xx: Make interrupt handler capable of returning IRQ_NONE

    ...

The result is that free_irq() doesn't actually take any action.  This
patch fixes it.
Signed-off-by: default avatarTony Battersby <tonyb@cybernetics.com>
Acked-by: default avatarChristoph Hellwig <hch@infradead.org>
Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
      7ee2413c
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86 · 3e3b3916
      Linus Torvalds authored 
      * git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86:
  x86: fix "Kernel panic - not syncing: IO-APIC + timer doesn't work!"
  genirq: revert lazy irq disable for simple irqs
  x86: also define AT_VECTOR_SIZE_ARCH
  x86: kprobes bugfix
  x86: jprobe bugfix
  timer: kernel/timer.c section fixes
  genirq: add unlocked version of set_irq_handler()
  clockevents: fix reprogramming decision in oneshot broadcast
  oprofile: op_model_athlon.c support for AMD family 10h barcelona performance counters
      3e3b3916
    • Ingo Molnar's avatar
      x86: fix "Kernel panic - not syncing: IO-APIC + timer doesn't work!" · 4aae0702
      Ingo Molnar authored 
      this is the tale of a full day spent debugging an ancient but elusive bug.

after booting up thousands of random .config kernels, i finally happened
to generate a .config that produced the following rare bootup failure
on 32-bit x86:

| ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
| ..MP-BIOS bug: 8254 timer not connected to IO-APIC
| ...trying to set up timer (IRQ0) through the 8259A ...  failed.
| ...trying to set up timer as Virtual Wire IRQ... failed.
| ...trying to set up timer as ExtINT IRQ... failed :(.
| Kernel panic - not syncing: IO-APIC + timer doesn't work!  Boot with apic=debug
| and send a report.  Then try booting with the 'noapic' option

this bug has been reported many times during the years, but it was never
reproduced nor fixed.

the bug that i hit was extremely sensitive to .config details.

First i did a .config-bisection - suspecting some .config detail.
That led to CONFIG_X86_MCE: enabling X86_MCE magically made the bug disappear
and the system would boot up just fine.

Debugging my way through the MCE code ended up identifying two unlikely
candidates: the thing that made a real difference to the hang was that
X86_MCE did two printks:

 Intel machine check architecture supported.
 Intel machine check reporting enabled on CPU#1.

Adding the same printks to a !CONFIG_X86_MCE kernel made the bug go away!

this left timing as the main suspect: i experimented with adding various
udelay()s to the arch/x86/kernel/io_apic_32.c:check_timer() function, and
the race window turned out to be narrower than 30 microseconds (!).

That made debugging especially funny, debugging without having printk
ability before the bug hits is ... interesting ;-)

eventually i started suspecting IRQ activities - those are pretty much the
only thing that happen this early during bootup and have the timescale of
a few dozen microseconds. Also, check_timer() changes the IRQ hardware
in various creative ways, so the main candidate became IRQ0 interaction.

i've added a counter to track timer irqs (on which core they arrived, at
what exact time, etc.) and found that no timer IRQ would arrive after the
bug condition hits - even if we re-enable IRQ0 and re-initialize the i8259A,
but that we'd get a small number of timer irqs right around the time when we
call the check_timer() function.

Eventually i got the following backtrace triggered from debug code in the
timer interrupt:

...trying to set up timer as Virtual Wire IRQ... failed.
...trying to set up timer as ExtINT IRQ...
Pid: 1, comm: swapper Not tainted (2.6.24-rc5 #57)
EIP: 0060:[<c044d57e>] EFLAGS: 00000246 CPU: 0
EIP is at _spin_unlock_irqrestore+0x5/0x1c
EAX: c0634178 EBX: 00000000 ECX: c4947d63 EDX: 00000246
ESI: 00000002 EDI: 00010031 EBP: c04e0f2e ESP: f7c41df4
 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
 CR0: 8005003b CR2: ffe04000 CR3: 00630000 CR4: 000006d0
 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
 DR6: ffff0ff0 DR7: 00000400
  [<c05f5784>] setup_IO_APIC+0x9c3/0xc5c

the spin_unlock() was called from init_8259A(). Wait ... we have an IRQ0
entry while we are in the middle of setting up the local APIC, the i8259A
and the PIT??

That is certainly not how it's supposed to work! check_timer() was supposed
to be called with irqs turned off - but this eroded away sometime in the
past. This code would still work most of the time because this code runs
very quickly, but just the right timing conditions are present and IRQ0
hits in this small, ~30 usecs window, timer irqs stop and the system does
not boot up. Also, given how early this is during bootup, the hang is
very deterministic - but it would only occur on certain machines (and
certain configs).

The fix was quite simple: disable/restore interrupts properly in this
function. With that in place the test-system now boots up just fine.

(64-bit x86 io_apic_64.c had the same bug.)

Phew! One down, only 1500 other kernel bugs are left ;-)
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      4aae0702
    • Steven Rostedt's avatar
      genirq: revert lazy irq disable for simple irqs · 971e5b35
      Steven Rostedt authored 
      In commit 76d21601 lazy irq disabling
was implemented, and the simple irq handler had a masking set to it.

Remy Bohmer discovered that some devices in the ARM architecture
would trigger the mask, but never unmask it. His patch to do the
unmasking was questioned by Russell King about masking simple irqs
to begin with. Looking further, it was discovered that the problems
Remy was seeing was due to improper use of the simple handler by
devices, and he later submitted patches to fix those. But the issue
that was uncovered was that the simple handler should never mask.

This patch reverts the masking in the simple handler.
Signed-off-by: default avatarSteven Rostedt <srostedt@redhat.com>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
Acked-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      971e5b35
    • Jan Beulich's avatar
      x86: also define AT_VECTOR_SIZE_ARCH · 213fde71
      Jan Beulich authored 
      The patch introducing this left out 64-bit x86 despite it also having
extra entries.

this solves Xen guest troubles.
Signed-off-by: default avatarJan Beulich <jbeulich@novell.com>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      213fde71
    • Masami Hiramatsu's avatar
      x86: kprobes bugfix · 0b0122fa
      Masami Hiramatsu authored 
      Kprobes for x86-64 may cause a kernel crash if it inserted on "iret"
instruction. "call absolute" is invalid on x86-64, so we don't need
treat it.

 - Change the processing order as same as x86-32.
 - Add "iret"(0xcf) case.
 - Remove next_rip local variable.
Signed-off-by: default avatarMasami Hiramatsu <mhiramat@redhat.com>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      0b0122fa
    • Masami Hiramatsu's avatar
      x86: jprobe bugfix · 29b6cd79
      Masami Hiramatsu authored 
      jprobe for x86-64 may cause kernel page fault when the jprobe_return()
is called from incorrect function.

- Use jprobe_saved_regs instead getting it from stack.
  (Especially on x86-64, it may get incorrect data, because
   pt_regs can not be get by using container_of(rsp))
- Change the type of stack pointer to unsigned long *.
Signed-off-by: default avatarMasami Hiramatsu <mhiramat@redhat.com>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      29b6cd79
    • Adrian Bunk's avatar
      timer: kernel/timer.c section fixes · b4be6258
      Adrian Bunk authored 
      This patch fixes the following section mismatches with CONFIG_HOTPLUG=n,
CONFIG_HOTPLUG_CPU=y:

...
WARNING: vmlinux.o(.text+0x41cd3): Section mismatch: reference to .init.data:tvec_base_done.22610 (between 'timer_cpu_notify' and 'run_timer_softirq')
WARNING: vmlinux.o(.text+0x41d67): Section mismatch: reference to .init.data:tvec_base_done.22610 (between 'timer_cpu_notify' and 'run_timer_softirq')
...
Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      b4be6258
    • Kevin Hilman's avatar
      genirq: add unlocked version of set_irq_handler() · b019e573
      Kevin Hilman authored 
      Add unlocked version for use by irq_chip.set_type handlers which may
wish to change handler to level or edge handler when IRQ type is
changed.

The normal set_irq_handler() call cannot be used because it tries to
take irq_desc.lock which is already held when the irq_chip.set_type
hook is called.
Signed-off-by: default avatarKevin Hilman <khilman@mvista.com>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      b019e573
    • Thomas Gleixner's avatar
      clockevents: fix reprogramming decision in oneshot broadcast · cdc6f27d
      Thomas Gleixner authored 
      Resolve the following regression of a choppy, almost unusable laptop:

 http://lkml.org/lkml/2007/12/7/299
 http://bugzilla.kernel.org/show_bug.cgi?id=9525

A previous version of the code did the reprogramming of the broadcast
device in the return from idle code. This was removed, but the logic in
tick_handle_oneshot_broadcast() was kept the same.

When a broadcast interrupt happens we signal the expiry to all CPUs
which have an expired event. If none of the CPUs has an expired event,
which can happen in dyntick mode, then we reprogram the broadcast
device. We do not reprogram otherwise, but this is only correct if all
CPUs, which are in the idle broadcast state have been woken up.

The code ignores, that there might be pending not yet expired events on
other CPUs, which are in the idle broadcast state. So the delivery of
those events can be delayed for quite a time.

Change the tick_handle_oneshot_broadcast() function to check for CPUs,
which are in broadcast state and are not woken up by the current event,
and enforce the rearming of the broadcast device for those CPUs.
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      cdc6f27d
    • Barry Kasindorf's avatar
      oprofile: op_model_athlon.c support for AMD family 10h barcelona performance counters · bd87f1f0
      Barry Kasindorf authored 
      This patch is for controlling the upper 32bits of the event ctrl msrs.
This includes the upper 4 bits of the event select and the Guest Only and
Host Only bits

This patch is necessary to make Event Based Profiling work reliably on a
Family 10h processor

[akpm@linux-foundation.org: checkpatch.pl fixes]
Signed-off-by: default avatarBarry Kasindorf <barry.kasindorf@amd.com>
Signed-off-by: default avatarRobert Richter <robert.richter@amd.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      bd87f1f0
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7