[parisc-linux] mkfs.xfs (xfsprogs-2.3.5) failled

[parisc-linux] mkfs.xfs (xfsprogs-2.3.5) failled

[jsoe0708]

Hi Stephan,

As you do earlier, I build a xfs-kernel diff versus 2.4.19 vanilla kernel,
apply it against 2.4.19-pa22 (with very small problem) and obtain a bootable
(and operational) kernel.

Now I rebuild debian package of xfsprogs-2.3.5 (cvs form) and obtain tools
binaries (without warning or error) but even mkfs -t xfs (mkfs.xfs) failed
with this concise message: "mkfs.xfs: cannot reserve space [28 - No space
left on device]".
(I try to xfs_check which failed also with a lot of error messages).

As you already do portage effort may be have you some idea of some starting
point of investigation?

Thanks in advance for all,
    Joel

[parisc-linux] Re: mkfs.xfs (xfsprogs-2.3.5) failled

[Stefan Pfetzing]

* jsoe0708@tiscali.be <jsoe0708@tiscali.be> [021023 09:30]:
> Hi Stephan,
> 
> As you do earlier, I build a xfs-kernel diff versus 2.4.19 vanilla kernel,
> apply it against 2.4.19-pa22 (with very small problem) and obtain a bootable
> (and operational) kernel.
Yup.

> Now I rebuild debian package of xfsprogs-2.3.5 (cvs form) and obtain tools
> binaries (without warning or error) but even mkfs -t xfs (mkfs.xfs) failed
> with this concise message: "mkfs.xfs: cannot reserve space [28 - No space
> left on device]".
> (I try to xfs_check which failed also with a lot of error messages).
Yea thats a problem, still in the Linux/Parisc kernel. It gives garbage with
BLKGETSIZE64. Simply look in the xfslibs directory where BLGKETSIZE64 is used
and comment that out. Thats a disgusting hack but it leads to a set of working
xfsprogs.

If you want I can make a patch for you, but this will take some time, since I
have the source not right by hand now.

bye

Stefan

-- 
        http://www.dreamind.de/
Oroborus and Debian GNU/Linux Developer.

Re: [parisc-linux] Re: mkfs.xfs (xfsprogs-2.3.5) failled

[Randolph Chung]

> Yea thats a problem, still in the Linux/Parisc kernel. It gives garbage with
> BLKGETSIZE64. Simply look in the xfslibs directory where BLGKETSIZE64 is used
> and comment that out. Thats a disgusting hack but it leads to a set of working
> xfsprogs.

i thought i fixed this in the kernel recently (last month). If this is
still not working, please point out the kernel version you are using.

thanks
randolph

Re: [parisc-linux] Re: mkfs.xfs (xfsprogs-2.3.5) failled

[Stefan Pfetzing]

Hi,

* Randolph Chung <randolph@tausq.org> [021024 20:15]:
> i thought i fixed this in the kernel recently (last month). If this is
> still not working, please point out the kernel version you are using.
Hm, maybe, it has been a while since I updated that machine.

2.4.19-pa9-xfs is running there.

bye

Stefan

-- 
        http://www.dreamind.de/
Oroborus and Debian GNU/Linux Developer.

Re: [parisc-linux] Re: mkfs.xfs (xfsprogs-2.3.5) failled

[Randolph Chung]

> Hm, maybe, it has been a while since I updated that machine.
> 
> 2.4.19-pa9-xfs is running there.

what machine was this on? is this a 32-bit or 64-bit kernel?

randolph
--  
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] Re: mkfs.xfs (xfsprogs-2.3.5) failled

[Stefan Pfetzing]

Hi Randolph,

* Randolph Chung <randolph@tausq.org> [021024 21:00]:
> > Hm, maybe, it has been a while since I updated that machine.
> > 
> > 2.4.19-pa9-xfs is running there.
> 
> what machine was this on? is this a 32-bit or 64-bit kernel?

Its a HP Visualize C200 and its a 32bit kernel.

bye

Stefan

-- 
        http://www.dreamind.de/
Oroborus and Debian GNU/Linux Developer.

RE: [parisc-linux] Re: mkfs.xfs (xfsprogs-2.3.5) failled

[jsoe0708]

Stephan,

>* jsoe0708@tiscali.be <jsoe0708@tiscali.be> [021023 09:30]:
>> Hi Stephan,
>> 
>> As you do earlier, I build a xfs-kernel diff versus 2.4.19 vanilla kernel,
>> apply it against 2.4.19-pa22 (with very small problem) and obtain a bootable
>> (and operational) kernel.
>Yup.
>
>> Now I rebuild debian package of xfsprogs-2.3.5 (cvs form) and obtain tools
>> binaries (without warning or error) but even mkfs -t xfs (mkfs.xfs) failed
>> with this concise message: "mkfs.xfs: cannot reserve space [28 - No space
>> left on device]".
>> (I try to xfs_check which failed also with a lot of error messages).
>Yea thats a problem, still in the Linux/Parisc kernel. It gives garbage
with
>BLKGETSIZE64. Simply look in the xfslibs directory where BLGKETSIZE64 is
>used
>and comment that out. Thats a disgusting hack but it leads to a set of working
>xfsprogs.
>
>If you want I can make a patch for you, but this will take some time, since
>I
>have the source not right by hand now.
Hmm I would have to be aware (as I try to implement put_user and get_user
for 64bits [ie long long] [unfortunately] without great success till now).

Evms also use BLKGETSIZE64 in a way that would be safely. The problem is
that hppa kernel just printk a bug message and do not return a error message
as ENOSYS or ENOTSUP? (duno yet how other platform manage this case)

Thanks for advise (will inform of progress)
    Joel

Re: [parisc-linux] Re: mkfs.xfs (xfsprogs-2.3.5) failled

[jsoe0708]

>
>> Hm, maybe, it has been a while since I updated that machine.
>> 
>> 2.4.19-pa9-xfs is running there.
>
>what machine was this on? is this a 32-bit or 64-bit kernel?
>
For my part it is 2.4.19-pa22 [32bits] (on a b180l)

I do think that BLGKETSIZE64 (in put_user and get_user) is well supported
in 64bits kernel but the job still have to do on 32bits kernel (?)

Thanks for attention and help,
    Joel

Re: [parisc-linux] Re: mkfs.xfs (xfsprogs-2.3.5) failled

[jsoe0708]

Hi Randolph,

It sure I found a bug in the two parts kernel and xfs.

A. The kernel hppa: put_user and get_user does just a printk for BUG messages
but don't return error code as ENOTSUP (or what else) (what I assume the
other platforms does when they do not yet support BLKGETSIZE64?)

Here is a small patch I suggest:
(I do not reach to implement an operational support of BLKGETSIZE64 [for
32bits kernel]; I do not find a easy way to manage code failure :-( )

--- uaccess.h.orig	2002-10-22 15:14:54.000000000 +0200
+++ uaccess.h	2002-10-23 13:46:48.000000000 +0200
@@ -35,10 +35,10 @@
 #define get_user __get_user
 
 #if BITS_PER_LONG == 32
-#define LDD_KERNEL(ptr)		BUG()
-#define LDD_USER(ptr)		BUG()
-#define STD_KERNEL(x, ptr)	BUG()
-#define STD_USER(x, ptr)	BUG()
+#define LDD_KERNEL(ptr)		BUG(); __gu_err=ENOTSUP;
+#define LDD_USER(ptr)		BUG(); __gu_err=ENOTSUP;
+#define STD_KERNEL(x, ptr)	BUG(); __pu_err=ENOTSUP;
+#define STD_USER(x, ptr)	BUG(); __pu_err=ENOTSUP;
 #else
 #define LDD_KERNEL(ptr) __get_kernel_asm("ldd",ptr)
 #define LDD_USER(ptr) __get_user_asm("ldd",ptr)
@@ -75,7 +75,7 @@
 	    case 2: __get_kernel_asm("ldh",ptr); break; \
 	    case 4: __get_kernel_asm("ldw",ptr); break; \
 	    case 8: LDD_KERNEL(ptr); break;		\
-	    default: BUG(); break;                      \
+	    default: BUG(); __gu_err=ENOTSUP; break;    \
 	    }                                           \
 	}                                               \
 	else {                                          \
@@ -84,7 +84,7 @@
 	    case 2: __get_user_asm("ldh",ptr); break;   \
 	    case 4: __get_user_asm("ldw",ptr); break;   \
 	    case 8: LDD_USER(ptr);  break;		\
-	    default: BUG(); break;                      \
+	    default: BUG(); __gu_err=ENOTSUP; break;    \
 	    }                                           \
 	}                                               \
 							\
@@ -144,7 +144,7 @@
 	    case 2: __put_kernel_asm("sth",x,ptr); break;       \
 	    case 4: __put_kernel_asm("stw",x,ptr); break;       \
 	    case 8: STD_KERNEL(x,ptr); break;			\
-	    default: BUG(); break;                              \
+	    default: BUG(); __pu_err=ENOTSUP; break;		\
 	    }                                                   \
 	}                                                       \
 	else {                                                  \
@@ -153,7 +153,7 @@
 	    case 2: __put_user_asm("sth",x,ptr); break;         \
 	    case 4: __put_user_asm("stw",x,ptr); break;         \
 	    case 8: STD_USER(x,ptr); break;			\
-	    default: BUG(); break;                              \
+	    default: BUG(); __pu_err=ENOTSUP; break;		\
 	    }                                                   \
 	}                                                       \
 								\

If all agreed, (awaiting better :?) can somebody ci it?


Thanks in advance for attention,
    Joel

PS: 
B. in xfs:

 	error = ioctl(fd, BLKGETSIZE64, &size);
-	if (error >= 0) {
+	if (!error) {
 		/* BLKGETSIZE64 returns size in bytes not 512-byte blocks */

AFAIK ioctl should return error=0 if success and error <>0 (>0?) 

here is the full patch I will suggest:

--- cmd/xfsprogs/libxfs/init.c.orig	2002-10-25 12:12:29.000000000 +0200
+++ cmd/xfsprogs/libxfs/init.c	2002-10-25 14:22:34.000000000 +0200
@@ -155,11 +155,14 @@
 			progname, path, strerror(errno));
 		exit(1);
 	}
+#if !defined(__hppa__) || defined(__LP64__)
 	error = ioctl(fd, BLKGETSIZE64, &size);
-	if (error >= 0) {
+	if (!error) {
 		/* BLKGETSIZE64 returns size in bytes not 512-byte blocks */
 		size = size >> 9;
-	} else {
+	} else
+#endif
+        {
 		/* If BLKGETSIZE64 fails, try BLKGETSIZE */
 		unsigned long tmpsize;
 		error = ioctl(fd, BLKGETSIZE, &tmpsize);

Re: [parisc-linux] Re: mkfs.xfs (xfsprogs-2.3.5) failled

[jsoe0708]

too bad:

 man ioctl advise that it would return -1 (not ENOTSUP which would be assign
to errno) I will try to see how?

Sorry to annoy,
    Joel

>-- Original Message --
>From: jsoe0708@tiscali.be
>Subject: Re: [parisc-linux] Re: mkfs.xfs (xfsprogs-2.3.5) failled
>To: "Randolph Chung" <randolph@tausq.org>,
>	"Stefan Pfetzing" <dreamind@dreamind.de>
>Cc: parisc-linux@lists.parisc-linux.org
>Date: Fri, 25 Oct 2002 14:58:42 +0200
>
>
>Hi Randolph,
>
>It sure I found a bug in the two parts kernel and xfs.
>
>A. The kernel hppa: put_user and get_user does just a printk for BUG messages
>but don't return error code as ENOTSUP (or what else) (what I assume the
>other platforms does when they do not yet support BLKGETSIZE64?)
>
>Here is a small patch I suggest:
>(I do not reach to implement an operational support of BLKGETSIZE64 [for
>32bits kernel]; I do not find a easy way to manage code failure :-( )
>
>--- uaccess.h.orig	2002-10-22 15:14:54.000000000 +0200
>+++ uaccess.h	2002-10-23 13:46:48.000000000 +0200
>@@ -35,10 +35,10 @@
> #define get_user __get_user
> 
> #if BITS_PER_LONG == 32
>-#define LDD_KERNEL(ptr)		BUG()
>-#define LDD_USER(ptr)		BUG()
>-#define STD_KERNEL(x, ptr)	BUG()
>-#define STD_USER(x, ptr)	BUG()
>+#define LDD_KERNEL(ptr)		BUG(); __gu_err=ENOTSUP;
>+#define LDD_USER(ptr)		BUG(); __gu_err=ENOTSUP;
>+#define STD_KERNEL(x, ptr)	BUG(); __pu_err=ENOTSUP;
>+#define STD_USER(x, ptr)	BUG(); __pu_err=ENOTSUP;
> #else
> #define LDD_KERNEL(ptr) __get_kernel_asm("ldd",ptr)
> #define LDD_USER(ptr) __get_user_asm("ldd",ptr)
>@@ -75,7 +75,7 @@
> 	    case 2: __get_kernel_asm("ldh",ptr); break; \
> 	    case 4: __get_kernel_asm("ldw",ptr); break; \
> 	    case 8: LDD_KERNEL(ptr); break;		\
>-	    default: BUG(); break;                      \
>+	    default: BUG(); __gu_err=ENOTSUP; break;    \
> 	    }                                           \
> 	}                                               \
> 	else {                                          \
>@@ -84,7 +84,7 @@
> 	    case 2: __get_user_asm("ldh",ptr); break;   \
> 	    case 4: __get_user_asm("ldw",ptr); break;   \
> 	    case 8: LDD_USER(ptr);  break;		\
>-	    default: BUG(); break;                      \
>+	    default: BUG(); __gu_err=ENOTSUP; break;    \
> 	    }                                           \
> 	}                                               \
> 							\
>@@ -144,7 +144,7 @@
> 	    case 2: __put_kernel_asm("sth",x,ptr); break;       \
> 	    case 4: __put_kernel_asm("stw",x,ptr); break;       \
> 	    case 8: STD_KERNEL(x,ptr); break;			\
>-	    default: BUG(); break;                              \
>+	    default: BUG(); __pu_err=ENOTSUP; break;		\
> 	    }                                                   \
> 	}                                                       \
> 	else {                                                  \
>@@ -153,7 +153,7 @@
> 	    case 2: __put_user_asm("sth",x,ptr); break;         \
> 	    case 4: __put_user_asm("stw",x,ptr); break;         \
> 	    case 8: STD_USER(x,ptr); break;			\
>-	    default: BUG(); break;                              \
>+	    default: BUG(); __pu_err=ENOTSUP; break;		\
> 	    }                                                   \
> 	}                                                       \
> 								\
>
>If all agreed, (awaiting better :?) can somebody ci it?
>
>
>Thanks in advance for attention,
>    Joel
>
>PS: 
>B. in xfs:
>
> 	error = ioctl(fd, BLKGETSIZE64, &size);
>-	if (error >= 0) {
>+	if (!error) {
> 		/* BLKGETSIZE64 returns size in bytes not 512-byte blocks */
>
>AFAIK ioctl should return error=0 if success and error <>0 (>0?) 
>
>here is the full patch I will suggest:
>
>--- cmd/xfsprogs/libxfs/init.c.orig	2002-10-25 12:12:29.000000000 +0200
>+++ cmd/xfsprogs/libxfs/init.c	2002-10-25 14:22:34.000000000 +0200
>@@ -155,11 +155,14 @@
> 			progname, path, strerror(errno));
> 		exit(1);
> 	}
>+#if !defined(__hppa__) || defined(__LP64__)
> 	error = ioctl(fd, BLKGETSIZE64, &size);
>-	if (error >= 0) {
>+	if (!error) {
> 		/* BLKGETSIZE64 returns size in bytes not 512-byte blocks */
> 		size = size >> 9;
>-	} else {
>+	} else
>+#endif
>+        {
> 		/* If BLKGETSIZE64 fails, try BLKGETSIZE */
> 		unsigned long tmpsize;
> 		error = ioctl(fd, BLKGETSIZE, &tmpsize);
>
>_______________________________________________
>parisc-linux mailing list
>parisc-linux@lists.parisc-linux.org
>http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: mkfs.xfs (xfsprogs-2.3.5) failled

[Randolph Chung]

>  #define LDD_KERNEL(ptr) __get_kernel_asm("ldd",ptr)
>  #define LDD_USER(ptr) __get_user_asm("ldd",ptr)
> @@ -75,7 +75,7 @@
>  	    case 2: __get_kernel_asm("ldh",ptr); break; \
>  	    case 4: __get_kernel_asm("ldw",ptr); break; \
>  	    case 8: LDD_KERNEL(ptr); break;		\
> -	    default: BUG(); break;                      \
> +	    default: BUG(); __gu_err=ENOTSUP; break;    \
>  	    }                                           \
>  	}                                               \

this is wrong.

get_user is not defined to return an errno, just whether it's successful
or not.

i'll take a closer look this weekend.

randolph

Re: [parisc-linux] Re: mkfs.xfs (xfsprogs-2.3.5) failled

[Joel Soete]

Hmm question about "default:" uaccess.h implementation on different 
platform:

i386 declare: "extern void __get_user_bad(void);"

ia64: "extern void __get_user_unknown (void);"

mips: "extern void __get_user_unknown(void);"
...
but not define elsewhere? (is it there so that the build of the kernel 
failed if that case was requested to run properly?)

Thanks in advance for attention,
     Joel

PS: afaik on i386 only put_user_u64 is define why not pending get_user?


jsoe0708@tiscali.be wrote:
> too bad:
> 
>  man ioctl advise that it would return -1 (not ENOTSUP which would be assign
> to errno) I will try to see how?
> 
> Sorry to annoy,
>     Joel
> 
> 
>>-- Original Message --
>>From: jsoe0708@tiscali.be
>>Subject: Re: [parisc-linux] Re: mkfs.xfs (xfsprogs-2.3.5) failled
>>To: "Randolph Chung" <randolph@tausq.org>,
>>	"Stefan Pfetzing" <dreamind@dreamind.de>
>>Cc: parisc-linux@lists.parisc-linux.org
>>Date: Fri, 25 Oct 2002 14:58:42 +0200
>>
>>
>>Hi Randolph,
>>
>>It sure I found a bug in the two parts kernel and xfs.
>>
>>A. The kernel hppa: put_user and get_user does just a printk for BUG messages
>>but don't return error code as ENOTSUP (or what else) (what I assume the
>>other platforms does when they do not yet support BLKGETSIZE64?)
>>
>>Here is a small patch I suggest:
>>(I do not reach to implement an operational support of BLKGETSIZE64 [for
>>32bits kernel]; I do not find a easy way to manage code failure :-( )
>>
>>--- uaccess.h.orig	2002-10-22 15:14:54.000000000 +0200
>>+++ uaccess.h	2002-10-23 13:46:48.000000000 +0200
>>@@ -35,10 +35,10 @@
>>#define get_user __get_user
>>
>>#if BITS_PER_LONG == 32
>>-#define LDD_KERNEL(ptr)		BUG()
>>-#define LDD_USER(ptr)		BUG()
>>-#define STD_KERNEL(x, ptr)	BUG()
>>-#define STD_USER(x, ptr)	BUG()
>>+#define LDD_KERNEL(ptr)		BUG(); __gu_err=ENOTSUP;
>>+#define LDD_USER(ptr)		BUG(); __gu_err=ENOTSUP;
>>+#define STD_KERNEL(x, ptr)	BUG(); __pu_err=ENOTSUP;
>>+#define STD_USER(x, ptr)	BUG(); __pu_err=ENOTSUP;
>>#else
>>#define LDD_KERNEL(ptr) __get_kernel_asm("ldd",ptr)
>>#define LDD_USER(ptr) __get_user_asm("ldd",ptr)
>>@@ -75,7 +75,7 @@
>>	    case 2: __get_kernel_asm("ldh",ptr); break; \
>>	    case 4: __get_kernel_asm("ldw",ptr); break; \
>>	    case 8: LDD_KERNEL(ptr); break;		\
>>-	    default: BUG(); break;                      \
>>+	    default: BUG(); __gu_err=ENOTSUP; break;    \
>>	    }                                           \
>>	}                                               \
>>	else {                                          \
>>@@ -84,7 +84,7 @@
>>	    case 2: __get_user_asm("ldh",ptr); break;   \
>>	    case 4: __get_user_asm("ldw",ptr); break;   \
>>	    case 8: LDD_USER(ptr);  break;		\
>>-	    default: BUG(); break;                      \
>>+	    default: BUG(); __gu_err=ENOTSUP; break;    \
>>	    }                                           \
>>	}                                               \
>>							\
>>@@ -144,7 +144,7 @@
>>	    case 2: __put_kernel_asm("sth",x,ptr); break;       \
>>	    case 4: __put_kernel_asm("stw",x,ptr); break;       \
>>	    case 8: STD_KERNEL(x,ptr); break;			\
>>-	    default: BUG(); break;                              \
>>+	    default: BUG(); __pu_err=ENOTSUP; break;		\
>>	    }                                                   \
>>	}                                                       \
>>	else {                                                  \
>>@@ -153,7 +153,7 @@
>>	    case 2: __put_user_asm("sth",x,ptr); break;         \
>>	    case 4: __put_user_asm("stw",x,ptr); break;         \
>>	    case 8: STD_USER(x,ptr); break;			\
>>-	    default: BUG(); break;                              \
>>+	    default: BUG(); __pu_err=ENOTSUP; break;		\
>>	    }                                                   \
>>	}                                                       \
>>								\
>>
>>If all agreed, (awaiting better :?) can somebody ci it?
>>
>>
>>Thanks in advance for attention,
>>   Joel
>>
>>PS: 
>>B. in xfs:
>>
>>	error = ioctl(fd, BLKGETSIZE64, &size);
>>-	if (error >= 0) {
>>+	if (!error) {
>>		/* BLKGETSIZE64 returns size in bytes not 512-byte blocks */
>>
>>AFAIK ioctl should return error=0 if success and error <>0 (>0?) 
>>
>>here is the full patch I will suggest:
>>
>>--- cmd/xfsprogs/libxfs/init.c.orig	2002-10-25 12:12:29.000000000 +0200
>>+++ cmd/xfsprogs/libxfs/init.c	2002-10-25 14:22:34.000000000 +0200
>>@@ -155,11 +155,14 @@
>>			progname, path, strerror(errno));
>>		exit(1);
>>	}
>>+#if !defined(__hppa__) || defined(__LP64__)
>>	error = ioctl(fd, BLKGETSIZE64, &size);
>>-	if (error >= 0) {
>>+	if (!error) {
>>		/* BLKGETSIZE64 returns size in bytes not 512-byte blocks */
>>		size = size >> 9;
>>-	} else {
>>+	} else
>>+#endif
>>+        {
>>		/* If BLKGETSIZE64 fails, try BLKGETSIZE */
>>		unsigned long tmpsize;
>>		error = ioctl(fd, BLKGETSIZE, &tmpsize);
>>
>>_______________________________________________
>>parisc-linux mailing list
>>parisc-linux@lists.parisc-linux.org
>>http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
> 
> 
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
> 

Re: [parisc-linux] Re: mkfs.xfs (xfsprogs-2.3.5) failled

[Randolph Chung]

In reference to a message from Joel Soete, dated Oct 26:
> i386 declare: "extern void __get_user_bad(void);"
> ...
> but not define elsewhere? (is it there so that the build of the kernel 
> failed if that case was requested to run properly?)

yes.

> PS: afaik on i386 only put_user_u64 is define why not pending get_user?

on first glance i haven't found any code that uses get_user with 64-bit
quantities. if you have a specific need for this, please let me know.

in the mean time, i've checked in support for put_user with 64-bit
values. This is in 2.4.19-pa24

Let me know if this works for you. i've tested it only lightly.

randolph
--  
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] Re: mkfs.xfs (xfsprogs-2.3.5) failled

[Joel Soete]

Joel Soete wrote:
> Hmm question about "default:" uaccess.h implementation on different 
> platform:
> 
> i386 declare: "extern void __get_user_bad(void);"
> 
> ia64: "extern void __get_user_unknown (void);"
> 
> mips: "extern void __get_user_unknown(void);"
> ...
> but not define elsewhere? (is it there so that the build of the kernel 
> failed if that case was requested to run properly?)

In the mean time I verify this hypothesis. So may I suggest a patch in 
this direction?

[Better would be to add _also_ support as in the patch I suggest in 
<http://lists.parisc-linux.org/pipermail/parisc-linux/2002-October/017887.html>
this was tested for __put_user_asm_64 && __put_kernel_asm_64 (not the 
corresponding __get_ :( I don't know yet if I can use a .fixup section ?)

May be some other could test and verify closer this part ?

Joel

> 
> Thanks in advance for attention,
>     Joel
> 
> PS: afaik on i386 only put_user_u64 is define why not pending get_user?
> 
> 
> jsoe0708@tiscali.be wrote:
> 
>> too bad:
>>
>>  man ioctl advise that it would return -1 (not ENOTSUP which would be 
>> assign
>> to errno) I will try to see how?
>>
>> Sorry to annoy,
>>     Joel
>>
>>
>>> -- Original Message --
>>> From: jsoe0708@tiscali.be
>>> Subject: Re: [parisc-linux] Re: mkfs.xfs (xfsprogs-2.3.5) failled
>>> To: "Randolph Chung" <randolph@tausq.org>,
>>>     "Stefan Pfetzing" <dreamind@dreamind.de>
>>> Cc: parisc-linux@lists.parisc-linux.org
>>> Date: Fri, 25 Oct 2002 14:58:42 +0200
>>>
>>>
>>> Hi Randolph,
>>>
>>> It sure I found a bug in the two parts kernel and xfs.
>>>
>>> A. The kernel hppa: put_user and get_user does just a printk for BUG 
>>> messages
>>> but don't return error code as ENOTSUP (or what else) (what I assume the
>>> other platforms does when they do not yet support BLKGETSIZE64?)
>>>
>>> Here is a small patch I suggest:
>>> (I do not reach to implement an operational support of BLKGETSIZE64 [for
>>> 32bits kernel]; I do not find a easy way to manage code failure :-( )
>>>
>>> --- uaccess.h.orig    2002-10-22 15:14:54.000000000 +0200
>>> +++ uaccess.h    2002-10-23 13:46:48.000000000 +0200
>>> @@ -35,10 +35,10 @@
>>> #define get_user __get_user
>>>
>>> #if BITS_PER_LONG == 32
>>> -#define LDD_KERNEL(ptr)        BUG()
>>> -#define LDD_USER(ptr)        BUG()
>>> -#define STD_KERNEL(x, ptr)    BUG()
>>> -#define STD_USER(x, ptr)    BUG()
>>> +#define LDD_KERNEL(ptr)        BUG(); __gu_err=ENOTSUP;
>>> +#define LDD_USER(ptr)        BUG(); __gu_err=ENOTSUP;
>>> +#define STD_KERNEL(x, ptr)    BUG(); __pu_err=ENOTSUP;
>>> +#define STD_USER(x, ptr)    BUG(); __pu_err=ENOTSUP;
>>> #else
>>> #define LDD_KERNEL(ptr) __get_kernel_asm("ldd",ptr)
>>> #define LDD_USER(ptr) __get_user_asm("ldd",ptr)
>>> @@ -75,7 +75,7 @@
>>>         case 2: __get_kernel_asm("ldh",ptr); break; \
>>>         case 4: __get_kernel_asm("ldw",ptr); break; \
>>>         case 8: LDD_KERNEL(ptr); break;        \
>>> -        default: BUG(); break;                      \
>>> +        default: BUG(); __gu_err=ENOTSUP; break;    \
>>>         }                                           \
>>>     }                                               \
>>>     else {                                          \
>>> @@ -84,7 +84,7 @@
>>>         case 2: __get_user_asm("ldh",ptr); break;   \
>>>         case 4: __get_user_asm("ldw",ptr); break;   \
>>>         case 8: LDD_USER(ptr);  break;        \
>>> -        default: BUG(); break;                      \
>>> +        default: BUG(); __gu_err=ENOTSUP; break;    \
>>>         }                                           \
>>>     }                                               \
>>>                             \
>>> @@ -144,7 +144,7 @@
>>>         case 2: __put_kernel_asm("sth",x,ptr); break;       \
>>>         case 4: __put_kernel_asm("stw",x,ptr); break;       \
>>>         case 8: STD_KERNEL(x,ptr); break;            \
>>> -        default: BUG(); break;                              \
>>> +        default: BUG(); __pu_err=ENOTSUP; break;        \
>>>         }                                                   \
>>>     }                                                       \
>>>     else {                                                  \
>>> @@ -153,7 +153,7 @@
>>>         case 2: __put_user_asm("sth",x,ptr); break;         \
>>>         case 4: __put_user_asm("stw",x,ptr); break;         \
>>>         case 8: STD_USER(x,ptr); break;            \
>>> -        default: BUG(); break;                              \
>>> +        default: BUG(); __pu_err=ENOTSUP; break;        \
>>>         }                                                   \
>>>     }                                                       \
>>>                                 \
>>>
>>> If all agreed, (awaiting better :?) can somebody ci it?
>>>
>>>
>>> Thanks in advance for attention,
>>>   Joel
>>>
>>> PS: B. in xfs:
>>>
>>>     error = ioctl(fd, BLKGETSIZE64, &size);
>>> -    if (error >= 0) {
>>> +    if (!error) {
>>>         /* BLKGETSIZE64 returns size in bytes not 512-byte blocks */
>>>
>>> AFAIK ioctl should return error=0 if success and error <>0 (>0?)
>>> here is the full patch I will suggest:
>>>
>>> --- cmd/xfsprogs/libxfs/init.c.orig    2002-10-25 12:12:29.000000000 
>>> +0200
>>> +++ cmd/xfsprogs/libxfs/init.c    2002-10-25 14:22:34.000000000 +0200
>>> @@ -155,11 +155,14 @@
>>>             progname, path, strerror(errno));
>>>         exit(1);
>>>     }
>>> +#if !defined(__hppa__) || defined(__LP64__)
>>>     error = ioctl(fd, BLKGETSIZE64, &size);
>>> -    if (error >= 0) {
>>> +    if (!error) {
>>>         /* BLKGETSIZE64 returns size in bytes not 512-byte blocks */
>>>         size = size >> 9;
>>> -    } else {
>>> +    } else
>>> +#endif
>>> +        {
>>>         /* If BLKGETSIZE64 fails, try BLKGETSIZE */
>>>         unsigned long tmpsize;
>>>         error = ioctl(fd, BLKGETSIZE, &tmpsize);
>>>
>>> _______________________________________________
>>> parisc-linux mailing list
>>> parisc-linux@lists.parisc-linux.org
>>> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>>
>>
>>
>> _______________________________________________
>> parisc-linux mailing list
>> parisc-linux@lists.parisc-linux.org
>> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>>
> 
> 

Re: [parisc-linux] Re: mkfs.xfs (xfsprogs-2.3.5) failled

[Joel Soete]

__pu_err disapear in ..asm64?
It doesn't seems to be an error, so don't we need anymore??

Joel Soete wrote:
> 
> 
> Randolph Chung wrote:
> 
>> In reference to a message from Joel Soete, dated Oct 26:
>>
>>> i386 declare: "extern void __get_user_bad(void);"
>>> ...
>>> but not define elsewhere? (is it there so that the build of the 
>>> kernel failed if that case was requested to run properly?)
>>
>>
>>
>> yes.
>>
>>
>>> PS: afaik on i386 only put_user_u64 is define why not pending get_user?
>>
>>
>>
>> on first glance i haven't found any code that uses get_user with 64-bit
>> quantities.
> 
> 
> Not found too.
> 
>> if you have a specific need for this, please let me know.
> 
> 
> No spefic need, thanks. It was just because mips (32bits) already 
> foreseen it and it would be already complete :)
> 
>>
>> in the mean time, i've checked in support for put_user with 64-bit
>> values. This is in 2.4.19-pa24
> 
> 
> Great, I will test it (in fact I was not so far; just a problem of 
> writing the right way).
> 
> Anyway couldn't we also consider __get_user_bad() and __get_kernel_bad() 
> for _default:_ case (just to avoid erronious case: with the problem 
> encounter with xfs test I was near to loose all my system :(( )?
> 
>>
>> Let me know if this works for you. i've tested it only lightly.
>>
> Just have to wait a few days to test at office.
> 
> Thanks again.
> 
> See you,
>     Joel
> 
>