[BUG] 2.6.33-rc1 gianfar error message

[BUG] 2.6.33-rc1 gianfar error message

[Michael Guntsche]

Hi,

I recently installed 2.6.33-rc1 on my Routerboard RB600a to give it a
quick test. After rebooting with 2.6.33-rc1 I got an almost immediate error 
message in my logs.

Sorry for not being able to get more debug info. But with this board I have a
limit on the kernel size.

wan selects TX queue 66, but real number of TX queues is 1
------------[ cut here ]------------
Badness at c01d846c [verbose debug info unavailable]
NIP: c01d846c LR: c01d846c CTR: c0159344
REGS: c0391b70 TRAP: 0700   Not tainted  (2.6.33-rc1)
MSR: 00029032 <EE,ME,CE,IR,DR>  CR: 24002024  XER: 20000000
TASK = c03733e8[0] 'swapper' THREAD: c0390000
GPR00: c01d846c c0391c20 c03733e8 0000004d 00003112 ffffffff c0159ebc c03756f0
GPR08: c039e7fc c0370000 00007fff 00003112 84002024 1001afc0 c78eb200 c031b38c
GPR16: 00000001 c031b3b8 00000000 c7967800 00000000 00000001 c780abec c780a800
GPR24: c780b000 c780b000 c581b300 c780b000 c79d96c0 c79d96c0 00000000 00000042
NIP [c01d846c] dev_queue_xmit+0x534/0x550
LR [c01d846c] dev_queue_xmit+0x534/0x550
Call Trace:
[c0391c20] [c01d846c] dev_queue_xmit+0x534/0x550 (unreliable)
[c0391c50] [c01e02bc] neigh_resolve_output+0xfc/0x26c
[c0391c80] [c0217354] ip_finish_output+0x2c0/0x300
[c0391ca0] [c0213e0c] ip_forward_finish+0x48/0x64
[c0391cb0] [c021263c] ip_rcv_finish+0x1a8/0x3b0
[c0391ce0] [c01d6a98] netif_receive_skb+0x2a4/0x530
[c0391d20] [c01a0998] gfar_clean_rx_ring+0xe0/0x43c
[c0391d70] [c01a1178] gfar_poll+0x484/0x598
[c0391e10] [c01d7688] net_rx_action+0xf0/0x1b4
[c0391e50] [c002651c] __do_softirq+0xb0/0x130
[c0391e90] [c0006294] do_softirq+0x58/0x5c
[c0391ea0] [c0026310] irq_exit+0x7c/0x9c
[c0391eb0] [c0006334] do_IRQ+0x9c/0xb4
[c0391ed0] [c0011dd8] ret_from_except+0x0/0x14
--- Exception: 501 at cpu_idle+0xdc/0xec
    LR = cpu_idle+0xdc/0xec
[c0391f90] [c0009378] cpu_idle+0x58/0xec (unreliable)
[c0391fb0] [c0003ea8] rest_init+0x5c/0x74
[c0391fc0] [c0346760] start_kernel+0x234/0x27c
[c0391ff0] [00003438] 0x3438
Instruction dump:
480d6491 4bfffdc0 7fe3fb78 3bc00000 480122c1 4bfffc00 80db019c 3c60c032
7fe5fb78 7f64db78 3863f000 480d6465 <0fe00000> 4bfffeec 3c60c032 7f64db78
lan selects TX queue 66, but real number of TX queues is 1
------------[ cut here ]------------
Badness at c01d846c [verbose debug info unavailable]
NIP: c01d846c LR: c01d846c CTR: c0159344
REGS: c5857690 TRAP: 0700   Tainted: G        W   (2.6.33-rc1)
MSR: 00029032 <EE,ME,CE,IR,DR>  CR: 24242422  XER: 20000000
TASK = c7b7d200[596] 'dnsmasq' THREAD: c5856000
GPR00: c01d846c c5857740 c7b7d200 0000004d 00003ae4 ffffffff c0159ebc c03756f0
GPR08: c039e7fc c038ecf4 00007fff 00003ae4 84242424 1004335c c78eb380 c031b38c
GPR16: 00000001 c031b3b8 00000000 c797c800 00000000 00000001 c780b3ec c780b000
GPR24: c780a800 c780a800 c7b90f00 c780a800 c5882180 c5882180 00000000 00000042
NIP [c01d846c] dev_queue_xmit+0x534/0x550
LR [c01d846c] dev_queue_xmit+0x534/0x550
Call Trace:
[c5857740] [c01d846c] dev_queue_xmit+0x534/0x550 (unreliable)
[c5857770] [c01e02bc] neigh_resolve_output+0xfc/0x26c
[c58577a0] [c0217354] ip_finish_output+0x2c0/0x300
[c58577c0] [c0213e0c] ip_forward_finish+0x48/0x64
[c58577d0] [c021263c] ip_rcv_finish+0x1a8/0x3b0
[c5857800] [c01d6a98] netif_receive_skb+0x2a4/0x530
[c5857840] [c01a0998] gfar_clean_rx_ring+0xe0/0x43c
[c5857890] [c01a1178] gfar_poll+0x484/0x598
[c5857930] [c01d7688] net_rx_action+0xf0/0x1b4
[c5857970] [c002651c] __do_softirq+0xb0/0x130
[c58579b0] [c0006294] do_softirq+0x58/0x5c
[c58579c0] [c0026310] irq_exit+0x7c/0x9c
[c58579d0] [c0006334] do_IRQ+0x9c/0xb4
[c58579f0] [c0011dd8] ret_from_except+0x0/0x14
--- Exception: 501 at sock_poll+0x20/0x38
    LR = do_select+0x2a8/0x4f0
[c5857ab0] [c009954c] poll_schedule_timeout+0x3c/0x60 (unreliable)
[c5857ac0] [c009a0bc] do_select+0x2a8/0x4f0
[c5857dc0] [c009a598] core_sys_select+0x294/0x388
[c5857f10] [c009a970] sys_select+0x40/0x138
[c5857f40] [c0011740] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xfe3864c
    LR = 0x10015860
Instruction dump:
480d6491 4bfffdc0 7fe3fb78 3bc00000 480122c1 4bfffc00 80db019c 3c60c032
7fe5fb78 7f64db78 3863f000 480d6465 <0fe00000> 4bfffeec 3c60c032 7f64db78

Both NICs continue to work but the messages continue to appear in the log
with the number (66) varying a little bit every now and then.

I had a look at the recent changes and started testing the different commits. I
found out that I start getting the errors with commmit

fba4ed030cfae7efdb6b79a57b0c5a9d72c9de83
gianfar: Add Multiple Queue Support

Relevant dmesg output:
eth0: Gianfar Ethernet Controller Version 1.2, 00:0c:42:28:de:4e
eth0: Running with NAPI enabled
eth0: :RX BD ring size for Q[0]: 256
eth0:TX BD ring size for Q[0]: 256
  alloc irq_desc for 32 on node 0
  alloc kstat_irqs on node 0
irq: irq 32 on host /soc8343@e0000000/pic@700 mapped to virtual irq 32
  alloc irq_desc for 33 on node 0
  alloc kstat_irqs on node 0
irq: irq 33 on host /soc8343@e0000000/pic@700 mapped to virtual irq 33
  alloc irq_desc for 34 on node 0[    0.546127]   alloc kstat_irqs on node 0
irq: irq 34 on host /soc8343@e0000000/pic@700 mapped to virtual irq 34
eth1: Gianfar Ethernet Controller Version 1.2, 00:0c:42:28:de:4f
eth1: Running with NAPI enabled
eth1: :RX BD ring size for Q[0]: 256
eth1:TX BD ring size for Q[0]: 256
Freescale PowerQUICC MII Bus: probed
Freescale PowerQUICC MII Bus: probed

If you need any more information please tell me.

Kind regards,
Michael

RE: [BUG] 2.6.33-rc1 gianfar error message

[Kumar Gopalpet-B05799]

>
>I recently installed 2.6.33-rc1 on my Routerboard RB600a to 
>give it a quick test. After rebooting with 2.6.33-rc1 I got an 
>almost immediate error message in my logs.
>
>Sorry for not being able to get more debug info. But with this 
>board I have a limit on the kernel size.
>
>wan selects TX queue 66, but real number of TX queues is 1 
>------------[ cut here ]------------ Badness at c01d846c 
[...]

>3c60c032 7f64db78 lan selects TX queue 66, but real number of 
>TX queues is 1 ------------[ cut here ]------------ Badness at 
>c01d846c [verbose debug info unavailable]
[...]
>Both NICs continue to work but the messages continue to appear 
>in the log with the number (66) varying a little bit every now 
>and then.
>
>I had a look at the recent changes and started testing the 
>different commits. I found out that I start getting the errors 
>with commmit
>
>fba4ed030cfae7efdb6b79a57b0c5a9d72c9de83
>gianfar: Add Multiple Queue Support
>
>Relevant dmesg output:
>eth0: Gianfar Ethernet Controller Version 1.2, 00:0c:42:28:de:4e
>eth0: Running with NAPI enabled
>eth0: :RX BD ring size for Q[0]: 256
>eth0:TX BD ring size for Q[0]: 256
>  alloc irq_desc for 32 on node 0
>  alloc kstat_irqs on node 0
>irq: irq 32 on host /soc8343@e0000000/pic@700 mapped to virtual irq 32
>  alloc irq_desc for 33 on node 0
>  alloc kstat_irqs on node 0
>irq: irq 33 on host /soc8343@e0000000/pic@700 mapped to virtual irq 33
>  alloc irq_desc for 34 on node 0[    0.546127]   alloc 
>kstat_irqs on node 0
>irq: irq 34 on host /soc8343@e0000000/pic@700 mapped to virtual irq 34
>eth1: Gianfar Ethernet Controller Version 1.2, 00:0c:42:28:de:4f
>eth1: Running with NAPI enabled
>eth1: :RX BD ring size for Q[0]: 256
>eth1:TX BD ring size for Q[0]: 256
>Freescale PowerQUICC MII Bus: probed
>Freescale PowerQUICC MII Bus: probed
>
>If you need any more information please tell me.
>

Hi Michael,

It looks like even we are enabling only single tx queue, some how it is
trying to pick up tx queue 66. 

Can you please let me know what is your test setup and, please give me
the location from where you cloned this kernel. 
Can you also share the dts file you were using ?

--

Thanks
Sandeep 

Re: [BUG] 2.6.33-rc1 gianfar error message

[Michael Guntsche]

[-- Attachment #1: Type: text/plain, Size: 820 bytes --]

On 21 Dec 09 09:58, Kumar Gopalpet-B05799 wrote:
> Hi Michael,
> 
> It looks like even we are enabling only single tx queue, some how it is
> trying to pick up tx queue 66. 
> 
> Can you please let me know what is your test setup and, please give me
The hardware used is a Mikrotik Routerboard RB600a, which is 83xx based.
It has three NICs two of them being gianfar devices.

> the location from where you cloned this kernel. 
The kernel used is vanilla 2.6.33-rc1 from git.kernel.org plus the Board
specific patches. The patches do not change anything on the network or
driver side, they just add ATA, nand and board specific support to the
kernel. If you want I can provide a git repo for it.

> Can you also share the dts file you were using ?
Attached you will find the DTS file being used.

Kind regards,
Michael


[-- Attachment #2: rb600.dts --]
[-- Type: text/plain, Size: 5157 bytes --]

/*
 * Routerboard RB600 Device Tree Source
 */

/dts-v1/;

/ {
	model = "RB600";
	compatible = "MPC83xx";
	#address-cells = <1>;
	#size-cells = <1>;

	aliases {
		ethernet0 = &enet0;
		ethernet1 = &enet1;
	};


	chosen {
		linux,stdout-path = "/soc8343@e0000000/serial@4500";
	};

	cpus {
		#address-cells = <1>;
		#size-cells = <0>;

		PowerPC,8343E@0 {
			device_type = "cpu";
			reg = <0x0>;
			d-cache-line-size = <0x20>;
			i-cache-line-size = <0x20>;
			d-cache-size = <0x8000>;
			i-cache-size = <0x8000>;
			timebase-frequency = <0x0000000>; // filled by the bootwrapper from the firmware blob
			clock-frequency = <0x00000000>; // filled by the bootwrapper from the firmware blob
		};
	};

	memory {
		device_type = "memory";
		reg = <0x0 0x0000000>; // filled by the bootwrapper from the firmware blob
	};

	cf@f9200000 {
		lb-timings = <0x5dc 0x3e8 0x1194 0x5dc 0x2af8>;
		interrupt-at-level = <0x0>;
		interrupt-parent = <&ipic>;
		interrupts = <0x16 0x8>;
		lbc_extra_divider = <0x1>;
		reg = <0xf9200000 0x200000>;
		device_type = "rb,cf";
	};

	cf@f9000000 {
		lb-timings = <0x5dc 0x3e8 0x1194 0x5dc 0x2af8>;
		interrupt-at-level = <0x0>;
		interrupt-parent = <&ipic>;
		interrupts = <0x14 0x8>;
		lbc_extra_divider = <0x1>;
		reg = <0xf9000000 0x200000>;
		device_type = "rb,cf";
	};

	flash {
		reg = <0xff800000 0x20000>;
	};

	nnand {
		reg = <0xf0000000 0x1000>;
	};

	nand {
		ale = <&gpio 0x6>;
		cle = <&gpio 0x5>;
		nce = <&gpio 0x4>;
		rdy = <&gpio 0x3>;
		reg = <0xf8000000 0x1000>;
		device_type = "rb,nand";
	};

	fancon {
		interrupt-parent = <&ipic>;
		interrupts = <0x17 0x8>;
		sense = <&gpio 0x7>;
		fan_on = <&gpio 0x9>;
	};

	pci0: pci@e0008500 {
		device_type = "pci";
		compatible = "fsl,mpc8349-pci";
		reg = <0xe0008500 0x100 0xe0008300 0x8>;
		#address-cells = <3>;
		#size-cells = <2>;
		#interrupt-cells = <1>;
		ranges = <0x2000000 0x0 0x80000000 0x80000000 0x0 0x20000000 0x1000000 0x0 0x0 0xd0000000 0x0 0x4000000>;
		bus-range = <0x0 0x0>;
		interrupt-map = <
		0x5800 0x0 0x0 0x1 &ipic 0x15 0x8
		0x6000 0x0 0x0 0x1 &ipic 0x30 0x8
		0x6000 0x0 0x0 0x2 &ipic 0x11 0x8
		0x6800 0x0 0x0 0x1 &ipic 0x11 0x8
		0x6800 0x0 0x0 0x2 &ipic 0x12 0x8
		0x7000 0x0 0x0 0x1 &ipic 0x12 0x8
		0x7000 0x0 0x0 0x2 &ipic 0x13 0x8
		0x7800 0x0 0x0 0x1 &ipic 0x13 0x8
		0x7800 0x0 0x0 0x2 &ipic 0x30 0x8
		0x8000 0x0 0x0 0x1 &ipic 0x30 0x8
		0x8000 0x0 0x0 0x2 &ipic 0x12 0x8
		0x8000 0x0 0x0 0x3 &ipic 0x11 0x8
		0x8000 0x0 0x0 0x4 &ipic 0x13 0x8
		0xa000 0x0 0x0 0x1 &ipic 0x30 0x8
		0xa000 0x0 0x0 0x2 &ipic 0x11 0x8
		0xa000 0x0 0x0 0x3 &ipic 0x12 0x8
		0xa000 0x0 0x0 0x4 &ipic 0x13 0x8
		0xa800 0x0 0x0 0x1 &ipic 0x11 0x8
		0xa800 0x0 0x0 0x2 &ipic 0x12 0x8
		0xa800 0x0 0x0 0x3 &ipic 0x13 0x8
		0xa800 0x0 0x0 0x4 &ipic 0x30 0x8>;
		interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
		interrupt-parent = <&ipic>;
		};


	soc8343@e0000000 {
		#address-cells = <1>;
		#size-cells = <1>;
		device_type = "soc";
		compatible = "simple-bus";
		ranges = <0x0 0xe0000000 0x100000>;
		reg = <0xe0000000 0x200>;
		bus-frequency = <0x1>;

		led {
			user_led = <&gpio 0x8>;
		};

		beeper {
			reg = <0x500 0x100>;
		};

		gpio: gpio@0 {
			#gpio-cells = <2>;
			compatible = "fsl,mpc8349-gpio";
			reg = <0xc08 0x4>;
			interrupt-parent = <&ipic>;
			gpio-controller;
		};

		enet0: ethernet@25000 {
			#address-cells = <1>;
			#size-cells = <1>;
			cell-index = <0>;
			phy-handle = <&phy0>;
			tbi-handle = <&tbi0>;
			interrupt-parent = <&ipic>;
			interrupts = <0x23 0x8 0x24 0x8 0x25 0x8>;
			local-mac-address = [00 00 00 00 00 00];
			reg = <0x25000 0x1000>;
			ranges = <0x0 0x25000 0x1000>;
			compatible = "gianfar";
			model = "TSEC";
			device_type = "network";

			mdio@520 {
				#address-cells = <1>;
				#size-cells = <0>;
				compatible = "fsl,gianfar-tbi";
				reg = <0x520 0x20>;

				tbi0: tbi-phy@11 {
					reg = <0x11>;
					device_type = "tbi-phy";
				};
			};
		};

		enet1: ethernet@24000 {
			#address-cells = <1>;
			#size-cells = <1>;
			cell-index = <1>;
			phy-handle = <&phy1>;
			tbi-handle = <&tbi1>;
			interrupt-parent = <&ipic>;
			interrupts = <0x20 0x8 0x21 0x8 0x22 0x8>;
			local-mac-address = [00 00 00 00 00 00];
			reg = <0x24000 0x1000>;
			ranges = <0x0 0x24000 0x1000>;
			compatible = "gianfar";
			model = "TSEC";
			device_type = "network";

			mdio@520 {
				#size-cells = <0x0>;
				#address-cells = <0x1>;
				reg = <0x520 0x20>;
				compatible = "fsl,gianfar-mdio";

				phy0: ethernet-phy@0 {
					device_type = "ethernet-phy";
					reg = <0x0>;
				};

				phy1: ethernet-phy@1 {
					device_type = "ethernet-phy";
					reg = <0x1>;
				};

				tbi1: tbi-phy@11 {
					reg = <0x11>;
					device_type = "tbi-phy";
				};
			};
		};



		ipic: pic@700 {
			interrupt-controller;
			#address-cells = <0>;
			#interrupt-cells = <2>;
			reg = <0x700 0x100>;
			device_type = "ipic";
		};

		serial@4500 {
			interrupt-parent = <&ipic>;
			interrupts = <0x9 0x8>;
			clock-frequency = <0xfe4f840>;
			reg = <0x4500 0x100>;
			compatible = "ns16550";
			device_type = "serial";
		};

		wdt@200 {
			reg = <0x200 0x100>;
			compatible = "mpc83xx_wdt";
			device_type = "watchdog";
		};
	};
};

RE: [BUG] 2.6.33-rc1 gianfar error message

[Kumar Gopalpet-B05799]

 

>-----Original Message-----
>From: Michael Guntsche [mailto:mike@it-loops.com] 
>Sent: Monday, December 21, 2009 12:57 PM
>To: Kumar Gopalpet-B05799
>Cc: netdev
>Subject: Re: [BUG] 2.6.33-rc1 gianfar error message
>
>On 21 Dec 09 09:58, Kumar Gopalpet-B05799 wrote:
>> Hi Michael,
>> 
>> It looks like even we are enabling only single tx queue, some how it 
>> is trying to pick up tx queue 66.
>> 
>> Can you please let me know what is your test setup and, 
>please give me
>The hardware used is a Mikrotik Routerboard RB600a, which is 
>83xx based.
>It has three NICs two of them being gianfar devices.
>
>> the location from where you cloned this kernel. 
>The kernel used is vanilla 2.6.33-rc1 from git.kernel.org plus 
>the Board specific patches. The patches do not change anything 
>on the network or driver side, they just add ATA, nand and 
>board specific support to the kernel. If you want I can 
>provide a git repo for it.
>
>> Can you also share the dts file you were using ?
>Attached you will find the DTS file being used.
>
>Kind regards,
>Michael
>
>
Michael, 

Kindly try the following changes at your side and let me know the
results. I couldn't test this
as I don't have any TSEC device with me.

diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index e0620d0..4577d90 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -2470,10 +2470,11 @@ static int gfar_process_frame(struct net_device
*dev, struct sk_buff *skb,
        fcb = (struct rxfcb *)skb->data;

        /* Remove the FCB from the skb */
-       skb_set_queue_mapping(skb, fcb->rq);
        /* Remove the padded bytes, if there are any */
-       if (amount_pull)
+       if (amount_pull) {
+               skb_set_queue_mapping(skb, fcb->rq);
                skb_pull(skb, amount_pull);
+       }

        if (priv->rx_csum_enable)
                gfar_rx_checksum(skb, fcb);
@@ -2555,6 +2556,7 @@ int gfar_clean_rx_ring(struct gfar_priv_rx_q
*rx_queue, int rx_work_limit)
                                skb_put(skb, pkt_len);
                                rx_queue->stats.rx_bytes += pkt_len;

+                               skb_set_queue_mapping(skb,
rx_queue->qindex);
                                gfar_process_frame(dev, skb,
amount_pull);

                        } else {
--

Re: [BUG] 2.6.33-rc1 gianfar error message

[Michael Guntsche]

On 21 Dec 09 14:19, Kumar Gopalpet-B05799 wrote:
> Michael, 
> 
> Kindly try the following changes at your side and let me know the
> results. I couldn't test this
> as I don't have any TSEC device with me.
<snip>

Your patch did not apply to vanilla 2.6.32-rc1 at all. I patched the
code myself and up to now I do not see any error messages. Uptime is at
33 minutes, without the patch the error message appeared immediately
after booting.

Just for my understanding. Is the first diff part of the fix as well?
With this change the FCB is only removed if there are padded bytes, why
would this make a difference here?

Kind regards,
Michael

RE: [BUG] 2.6.33-rc1 gianfar error message

[Kumar Gopalpet-B05799]

 

>-----Original Message-----
>From: Michael Guntsche [mailto:mike@it-loops.com] 
>Sent: Monday, December 21, 2009 10:09 PM
>To: Kumar Gopalpet-B05799
>Cc: netdev
>Subject: Re: [BUG] 2.6.33-rc1 gianfar error message
>
>On 21 Dec 09 14:19, Kumar Gopalpet-B05799 wrote:
>> Michael,
>> 
>> Kindly try the following changes at your side and let me know the 
>> results. I couldn't test this as I don't have any TSEC 
>device with me.
><snip>
>
>Your patch did not apply to vanilla 2.6.32-rc1 at all. I patched the
>code myself and up to now I do not see any error messages. Uptime is at
>33 minutes, without the patch the error message appeared immediately
>after booting.
>
I am sorry about that, I forgot to mention that my patch was against
net-next-2.6 tree.

>Just for my understanding. Is the first diff part of the fix as well?
>With this change the FCB is only removed if there are padded bytes, why
>would this make a difference here?
>

Yes, the first diff portion is not required.

Also, if you confirm that the changes are working fine.
I will generate a clean patch and send it out.
Thanks for reporting it and testing it out.

--

Thanks
Sandeep

Re: [BUG] 2.6.33-rc1 gianfar error message

[Michael Guntsche]

On 22 Dec 09 10:32, Kumar Gopalpet-B05799 wrote:
> >Just for my understanding. Is the first diff part of the fix as well?
> >With this change the FCB is only removed if there are padded bytes, why
> >would this make a difference here?
> >
> 
> Yes, the first diff portion is not required.
> 
> Also, if you confirm that the changes are working fine.
> I will generate a clean patch and send it out.
> Thanks for reporting it and testing it out.

Hi,

I have now an uptime of 20 hours with no error messages so far. I had
one ppp disconnect but I think this was ADSL related. 

I will continue running this kernel for now to test it some more but I
think the initial problem I was seeing is fixed now.

Kind regards,
Michael

Re: [BUG] 2.6.33-rc1 gianfar error message

[Michael Guntsche]

On 2009.12.22 10:32:49 , Kumar Gopalpet-B05799 wrote:
> >Just for my understanding. Is the first diff part of the fix as well?
> >With this change the FCB is only removed if there are padded bytes, why
> >would this make a difference here?
> >
> 
> Yes, the first diff portion is not required.
> 
> Also, if you confirm that the changes are working fine.
> I will generate a clean patch and send it out.
> Thanks for reporting it and testing it out.

Hi,

Since you said that the first patch is not needed

@@ -2470,10 +2470,11 @@ static int gfar_process_frame(struct net_device
        fcb = (struct rxfcb *)skb->data;

        /* Remove the FCB from the skb */
-       skb_set_queue_mapping(skb, fcb->rq);
        /* Remove the padded bytes, if there are any */
-       if (amount_pull)
+       if (amount_pull) {
+               skb_set_queue_mapping(skb, fcb->rq);
                skb_pull(skb, amount_pull);
+       }

        if (priv->rx_csum_enable)
                gfar_rx_checksum(skb, fcb);

I only applied the second one and tested again. Right after the reboot I got an error so apparently this change IS required as well. 

Kind regards,
Michael 

Re: [BUG] 2.6.33-rc1 gianfar error message

[Michael Guntsche]

On 2009.12.22 19:10:00 , Michael Guntsche wrote:
> Since you said that the first patch is not needed
> 
> @@ -2470,10 +2470,11 @@ static int gfar_process_frame(struct net_device
>         fcb = (struct rxfcb *)skb->data;
> 
>         /* Remove the FCB from the skb */
> -       skb_set_queue_mapping(skb, fcb->rq);
>         /* Remove the padded bytes, if there are any */
> -       if (amount_pull)
> +       if (amount_pull) {
> +               skb_set_queue_mapping(skb, fcb->rq);
>                 skb_pull(skb, amount_pull);
> +       }
> 
>         if (priv->rx_csum_enable)
>                 gfar_rx_checksum(skb, fcb);
> 
> I only applied the second one and tested again. Right after the reboot
> I got an error so apparently this change IS required as well. 

I tested this now in the opposite direction and apparently ONLY this
patch is needed. I commented out the second diff and did not get any
errors so far. Sorry for not testing this before sending my previous
mail.

Kind regards,
Michael

RE: [BUG] 2.6.33-rc1 gianfar error message

[Kumar Gopalpet-B05799]

 

>-----Original Message-----
>From: Michael Guntsche [mailto:mike@it-loops.com] 
>Sent: Tuesday, December 22, 2009 11:58 PM
>To: Kumar Gopalpet-B05799
>Cc: netdev
>Subject: Re: [BUG] 2.6.33-rc1 gianfar error message
>
>On 2009.12.22 19:10:00 , Michael Guntsche wrote:
>> Since you said that the first patch is not needed
>> 
>> @@ -2470,10 +2470,11 @@ static int gfar_process_frame(struct 
>net_device
>>         fcb = (struct rxfcb *)skb->data;
>> 
>>         /* Remove the FCB from the skb */
>> -       skb_set_queue_mapping(skb, fcb->rq);
>>         /* Remove the padded bytes, if there are any */
>> -       if (amount_pull)
>> +       if (amount_pull) {
>> +               skb_set_queue_mapping(skb, fcb->rq);
>>                 skb_pull(skb, amount_pull);
>> +       }
>> 
>>         if (priv->rx_csum_enable)
>>                 gfar_rx_checksum(skb, fcb);
>> 
>> I only applied the second one and tested again. Right after 
>the reboot 
>> I got an error so apparently this change IS required as well.
>
>I tested this now in the opposite direction and apparently 
>ONLY this patch is needed. I commented out the second diff and 
>did not get any errors so far. Sorry for not testing this 
>before sending my previous mail.
>

Ok. Thanks !

>Kind regards,
>Michael
>
>