Re: reiser4 experimental patch

2006-11-10 Thread Johannes Hirte
Am Freitag, 10. November 2006 00:39 schrieb [EMAIL PROTECTED]:
 thanks for answer! :)

 so, the patch compiles fine (one warning in super_ops.c), the FS boot
 correctly, but if i execute for exemple startx, kernel panic! i compile
 reiser4 built in with debug, i will send the error (kernel panic) to the
 list tomorow because i'm now in my house, and the experinet is on my work
 computer :)

I didn't look closer on your patch, but you shouldn't get a warning in 
super_ops.c. Which compiler do you use?
Can you try the patch, I've made?
http://www.stud.tu-ilmenau.de/~johi-in/patch-reiser4-2.6.18.bz2


Re: reiser4 experimental patch

2006-11-10 Thread Guilherme Covolo
Em Sexta 10 Novembro 2006 09:44, Johannes Hirte escreveu:
 Am Freitag, 10. November 2006 00:39 schrieb [EMAIL PROTECTED]:
  thanks for answer! :)
 
  so, the patch compiles fine (one warning in super_ops.c), the FS boot
  correctly, but if i execute for exemple startx, kernel panic! i compile
  reiser4 built in with debug, i will send the error (kernel panic) to the
  list tomorow because i'm now in my house, and the experinet is on my work
  computer :)

 I didn't look closer on your patch, but you shouldn't get a warning in
 super_ops.c. Which compiler do you use?
 Can you try the patch, I've made?
 http://www.stud.tu-ilmenau.de/~johi-in/patch-reiser4-2.6.18.bz2

Hello, 

i use gcc 3.4.6 on slamd64 (www.slamd64.com), x86_64.

i will try your patch :) 

i'm on-line now on irc.oftc.net nick smyows #reiser4 and my nootebook is on 
[EMAIL PROTECTED] ... 

error from boot today..

reiser4 panicked cowaedly: reiser4[mount(1909)]: check_blocks_bitmap 
(fs/reiser4/plugin/space/bitmap.c:1268)[zam-623]: assertion failed: 
reiser4_find_next_zero_bit(bnode_working_data(bnode), end_offset, 
start_offset) = end_offset

Kernel panic - not syncing: reiser4[mount(1909)]: check_blocks_bitmap 
(fs/reiser4/plugin/space/bitmap.c:1268)[zam-623]: assertion failed: 
reiser4_find_next_zero_bit(bnode_working_data(bnode), end_offset, 
start_offset) = end_offset

... 

yesterday give some error but in /fs/reiser4/context.c line 79

i reboot the computer and works now.

i'll compare the super_ops.c :)

thaks


Re: reiser4 experimental patch

2006-11-10 Thread Guilherme Covolo
the diference between my an  Johannes Hirte's patch is:

/fs/reiser4/plugins/item/item.h

   ssize_t (*write) (struct file *, const char __user *, size_t, loff_t 
*pos);
---
   int (*write) (struct file *, const char __user *, size_t, loff_t 
*pos);
*

/fs/reiser4/super_ops.c

290c290
 static int reiser4_statfs(struct dentry *dentry, struct kstatfs *statfs)
---
 static int reiser4_statfs(struct super_block *super, struct kstatfs *statfs)
292,293d291
   struct super_block *super = dentry-d_sb;

571a570,571

 // alterado
575,576c575
 void *data,
 struct vfsmount *mnt)
---
 void *data, struct vfsmount *mnt)
582c581,582
 static struct file_system_type reiser4_fs_type = {
---
 // alterado
 struct file_system_type reiser4_fs_type = {
*

i change my super_ops.c but why you alter te int to ssize_t on item.h?

()'s

Em Sexta 10 Novembro 2006 09:57, Guilherme Covolo escreveu:
 Em Sexta 10 Novembro 2006 09:44, Johannes Hirte escreveu:
  Am Freitag, 10. November 2006 00:39 schrieb [EMAIL PROTECTED]:
   thanks for answer! :)
  
   so, the patch compiles fine (one warning in super_ops.c), the FS boot
   correctly, but if i execute for exemple startx, kernel panic! i compile
   reiser4 built in with debug, i will send the error (kernel panic) to
   the list tomorow because i'm now in my house, and the experinet is on
   my work computer :)
 
  I didn't look closer on your patch, but you shouldn't get a warning in
  super_ops.c. Which compiler do you use?
  Can you try the patch, I've made?
  http://www.stud.tu-ilmenau.de/~johi-in/patch-reiser4-2.6.18.bz2

 Hello,

 i use gcc 3.4.6 on slamd64 (www.slamd64.com), x86_64.

 i will try your patch :)

 i'm on-line now on irc.oftc.net nick smyows #reiser4 and my nootebook is on
 [EMAIL PROTECTED] ...

 error from boot today..

 reiser4 panicked cowaedly: reiser4[mount(1909)]: check_blocks_bitmap
 (fs/reiser4/plugin/space/bitmap.c:1268)[zam-623]: assertion failed:
 reiser4_find_next_zero_bit(bnode_working_data(bnode), end_offset,
 start_offset) = end_offset

 Kernel panic - not syncing: reiser4[mount(1909)]: check_blocks_bitmap
 (fs/reiser4/plugin/space/bitmap.c:1268)[zam-623]: assertion failed:
 reiser4_find_next_zero_bit(bnode_working_data(bnode), end_offset,
 start_offset) = end_offset

 ...

 yesterday give some error but in /fs/reiser4/context.c line 79

 i reboot the computer and works now.

 i'll compare the super_ops.c :)

 thaks


Re: reiser4 experimental patch

2006-11-10 Thread Valdis . Kletnieks
On Fri, 10 Nov 2006 10:59:30 -0200, Guilherme Covolo said:
 the diference between my an  Johannes Hirte's patch is:
 *
 
 /fs/reiser4/super_ops.c
 
 290c290
  static int reiser4_statfs(struct dentry *dentry, struct kstatfs *statfs)
 ---
  static int reiser4_statfs(struct super_block *super, struct kstatfs *statfs

diff -c or diff -u please.  That way, if some unrelated thing moves the lines
up or down 1 or 2, it still applies.  Also, it's easier to look at a 'diff -u'
and understand what's going on, because you get to see 3-4 lines either side
of the changed lines.

 i change my super_ops.c but why you alter te int to ssize_t on item.h?

ssize_t isn't an int on some architectures, it's a 'long'.  As a result if
you reference a 32 bit value where you should use 64, you'll certainly
end up with something unexpected (probably an oops).


pgp89gE9Ad8ly.pgp
Description: PGP signature


Re: reiser4 experimental patch

2006-11-10 Thread Guilherme Covolo
i change my patch, now is equals of the  
Johannes Hirte's patch .. only difference is my patch have the comment /* 
change */ in the source. 

run on x86_64 fine! :)

my patch and the Johannes Hirte's patch is linked in my site, 
www.youare.not.br 

thanks to all!

Em Sexta 10 Novembro 2006 12:42, [EMAIL PROTECTED] escreveu:
 On Fri, 10 Nov 2006 10:59:30 -0200, Guilherme Covolo said:
  the diference between my an  Johannes Hirte's patch is:
  *
 
  /fs/reiser4/super_ops.c
 
  290c290
   static int reiser4_statfs(struct dentry *dentry, struct kstatfs
  *statfs) ---
 
   static int reiser4_statfs(struct super_block *super, struct kstatfs
   *statfs

 diff -c or diff -u please.  That way, if some unrelated thing moves the
 lines up or down 1 or 2, it still applies.  Also, it's easier to look at a
 'diff -u' and understand what's going on, because you get to see 3-4 lines
 either side of the changed lines.

  i change my super_ops.c but why you alter te int to ssize_t on item.h?

 ssize_t isn't an int on some architectures, it's a 'long'.  As a result if
 you reference a 32 bit value where you should use 64, you'll certainly
 end up with something unexpected (probably an oops).


Re: reiser4 experimental patch

2006-11-09 Thread Valdis . Kletnieks
On Thu, 09 Nov 2006 17:23:20 -0200, Guilherme Covolo said:
 hello guys,
 
 my experimental patch need modfications on fs/reiser4/context.c
 
 i need help ;)

You'll have to give us more info than that.  What happened?

Patch reject? It didn't compile? It didn't modprobe? The resulting kernel
didn't boot? The resulting kernel oopsed? Other? 



pgpL4a0CRF33Z.pgp
Description: PGP signature


Re: reiser4 experimental patch

2006-11-09 Thread smyows
thanks for answer! :)

so, the patch compiles fine (one warning in super_ops.c), the FS boot
correctly, but if i execute for exemple startx, kernel panic! i compile
reiser4 built in with debug, i will send the error (kernel panic) to the
list tomorow because i'm now in my house, and the experinet is on my work
computer :)

i don't have much knowledge in C, kernel programer (i'm noob!), and so
sorry  my poor english :) but if the comunity works together, i beliave it
is posibile!

thank you so mutch!

 On Thu, 09 Nov 2006 17:23:20 -0200, Guilherme Covolo said:
 hello guys,

 my experimental patch need modfications on fs/reiser4/context.c

 i need help ;)

 You'll have to give us more info than that.  What happened?

 Patch reject? It didn't compile? It didn't modprobe? The resulting kernel
 didn't boot? The resulting kernel oopsed? Other?