1. 13 12月, 2011 1 次提交
    • L
      ipv6: Fix for adding multicast route for loopback device automatically. · 4af04aba
      Li Wei 提交于
      There is no obvious reason to add a default multicast route for loopback
      devices, otherwise there would be a route entry whose dst.error set to
      -ENETUNREACH that would blocking all multicast packets.
      
      ====================
      
      [ more detailed explanation ]
      
      The problem is that the resulting routing table depends on the sequence
      of interface's initialization and in some situation, that would block all
      muticast packets. Suppose there are two interfaces on my computer
      (lo and eth0), if we initailize 'lo' before 'eth0', the resuting routing
      table(for multicast) would be
      
      # ip -6 route show | grep ff00::
      unreachable ff00::/8 dev lo metric 256 error -101
      ff00::/8 dev eth0 metric 256
      
      When sending multicasting packets, routing subsystem will return the first
      route entry which with a error set to -101(ENETUNREACH).
      
      I know the kernel will set the default ipv6 address for 'lo' when it is up
      and won't set the default multicast route for it, but there is no reason to
      stop 'init' program from setting address for 'lo', and that is exactly what
      systemd did.
      
      I am sure there is something wrong with kernel or systemd, currently I preferred
      kernel caused this problem.
      
      ====================
      Signed-off-by: NLi Wei <lw@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4af04aba
  2. 10 12月, 2011 1 次提交
  3. 09 12月, 2011 1 次提交
    • H
      ssb: fix init regression with SoCs · 329456d1
      Hauke Mehrtens 提交于
      This fixes a Data bus error on some SoCs. The first fix for this
      problem did not solve it on all devices.
          commit 6ae8ec27
          Author: Rafał Miłecki <zajec5@gmail.com>
          Date:   Tue Jul 5 17:25:32 2011 +0200
              ssb: fix init regression of hostmode PCI core
      
      In ssb_pcicore_fix_sprom_core_index() the sprom on the PCI core is
      accessed, but the sprom only exists when the ssb bus is connected over
      a PCI bus to the rest of the system and not when the SSB Bus is the
      main system bus. SoCs sometimes have a PCI host controller and there
      this code will not be executed, but there are some old SoCs with an PCI
      controller in client mode around and ssb_pcicore_fix_sprom_core_index()
      should not be called on these devices too. The PCI controller on these
      devices are unused, but without this fix it results in an Data bus
      error when it gets initialized.
      
      Cc: Michael Buesch <m@bues.ch>
      Cc: Rafał Miłecki <zajec5@gmail.com>
      Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      329456d1
  4. 08 12月, 2011 6 次提交
  5. 07 12月, 2011 8 次提交
  6. 06 12月, 2011 23 次提交