[Qemu-devel] Regression: QEMU 0.8.2 (and CVS) fails to boot a debian arm

[Qemu-devel] Regression: QEMU 0.8.2 (and CVS) fails to boot a debian arm

[Aurelien Jarno]

Hi,

I have setup a debian arm (unstable) under QEMU, until now using version 
0.8.1 and a root on NFS.

I wanted to use the new SCSI card emulation introduced in QEMU 0.8.2, 
but it fails to boot (still with root on NFS). It freeze, the last 
message being:

INIT: version 2.86 booting

There is the same problem with QEMU CVS. Note that using root=/bin/sh 
works well using root on NFS and even using the emulated SCSI drive.

I can provide some more details if needed, just ask. Or please tell me 
how to debug that.

FYI, on an Athlon 64 @2.2 GHz, qemu-system-arm is faster than my NSLU2, 
and it has a lot more ram. That rocks!

Bye,
Aurelien

-- 
   .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
  : :' :  Debian developer           | Electrical Engineer
  `. `'   aurel32@debian.org         | aurelien@aurel32.net
    `-    people.debian.org/~aurel32 | www.aurel32.net

[Qemu-devel] Re: Regression: QEMU 0.8.2 (and CVS) fails to boot a debian arm

[Aurelien Jarno]

On Wed, Sep 06, 2006 at 12:14:44PM +0200, Aurelien Jarno wrote:
> Hi,
> 
> I have setup a debian arm (unstable) under QEMU, until now using version 
> 0.8.1 and a root on NFS.
> 
> I wanted to use the new SCSI card emulation introduced in QEMU 0.8.2, 
> but it fails to boot (still with root on NFS). It freeze, the last 
> message being:
> 
> INIT: version 2.86 booting
> 
> There is the same problem with QEMU CVS. Note that using root=/bin/sh 
> works well using root on NFS and even using the emulated SCSI drive.
> 

I think I have found the problem. Actually the system is not frozen, but
just very slow. I now get while booting the kernel:
  Calibrating delay loop... 12.16 BogoMIPS (lpj=60800)
instead of
  Calibrating delay loop... 486.60 BogoMIPS (lpj=2433024)

Note that it is with the versatilepb (or versatileab) machine, the
problem is not there with the integrator one.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

Re: [Qemu-devel] Re: Regression: QEMU 0.8.2 (and CVS) fails to boot a debian arm

[Paul Brook]

> > There is the same problem with QEMU CVS. Note that using root=/bin/sh
> > works well using root on NFS and even using the emulated SCSI drive.
>
> I think I have found the problem. Actually the system is not frozen, but
> just very slow. I now get while booting the kernel:
>   Calibrating delay loop... 12.16 BogoMIPS (lpj=60800)
> instead of
>   Calibrating delay loop... 486.60 BogoMIPS (lpj=2433024)
>
> Note that it is with the versatilepb (or versatileab) machine, the
> problem is not there with the integrator one.

I've not idea what might be causing this. It works fine for me using both 
machine types.

Paul

Re: [Qemu-devel] Re: Regression: QEMU 0.8.2 (and CVS) fails to boot a debian arm

[Aurelien Jarno]

Paul Brook wrote:
>>> There is the same problem with QEMU CVS. Note that using root=/bin/sh
>>> works well using root on NFS and even using the emulated SCSI drive.
>> I think I have found the problem. Actually the system is not frozen, but
>> just very slow. I now get while booting the kernel:
>>   Calibrating delay loop... 12.16 BogoMIPS (lpj=60800)
>> instead of
>>   Calibrating delay loop... 486.60 BogoMIPS (lpj=2433024)
>>
>> Note that it is with the versatilepb (or versatileab) machine, the
>> problem is not there with the integrator one.
> 
> I've not idea what might be causing this. It works fine for me using both 
> machine types.
> 

So maybe I am doing something wrong, or I have something broken in my 
kernel. Here is the command line I used:

qemu-system-arm -M versatilepb -kernel vmlinuz -initrd initrd.gz -append 
"root=/dev/ram console=ttyAMA0" -nographic

The kernel and the initrd are available on http://temp.aurel32.net/arm . 
The initrd is actually the one from the debian-installer. To get a 
console, select "Go Back" to get a menu where you can select "Execute a 
shell".

I have compared QEMU 0.8.1, QEMU 0.8.2 and QEMU CVS, both on an i386 and 
an amd64 machines. Versions 0.8.2 and CVS are a lot slower than version 
0.8.1, even for booting the kernel.

It would be nice if somebody could do the same tests, to make sure it is 
not related to my machines.

Thanks,
Aurelien

-- 
   .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
  : :' :  Debian developer           | Electrical Engineer
  `. `'   aurel32@debian.org         | aurelien@aurel32.net
    `-    people.debian.org/~aurel32 | www.aurel32.net

Re: [Qemu-devel] Re: Regression: QEMU 0.8.2 (and CVS) fails to boot a debian arm

[Aurelien Jarno]

[-- Attachment #1: Type: text/plain, Size: 1923 bytes --]

On Thu, Sep 07, 2006 at 11:45:37AM +0200, Aurelien Jarno wrote:
> Paul Brook wrote:
> >>>There is the same problem with QEMU CVS. Note that using root=/bin/sh
> >>>works well using root on NFS and even using the emulated SCSI drive.
> >>I think I have found the problem. Actually the system is not frozen, but
> >>just very slow. I now get while booting the kernel:
> >>  Calibrating delay loop... 12.16 BogoMIPS (lpj=60800)
> >>instead of
> >>  Calibrating delay loop... 486.60 BogoMIPS (lpj=2433024)
> >>
> >>Note that it is with the versatilepb (or versatileab) machine, the
> >>problem is not there with the integrator one.
> >
> >I've not idea what might be causing this. It works fine for me using both 
> >machine types.
> >
> 
> So maybe I am doing something wrong, or I have something broken in my 
> kernel. Here is the command line I used:
> 
> qemu-system-arm -M versatilepb -kernel vmlinuz -initrd initrd.gz -append 
> "root=/dev/ram console=ttyAMA0" -nographic
> 
> The kernel and the initrd are available on http://temp.aurel32.net/arm . 
> The initrd is actually the one from the debian-installer. To get a 
> console, select "Go Back" to get a menu where you can select "Execute a 
> shell".
> 
> I have compared QEMU 0.8.1, QEMU 0.8.2 and QEMU CVS, both on an i386 and 
> an amd64 machines. Versions 0.8.2 and CVS are a lot slower than version 
> 0.8.1, even for booting the kernel.
> 
> It would be nice if somebody could do the same tests, to make sure it is 
> not related to my machines.
> 

I have been able to determine that the bug has been introduced between
20060714 and 20060715, so it is hidden somewhere in the diff attached. I
will have a closer look later.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

[-- Attachment #2: diff.gz --]
[-- Type: application/octet-stream, Size: 6421 bytes --]

Re: [Qemu-devel] Re: Regression: QEMU 0.8.2 (and CVS) fails to boot a debian arm

[Aurelien Jarno]

Aurelien Jarno a écrit :
> On Thu, Sep 07, 2006 at 11:45:37AM +0200, Aurelien Jarno wrote:
>> Paul Brook wrote:
>>>>> There is the same problem with QEMU CVS. Note that using root=/bin/sh
>>>>> works well using root on NFS and even using the emulated SCSI drive.
>>>> I think I have found the problem. Actually the system is not frozen, but
>>>> just very slow. I now get while booting the kernel:
>>>>  Calibrating delay loop... 12.16 BogoMIPS (lpj=60800)
>>>> instead of
>>>>  Calibrating delay loop... 486.60 BogoMIPS (lpj=2433024)
>>>>
>>>> Note that it is with the versatilepb (or versatileab) machine, the
>>>> problem is not there with the integrator one.
>>> I've not idea what might be causing this. It works fine for me using both 
>>> machine types.
>>>
>> So maybe I am doing something wrong, or I have something broken in my 
>> kernel. Here is the command line I used:
>>
>> qemu-system-arm -M versatilepb -kernel vmlinuz -initrd initrd.gz -append 
>> "root=/dev/ram console=ttyAMA0" -nographic
>>
>> The kernel and the initrd are available on http://temp.aurel32.net/arm . 
>> The initrd is actually the one from the debian-installer. To get a 
>> console, select "Go Back" to get a menu where you can select "Execute a 
>> shell".
>>
>> I have compared QEMU 0.8.1, QEMU 0.8.2 and QEMU CVS, both on an i386 and 
>> an amd64 machines. Versions 0.8.2 and CVS are a lot slower than version 
>> 0.8.1, even for booting the kernel.
>>
>> It would be nice if somebody could do the same tests, to make sure it is 
>> not related to my machines.
>>
> 
> I have been able to determine that the bug has been introduced between
> 20060714 and 20060715, so it is hidden somewhere in the diff attached. I
> will have a closer look later.
> 

And it seems the bug is only present on SMP (or HT) hosts.


-- 
   .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
  : :' :  Debian developer           | Electrical Engineer
  `. `'   aurel32@debian.org         | aurelien@aurel32.net
    `-    people.debian.org/~aurel32 | www.aurel32.net

Re: [Qemu-devel] Re: Regression: QEMU 0.8.2 (and CVS) fails to boot a debian arm

[Aurelien Jarno]

On Thu, Sep 07, 2006 at 07:18:52PM +0200, Aurelien Jarno wrote:
> On Thu, Sep 07, 2006 at 11:45:37AM +0200, Aurelien Jarno wrote:
> > Paul Brook wrote:
> > >>>There is the same problem with QEMU CVS. Note that using root=/bin/sh
> > >>>works well using root on NFS and even using the emulated SCSI drive.
> > >>I think I have found the problem. Actually the system is not frozen, but
> > >>just very slow. I now get while booting the kernel:
> > >>  Calibrating delay loop... 12.16 BogoMIPS (lpj=60800)
> > >>instead of
> > >>  Calibrating delay loop... 486.60 BogoMIPS (lpj=2433024)
> > >>
> > >>Note that it is with the versatilepb (or versatileab) machine, the
> > >>problem is not there with the integrator one.
> > >
> > >I've not idea what might be causing this. It works fine for me using both 
> > >machine types.
> > >
> > 
> > So maybe I am doing something wrong, or I have something broken in my 
> > kernel. Here is the command line I used:
> > 
> > qemu-system-arm -M versatilepb -kernel vmlinuz -initrd initrd.gz -append 
> > "root=/dev/ram console=ttyAMA0" -nographic
> > 
> > The kernel and the initrd are available on http://temp.aurel32.net/arm . 
> > The initrd is actually the one from the debian-installer. To get a 
> > console, select "Go Back" to get a menu where you can select "Execute a 
> > shell".
> > 
> > I have compared QEMU 0.8.1, QEMU 0.8.2 and QEMU CVS, both on an i386 and 
> > an amd64 machines. Versions 0.8.2 and CVS are a lot slower than version 
> > 0.8.1, even for booting the kernel.
> > 
> > It would be nice if somebody could do the same tests, to make sure it is 
> > not related to my machines.
> > 
> 
> I have been able to determine that the bug has been introduced between
> 20060714 and 20060715, so it is hidden somewhere in the diff attached. I
> will have a closer look later.
> 

>From the attached diff, removing this small change make QEMU working
back at normal speed:

diff -Nurd qemu-0.8.2.orig/vl.c qemu-0.8.2/vl.c
--- qemu-0.8.2.orig/vl.c	2006-07-22 19:23:34.000000000 +0200
+++ qemu-0.8.2/vl.c	2006-09-07 21:42:45.962537314 +0200
@@ -774,7 +774,7 @@
         return get_clock() / 1000000;
     default:
     case QEMU_TIMER_VIRTUAL:
-        return cpu_get_clock();
+        return cpu_get_ticks();
     }
 }

It's probably a very wrong patch. As the arm integrator target is
running correctly, my guess is that the sp804 timer call this function
too often, and the small overhead introduced by this change becomes
really important.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

[Qemu-devel] Load PL110 module driver to reserve a specified address?

[Tieu Ma Dau]

[-- Attachment #1: Type: text/plain, Size: 572 bytes --]

Hi all,
  I run ARM Linux kernel on Qemu ARM simulator. In this simulator, PL110 LCD controller is at 0xc0000000 and PL110 driver will control LCD device at this address.
  For my project, I want to add a new PL110 LCD controller at 0x1b000000, so I don't know how I can load / insmod the second PL110 module driver so that this module driver can control the second PL110 LCD controller at 0x1b000000.
  Thanks for any reply.
  Tieu
 		
---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.

[-- Attachment #2: Type: text/html, Size: 688 bytes --]

Re: [Qemu-devel] Load PL110 module driver to reserve a specified address?

[Paul Brook]

On Thursday 07 September 2006 12:12, Tieu Ma Dau wrote:
> Hi all,
>   I run ARM Linux kernel on Qemu ARM simulator. In this simulator, PL110
> LCD controller is at 0xc0000000 and PL110 driver will control LCD device at
> this address. For my project, I want to add a new PL110 LCD controller at
> 0x1b000000, so I don't know how I can load / insmod the second PL110 module
> driver so that this module driver can control the second PL110 LCD
> controller at 0x1b000000. Thanks for any reply.

This is the wrong place for this question. Ask your OS vendor.

Paul

[Qemu-devel] Re: Regression: QEMU 0.8.2 (and CVS) fails to boot a debian arm

[Martin Guy]

On Wed, Sep 06, 2006 at 12:14:44PM +0200, Aurelien Jarno wrote:
>> I have setup a debian arm (unstable) under QEMU, until now using version
>> 0.8.1 and a root on NFS.
>>
>> I wanted to use the new SCSI card emulation introduced in QEMU 0.8.2,
>> but it fails to boot (still with root on NFS). It freeze, the last
>> message being:
>>
>> INIT: version 2.86 booting
>
>I think I have found the problem. Actually the system is not frozen, but
>just very slow. I now get while booting the kernel:
>  Calibrating delay loop... 12.16 BogoMIPS (lpj=60800)
>instead of
>  Calibrating delay loop... 486.60 BogoMIPS (lpj=2433024)

I suffered the same exact symptom, except that in my case it was
caused by a kernel upgrade and fixed by using a kernel that was
2.6.16-rc3 or later while vanilla 2.6.16 gave this incredible
slowdown.
That may or may not be relevant...

     M