Re: linux-next: Tree for June 26

Re: linux-next: Tree for June 26

[Rafael J. Wysocki]

On Thursday, 26 of June 2008, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since next-20080625:
> 
> The tip-core tree lost its three conflicts against Linus' tree.
> 
> The pci tree gained two conflicts against the x86 tree.
> 
> The v4l-dvb tree had the second revert undone.  We will see if this is
> right.
> 
> The net tree gained a conflict against the wireless-current tree.
> 
> The vfs tree lost its conflict against the sched tree.
> 
> The arm tree lost its conflict against Linus' tree.
> 
> The rr tree gained a patch for a build problem instead the revert.
> 
> The firmware tree lost a conflict against the usb tree.

commit 423c982fffb1cd95c8cdd654ce5ab59351ba41f5
Author: Jaswinder Singh <jaswinder-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Date:   Wed Jun 18 19:58:33 2008 +0530

    firmware: convert tg3 driver to request_firmware()

breaks my nx6325.

Apparently, with this patch applied the tg3 has a NULL pointer dereference
somewhere, but I can only see the first line of the oops, afterwards the box
hangs solid.

Please drop it if possible.

Also, arch/x86/kernel/io_apic_64.c seems wrong at the moment, as it checks
for conditions that are never satisfied etc.

Thanks,
Rafael

Re: linux-next: Tree for June 26

[David Woodhouse]

On Fri, 2008-06-27 at 01:38 +0200, Rafael J. Wysocki wrote:
> Apparently, with this patch applied the tg3 has a NULL pointer
> dereference somewhere, but I can only see the first line of the oops,
> afterwards the box hangs solid.
> 
> Please drop it if possible.

I'll take a careful look over it for problems, and will drop it for now
if I can't find the cause. I did post it for review, but just got
mostly-unrelated noise rather than anyone looking at the code changes.

-- 
dwmw2

Re: linux-next: Tree for June 26

[David Woodhouse]

On Fri, 2008-06-27 at 01:38 +0200, Rafael J. Wysocki wrote:
> commit 423c982fffb1cd95c8cdd654ce5ab59351ba41f5
> Author: Jaswinder Singh <jaswinder@infradead.org>
> Date:   Wed Jun 18 19:58:33 2008 +0530
> 
>     firmware: convert tg3 driver to request_firmware()
> 
> breaks my nx6325.
> 
> Apparently, with this patch applied the tg3 has a NULL pointer dereference
> somewhere, but I can only see the first line of the oops, afterwards the box
> hangs solid.

That's a 5705, isn't it? So using the 'tso5' firmware?

Is that firmware available (did you either build it into your kernel, or
run 'make INSTALL_FW_PATH=/lib/firmware firmware_install')? 

Not that it matters; I suspect the driver isn't trying to load it at
all. Can you test this patch, please?

(There are more cleanups I want to do to the error paths here, but those
should be harmless and irrelevant: http://david.woodhou.se/tg3.patch )

diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index a70147d..bad784b 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -12234,11 +12234,6 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
 
 	if (tp->tg3_flags2 & TG3_FLG2_HW_TSO) {
 		tp->tg3_flags2 |= TG3_FLG2_TSO_CAPABLE;
-
-		if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705)
-			fw_name = "tigon/tg3_tso5.bin";
-		else
-			fw_name = "tigon/tg3_tso.bin";
 	}
 	else if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700 ||
 	    GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701 ||
@@ -12248,6 +12243,13 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
 		tp->tg3_flags2 &= ~TG3_FLG2_TSO_CAPABLE;
 	} else {
 		tp->tg3_flags2 |= TG3_FLG2_TSO_CAPABLE | TG3_FLG2_TSO_BUG;
+		printk("this code path would have forgotten to load the firmware\n");
+	}
+	if (tp->tg3_flags2 & TG3_FLG2_TSO_CAPABLE) {
+		if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705)
+			fw_name = "tigon/tg3_tso5.bin";
+		else
+			fw_name = "tigon/tg3_tso.bin";
 	}
 
 	if (fw_name) {


-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation



---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: linux-next: Tree for June 26

[Kamalesh Babulal]

David Woodhouse wrote:
> On Fri, 2008-06-27 at 01:38 +0200, Rafael J. Wysocki wrote:
>> commit 423c982fffb1cd95c8cdd654ce5ab59351ba41f5
>> Author: Jaswinder Singh <jaswinder@infradead.org>
>> Date:   Wed Jun 18 19:58:33 2008 +0530
>>
>>     firmware: convert tg3 driver to request_firmware()
>>
>> breaks my nx6325.
>>
>> Apparently, with this patch applied the tg3 has a NULL pointer dereference
>> somewhere, but I can only see the first line of the oops, afterwards the box
>> hangs solid.
> 
> That's a 5705, isn't it? So using the 'tso5' firmware?
> 
> Is that firmware available (did you either build it into your kernel, or
> run 'make INSTALL_FW_PATH=/lib/firmware firmware_install')? 
> 
> Not that it matters; I suspect the driver isn't trying to load it at
> all. Can you test this patch, please?
> 
> (There are more cleanups I want to do to the error paths here, but those
> should be harmless and irrelevant: http://david.woodhou.se/tg3.patch )
> 
> diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
> index a70147d..bad784b 100644
> --- a/drivers/net/tg3.c
> +++ b/drivers/net/tg3.c
> @@ -12234,11 +12234,6 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
> 
>  	if (tp->tg3_flags2 & TG3_FLG2_HW_TSO) {
>  		tp->tg3_flags2 |= TG3_FLG2_TSO_CAPABLE;
> -
> -		if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705)
> -			fw_name = "tigon/tg3_tso5.bin";
> -		else
> -			fw_name = "tigon/tg3_tso.bin";
>  	}
>  	else if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700 ||
>  	    GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701 ||
> @@ -12248,6 +12243,13 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
>  		tp->tg3_flags2 &= ~TG3_FLG2_TSO_CAPABLE;
>  	} else {
>  		tp->tg3_flags2 |= TG3_FLG2_TSO_CAPABLE | TG3_FLG2_TSO_BUG;
> +		printk("this code path would have forgotten to load the firmware\n");
> +	}
> +	if (tp->tg3_flags2 & TG3_FLG2_TSO_CAPABLE) {
> +		if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705)
> +			fw_name = "tigon/tg3_tso5.bin";
> +		else
> +			fw_name = "tigon/tg3_tso.bin";
>  	}
> 
>  	if (fw_name) {
> 
Hi David,

Thanks, the patch fixes the kernel panic on x86_64 boxes. (the panic message
is listed below)

Tested-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>

BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
IP: [<ffffffff803be1e8>] tg3_reset_hw+0xf48/0x154b
PGD add0067 PUD ad1a067 PMD 0 
Oops: 0000 [1] SMP 
last sysfs file: /sys/class/net/eth1/address
CPU 2 
Modules linked in: battery ac lp parport_pc parport nvram amd_rng rng_core i2c_amd756 i2c_core pcspkr button
Pid: 1919, comm: ip Not tainted 2.6.26-rc8-next-20080627-autotest #1
RIP: 0010:[<ffffffff803be1e8>]  [<ffffffff803be1e8>] tg3_reset_hw+0xf48/0x154b
RSP: 0018:ffff81000ad21d38  EFLAGS: 00010246
RAX: 000000000040a026 RBX: 000000000001f800 RCX: 0000000000000000
RDX: 0000000000000006 RSI: 0000000000005400 RDI: ffff81003d4e8740
RBP: ffff81003d4e8740 R08: 0000000000000002 R09: 0000000000000008
R10: 0000000000000009 R11: ffffffff804773d9 R12: 0000000001000008
R13: 00000000000003fe R14: ffff81003d4e8748 R15: 0000000000000000
FS:  00007f600a2586f0(0000) GS:ffff81003f99e800(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000008 CR3: 000000000c0c6000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process ip (pid: 1919, threadinfo ffff81000ad20000, task ffff81003d519db0)
Stack:  ffff81003d4e8740 0000000000000074 0000000000000028 ffff000880340430
 ffff81003d4e8740 ffff81003d4e8800 ffff81003d4e8740 0000000000001002
 0000000000000000 ffff81003d4e8748 ffff81003d4e8000 ffffffff803c2a7a
Call Trace:
 [<ffffffff803c2a7a>] tg3_open+0x29a/0x5e8
 [<ffffffff80317af4>] selinux_capable+0x87/0x90
 [<ffffffff80486e13>] dev_open+0x6b/0x9e
 [<ffffffff80484fd8>] dev_change_flags+0xa6/0x15d
 [<ffffffff804c42ed>] devinet_ioctl+0x243/0x59e
 [<ffffffff80278baf>] handle_mm_fault+0x32b/0x6a5
 [<ffffffff80479488>] sock_ioctl+0x1d4/0x1f8
 [<ffffffff8029eb09>] vfs_ioctl+0x21/0x6b
 [<ffffffff8029edaf>] do_vfs_ioctl+0x25c/0x275
 [<ffffffff8029ee19>] sys_ioctl+0x51/0x70
 [<ffffffff8020bcfb>] system_call_after_swapgs+0x7b/0x80


Code: ef e8 63 a0 ff ff 8b 85 88 07 00 00 a8 20 0f 84 06 01 00 00 a9 00 00 01 08 0f 85 fb 00 00 00 48 8b 8d 48 0b 00 00 be 00 54 00 00 <48> 8b 51 08 8b 42 04 48 83 c2 0c 0f c8 89 04 24 8b 01 b9 00 40 
RIP  [<ffffffff803be1e8>] tg3_reset_hw+0xf48/0x154b
 RSP <ffff81000ad21d38>
CR2: 0000000000000008
---[ end trace beeca7990caa7b8a ]---
Kernel panic - not syncing: Aiee, killing interrupt handler!
Pid: 1919, comm: ip Tainted: G      D   2.6.26-rc8-next-20080627-autotest #1

Call Trace:
 [<ffffffff802336e3>] panic+0x86/0x144
 [<ffffffff802530a9>] kallsyms_lookup+0x49/0x80
 [<ffffffff803be1e8>] tg3_reset_hw+0xf48/0x154b
 [<ffffffff80234256>] printk+0x4e/0x56
 [<ffffffff80234256>] printk+0x4e/0x56
 [<ffffffff802367d6>] do_exit+0x71/0x67c
 [<ffffffff804fdbe1>] oops_begin+0x0/0x8c
 [<ffffffff804ffafb>] do_page_fault+0x77b/0x834
 [<ffffffff804fd829>] error_exit+0x0/0x51
 [<ffffffff804773d9>] pci_conf1_write+0x0/0xdb
 [<ffffffff803be1e8>] tg3_reset_hw+0xf48/0x154b
 [<ffffffff803be0b3>] tg3_reset_hw+0xe13/0x154b
 [<ffffffff803c2a7a>] tg3_open+0x29a/0x5e8
 [<ffffffff80317af4>] selinux_capable+0x87/0x90
 [<ffffffff80486e13>] dev_open+0x6b/0x9e
 [<ffffffff80484fd8>] dev_change_flags+0xa6/0x15d
 [<ffffffff804c42ed>] devinet_ioctl+0x243/0x59e
 [<ffffffff80278baf>] handle_mm_fault+0x32b/0x6a5
 [<ffffffff80479488>] sock_ioctl+0x1d4/0x1f8
 [<ffffffff8029eb09>] vfs_ioctl+0x21/0x6b
 [<ffffffff8029edaf>] do_vfs_ioctl+0x25c/0x275
 [<ffffffff8029ee19>] sys_ioctl+0x51/0x70
 [<ffffffff8020bcfb>] system_call_after_swapgs+0x7b/0x80



-- 
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.

Re: linux-next: Tree for June 26

[David Woodhouse]

On Fri, 2008-06-27 at 18:12 +0530, Kamalesh Babulal wrote:
> Thanks, the patch fixes the kernel panic on x86_64 boxes.

Thanks. I'll update my git tree and it should appear in tomorrow's
linux-next.

-- 
dwmw2

Re: linux-next: Tree for June 26

[Rafael J. Wysocki]

On Friday, 27 of June 2008, David Woodhouse wrote:
> On Fri, 2008-06-27 at 01:38 +0200, Rafael J. Wysocki wrote:
> > commit 423c982fffb1cd95c8cdd654ce5ab59351ba41f5
> > Author: Jaswinder Singh <jaswinder-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
> > Date:   Wed Jun 18 19:58:33 2008 +0530
> > 
> >     firmware: convert tg3 driver to request_firmware()
> > 
> > breaks my nx6325.
> > 
> > Apparently, with this patch applied the tg3 has a NULL pointer dereference
> > somewhere, but I can only see the first line of the oops, afterwards the box
> > hangs solid.
> 
> That's a 5705, isn't it? So using the 'tso5' firmware?
> 
> Is that firmware available (did you either build it into your kernel, or
> run 'make INSTALL_FW_PATH=/lib/firmware firmware_install')? 

I built it into the kernel.

> Not that it matters; I suspect the driver isn't trying to load it at
> all. Can you test this patch, please?

Unfortunately, it doesn't help.  The driver either oopses or just doesn't work
(I don't know what exactly causes it to oops, although that only happens during
boot).

However, Ingo wrote that

" the firmware image, if i compare the before and after tg3FwText 
hex dump is blatantly different. Is this some different format, or did 
the "convert to request_firmware()" commit also embed an undocumented 
version jump in the binary blob that is loaded to your card? "

May this be the source of the problem?

Rafael

Re: linux-next: Tree for June 26

[Jaswinder Singh]

Hello Rafael,

I am really sorry for inconvenience.

I do not have this hardware around me to test this patch.
I really need your help to figure out where is problem.

On Sat, 2008-06-28 at 01:04 +0200, Rafael J. Wysocki wrote:
> On Friday, 27 of June 2008, David Woodhouse wrote:
> > On Fri, 2008-06-27 at 01:38 +0200, Rafael J. Wysocki wrote:
> > > commit 423c982fffb1cd95c8cdd654ce5ab59351ba41f5
> > > Author: Jaswinder Singh <jaswinder@infradead.org>
> > > Date:   Wed Jun 18 19:58:33 2008 +0530
> > > 
> > >     firmware: convert tg3 driver to request_firmware()
> > > 
> > > breaks my nx6325.
> > > 
> > > Apparently, with this patch applied the tg3 has a NULL pointer dereference
> > > somewhere, but I can only see the first line of the oops, afterwards the box
> > > hangs solid.
> > 
> > That's a 5705, isn't it? So using the 'tso5' firmware?
> > 

Here is updated patch :-

http://git.infradead.org/users/jaswinder/firm-jsr-2.6.git?a=commitdiff;h=aa8b184d8eb4f1d7b5e37d5ad449fb7c02ad79c2

Original tg3 driver have 3 firmwares :-
1. static const u32 tg3FwText[(TG3_FW_TEXT_LEN / sizeof(u32)) + 1]
2. static const u32 tg3TsoFwText[(TG3_TSO_FW_TEXT_LEN / 4) + 1]
3. static const u32 tg3Tso5FwText[(TG3_TSO5_FW_TEXT_LEN / 4) + 1]

your hardware needs which of the above firmware.

> Unfortunately, it doesn't help.  The driver either oopses or just doesn't work
> (I don't know what exactly causes it to oops, although that only happens during
> boot).
> 

Please give us more info about oops.

You always get oops or sometimes.

If you want I can put some debugging message.

> However, Ingo wrote that
> 
> " the firmware image, if i compare the before and after tg3FwText 
> hex dump is blatantly different. Is this some different format, or did 
> the "convert to request_firmware()" commit also embed an undocumented 
> version jump in the binary blob that is loaded to your card? "
> 
> May this be the source of the problem?
> 

No, firmware is same.

Our Firmware blob looks like this...
	u8 firmware_major
	u8 firmware_minor
	u8 firmware_fix
	u8 pad
	__be32 start_address
	__be32 length (total, including BSS sections to be zeroed)
	data... (in __be32 words, which is native for the firmware)

rest of data is same and you can see it manually.

I am surprise why Ingo is using hex dump and he finds different data.

And I did not received any feedback from Ingo yet.

Thank you,

Jaswinder Singh.

Re: linux-next: Tree for June 26

[David Woodhouse]

On Sat, 2008-06-28 at 01:04 +0200, Rafael J. Wysocki wrote:
> Unfortunately, it doesn't help.  The driver either oopses or just doesn't work
> (I don't know what exactly causes it to oops, although that only happens during
> boot).

Hm, do you get any more useful output with this...?

diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 8c0631b..3bcf128 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -5670,6 +5670,11 @@ static int tg3_load_firmware_cpu(struct tg3 *tp, u32 cpu_base, u32 cpu_scratch_b
 	int err, lock_err, i;
 	void (*write_op)(struct tg3 *, u32, u32);
 
+	printk("%s, base %x scratch %x,%x info %x,%x,%p[%x,%x...]\n",
+	       __func__, cpu_base, cpu_scratch_base, cpu_scratch_size,
+	       info->fw_base, info->fw_len, info->fw_data, info->fw_data[0],
+	       info->fw_data[1]);
+
 	if (cpu_base == TX_CPU_BASE &&
 	    (tp->tg3_flags2 & TG3_FLG2_5705_PLUS)) {
 		printk(KERN_ERR PFX "tg3_load_firmware_cpu: Trying to load "
@@ -5697,12 +5702,18 @@ static int tg3_load_firmware_cpu(struct tg3 *tp, u32 cpu_base, u32 cpu_scratch_b
 		write_op(tp, cpu_scratch_base + i, 0);
 	tw32(cpu_base + CPU_STATE, 0xffffffff);
 	tw32(cpu_base + CPU_MODE, tr32(cpu_base+CPU_MODE)|CPU_MODE_HALT);
-	for (i = 0; i < (info->fw_len / sizeof(u32)); i++)
+	for (i = 0; i < (info->fw_len / sizeof(u32)); i++) {
+		if ((i < 5) || i > ((info->fw_len / 4) - 5))
+			printk("Write word at %x: %x\n", 
+			       cpu_scratch_base +
+			       (info->fw_base & 0xffff) +
+			       (i * sizeof(u32)),
+			       be32_to_cpu(info->fw_data[i]));
 		write_op(tp, (cpu_scratch_base +
 			      (info->fw_base & 0xffff) +
 			      (i * sizeof(u32))),
 			      be32_to_cpu(info->fw_data[i]));
-
+	}
 	err = 0;
 
 out:
@@ -5716,6 +5727,8 @@ static int tg3_load_5701_a0_firmware_fix(struct tg3 *tp)
 	const __be32 *fw_data;
 	int err, i;
 
+	printk("%s, fw %p\n", __func__, tp->fw);
+
 	fw_data = (void *)tp->fw->data;
 
 	/* Firmware blob starts with version numbers, followed by
@@ -5778,6 +5791,8 @@ static int tg3_load_tso_firmware(struct tg3 *tp)
 	if (tp->tg3_flags2 & TG3_FLG2_HW_TSO)
 		return 0;
 
+	printk("%s, fw %p\n", __func__, tp->fw);
+
 	fw_data = (void *)tp->fw->data;
 
 	/* Firmware blob starts with version numbers, followed by
@@ -12253,6 +12268,7 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
 	if (fw_name) {
 		const __be32 *fw_data;
 
+		printk("tg3 request firmware %s\n", fw_name);
 		err = request_firmware(&tp->fw, fw_name, &tp->pdev->dev);
 		if (err) {
 			printk(KERN_ERR "tg3: Failed to load firmware \"%s\"\n",
@@ -12273,7 +12289,9 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
 			err = -EINVAL;
 			goto err_out_fw;
 		}
-	}
+		printk("tg3 loaded fw %s, len %x\n", fw_name, tp->fw_len);
+	} else
+		printk("tg3 no firmware\n");
 
 	/* TSO is on by default on chips that support hardware TSO.
 	 * Firmware TSO on older chips gives lower performance, so it

> However, Ingo wrote that
> 
> " the firmware image, if i compare the before and after tg3FwText 
> hex dump is blatantly different. Is this some different format, or did 
> the "convert to request_firmware()" commit also embed an undocumented 
> version jump in the binary blob that is loaded to your card? "

Where did Ingo write that? Google doesn't show any instance of those
words other than your own quote, and I'm fairly sure he didn't Cc me
when he said it.

The firmware images are a straight binary dump of what was in the driver
in hex form, stored big-endian, and with a header at the beginning thus:
{
  unsigned char major, minor, fix, pad;
  __be32 load_address;
  __be32 length; // including BSS to be zeroed
  __be32 data[];
}

The TEXT/RODATA/DATA regions were all fairly much contiguous anyway, so
they just appear one after the other in the data[] blob. Let's run 'make
firmware_install' and look at usr/lib/firmware/tigon/tg3.bin... (with
'od -A x -t x4' on a big-endian box):

	000000 00000000 08000000 00000a80 00000000
	000010 10000003 00000000 0000000d 0000000d
	000020 3c1d0800 37bd3ffc 03a0f021 3c100800
	   ... text ...
	0009b0 00851024 1443ffe8 00851824 27bd0008
	0009c0 03e00008 00000000 00000000 35373031
	0009d0 726c7341 00000000 00000000 53774576
	   ... data ...
	000a10 6c457272 00000000 00000000 4d61696e
	000a20 43707542 00000000 00000000 00000000
	000a30 00000000 00000000 00000000 00000000
	*
	000a60 00000000 00000000 00000000

That does look like Tg3FwText[] starts at 0xC after the header (with
0x0, 0x10000003, 0x0, 0xd, 0xd, 0x3c1d0800...) as it should. It ends
with 0x00851824, 0x27bd0008, 0x03e00008, 0x0, 0x0 as it should, at
offset 0x9cc in the file (there's a superfluous 0 on the end of each
word array in the driver). Then you see tg3FwRodata[] starting
0x35373031, 0x726c7341, 0x0, 0x0, 0x53774576..., and tg3FwData[] is all
zeroes at the end.

I don't think you're using that firmware though; I think you're using
tg3_tso5.bin? That one looks fine to me too -- Tg3Tso5Fw[] starts with
0x0c004003, 0x0, 0x10f04, 0x0, 0x10000003 at offset 0xC in the file, as
it should, and ends at 0xe9C with 0x03e00008, 0xac4b001c, 0x0, 0x0. Then
the 0x50 bytes of Tg3Tso5FwRodata[] appear from 0xe9c-0xeec as they
should. And then there's a gap between the end of the rodata, and
Tg3TsoData[] at 0xf0c.

	000000 01020000 00010000 00000fd8 0c004003
	000010 00000000 00010f04 00000000 10000003
	   ... text ...
	000e80 ac460010 ac470014 ac4a0018 03e00008
	000e90 ac4b001c 00000000 00000000 4d61696e
	000ea0 43707542 00000000 4d61696e 43707541
	   ... rodata ...
	000ee0 6c457272 00000000 00000000 00000000
	000ef0 00000000 00000000 00000000 00000000
	000f00 00000000 00000000 00000000 00000000
	000f10 73746b6f 66666c64 5f76312e 322e3000
	000f20 00000000 00000000 00000000

I went over the binary files quite carefully, have just done so again,
and I don't see a problem with them. If Ingo sees one, then he's
cleverer than me. But quite naughty for not Ccing me when he pointed it
out.

-- 
dwmw2

Re: linux-next: Tree for June 26

[David Woodhouse]

On Sat, 2008-06-28 at 15:24 +0530, Jaswinder Singh wrote:
> Here is updated patch :-
> 
> http://git.infradead.org/users/jaswinder/firm-jsr-2.6.git?a=commitdiff;h=aa8b184d8eb4f1d7b5e37d5ad449fb7c02ad79c2

You can ignore that; it's just the same as today's linux-next (which in
turn is just the same as yesterday's + the patch which fixes the problem
for Kamalesh but not for you + the other minor error path cleanup.

Please could you try the other debugging patch I just sent, on top of
today's linux-next? It should confirm that you're using the 'Tso5'
firmware, as I told Jaswinder yesterday, and give us a little more clue
as to what's going on.

This is your machine, right? ...

http://www.ussg.iu.edu/hypermail/linux/kernel/0709.3/1619.html

tg3.c:v3.81 (September 5, 2007)
ACPI: PCI Interrupt 0000:02:01.0[A] -> GSI 23 (level, low) -> IRQ 23
eth1: Tigon3 [partno(BCM95788A50) rev 3003 PHY(5705)] (PCI:33MHz:32-bit) 10/100/1000Base-T Ethernet 00:17:08:2e:2e:f3
eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[0] TSOcap[1]
eth1: dma_rwctrl[763f0000] dma_mask[32-bit]

 tp->pci_chip_rev_id is 0x3003, which is ASIC_REV_5705.

-- 
dwmw2

Re: linux-next: Tree for June 26

[Ingo Molnar]

* Jaswinder Singh <jaswinder@infradead.org> wrote:

> No, firmware is same.
> 
> Our Firmware blob looks like this...
> 	u8 firmware_major
> 	u8 firmware_minor
> 	u8 firmware_fix
> 	u8 pad
> 	__be32 start_address
> 	__be32 length (total, including BSS sections to be zeroed)
> 	data... (in __be32 words, which is native for the firmware)
> 
> rest of data is same and you can see it manually.
> 
> I am surprise why Ingo is using hex dump and he finds different data.
> 
> And I did not received any feedback from Ingo yet.

sorry - it was just a drive-by comment i made to Rafael while i reacted 
to the x86 portion of his mail - i dont have this tg3 problem myself so 
there's nothing i could report or test. I only looked at the patch that 
was identified and the tg3FwText[] array appeared to be different - but 
as you explain it above, that is OK and the firmware image is the same.

	Ingo

Re: linux-next: Tree for June 26

[Rafael J. Wysocki]

On Saturday, 28 of June 2008, David Woodhouse wrote:
> On Sat, 2008-06-28 at 15:24 +0530, Jaswinder Singh wrote:
> > Here is updated patch :-
> > 
> > http://git.infradead.org/users/jaswinder/firm-jsr-2.6.git?a=commitdiff;h=aa8b184d8eb4f1d7b5e37d5ad449fb7c02ad79c2
> 
> You can ignore that; it's just the same as today's linux-next (which in
> turn is just the same as yesterday's + the patch which fixes the problem
> for Kamalesh but not for you + the other minor error path cleanup.
> 
> Please could you try the other debugging patch I just sent, on top of
> today's linux-next? It should confirm that you're using the 'Tso5'
> firmware, as I told Jaswinder yesterday, and give us a little more clue
> as to what's going on.

I tested with the debug patch on top of
http://git.infradead.org/users/jaswinder/firm-jsr-2.6.git?a=commitdiff;h=aa8b184d8eb4f1d7b5e37d5ad449fb7c02ad79c2

dmesg output is at: http://www.sisk.pl/kernel/debug/20080627/dmesg-1.log
the .config is at: http://www.sisk.pl/kernel/debug/20080627/config-1

and it looks like the card just can't load the firmware.

> This is your machine, right? ...
> 
> http://www.ussg.iu.edu/hypermail/linux/kernel/0709.3/1619.html

Yes, this is the one.

Thanks,
Rafael

Re: linux-next: Tree for June 26

[David Woodhouse]

On Sun, 2008-06-29 at 02:15 +0200, Rafael J. Wysocki wrote:
> On Saturday, 28 of June 2008, David Woodhouse wrote:
> > On Sat, 2008-06-28 at 15:24 +0530, Jaswinder Singh wrote:
> > > Here is updated patch :-
> > > 
> > > http://git.infradead.org/users/jaswinder/firm-jsr-2.6.git?a=commitdiff;h=aa8b184d8eb4f1d7b5e37d5ad449fb7c02ad79c2
> > 
> > You can ignore that; it's just the same as today's linux-next (which in
> > turn is just the same as yesterday's + the patch which fixes the problem
> > for Kamalesh but not for you + the other minor error path cleanup.
> > 
> > Please could you try the other debugging patch I just sent, on top of
> > today's linux-next? It should confirm that you're using the 'Tso5'
> > firmware, as I told Jaswinder yesterday, and give us a little more clue
> > as to what's going on.
> 
> I tested with the debug patch on top of
> http://git.infradead.org/users/jaswinder/firm-jsr-2.6.git?a=commitdiff;h=aa8b184d8eb4f1d7b5e37d5ad449fb7c02ad79c2
> 
> dmesg output is at: http://www.sisk.pl/kernel/debug/20080627/dmesg-1.log
> the .config is at: http://www.sisk.pl/kernel/debug/20080627/config-1
> 
> and it looks like the card just can't load the firmware.

Ah, you have it configured as a module, not built-in. You need to run
'make INSTALL_FW_PATH=/lib/firmware firmware_install'

-- 
dwmw2

Re: linux-next: Tree for June 26

[Rafael J. Wysocki]

On Sunday, 29 of June 2008, David Woodhouse wrote:
> On Sun, 2008-06-29 at 02:15 +0200, Rafael J. Wysocki wrote:
> > On Saturday, 28 of June 2008, David Woodhouse wrote:
> > > On Sat, 2008-06-28 at 15:24 +0530, Jaswinder Singh wrote:
> > > > Here is updated patch :-
> > > > 
> > > > http://git.infradead.org/users/jaswinder/firm-jsr-2.6.git?a=commitdiff;h=aa8b184d8eb4f1d7b5e37d5ad449fb7c02ad79c2
> > > 
> > > You can ignore that; it's just the same as today's linux-next (which in
> > > turn is just the same as yesterday's + the patch which fixes the problem
> > > for Kamalesh but not for you + the other minor error path cleanup.
> > > 
> > > Please could you try the other debugging patch I just sent, on top of
> > > today's linux-next? It should confirm that you're using the 'Tso5'
> > > firmware, as I told Jaswinder yesterday, and give us a little more clue
> > > as to what's going on.
> > 
> > I tested with the debug patch on top of
> > http://git.infradead.org/users/jaswinder/firm-jsr-2.6.git?a=commitdiff;h=aa8b184d8eb4f1d7b5e37d5ad449fb7c02ad79c2
> > 
> > dmesg output is at: http://www.sisk.pl/kernel/debug/20080627/dmesg-1.log
> > the .config is at: http://www.sisk.pl/kernel/debug/20080627/config-1
> > 
> > and it looks like the card just can't load the firmware.
> 
> Ah, you have it configured as a module, not built-in. You need to run
> 'make INSTALL_FW_PATH=/lib/firmware firmware_install'

# make INSTALL_FW_PATH=/lib/firmware firmware_install
make -C /home/rafael/src/linux-next O=/home/rafael/src/build/next/albercik/. firmware_install
make[3]: *** No rule to make target `firmware/acenic/tg1.bin', needed by `/lib/firmware/acenic/tg1.bin'.  Stop.
make[2]: *** [firmware_install] Error 2
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2

Re: linux-next: Tree for June 26

[David Woodhouse]

On Sun, 2008-06-29 at 13:36 +0200, Rafael J. Wysocki wrote:
> # make INSTALL_FW_PATH=/lib/firmware firmware_install
> make -C /home/rafael/src/linux-next
> O=/home/rafael/src/build/next/albercik/. firmware_install
> make[3]: *** No rule to make target `firmware/acenic/tg1.bin', needed
> by `/lib/firmware/acenic/tg1.bin'.  Stop.
> make[2]: *** [firmware_install] Error 2
> make[1]: *** [sub-make] Error 2
> make: *** [all] Error 2

Ah, sorry -- I haven't been testing firmware_install with O= builds very
often, and I seem to have broken it. This should fix it:

--- a/firmware/Makefile
+++ b/firmware/Makefile
@@ -69,7 +69,7 @@ fw-shipped-y :=
 endif
 
 firmware-y    := $(fw-external-y) $(fw-shipped-y)
-firmware-dirs := $(sort $(patsubst %,$(objtree)/$(obj)/%/,$(dir $(firmware-y))))
+firmware-dirs := $(sort $(patsubst %,$(objtree)/$(obj)/%/,$(dir $(firmware-y) $(fw-shipped-))))
 
 quiet_cmd_mkdir = MKDIR   $(patsubst $(objtree)/%,%,$@)
       cmd_mkdir = mkdir -p $@


-- 
dwmw2