bugs?

bugs?

[Caroline GAUDREAU]

my cpu is 1400MHz, but why there's cpu MHz         : 598.593

caro@olymphe:~$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 9
model name      : Intel(R) Pentium(R) M processor 1400MHz
stepping        : 5
cpu MHz         : 598.593
cache size      : 1024 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov 
pat clflush dts acpi mmx fxsr sse sse2 tm pbe est tm2
bogomips        : 1186.66

Re: bugs?

[Andrew Haninger]

On 12/13/05, Caroline GAUDREAU <caroline.gaudreau.1@ens.etsmtl.ca> wrote:
=> model name      : Intel(R) Pentium(R) M processor 1400MHz
> cpu MHz         : 598.593
You're probably using a notebook. Your CPU is running slower to save
power since you're probably not doing anything CPU-intensive.

Open a terminal and do 'cat /dev/urandom > /dev/null' and then look at
your CPU speed. You should find that it will climb to 1400 MHz.

HTH.

-Andy

Re: bugs?

[Dmitry Torokhov]

On Tuesday 13 December 2005 20:47, Caroline GAUDREAU wrote:
> my cpu is 1400MHz, but why there's cpu MHz         : 598.593
>

Do you have cpufreq active?

[root@core ~]# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 11
model name      : Intel(R) Pentium(R) III Mobile CPU      1000MHz
stepping        : 1
cpu MHz         : 730.646

-- 
Dmitry

Re: bugs?

[Coywolf Qi Hunt]

2005/12/14, Dmitry Torokhov <dtor_core@ameritech.net>:
> On Tuesday 13 December 2005 20:47, Caroline GAUDREAU wrote:
> > my cpu is 1400MHz, but why there's cpu MHz         : 598.593
> >
>
> Do you have cpufreq active?

Caro, do a "$ grep -i cpufreq /boot/config".

>
> [root@core ~]# cat /proc/cpuinfo
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 11
> model name      : Intel(R) Pentium(R) III Mobile CPU      1000MHz
> stepping        : 1
> cpu MHz         : 730.646
>
> --
> Dmitry
>


--
Coywolf Qi Hunt
http://sosdg.org/~coywolf/

Re: bugs?

[Dave Jones]

On Tue, Dec 13, 2005 at 08:47:58PM -0500, Caroline GAUDREAU wrote:
 > my cpu is 1400MHz, but why there's cpu MHz         : 598.593

 > flags           : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov 
 > pat clflush dts acpi mmx fxsr sse sse2 tm pbe est tm2
                                                 ^^^

Your CPU is speedstep capable.  Most modern distros include a daemon
for adjusting CPU speed based upon load.

		Dave

Re: bugs?

[Coywolf Qi Hunt]

2005/12/14, Dave Jones <davej@redhat.com>:
> On Tue, Dec 13, 2005 at 08:47:58PM -0500, Caroline GAUDREAU wrote:
>  > my cpu is 1400MHz, but why there's cpu MHz         : 598.593
>
>  > flags           : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov
>  > pat clflush dts acpi mmx fxsr sse sse2 tm pbe est tm2
>                                                  ^^^
>
> Your CPU is speedstep capable.  Most modern distros include a daemon
> for adjusting CPU speed based upon load.

what daemon? suppose in debian or redhat.
--
Coywolf Qi Hunt
http://sosdg.org/~coywolf/

Re: bugs?

[Dave Jones]

On Wed, Dec 14, 2005 at 11:03:36AM +0800, Coywolf Qi Hunt wrote:
 > 2005/12/14, Dave Jones <davej@redhat.com>:
 > > On Tue, Dec 13, 2005 at 08:47:58PM -0500, Caroline GAUDREAU wrote:
 > >  > my cpu is 1400MHz, but why there's cpu MHz         : 598.593
 > >
 > >  > flags           : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov
 > >  > pat clflush dts acpi mmx fxsr sse sse2 tm pbe est tm2
 > >                                                  ^^^
 > >
 > > Your CPU is speedstep capable.  Most modern distros include a daemon
 > > for adjusting CPU speed based upon load.
 > 
 > what daemon? suppose in debian or redhat.

'cpuspeed' in Fedora/RHEL.  Debian probably offers a dozen different
ones most of which I've never heard of :)

		Dave

Re: bugs?

[Willy Tarreau]

On Tue, Dec 13, 2005 at 08:47:58PM -0500, Caroline GAUDREAU wrote:
> my cpu is 1400MHz, but why there's cpu MHz         : 598.593
> 
> caro@olymphe:~$ cat /proc/cpuinfo
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 9
> model name      : Intel(R) Pentium(R) M processor 1400MHz
> stepping        : 5
> cpu MHz         : 598.593
> cache size      : 1024 KB
> fdiv_bug        : no
> hlt_bug         : no
> f00f_bug        : no
> coma_bug        : no
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 2
> wp              : yes
> flags           : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov 
> pat clflush dts acpi mmx fxsr sse sse2 tm pbe est tm2
> bogomips        : 1186.66

It's probably a notebook that you started unplugged from the mains power.
Mine is stupid enough to believe that I *want* to save power if I plug
the mains *after* powering it up ! And there's no way to force it to
switch from 600 to nominal freq afterwards ! So I have to connect it to
the mains first.

Regards,
Willy

Re: bugs?

[Coywolf Qi Hunt]

2005/12/14, Willy Tarreau <willy@w.ods.org>:
> On Tue, Dec 13, 2005 at 08:47:58PM -0500, Caroline GAUDREAU wrote:
> > my cpu is 1400MHz, but why there's cpu MHz         : 598.593
> >
> > caro@olymphe:~$ cat /proc/cpuinfo
> > processor       : 0
> > vendor_id       : GenuineIntel
> > cpu family      : 6
> > model           : 9
> > model name      : Intel(R) Pentium(R) M processor 1400MHz
> > stepping        : 5
> > cpu MHz         : 598.593
> > cache size      : 1024 KB
> > fdiv_bug        : no
> > hlt_bug         : no
> > f00f_bug        : no
> > coma_bug        : no
> > fpu             : yes
> > fpu_exception   : yes
> > cpuid level     : 2
> > wp              : yes
> > flags           : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov
> > pat clflush dts acpi mmx fxsr sse sse2 tm pbe est tm2
> > bogomips        : 1186.66
>
> It's probably a notebook that you started unplugged from the mains power.
> Mine is stupid enough to believe that I *want* to save power if I plug
> the mains *after* powering it up ! And there's no way to force it to
> switch from 600 to nominal freq afterwards ! So I have to connect it to

Isn't there a daemon to do that?

> the mains first.

--
Coywolf Qi Hunt
http://sosdg.org/~coywolf/

Re: bugs?

[Sander]

Willy Tarreau wrote (ao):
> On Tue, Dec 13, 2005 at 08:47:58PM -0500, Caroline GAUDREAU wrote:
> > my cpu is 1400MHz, but why there's cpu MHz         : 598.593
> > 
> > caro@olymphe:~$ cat /proc/cpuinfo
> > processor       : 0
> > vendor_id       : GenuineIntel
> > cpu family      : 6
> > model           : 9
> > model name      : Intel(R) Pentium(R) M processor 1400MHz
> > stepping        : 5
> > cpu MHz         : 598.593
> > cache size      : 1024 KB
> 
> It's probably a notebook that you started unplugged from the mains
> power. Mine is stupid enough to believe that I *want* to save power if
> I plug the mains *after* powering it up ! And there's no way to force
> it to switch from 600 to nominal freq afterwards ! So I have to
> connect it to the mains first.

If you say this based on 'cat /proc/cpuinfo' output: isn't it true that
/proc/cpuinfo is static, and doesn't necessarily reflect the actual
speed of the processor?

-- 
Humilis IT Services and Solutions
http://www.humilis.net

Re: bugs?

[Arjan van de Ven]

> If you say this based on 'cat /proc/cpuinfo' output: isn't it true that
> /proc/cpuinfo is static, and doesn't necessarily reflect the actual
> speed of the processor?

no that's not true.

Re: bugs?

[Dirk Henning Gerdes]

Hallo!

You could try:
  
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor 

It's possible that you have chosen "power_save".
You can see possible settings in 

sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors

Try "performance"!
Then you should get your 1,4 GHz.
But be aware, that this is not powersaving!
Maybe you can play around with it.
A good possibility is to install an userspace application for governing
the cpu-speed lik cpufreqd



Dirk


Am Mittwoch, den 14.12.2005, 11:57 +0100 schrieb Sander:
> Willy Tarreau wrote (ao):
> > On Tue, Dec 13, 2005 at 08:47:58PM -0500, Caroline GAUDREAU wrote:
> > > my cpu is 1400MHz, but why there's cpu MHz         : 598.593
> > > 
> > > caro@olymphe:~$ cat /proc/cpuinfo
> > > processor       : 0
> > > vendor_id       : GenuineIntel
> > > cpu family      : 6
> > > model           : 9
> > > model name      : Intel(R) Pentium(R) M processor 1400MHz
> > > stepping        : 5
> > > cpu MHz         : 598.593
> > > cache size      : 1024 KB
> > 
> > It's probably a notebook that you started unplugged from the mains
> > power. Mine is stupid enough to believe that I *want* to save power if
> > I plug the mains *after* powering it up ! And there's no way to force
> > it to switch from 600 to nominal freq afterwards ! So I have to
> > connect it to the mains first.
> 
> If you say this based on 'cat /proc/cpuinfo' output: isn't it true that
> /proc/cpuinfo is static, and doesn't necessarily reflect the actual
> speed of the processor?
> 
-- 
Dirk Henning Gerdes
Bönnersdyk 47
47803 Krefeld

Tel:  02151-755745
      0174-7776640
Mail: mail@dirk-gerdes.de

bugs!

[Lucas Correia Villa Real]

Hi!

I'm almost finished with my driver for the monochromatic ST7565 LCD, but I'm 
dealing with a bug that I could't solve by the entire day.

It was designed to be run as a module, and it's living together with another 
display that already owns the console devices. So, when I load st7565's 
module, it just skips take_over_console() code in fbmem.c and starts to 
accept write()'s on it.

By the way, I got some demo applications from MicroWindows (microwindows.org) 
that starts to get more information from the driver. It looks like when they 
request st7565_set_cmap(), some invalid pointer is accessed and the driver 
just dies:

Unhandled fault: external abort on non-linefetch (0x00a) at 0x4001a004
pgd = c3d78000
*pgd = 0bcaf001, *pmd = 0bcaf001, *pte = c4a5e0b3, *ppte = c4a5eff2

I've looked at other drivers' routines, such as hgafb, and it really looks to 
be everything on the right place. I got the impression that this error could 
be happening due to the fact that my driver didn't get the console's 
ownership, so I've disabled the other driver and compiled st7565 built-in, 
but then the driver dies with the same message at take_over_console().

Does anyone know if hgafb is a working driver that I could rely on? Also I got 
confused by the need to use or not a color pallete -- probably I don't need, 
as I'm working only with black/white, but at this time I'm no more sure about 
anything at all :-)

I'm also confused about the "setcolreg()" function passed to fb_get_cmap(). 
What should it do? What's the meaning of its 1st parameter, "regno"?

If someone could take a time to give a quick look on my set_cmap() routine, 
I've uploaded the code here:

http://cscience.org/~lucasvr/etc/st7565.c

Thanks in advance, any help will be very appreciated!
Lucas


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: bugs!

[Lucas Correia Villa Real]

Hi again,

I've fixed the non-linefetch error: I was passing the virtual framebuffer 
address into fix.smem_start instead of the physical one. Things got weird 
then when fb_writeb() tryied to write on that address ;-)

Cheers,
Lucas


On Friday 14 May 2004 01:30, Lucas Correia Villa Real wrote:
> Hi!
>
> I'm almost finished with my driver for the monochromatic ST7565 LCD, but
> I'm dealing with a bug that I could't solve by the entire day.
>
> It was designed to be run as a module, and it's living together with
> another display that already owns the console devices. So, when I load
> st7565's module, it just skips take_over_console() code in fbmem.c and
> starts to accept write()'s on it.
>
> By the way, I got some demo applications from MicroWindows
> (microwindows.org) that starts to get more information from the driver. It
> looks like when they request st7565_set_cmap(), some invalid pointer is
> accessed and the driver just dies:
>
> Unhandled fault: external abort on non-linefetch (0x00a) at 0x4001a004
> pgd = c3d78000
> *pgd = 0bcaf001, *pmd = 0bcaf001, *pte = c4a5e0b3, *ppte = c4a5eff2
>
> I've looked at other drivers' routines, such as hgafb, and it really looks
> to be everything on the right place. I got the impression that this error
> could be happening due to the fact that my driver didn't get the console's
> ownership, so I've disabled the other driver and compiled st7565 built-in,
> but then the driver dies with the same message at take_over_console().
>
> Does anyone know if hgafb is a working driver that I could rely on? Also I
> got confused by the need to use or not a color pallete -- probably I don't
> need, as I'm working only with black/white, but at this time I'm no more
> sure about anything at all :-)
>
> I'm also confused about the "setcolreg()" function passed to fb_get_cmap().
> What should it do? What's the meaning of its 1st parameter, "regno"?
>
> If someone could take a time to give a quick look on my set_cmap() routine,
> I've uploaded the code here:
>
> http://cscience.org/~lucasvr/etc/st7565.c
>
> Thanks in advance, any help will be very appreciated!
> Lucas
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: SourceForge.net Broadband
> Sign-up now for SourceForge Broadband and get the fastest
> 6.0/768 connection for only $19.95/mo for the first 3 months!
> http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: bugs!

[Lucas Correia Villa Real]

Ops, it's the opposite :-)

Lucas


On Friday 14 May 2004 20:14, Lucas Correia Villa Real wrote:
> Hi again,
>
> I've fixed the non-linefetch error: I was passing the virtual framebuffer
> address into fix.smem_start instead of the physical one. Things got weird
> then when fb_writeb() tryied to write on that address ;-)
>
> Cheers,
> Lucas
>
> On Friday 14 May 2004 01:30, Lucas Correia Villa Real wrote:
> > Hi!
> >
> > I'm almost finished with my driver for the monochromatic ST7565 LCD, but
> > I'm dealing with a bug that I could't solve by the entire day.
> >
> > It was designed to be run as a module, and it's living together with
> > another display that already owns the console devices. So, when I load
> > st7565's module, it just skips take_over_console() code in fbmem.c and
> > starts to accept write()'s on it.
> >
> > By the way, I got some demo applications from MicroWindows
> > (microwindows.org) that starts to get more information from the driver.
> > It looks like when they request st7565_set_cmap(), some invalid pointer
> > is accessed and the driver just dies:
> >
> > Unhandled fault: external abort on non-linefetch (0x00a) at 0x4001a004
> > pgd = c3d78000
> > *pgd = 0bcaf001, *pmd = 0bcaf001, *pte = c4a5e0b3, *ppte = c4a5eff2
> >
> > I've looked at other drivers' routines, such as hgafb, and it really
> > looks to be everything on the right place. I got the impression that this
> > error could be happening due to the fact that my driver didn't get the
> > console's ownership, so I've disabled the other driver and compiled
> > st7565 built-in, but then the driver dies with the same message at
> > take_over_console().
> >
> > Does anyone know if hgafb is a working driver that I could rely on? Also
> > I got confused by the need to use or not a color pallete -- probably I
> > don't need, as I'm working only with black/white, but at this time I'm no
> > more sure about anything at all :-)
> >
> > I'm also confused about the "setcolreg()" function passed to
> > fb_get_cmap(). What should it do? What's the meaning of its 1st
> > parameter, "regno"?
> >
> > If someone could take a time to give a quick look on my set_cmap()
> > routine, I've uploaded the code here:
> >
> > http://cscience.org/~lucasvr/etc/st7565.c
> >
> > Thanks in advance, any help will be very appreciated!
> > Lucas
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: SourceForge.net Broadband
> > Sign-up now for SourceForge Broadband and get the fastest
> > 6.0/768 connection for only $19.95/mo for the first 3 months!
> > http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
> > _______________________________________________
> > Linux-fbdev-devel mailing list
> > Linux-fbdev-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: SourceForge.net Broadband
> Sign-up now for SourceForge Broadband and get the fastest
> 6.0/768 connection for only $19.95/mo for the first 3 months!
> http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: Bugs?

[William Jared Roberts]

> He shouldn't be using reiser4 for anything other than bug finding and 
> stress testing.  Given how extensively we warn people that, I assume 
> this is just a toy installation without any real data on it for the 
> purpose of seeing how fast he can crash it.....

Yes, and we all follow that counsel to the letter, I assure you ;).

If it helps to track this thing down, here's a call trace I collected from
hitting Alt+SysRq+P while I was getting the "flushing like mad" with powers of 2
during a shutdown.  Again, this is NOT an oops, so I don't know if it will be as
useful.  Also, it was copied by hand to paper first, then to this email, so
there may be a couple typos in there, sorry :(.  It also may be slightly out of
date-- this a bk pull  pretty much right after the sync to 2.6.0-test3.

EIP: 0060:[<c01fa978>] CPU:0
EIP is at reiser4_lock_page+0x8/0x20
  EFLAGS:00000206           Not tainted
EAX:0100106c   EBX:00000001   ECX:dfcb2b00   EDX:c14f7b780
ESI:c14f7b80   EDI:00000001   EBP:df8fff80   DS:007b   ES:007b
CR0:80050036   CR2:400e1c40   CR3:01611000   CR4:000006d0
Call Trace:
[<c01f7c00>] jnode_extent_write+0xd0/0x2f0
[<c01f7eae>] write_jnode_list+0x8e/0xc0
[<c01fc614>] write_fq+0x34/0x50
[<c01f4756>] flush_current_atom+0x146/0x1e0
[<c01f1d39>] commit_current_atom+0x49/0x1d0
[<c01f23c8>] try_commit_txnh+0xf8/0x130
[<c01f242d>] commit_txnh+0x2d/0xa0
[<c01f1769>] txn_end+0x39/0x40
[<c01f1ddc>] force_commit_atom_nolock+0x2c/0x50
[<c01f1ffd>] txnmgr_force_commit_all+0xad/0xc0
[<c01fff16>] writeout+0x66/0x70
[<c01fff71>] reiser4_sync_inodes+0x51/0x80
[<c016a31e>] sync_sb_inodes+0x23/0x40
[<c016a3f7>] sync_inodes_sb+0x77/0x90
[<c016a4bb>] sync_inodes+0x2b/0xa0
[<c014e883>] do_sync+0x23/0x70
[<c014e8df>] sys_sync+0xf/0x20
[<c0108e5f>] syscall_call+0x7/0xb

Let me know if any other information would help.

Re: Bugs?

[William Jared Roberts]

> kernel command-line options <-- sorry, can you point out the full command
> for this please ? Thanks.
> >

I think you can just add some combination of "rw" and/or "rootflags=0" to your
command line to do it.  You may also need to bypass the remount in your
initscripts.  I did this by using "init=/bin/sh" to boot once, then commenting
out the relelvant part of my init script, then rebooting.  You may also want to
add read-write to your lilo stanza and rerun lilo.  I also did an "rdev -R 0" on
my vmlinuz image.  Sorry, I'm not sure which of these steps are really necessary
and which just add to the confusion, but it "works" for me.

Re: Bugs?

[William Jared Roberts]

> are you meaning that remount it manually ?
> also, I know the problem will happen during startup and shutdown, sigh...
> 

No.  You can have the kernel initially mount the partition read-write.  IIRC,
you can use rdev and/or kernel command-line options to acheive this effect. 
It's just a band-aid for the real problem though, if you really need to get into
your box.

Re: Bugs?

[Hans Reiser]

William Jared Roberts wrote:

>>are you meaning that remount it manually ?
>>also, I know the problem will happen during startup and shutdown, sigh...
>>
>>    
>>
>
>No.  You can have the kernel initially mount the partition read-write.  IIRC,
>you can use rdev and/or kernel command-line options to acheive this effect. 
>It's just a band-aid for the real problem though, if you really need to get into
>your box.
>
>
>
>  
>
He shouldn't be using reiser4 for anything other than bug finding and 
stress testing.  Given how extensively we warn people that, I assume 
this is just a toy installation without any real data on it for the 
purpose of seeing how fast he can crash it.....

-- 
Hans

Re: Bugs?

[Nikita Danilov]

Hans Reiser writes:
 > William Jared Roberts wrote:
 > 
 > >>are you meaning that remount it manually ?
 > >>also, I know the problem will happen during startup and shutdown, sigh...
 > >>
 > >>    
 > >>
 > >
 > >No.  You can have the kernel initially mount the partition read-write.  IIRC,
 > >you can use rdev and/or kernel command-line options to acheive this effect. 
 > >It's just a band-aid for the real problem though, if you really need to get into
 > >your box.
 > >
 > >
 > >
 > >  
 > >
 > He shouldn't be using reiser4 for anything other than bug finding and 
 > stress testing.  Given how extensively we warn people that, I assume 

Yes, this is right. Moreover, read-only mode is yet unsupported.

 > this is just a toy installation without any real data on it for the 
 > purpose of seeing how fast he can crash it.....
 > 
 > -- 
 > Hans
 > 

Nikita.

 > 

Re: Bugs?

[William Jared Roberts]

> WARNING: Flushing like mad: (number)
>  reiser4[mount(17)]: commit_current_atom
> (fs/reiser4/txnmgr.c:1023)[nikita-3176]:
> 
> I couldn't even login to my new reiser4 linux, anyone have idea why ?
> 

Yes, I reported the same problem a couple weeks ago, but got no response.  For
me, the error occurs on startup when the initscript is remounting / from
read-only to read-write.  I was never able to "solve" the problem, but I can
kind-of work around it by commenting out the remount in my initscript and having
the kernel mount / read-write initially (using rdev).  Sadly, the same problem
manifests itself on shutdown sync, so it's never able to complete a "proper"
shutdown.

Bugs?

[Thomas Graham]

WARNING: Flushing like mad: (number)
 reiser4[mount(17)]: commit_current_atom
(fs/reiser4/txnmgr.c:1023)[nikita-3176]:

I couldn't even login to my new reiser4 linux, anyone have idea why ?


-- 
HK Celtic Orchestra leader and coordanator: Thomas Graham Lau
Phone number: 852-93239670    (24hours a day, 7days a week non-stop phone)
Web site: http://sml.dyndns.org
Email: lkthomas@sml.dyndns.org

Re: Bugs?

[Alex Zarochentsev]

On Sun, Aug 17, 2003 at 12:04:08PM +0800, Thomas Graham wrote:
> WARNING: Flushing like mad: (number)
>  reiser4[mount(17)]: commit_current_atom
> (fs/reiser4/txnmgr.c:1023)[nikita-3176]:
> 
> I couldn't even login to my new reiser4 linux,

Did it boot and pass the init scripts? 

> anyone have idea why ?

Thank you for the report. Yes, it is a bug.

Is your reiser4 partition mounted on /?  Can you describe what linux system
did you put on reiser4? 

> -- 
> HK Celtic Orchestra leader and coordanator: Thomas Graham Lau
> Phone number: 852-93239670    (24hours a day, 7days a week non-stop phone)
> Web site: http://sml.dyndns.org
> Email: lkthomas@sml.dyndns.org

-- 
Alex.

Re: Bugs?

[Thomas Graham]

> On Sun, Aug 17, 2003 at 12:04:08PM +0800, Thomas Graham wrote:
>> WARNING: Flushing like mad: (number)
>>  reiser4[mount(17)]: commit_current_atom
>> (fs/reiser4/txnmgr.c:1023)[nikita-3176]:
>>
>> I couldn't even login to my new reiser4 linux,
>
> Did it boot and pass the init scripts?
INIT: version 2.85 booting
The system is coming up. Please wait
WARNING message repeating... start from here...


>
>> anyone have idea why ?
>
> Thank you for the report. Yes, it is a bug.
>
> Is your reiser4 partition mounted on /?  Can you describe what linux
> system did you put on reiser4?

I am using CRUX ( built from scratch distro ), yep, I am using reiser4 as
root partition "/"

>
>> --
>> HK Celtic Orchestra leader and coordanator: Thomas Graham Lau
>> Phone number: 852-93239670    (24hours a day, 7days a week non-stop
>> phone) Web site: http://sml.dyndns.org
>> Email: lkthomas@sml.dyndns.org
>
> --
> Alex.