[Qemu-devel] [RFT] qemu 0.13.0-rc3

[Qemu-devel] [RFT] qemu 0.13.0-rc3

[Anthony Liguori]

After suffering from a prolonged maintainer softlockup, I'm attempting 
to get 0.13.0 release process back on track.

I've tagged qemu-0.13.0-rc3 in git which only carries a few changes 
since 0.13.0-rc1.  Most notably, a series of updates from Kevin Wolf and 
Cam Macdonell's ivshmem device.

I think we're pretty good testing wise for the final release but I 
wanted to offer a 24-hour window for last minute fixes.  I'm only 
interested in the following:

1) Patches that are *tested* against the stable-0.13 branch that are 
already committed in master.  Please tell me explicitly that you've 
tested the patch and how you've tested it.

2) Pull requests from other maintainers with cherry-picked patches 
against stable-0.13 that have been tested.

If you don't already have something ready, it's probably not worth 
worrying about.  We can follow with 0.13.1 in a relatively short period 
of time.

So please get any requests to me before 6PM US Central time October 12th.

Post 0.13.0, as part of the 0.14 planning, we can discuss how to avoid 
future delay with releases.

Thanks!

Regards,

Anthony Liguori

[Qemu-devel] Re: [RFT] qemu 0.13.0-rc3

[Luiz Capitulino]

On Mon, 11 Oct 2010 17:15:30 -0500
Anthony Liguori <aliguori@linux.vnet.ibm.com> wrote:

> After suffering from a prolonged maintainer softlockup, I'm attempting 
> to get 0.13.0 release process back on track.
> 
> I've tagged qemu-0.13.0-rc3 in git which only carries a few changes 
> since 0.13.0-rc1.  Most notably, a series of updates from Kevin Wolf and 
> Cam Macdonell's ivshmem device.
> 
> I think we're pretty good testing wise for the final release but I 
> wanted to offer a 24-hour window for last minute fixes.  I'm only 
> interested in the following:
> 
> 1) Patches that are *tested* against the stable-0.13 branch that are 
> already committed in master.  Please tell me explicitly that you've 
> tested the patch and how you've tested it.
> 
> 2) Pull requests from other maintainers with cherry-picked patches 
> against stable-0.13 that have been tested.

I went through 0.13-rc3's log and found out a number of fixes missing,
some are quite old. Strange, I really thought they were all applied.

Maybe I confused myself when they got applied to master. Not sure.

Anyway, I've cherry-picked them in the following location:

  git://repo.or.cz/qemu/qmp-unstable.git for-stable-0.13

Please, note that there non-monitor fixes too.

Alex Williamson (1):
      savevm: Reset last block info at beginning of each save

Amit Shah (1):
      migration: Accept 'cont' only after successful incoming migration

Eduardo Habkost (1):
      disable guest-provided stats on "info balloon" command

Luiz Capitulino (3):
      QMP doc: Add 'Stability Considerations' section
      QMP: Update README file
      QMP/README: Update QMP homepage address

Marcelo Tosatti (1):
      set proper migration status on ->write error (v5)

Miguel Di Ciurcio Filho (2):
      QMP: update 'query-version' documentation
      QMP/monitor: update do_info_version() to output broken down version string

[Qemu-devel] Re: [RFT] qemu 0.13.0-rc3

[Anthony Liguori]

On 10/11/2010 06:45 PM, Luiz Capitulino wrote:
> On Mon, 11 Oct 2010 17:15:30 -0500
> Anthony Liguori<aliguori@linux.vnet.ibm.com>  wrote:
>
>    
>> After suffering from a prolonged maintainer softlockup, I'm attempting
>> to get 0.13.0 release process back on track.
>>
>> I've tagged qemu-0.13.0-rc3 in git which only carries a few changes
>> since 0.13.0-rc1.  Most notably, a series of updates from Kevin Wolf and
>> Cam Macdonell's ivshmem device.
>>
>> I think we're pretty good testing wise for the final release but I
>> wanted to offer a 24-hour window for last minute fixes.  I'm only
>> interested in the following:
>>
>> 1) Patches that are *tested* against the stable-0.13 branch that are
>> already committed in master.  Please tell me explicitly that you've
>> tested the patch and how you've tested it.
>>
>> 2) Pull requests from other maintainers with cherry-picked patches
>> against stable-0.13 that have been tested.
>>      
> I went through 0.13-rc3's log and found out a number of fixes missing,
> some are quite old. Strange, I really thought they were all applied.
>
> Maybe I confused myself when they got applied to master. Not sure.
>
> Anyway, I've cherry-picked them in the following location:
>
>    git://repo.or.cz/qemu/qmp-unstable.git for-stable-0.13
>
> Please, note that there non-monitor fixes too.
>    

Thanks, I've pulled them into stable-0.13.

Regards,

Anthony Liguori

> Alex Williamson (1):
>        savevm: Reset last block info at beginning of each save
>
> Amit Shah (1):
>        migration: Accept 'cont' only after successful incoming migration
>
> Eduardo Habkost (1):
>        disable guest-provided stats on "info balloon" command
>
> Luiz Capitulino (3):
>        QMP doc: Add 'Stability Considerations' section
>        QMP: Update README file
>        QMP/README: Update QMP homepage address
>
> Marcelo Tosatti (1):
>        set proper migration status on ->write error (v5)
>
> Miguel Di Ciurcio Filho (2):
>        QMP: update 'query-version' documentation
>        QMP/monitor: update do_info_version() to output broken down version string
>    

Re: [Qemu-devel] [RFT] qemu 0.13.0-rc3

[Rick Vernam]

I encountered two issues with 0.13.0-rc1, not sure how to tell if the patches 
have been applied?

one is this patch: http://patchwork.ozlabs.org/patch/62420/
discussed here:
http://lists.nongnu.org/archive/html/qemu-devel/2010-09/msg01114.html

the other was
http://lists.nongnu.org/archive/html/qemu-devel/2010-09/msg01165.html
which was applied to seabios, but how can I determine if the shipped seabios 
includes this particular patch?

Sorry for the noise...

On Monday 11 October 2010 17:15:30 Anthony Liguori wrote:
> After suffering from a prolonged maintainer softlockup, I'm attempting
> to get 0.13.0 release process back on track.
> 
> I've tagged qemu-0.13.0-rc3 in git which only carries a few changes
> since 0.13.0-rc1.  Most notably, a series of updates from Kevin Wolf and
> Cam Macdonell's ivshmem device.
> 
> I think we're pretty good testing wise for the final release but I
> wanted to offer a 24-hour window for last minute fixes.  I'm only
> interested in the following:
> 
> 1) Patches that are *tested* against the stable-0.13 branch that are
> already committed in master.  Please tell me explicitly that you've
> tested the patch and how you've tested it.
> 
> 2) Pull requests from other maintainers with cherry-picked patches
> against stable-0.13 that have been tested.
> 
> If you don't already have something ready, it's probably not worth
> worrying about.  We can follow with 0.13.1 in a relatively short period
> of time.
> 
> So please get any requests to me before 6PM US Central time October 12th.
> 
> Post 0.13.0, as part of the 0.14 planning, we can discuss how to avoid
> future delay with releases.
> 
> Thanks!
> 
> Regards,
> 
> Anthony Liguori

Re: [Qemu-devel] [RFT] qemu 0.13.0-rc3

[Stefan Weil]

Am 12.10.2010 00:15, schrieb Anthony Liguori:
> After suffering from a prolonged maintainer softlockup, I'm attempting 
> to get 0.13.0 release process back on track.
>
> I've tagged qemu-0.13.0-rc3 in git which only carries a few changes 
> since 0.13.0-rc1.  Most notably, a series of updates from Kevin Wolf 
> and Cam Macdonell's ivshmem device.
>
> I think we're pretty good testing wise for the final release but I 
> wanted to offer a 24-hour window for last minute fixes.  I'm only 
> interested in the following:
>
> 1) Patches that are *tested* against the stable-0.13 branch that are 
> already committed in master.  Please tell me explicitly that you've 
> tested the patch and how you've tested it.
>
> 2) Pull requests from other maintainers with cherry-picked patches 
> against stable-0.13 that have been tested.
>
> If you don't already have something ready, it's probably not worth 
> worrying about.  We can follow with 0.13.1 in a relatively short 
> period of time.
>
> So please get any requests to me before 6PM US Central time October 12th.
>
> Post 0.13.0, as part of the 0.14 planning, we can discuss how to avoid 
> future delay with releases.
>
> Thanks!
>
> Regards,
>
> Anthony Liguori
>
>

Michael's last PCI pull request ([PULL] eeepro100, virtio, net, vhost fixes)
was proposed for master and for 0.13, too.

I tested the patch 010ec6293409f10b88631c36145944b9c3277ce1
"eepro100: Add support for multiple individual addresses (multiple IA))"
and suggest to include it.

Regards,
Stefan Weil

Re: [Qemu-devel] [RFT] qemu 0.13.0-rc3

[Juergen Lock]

In article <4CB38C82.1090403@linux.vnet.ibm.com> you write:
>After suffering from a prolonged maintainer softlockup, I'm attempting 
>to get 0.13.0 release process back on track.
>
>I've tagged qemu-0.13.0-rc3 in git which only carries a few changes 
>since 0.13.0-rc1.  Most notably, a series of updates from Kevin Wolf and 
>Cam Macdonell's ivshmem device.
>
>I think we're pretty good testing wise for the final release but I 
>wanted to offer a 24-hour window for last minute fixes.  I'm only 
>interested in the following:
>
>1) Patches that are *tested* against the stable-0.13 branch that are 
>already committed in master.  Please tell me explicitly that you've 
>tested the patch and how you've tested it.
>
>[...]

First tests:

- vmmouse seems broken (or disabled?  I don't see it in `info qdm'...)

- to test arm emulation I tried booting my old zaurus images (-M terrier)
  which failed (q&d fix below), and in the process also tested -M n800
  w/o an image which failed with:

	qemu-system-arm: Duplicate ID 'null' for chardev
	Can't create serial device, empty char device

  and that I got fixed by cherry-picking this commit from master:

	6a8aabd3c132188ee8e0e82ef4aba09f782cbe96

	From: Stefan Weil <weil@mail.berlios.de>
	Date: Sun, 8 Aug 2010 14:09:26 +0200
	Subject: [PATCH] hw/omap: Fix default setup for OMAP UART devices

==========

And the zaurus patch, problem was the 2nd scoop's base address
(0x08800040) gets rounded down to start of page which causes its
io read/write callbacks to be passed addresses 0x40 higher than
the code expects:  (as witnessed by "Bad register offset" messages
and failure to attach the internal CF disk aka microdrive at least.)

Signed-off-by: Juergen Lock <nox@jelal.kn-bremen.de>

--- a/hw/zaurus.c
+++ b/hw/zaurus.c
@@ -70,6 +70,10 @@ static uint32_t scoop_readb(void *opaque
 {
     ScoopInfo *s = (ScoopInfo *) opaque;
 
+    // XXX Workaround for base address (0x08800040 in this case)
+    //     rounded down to start of page
+    addr &= 0x3f;
+
     switch (addr) {
     case SCOOP_MCR:
         return s->mcr;
@@ -104,6 +108,10 @@ static void scoop_writeb(void *opaque, t
     ScoopInfo *s = (ScoopInfo *) opaque;
     value &= 0xffff;
 
+    // XXX Workaround for base address (0x08800040 in this case)
+    //     rounded down to start of page
+    addr &= 0x3f;
+
     switch (addr) {
     case SCOOP_MCR:
         s->mcr = value;

Re: [Qemu-devel] [RFT] qemu 0.13.0-rc3

[Anthony Liguori]

On 10/12/2010 04:34 PM, Juergen Lock wrote:
> In article<4CB38C82.1090403@linux.vnet.ibm.com>  you write:
>    
>> After suffering from a prolonged maintainer softlockup, I'm attempting
>> to get 0.13.0 release process back on track.
>>
>> I've tagged qemu-0.13.0-rc3 in git which only carries a few changes
>> since 0.13.0-rc1.  Most notably, a series of updates from Kevin Wolf and
>> Cam Macdonell's ivshmem device.
>>
>> I think we're pretty good testing wise for the final release but I
>> wanted to offer a 24-hour window for last minute fixes.  I'm only
>> interested in the following:
>>
>> 1) Patches that are *tested* against the stable-0.13 branch that are
>> already committed in master.  Please tell me explicitly that you've
>> tested the patch and how you've tested it.
>>
>> [...]
>>      
> First tests:
>
> - vmmouse seems broken (or disabled?  I don't see it in `info qdm'...)
>    

I don't think vmmouse is part of qdev yet.

> - to test arm emulation I tried booting my old zaurus images (-M terrier)
>    which failed (q&d fix below), and in the process also tested -M n800
>    w/o an image which failed with:
>
> 	qemu-system-arm: Duplicate ID 'null' for chardev
> 	Can't create serial device, empty char device
>
>    and that I got fixed by cherry-picking this commit from master:
>
> 	6a8aabd3c132188ee8e0e82ef4aba09f782cbe96
>
> 	From: Stefan Weil<weil@mail.berlios.de>
> 	Date: Sun, 8 Aug 2010 14:09:26 +0200
> 	Subject: [PATCH] hw/omap: Fix default setup for OMAP UART devices
>    

Sorry, is the patch below an additional fix?  If so, please submit 
against master.

Regards,

Anthony Liguori

> ==========
>
> And the zaurus patch, problem was the 2nd scoop's base address
> (0x08800040) gets rounded down to start of page which causes its
> io read/write callbacks to be passed addresses 0x40 higher than
> the code expects:  (as witnessed by "Bad register offset" messages
> and failure to attach the internal CF disk aka microdrive at least.)
>
> Signed-off-by: Juergen Lock<nox@jelal.kn-bremen.de>
>
> --- a/hw/zaurus.c
> +++ b/hw/zaurus.c
> @@ -70,6 +70,10 @@ static uint32_t scoop_readb(void *opaque
>   {
>       ScoopInfo *s = (ScoopInfo *) opaque;
>
> +    // XXX Workaround for base address (0x08800040 in this case)
> +    //     rounded down to start of page
> +    addr&= 0x3f;
> +
>       switch (addr) {
>       case SCOOP_MCR:
>           return s->mcr;
> @@ -104,6 +108,10 @@ static void scoop_writeb(void *opaque, t
>       ScoopInfo *s = (ScoopInfo *) opaque;
>       value&= 0xffff;
>
> +    // XXX Workaround for base address (0x08800040 in this case)
> +    //     rounded down to start of page
> +    addr&= 0x3f;
> +
>       switch (addr) {
>       case SCOOP_MCR:
>           s->mcr = value;
>
>    

Re: [Qemu-devel] [RFT] qemu 0.13.0-rc3

[Juergen Lock]

On Tue, Oct 12, 2010 at 05:00:34PM -0500, Anthony Liguori wrote:
> On 10/12/2010 04:34 PM, Juergen Lock wrote:
> > In article<4CB38C82.1090403@linux.vnet.ibm.com>  you write:
> >    
> >> After suffering from a prolonged maintainer softlockup, I'm attempting
> >> to get 0.13.0 release process back on track.
> >>
> >> I've tagged qemu-0.13.0-rc3 in git which only carries a few changes
> >> since 0.13.0-rc1.  Most notably, a series of updates from Kevin Wolf and
> >> Cam Macdonell's ivshmem device.
> >>
> >> I think we're pretty good testing wise for the final release but I
> >> wanted to offer a 24-hour window for last minute fixes.  I'm only
> >> interested in the following:
> >>
> >> 1) Patches that are *tested* against the stable-0.13 branch that are
> >> already committed in master.  Please tell me explicitly that you've
> >> tested the patch and how you've tested it.
> >>
> >> [...]
> >>      
> > First tests:
> >
> > - vmmouse seems broken (or disabled?  I don't see it in `info qdm'...)
> >    
> 
> I don't think vmmouse is part of qdev yet.
> 
Ok, but it also stopped working, pointer doesn't move...

> > - to test arm emulation I tried booting my old zaurus images (-M terrier)
> >    which failed (q&d fix below), and in the process also tested -M n800
> >    w/o an image which failed with:
> >
> > 	qemu-system-arm: Duplicate ID 'null' for chardev
> > 	Can't create serial device, empty char device
> >
> >    and that I got fixed by cherry-picking this commit from master:
> >
> > 	6a8aabd3c132188ee8e0e82ef4aba09f782cbe96
> >
> > 	From: Stefan Weil<weil@mail.berlios.de>
> > 	Date: Sun, 8 Aug 2010 14:09:26 +0200
> > 	Subject: [PATCH] hw/omap: Fix default setup for OMAP UART devices
> >    
> 
> Sorry, is the patch below an additional fix?

 Yes, different and unrelated bug.

>  If so, please submit 
> against master.
> 
 Right, I shall build & test that as well - later. :)

 Thanx,
	Juergen

Re: [Qemu-devel] [RFT] qemu 0.13.0-rc3

[Amit Shah]

On (Mon) Oct 11 2010 [17:15:30], Anthony Liguori wrote:
> After suffering from a prolonged maintainer softlockup, I'm
> attempting to get 0.13.0 release process back on track.

Anthony,

can you pick up the patches in the thread:

http://www.mail-archive.com/qemu-devel@nongnu.org/msg41478.html

Patch 2/4 got applied, but 1, 3 and 4 are still unapplied to the stable
branch.

		Amit

[Qemu-devel] [PATCH] (master, stable-0.13) zaurus: workaround for io base address rounded down

[Juergen Lock]

The 2nd scoop's base address (0x08800040) now gets rounded down to
start of page which causes its io read/write callbacks to be passed
addresses 0x40 higher than the code expects:  (as witnessed by
"Bad register offset" messages and failure to attach the internal
CF disk aka microdrive at least.)

[There may be more bugs of this kind hiding in other targets, this
 was just the one I tested...]

Signed-off-by: Juergen Lock <nox@jelal.kn-bremen.de>

--- a/hw/zaurus.c
+++ b/hw/zaurus.c
@@ -70,6 +70,10 @@ static uint32_t scoop_readb(void *opaque
 {
     ScoopInfo *s = (ScoopInfo *) opaque;
 
+    // XXX Workaround for base address (0x08800040 in this case)
+    //     rounded down to start of page
+    addr &= 0x3f;
+
     switch (addr) {
     case SCOOP_MCR:
         return s->mcr;
@@ -104,6 +108,10 @@ static void scoop_writeb(void *opaque, t
     ScoopInfo *s = (ScoopInfo *) opaque;
     value &= 0xffff;
 
+    // XXX Workaround for base address (0x08800040 in this case)
+    //     rounded down to start of page
+    addr &= 0x3f;
+
     switch (addr) {
     case SCOOP_MCR:
         s->mcr = value;

Re: [Qemu-devel] [RFT] qemu 0.13.0-rc3

[Juergen Lock]

On Wed, Oct 13, 2010 at 05:28:37AM +0200, Juergen Lock wrote:
> On Tue, Oct 12, 2010 at 05:00:34PM -0500, Anthony Liguori wrote:
> > On 10/12/2010 04:34 PM, Juergen Lock wrote:
> > > In article<4CB38C82.1090403@linux.vnet.ibm.com>  you write:
> > >    
> > >> After suffering from a prolonged maintainer softlockup, I'm attempting
> > >> to get 0.13.0 release process back on track.
> > >>
> > >> I've tagged qemu-0.13.0-rc3 in git which only carries a few changes
> > >> since 0.13.0-rc1.  Most notably, a series of updates from Kevin Wolf and
> > >> Cam Macdonell's ivshmem device.
> > >>
> > >> I think we're pretty good testing wise for the final release but I
> > >> wanted to offer a 24-hour window for last minute fixes.  I'm only
> > >> interested in the following:
> > >>
> > >> 1) Patches that are *tested* against the stable-0.13 branch that are
> > >> already committed in master.  Please tell me explicitly that you've
> > >> tested the patch and how you've tested it.
> > >>
> > >> [...]
> > >>      
> > > First tests:
> > >
> > > - vmmouse seems broken (or disabled?  I don't see it in `info qdm'...)
> > >    
> > 
> > I don't think vmmouse is part of qdev yet.
> > 
> Ok, but it also stopped working, pointer doesn't move...
> 
> > > - to test arm emulation I tried booting my old zaurus images (-M terrier)
> > >    which failed (q&d fix below), and in the process also tested -M n800
> > >    w/o an image which failed with:
> > >
> > > 	qemu-system-arm: Duplicate ID 'null' for chardev
> > > 	Can't create serial device, empty char device
> > >
> > >    and that I got fixed by cherry-picking this commit from master:
> > >
> > > 	6a8aabd3c132188ee8e0e82ef4aba09f782cbe96
> > >
> > > 	From: Stefan Weil<weil@mail.berlios.de>
> > > 	Date: Sun, 8 Aug 2010 14:09:26 +0200
> > > 	Subject: [PATCH] hw/omap: Fix default setup for OMAP UART devices
> > >    
> > 
> > Sorry, is the patch below an additional fix?
> 
>  Yes, different and unrelated bug.
> 
> >  If so, please submit 
> > against master.
> > 
>  Right, I shall build & test that as well - later. :)

Done, and I can report vmmouse is broken on master too.  Or at least
it is w/ jit, didn't test kvm since this was on FreeBSD.  And I
tested sidux/aptosid isos since those enable vmmouse by default
if detected.

 Cheers,
	Juergen

Re: [Qemu-devel] [PATCH] (master, stable-0.13) zaurus: workaround for io base address rounded down

[Blue Swirl]

On Wed, Oct 13, 2010 at 7:12 PM, Juergen Lock <qemu-l@jelal.kn-bremen.de> wrote:
> The 2nd scoop's base address (0x08800040) now gets rounded down to
> start of page which causes its io read/write callbacks to be passed
> addresses 0x40 higher than the code expects:  (as witnessed by
> "Bad register offset" messages and failure to attach the internal
> CF disk aka microdrive at least.)
>
> [There may be more bugs of this kind hiding in other targets, this
>  was just the one I tested...]

The devices are passed an offset to base address. Perhaps the real
problem is that scoop_init registers too much MMIO: 0x1000, when the
real range should be only 0x28. Also the registers are in 4 byte
intervals and any access to address between the registers also
triggers a warning.

What were the messages exactly?

Re: [Qemu-devel] [PATCH] (master, stable-0.13) zaurus: workaround for io base address rounded down

[Juergen Lock]

On Wed, Oct 13, 2010 at 07:45:19PM +0000, Blue Swirl wrote:
> On Wed, Oct 13, 2010 at 7:12 PM, Juergen Lock <qemu-l@jelal.kn-bremen.de> wrote:
> > The 2nd scoop's base address (0x08800040) now gets rounded down to
> > start of page which causes its io read/write callbacks to be passed
> > addresses 0x40 higher than the code expects:  (as witnessed by
> > "Bad register offset" messages and failure to attach the internal
> > CF disk aka microdrive at least.)
> >
> > [There may be more bugs of this kind hiding in other targets, this
> >  was just the one I tested...]
> 
> The devices are passed an offset to base address. Perhaps the real
> problem is that scoop_init registers too much MMIO: 0x1000, when the
> real range should be only 0x28. Also the registers are in 4 byte
> intervals and any access to address between the registers also
> triggers a warning.
> 
Well I just tried registering only 0x28 bytes and still got the messages:

--- a/hw/zaurus.c
+++ b/hw/zaurus.c
@@ -237,7 +241,7 @@ ScoopInfo *scoop_init(PXA2xxState *cpu,
     s->in = qemu_allocate_irqs(scoop_gpio_set, s, 16);
     iomemtype = cpu_register_io_memory(scoop_readfn,
                     scoop_writefn, s);
-    cpu_register_physical_memory(target_base, 0x1000, iomemtype);
+    cpu_register_physical_memory(target_base, 0x28, iomemtype);
     register_savevm(NULL, "scoop", instance, 1, scoop_save, scoop_load, s);
 
     return s;

> What were the messages exactly?

Excerpt:

[...]
scoop_readb: Bad register offset 0x4c
scoop_writeb: Bad register offset 0x54
scoop_writeb: Bad register offset 0x5c
scoop_writeb: Bad register offset 0x54
scoop_readb: Bad register offset 0x48
scoop_writeb: Bad register offset 0x44
scoop_readb: Bad register offset 0x4c
scoop_readb: Bad register offset 0x48
scoop_readb: Bad register offset 0x4c
scoop_readb: Bad register offset 0x48
scoop_readb: Bad register offset 0x4c
scoop_readb: Bad register offset 0x48
spitz_out_switch: Green LED off.
spitz_out_switch: Green LED on.
spitz_out_switch: Green LED off.
spitz_out_switch: Green LED on.
scoop_readb: Bad register offset 0x4c
scoop_writeb: Bad register offset 0x54
scoop_writeb: Bad register offset 0x5c
scoop_writeb: Bad register offset 0x54
scoop_readb: Bad register offset 0x48
scoop_writeb: Bad register offset 0x44
spitz_out_switch: Green LED off.
spitz_out_switch: Green LED on.
spitz_out_switch: Green LED off.
spitz_out_switch: Green LED on.
scoop_readb: Bad register offset 0x4c
scoop_writeb: Bad register offset 0x54
scoop_writeb: Bad register offset 0x5c
scoop_writeb: Bad register offset 0x54
scoop_readb: Bad register offset 0x48
scoop_writeb: Bad register offset 0x44
spitz_out_switch: Green LED off.
spitz_out_switch: Green LED on.
spitz_out_switch: Green LED off.
spitz_out_switch: Green LED on.
scoop_readb: Bad register offset 0x4c
scoop_writeb: Bad register offset 0x54
scoop_writeb: Bad register offset 0x5c
scoop_writeb: Bad register offset 0x54
scoop_readb: Bad register offset 0x48
scoop_writeb: Bad register offset 0x44
spitz_out_switch: Green LED off.
spitz_out_switch: Green LED on.
spitz_out_switch: Green LED off.
spitz_out_switch: Green LED on.
scoop_readb: Bad register offset 0x4c
scoop_writeb: Bad register offset 0x54
scoop_writeb: Bad register offset 0x5c
scoop_writeb: Bad register offset 0x54
scoop_readb: Bad register offset 0x48
scoop_writeb: Bad register offset 0x44
spitz_out_switch: Green LED off.
spitz_out_switch: Green LED on.
spitz_out_switch: Green LED off.
spitz_out_switch: Green LED on.
scoop_readb: Bad register offset 0x4c
scoop_writeb: Bad register offset 0x54
scoop_writeb: Bad register offset 0x5c
scoop_writeb: Bad register offset 0x54
scoop_readb: Bad register offset 0x48
scoop_writeb: Bad register offset 0x44
spitz_out_switch: Green LED off.

 (The above patch together with the addr &= 0x3f changes works tho.)

 Thanx, :)
	Juergen