| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <000b01cb6f4e$cc555df0$66f8800a@maildom.okisemi.com>
Date: Tue, 19 Oct 2010 14:30:44 +0900
From: "Masayuki Ohtake" <masa-korg@....okisemi.com>
To: "seedshope" <bocui107@...il.com>
Cc: "David S. Miller" <davem@...emloft.net>,
"Randy Dunlap" <randy.dunlap@...cle.com>,
"John Linn" <john.linn@...inx.com>,
"Ralf Baechle" <ralf@...ux-mips.org>,
"Kristoffer Glembo" <kristoffer@...sler.com>,
"Maxime Bizon" <mbizon@...ebox.fr>,
"Greg Rose" <gregory.v.rose@...el.com>,
"ML netdev" <netdev@...r.kernel.org>,
"LKML" <linux-kernel@...r.kernel.org>,
"Toshiharu Okada" <okada533@....okisemi.com>,
"Takahiro Shimizu" <shimizu394@....okisemi.com>,
"Tomoya Morinaga" <morinaga526@....okisemi.com>,
"Wang, Qi" <qi.wang@...el.com>,
"Wang, Yong Y" <yong.y.wang@...el.com>,
"Andrew" <andrew.chih.howe.khor@...el.com>,
"Intel OTC" <joel.clark@...el.com>,
"Foster, Margie" <margie.foster@...el.com>,
"MeeGo" <meego-dev@...go.com>
Subject: Re: [PATCH v6] Gigabit Ethernet driver of Topcliff PCH
Hi seedshope,
>why it is need to compare the INT_EN bit?
>As general, the pch_gbe_intr function was call,the interrupt is enable.
>In addition to the interrupt generate, what other conditions would call the interrupt function?
PCI devices in Topcliff IOH are connected with external PCI Express through logical PCI bus.
In Topcliff IOH, more PCI devices are sharing interruption.
Gigabit Ethernet device and USB Host are sharing interruption.
The pch_gbe_intr function is called on condition of others.
So, the comparison with INT_EN bit is necessary.
>resently , I fail to test the kgdboe on the gbe driver.
>The pch_gbe_netpoll will call the pch_gbe_intr function.
>The interruption will be disable before enter the pch_gbe_intr.
>So the pch_gbe_netpoll is fail for ever. Is it a bug?
I think it is not a bug.
The INT_EN bit is a value of Gigabit Ethernet device's register.
The interruption disable processing before pch_gbe_intr() in pch_gbe_netpoll() function is a disable_irq() function.
The disable_irq() function does not change the register of a Gigabit Ethernet device.
Best regards.
Masayuki Otake.
-----
Date: Mon, 18 Oct 2010 16:48:50 +0800
From: seedshope
Hi Masayuki,
>/**
> * pch_gbe_intr - Interrupt Handler
> * @irq: Interrupt number
> * @data: Pointer to a network interface device structure
> * Returns
> * - IRQ_HANDLED: Our interrupt
> * - IRQ_NONE: Not our interrupt
> */
>static irqreturn_t pch_gbe_intr(int irq, void *data)
>{
> struct net_device *netdev = data;
> struct pch_gbe_adapter *adapter = netdev_priv(netdev);
> struct pch_gbe_hw *hw = &adapter->hw;
> u32 int_st;
> u32 int_en;
>
> /* Check request status */
> int_st = ioread32(&hw->reg->INT_ST);
> int_st = int_st & ioread32(&hw->reg->INT_EN);
why it is need to compare the INT_EN bit? As general, the pch_gbe_intr function was call,the interrupt is enable. In
addition to the interrupt generate, what other conditions would call the interrupt function?
resently , I fail to test the kgdboe on the gbe driver. The pch_gbe_netpoll will call the pch_gbe_intr function. The
interruption will be disable before enter the pch_gbe_intr.
So the pch_gbe_netpoll is fail for ever. Is it a bug?
> /* When request status is no interruption factor */
> if (unlikely(!int_st))
> return IRQ_NONE; /* Not our interrupt. End processing. */
> pr_debug("%s occur int_st = 0x%08x\n", __func__, int_st);
> if (int_st & PCH_GBE_INT_RX_FRAME_ERR)
> adapter->stats.intr_rx_frame_err_count++;
> if (int_st & PCH_GBE_INT_RX_FIFO_ERR)
> adapter->stats.intr_rx_fifo_err_count++;
> if (int_st & PCH_GBE_INT_RX_DMA_ERR)
> adapter->stats.intr_rx_dma_err_count++;
> if (int_st & PCH_GBE_INT_TX_FIFO_ERR)
> adapter->stats.intr_tx_fifo_err_count++;
> if (int_st & PCH_GBE_INT_TX_DMA_ERR)
> adapter->stats.intr_tx_dma_err_count++;
> if (int_st & PCH_GBE_INT_TCPIP_ERR)
> adapter->stats.intr_tcpip_err_count++;
> /* When Rx descriptor is empty */
> if ((int_st & PCH_GBE_INT_RX_DSC_EMP)) {
> adapter->stats.intr_rx_dsc_empty_count++;
> pr_err("Rx descriptor is empty\n");
> int_en = ioread32(&hw->reg->INT_EN);
> iowrite32((int_en & ~PCH_GBE_INT_RX_DSC_EMP), &hw->reg->INT_EN);
> if (hw->mac.tx_fc_enable) {
> /* Set Pause packet */
> pch_gbe_mac_set_pause_packet(hw);
> }
> if ((int_en & (PCH_GBE_INT_RX_DMA_CMPLT | PCH_GBE_INT_TX_CMPLT))
> == 0) {
> return IRQ_HANDLED;
> }
> }
>
> /* When request status is Receive interruption */
> if ((int_st & (PCH_GBE_INT_RX_DMA_CMPLT | PCH_GBE_INT_TX_CMPLT))) {
> if (likely(napi_schedule_prep(&adapter->napi))) {
> /* Enable only Rx Descriptor empty */
> atomic_inc(&adapter->irq_sem);
> int_en = ioread32(&hw->reg->INT_EN);
> int_en &=
> ~(PCH_GBE_INT_RX_DMA_CMPLT | PCH_GBE_INT_TX_CMPLT);
> iowrite32(int_en, &hw->reg->INT_EN);
> /* Start polling for NAPI */
> __napi_schedule(&adapter->napi);
> }
> }
> pr_debug("return = 0x%08x INT_EN reg = 0x%08x\n",
> IRQ_HANDLED, ioread32(&hw->reg->INT_EN));
> return IRQ_HANDLED;
>}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists