[parisc-linux] XFS - blkgetsize64

[parisc-linux] XFS - blkgetsize64

[Stefan Pfetzing]

Hi,

I just tried to get XFS working on my C200 (I've got a new IBM SCSI disk.) and
mkfs.xfs always got the size of the Device (/dev/sda5) wrong. (it complained
about not getting with lseek64 to that position...)
(I don't have the correct error message ready, but I can check, if its needed)

After I changed the libxfs to only use the BLKGETSIZE64 ioctl, it works fine
now. (Eric Sandeen pointed me to this)

So he said, perhaps there is a bug in the SCSI (lasi?) driver.

bye

Stefan

P.S.: I'm using 2.4.19-pa9 with a self made diff from vanilla 2.4.19 against
XFS CVS. (the patch did in nearly cleanly)
-- 
        http://www.dreamind.de/
Oroborus and Debian GNU/Linux Developer.

Re: [parisc-linux] XFS - blkgetsize64

[Grant Grundler]

Stefan Pfetzing wrote:
> mkfs.xfs always got the size of the Device (/dev/sda5) wrong. (it complained
> about not getting with lseek64 to that position...)
...
> So he said, perhaps there is a bug in the SCSI (lasi?) driver.

I don't think it's the driver.

lseek64 must be getting redirected to lseek().
Linux kernel only supports "lseek".
See "struct file_operations" in include/linux/fs.h.

loff_t is a 64-bit type.
include/linux/types.h:typedef __kernel_loff_t           loff_t;
include/asm/posix_types.h:typedef long long             __kernel_loff_t;

> P.S.: I'm using 2.4.19-pa9 with a self made diff from vanilla 2.4.19 against
> XFS CVS. (the patch did in nearly cleanly)

Are you running 32-bit or 64-bit kernel?
I want to know if arch/parisc/kernel/sys_parisc32.c might be the problem.

grant

Re: [parisc-linux] XFS - blkgetsize64

[Randolph Chung]

> I don't think it's the driver.

no, not the driver...

> lseek64 must be getting redirected to lseek().
> Linux kernel only supports "lseek".

lseek64 is translated to a sys_llseek (you can see that with strace). 

> See "struct file_operations" in include/linux/fs.h.
> loff_t is a 64-bit type.
> include/linux/types.h:typedef __kernel_loff_t           loff_t;
> include/asm/posix_types.h:typedef long long             __kernel_loff_t;

we need to do some tricks to get this right ... some of the other
syscalls are fixed, but this one is not it seems.

> I want to know if arch/parisc/kernel/sys_parisc32.c might be the problem.

fwiw sys_llseek is not translated.

randolph

Re: [parisc-linux] XFS - blkgetsize64

[Stefan Pfetzing]

Hi,

* Grant Grundler <grundler@dsl2.external.hp.com> [020904 18:51]:
> Stefan Pfetzing wrote:
[snip]
> > P.S.: I'm using 2.4.19-pa9 with a self made diff from vanilla 2.4.19 against
> > XFS CVS. (the patch did in nearly cleanly)
> 
> Are you running 32-bit or 64-bit kernel?
> I want to know if arch/parisc/kernel/sys_parisc32.c might be the problem.
I'm running a 32bit kernel, since some time ago I had problems with 64bit and
cdrecord.

bye

Stefan

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

[parisc-linux] GCC and quad-precision floating point

[John David Anglin]

I have just implemented some fixes and changed the long double size
to 128 bits on the hppa64 GCC ports.  For parisc-linux, the long double
support should be 128 bits (both for 32 and 64 bit) but we are currently
stuck at 64 bits because we are missing a bunch of quad library calls:

_U_Qfadd, _U_Qfsub, _U_Qfmpy, _U_Qfdiv, _U_Qfneg, _U_Qfsqrt, _U_Qfabs,
_U_Qfmin, _U_Qfmax, _U_Qfcnvff_sgl_to_quad, _U_Qfcnvff_dbl_to_quad,
_U_Qfcnvff_quad_to_sgl, _U_Qfcnvff_quad_to_dbl, _U_Qfcnvxf_sgl_to_quad,
_U_Qfcnvxf_dbl_to_quad, _U_Qfcnvfxt_quad_to_sgl, _U_Qfcnvfxt_quad_to_usgl,
_U_Qfcnvfxt_quad_to_udbl, _U_Qfcnvfxt_quad_to_dbl, _U_Qfeq, _U_Qfne,
_U_Qfgt, _U_Qfge, _U_Qflt, _U_Qfle.

There are probably some more for unordered comparisons.

Any chance that someone with contacts inside HP, might be able to
obtain the source code for these functions?  They are really part
of the ABI.

While it's relatively straightforward to implement these using the
quad-precision instructions in the PA 2.0 architecture for the 64-bit
port, it's non trivial to implement them for earlier architectures
using the 32-bit port.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] GCC and quad-precision floating point

[Carlos O'Donell]

> I have just implemented some fixes and changed the long double size
> to 128 bits on the hppa64 GCC ports.  For parisc-linux, the long double
> support should be 128 bits (both for 32 and 64 bit) but we are currently
> stuck at 64 bits because we are missing a bunch of quad library calls:
> 
> _U_Qfadd, _U_Qfsub, _U_Qfmpy, _U_Qfdiv, _U_Qfneg, _U_Qfsqrt, _U_Qfabs,
> _U_Qfmin, _U_Qfmax, _U_Qfcnvff_sgl_to_quad, _U_Qfcnvff_dbl_to_quad,
> _U_Qfcnvff_quad_to_sgl, _U_Qfcnvff_quad_to_dbl, _U_Qfcnvxf_sgl_to_quad,
> _U_Qfcnvxf_dbl_to_quad, _U_Qfcnvfxt_quad_to_sgl, _U_Qfcnvfxt_quad_to_usgl,
> _U_Qfcnvfxt_quad_to_udbl, _U_Qfcnvfxt_quad_to_dbl, _U_Qfeq, _U_Qfne,
> _U_Qfgt, _U_Qfge, _U_Qflt, _U_Qfle.
> 
> There are probably some more for unordered comparisons.
> 
> Any chance that someone with contacts inside HP, might be able to
> obtain the source code for these functions?  They are really part
> of the ABI.
> 
> While it's relatively straightforward to implement these using the
> quad-precision instructions in the PA 2.0 architecture for the 64-bit
> port, it's non trivial to implement them for earlier architectures
> using the 32-bit port.
> 
> Dave

Randolph and I were discussing borrowing from gmp to implement some of 
these for the earlier 32-bit processors. Thought it seems that this may
break the HPUX compatibility? 

gmp seems to have support for:

	add, sub, multiply, div, neg, sqrt, abs, min, max
	equals, not-equals, greater-than, greather-than-or-equal,
	less-than, less-than-or-equal.	

The 'cnv' functions need to be addressed:

	single -> quad
	double -> quad
	quad   -> single
	quad   -> double
	quad   -> unsigned single
	quad   -> unsigned double

Under certain conditions of float-float, float-fixed, float-fixed&truncate.
This will have to follow the HPUX convention?

c.

Re: [parisc-linux] GCC and quad-precision floating point

[John David Anglin]

> Randolph and I were discussing borrowing from gmp to implement some of 
> these for the earlier 32-bit processors. Thought it seems that this may
> break the HPUX compatibility? 

I would guess that that the best compatibility would be obtained with
the HP functions.  As far as I can tell, gmp does not use IEEE standard
data types.  Thus, concepts of nans, snans, unordered if present at
all in gmp would differ.

GCC can only deal with floating data in IEEE format.  So, conversion
would have to be done for all operations.

I presume that the HPUX compatibility is just for static binaries
(i.e., there is no shared library support).  In this case, the routines
would be compiled into hpux binaries.  So, I don't think much additional
would be needed at an os level.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] XFS - blkgetsize64

[Stefan Pfetzing]

Hum, replying to myself...

* Stefan Pfetzing <dreamind@dreamind.de> [020904 20:28]:
> * Grant Grundler <grundler@dsl2.external.hp.com> [020904 18:51]:
> > Stefan Pfetzing wrote:
> [snip]
> > > P.S.: I'm using 2.4.19-pa9 with a self made diff from vanilla 2.4.19 against
> > > XFS CVS. (the patch did in nearly cleanly)
> > 
> > Are you running 32-bit or 64-bit kernel?
> > I want to know if arch/parisc/kernel/sys_parisc32.c might be the problem.
> I'm running a 32bit kernel, since some time ago I had problems with 64bit and
> cdrecord.

I just got a blkgetsize* testprogram...
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=62038)

---snip---
root@hp:~# ./blkgetsizetester /dev/sda2
Device size is 83968 blocks (42991616 bytes)
Device size per BLKGETSIZE64 is 12345 bytes
root@hp:~# ./blkgetsizetester /dev/sda5 
Device size is 1026016 blocks (525320192 bytes)
Device size per BLKGETSIZE64 is 12345 bytes
root@hp:~#
---snip---

I think thats the problem with xfs... well at least blkgetsize64 should report
an error, if its not working correctly.

bye

Stefan

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

Re: [parisc-linux] XFS - blkgetsize64

[Randolph Chung]

> I just got a blkgetsize* testprogram...
> (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=62038)

the test program has a nasty bug in it...
#define BLKGETSIZE64 _IOR(0x12,114,sizeof(unsigned long long)) /* return device

that's wrong.. it should be
#define BLKGETSIZE64 _IOR(0x12,114,unsigned long long) /* return device

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

Re: [parisc-linux] XFS - blkgetsize64

[Randolph Chung]

> I just tried to get XFS working on my C200 (I've got a new IBM SCSI disk.) and
> mkfs.xfs always got the size of the Device (/dev/sda5) wrong. (it complained
> about not getting with lseek64 to that position...)

64-bit kernel:
tausq@gsyprf11:~$ ls -l tst
-r-x--xr--    1 tausq    tausq    1099511627777 Sep  4 22:18 tst*
tausq@gsyprf11:~$ ./tt tst
lseek64(3,0,SEEK_END) = 1048576M


on my gecko (32-bit)
randolph@frodo:~$ sudo ./t /dev/sda3
lseek64(3,0,SEEK_END) = 1949M

seems to work ok?

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