Skip to content
Snippets Groups Projects
  1. Oct 10, 2007
    • Maciej W. Rozycki's avatar
      NET_SB1250_MAC: Rename to SB1250_MAC · 1a9e8549
      Maciej W. Rozycki authored
      
       Rename NET_SB1250_MAC to SB1250_MAC to follow the convention.
      
      Signed-off-by: default avatarMaciej W. Rozycki <macro@linux-mips.org>
      Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      1a9e8549
    • David Gibson's avatar
      Device tree aware EMAC driver · 1d3bb996
      David Gibson authored
      
      Based on BenH's earlier work, this is a new version of the EMAC driver
      for the built-in ethernet found on PowerPC 4xx embedded CPUs.  The
      same ASIC is also found in the Axon bridge chip.  This new version is
      designed to work in the arch/powerpc tree, using the device tree to
      probe the device, rather than the old and ugly arch/ppc OCP layer.
      
      This driver is designed to sit alongside the old driver (that lies in
      drivers/net/ibm_emac and this one in drivers/net/ibm_newemac).  The
      old driver is left in place to support arch/ppc until arch/ppc itself
      reaches its final demise (not too long now, with luck).
      
      This driver still has a number of things that could do with cleaning
      up, but I think they can be fixed up after merging.  Specifically:
      	- Should be adjusted to properly use the dma mapping API.
      Axon needs this.
      	- Probe logic needs reworking, in conjuction with the general
      probing code for of_platform devices.  The dependencies here between
      EMAC, MAL, ZMII etc. make this complicated.  At present, it usually
      works, because we initialize and register the sub-drivers before the
      EMAC driver itself, and (being in driver code) runs after the devices
      themselves have been instantiated from the device tree.
      
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      1d3bb996
    • Eric W. Biederman's avatar
      [NET]: Make the device list and device lookups per namespace. · 881d966b
      Eric W. Biederman authored
      
      This patch makes most of the generic device layer network
      namespace safe.  This patch makes dev_base_head a
      network namespace variable, and then it picks up
      a few associated variables.  The functions:
      dev_getbyhwaddr
      dev_getfirsthwbytype
      dev_get_by_flags
      dev_get_by_name
      __dev_get_by_name
      dev_get_by_index
      __dev_get_by_index
      dev_ioctl
      dev_ethtool
      dev_load
      wireless_process_ioctl
      
      were modified to take a network namespace argument, and
      deal with it.
      
      vlan_ioctl_set and brioctl_set were modified so their
      hooks will receive a network namespace argument.
      
      So basically anthing in the core of the network stack that was
      affected to by the change of dev_base was modified to handle
      multiple network namespaces.  The rest of the network stack was
      simply modified to explicitly use &init_net the initial network
      namespace.  This can be fixed when those components of the network
      stack are modified to handle multiple network namespaces.
      
      For now the ifindex generator is left global.
      
      Fundametally ifindex numbers are per namespace, or else
      we will have corner case problems with migration when
      we get that far.
      
      At the same time there are assumptions in the network stack
      that the ifindex of a network device won't change.  Making
      the ifindex number global seems a good compromise until
      the network stack can cope with ifindex changes when
      you change namespaces, and the like.
      
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      881d966b
    • Eric W. Biederman's avatar
      [NET]: Make device event notification network namespace safe · e9dc8653
      Eric W. Biederman authored
      
      Every user of the network device notifiers is either a protocol
      stack or a pseudo device.  If a protocol stack that does not have
      support for multiple network namespaces receives an event for a
      device that is not in the initial network namespace it quite possibly
      can get confused and do the wrong thing.
      
      To avoid problems until all of the protocol stacks are converted
      this patch modifies all netdev event handlers to ignore events on
      devices that are not in the initial network namespace.
      
      As the rest of the code is made network namespace aware these
      checks can be removed.
      
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e9dc8653
    • Robert Olsson's avatar
      [SOFTIRQ]: Remove do_softirq() symbol export. · c45248c7
      Robert Olsson authored
      
      As noted by Christoph Hellwig, pktgen was the only user so
      it can now be removed.
      
      [ Add missing cases caught by Adrian Bunk. -DaveM ]
      
      Signed-off-by: default avatarRobert Olsson <robert.olsson@its.uu.se>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c45248c7
  2. Oct 09, 2007
  3. Oct 07, 2007
    • Rafal Bilski's avatar
      Longhaul: add auto enabled "revid_errata" option · 52a2638b
      Rafal Bilski authored
      
      VIA C3 Ezra-T has RevisionID equal to 1, but it needs RevisionKey to be 0
      or CPU will ignore new frequency and will continue to work at old
      frequency.  New "revid_errata" option will force RevisionKey to be set to
      0, whatever RevisionID is.
      
      Additionaly "Longhaul" will not silently ignore unsuccessful transition.
      It will try to check if "revid_errata" or "disable_acpi_c3" options need to
      be enabled for this processor/system.
      
      Same for Longhaul ver.  2 support.  It will be disabled if none of above
      options will work.
      
       Best case scenario (with patch apllied and v2 enabled):
       longhaul: VIA C3 'Ezra' [C5C] CPU detected.  Longhaul v2 supported.
       longhaul: Using northbridge support.
       longhaul: VRM 8.5
       longhaul: Max VID=1.350  Min VID=1.050, 13 possible voltage scales
       longhaul: f: 300000 kHz, index: 0, vid: 1050 mV
       [...]
       longhaul: Voltage scaling enabled.
       Worst case scenario:
       longhaul: VIA C3 'Ezra-T' [C5M] CPU detected.  Powersaver supported.
       longhaul: Using northbridge support.
       longhaul: Using ACPI support.
       longhaul: VRM 8.5
       longhaul: Claims to support voltage scaling but min & max are both 1.250. Voltage scaling disabled
       longhaul: Failed to set requested frequency!
       longhaul: Enabling "Ignore Revision ID" option.
       longhaul: Failed to set requested frequency!
       longhaul: Disabling ACPI C3 support.
       longhaul: Disabling "Ignore Revision ID" option.
       longhaul: Failed to set requested frequency!
       longhaul: Enabling "Ignore Revision ID" option.
      
      [akpm@linux-foundation.org: coding-style cleanups]
      Signed-off-by: default avatarRafal Bilski <rafalbilski@interia.pl>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      52a2638b
  4. Oct 05, 2007
  5. Oct 04, 2007
  6. Oct 03, 2007
  7. Oct 02, 2007
  8. Oct 01, 2007
    • Andi Kleen's avatar
      x86_64: increase VDSO_TEXT_OFFSET for ancient binutils · cf8dc57c
      Andi Kleen authored
      
      For some reason old binutils genertate larger headers so increase the text
      offset of the vdso to avoid linker errors.
      
      Roland McGrath explains:
        "There are extra symbols in the '.dynsym' section that are responsible
         for the size difference (They also cause corresponding inflation in
         '.gnu.version')
      
         Older ld's wrongly generated these unneeded symbols in .dynsym.  This
         was fixed not all that long ago (2006); binutils-2.17.50.0.6 might be
         the first fixed version, but I have not verified for sure where the
         cutoff was.
      
         The unneeded symbols et al from old ld add almost 700 bytes excess.
         This limits fairly tightly the amount by which the actual text and
         data in the vDSO can grow in the future without pushing the whole
         file over 4kb.  If it does grow later on, we should consider changing
         the layout with a config option or something to pack it better
         without that padding, when building the kernel with newer binutils."
      
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Badari Pulavarty <pbadari@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      cf8dc57c
    • Anton Blanchard's avatar
      [POWERPC] Fix xics set_affinity code · e48395f1
      Anton Blanchard authored
      
      On a POWER6 machine running 2.6.23-rc8 I sometimes see the following error:
      
      xics_set_affinity: No online cpus in the mask 00000000,00000000,00000000,00000001 for irq 20
      
      In a desperate attempt to get a changelog entry in 2.6.23, I took a look
      into it.
      
      It turns out we are passing a real and not a virtual irq into
      get_irq_server.  This works for the case where hwirq < NR_IRQS and we
      set virq = hwirq.  In my case however hwirq = 590082 and we try and
      access irq_desc[590082], slightly past the end at 512 entries.
      
      Lucky we ship lots of memory with our machines.
      
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      e48395f1
    • Maciej W. Rozycki's avatar
      [MIPS] vmlinux.lds.S: Handle note sections · 6f6b3940
      Maciej W. Rozycki authored
      
      Store any note sections after the exception tables like the other
      architectures do.  This is required for .note.gnu.build-id emitted from
      binutils 2.18 onwards if nothing else.
      
      Signed-off-by: default avatarMaciej W. Rozycki <macro@linux-mips.org>
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      6f6b3940
  9. Sep 30, 2007
    • David S. Miller's avatar
      [SPARC64]: Fix put_user() calls in binfmt_aout32.c · 8cc8c28a
      David S. Miller authored
      
      argv and envp are pointers to u32's in userspace, so don't
      try to put_user() a NULL to them.
      
      Aparently gcc-4.2.x now warns about this, and since we use
      -Werror for arch/sparc64 code, this breaks the build.
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8cc8c28a
    • Russell King's avatar
      [ARM] Resolve PCI section warnings · 46edfc54
      Russell King authored
      
      Fix the following (valid) section warnings:
      
      WARNING: vmlinux.o(.text+0xf7b5c): Section mismatch: reference to .init.text:pcibios_fixup_bus (between 'pci_scan_child_bus' and 'pci_scan_bridge')
      WARNING: vmlinux.o(.text+0xfc5f4): Section mismatch: reference to .init.text:pcibios_resource_to_bus (between 'pci_map_rom' and 'pci_unmap_rom')
      WARNING: vmlinux.o(.text+0xfc824): Section mismatch: reference to .init.text:pcibios_resource_to_bus (between 'pci_update_resource' and 'pci_claim_resource')
      WARNING: vmlinux.o(.text+0xfd6d8): Section mismatch: reference to .init.text:pcibios_resource_to_bus (between 'pci_setup_cardbus' and 'find_free_bus_resource')
      WARNING: vmlinux.o(.text+0xfd730): Section mismatch: reference to .init.text:pcibios_resource_to_bus (between 'pci_setup_cardbus' and 'find_free_bus_resource')
      WARNING: vmlinux.o(.text+0xfd788): Section mismatch: reference to .init.text:pcibios_resource_to_bus (between 'pci_setup_cardbus' and 'find_free_bus_resource')
      WARNING: vmlinux.o(.text+0xfd7e0): Section mismatch: reference to .init.text:pcibios_resource_to_bus (between 'pci_setup_cardbus' and 'find_free_bus_resource')
      WARNING: vmlinux.o(.text+0xfe024): Section mismatch: reference to .init.text:pcibios_resource_to_bus (between 'pci_bus_assign_resources' and 'sys_pciconfig_read')
      WARNING: vmlinux.o(.text+0xfe0f4): Section mismatch: reference to .init.text:pcibios_resource_to_bus (between 'pci_bus_assign_resources' and 'sys_pciconfig_read')
      WARNING: vmlinux.o(.text+0xfe17c): Section mismatch: reference to .init.text:pcibios_resource_to_bus (between 'pci_bus_assign_resources' and 'sys_pciconfig_read')
      
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      46edfc54
  10. Sep 28, 2007
  11. Sep 27, 2007
  12. Sep 26, 2007
    • Linus Torvalds's avatar
      Revert "x86-64: Disable local APIC timer use on AMD systems with C1E" · f7f847b0
      Linus Torvalds authored
      
      This reverts commit e66485d7, since
      Rafael Wysocki noticed that the change only works for his in -mm, not in
      mainline (and that both "noapictimer" _and_ "apicmaintimer" are broken
      on his hardware, but that's apparently not a regression, just a symptom
      of the same issue that causes the automatic apic timer disable to not
      work).
      
      It turns out that it really doesn't work correctly on x86-64, since
      x86-64 doesn't use the generic clock events for timers yet.
      
      Thanks to Rafal for testing, and here's the ugly details on x86-64 as
      per Thomas:
      
        "I just looked into the code and the logic vs.  noapictimer on SMP is
         completely broken.
      
         On i386 the noapictimer option not only disables the local APIC
         timer, it also registers the CPUs for broadcasting via IPI on SMP
         systems.
      
         The x86-64 code uses the broadcast only when the local apic timer is
         active, i.e.  "noapictimer" is not on the command line.  This defeats
         the whole purpose of "noapictimer".  It should be there to make boxen
         work, where the local APIC timer actually has a hardware problem,
         e.g.  the nx6325.
      
         The current implementation of x86_64 only fixes the ACPI c-states
         related problem where the APIC timer stops in C3(2), nothing else.
      
         On nx6325 and other AMD X2 equipped systems which have the C1E
         enabled we run into the following:
      
         PIT keeps jiffies (and the system) running, but the local APIC timer
         interrupts can get out of sync due to this C1E effect.
      
         I don't think this is a critical problem, but it is wrong
         nevertheless.
      
         I think it's safe to revert the C1E patch and postpone the fix to the
         clock events conversion."
      
      On further reflection, Thomas noted:
      
         "It's even worse than I thought on the first check:
      
          "noapictimer" on the command line of an SMP box prevents _ONLY_ the
          boot CPU apic timer from being used.  But the secondary CPU is still
          unconditionally setting up the APIC timer and uses the non
          calibrated variable calibration_result, which is of course 0, to
          setup the APIC timer.  Wreckage guaranteed."
      
      so we'll just have to wait for the x86 merge to hopefully fix this up
      for x86-64.
      
      Tested-and-requested-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f7f847b0
    • H. Peter Anvin's avatar
      [x86 setup] Handle case of improperly terminated E820 chain · 2efa33f8
      H. Peter Anvin authored
      
      At least one system (a Geode system with a Digital Logic BIOS) has
      been found which suddenly stops reporting the SMAP signature when
      reading the E820 memory chain.  We can't know what, exactly, broke in
      the BIOS, so if we detect this situation, declare the E820 data
      unusable and fall back to E801.
      
      Also, revert to original behavior of always probing all memory
      methods; that way all the memory information is available to the
      kernel.
      
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Cc: Jordan Crouse <jordan.crouse@amd.com>
      Cc: Joerg Pommnitz <pommnitz@yahoo.com>
      2efa33f8
    • Jeremy Fitzhardinge's avatar
      xen: execve's error paths don't pin the mm before unpinning · df912ea4
      Jeremy Fitzhardinge authored
      
      execve's error paths don't activate (and therefore pin) the mm before
      calling exit_mmap to free it up, so don't try to unpin unless it is
      actually pinned.  This prevents a BUG_ON from triggering.
      
      Signed-off-by: default avatarJeremy Fitzhardinge <jeremy@xensource.com>
      Cc: Christian Ostheimer <osth@freesurf.ch>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      df912ea4
    • Thomas Gleixner's avatar
      x86-64: Disable local APIC timer use on AMD systems with C1E · e66485d7
      Thomas Gleixner authored
      
      commit 3556ddfa titled
      
       [PATCH] x86-64: Disable local APIC timer use on AMD systems with C1E
      
      solves a problem with AMD dual core laptops e.g. HP nx6325 (Turion 64
      X2) with C1E enabled:
      
      When both cores go into idle at the same time, then the system switches
      into C1E state, which is basically the same as C3. This stops the local
      apic timer.
      
      This was debugged right after the dyntick merge on i386 and despite the
      patch title it fixes only the 32 bit path.
      
      x86_64 is still missing this fix. It seems that mainline is not really
      affected by this issue, as the PIT is running and keeps jiffies
      incrementing, but that's just waiting for trouble.
      
      -mm suffers from this problem due to the x86_64 high resolution timer
      patches.
      
      This is a quick and dirty port of the i386 code to x86_64.
      
      I spent quite a time with Rafael to debug the -mm / hrt wreckage until
      someone pointed us to this. I really had forgotten that we debugged this
      half a year ago already.
      
      Sigh, is it just me or is there something yelling arch/x86 into my ear?
      
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e66485d7
Loading