* Re: via_rhine/qdisc Dead loop on netdevice eth1, fix it urgently!
From: James Bourne @ 2006-04-23 17:04 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <20060423113107.GA16193@gondor.apana.org.au>
On Sun, 23 Apr 2006, Herbert Xu wrote:
> On Fri, Apr 14, 2006 at 03:51:15PM +0000, James Bourne wrote:
>>
>> Apr 14 08:32:54 bama kernel: [<c02becbb>] netpoll_send_skb+0xa8/0x100 [<f8c4c174>] write_msg+0x140/0x181 [netconsole]
>
> This is the culprit. Disable that and the problem will go away.
That's done now, but... This has been happening for a while now, and I had
enabled netdump/netconsole to try and troubleshoot the problem if there was
a crash involved (which unfortunately there never has been).
Thanks though, and if/when it happens I'll let you know.
Regards
James
>
> Cheers,
>
--
James Bourne | Email: jbourne@hardrock.org
UNIX Systems Administration | WWW: http://www.hardrock.org
Custom UNIX Programming | Linux: The choice of a GNU generation
----------------------------------------------------------------------
"All you need's an occasional kick in the philosophy." Frank Herbert
^ permalink raw reply
* Re: Van Jacobson's net channels and real-time
From: Ingo Oeser @ 2006-04-23 14:15 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, simlo, linux-kernel, mingo, netdev
In-Reply-To: <20060422.225639.93889487.davem@davemloft.net>
Hi Dave,
On Sunday, 23. April 2006 07:56, David S. Miller wrote:
> > If cacheline bouncing because of the shared filled_entries becomes an issue,
> > you are receiving or sending a lot.
>
> Cacheline bouncing is the core issue being addressed by this
> data structure, so we really can't consider your idea seriously.
Ok, I can see it now more clearly. Many thanks for clearing that up
in the other replies. I had a major misunderstanding there.
> I've just got an off-by-one error, no need to wreck the entire
> data structure just to solve that :-)
Yes, you are right. But even then I can still implement the
reserve/commit once you provide the helpers for
producer_space and consumer_space.
Regards
Ingo Oeser
^ permalink raw reply
* Re: [PATCH 00/10] e1000: Driver fixes and update to 7.0.38-k2
From: Auke Kok @ 2006-04-23 14:13 UTC (permalink / raw)
To: David S. Miller
Cc: herbert, jgarzik, auke-jan.h.kok, netdev, john.ronciak,
jesse.brandeburg, Jeffrey.t.kirsher, auke
In-Reply-To: <20060422.225345.125621531.davem@davemloft.net>
David S. Miller wrote:
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Sat, 22 Apr 2006 15:22:54 +1000
>
>> Jeff Garzik <jgarzik@pobox.com> wrote:
>>>> 05/10: [PATCH] Update truesize with the length of the packet for
>>>> packet split
>>> These 10 patches look OK, but since the current kernel version is
>>> 2.6.17-rc1, that means we are in "bug fix only" mode right now.
>>>
>>> Should I (a) apply these all to netdev2-.6.git#upstream, queueing them
>>> for 2.6.18, or (b) let you split the submission into two parts, bug
>>> fixes only and everything else?
>> It turns out that the truesize patch is pretty important as otherwise
>> most of TCP receive socket buffer accounting falls apart. So it should
>> probably go into 2.6.17 and even 2.6.16-stable.
>
> I totally agree.
>
> Jeff please try to get at least this skb->truesize fix queued
> to both -stable and current 2.6.x, it's really needed and
> important for proper socket memory accounting on receive with
> e1000.
I agree, Jeff, please go ahead or let me know if you want me to submit this
separately.
Auke
^ permalink raw reply
* Re: TCP not retransmitting supposedly lost segment
From: Herbert Xu @ 2006-04-23 12:27 UTC (permalink / raw)
To: Florian Zumbiehl; +Cc: netdev
In-Reply-To: <20060410010005.GA9282@florz.florz.dyndns.org>
On Mon, Apr 10, 2006 at 01:00:05AM +0000, Florian Zumbiehl wrote:
>
> meanwhile I gathered some information from /proc/net/tcp6 on this
> problem - in case anyone is interested :-)
>
> | 1144560959: 8: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:1223 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:1A0B 01 00000000:00000000 02:00097F82 00000000 1000 0 3188619 8 c1409260 89 10 20 2 2
> | 1144560969: 8: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:1223 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:1A0B 01 00000016:00000000 01:00000074 00000004 1000 0 3188619 9 c1409260 1424 10 18 1 2
> | 1144560980: 8: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:1223 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:1A0B 01 00000016:00000000 01:000000FA 00000005 1000 0 3188619 9 c1409260 2848 10 18 1 2
> | 1144560990: 8: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:1223 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:1A0B 01 00000016:00000000 01:000005F2 00000006 1000 0 3188619 9 c1409260 5696 10 18 1 2
This tells us that the kernel was indeed retransmitting but the
packet didn't make it out of the interface according to your
tcpdump.
Do you have any firewall rules? Any tc rules?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Netpoll checksum issue
From: Herbert Xu @ 2006-04-23 11:34 UTC (permalink / raw)
To: Aubrey; +Cc: Stephen Hemminger, netdev
In-Reply-To: <6d6a94c50604191854m73b241e3v104d713b7bb93674@mail.gmail.com>
On Thu, Apr 20, 2006 at 09:54:54AM +0800, Aubrey wrote:
>
> Hi Herbert - I'm working on blackfin uclinux platform. My network
> driver is for blackfin on-chip EMAC. Of course it's open source, but
> so far it's not committed into mainline tree. We can be found at here:
> http://www.blackfin.uclinux.org
Please send me a copy of the driver source that you were using when
this happened.
> My driver didn't assign any value to skb->ip_summed, and didn't
> define tx/rx checksum routine like "e1000_rx_checksum", but it did
> work before on 2.6.12. I'm trying to find what's broken.
Could you please add a printk in checksum_udp to print out the pertinent
values such as the expected checksum and actual checksum?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: via_rhine/qdisc Dead loop on netdevice eth1, fix it urgently!
From: Herbert Xu @ 2006-04-23 11:31 UTC (permalink / raw)
To: James Bourne; +Cc: netdev
In-Reply-To: <Pine.LNX.4.58.0604140935220.4085@ldap2.hardrock.org>
On Fri, Apr 14, 2006 at 03:51:15PM +0000, James Bourne wrote:
>
> Apr 14 08:32:54 bama kernel: [<c02becbb>] netpoll_send_skb+0xa8/0x100 [<f8c4c174>] write_msg+0x140/0x181 [netconsole]
This is the culprit. Disable that and the problem will go away.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] bcm43xx: make PIO mode usable
From: Michael Buesch @ 2006-04-23 11:23 UTC (permalink / raw)
To: John W. Linville; +Cc: Andrew Morton, netdev, bcm43xx-dev
[-- Attachment #1: Type: text/plain, Size: 10100 bytes --]
Please apply this to 2.6.17, because it can be used
as a tempoary workaround for people with the >1G problem.
--
This patch fixes PIO mode on the softmac bcm43xx
driver. (A dscape patch will follow).
It mainly fixes endianess issues.
This patch is tested on PowerPC32 and i386.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_dma.h
===================================================================
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_dma.h 2006-04-11 06:26:46.000000000 +0200
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_dma.h 2006-04-22 16:47:51.000000000 +0200
@@ -213,6 +213,14 @@
void bcm43xx_dma_rx(struct bcm43xx_dmaring *ring)
{
}
+static inline
+void bcm43xx_dma_tx_suspend(struct bcm43xx_dmaring *ring)
+{
+}
+static inline
+void bcm43xx_dma_tx_resume(struct bcm43xx_dmaring *ring)
+{
+}
#endif /* CONFIG_BCM43XX_DMA */
#endif /* BCM43xx_DMA_H_ */
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_pio.c
===================================================================
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_pio.c 2006-04-11 06:26:46.000000000 +0200
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_pio.c 2006-04-23 13:10:02.000000000 +0200
@@ -27,6 +27,7 @@
#include "bcm43xx_pio.h"
#include "bcm43xx_main.h"
#include "bcm43xx_xmit.h"
+#include "bcm43xx_power.h"
#include <linux/delay.h>
@@ -44,10 +45,10 @@
bcm43xx_pio_write(queue, BCM43xx_PIO_TXDATA,
octet);
bcm43xx_pio_write(queue, BCM43xx_PIO_TXCTL,
- BCM43xx_PIO_TXCTL_WRITEHI);
+ BCM43xx_PIO_TXCTL_WRITELO);
} else {
bcm43xx_pio_write(queue, BCM43xx_PIO_TXCTL,
- BCM43xx_PIO_TXCTL_WRITEHI);
+ BCM43xx_PIO_TXCTL_WRITELO);
bcm43xx_pio_write(queue, BCM43xx_PIO_TXDATA,
octet);
}
@@ -103,7 +104,7 @@
bcm43xx_pio_write(queue, BCM43xx_PIO_TXDATA,
skb->data[skb->len - 1]);
bcm43xx_pio_write(queue, BCM43xx_PIO_TXCTL,
- BCM43xx_PIO_TXCTL_WRITEHI |
+ BCM43xx_PIO_TXCTL_WRITELO |
BCM43xx_PIO_TXCTL_COMPLETE);
} else {
bcm43xx_pio_write(queue, BCM43xx_PIO_TXCTL,
@@ -112,9 +113,10 @@
}
static u16 generate_cookie(struct bcm43xx_pioqueue *queue,
- int packetindex)
+ struct bcm43xx_pio_txpacket *packet)
{
u16 cookie = 0x0000;
+ int packetindex;
/* We use the upper 4 bits for the PIO
* controller ID and the lower 12 bits
@@ -135,6 +137,7 @@
default:
assert(0);
}
+ packetindex = pio_txpacket_getindex(packet);
assert(((u16)packetindex & 0xF000) == 0x0000);
cookie |= (u16)packetindex;
@@ -184,7 +187,7 @@
bcm43xx_generate_txhdr(queue->bcm,
&txhdr, skb->data, skb->len,
(packet->xmitted_frags == 0),
- generate_cookie(queue, pio_txpacket_getindex(packet)));
+ generate_cookie(queue, packet));
tx_start(queue);
octets = skb->len + sizeof(txhdr);
@@ -241,7 +244,7 @@
queue->tx_devq_packets++;
queue->tx_devq_used += octets;
- assert(packet->xmitted_frags <= packet->txb->nr_frags);
+ assert(packet->xmitted_frags < packet->txb->nr_frags);
packet->xmitted_frags++;
packet->xmitted_octets += octets;
}
@@ -257,8 +260,14 @@
unsigned long flags;
struct bcm43xx_pio_txpacket *packet, *tmp_packet;
int err;
+ u16 txctl;
bcm43xx_lock_mmio(bcm, flags);
+
+ txctl = bcm43xx_pio_read(queue, BCM43xx_PIO_TXCTL);
+ if (txctl & BCM43xx_PIO_TXCTL_SUSPEND)
+ goto out_unlock;
+
list_for_each_entry_safe(packet, tmp_packet, &queue->txqueue, list) {
assert(packet->xmitted_frags < packet->txb->nr_frags);
if (packet->xmitted_frags == 0) {
@@ -288,6 +297,7 @@
next_packet:
continue;
}
+out_unlock:
bcm43xx_unlock_mmio(bcm, flags);
}
@@ -330,12 +340,19 @@
(unsigned long)queue);
value = bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD);
- value |= BCM43xx_SBF_XFER_REG_BYTESWAP;
+ value &= ~BCM43xx_SBF_XFER_REG_BYTESWAP;
bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD, value);
qsize = bcm43xx_read16(bcm, queue->mmio_base + BCM43xx_PIO_TXQBUFSIZE);
+ if (qsize == 0) {
+ printk(KERN_ERR PFX "ERROR: This card does not support PIO "
+ "operation mode. Please use DMA mode "
+ "(module parameter pio=0).\n");
+ goto err_freequeue;
+ }
if (qsize <= BCM43xx_PIO_TXQADJUST) {
- printk(KERN_ERR PFX "PIO tx device-queue too small (%u)\n", qsize);
+ printk(KERN_ERR PFX "PIO tx device-queue too small (%u)\n",
+ qsize);
goto err_freequeue;
}
qsize -= BCM43xx_PIO_TXQADJUST;
@@ -444,15 +461,10 @@
{
struct bcm43xx_pioqueue *queue = bcm43xx_current_pio(bcm)->queue1;
struct bcm43xx_pio_txpacket *packet;
- u16 tmp;
assert(!queue->tx_suspended);
assert(!list_empty(&queue->txfree));
- tmp = bcm43xx_pio_read(queue, BCM43xx_PIO_TXCTL);
- if (tmp & BCM43xx_PIO_TXCTL_SUSPEND)
- return -EBUSY;
-
packet = list_entry(queue->txfree.next, struct bcm43xx_pio_txpacket, list);
packet->txb = txb;
packet->xmitted_frags = 0;
@@ -462,7 +474,7 @@
assert(queue->nr_txfree < BCM43xx_PIO_MAXTXPACKETS);
/* Suspend TX, if we are out of packets in the "free" queue. */
- if (unlikely(list_empty(&queue->txfree))) {
+ if (list_empty(&queue->txfree)) {
netif_stop_queue(queue->bcm->net_dev);
queue->tx_suspended = 1;
}
@@ -480,15 +492,15 @@
queue = parse_cookie(bcm, status->cookie, &packet);
assert(queue);
-//TODO
-if (!queue)
-return;
+
free_txpacket(packet, 1);
- if (unlikely(queue->tx_suspended)) {
+ if (queue->tx_suspended) {
queue->tx_suspended = 0;
netif_wake_queue(queue->bcm->net_dev);
}
- /* If there are packets on the txqueue, poke the tasklet. */
+ /* If there are packets on the txqueue, poke the tasklet
+ * to transmit them.
+ */
if (!list_empty(&queue->txqueue))
tasklet_schedule(&queue->txtask);
}
@@ -519,12 +531,9 @@
int i, preamble_readwords;
struct sk_buff *skb;
-return;
tmp = bcm43xx_pio_read(queue, BCM43xx_PIO_RXCTL);
- if (!(tmp & BCM43xx_PIO_RXCTL_DATAAVAILABLE)) {
- dprintkl(KERN_ERR PFX "PIO RX: No data available\n");//TODO: remove this printk.
+ if (!(tmp & BCM43xx_PIO_RXCTL_DATAAVAILABLE))
return;
- }
bcm43xx_pio_write(queue, BCM43xx_PIO_RXCTL,
BCM43xx_PIO_RXCTL_DATAAVAILABLE);
@@ -538,8 +547,7 @@
return;
data_ready:
-//FIXME: endianess in this function.
- len = le16_to_cpu(bcm43xx_pio_read(queue, BCM43xx_PIO_RXDATA));
+ len = bcm43xx_pio_read(queue, BCM43xx_PIO_RXDATA);
if (unlikely(len > 0x700)) {
pio_rx_error(queue, 0, "len > 0x700");
return;
@@ -555,7 +563,7 @@
preamble_readwords = 18 / sizeof(u16);
for (i = 0; i < preamble_readwords; i++) {
tmp = bcm43xx_pio_read(queue, BCM43xx_PIO_RXDATA);
- preamble[i + 1] = cpu_to_be16(tmp);//FIXME?
+ preamble[i + 1] = cpu_to_le16(tmp);
}
rxhdr = (struct bcm43xx_rxhdr *)preamble;
rxflags2 = le16_to_cpu(rxhdr->flags2);
@@ -591,16 +599,40 @@
}
skb_put(skb, len);
for (i = 0; i < len - 1; i += 2) {
- tmp = cpu_to_be16(bcm43xx_pio_read(queue, BCM43xx_PIO_RXDATA));
- *((u16 *)(skb->data + i)) = tmp;
+ tmp = bcm43xx_pio_read(queue, BCM43xx_PIO_RXDATA);
+ *((u16 *)(skb->data + i)) = cpu_to_le16(tmp);
}
if (len % 2) {
tmp = bcm43xx_pio_read(queue, BCM43xx_PIO_RXDATA);
skb->data[len - 1] = (tmp & 0x00FF);
+/* The specs say the following is required, but
+ * it is wrong and corrupts the PLCP. If we don't do
+ * this, the PLCP seems to be correct. So ifdef it out for now.
+ */
+#if 0
if (rxflags2 & BCM43xx_RXHDR_FLAGS2_TYPE2FRAME)
- skb->data[0x20] = (tmp & 0xFF00) >> 8;
+ skb->data[2] = (tmp & 0xFF00) >> 8;
else
- skb->data[0x1E] = (tmp & 0xFF00) >> 8;
+ skb->data[0] = (tmp & 0xFF00) >> 8;
+#endif
}
+ skb_trim(skb, len - IEEE80211_FCS_LEN);
bcm43xx_rx(queue->bcm, skb, rxhdr);
}
+
+void bcm43xx_pio_tx_suspend(struct bcm43xx_pioqueue *queue)
+{
+ bcm43xx_power_saving_ctl_bits(queue->bcm, -1, 1);
+ bcm43xx_pio_write(queue, BCM43xx_PIO_TXCTL,
+ bcm43xx_pio_read(queue, BCM43xx_PIO_TXCTL)
+ | BCM43xx_PIO_TXCTL_SUSPEND);
+}
+
+void bcm43xx_pio_tx_resume(struct bcm43xx_pioqueue *queue)
+{
+ bcm43xx_pio_write(queue, BCM43xx_PIO_TXCTL,
+ bcm43xx_pio_read(queue, BCM43xx_PIO_TXCTL)
+ & ~BCM43xx_PIO_TXCTL_SUSPEND);
+ bcm43xx_power_saving_ctl_bits(queue->bcm, -1, -1);
+ tasklet_schedule(&queue->txtask);
+}
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_pio.h
===================================================================
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_pio.h 2006-04-11 06:26:46.000000000 +0200
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_pio.h 2006-04-22 16:47:17.000000000 +0200
@@ -14,8 +14,8 @@
#define BCM43xx_PIO_RXCTL 0x08
#define BCM43xx_PIO_RXDATA 0x0A
-#define BCM43xx_PIO_TXCTL_WRITEHI (1 << 0)
-#define BCM43xx_PIO_TXCTL_WRITELO (1 << 1)
+#define BCM43xx_PIO_TXCTL_WRITELO (1 << 0)
+#define BCM43xx_PIO_TXCTL_WRITEHI (1 << 1)
#define BCM43xx_PIO_TXCTL_COMPLETE (1 << 2)
#define BCM43xx_PIO_TXCTL_INIT (1 << 3)
#define BCM43xx_PIO_TXCTL_SUSPEND (1 << 7)
@@ -95,6 +95,7 @@
u16 offset, u16 value)
{
bcm43xx_write16(queue->bcm, queue->mmio_base + offset, value);
+ mmiowb();
}
@@ -107,6 +108,9 @@
struct bcm43xx_xmitstatus *status);
void bcm43xx_pio_rx(struct bcm43xx_pioqueue *queue);
+void bcm43xx_pio_tx_suspend(struct bcm43xx_pioqueue *queue);
+void bcm43xx_pio_tx_resume(struct bcm43xx_pioqueue *queue);
+
#else /* CONFIG_BCM43XX_PIO */
static inline
@@ -133,6 +137,14 @@
void bcm43xx_pio_rx(struct bcm43xx_pioqueue *queue)
{
}
+static inline
+void bcm43xx_pio_tx_suspend(struct bcm43xx_pioqueue *queue)
+{
+}
+static inline
+void bcm43xx_pio_tx_resume(struct bcm43xx_pioqueue *queue)
+{
+}
#endif /* CONFIG_BCM43XX_PIO */
#endif /* BCM43xx_PIO_H_ */
--
Greetings Michael.
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: Van Jacobson's net channels and real-time
From: Avi Kivity @ 2006-04-23 9:23 UTC (permalink / raw)
To: Ingo Oeser
Cc: Jörn Engel, Ingo Oeser, David S. Miller, simlo, linux-kernel,
mingo, netdev
In-Reply-To: <200604221529.59899.ioe-lkml@rameria.de>
Ingo Oeser wrote:
> Hi Jörn,
>
> On Saturday, 22. April 2006 13:48, Jörn Engel wrote:
>
>> Unless I completely misunderstand something, one of the main points of
>> the netchannels if to have *zero* fields written to by both producer
>> and consumer.
>>
>
> Hmm, for me the main point was to keep the complete processing
> of a single packet within one CPU/Core where this is a non-issue.
>
But the interrupt for a packet can be received by cpu 0 whereas the rest
of processing proceeds on cpu 1; so it still helps to keep the producer
index and consumer index on separate cachelines.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Your Invoice is Ready
From: Joni Slaughter @ 2006-04-23 8:37 UTC (permalink / raw)
To: netdev
"Cia-lis Sof`tabs" is better than Pfizer V`ia`g`ra
and normal Ci-ialis because:
- Guarantes 40 hours lasting
- Safe to take, no side efects at all
- Boost and increase se-xual performance
- Harder e`rectiiions and quick recharge
- Proven and certified by experts and doctors
- only $1.56 per tabs
- Special offeer! These prices
- are valid until 30th of April!
Clisk here: http://shubuobbctr.info
inscription autosuggestible dashboard confusion carol antonym bestseller cloth eben ladyfern
shareholder intimate bacterial lifeblood quito digitalis fluorspar cowpunch drainage
dynamo mine rock breakwater alcoa tarpon kankakee dodecahedra alumna arcturus noose
surjection dad d occipital yukon waggle jar annihilate
vestal ablution deadwood resin bizet pinscher drought busch
extolling abram audible serine balinese baldwin turbinate brothel
^ permalink raw reply
* Re: Van Jacobson's net channels and real-time
From: David S. Miller @ 2006-04-23 5:56 UTC (permalink / raw)
To: netdev; +Cc: simlo, linux-kernel, mingo, netdev, ioe-lkml
In-Reply-To: <200604211852.47335.netdev@axxeo.de>
From: Ingo Oeser <netdev@axxeo.de>
Date: Fri, 21 Apr 2006 18:52:47 +0200
> nice to see you getting started with it.
Thanks for reviewing.
> I'm not sure about the queue logic there.
>
> 1867 /* Caller must have exclusive producer access to the netchannel. */
> 1868 int netchannel_enqueue(struct netchannel *np, struct netchannel_buftrailer *bp)
> 1869 {
> 1870 unsigned long tail;
> 1871
> 1872 tail = np->netchan_tail;
> 1873 if (tail == np->netchan_head)
> 1874 return -ENOMEM;
>
> This looks wrong, since empty and full are the same condition in your
> case.
Thanks, that's obviously wrong. I'll try to fix this up.
> What about sth. like
>
> struct netchannel {
> /* This is only read/written by the writer (producer) */
> unsigned long write_ptr;
> struct netchannel_buftrailer *netchan_queue[NET_CHANNEL_ENTRIES];
>
> /* This is modified by both */
> atomic_t filled_entries; /* cache_line_align this? */
>
> /* This is only read/written by the reader (consumer) */
> unsigned long read_ptr;
> }
As stated elsewhere, if you add atomic operations you break the entire
idea of net channels. They are meant to be SMP efficient data structures
where the producer has one cache line that only it dirties and the
consumer has one cache line that likewise only it dirties.
> If cacheline bouncing because of the shared filled_entries becomes an issue,
> you are receiving or sending a lot.
Cacheline bouncing is the core issue being addressed by this
data structure, so we really can't consider your idea seriously.
I've just got an off-by-one error, no need to wreck the entire
data structure just to solve that :-)
^ permalink raw reply
* Re: [PATCH 00/10] e1000: Driver fixes and update to 7.0.38-k2
From: David S. Miller @ 2006-04-23 5:53 UTC (permalink / raw)
To: herbert
Cc: jgarzik, auke-jan.h.kok, netdev, john.ronciak, jesse.brandeburg,
Jeffrey.t.kirsher, auke
In-Reply-To: <E1FXAa6-0001Wt-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat, 22 Apr 2006 15:22:54 +1000
> Jeff Garzik <jgarzik@pobox.com> wrote:
> >
> >> 05/10: [PATCH] Update truesize with the length of the packet for
> >> packet split
> >
> > These 10 patches look OK, but since the current kernel version is
> > 2.6.17-rc1, that means we are in "bug fix only" mode right now.
> >
> > Should I (a) apply these all to netdev2-.6.git#upstream, queueing them
> > for 2.6.18, or (b) let you split the submission into two parts, bug
> > fixes only and everything else?
>
> It turns out that the truesize patch is pretty important as otherwise
> most of TCP receive socket buffer accounting falls apart. So it should
> probably go into 2.6.17 and even 2.6.16-stable.
I totally agree.
Jeff please try to get at least this skb->truesize fix queued
to both -stable and current 2.6.x, it's really needed and
important for proper socket memory accounting on receive with
e1000.
Thanks.
^ permalink raw reply
* Re: Van Jacobson's net channels and real-time
From: David S. Miller @ 2006-04-23 5:53 UTC (permalink / raw)
To: bert.hubert; +Cc: simlo, linux-kernel, mingo, netdev
In-Reply-To: <20060422193024.GA29040@outpost.ds9a.nl>
From: bert hubert <bert.hubert@netherlabs.nl>
Date: Sat, 22 Apr 2006 21:30:24 +0200
> On Thu, Apr 20, 2006 at 12:09:55PM -0700, David S. Miller wrote:
> > Going all the way to the socket is a large endeavor and will require a
> > lot of restructuring to do it right, so expect this to take on the
> > order of months.
>
> That's what you said about Niagara too :-)
I'm just trying to keep the expectations low so it's easier
to exceed them :-)
^ permalink raw reply
* Re: Van Jacobson's net channels and real-time
From: David S. Miller @ 2006-04-23 5:52 UTC (permalink / raw)
To: ioe-lkml; +Cc: joern, netdev, simlo, linux-kernel, mingo, netdev
In-Reply-To: <200604221529.59899.ioe-lkml@rameria.de>
From: Ingo Oeser <ioe-lkml@rameria.de>
Date: Sat, 22 Apr 2006 15:29:58 +0200
> On Saturday, 22. April 2006 13:48, Jörn Engel wrote:
> > Unless I completely misunderstand something, one of the main points of
> > the netchannels if to have *zero* fields written to by both producer
> > and consumer.
>
> Hmm, for me the main point was to keep the complete processing
> of a single packet within one CPU/Core where this is a non-issue.
Both are the important issues.
You move the bulk of the packet processing work to the end
cores of the system, yes. But you do so with an enormously
SMP friendly queue data structure so that it does not matter
at all that the packet is received on one cpu, yet processed
in socket context on another.
If you elide either part of the implementation, you miss the
entire point of net channels.
^ permalink raw reply
* Re: Van Jacobson's net channels and real-time
From: David S. Miller @ 2006-04-23 5:51 UTC (permalink / raw)
To: joern; +Cc: netdev, simlo, linux-kernel, mingo, netdev, ioe-lkml
In-Reply-To: <20060422114846.GA6629@wohnheim.fh-wedel.de>
From: Jörn Engel <joern@wohnheim.fh-wedel.de>
Date: Sat, 22 Apr 2006 13:48:46 +0200
> Unless I completely misunderstand something, one of the main points of
> the netchannels if to have *zero* fields written to by both producer
> and consumer. Receiving and sending a lot can be expected to be the
> common case, so taking a performance hit in this case is hardly a good
> idea.
That's absolutely correct, this is absolutely critical to
the implementation.
If you're doing any atomic operations, or any write operations by both
consumer and producer to the same cacheline, you've broken things :-)
^ permalink raw reply
* Re: Van Jacobson's net channels and real-time
From: David S. Miller @ 2006-04-23 5:50 UTC (permalink / raw)
To: ioe-lkml; +Cc: joern, netdev, simlo, linux-kernel, mingo, netdev
In-Reply-To: <200604230205.33668.ioe-lkml@rameria.de>
From: Ingo Oeser <ioe-lkml@rameria.de>
Date: Sun, 23 Apr 2006 02:05:32 +0200
> On Saturday, 22. April 2006 15:49, Jörn Engel wrote:
> > That was another main point, yes. And the endpoints should be as
> > little burden on the bottlenecks as possible. One bottleneck is the
> > receive interrupt, which shouldn't wait for cachelines from other cpus
> > too much.
>
> Thats right. This will be made a non issue with early demuxing
> on the NIC and MSI (or was it MSI-X?) which will select
> the right CPU based on hardware channels.
It is not clear that MSI'ing the RX interrupt to multiple cpus is the
answer.
Consider the fact that by doing so you're reducing the amount of batch
work each interrupt does by a factor N. One of the biggest gains of
NAPI btw is that it batches patcket receive, if you don't believe the
benefits of this put a simply cycle counter sample around
netif_receive_skb() calls, and note the difference between the first
packet processed and subsequent ones, it's several orders of magnitude
faster to process subsequent packets within a batch. I've done this
before on tg3 with sparc64 and posted the numbers on netdev about a
year or so ago.
If you are doing something like netchannels, it helps to batch so that
the demuxing table stays hot in the cpu cache.
There is even talk of dedicating a thread on enormously multi-
threaded cpus just to the NIC hardware interrupt, so it could net
channel to the socket processes running on the other strands.
^ permalink raw reply
* Re: Fw: [Bug 6421] New: kernel 2.6.10-2.6.16 on alpha: arch/alpha/kernel/io.c, iowrite16_rep() BUG_ON((unsigned long)src & 0x1) triggered
From: Herbert Xu @ 2006-04-23 5:49 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: p_gortmaker, netdev, tomri
In-Reply-To: <E1FXXNS-0003dJ-00@gondolin.me.apana.org.au>
On Sun, Apr 23, 2006 at 03:43:22PM +1000, Herbert Xu wrote:
>
> Can you please put some printks in to find out if
>
> 1) skb_padto is being called.
> 2) Is the input to skb_padto aligned?
I'd also help if you could print out the contents of the packet itself.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Fw: [Bug 6421] New: kernel 2.6.10-2.6.16 on alpha: arch/alpha/kernel/io.c, iowrite16_rep() BUG_ON((unsigned long)src & 0x1) triggered
From: Herbert Xu @ 2006-04-23 5:43 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: p_gortmaker, netdev, tomri
In-Reply-To: <20060421102757.45d26db0@localhost.localdomain>
<tomri@gmx.net> wrote:
>
> And the output in the kernel ring buffer is:
> dmesg | grep xmit
> ei_start_xmit(): skb->data unaligned fffffc0019be55d5 align to fffffc001ef37620
> length 60
Very weird. The length seems to indicate that this packet went through
skb_padto. However, I can't see how skb_padto can produce an unaligned
skb if the input was aligned (the input coming out of TCP should definitely
be aligned).
Can you please put some printks in to find out if
1) skb_padto is being called.
2) Is the input to skb_padto aligned?
> Here some stack traces with BUG_ON/ WARN_ON added by me in more places to trace
> down the problem:
> Kernel bug at net/ipv4/ip_output.c:297
> cc1(2841): Kernel Bug 1
> pc = [<fffffc000062a92c>] ra = [<fffffc00006407c8>] ps = 0000 Not tainted
> pc is at ip_queue_xmit+0x59c/0x690
> ra is at tcp_transmit_skb+0x588/0xbb0
This is pretty meaningless if you don't show us the check that you added
to produce this.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: ipsec tunnel asymmetrical mtu
From: Herbert Xu @ 2006-04-23 3:51 UTC (permalink / raw)
To: Marco Berizzi; +Cc: herbert, netdev
In-Reply-To: <BAY103-F21399F30719D1EBD180B04B2CC0@phx.gbl>
Marco Berizzi <pupilla@hotmail.com> wrote:
>
> Is there any news about this issue?
Sorry for the delay, I've been travelling.
The fact that tcpdump with "host 172.16.0.138" does not fix it tells
us that this is related to the NAT that you're doing to the 172.16
side of the network.
Looking at your packet dump your setup is definitely suboptimal in
that correct MTU information is not being provided to either side
of the connection.
The result is that the 10.16 end is sending fragments which have to
be reassembled at mimosa before immediately getting refragmented on
its way to pleiadi.
So if it was my network this would be the first issue I'd try to
address, possibly through MSS clamping.
However, the fact that the tcpdump causes more chunky packets to
make it through could be an indication that there is a bug somewhere
in our NAT/IPsec code or at least a suboptimal memory allocation
strategy that's somehow avoided when AF_PACKET pins the skb down.
So I would like your help in tracking that down before you fix your
network properly.
For a start could you please send me the complete kern.log messages
on mimosa from boot time to the point after a slow connection has
occured. I'd also like to see /proc/net/snmp at that point.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Van Jacobson's net channels and real-time
From: Ingo Oeser @ 2006-04-23 0:05 UTC (permalink / raw)
To: Jörn Engel
Cc: Ingo Oeser, David S. Miller, simlo, linux-kernel, mingo, netdev
In-Reply-To: <20060422134956.GC6629@wohnheim.fh-wedel.de>
On Saturday, 22. April 2006 15:49, Jörn Engel wrote:
> That was another main point, yes. And the endpoints should be as
> little burden on the bottlenecks as possible. One bottleneck is the
> receive interrupt, which shouldn't wait for cachelines from other cpus
> too much.
Thats right. This will be made a non issue with early demuxing
on the NIC and MSI (or was it MSI-X?) which will select
the right CPU based on hardware channels.
In the meantime I would reduce the effects with only committing
on full buffer or on leaving the interrupt handler.
This would be ok, because here you have to wakeup the process
anyway on full buffer and if it slept because of empty buffer.
You loose only, if your application didn't sleep yet and you need to
leave the interrupt handler because there is no work anymore.
In this case the atomic_add would be significant.
All this is quite similiar to now we do page_vec stuff in mm/ already.
Regards
Ingo Oeser
^ permalink raw reply
* Fw: sky2 driver network freeze while transfering data
From: Andrew Morton @ 2006-04-22 23:21 UTC (permalink / raw)
To: netdev; +Cc: thomas klein
Begin forwarded message:
Date: Sat, 22 Apr 2006 12:45:44 +0200
From: thomas klein <tkl@laposte.net>
To: linux-kernel@vger.kernel.org
Subject: sky2 driver network freeze while transfering data
pitfall@archon:~/kernel/linux-2.6.16.9$ sh scripts/ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux archon 2.6.15-20-686 #1 SMP PREEMPT Tue Apr 4 18:37:00 UTC 2006
i686 GNU/Linux
Gnu C 4.0.3
Gnu make 3.81beta4
binutils 2.16.91
util-linux 2.12r
mount 2.12r
module-init-tools 3.2.2
e2fsprogs 1.38
jfsutils 1.1.8
reiserfsprogs 3.6.19
reiser4progs 1.0.5
xfsprogs 2.7.7
pcmcia-cs 3.2.8
Linux C Library 2.3.6
Dynamic linker (ldd) 2.3.6
Procps 3.2.6
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 5.93
udev 079pitfall@archon:~/kernel/linux-2.6.16.9$ sh
scripts/ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux archon 2.6.15-20-686 #1 SMP PREEMPT Tue Apr 4 18:37:00 UTC 2006
i686 GNU/Linux
Gnu C 4.0.3
Gnu make 3.81beta4
binutils 2.16.91
util-linux 2.12r
mount 2.12r
module-init-tools 3.2.2
e2fsprogs 1.38
jfsutils 1.1.8
reiserfsprogs 3.6.19
reiser4progs 1.0.5
xfsprogs 2.7.7
pcmcia-cs 3.2.8
Linux C Library 2.3.6
Dynamic linker (ldd) 2.3.6
Procps 3.2.6
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 5.93
udev 079
Modules Loaded binfmt_misc rfcomm l2cap bluetooth sonypi
speedstep_centrino cpufreq_userspace cpufreq_stats freq_table
cpufreq_powersave cpufreq_ondemand cpufreq_conservative video
tc1100_wmi sony_acpi pcc_acpi hotkey dev_acpi container button
acpi_sbs battery ac i2c_acpi_ec ipv6 dm_mod af_packet md_mod sr_mod
sbp2 parport_pc lp parport pcmcia joydev yenta_socket rsrc_nonstatic
ohci1394 sky2 pcmcia_core ieee1394 nvidia i2c_core rtc psmouse
serio_raw snd_hda_intel snd_hda_codec snd_pcm_oss snd_mixer_oss
snd_pcm snd_timer snd soundcore snd_page_alloc shpchp pci_hotplug
intel_agp agpgart tsdev evdev sg usbhid ext3 jbd ide_generic ehci_hcd
uhci_hcd usbcore sd_mod ata_piix libata scsi_mod ide_cd cdrom piix
generic thermal processor fan capability commoncap vga16fb vgastate
fbcon tileblit font bitblit softcursor
Modules Loaded binfmt_misc rfcomm l2cap bluetooth sonypi
speedstep_centrino cpufreq_userspace cpufreq_stats freq_table
cpufreq_powersave cpufreq_ondemand cpufreq_conservative video
tc1100_wmi sony_acpi pcc_acpi hotkey dev_acpi container button
acpi_sbs battery ac i2c_acpi_ec ipv6 dm_mod af_packet md_mod sr_mod
sbp2 parport_pc lp parport pcmcia joydev yenta_socket rsrc_nonstatic
ohci1394 sky2 pcmcia_core ieee1394 nvidia i2c_core rtc psmouse
serio_raw snd_hda_intel snd_hda_codec snd_pcm_oss snd_mixer_oss
snd_pcm snd_timer snd soundcore snd_page_alloc shpchp pci_hotplug
intel_agp agpgart tsdev evdev sg usbhid ext3 jbd ide_generic ehci_hcd
uhci_hcd usbcore sd_mod ata_piix libata scsi_mod ide_cd cdrom piix
generic thermal processor fan capability commoncap vga16fb vgastate
fbcon tileblit font bitblit softcursor
This is the stock kernel I'm using... I tried the latest 2.6.16.9, the
problem was the same.
Problem :
0000:07:00.0 Ethernet controller: Marvell Technology Group Ltd.
88E8036 Fast Ethernet Controller (rev 15)
I can browse the web, check emails etc... but, If I try some rsync
from my old laptop (to backup my stuff) the network freeze after 1 or
2minutes.
the bug is reproductible.
I don't have logs each time, but, sometimes I got this
Apr 15 11:35:42 archon kernel: [4297572.802000] NETDEV WATCHDOG:
eth0: transmit timed out
Apr 15 11:35:42 archon kernel: [4297572.802000] sky2 hardware hung?
flushing
same freeze with the 2.6.16.9
thanks in advance,
thomas.
PS : I didn't subscribe any linux ml, can I see any progress on this
report somewhere ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH 8/10] d80211: get rid of default management interface
From: Jouni Malinen @ 2006-04-22 2:44 UTC (permalink / raw)
To: Jiri Benc; +Cc: netdev
In-Reply-To: <20060421205328.39BE2482C1@silver.suse.cz>
On Fri, Apr 21, 2006 at 10:53:28PM +0200, Jiri Benc wrote:
> Default management interface (wlanXap) confuses users. It is only needed for
> AP mode (and only until interfaces are converted to use native 802.11
> frames).
Or when using user space MLME in client mode which is something that I
just got working as far as scanning and association is concerned. In
other words, wpa_supplicant will be needing this interface..
> This patch removes default management interface. When a new interface is
> switched to AP mode, a management interface is created automatically. This
> also fixes some problems with multiple AP interfaces - now you have
> different management interface for each AP interface.
That sounds like something that could break multi-BSSID/SSID aware
hostapd. Are you saying that there would be new wlanXap like interface
for each BSS/VLAN interface? What are the problems this is fixing with
multiple AP interfaces? So far, hostapd has been responsible for
receiving all management from a single interface and then internally
decide which BSS/multi-SSID entry to use for each.
I would assume that hostapd could be changed to process frames from
multiple interfaces (at least if this is only for multi-BSSID, not for
multi-SSID/VLAN case). There may be some special cases, where it would
be easier to just be able to use one interface. Likewise, I would expect
single interface to be closer to a design that would be using netlink
for getting management frames into user space.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: Van Jacobson's net channels and real-time
From: Jörn Engel @ 2006-04-22 11:48 UTC (permalink / raw)
To: Ingo Oeser
Cc: David S. Miller, simlo, linux-kernel, mingo, netdev, Ingo Oeser
In-Reply-To: <200604211852.47335.netdev@axxeo.de>
On Fri, 21 April 2006 18:52:47 +0200, Ingo Oeser wrote:
> What about sth. like
>
> struct netchannel {
> /* This is only read/written by the writer (producer) */
> unsigned long write_ptr;
> struct netchannel_buftrailer *netchan_queue[NET_CHANNEL_ENTRIES];
>
> /* This is modified by both */
> atomic_t filled_entries; /* cache_line_align this? */
>
> /* This is only read/written by the reader (consumer) */
> unsigned long read_ptr;
> }
>
> This would prevent this bug from the beginning and let us still use the
> full queue size.
>
> If cacheline bouncing because of the shared filled_entries becomes an issue,
> you are receiving or sending a lot.
Unless I completely misunderstand something, one of the main points of
the netchannels if to have *zero* fields written to by both producer
and consumer. Receiving and sending a lot can be expected to be the
common case, so taking a performance hit in this case is hardly a good
idea.
I haven't looked at Davem's implementation at all, but Van simply
seperated fields in consumer-written and producer-written, with proper
alignment between them. Some consumer-written fields are also read by
the producer and vice versa. But none of this results in cacheline
pingpong.
If your description of the problem is correct, it should only mean
that the implementation has a problem, not the concept.
Jörn
--
Time? What's that? Time is only worth what you do with it.
-- Theo de Raadt
^ permalink raw reply
* Hosting Solutions
From: Marcus Echols @ 2006-04-22 13:35 UTC (permalink / raw)
To: netdev
-Sensattional revolution in medicine!
-Enlarge your penis up to 10 cm or up to 4 inches!
-It's herbal solution what hasn't side effect, but has 100% guaranted results!
-Don't lose your chance and but know wihtout doubts, you will be i`mpressed with results!
Clisk here: http://flomatrix.info
birgit monarchy walton remedial prone lanky disc beachhead hepatica mcguire
lansing seismograph saloonkeep surreptitious inviable deer modulus sen holt
tactician copperas assyriology conspire recurred opposable singe salvation jeopardy claudia trigonal
ant began enquire cavernous bred chlorophyll pegboard potatoes
libel carcinogenic emitted sibling chaise hashish grove announce
camber christendom larynx dynast hovel guzzle fourteenth armhole
^ permalink raw reply
* Re: Van Jacobson's net channels and real-time
From: Jörn Engel @ 2006-04-22 13:49 UTC (permalink / raw)
To: Ingo Oeser
Cc: Ingo Oeser, David S. Miller, simlo, linux-kernel, mingo, netdev
In-Reply-To: <200604221529.59899.ioe-lkml@rameria.de>
On Sat, 22 April 2006 15:29:58 +0200, Ingo Oeser wrote:
> On Saturday, 22. April 2006 13:48, Jörn Engel wrote:
> > Unless I completely misunderstand something, one of the main points of
> > the netchannels if to have *zero* fields written to by both producer
> > and consumer.
>
> Hmm, for me the main point was to keep the complete processing
> of a single packet within one CPU/Core where this is a non-issue.
That was another main point, yes. And the endpoints should be as
little burden on the bottlenecks as possible. One bottleneck is the
receive interrupt, which shouldn't wait for cachelines from other cpus
too much.
Jörn
--
Why do musicians compose symphonies and poets write poems?
They do it because life wouldn't have any meaning for them if they didn't.
That's why I draw cartoons. It's my life.
-- Charles Shultz
^ permalink raw reply
* Re: [PATCH TESTING] bcm43xx PIO mode
From: Michael Buesch @ 2006-04-22 20:07 UTC (permalink / raw)
To: bcm43xx-dev; +Cc: netdev
In-Reply-To: <200604221718.54245.mb@bu3sch.de>
[-- Attachment #1: Type: text/plain, Size: 414 bytes --]
On Saturday 22 April 2006 17:18, you wrote:
> bcm43xx_lock_mmio(bcm, flags);
> +
> + txctl = bcm43xx_pio_read(queue, BCM43xx_PIO_TXCTL);
> + if (txctl & BCM43xx_PIO_TXCTL_SUSPEND)
> + return;
Ah, and yes, I see the bug here. :)
But that normally does not trigger anyway. So no problem
for testing.
And I forgot to say that PIO mode is enabled by module
parameter pio=1
--
Greetings Michael.
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox