1. 28 10月, 2015 1 次提交
    • N
      forcedeth: fix unilateral interrupt disabling in netpoll path · 0b7c8743
      Neil Horman 提交于
      Forcedeth currently uses disable_irq_lockdep and enable_irq_lockdep, which in
      some configurations simply calls local_irq_disable.  This causes errant warnings
      in the netpoll path as in netpoll_send_skb_on_dev, where we disable irqs using
      local_irq_save, leading to the following warning:
      
      WARNING: at net/core/netpoll.c:352 netpoll_send_skb_on_dev+0x243/0x250() (Not
      tainted)
      Hardware name:
      netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll
      (nv_start_xmit_optimized+0x0/0x860 [forcedeth])
      Modules linked in: netconsole(+) configfs ipv6 iptable_filter ip_tables ppdev
      parport_pc parport sg microcode serio_raw edac_core edac_mce_amd k8temp
      snd_hda_codec_realtek snd_hda_codec_generic forcedeth snd_hda_intel
      snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd soundcore
      snd_page_alloc i2c_nforce2 i2c_core shpchp ext4 jbd2 mbcache sr_mod cdrom sd_mod
      crc_t10dif pata_amd ata_generic pata_acpi sata_nv dm_mirror dm_region_hash
      dm_log dm_mod [last unloaded: scsi_wait_scan]
      Pid: 1940, comm: modprobe Not tainted 2.6.32-573.7.1.el6.x86_64.debug #1
      Call Trace:
       [<ffffffff8107bbc1>] ? warn_slowpath_common+0x91/0xe0
       [<ffffffff8107bcc6>] ? warn_slowpath_fmt+0x46/0x60
       [<ffffffffa00fe5b0>] ? nv_start_xmit_optimized+0x0/0x860 [forcedeth]
       [<ffffffff814b3593>] ? netpoll_send_skb_on_dev+0x243/0x250
       [<ffffffff814b37c9>] ? netpoll_send_udp+0x229/0x270
       [<ffffffffa02e3299>] ? write_msg+0x39/0x110 [netconsole]
       [<ffffffffa02e331b>] ? write_msg+0xbb/0x110 [netconsole]
       [<ffffffff8107bd55>] ? __call_console_drivers+0x75/0x90
       [<ffffffff8107bdba>] ? _call_console_drivers+0x4a/0x80
       [<ffffffff8107c445>] ? release_console_sem+0xe5/0x250
       [<ffffffff8107d200>] ? register_console+0x190/0x3e0
       [<ffffffffa02e71a6>] ? init_netconsole+0x1a6/0x216 [netconsole]
       [<ffffffffa02e7000>] ? init_netconsole+0x0/0x216 [netconsole]
       [<ffffffff810020d0>] ? do_one_initcall+0xc0/0x280
       [<ffffffff810d4933>] ? sys_init_module+0xe3/0x260
       [<ffffffff8100b0d2>] ? system_call_fastpath+0x16/0x1b
      ---[ end trace f349c7af88e6a6d5 ]---
      console [netcon0] enabled
      netconsole: network logging started
      
      Fix it by modifying the forcedeth code to use
      disable_irq_nosync_lockdep_irqsavedisable_irq_nosync_lockdep_irqsave instead,
      which saves and restores irq state properly.  This also saves us a little code
      in the process
      
      Tested by the reporter, with successful restuls
      
      Patch applies to the head of the net tree
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: "David S. Miller" <davem@davemloft.net>
      Reported-by: NVasily Averin <vvs@sw.ru>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0b7c8743
  2. 27 10月, 2015 8 次提交
  3. 26 10月, 2015 7 次提交
  4. 23 10月, 2015 7 次提交
  5. 22 10月, 2015 6 次提交
  6. 21 10月, 2015 6 次提交
  7. 19 10月, 2015 4 次提交
  8. 18 10月, 2015 1 次提交
    • M
      i2c: designware: Do not use parameters from ACPI on Dell Inspiron 7348 · 56d4b8a2
      Mika Westerberg 提交于
      ACPI SSCN/FMCN methods were originally added because then the platform can
      provide the most accurate HCNT/LCNT values to the driver. However, this
      seems not to be true for Dell Inspiron 7348 where using these causes the
      touchpad to fail in boot:
      
        i2c_hid i2c-DLL0675:00: failed to retrieve report from device.
        i2c_designware INT3433:00: i2c_dw_handle_tx_abort: lost arbitration
        i2c_hid i2c-DLL0675:00: failed to retrieve report from device.
        i2c_designware INT3433:00: controller timed out
      
      The values received from ACPI are (in fast mode):
      
        HCNT: 72
        LCNT: 160
      
      this translates to following timings (input clock is 100MHz on Broadwell):
      
        tHIGH: 720 ns (spec min 600 ns)
        tLOW: 1600 ns (spec min 1300 ns)
        Bus period: 2920 ns (assuming 300 ns tf and tr)
        Bus speed: 342.5 kHz
      
      Both tHIGH and tLOW are within the I2C specification.
      
      The calculated values when ACPI parameters are not used are (in fast mode):
      
        HCNT: 87
        LCNT: 159
      
      which translates to:
      
        tHIGH: 870 ns (spec min 600 ns)
        tLOW: 1590 ns (spec min 1300 ns)
        Bus period 3060 ns (assuming 300 ns tf and tr)
        Bus speed 326.8 kHz
      
      These values are also within the I2C specification.
      
      Since both ACPI and calculated values meet the I2C specification timing
      requirements it is hard to say why the touchpad does not function properly
      with the ACPI values except that the bus speed is higher in this case (but
      still well below the max 400kHz).
      
      Solve this by adding DMI quirk to the driver that disables using ACPI
      parameters on this particulare machine.
      Reported-by: NPavel Roskin <plroskin@gmail.com>
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Tested-by: NPavel Roskin <plroskin@gmail.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      Cc: stable@kernel.org
      56d4b8a2
新手
引导
客服 返回
顶部