* [parisc-linux] fdisk problems 2.4 <-> 2.6
@ 2003-11-05 20:21 Ruediger Scholz
2003-11-06 22:29 ` Matthew Wilcox
2003-11-10 21:58 ` Ruediger Scholz
0 siblings, 2 replies; 23+ messages in thread
From: Ruediger Scholz @ 2003-11-05 20:21 UTC (permalink / raw)
To: parisc-linux
Hi there,
it's me again. I repartioned a IBM-hd with 4330 MB but when running
fdisk with 2.6.0-test8-pa4, fdisk told me:
--------><------------
gandalf:~# fdisk /dev/sdb
Befehl (m für Hilfe): p
Platte /dev/sdb: 40 MByte, 40239104 Byte
134 Köpfe, 62 Sektoren/Spuren, 9 Zylinder
Einheiten = Zylinder von 8308 * 512 = 4253696 Bytes
Gerät Boot Start End Blocks Id System
/dev/sdb1 * 1 8 33201 f0 Linux/PA-RISC boot
/dev/sdb2 9 23 62310 83 Linux
/dev/sdb3 24 83 249240 82 Linux Swap
/dev/sdb4 84 1019 3888144 8e Linux LVM
Befehl (m für Hilfe):
------><-------------
Cause some bytes are missing ;) I booted 2.4.22-pa13 and fdisk is now
telling the correct values:
-------><--------
gandalf:~# fdisk /dev/sdb
Befehl (m für Hilfe): p
Platte /dev/sdb: 4335 MByte, 4335206400 Byte
134 Köpfe, 62 Sektoren/Spuren, 1019 Zylinder
Einheiten = Zylinder von 8308 * 512 = 4253696 Bytes
Gerät Boot Start End Blocks Id System
/dev/sdb1 * 1 8 33201 f0 Linux/PA-RISC boot
/dev/sdb2 9 23 62310 83 Linux
/dev/sdb3 24 83 249240 82 Linux Swap
/dev/sdb4 84 1019 3888144 8e Linux LVM
Befehl (m für Hilfe): q
gandalf:~#
----------><--------
I have a 715/100 with 128 MB, a 2GB Seagate and a 4GB IBM-HD.
With my 2GB fdisk seems to have no problem:
------>2.6.0-test8-pa4<---------
gandalf:~# fdisk /dev/sda
Befehl (m für Hilfe): p
Platte /dev/sda: 2147 MByte, 2147678720 Byte
67 Köpfe, 62 Sektoren/Spuren, 1009 Zylinder
Einheiten = Zylinder von 4154 * 512 = 2126848 Bytes
Gerät Boot Start End Blocks Id System
/dev/sda1 1 11 22816 f0 Linux/PA-RISC boot
/dev/sda2 12 32 43617 83 Linux
/dev/sda3 33 96 132928 82 Linux Swap
/dev/sda4 97 1009 1896301 83 Linux
Befehl (m für Hilfe):
-----><-----------
----->2.4.22-pa13<----------
gandalf:~# fdisk /dev/sda
Befehl (m für Hilfe): p
Platte /dev/sda: 2147 MByte, 2147678720 Byte
67 Köpfe, 62 Sektoren/Spuren, 1009 Zylinder
Einheiten = Zylinder von 4154 * 512 = 2126848 Bytes
Gerät Boot Start End Blocks Id System
/dev/sda1 1 11 22816 f0 Linux/PA-RISC boot
/dev/sda2 12 32 43617 83 Linux
/dev/sda3 33 96 132928 82 Linux Swap
/dev/sda4 97 1009 1896301 83 Linux
Befehl (m für Hilfe):
----------><----------
Anybody encounter the same problems with fdisk?
Greetings,
Ruediger
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [parisc-linux] fdisk problems 2.4 <-> 2.6 2003-11-05 20:21 [parisc-linux] fdisk problems 2.4 <-> 2.6 Ruediger Scholz @ 2003-11-06 22:29 ` Matthew Wilcox 2003-11-07 17:52 ` Joel Soete 2003-11-07 20:32 ` Ruediger Scholz 2003-11-10 21:58 ` Ruediger Scholz 1 sibling, 2 replies; 23+ messages in thread From: Matthew Wilcox @ 2003-11-06 22:29 UTC (permalink / raw) To: Ruediger Scholz; +Cc: parisc-linux On Wed, Nov 05, 2003 at 09:21:14PM +0100, Ruediger Scholz wrote: > it's me again. I repartioned a IBM-hd with 4330 MB but when running > fdisk with 2.6.0-test8-pa4, fdisk told me: > > --------><------------ > gandalf:~# fdisk /dev/sdb > > Befehl (m für Hilfe): p > > Platte /dev/sdb: 40 MByte, 40239104 Byte Oh oh. We have an interesting problem here. > Platte /dev/sdb: 4335 MByte, 4335206400 Byte 4335206400 - 4294967296 = 40239104 So we've lost the top 32 bits of the value. Can you run it under strace and tell me what ioctls fdisk is calling? I bet it's calling BLKGETSIZE64 and our put_user() is broken. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [parisc-linux] fdisk problems 2.4 <-> 2.6 2003-11-06 22:29 ` Matthew Wilcox @ 2003-11-07 17:52 ` Joel Soete 2003-11-08 1:59 ` Grant Grundler 2003-11-07 20:32 ` Ruediger Scholz 1 sibling, 1 reply; 23+ messages in thread From: Joel Soete @ 2003-11-07 17:52 UTC (permalink / raw) To: Matthew Wilcox, Ruediger Scholz; +Cc: parisc-linux > [...] I bet it's calling BLKGETSIZE64 and our put_user() is broken. I trusted that Grant merged the same code in 2.4 and 2.6 for put_user() some time ago? Is it the same with 64bits kernels? hth, Joel ------------------------------------------------------------------------- Tiscali ADSL: 3 mois GRATUITS! L'Internet rapide, c'est pour tout le monde. http://reg.tiscali.be/default.asp?lg=fr ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [parisc-linux] fdisk problems 2.4 <-> 2.6 2003-11-07 17:52 ` Joel Soete @ 2003-11-08 1:59 ` Grant Grundler 2003-11-08 10:59 ` Joel Soete 0 siblings, 1 reply; 23+ messages in thread From: Grant Grundler @ 2003-11-08 1:59 UTC (permalink / raw) To: Joel Soete; +Cc: Matthew Wilcox, Ruediger Scholz, parisc-linux On Fri, Nov 07, 2003 at 06:52:58PM +0100, Joel Soete wrote: > > [...] I bet it's calling BLKGETSIZE64 and our put_user() is broken. > > I trusted that Grant merged the same code in 2.4 and 2.6 for put_user() some > time ago? put_user()? I don't recall. > Is it the same with 64bits kernels? Can you point me at the modified 2.4 file and I'll check. thanks, grant ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [parisc-linux] fdisk problems 2.4 <-> 2.6 2003-11-08 1:59 ` Grant Grundler @ 2003-11-08 10:59 ` Joel Soete 2003-11-08 19:48 ` Grant Grundler 0 siblings, 1 reply; 23+ messages in thread From: Joel Soete @ 2003-11-08 10:59 UTC (permalink / raw) To: Grant Grundler; +Cc: Matthew Wilcox, Ruediger Scholz, parisc-linux Grant Grundler wrote: > On Fri, Nov 07, 2003 at 06:52:58PM +0100, Joel Soete wrote: > >>>[...] I bet it's calling BLKGETSIZE64 and our put_user() is broken. >> >>I trusted that Grant merged the same code in 2.4 and 2.6 for put_user() some >>time ago? > > > put_user()? > I don't recall. > > >>Is it the same with 64bits kernels? > > > Can you point me at the modified 2.4 file and I'll check. > IIRC include/asm-parisc/uaccess.h I do not work more on this stuff because I am awaiting patch that Randolph (always iirc) should still have in its tree to change the management of exception (which Matthew assumes to never occur in kernel mode iirc) (sorry but I just spend half an hour to find back this thread but without success :( ) hth, Joel ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [parisc-linux] fdisk problems 2.4 <-> 2.6 2003-11-08 10:59 ` Joel Soete @ 2003-11-08 19:48 ` Grant Grundler 2003-11-08 22:15 ` Joel Soete 0 siblings, 1 reply; 23+ messages in thread From: Grant Grundler @ 2003-11-08 19:48 UTC (permalink / raw) To: Joel Soete; +Cc: Grant Grundler, Matthew Wilcox, Ruediger Scholz, parisc-linux On Sat, Nov 08, 2003 at 10:59:20AM +0000, Joel Soete wrote: > IIRC include/asm-parisc/uaccess.h get/put user stuff looks the same to me in both 2.4/2.6 cvs. I'm likely to forget forward porting 2.4 changes to 2.6 but I thought I got that in the last round. If someone trolls the parisc-linux-cvs archive and compares my commits for the past 2-3 monthes... thanks, grant ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [parisc-linux] fdisk problems 2.4 <-> 2.6 2003-11-08 19:48 ` Grant Grundler @ 2003-11-08 22:15 ` Joel Soete 2003-11-09 13:50 ` Joel Soete 0 siblings, 1 reply; 23+ messages in thread From: Joel Soete @ 2003-11-08 22:15 UTC (permalink / raw) To: Grant Grundler; +Cc: Matthew Wilcox, Ruediger Scholz, parisc-linux Any way, should it be this stuff (I don't notice it before): ----------><---------- --- uaccess.h.orig 2004-04-20 19:58:08.000000000 +0200 +++ uaccess.h-t1 2004-04-20 20:10:09.000000000 +0200 @@ -42,8 +42,8 @@ #if BITS_PER_LONG == 32 #define LDD_KERNEL(ptr) __get_kernel_bad(); #define LDD_USER(ptr) __get_user_bad(); -#define STD_KERNEL(x, ptr) __put_kernel_asm64((u32)x,ptr) -#define STD_USER(x, ptr) __put_user_asm64((u32)x,ptr) +#define STD_KERNEL(x, ptr) __put_kernel_asm64(x,ptr) +#define STD_USER(x, ptr) __put_user_asm64(x,ptr) #else #define LDD_KERNEL(ptr) __get_kernel_asm("ldd",ptr) #define LDD_USER(ptr) __get_user_asm("ldd",ptr) ----------><---------- But I presume it should reuired some cast so would it be better: ----------><---------- --- uaccess.h.orig 2004-04-20 19:58:08.000000000 +0200 +++ uaccess.h-t2 2004-04-20 20:10:41.000000000 +0200 @@ -42,8 +42,8 @@ #if BITS_PER_LONG == 32 #define LDD_KERNEL(ptr) __get_kernel_bad(); #define LDD_USER(ptr) __get_user_bad(); -#define STD_KERNEL(x, ptr) __put_kernel_asm64((u32)x,ptr) -#define STD_USER(x, ptr) __put_user_asm64((u32)x,ptr) +#define STD_KERNEL(x, ptr) __put_kernel_asm64((u64)x,ptr) +#define STD_USER(x, ptr) __put_user_asm64((u64)x,ptr) #else #define LDD_KERNEL(ptr) __get_kernel_asm("ldd",ptr) #define LDD_USER(ptr) __get_user_asm("ldd",ptr) ----------><---------- I don't test it but hth, Joel Grant Grundler wrote: > On Sat, Nov 08, 2003 at 10:59:20AM +0000, Joel Soete wrote: > >>IIRC include/asm-parisc/uaccess.h > > > get/put user stuff looks the same to me in both 2.4/2.6 cvs. > I'm likely to forget forward porting 2.4 changes to 2.6 but I thought > I got that in the last round. If someone trolls the parisc-linux-cvs > archive and compares my commits for the past 2-3 monthes... > > thanks, > grant > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [parisc-linux] fdisk problems 2.4 <-> 2.6 2003-11-08 22:15 ` Joel Soete @ 2003-11-09 13:50 ` Joel Soete 2003-11-09 17:57 ` Matthew Wilcox 0 siblings, 1 reply; 23+ messages in thread From: Joel Soete @ 2003-11-09 13:50 UTC (permalink / raw) To: parisc-linux; +Cc: Grant Grundler, Matthew Wilcox, Ruediger Scholz Ok Ok :) Matthew you have right: Joel Soete wrote: > ----------><---------- > --- uaccess.h.orig 2004-04-20 19:58:08.000000000 +0200 > +++ uaccess.h-t2 2004-04-20 20:10:41.000000000 +0200 > @@ -42,8 +42,8 @@ > #if BITS_PER_LONG == 32 > #define LDD_KERNEL(ptr) __get_kernel_bad(); > #define LDD_USER(ptr) __get_user_bad(); > -#define STD_KERNEL(x, ptr) __put_kernel_asm64((u32)x,ptr) > -#define STD_USER(x, ptr) __put_user_asm64((u32)x,ptr) > +#define STD_KERNEL(x, ptr) __put_kernel_asm64((u64)x,ptr) > +#define STD_USER(x, ptr) __put_user_asm64((u64)x,ptr) > #else > #define LDD_KERNEL(ptr) __get_kernel_asm("ldd",ptr) > #define LDD_USER(ptr) __get_user_asm("ldd",ptr) > ----------><---------- I just test it and it seems to be a fix (among others): hpalin:~# fdisk /dev/sda Command (m for help): p Disk /dev/sda: 4294 MB, 4294816768 bytes 133 heads, 62 sectors/track, 1017 cylinders Units = cylinders of 8246 * 512 = 4221952 bytes Device Boot Start End Blocks Id System /dev/sda1 * 1 16 65937 f0 Linux/PA-RISC boot /dev/sda2 17 48 131936 fd Linux raid autodetect /dev/sda3 49 79 127813 fd Linux raid autodetect /dev/sda4 80 993 3768422 5 Extended /dev/sda5 80 496 1719260 fd Linux raid autodetect /dev/sda6 497 558 255595 fd Linux raid autodetect /dev/sda7 559 589 127782 fd Linux raid autodetect /dev/sda8 590 620 127782 fd Linux raid autodetect /dev/sda9 621 993 1537848 83 Linux Can somebody re-test it and ci for me? hth, Joel ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [parisc-linux] fdisk problems 2.4 <-> 2.6 2003-11-09 13:50 ` Joel Soete @ 2003-11-09 17:57 ` Matthew Wilcox 2003-11-09 18:59 ` Joel Soete 0 siblings, 1 reply; 23+ messages in thread From: Matthew Wilcox @ 2003-11-09 17:57 UTC (permalink / raw) To: Joel Soete; +Cc: parisc-linux, Grant Grundler, Matthew Wilcox, Ruediger Scholz On Sun, Nov 09, 2003 at 01:50:49PM +0000, Joel Soete wrote: > Joel Soete wrote: > >----------><---------- > >--- uaccess.h.orig 2004-04-20 19:58:08.000000000 +0200 > >+++ uaccess.h-t2 2004-04-20 20:10:41.000000000 +0200 > >@@ -42,8 +42,8 @@ > > #if BITS_PER_LONG == 32 > > #define LDD_KERNEL(ptr) __get_kernel_bad(); > > #define LDD_USER(ptr) __get_user_bad(); > >-#define STD_KERNEL(x, ptr) __put_kernel_asm64((u32)x,ptr) > >-#define STD_USER(x, ptr) __put_user_asm64((u32)x,ptr) > >+#define STD_KERNEL(x, ptr) __put_kernel_asm64((u64)x,ptr) > >+#define STD_USER(x, ptr) __put_user_asm64((u64)x,ptr) > > #else > > #define LDD_KERNEL(ptr) __get_kernel_asm("ldd",ptr) > > #define LDD_USER(ptr) __get_user_asm("ldd",ptr) > >----------><---------- > I just test it and it seems to be a fix (among others): I figured this out in Chicago airport yesterday. Grant just pointed me to this mail after I checked in the fix deleting the cast entirely. Thanks for testing though. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [parisc-linux] fdisk problems 2.4 <-> 2.6 2003-11-09 17:57 ` Matthew Wilcox @ 2003-11-09 18:59 ` Joel Soete 2003-11-10 4:45 ` Grant Grundler 0 siblings, 1 reply; 23+ messages in thread From: Joel Soete @ 2003-11-09 18:59 UTC (permalink / raw) To: Matthew Wilcox; +Cc: parisc-linux, Grant Grundler Just for remainder here is the alignement of uaccess.h (i just finished to test on my c110 :)): ----------><---------- --- uaccess.h.orig 2004-04-20 21:03:59.000000000 +0200 +++ uaccess.h 2003-11-09 18:47:06.000000000 +0100 @@ -42,8 +42,8 @@ #if BITS_PER_LONG == 32 #define LDD_KERNEL(ptr) __get_kernel_bad(); #define LDD_USER(ptr) __get_user_bad(); -#define STD_KERNEL(x, ptr) __put_kernel_asm64((u32)x,ptr) -#define STD_USER(x, ptr) __put_user_asm64((u32)x,ptr) +#define STD_KERNEL(x, ptr) __put_kernel_asm64((u64)x,ptr) +#define STD_USER(x, ptr) __put_user_asm64((u64)x,ptr) #else #define LDD_KERNEL(ptr) __get_kernel_asm("ldd",ptr) #define LDD_USER(ptr) __get_user_asm("ldd",ptr) @@ -213,41 +213,33 @@ : "=r"(__pu_err) \ : "r"(ptr), "r"(x), "0"(__pu_err)) -static inline void __put_kernel_asm64(u64 x, void *ptr) -{ - u32 hi = x>>32; - u32 lo = x&0xffffffff; - __asm__ __volatile__ ( - "\n1:\tstw %1,0(%0)\n" - "\n2:\tstw %2,4(%0)\n" - "3:\n" - "\t.section __ex_table,\"a\"\n" - "\t.word\t1b\n" - "\t.word\t(3b-1b)+1\n" - "\t.word\t2b\n" - "\t.word\t(3b-2b)+1\n" - "\t.previous" - : : "r"(ptr), "r"(hi), "r"(lo)); - -} - -static inline void __put_user_asm64(u64 x, void *ptr) -{ - u32 hi = x>>32; - u32 lo = x&0xffffffff; - __asm__ __volatile__ ( - "\n1:\tstw %1,0(%%sr3,%0)\n" - "\n2:\tstw %2,4(%%sr3,%0)\n" - "3:\n" - "\t.section __ex_table,\"a\"\n" - "\t.word\t1b\n" - "\t.word\t(3b-1b)+1\n" - "\t.word\t2b\n" - "\t.word\t(3b-2b)+1\n" - "\t.previous" - : : "r"(ptr), "r"(hi), "r"(lo)); +#define __put_kernel_asm64(x, ptr) \ + __asm__ __volatile__ ( \ + "\n1:\tstw\t%2,0(%1)\n" \ + "2:\tstw\t%R2,4(%1)\n" \ + "3:\n" \ + "\t.section __ex_table,\"a\"\n" \ + "\t.word\t1b\n" \ + "\t.word\t(3b-1b)+1\n" \ + "\t.word\t2b\n" \ + "\t.word\t(3b-2b)+1\n" \ + "\t.previous" \ + : "=r"(__pu_err) \ + : "r"(ptr), "r"(x), "0"(__pu_err)) -} +#define __put_user_asm64(x, ptr) \ + __asm__ __volatile__ ( \ + "\n1:\tstw\t%2,0(%%sr3,%1)\n" \ + "2:\tstw\t%R2,4(%%sr3,%1)\n" \ + "3:\n" \ + "\t.section __ex_table,\"a\"\n" \ + "\t.word\t1b\n" \ + "\t.word\t(3b-1b)+1\n" \ + "\t.word\t2b\n" \ + "\t.word\t(3b-2b)+1\n" \ + "\t.previous" \ + : "=r"(__pu_err) \ + : "r"(ptr), "r"(x), "0"(__pu_err)) #endif ----------><---------- Cheers, Joel PS: I also attach the patch for easy apply and here I need the cast. Matthew Wilcox wrote: > On Sun, Nov 09, 2003 at 01:50:49PM +0000, Joel Soete wrote: > >>Joel Soete wrote: >> >>>----------><---------- >>>--- uaccess.h.orig 2004-04-20 19:58:08.000000000 +0200 >>>+++ uaccess.h-t2 2004-04-20 20:10:41.000000000 +0200 >>>@@ -42,8 +42,8 @@ >>>#if BITS_PER_LONG == 32 >>>#define LDD_KERNEL(ptr) __get_kernel_bad(); >>>#define LDD_USER(ptr) __get_user_bad(); >>>-#define STD_KERNEL(x, ptr) __put_kernel_asm64((u32)x,ptr) >>>-#define STD_USER(x, ptr) __put_user_asm64((u32)x,ptr) >>>+#define STD_KERNEL(x, ptr) __put_kernel_asm64((u64)x,ptr) >>>+#define STD_USER(x, ptr) __put_user_asm64((u64)x,ptr) >>>#else >>>#define LDD_KERNEL(ptr) __get_kernel_asm("ldd",ptr) >>>#define LDD_USER(ptr) __get_user_asm("ldd",ptr) >>>----------><---------- >> >>I just test it and it seems to be a fix (among others): > > > I figured this out in Chicago airport yesterday. Grant just pointed > me to this mail after I checked in the fix deleting the cast entirely. > Thanks for testing though. > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [parisc-linux] fdisk problems 2.4 <-> 2.6 2003-11-09 18:59 ` Joel Soete @ 2003-11-10 4:45 ` Grant Grundler 2003-11-10 4:55 ` Grant Grundler ` (3 more replies) 0 siblings, 4 replies; 23+ messages in thread From: Grant Grundler @ 2003-11-10 4:45 UTC (permalink / raw) To: Joel Soete; +Cc: Matthew Wilcox, parisc-linux, Grant Grundler On Sun, Nov 09, 2003 at 06:59:48PM +0000, Joel Soete wrote: > Just for remainder here is the alignement of uaccess.h (i just finished > to test on my c110 :)): > ----------><---------- > --- uaccess.h.orig 2004-04-20 21:03:59.000000000 +0200 > +++ uaccess.h 2003-11-09 18:47:06.000000000 +0100 > @@ -42,8 +42,8 @@ > #if BITS_PER_LONG == 32 > #define LDD_KERNEL(ptr) __get_kernel_bad(); > #define LDD_USER(ptr) __get_user_bad(); > -#define STD_KERNEL(x, ptr) __put_kernel_asm64((u32)x,ptr) > -#define STD_USER(x, ptr) __put_user_asm64((u32)x,ptr) > +#define STD_KERNEL(x, ptr) __put_kernel_asm64((u64)x,ptr) > +#define STD_USER(x, ptr) __put_user_asm64((u64)x,ptr) willy just removed the (u32) cast and things seem to work for him. Do you need the (u64) cast? ... > -static inline void __put_kernel_asm64(u64 x, void *ptr) ... > +#define __put_kernel_asm64(x, ptr) \ ... Why replace the static inline with a macro? static inline provides type checking and type "coercion" when it's not exactly right. > + __asm__ __volatile__ ( \ > + "\n1:\tstw\t%2,0(%1)\n" \ > + "2:\tstw\t%R2,4(%1)\n" \ What is "%R2" intended to be? Randolph pointed out this is broken before and I was wrong to commit this chunk to the 2.4 tree (I'm working on removing it now). thanks, grant ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [parisc-linux] fdisk problems 2.4 <-> 2.6 2003-11-10 4:45 ` Grant Grundler @ 2003-11-10 4:55 ` Grant Grundler 2003-11-10 5:01 ` John David Anglin ` (2 subsequent siblings) 3 siblings, 0 replies; 23+ messages in thread From: Grant Grundler @ 2003-11-10 4:55 UTC (permalink / raw) To: Joel Soete; +Cc: parisc-linux On Sun, Nov 09, 2003 at 09:45:56PM -0700, Grant Grundler wrote: > What is "%R2" intended to be? > Randolph pointed out this is broken before and I was wrong > to commit this chunk to the 2.4 tree (I'm working on removing it now). For reference: http://lists.parisc-linux.org/pipermail/parisc-linux/2002-November/018441.html grant ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [parisc-linux] fdisk problems 2.4 <-> 2.6 2003-11-10 4:45 ` Grant Grundler 2003-11-10 4:55 ` Grant Grundler @ 2003-11-10 5:01 ` John David Anglin 2003-11-10 5:07 ` Randolph Chung 2003-11-10 9:51 ` Joel Soete 3 siblings, 0 replies; 23+ messages in thread From: John David Anglin @ 2003-11-10 5:01 UTC (permalink / raw) To: Grant Grundler; +Cc: soete.joel, willy, parisc-linux, grundler > Why replace the static inline with a macro? > static inline provides type checking and > type "coercion" when it's not exactly right. > > > + __asm__ __volatile__ ( \ > > + "\n1:\tstw\t%2,0(%1)\n" \ > > + "2:\tstw\t%R2,4(%1)\n" \ > > What is "%R2" intended to be? "%R2" should cause the second register name of a register pair to be printed. It's used for long long support on 32-bit ports. See case 'R' in the function print_operand in pa.c. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [parisc-linux] fdisk problems 2.4 <-> 2.6 2003-11-10 4:45 ` Grant Grundler 2003-11-10 4:55 ` Grant Grundler 2003-11-10 5:01 ` John David Anglin @ 2003-11-10 5:07 ` Randolph Chung 2003-11-10 5:25 ` John David Anglin 2003-11-10 18:35 ` Joel Soete 2003-11-10 9:51 ` Joel Soete 3 siblings, 2 replies; 23+ messages in thread From: Randolph Chung @ 2003-11-10 5:07 UTC (permalink / raw) To: Grant Grundler; +Cc: Joel Soete, Matthew Wilcox, parisc-linux > What is "%R2" intended to be? > Randolph pointed out this is broken before and I was wrong > to commit this chunk to the 2.4 tree (I'm working on > removing it now). Just a clarification: %R2 is not *wrong* -- it points to the right side of argument register 2 (jda explained this in an earlier thread), but I am not 100% sure %R2 will do the right thing for a 32-bit build though -- if you are running on a pa1.1 machine and the register is only 32-bit, does %R2 automatically do the right thing with 64-bit arguments? I guess it's easy enough to tell by looking at the code gcc generates... anyway, i think we should stick with the inline version of the code too.... thx randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [parisc-linux] fdisk problems 2.4 <-> 2.6 2003-11-10 5:07 ` Randolph Chung @ 2003-11-10 5:25 ` John David Anglin 2003-11-10 9:16 ` Joel Soete 2003-11-10 9:47 ` Joel Soete 2003-11-10 18:35 ` Joel Soete 1 sibling, 2 replies; 23+ messages in thread From: John David Anglin @ 2003-11-10 5:25 UTC (permalink / raw) To: tausq; +Cc: grundler, soete.joel, willy, parisc-linux > %R2 is not *wrong* -- it points to the right side of argument register > 2 (jda explained this in an earlier thread), but I am not 100% sure > %R2 will do the right thing for a 32-bit build though -- if you are > running on a pa1.1 machine and the register is only 32-bit, does %R2 > automatically do the right thing with 64-bit arguments? I guess it's > easy enough to tell by looking at the code gcc generates... 'R' simply adds 1 to the register number specified for operand 2. This is the right thing to do for a DImode value running 32-bit code. In the code that gcc generates, we use a specific set of register pairs for long doubles (see HARD_REGNO_MODE_OK). The main question that I would have is is the register created in the asm consistent with the register allocation needed for a DImode value. I think it would be if the mode/type for the input/output was specified correctly. This can be done with a cast in the asm. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [parisc-linux] fdisk problems 2.4 <-> 2.6 2003-11-10 5:25 ` John David Anglin @ 2003-11-10 9:16 ` Joel Soete 2003-11-10 9:47 ` Joel Soete 1 sibling, 0 replies; 23+ messages in thread From: Joel Soete @ 2003-11-10 9:16 UTC (permalink / raw) To: John David Anglin, tausq; +Cc: grundler, willy, parisc-linux >-- Original Message -- >To: tausq@debian.org >From: "John David Anglin" <dave@hiauly1.hia.nrc.ca> >Cc: grundler@parisc-linux.org, soete.joel@tiscali.be, > willy@debian.org, parisc-linux@lists.parisc-linux.org >Date: Mon, 10 Nov 2003 00:25:42 -0500 (EST) >Subject: Re: [parisc-linux] fdisk problems 2.4 <-> 2.6 > > >> %R2 is not *wrong* -- it points to the right side of argument register > 2 (jda explained this in an earlier thread), but I am not 100% sure > %R2 will do the right thing for a 32-bit build though -- if you are > running on a pa1.1 machine and >he register is only 32-bit, does %R2 > automatically do the right thing with 64-bit arguments? I guess it's > easy enough to tell by looking at the code gcc generates... 'R' simply adds 1 to the register number specified for operand 2. This is >the right thing to do for a DImode value running 32-bit code. In the code that gcc generates, we use a specific set of register pairs for long doubles (see HARD_REGNO_MODE_OK). The main question that I would have is is the register created in the a >m consistent with the register allocation needed for a DImode value. I think it would be if the mode/type for the input/output was specified correctly. This can be done with a cast in the asm. Dave -- J. David Anglin > dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-li >ux.org/mailman/listinfo/parisc-linux ------------------------------------------------------------------------- Tiscali ADSL: 3 mois GRATUITS! L'Internet rapide, c'est pour tout le monde. http://reg.tiscali.be/default.asp?lg=fr ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [parisc-linux] fdisk problems 2.4 <-> 2.6 2003-11-10 5:25 ` John David Anglin 2003-11-10 9:16 ` Joel Soete @ 2003-11-10 9:47 ` Joel Soete 1 sibling, 0 replies; 23+ messages in thread From: Joel Soete @ 2003-11-10 9:47 UTC (permalink / raw) To: John David Anglin, tausq; +Cc: grundler, willy, parisc-linux Dave, Thanks a lot you explain all better I while I was trying to find a sleep (too coffee even if not java :) ). Just to remaind the following of the tread that Grant mentioned before: <http://lists.parisc-linux.org/pipermail/parisc-linux/2002-November/018443.html> > I think it would be if the mode/type for the input/output was specified > correctly. This can be done with a cast in the asm. Yes, that is why I need cast in this case. That says, obviously I just had enough time to test it with success before submit it :) Finaly, for the history, before 'BLKGETSIZE64' was used in evms and xfs, I tried to write it as a macro because there was (as there are still) macro for 32bit world on a pa1.1 and also for 64bits on pa2.0 and so I would like to continue the same style :) Thanks again to all for your attention, Joel ------------------------------------------------------------------------- Tiscali ADSL: 3 mois GRATUITS! L'Internet rapide, c'est pour tout le monde. http://reg.tiscali.be/default.asp?lg=fr ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [parisc-linux] fdisk problems 2.4 <-> 2.6 2003-11-10 5:07 ` Randolph Chung 2003-11-10 5:25 ` John David Anglin @ 2003-11-10 18:35 ` Joel Soete 2003-11-11 11:21 ` Joel Soete 1 sibling, 1 reply; 23+ messages in thread From: Joel Soete @ 2003-11-10 18:35 UTC (permalink / raw) To: Randolph Chung; +Cc: Grant Grundler, Matthew Wilcox, parisc-linux Randolph Chung wrote: >>What is "%R2" intended to be? >>Randolph pointed out this is broken before and I was wrong >>to commit this chunk to the 2.4 tree (I'm working on >>removing it now). > > > Just a clarification: > > %R2 is not *wrong* -- it points to the right side of argument register > 2 (jda explained this in an earlier thread), but I am not 100% sure > %R2 will do the right thing for a 32-bit build though -- if you are > running on a pa1.1 machine and the register is only 32-bit, does %R2 > automatically do the right thing with 64-bit arguments? I guess it's > easy enough to tell by looking at the code gcc generates... > Good idea and just for curiosity (i don't want to insist to maintain some line of code which soon or later would have to be change ), I can try to find back a test case I used to prepare. (Just be patient) > anyway, i think we should stick with the inline version of the code > too.... > > thx > randolph thx also for attention, Joel ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [parisc-linux] fdisk problems 2.4 <-> 2.6 2003-11-10 18:35 ` Joel Soete @ 2003-11-11 11:21 ` Joel Soete 0 siblings, 0 replies; 23+ messages in thread From: Joel Soete @ 2003-11-11 11:21 UTC (permalink / raw) To: Joel Soete; +Cc: Randolph Chung, Grant Grundler, Matthew Wilcox, parisc-linux Joel Soete wrote: > > >> >> %R2 is not *wrong* -- it points to the right side of argument register >> 2 (jda explained this in an earlier thread), but I am not 100% sure >> %R2 will do the right thing for a 32-bit build though -- if you are >> running on a pa1.1 machine and the register is only 32-bit, does %R2 >> automatically do the right thing with 64-bit arguments? I guess it's >> easy enough to tell by looking at the code gcc generates... >> > > Good idea and just for curiosity (i don't want to insist to maintain > some line of code which soon or later would have to be change ), I can > try to find back a test case I used to prepare. (Just be patient) > So here is my test-case: ---------><--------- #include <stdlib.h> #include <stdio.h> #include <string.h> #include <errno.h> #define KERNEL_DS ((mm_segment_t){0}) #define USER_DS ((mm_segment_t){1}) #define segment_eq(a,b) ((a).seg == (b).seg) #define get_ds() (KERNEL_DS) #define get_fs() (current->addr_limit) #define set_fs(x) (current->addr_limit = (x)) #define put_user __put_user #define STD_USER(x, ptr) __put_user_asm_64(x, ptr) #define __put_user(x,ptr) \ ({ \ register long __pu_err __asm__ ("r8") = 0; \ \ switch (sizeof(*(ptr))) { \ case 1: __put_user_asm("stb",x,ptr); break; \ 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: printf("Bug"); break; \ } \ \ __pu_err; \ }) /* * The "__put_user/kernel_asm()" macros tell gcc they read from memory * instead of writing. This is because they do not write to any memory * gcc knows about, so there are no aliasing issues. */ #define __put_user_asm(stx,x,ptr) \ __asm__ __volatile__ ( \ "\n1:\t" stx "\t%2,0(%%sr3,%1)\n" \ "2:\n" \ "\t.section __ex_table,\"a\"\n" \ "\t.word\t1b\n" \ "\t.word\t(2b-1b)+1\n" \ "\t.previous" \ : "=r"(__pu_err) \ : "r"(ptr), "r"(x), "0"(__pu_err)) #define __put_user_asm_64(x, ptr) \ __asm__ __volatile__ ( \ "\n1:\tstw\t%2,0(%%sr3,%1)\n" \ "2:\tstw\t%R2,4(%%sr3,%1)\n" \ "3:\n" \ "\t.section __ex_table,\"a\"\n" \ "\t.word\t1b\n" \ "\t.word\t(3b-1b)+1\n" \ "\t.word\t2b\n" \ "\t.word\t(3b-2b)+1\n" \ "\t.previous" \ : "=r"(__pu_err) \ : "r"(ptr), "r"(x), "0"(__pu_err)) typedef unsigned long long u64; typedef u_int8_t BOOLEAN; typedef struct { unsigned char b7, b6, b5, b4, b3, b2, b1, b0; } EightBytes; int main(int argc, char * * argv, char * * env) { unsigned long long TU64; unsigned long long * PTU64=(unsigned long long *) malloc(sizeof(unsigned long long)); int err; union { unsigned long long U64; EightBytes B8; } Uu64; Uu64.U64 = 0xf7f6f5f4f3f2f1f0LL; TU64 = Uu64.U64; err = put_user(TU64, PTU64); printf("TestU64 is of len: %u\n", sizeof(Uu64.U64)); printf("Address of TestU64: %p\n", &TU64); printf("Value of Uu64.U64: %0Lx\n", Uu64.U64); printf("Value of Uu64.U64l: %0x\n", (unsigned int) Uu64.U64 ); printf("Value of Uu64.U64h: %0x\n", (unsigned int) (Uu64.U64 >> 32) ); printf("Value of Uu64.U64b0: %0x\n", (unsigned char) Uu64.B8.b0 ); printf("Address of Uu64.U64: %p\n", &(Uu64.U64)); printf("Address of Uu64.U64b7: %p\n", &(Uu64.B8.b7)); printf("Address of Uu64.U64b0: %p\n", &(Uu64.B8.b0)); printf("PTU64 is of len: %u\n", sizeof(*PTU64)); printf("Address of PTU64: %p\n", PTU64); printf("Value of PTU64: %0Lx\n", *PTU64); return err; } ---------><--------- And the generated code by gcc 3.3.2: [...] main: .PROC .CALLINFO FRAME=128,CALLS,SAVE_RP,SAVE_SP,ENTRY_GR=4 .ENTRY stw %r2,-20(%r30) copy %r3,%r1 copy %r30,%r3 stwm %r1,128(%r30) stw %r8,32(%r3) stw %r26,-36(%r3) stw %r25,-40(%r3) stw %r24,-44(%r3) ldi 8,%r26 bl malloc,%r2 nop copy %r28,%r19 stw %r19,16(%r3) ldil L'-202182160,%r20 ldil L'-134810124,%r19 ldo R'-134810124(%r19),%r19 ldo R'-202182160(%r20),%r20 stw %r19,24(%r3) stw %r20,28(%r3) ldw 24(%r3),%r19 ldw 28(%r3),%r20 stw %r19,8(%r3) stw %r20,12(%r3) ldi 0,%r8 ldw 16(%r3),%r21 ldw 8(%r3),%r19 ldw 12(%r3),%r20 #APP 1: stw %r19,0(%sr3,%r21) 2: stw %r20,4(%sr3,%r21) 3: .section __ex_table,"a" .word 1b .word (3b-1b)+1 .word 2b .word (3b-2b)+1 .previous #NO_APP stw %r8,20(%r3) ldil LR'.LC1,%r19 ldo RR'.LC1(%r19),%r26 ldi 8,%r25 bl printf,%r2 nop ldil LR'.LC2,%r19 [...] Please let me know if I miss something ;) Cheers, Joel ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [parisc-linux] fdisk problems 2.4 <-> 2.6 2003-11-10 4:45 ` Grant Grundler ` (2 preceding siblings ...) 2003-11-10 5:07 ` Randolph Chung @ 2003-11-10 9:51 ` Joel Soete 2003-11-10 16:58 ` Grant Grundler 3 siblings, 1 reply; 23+ messages in thread From: Joel Soete @ 2003-11-10 9:51 UTC (permalink / raw) To: Grant Grundler; +Cc: Matthew Wilcox, parisc-linux, Grant Grundler That is Ok for me, Do you still have the patch to revert it? Joel >-- Original Message -- >From: Grant Grundler <grundler@parisc-linux.org> >To: Joel Soete <soete.joel@tiscali.be> >Cc: Matthew Wilcox <willy@debian.org>, > parisc-linux@lists.parisc-linux.org, > Grant Grundler <grundler@parisc-linux.org> >Date: Sun, 9 Nov 2003 21:45:56 -0700 >Subject: Re: [parisc-linux] fdisk problems 2.4 <-> 2.6 > > >On Sun, Nov 09, 2003 at 06:59:48PM +0000, Joel Soete wrote: > Just for remainder here is the alignement of uaccess.h (i just finished > to test on my c110 :)): > ----------><---------- > --- uaccess.h.orig 2004-04-20 21:03:59.000000000 +0200 >> +++ uaccess.h 2003-11-09 18:47:06.000000000 +0100 > @@ -42,8 +42,8 @@ > #if BITS_PER_LONG == 32 > #define LDD_KERNEL(ptr) __get_kernel_bad(); > #define LDD_USER(ptr) __get_user_bad(); > -#define STD_KERNEL(x, ptr) __put_kernel_asm64((u32)x, >tr) > -#define STD_USER(x, ptr) __put_user_asm64((u32)x,ptr) > +#define STD_KERNEL(x, ptr) __put_kernel_asm64((u64)x,ptr) > +#define STD_USER(x, ptr) __put_user_asm64((u64)x,ptr) willy just removed the (u32) cast and things seem to work for him. >Do you need the (u64) cast? ... > -static inline void __put_kernel_asm64(u64 x, void *ptr) ... > +#define __put_kernel_asm64(x, ptr) \ ... Why replace the static inline with a macro? static inline provides type checki >g and type "coercion" when it's not exactly right. > + __asm__ __volatile__ ( \ > + "\n1:\tstw\t%2,0(%1)\n" \ > + "2:\tstw\t%R2,4(%1)\n" \ >hat is "%R2" intended to be? Randolph pointed out this is broken before and I was wrong to commit this chunk to the 2.4 tree (I'm working on removing it now). thanks, grant _______________________________________________ parisc-linux mailing l >st parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ------------------------------------------------------------------------- Tiscali ADSL: 3 mois GRATUITS! L'Internet rapide, c'est pour tout le monde. http://reg.tiscali.be/default.asp?lg=fr ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [parisc-linux] fdisk problems 2.4 <-> 2.6 2003-11-10 9:51 ` Joel Soete @ 2003-11-10 16:58 ` Grant Grundler 0 siblings, 0 replies; 23+ messages in thread From: Grant Grundler @ 2003-11-10 16:58 UTC (permalink / raw) To: Joel Soete; +Cc: Grant Grundler, Matthew Wilcox, parisc-linux On Mon, Nov 10, 2003 at 10:51:32AM +0100, Joel Soete wrote: > That is Ok for me, Do you still have the patch to revert it? yes - I'll test/commmit that this morning. thanks, grant ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [parisc-linux] fdisk problems 2.4 <-> 2.6 2003-11-06 22:29 ` Matthew Wilcox 2003-11-07 17:52 ` Joel Soete @ 2003-11-07 20:32 ` Ruediger Scholz 1 sibling, 0 replies; 23+ messages in thread From: Ruediger Scholz @ 2003-11-07 20:32 UTC (permalink / raw) To: Matthew Wilcox; +Cc: parisc-linux [-- Attachment #1: Type: text/plain, Size: 310 bytes --] Matthew Wilcox schrieb: >So we've lost the top 32 bits of the value. Can you run it under strace >and tell me what ioctls fdisk is calling? I bet it's calling BLKGETSIZE64 >and our put_user() is broken. > Yes, it's calling BLKGETSIZE64... Full Output of 'strace fdisk' is attached. Greetings, Ruediger [-- Attachment #2: fdisk-2.6.log --] [-- Type: text/plain, Size: 6401 bytes --] gandalf:~# strace fdisk /dev/sdb execve("/sbin/fdisk", ["fdisk", "/dev/sdb"], [/* 14 vars */]) = 0 newuname({sys="Linux", node="gandalf", ...}) = 0 brk(0) = 0x3a000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40018000 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=0, st_size=0, ...}) = 0 mmap(NULL, 35026, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40019000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\17\0\0\0\1\0\1\365"..., 512) = 512 fstat64(3, {st_mode=0, st_size=0, ...}) = 0 mmap(NULL, 1446800, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40029000 mprotect(0x40172000, 99216, PROT_NONE) = 0 mmap(0x40181000, 32768, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0x148000) = 0x40181000 mmap(0x40189000, 5008, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40189000 close(3) = 0 munmap(0x40019000, 35026) = 0 open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=0, st_size=0, ...}) = 0 mmap2(NULL, 1860304, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4018b000 close(3) = 0 brk(0) = 0x3a000 brk(0x5b000) = 0x5b000 brk(0) = 0x5b000 open("/dev/sdb", O_RDWR|O_LARGEFILE) = 3 read(3, "\200\0PALO\0\3\0\4\200\0\0)\323\375\0\0\0\0\0\0\0\0002"..., 512) = 512 newuname({sys="Linux", node="gandalf", ...}) = 0 ioctl(3, BLKSSZGET, 0xfaf004c8) = 0 fstat64(3, {st_mode=0, st_size=6, ...}) = 0 ioctl(3, 0x301, 0xfaf004c8) = 0 ioctl(3, BLKGETSIZE64, 0xfaf00530) = 0 _llseek(3, 0, [0], SEEK_SET) = 0 read(3, "\200\0PALO\0\3\0\4\200\0\0)\323\375\0\0\0\0\0\0\0\0002"..., 8192) = 8192 fstat64(1, {st_mode=0, st_size=5, ...}) = 0 ioctl(1, 0x40245410, {B9600 opost isig icanon echo ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40019000 write(1, "\n", 1 ) = 1 open("/usr/share/locale/locale.alias", O_RDONLY) = 4 fstat64(4, {st_mode=0, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001a000 read(4, "# Locale name alias data base.\n#"..., 4096) = 2539 read(4, "", 4096) = 0 close(4) = 0 munmap(0x4001a000, 4096) = 0 open("/usr/share/locale/de_DE@euro/LC_MESSAGES/util-linux.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/de@euro/LC_MESSAGES/util-linux.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/de_DE/LC_MESSAGES/util-linux.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/de/LC_MESSAGES/util-linux.mo", O_RDONLY) = 4 fstat64(4, {st_mode=0, st_size=0, ...}) = 0 mmap(NULL, 163630, PROT_READ, MAP_PRIVATE, 4, 0) = 0x40352000 close(4) = 0 open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/gconv/gconv-modules", O_RDONLY) = 4 fstat64(4, {st_mode=0, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001a000 read(4, "# GNU libc iconv configuration.\n"..., 4096) = 4096 read(4, ".B1.002//\nalias\tJS//\t\t\tJUS_I.B1."..., 4096) = 4096 read(4, "859-3\t1\nmodule\tINTERNAL\t\tISO-885"..., 4096) = 4096 read(4, "9-14//\nalias\tLATIN8//\t\tISO-8859-"..., 4096) = 4096 read(4, "CSEBCDICES//\t\tEBCDIC-ES//\nalias\t"..., 4096) = 4096 read(4, "IBM284//\nalias\tEBCDIC-CP-ES//\t\tI"..., 4096) = 4096 read(4, "ias\t864//\t\t\tIBM864//\nalias\tCSIBM"..., 4096) = 4096 read(4, "\tIBM937\t\t1\nmodule\tINTERNAL\t\tIBM9"..., 4096) = 4096 read(4, "UC-JP//\nmodule\tEUC-JP//\t\tINTERNA"..., 4096) = 4096 read(4, "143IECP271//\tIEC_P27-1//\nalias\tI"..., 4096) = 4096 read(4, "\nmodule\tINTERNAL\t\tISO_10367-BOX/"..., 4096) = 4096 read(4, "\t\tto\t\t\tmodule\t\tcost\nmodule\tShift"..., 4096) = 222 read(4, "", 4096) = 0 close(4) = 0 munmap(0x4001a000, 4096) = 0 open("/usr/lib/gconv/ISO8859-15.so", O_RDONLY) = 4 read(4, "\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\17\0\0\0\1\0\0\7"..., 512) = 512 fstat64(4, {st_mode=0, st_size=0, ...}) = 0 mmap(NULL, 73040, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0x4037a000 mprotect(0x4037c000, 64848, PROT_NONE) = 0 mmap(0x4038b000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0x1000) = 0x4038b000 close(4) = 0 write(1, "Befehl (m f\374r Hilfe): ", 22Befehl (m für Hilfe): ) = 22 fstat64(0, {st_mode=0, st_size=5, ...}) = 0 ioctl(0, 0x40245410, {B9600 opost isig icanon echo ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001a000 read(0, p "p\n", 4096) = 2 write(1, "\n", 1 ) = 1 write(1, "Platte /dev/sdb: 40 MByte, 40239"..., 41Platte /dev/sdb: 40 MByte, 40239104 Byte ) = 41 write(1, "134 K\366pfe, 62 Sektoren/Spuren, 9"..., 42134 Köpfe, 62 Sektoren/Spuren, 9 Zylinder ) = 42 write(1, "Einheiten = Zylinder von 8308 * "..., 53Einheiten = Zylinder von 8308 * 512 = 4253696 Bytes ) = 53 write(1, " Ger\344t Boot Start "..., 63 Gerät Boot Start End Blocks Id System ) = 63 write(1, "/dev/sdb1 * 1 "..., 75/dev/sdb1 * 1 8 33201 f0 Linux/PA-RISC boot ) = 75 write(1, "/dev/sdb2 9 "..., 62/dev/sdb2 9 23 62310 83 Linux ) = 62 write(1, "/dev/sdb3 24 "..., 67/dev/sdb3 24 83 249240 82 Linux Swap ) = 67 write(1, "/dev/sdb4 84 "..., 66/dev/sdb4 84 1019 3888144 8e Linux LVM ) = 66 write(1, "\n", 1 ) = 1 write(1, "Befehl (m f\374r Hilfe): ", 22Befehl (m für Hilfe): ) = 22 read(0, q "q\n", 4096) = 2 close(3) = 0 write(1, "\n", 1 ) = 1 munmap(0x40019000, 4096) = 0 exit(0) = ? gandalf:~# ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [parisc-linux] fdisk problems 2.4 <-> 2.6 2003-11-05 20:21 [parisc-linux] fdisk problems 2.4 <-> 2.6 Ruediger Scholz 2003-11-06 22:29 ` Matthew Wilcox @ 2003-11-10 21:58 ` Ruediger Scholz 1 sibling, 0 replies; 23+ messages in thread From: Ruediger Scholz @ 2003-11-10 21:58 UTC (permalink / raw) To: parisc-linux Thanks for all your help! Everything works fine for me now. Greetings, Ruediger ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2003-11-11 11:21 UTC | newest] Thread overview: 23+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2003-11-05 20:21 [parisc-linux] fdisk problems 2.4 <-> 2.6 Ruediger Scholz 2003-11-06 22:29 ` Matthew Wilcox 2003-11-07 17:52 ` Joel Soete 2003-11-08 1:59 ` Grant Grundler 2003-11-08 10:59 ` Joel Soete 2003-11-08 19:48 ` Grant Grundler 2003-11-08 22:15 ` Joel Soete 2003-11-09 13:50 ` Joel Soete 2003-11-09 17:57 ` Matthew Wilcox 2003-11-09 18:59 ` Joel Soete 2003-11-10 4:45 ` Grant Grundler 2003-11-10 4:55 ` Grant Grundler 2003-11-10 5:01 ` John David Anglin 2003-11-10 5:07 ` Randolph Chung 2003-11-10 5:25 ` John David Anglin 2003-11-10 9:16 ` Joel Soete 2003-11-10 9:47 ` Joel Soete 2003-11-10 18:35 ` Joel Soete 2003-11-11 11:21 ` Joel Soete 2003-11-10 9:51 ` Joel Soete 2003-11-10 16:58 ` Grant Grundler 2003-11-07 20:32 ` Ruediger Scholz 2003-11-10 21:58 ` Ruediger Scholz
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.