Re: aoe fails on sparc64
Ed L Cashin <[EMAIL PROTECTED]> writes: ... > Let's take this discussion off the lkml, because I doubt there's a > problem with the aoe driver in the kernel, and I can easily follow up > to the lkml with a synopsis if it turns out I'm wrong. It looks like I was probably wrong. I need to do some debugging, but the only sparc64 machine here at hand is in use. If anybody would be up for running 2.6.13 on a sparc64 host and running tests with a patched aoe driver, please let me know. A test would look something like this, using an x86 host and a sparc64 host on the same LAN. x86$ dd if=/dev/zero of=/tmp/0x1234567 bs=1k count=1 seek=19088742 x86$ vblade 0 1 eth0 /tmp/0x1234567 sparc64$ rmmod aoe sparc64$ cd ~/linux-2.6.13 sparc64$ patch -p1 < aoe.diff sparc64$ make && make modules_install sparc64$ modprobe aoe I'd email you patches, and you'd email me the printk messages that show up in the logs. Such help would be much appreciated. -- Ed L Cashin <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aoe fails on sparc64
Ed L Cashin [EMAIL PROTECTED] writes: ... Let's take this discussion off the lkml, because I doubt there's a problem with the aoe driver in the kernel, and I can easily follow up to the lkml with a synopsis if it turns out I'm wrong. It looks like I was probably wrong. I need to do some debugging, but the only sparc64 machine here at hand is in use. If anybody would be up for running 2.6.13 on a sparc64 host and running tests with a patched aoe driver, please let me know. A test would look something like this, using an x86 host and a sparc64 host on the same LAN. x86$ dd if=/dev/zero of=/tmp/0x1234567 bs=1k count=1 seek=19088742 x86$ vblade 0 1 eth0 /tmp/0x1234567 sparc64$ rmmod aoe sparc64$ cd ~/linux-2.6.13 sparc64$ patch -p1 aoe.diff sparc64$ make make modules_install sparc64$ modprobe aoe I'd email you patches, and you'd email me the printk messages that show up in the logs. Such help would be much appreciated. -- Ed L Cashin [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aoe fails on sparc64
Jim MacBaine <[EMAIL PROTECTED]> writes: > On 9/1/05, Ed L Cashin <[EMAIL PROTECTED]> wrote: > >> The aoe driver looks OK, but it turns out there's a byte swapping bug >> in the vblade that could be related if he's running the vblade on a >> big endian host (even though he said it was an x86 host), but I >> haven't heard back from the original poster yet. > > It is in fact a x86_64 kernel, but with a mostly x86 userland. Vblade > is pure x86 code. > >> The vblade bug was the omission of swapping the bytes in each short. >> The fix below shows what I mean: > > Unfortunately it doesn't fix anything here. The client still reports > the same wrong size as before. The dmesg output is identical, too. Let's take this discussion off the lkml, because I doubt there's a problem with the aoe driver in the kernel, and I can easily follow up to the lkml with a synopsis if it turns out I'm wrong. Jim MacBaine, I'm going to ask for more details in a separate email. -- Ed L Cashin <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aoe fails on sparc64
Jim MacBaine [EMAIL PROTECTED] writes: On 9/1/05, Ed L Cashin [EMAIL PROTECTED] wrote: The aoe driver looks OK, but it turns out there's a byte swapping bug in the vblade that could be related if he's running the vblade on a big endian host (even though he said it was an x86 host), but I haven't heard back from the original poster yet. It is in fact a x86_64 kernel, but with a mostly x86 userland. Vblade is pure x86 code. The vblade bug was the omission of swapping the bytes in each short. The fix below shows what I mean: Unfortunately it doesn't fix anything here. The client still reports the same wrong size as before. The dmesg output is identical, too. Let's take this discussion off the lkml, because I doubt there's a problem with the aoe driver in the kernel, and I can easily follow up to the lkml with a synopsis if it turns out I'm wrong. Jim MacBaine, I'm going to ask for more details in a separate email. -- Ed L Cashin [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aoe fails on sparc64
On 9/1/05, Ed L Cashin <[EMAIL PROTECTED]> wrote: > The aoe driver looks OK, but it turns out there's a byte swapping bug > in the vblade that could be related if he's running the vblade on a > big endian host (even though he said it was an x86 host), but I > haven't heard back from the original poster yet. It is in fact a x86_64 kernel, but with a mostly x86 userland. Vblade is pure x86 code. > The vblade bug was the omission of swapping the bytes in each short. > The fix below shows what I mean: Unfortunately it doesn't fix anything here. The client still reports the same wrong size as before. The dmesg output is identical, too. Regards, Jim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aoe fails on sparc64
On 9/1/05, Ed L Cashin [EMAIL PROTECTED] wrote: The aoe driver looks OK, but it turns out there's a byte swapping bug in the vblade that could be related if he's running the vblade on a big endian host (even though he said it was an x86 host), but I haven't heard back from the original poster yet. It is in fact a x86_64 kernel, but with a mostly x86 userland. Vblade is pure x86 code. The vblade bug was the omission of swapping the bytes in each short. The fix below shows what I mean: Unfortunately it doesn't fix anything here. The client still reports the same wrong size as before. The dmesg output is identical, too. Regards, Jim - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aoe fails on sparc64
From: Ed L Cashin <[EMAIL PROTECTED]> Date: Thu, 01 Sep 2005 15:13:52 -0400 > The aoe driver looks OK, but it turns out there's a byte swapping bug > in the vblade that could be related if he's running the vblade on a > big endian host (even though he said it was an x86 host), but I > haven't heard back from the original poster yet. I see, thanks for looking into this. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aoe fails on sparc64
"David S. Miller" <[EMAIL PROTECTED]> writes:
> From: Ed L Cashin <[EMAIL PROTECTED]>
...
>> OK. 67553994410557440 is 61440 byte swapped in 64 bits, and 30MB is
>> 61440 sectors, so this should be a simple byte order fix.
>
> More strangely, the upper and lower 32-bit words are swapped.
> The bytes within each 32-bit word are swapped correctly.
>
> So the calculation maybe should be something like:
>
> __le32 *p = (__le32 *) [100 << 1];
> u32 high32 = le32_to_cpup(p);
> u32 low32 = le32_to_cpup(p + 1);
>
> ssize = (((u64)high32 << 32) | (u64) low32);
>
> But that doesn't make any sense, and even ide_fix_driveid() in
> drivers/ide/ide-iops.c does a le64_to_cpu() for this value:
>
> id->lba_capacity_2 = __le64_to_cpu(id->lba_capacity_2);
>
> I wonder if this is some artifact of how AOE devices encode
> this field when sending it to the client.
Well, an EtherDrive blade just copies the ATA identify response data
into a network packet without looking at it. The vblade, though, has
to set the lba_capacity and lba_capacity_2 fields itself.
The aoe driver looks OK, but it turns out there's a byte swapping bug
in the vblade that could be related if he's running the vblade on a
big endian host (even though he said it was an x86 host), but I
haven't heard back from the original poster yet.
The vblade bug was the omission of swapping the bytes in each short.
The fix below shows what I mean:
diff -urNp a-exp/ata.c b-exp/ata.c
--- a-exp/ata.c 2005-09-01 10:19:11.0 -0400
+++ b-exp/ata.c 2005-09-01 10:19:12.0 -0400
@@ -55,24 +55,29 @@ setfld(ushort *a, int idx, int len, char
}
static void
-setlba28(ushort *p, vlong lba)
+setlba28(ushort *ident, vlong lba)
{
- p += 60;
- *p++ = lba & 0x;
- *p = lba >> 16 & 0x0fff;
+ uchar *cp;
+
+ cp = (uchar *) [60];
+ *cp++ = lba;
+ *cp++ = lba >>= 8;
+ *cp++ = lba >>= 8;
+ *cp++ = (lba >>= 8) & 0xf;
}
static void
-setlba48(ushort *p, vlong lba)
+setlba48(ushort *ident, vlong lba)
{
- p += 100;
- *p++ = lba;
- lba >>= 16;
- *p++ = lba;
- lba >>= 16;
- *p++ = lba;
- lba >>= 16;
- *p = lba;
+ uchar *cp;
+
+ cp = (uchar *) [100];
+ *cp++ = lba;
+ *cp++ = lba >>= 8;
+ *cp++ = lba >>= 8;
+ *cp++ = lba >>= 8;
+ *cp++ = lba >>= 8;
+ *cp++ = lba >>= 8;
}
void
--
Ed L Cashin <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: aoe fails on sparc64
From: Ed L Cashin <[EMAIL PROTECTED]> Date: Wed, 31 Aug 2005 11:50:55 -0400 > Jim MacBaine <[EMAIL PROTECTED]> writes: > > > Aug 31 15:18:49 sunny kernel: devfs_mk_dir: invalid argument.<6> > > etherd/e0.0: unknown partition table > > Aug 31 15:18:49 sunny kernel: aoe: 0011d8xx e0.0 v4000 has > > 67553994410557440 > > sectors > > OK. 67553994410557440 is 61440 byte swapped in 64 bits, and 30MB is > 61440 sectors, so this should be a simple byte order fix. More strangely, the upper and lower 32-bit words are swapped. The bytes within each 32-bit word are swapped correctly. So the calculation maybe should be something like: __le32 *p = (__le32 *) [100 << 1]; u32 high32 = le32_to_cpup(p); u32 low32 = le32_to_cpup(p + 1); ssize = (((u64)high32 << 32) | (u64) low32); But that doesn't make any sense, and even ide_fix_driveid() in drivers/ide/ide-iops.c does a le64_to_cpu() for this value: id->lba_capacity_2 = __le64_to_cpu(id->lba_capacity_2); I wonder if this is some artifact of how AOE devices encode this field when sending it to the client. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aoe fails on sparc64
From: Ed L Cashin [EMAIL PROTECTED] Date: Wed, 31 Aug 2005 11:50:55 -0400 Jim MacBaine [EMAIL PROTECTED] writes: Aug 31 15:18:49 sunny kernel: devfs_mk_dir: invalid argument.6 etherd/e0.0: unknown partition table Aug 31 15:18:49 sunny kernel: aoe: 0011d8xx e0.0 v4000 has 67553994410557440 sectors OK. 67553994410557440 is 61440 byte swapped in 64 bits, and 30MB is 61440 sectors, so this should be a simple byte order fix. More strangely, the upper and lower 32-bit words are swapped. The bytes within each 32-bit word are swapped correctly. So the calculation maybe should be something like: __le32 *p = (__le32 *) id[100 1]; u32 high32 = le32_to_cpup(p); u32 low32 = le32_to_cpup(p + 1); ssize = (((u64)high32 32) | (u64) low32); But that doesn't make any sense, and even ide_fix_driveid() in drivers/ide/ide-iops.c does a le64_to_cpu() for this value: id-lba_capacity_2 = __le64_to_cpu(id-lba_capacity_2); I wonder if this is some artifact of how AOE devices encode this field when sending it to the client. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aoe fails on sparc64
From: Ed L Cashin [EMAIL PROTECTED] Date: Thu, 01 Sep 2005 15:13:52 -0400 The aoe driver looks OK, but it turns out there's a byte swapping bug in the vblade that could be related if he's running the vblade on a big endian host (even though he said it was an x86 host), but I haven't heard back from the original poster yet. I see, thanks for looking into this. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aoe fails on sparc64
David S. Miller [EMAIL PROTECTED] writes:
From: Ed L Cashin [EMAIL PROTECTED]
...
OK. 67553994410557440 is 61440 byte swapped in 64 bits, and 30MB is
61440 sectors, so this should be a simple byte order fix.
More strangely, the upper and lower 32-bit words are swapped.
The bytes within each 32-bit word are swapped correctly.
So the calculation maybe should be something like:
__le32 *p = (__le32 *) id[100 1];
u32 high32 = le32_to_cpup(p);
u32 low32 = le32_to_cpup(p + 1);
ssize = (((u64)high32 32) | (u64) low32);
But that doesn't make any sense, and even ide_fix_driveid() in
drivers/ide/ide-iops.c does a le64_to_cpu() for this value:
id-lba_capacity_2 = __le64_to_cpu(id-lba_capacity_2);
I wonder if this is some artifact of how AOE devices encode
this field when sending it to the client.
Well, an EtherDrive blade just copies the ATA identify response data
into a network packet without looking at it. The vblade, though, has
to set the lba_capacity and lba_capacity_2 fields itself.
The aoe driver looks OK, but it turns out there's a byte swapping bug
in the vblade that could be related if he's running the vblade on a
big endian host (even though he said it was an x86 host), but I
haven't heard back from the original poster yet.
The vblade bug was the omission of swapping the bytes in each short.
The fix below shows what I mean:
diff -urNp a-exp/ata.c b-exp/ata.c
--- a-exp/ata.c 2005-09-01 10:19:11.0 -0400
+++ b-exp/ata.c 2005-09-01 10:19:12.0 -0400
@@ -55,24 +55,29 @@ setfld(ushort *a, int idx, int len, char
}
static void
-setlba28(ushort *p, vlong lba)
+setlba28(ushort *ident, vlong lba)
{
- p += 60;
- *p++ = lba 0x;
- *p = lba 16 0x0fff;
+ uchar *cp;
+
+ cp = (uchar *) ident[60];
+ *cp++ = lba;
+ *cp++ = lba = 8;
+ *cp++ = lba = 8;
+ *cp++ = (lba = 8) 0xf;
}
static void
-setlba48(ushort *p, vlong lba)
+setlba48(ushort *ident, vlong lba)
{
- p += 100;
- *p++ = lba;
- lba = 16;
- *p++ = lba;
- lba = 16;
- *p++ = lba;
- lba = 16;
- *p = lba;
+ uchar *cp;
+
+ cp = (uchar *) ident[100];
+ *cp++ = lba;
+ *cp++ = lba = 8;
+ *cp++ = lba = 8;
+ *cp++ = lba = 8;
+ *cp++ = lba = 8;
+ *cp++ = lba = 8;
}
void
--
Ed L Cashin [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: aoe fails on sparc64
Jim MacBaine <[EMAIL PROTECTED]> writes: > Hello, > > Using aoe on a sparc64 system gives strange results: > ... > The log says: > > Aug 31 15:18:49 sunny kernel: devfs_mk_dir: invalid argument.<6> > etherd/e0.0: unknown partition table > Aug 31 15:18:49 sunny kernel: aoe: 0011d8xx e0.0 v4000 has > 67553994410557440 > sectors OK. 67553994410557440 is 61440 byte swapped in 64 bits, and 30MB is 61440 sectors, so this should be a simple byte order fix. > The system is an Sun Ultra 5, running 2.6.12.5/sparc64 compiled with > gcc-3.4.2. e0.0 is exported on a x86 system using vblade-5, and has a > size of 30 MB. Thanks for the report. -- Ed L Cashin <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
aoe fails on sparc64
Hello, Using aoe on a sparc64 system gives strange results: sunny:/dev/etherd# echo >discover sunny:/dev/etherd# mke2fs e0.0 mke2fs 1.37 (21-Mar-2005) mke2fs: File too large while trying to determine filesystem size sunny:/dev/etherd# blockdev --getsz e0.0 -4503599627370496 The log says: Aug 31 15:18:49 sunny kernel: devfs_mk_dir: invalid argument.<6> etherd/e0.0: unknown partition table Aug 31 15:18:49 sunny kernel: aoe: 0011d8xx e0.0 v4000 has 67553994410557440 sectors The system is an Sun Ultra 5, running 2.6.12.5/sparc64 compiled with gcc-3.4.2. e0.0 is exported on a x86 system using vblade-5, and has a size of 30 MB. Regards, Jim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
aoe fails on sparc64
Hello, Using aoe on a sparc64 system gives strange results: sunny:/dev/etherd# echo discover sunny:/dev/etherd# mke2fs e0.0 mke2fs 1.37 (21-Mar-2005) mke2fs: File too large while trying to determine filesystem size sunny:/dev/etherd# blockdev --getsz e0.0 -4503599627370496 The log says: Aug 31 15:18:49 sunny kernel: devfs_mk_dir: invalid argument.6 etherd/e0.0: unknown partition table Aug 31 15:18:49 sunny kernel: aoe: 0011d8xx e0.0 v4000 has 67553994410557440 sectors The system is an Sun Ultra 5, running 2.6.12.5/sparc64 compiled with gcc-3.4.2. e0.0 is exported on a x86 system using vblade-5, and has a size of 30 MB. Regards, Jim - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aoe fails on sparc64
Jim MacBaine [EMAIL PROTECTED] writes: Hello, Using aoe on a sparc64 system gives strange results: ... The log says: Aug 31 15:18:49 sunny kernel: devfs_mk_dir: invalid argument.6 etherd/e0.0: unknown partition table Aug 31 15:18:49 sunny kernel: aoe: 0011d8xx e0.0 v4000 has 67553994410557440 sectors OK. 67553994410557440 is 61440 byte swapped in 64 bits, and 30MB is 61440 sectors, so this should be a simple byte order fix. The system is an Sun Ultra 5, running 2.6.12.5/sparc64 compiled with gcc-3.4.2. e0.0 is exported on a x86 system using vblade-5, and has a size of 30 MB. Thanks for the report. -- Ed L Cashin [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
