Hi,
MSR index is 32bit not 64bit. All other MSR indexes are defined
without the ULL suffix. Otherwise, you will get
[EMAIL PROTECTED] tmp]$ cat foo.c
typedef unsigned long long u64;
int is_disabled(void)
{
u64 vm_cr;
do { unsigned long l__,h__; __asm__ __volatile__("rdmsr" : "=a" (l__),
"=d"
Hi,
MSR index is 32bit not 64bit. All other MSR indexes are defined
without the ULL suffix. Otherwise, you will get
[EMAIL PROTECTED] tmp]$ cat foo.c
typedef unsigned long long u64;
int is_disabled(void)
{
u64 vm_cr;
do { unsigned long l__,h__; __asm__ __volatile__(rdmsr : =a (l__),
=d (h__)
On Wed, Dec 06, 2006 at 06:52:39PM +0100, Mikael Pettersson wrote:
>
> If hardware x86 decoders (i.e., Intel or AMD processors)
> get measurably faster with the new order, that would be
> a good reason to change it.
I was told that AMD processors had no preferences and Intel processors
preferred
On Wed, Dec 06, 2006 at 08:43:17AM -0800, Randy Dunlap wrote:
> On Tue, 5 Dec 2006 23:00:14 -0800 H. J. Lu wrote:
>
> > On x86, the order of prefix SEG_PREFIX, ADDR_PREFIX, DATA_PREFIX and
> > LOCKREP_PREFIX isn't fixed. Currently, gas generates
> >
> > LOCKREP_
On Wed, Dec 06, 2006 at 08:43:17AM -0800, Randy Dunlap wrote:
On Tue, 5 Dec 2006 23:00:14 -0800 H. J. Lu wrote:
On x86, the order of prefix SEG_PREFIX, ADDR_PREFIX, DATA_PREFIX and
LOCKREP_PREFIX isn't fixed. Currently, gas generates
LOCKREP_PREFIX ADDR_PREFIX DATA_PREFIX SEG_PREFIX
On Wed, Dec 06, 2006 at 06:52:39PM +0100, Mikael Pettersson wrote:
If hardware x86 decoders (i.e., Intel or AMD processors)
get measurably faster with the new order, that would be
a good reason to change it.
I was told that AMD processors had no preferences and Intel processors
preferred the
On x86, the order of prefix SEG_PREFIX, ADDR_PREFIX, DATA_PREFIX and
LOCKREP_PREFIX isn't fixed. Currently, gas generates
LOCKREP_PREFIX ADDR_PREFIX DATA_PREFIX SEG_PREFIX
I will check in a patch:
http://sourceware.org/ml/binutils/2006-12/msg00054.html
tomorrow and change gas to generate
On x86, the order of prefix SEG_PREFIX, ADDR_PREFIX, DATA_PREFIX and
LOCKREP_PREFIX isn't fixed. Currently, gas generates
LOCKREP_PREFIX ADDR_PREFIX DATA_PREFIX SEG_PREFIX
I will check in a patch:
http://sourceware.org/ml/binutils/2006-12/msg00054.html
tomorrow and change gas to generate
On Wed, Aug 24, 2005 at 01:10:35PM +0200, Adrian Bunk wrote:
> auxiliary-vector-cleanups.patch broke compilation on the xtensa
> architecture because it doesn't add an asm/auxvec.h on this
> architecture.
>
This added asm-frv/auxvec.h and asm-xtensa/auxvec.h.
H.J.
---
---
On Wed, Aug 24, 2005 at 01:10:35PM +0200, Adrian Bunk wrote:
auxiliary-vector-cleanups.patch broke compilation on the xtensa
architecture because it doesn't add an asm/auxvec.h on this
architecture.
This added asm-frv/auxvec.h and asm-xtensa/auxvec.h.
H.J.
---
---
On Tue, Jul 26, 2005 at 10:06:37PM -0700, Andrew Morton wrote:
> "H. J. Lu" <[EMAIL PROTECTED]> wrote:
> >
> > On Tue, Jul 26, 2005 at 09:53:23PM -0700, Andrew Morton wrote:
> > > "H. J. Lu" <[EMAIL PROTECTED]> wrote:
> > > >
&g
On Tue, Jul 26, 2005 at 10:06:37PM -0700, Andrew Morton wrote:
H. J. Lu [EMAIL PROTECTED] wrote:
On Tue, Jul 26, 2005 at 09:53:23PM -0700, Andrew Morton wrote:
H. J. Lu [EMAIL PROTECTED] wrote:
My patch breaks x86_64 build. This patch will fix x86_64 build. I am
also enclosing
On Tue, Jul 26, 2005 at 09:53:23PM -0700, Andrew Morton wrote:
> "H. J. Lu" <[EMAIL PROTECTED]> wrote:
> >
> > My patch breaks x86_64 build. This patch will fix x86_64 build. I am
> > also enclosing the updated full patch.
>
> It now break
On Tue, Jul 26, 2005 at 02:46:20PM -0700, [EMAIL PROTECTED] wrote:
>
> The patch titled
>
> Define auxiliary vector size, AT_VECTOR_SIZE
>
> has been added to the -mm tree. Its filename is
>
> define-auxiliary-vector-size-at_vector_size.patch
>
> Patches currently in -mm which
The size of auxiliary vector is fixed at 42 in linux/sched.h. But
it isn't very obvious when looking at linux/elf.h. This patch adds
AT_VECTOR_SIZE so that we can change it if necessary when a new
vector is added.
H.J.
--- linux/include/linux/elf.h.auxv 2004-10-18 14:53:22.0 -0700
The size of auxiliary vector is fixed at 42 in linux/sched.h. But
it isn't very obvious when looking at linux/elf.h. This patch adds
AT_VECTOR_SIZE so that we can change it if necessary when a new
vector is added.
H.J.
--- linux/include/linux/elf.h.auxv 2004-10-18 14:53:22.0 -0700
On Tue, Jul 26, 2005 at 02:46:20PM -0700, [EMAIL PROTECTED] wrote:
The patch titled
Define auxiliary vector size, AT_VECTOR_SIZE
has been added to the -mm tree. Its filename is
define-auxiliary-vector-size-at_vector_size.patch
Patches currently in -mm which might be from
On Tue, Jul 26, 2005 at 09:53:23PM -0700, Andrew Morton wrote:
H. J. Lu [EMAIL PROTECTED] wrote:
My patch breaks x86_64 build. This patch will fix x86_64 build. I am
also enclosing the updated full patch.
It now breaks ppc64
include/asm/elf.h: In function `dump_task_regs':
include
On Thu, Mar 31, 2005 at 02:57:57AM +0200, Pau Aliagas wrote:
> On Wed, 30 Mar 2005, H. J. Lu wrote:
>
> >>>That is what the assembler generates, and should have generated, for
> >>>"movw %ds,(%eax)" since Nov. 4, 2004.
> >>
> >>Could th
On Thu, Mar 31, 2005 at 12:18:55AM +0200, Pau Aliagas wrote:
> On Wed, 30 Mar 2005, H. J. Lu wrote:
>
> >On Wed, Mar 30, 2005 at 07:57:28AM -0800, Linus Torvalds wrote:
>
> >>>There is no such an instruction of "movl %ds,(%eax)". The old assembler
> &
On Wed, Mar 30, 2005 at 11:23:25AM -0500, linux-os wrote:
>
> So if there are any "movw (mem), %ds" and
> "movw %ds, (mem)" in the code. The sizeof(mem)
> needs to be 32-bits and the 'w' needs to be removed.
> Otherwise, we are wasting CPU cycles and/or fooling
> ourselves. GAS needs to continue
On Wed, Mar 30, 2005 at 07:57:28AM -0800, Linus Torvalds wrote:
>
> [ binutils and libc back in the discussion - I don't know why they got
> dropped ]
Removing glibc since it accesses segment register with proper
instructions.
>
> On Tue, 29 Mar 2005,
On Wed, Mar 30, 2005 at 07:57:28AM -0800, Linus Torvalds wrote:
[ binutils and libc back in the discussion - I don't know why they got
dropped ]
Removing glibc since it accesses segment register with proper
instructions.
On Tue, 29 Mar 2005, H. J. Lu wrote
On Wed, Mar 30, 2005 at 11:23:25AM -0500, linux-os wrote:
So if there are any movw (mem), %ds and
movw %ds, (mem) in the code. The sizeof(mem)
needs to be 32-bits and the 'w' needs to be removed.
Otherwise, we are wasting CPU cycles and/or fooling
ourselves. GAS needs to continue to
On Thu, Mar 31, 2005 at 12:18:55AM +0200, Pau Aliagas wrote:
On Wed, 30 Mar 2005, H. J. Lu wrote:
On Wed, Mar 30, 2005 at 07:57:28AM -0800, Linus Torvalds wrote:
There is no such an instruction of movl %ds,(%eax). The old assembler
accepts it and turns it into movw %ds,(%eax).
I
On Thu, Mar 31, 2005 at 02:57:57AM +0200, Pau Aliagas wrote:
On Wed, 30 Mar 2005, H. J. Lu wrote:
That is what the assembler generates, and should have generated, for
movw %ds,(%eax) since Nov. 4, 2004.
Could this be the reason for the reported slowdown in the last six months?
Can you
On Tue, Mar 29, 2005 at 06:44:18PM -0800, Linus Torvalds wrote:
>
>
> On Tue, 29 Mar 2005, H. J. Lu wrote:
> >
> > > the smaller and faster version do not want to just rely on gas
> > > automatically getting it right, especially since gas has historically be
On Tue, Mar 29, 2005 at 04:30:01PM -0800, Linus Torvalds wrote:
>
>
> On Mon, 28 Mar 2005, Andi Kleen wrote:
> >
> > "H. J. Lu" <[EMAIL PROTECTED]> writes:
> > > The new assembler will disallow them since those instructions with
> > > memor
The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,
movl (%eax),%ds
movl %ds,(%eax)
To generate instructions for moving between a segment register and a
16bit memory location without the 16bit
The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,
movl (%eax),%ds
movl %ds,(%eax)
To generate instructions for moving between a segment register and a
16bit memory location without the 16bit
On Tue, Mar 29, 2005 at 04:30:01PM -0800, Linus Torvalds wrote:
On Mon, 28 Mar 2005, Andi Kleen wrote:
H. J. Lu [EMAIL PROTECTED] writes:
The new assembler will disallow them since those instructions with
memory operand will only use the first 16bits. If the memory operand
On Tue, Mar 29, 2005 at 06:44:18PM -0800, Linus Torvalds wrote:
On Tue, 29 Mar 2005, H. J. Lu wrote:
the smaller and faster version do not want to just rely on gas
automatically getting it right, especially since gas has historically been
very very bad at getting things right
On Mon, Mar 28, 2005 at 09:46:00AM -0800, H. J. Lu wrote:
> On Mon, Mar 28, 2005 at 05:47:06PM +0200, Andi Kleen wrote:
> > "H. J. Lu" <[EMAIL PROTECTED]> writes:
> > > The new assembler will disallow them since those instructions with
> > > me
On Mon, Mar 28, 2005 at 05:47:06PM +0200, Andi Kleen wrote:
> "H. J. Lu" <[EMAIL PROTECTED]> writes:
> > The new assembler will disallow them since those instructions with
> > memory operand will only use the first 16bits. If the memory operand
> >
On Mon, Mar 28, 2005 at 05:47:06PM +0200, Andi Kleen wrote:
H. J. Lu [EMAIL PROTECTED] writes:
The new assembler will disallow them since those instructions with
memory operand will only use the first 16bits. If the memory operand
is 16bit, you won't see any problems. But if the memory
On Mon, Mar 28, 2005 at 09:46:00AM -0800, H. J. Lu wrote:
On Mon, Mar 28, 2005 at 05:47:06PM +0200, Andi Kleen wrote:
H. J. Lu [EMAIL PROTECTED] writes:
The new assembler will disallow them since those instructions with
memory operand will only use the first 16bits. If the memory operand
with
memory operand will only use the first 16bits. If the memory operand
is 16bit, you won't see any problems. But if the memory destinatin
is 32bit, the upper 16bits may have random values. The new assembler
will force people to use
mov (%eax),%ds
movw (%eax),%ds
movw %ds,(
people to use
mov (%eax),%ds
movw (%eax),%ds
movw %ds,(%eax)
mov %ds,(%eax)
Will it be a big problem for kernel people?
BTW, I haven't checked glibc yet. It may have similar issues.
H.J.
---
On Fri, Mar 25, 2005 at 06:05:06PM -0800, H. J. Lu wrote:
X86 segment
On Wed, May 16, 2001 at 03:41:40PM +0200, Geert Uytterhoeven wrote:
> On Tue, 15 May 2001, H . J . Lu wrote:
> > Here is a patch for 2.4.4. linux_logo_bw is used in hgafb.c, which
> > can be compiled as a module. But linux_logo_bw is not exported.
> >
>
> linux_log
On Wed, May 16, 2001 at 05:33:12AM -0700, Jalaja Devi wrote:
> Hi!
> Could you please tell me how you fixed the udelay
> problem. cuz, I am encountering the same problem in my
> driver.
>
I am not a kernel expert. You should ask it on the kernel mailing
list.
> Thanks for your time,
> Jalaja
>
On Wed, May 16, 2001 at 05:33:12AM -0700, Jalaja Devi wrote:
Hi!
Could you please tell me how you fixed the udelay
problem. cuz, I am encountering the same problem in my
driver.
I am not a kernel expert. You should ask it on the kernel mailing
list.
Thanks for your time,
Jalaja
In
On Wed, May 16, 2001 at 03:41:40PM +0200, Geert Uytterhoeven wrote:
On Tue, 15 May 2001, H . J . Lu wrote:
Here is a patch for 2.4.4. linux_logo_bw is used in hgafb.c, which
can be compiled as a module. But linux_logo_bw is not exported.
linux_logo_bw is __initdata.
How about
Here is a patch for 2.4.4. linux_logo_bw is used in hgafb.c, which
can be compiled as a module. But linux_logo_bw is not exported.
H.J.
---
--- linux-2.4.4-ac9/drivers/video/fbcon.c.mod Tue May 15 15:39:17 2001
+++ linux-2.4.4-ac9/drivers/video/fbcon.c Tue May 15 15:40:18 2001
@@
In 2.4.4, drivers/net/aironet4500_card.c has
# grep udelay linux/drivers/net/aironet4500_card.c
udelay(1000);
udelay(100);
udelay(10);
udelay(10);
udelay(20);
udelay(25);
udelay(1);
udelay(1);
>
> The clean way to handle it, and I'll take a look it to have
> root=/dev/nfs (and the rdev equivalent) to set ip=on if it isn't
Yes.
> already. The current 2.4.4 behavior of root=/dev/hda3 doing ip
> autoconfig when the code is compiled into the kernel is just bad.
Agreed.
H.J.
-
To
In 2.4.4, drivers/net/aironet4500_card.c has
# grep udelay linux/drivers/net/aironet4500_card.c
udelay(1000);
udelay(100);
udelay(10);
udelay(10);
udelay(20);
udelay(25);
udelay(1);
udelay(1);
Here is a patch for 2.4.4. linux_logo_bw is used in hgafb.c, which
can be compiled as a module. But linux_logo_bw is not exported.
H.J.
---
--- linux-2.4.4-ac9/drivers/video/fbcon.c.mod Tue May 15 15:39:17 2001
+++ linux-2.4.4-ac9/drivers/video/fbcon.c Tue May 15 15:40:18 2001
@@
The clean way to handle it, and I'll take a look it to have
root=/dev/nfs (and the rdev equivalent) to set ip=on if it isn't
Yes.
already. The current 2.4.4 behavior of root=/dev/hda3 doing ip
autoconfig when the code is compiled into the kernel is just bad.
Agreed.
H.J.
-
To
On Mon, May 14, 2001 at 12:02:48PM -0700, H . J . Lu wrote:
>
> BTW, I cannot select both CONFIG_IP_PNP_DHCP and CONFIG_IP_PNP_BOOTP.
> BOOTP doesn' work even if I pass "ip=bootp" to kernel. I will take
> a look.
>
>
Here is a patch. We should do DHCP iff it is ena
On Mon, May 14, 2001 at 02:36:05PM -0400, Jeff Garzik wrote:
> Mads Martin Jørgensen wrote:
> >
> > * H . J . Lu <[EMAIL PROTECTED]> [May 14. 2001 11:22]:
> > > On Sat, May 12, 2001 at 03:25:34PM -0400, Jeff Garzik wrote:
> > > > Attached is a patch agai
On Sat, May 12, 2001 at 03:25:34PM -0400, Jeff Garzik wrote:
> Attached is a patch against 2.4.4-ac8 which includes several fixes to
> the Tulip driver. This should fix the reported PNIC problems, as well
> as problems with forcing media on MII phys and several other bugs.
>
Your patch doesn't
On Sat, May 12, 2001 at 03:25:34PM -0400, Jeff Garzik wrote:
Attached is a patch against 2.4.4-ac8 which includes several fixes to
the Tulip driver. This should fix the reported PNIC problems, as well
as problems with forcing media on MII phys and several other bugs.
Your patch doesn't
On Mon, May 14, 2001 at 02:36:05PM -0400, Jeff Garzik wrote:
Mads Martin Jørgensen wrote:
* H . J . Lu [EMAIL PROTECTED] [May 14. 2001 11:22]:
On Sat, May 12, 2001 at 03:25:34PM -0400, Jeff Garzik wrote:
Attached is a patch against 2.4.4-ac8 which includes several fixes
On Mon, May 14, 2001 at 12:02:48PM -0700, H . J . Lu wrote:
BTW, I cannot select both CONFIG_IP_PNP_DHCP and CONFIG_IP_PNP_BOOTP.
BOOTP doesn' work even if I pass ip=bootp to kernel. I will take
a look.
Here is a patch. We should do DHCP iff it is enabled.
H.J.
--- linux-2.4.4-ac9/net
On Sun, May 13, 2001 at 07:24:31PM -0600, Eric W. Biederman wrote:
>
> I agree it isn't intuitive, and if nfsroot=xxx is specified it should
> probably turn on if there is missing information.
>
> But if you have to select the command line anyway
>
> Mostly I like the situation where I can
On Sun, May 13, 2001 at 01:24:18PM -0600, Eric W. Biederman wrote:
> "H . J . Lu" <[EMAIL PROTECTED]> writes:
>
> > It doesn't make any senses. When I specify CONFIG_IP_PNP and
> > BOOTP/DHCP, I want a kernel with IP config using BOOTP/DHCP. I would
> > e
On Sun, May 13, 2001 at 01:24:18PM -0600, Eric W. Biederman wrote:
H . J . Lu [EMAIL PROTECTED] writes:
It doesn't make any senses. When I specify CONFIG_IP_PNP and
BOOTP/DHCP, I want a kernel with IP config using BOOTP/DHCP. I would
expect IP config is turned for BOOTP/DHCP by default
On Sun, May 13, 2001 at 07:24:31PM -0600, Eric W. Biederman wrote:
I agree it isn't intuitive, and if nfsroot=xxx is specified it should
probably turn on if there is missing information.
But if you have to select the command line anyway
Mostly I like the situation where I can
The tulip driver in 2.4.4-ac8 doesn't work with Lite-On 82c168 PNIC
rev 32 in the NetGear FA310TX REV-D2. It sends BOOTP request and
times out.
H.J.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Fri, May 11, 2001 at 04:28:05PM -0700, David S. Miller wrote:
>
> H . J . Lu writes:
> > 2.4.4-ac8 disables IP auto config by default even if CONFIG_IP_PNP is
> > defined. Here is a patch.
>
> It doesn't make any sense to enable this unless parameters are
&
2.4.4-ac8 disables IP auto config by default even if CONFIG_IP_PNP is
defined. Here is a patch.
H.J.
---
--- linux-2.4.4-ac8/net/ipv4/ipconfig.c.autoFri May 11 14:02:32 2001
+++ linux-2.4.4-ac8/net/ipv4/ipconfig.c Fri May 11 15:26:25 2001
@@ -100,7 +100,11 @@
*/
int ic_set_manually
This should fix
http://boudicca.tux.org/hypermail/linux-kernel/this-week/0901.html
H.J.
--- linux-2.4.4-ac7/mm/filemap.c.module Fri May 11 13:32:20 2001
+++ linux-2.4.4-ac7/mm/filemap.cFri May 11 13:33:03 2001
@@ -9,6 +9,8 @@
* most "normal" filesystems (but you don't /have/ to
This should fix
http://boudicca.tux.org/hypermail/linux-kernel/this-week/0901.html
H.J.
--- linux-2.4.4-ac7/mm/filemap.c.module Fri May 11 13:32:20 2001
+++ linux-2.4.4-ac7/mm/filemap.cFri May 11 13:33:03 2001
@@ -9,6 +9,8 @@
* most normal filesystems (but you don't /have/ to
2.4.4-ac8 disables IP auto config by default even if CONFIG_IP_PNP is
defined. Here is a patch.
H.J.
---
--- linux-2.4.4-ac8/net/ipv4/ipconfig.c.autoFri May 11 14:02:32 2001
+++ linux-2.4.4-ac8/net/ipv4/ipconfig.c Fri May 11 15:26:25 2001
@@ -100,7 +100,11 @@
*/
int ic_set_manually
The tulip driver in 2.4.4-ac8 doesn't work with Lite-On 82c168 PNIC
rev 32 in the NetGear FA310TX REV-D2. It sends BOOTP request and
times out.
H.J.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Fri, May 11, 2001 at 04:28:05PM -0700, David S. Miller wrote:
H . J . Lu writes:
2.4.4-ac8 disables IP auto config by default even if CONFIG_IP_PNP is
defined. Here is a patch.
It doesn't make any sense to enable this unless parameters are
given to the kernel via the kernel
On Mon, Mar 12, 2001 at 03:56:20PM +0100, Trond Myklebust wrote:
> > " " == Chris Jensen <[EMAIL PROTECTED]> writes:
>
> >> Details please, the minimum info required being 'which kernel
> >> is your client running'?
> >>
>
> > Oh yeah, whoops, sorry The server is a 586 and
On Mon, Mar 12, 2001 at 03:56:20PM +0100, Trond Myklebust wrote:
" " == Chris Jensen [EMAIL PROTECTED] writes:
Details please, the minimum info required being 'which kernel
is your client running'?
Oh yeah, whoops, sorry The server is a 586 and the client is
On Tue, Feb 27, 2001 at 03:04:32PM -0800, H . J . Lu wrote:
> > entry->prev_cookie = entry->cookie;
> > - p = xdr_decode_hyper(p, >cookie);
> > + p = xdr_decode_hyper(p, cookie);
> > + entry->cookie = nfs_transform_cookie64(cookie);
>
> I d
On Thu, Feb 22, 2001 at 03:48:50PM +0100, Trond Myklebust wrote:
>
> The above fixes should ensure that all cookies taking values between 0
> and (2^32-1) on the NFS server are preserved through the 32-bit VFS
> interface, and are accepted by glibc as valid entries. It should also
> work fine
On Thu, Feb 22, 2001 at 03:48:50PM +0100, Trond Myklebust wrote:
The above fixes should ensure that all cookies taking values between 0
and (2^32-1) on the NFS server are preserved through the 32-bit VFS
interface, and are accepted by glibc as valid entries. It should also
work fine with
On Tue, Feb 27, 2001 at 03:04:32PM -0800, H . J . Lu wrote:
entry-prev_cookie = entry-cookie;
- p = xdr_decode_hyper(p, entry-cookie);
+ p = xdr_decode_hyper(p, cookie);
+ entry-cookie = nfs_transform_cookie64(cookie);
I don't understand this. As far as I can tell, "c
On Tue, Feb 27, 2001 at 07:57:36AM +0100, Trond Myklebust wrote:
> >>>>> " " == H J Lu <[EMAIL PROTECTED]> writes:
>
> > I don't know how it will work with real 64bit cookies on a
> > 32bit host for NFS V3 since you truncate it into 32
On Thu, Feb 22, 2001 at 03:48:50PM +0100, Trond Myklebust wrote:
>
> Hi,
>
> After having tried to thrash out what exactly is the kernel
> interface for telldir/seekdir w.r.t. the existence of negative offsets
> with the glibc people, I've finally found a way to work within the
> current
On Thu, Feb 22, 2001 at 03:48:50PM +0100, Trond Myklebust wrote:
Hi,
After having tried to thrash out what exactly is the kernel
interface for telldir/seekdir w.r.t. the existence of negative offsets
with the glibc people, I've finally found a way to work within the
current scheme.
On Tue, Feb 27, 2001 at 07:57:36AM +0100, Trond Myklebust wrote:
" " == H J Lu [EMAIL PROTECTED] writes:
I don't know how it will work with real 64bit cookies on a
32bit host for NFS V3 since you truncate it into 32bit during
sign extension.
It won't for
Here is a patch for kernel 2.4.0. Without it, kernel 2.4.0 won't pass
the Connectathon Testsuite.
--
H.J. Lu ([EMAIL PROTECTED])
---
--- linux/fs/lockd/clntproc.c.lfs Sun Dec 3 18:01:01 2000
+++ linux/fs/lockd/clntproc.c Thu Jan 25 14:58:42 2001
@@ -142,7 +142,8 @@ nlmclnt_proc(struct
Here is a patch for kernel 2.4.0. Without it, kernel 2.4.0 won't pass
the Connectathon Testsuite.
--
H.J. Lu ([EMAIL PROTECTED])
---
--- linux/fs/lockd/clntproc.c.lfs Sun Dec 3 18:01:01 2000
+++ linux/fs/lockd/clntproc.c Thu Jan 25 14:58:42 2001
@@ -142,7 +142,8 @@ nlmclnt_proc(struct
On Mon, Jan 22, 2001 at 03:36:38PM -0800, H . J . Lu wrote:
> On Tue, Jan 23, 2001 at 12:00:29AM +0100, Trond Myklebust wrote:
> > >>>>> " " == H J Lu <[EMAIL PROTECTED]> writes:
> >
> > > I got a report which indicates it may not be
On Mon, Jan 22, 2001 at 03:36:38PM -0800, H . J . Lu wrote:
On Tue, Jan 23, 2001 at 12:00:29AM +0100, Trond Myklebust wrote:
" " == H J Lu [EMAIL PROTECTED] writes:
I got a report which indicates it may not be a good idea,
especially for UDP. Suppose you have a
On Tue, Jan 23, 2001 at 12:00:29AM +0100, Trond Myklebust wrote:
> >>>>> " " == H J Lu <[EMAIL PROTECTED]> writes:
>
> > I got a report which indicates it may not be a good idea,
> > especially for UDP. Suppose you have a lousy LAN or
On Thu, Dec 14, 2000 at 03:16:36PM +0100, Trond Myklebust wrote:
>
> Hi,
>
>One of the things we've been lacking in the Linux implementation of
> RPC is the 'ping' routine. The latter is used on most *NIX
> implementations in order to test whether or not the RPC server is
> alive. To do so,
On Thu, Dec 14, 2000 at 03:16:36PM +0100, Trond Myklebust wrote:
Hi,
One of the things we've been lacking in the Linux implementation of
RPC is the 'ping' routine. The latter is used on most *NIX
implementations in order to test whether or not the RPC server is
alive. To do so, it
On Tue, Jan 23, 2001 at 12:00:29AM +0100, Trond Myklebust wrote:
" " == H J Lu [EMAIL PROTECTED] writes:
I got a report which indicates it may not be a good idea,
especially for UDP. Suppose you have a lousy LAN or NFS UDP
server for whatever reason, some NFS/U
2.2.18pre23 allows lseek to negative offsets in ext2 and has no checks
for proc. Here is a patch.
BTW, ext2 2.4-test10 is ok.
--
H.J. Lu ([EMAIL PROTECTED])
---
--- linux/fs/ext2/file.c.lseek Sat Nov 18 17:18:49 2000
+++ linux/fs/ext2/file.cThu Nov 23 21:54:58 2000
@@ -120,6 +120,8
2.2.18pre23 allows lseek to negative offsets in ext2 and has no checks
for proc. Here is a patch.
BTW, ext2 2.4-test10 is ok.
--
H.J. Lu ([EMAIL PROTECTED])
---
--- linux/fs/ext2/file.c.lseek Sat Nov 18 17:18:49 2000
+++ linux/fs/ext2/file.cThu Nov 23 21:54:58 2000
@@ -120,6 +120,8
On Sun, Nov 19, 2000 at 04:07:04AM +0100, Andrea Arcangeli wrote:
> On Sat, Nov 18, 2000 at 05:20:34PM -0800, H . J . Lu wrote:
> > Try this again 2.2.18pre21. It works for me.
> >
> >
> > --
> > H.J. Lu ([EMAIL PROTECTED])
> > ---
> > --- linux/
On Sun, Nov 19, 2000 at 01:45:12AM +0100, Andrea Arcangeli wrote:
> On Sat, Nov 18, 2000 at 07:25:42PM +0100, Andrea Arcangeli wrote:
> > I fixed it this way:
>
> fix is plain wrong, it's still possible to have lseek return -1 -2 -3 -4
> even when it should return -EINVAL.
>
Try this again
On Sat, Nov 18, 2000 at 07:25:42PM +0100, Andrea Arcangeli wrote:
> On Fri, Nov 17, 2000 at 04:09:00PM -0800, H . J . Lu wrote:
> > On Fri, Nov 17, 2000 at 03:59:13PM -0800, H . J . Lu wrote:
> > > # gcc x.c
> > > # ./a.out
> > > lseek on -10:
On Sun, Nov 19, 2000 at 01:45:12AM +0100, Andrea Arcangeli wrote:
On Sat, Nov 18, 2000 at 07:25:42PM +0100, Andrea Arcangeli wrote:
I fixed it this way:
fix is plain wrong, it's still possible to have lseek return -1 -2 -3 -4
even when it should return -EINVAL.
Try this again
On Sun, Nov 19, 2000 at 04:07:04AM +0100, Andrea Arcangeli wrote:
On Sat, Nov 18, 2000 at 05:20:34PM -0800, H . J . Lu wrote:
Try this again 2.2.18pre21. It works for me.
--
H.J. Lu ([EMAIL PROTECTED])
---
--- linux/fs/ext2/file.c.lseek Sat Nov 18 17:18:49 2000
+++ linux
# gcc x.c
# ./a.out
lseek on -10: -10
write: File too large
Should kernel allow negative offsets for lseek/llseek?
--
H.J. Lu ([EMAIL PROTECTED])
---
#include
#include
#include
extern loff_t llseek (int fd, loff_t offset, int whence);
int
main ()
{
int fd = open
# gcc x.c
# ./a.out
lseek on -10: -10
write: File too large
Should kernel allow negative offsets for lseek/llseek?
--
H.J. Lu ([EMAIL PROTECTED])
---
#include fcntl.h
#include unistd.h
#include stdio.h
extern loff_t llseek (int fd, loff_t offset, int whence);
int
main ()
{
int fd
On Mon, Nov 13, 2000 at 05:58:37AM -0800, [EMAIL PROTECTED] wrote:
>
> Red Hat 6.2
> server running 2.2.18pre17 and nfs-utils 0.2
When you have a NFS problem, the best thing you can do is to check if
your nfs-utils is up to date before you report it. BTW, the current
one is 0.2.1.
--
H.J. Lu
On Mon, Nov 13, 2000 at 05:58:37AM -0800, [EMAIL PROTECTED] wrote:
Red Hat 6.2
server running 2.2.18pre17 and nfs-utils 0.2
When you have a NFS problem, the best thing you can do is to check if
your nfs-utils is up to date before you report it. BTW, the current
one is 0.2.1.
--
H.J. Lu
95 matches
Mail list logo
