Atari TT (next)

Atari TT (next)

[Alan Hourihane]

Hi all,

O.k. I'm passed the unexpected interrupt problem.

Now the next problem is that the console is all corrupted because atafb
initializes and shows this...

atafb_init: start
atafb_init: initializing TT hw
atafb: screen_base 0046e000 real_screen_base 0046e000 screen_len 311296
Determined 640x480, depth 4
  virtual 640x972

Now, that screen_base is above 4MB, and I've only got 4MB STRAM.

But there's also this further up the boot log.

Ignoring memory chunk at 0x0:0x400000 before the first chunk
Fix your bootloader or use a memfile to make use of this area!

I tried a memfile, but that just produces the same message.

I've read in some old threads about stram_swap=0 helping, but I don't
see that implemented anymore.

Alan.

Re: Atari TT (next)

[Michael Schmitz]

Hi Guys,
> O.k. I'm passed the unexpected interrupt problem.
>
> Now the next problem is that the console is all corrupted because atafb
> initializes and shows this...
>
> atafb_init: start
> atafb_init: initializing TT hw
> atafb: screen_base 0046e000 real_screen_base 0046e000 screen_len 311296
> Determined 640x480, depth 4
>    virtual 640x972
>
> Now, that screen_base is above 4MB, and I've only got 4MB STRAM.
You need to reserve ST-RAM for use by late initializing drivers - 
stram_pool=512k would be a good start. Not sure this works with only 4MB 
of ST-RAM though.
> But there's also this further up the boot log.
>
> Ignoring memory chunk at 0x0:0x400000 before the first chunk
> Fix your bootloader or use a memfile to make use of this area!
>
> I tried a memfile, but that just produces the same message.
Looks like your kernel gets placed in TT-RAM (because of size?) and 
hence TT-RAM is listed as the first memory chunk. I don't think ataboot 
supports a memfile, so it remains the first chunk?

I've tried to play around with the MM init code to circumvent this in 
the past, to no avail. I think  memory chunks have to be listed in 
strict order for MM init to work. I don't think reordering the memory 
chunk list once the kernel has started will work, so implementing the 
memfile option in ataboot may be necessary.

Cheers,

   Michael

> I've read in some old threads about stram_swap=0 helping, but I don't
> see that implemented anymore.
>
> Alan.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Atari TT (next)

[Alan Hourihane]

On 07/01/12 06:47, Michael Schmitz wrote:
> Hi Guys,
>> O.k. I'm passed the unexpected interrupt problem.
>>
>> Now the next problem is that the console is all corrupted because atafb
>> initializes and shows this...
>>
>> atafb_init: start
>> atafb_init: initializing TT hw
>> atafb: screen_base 0046e000 real_screen_base 0046e000 screen_len 311296
>> Determined 640x480, depth 4
>>    virtual 640x972
>>
>> Now, that screen_base is above 4MB, and I've only got 4MB STRAM.
> You need to reserve ST-RAM for use by late initializing drivers -
> stram_pool=512k would be a good start. Not sure this works with only
> 4MB of ST-RAM though.

I saw this option and I don't understand why it even exists. ST-RAM is
being sent by the bootloader with it's start (0) and size. ST-RAM always
starts at 0. So it's perfectly detectable, so why the need for an option
to specify the ST-RAM pool size ?

>> But there's also this further up the boot log.
>>
>> Ignoring memory chunk at 0x0:0x400000 before the first chunk
>> Fix your bootloader or use a memfile to make use of this area!
>>
>> I tried a memfile, but that just produces the same message.
> Looks like your kernel gets placed in TT-RAM (because of size?) and
> hence TT-RAM is listed as the first memory chunk. I don't think
> ataboot supports a memfile, so it remains the first chunk?
>

No, because I don't use "-s" on the bootloader. That means it loads the
kernel in TTRAM.

> I've tried to play around with the MM init code to circumvent this in
> the past, to no avail. I think  memory chunks have to be listed in
> strict order for MM init to work. I don't think reordering the memory
> chunk list once the kernel has started will work, so implementing the
> memfile option in ataboot may be necessary.

I think anyone with ARanyM should be able to see this problem, by
setting their STRAM to 4MB and removing the "-s" flag from the
bootstra.tos app, to load the kernel in TTRAM.

Alan.

Re: Atari TT (next)

[Alan Hourihane]

On 07/01/12 06:47, Michael Schmitz wrote:
> Hi Guys,
>> O.k. I'm passed the unexpected interrupt problem.
>>
>> Now the next problem is that the console is all corrupted because atafb
>> initializes and shows this...
>>
>> atafb_init: start
>> atafb_init: initializing TT hw
>> atafb: screen_base 0046e000 real_screen_base 0046e000 screen_len 311296
>> Determined 640x480, depth 4
>>    virtual 640x972
>>
>> Now, that screen_base is above 4MB, and I've only got 4MB STRAM.
> You need to reserve ST-RAM for use by late initializing drivers -
> stram_pool=512k would be a good start. Not sure this works with only
> 4MB of ST-RAM though.

I saw this option and I don't understand why it even exists. ST-RAM is
being sent by the bootloader with it's start (0) and size. ST-RAM always
starts at 0. So it's perfectly detectable, so why the need for an option
to specify the ST-RAM pool size ?


>> But there's also this further up the boot log.
>>
>> Ignoring memory chunk at 0x0:0x400000 before the first chunk
>> Fix your bootloader or use a memfile to make use of this area!
>>
>> I tried a memfile, but that just produces the same message.
> Looks like your kernel gets placed in TT-RAM (because of size?) and
> hence TT-RAM is listed as the first memory chunk. I don't think
> ataboot supports a memfile, so it remains the first chunk?
>

No, because I don't use "-s" on the bootloader. That means it loads the
kernel in TTRAM.



> I've tried to play around with the MM init code to circumvent this in
> the past, to no avail. I think  memory chunks have to be listed in
> strict order for MM init to work. I don't think reordering the memory
> chunk list once the kernel has started will work, so implementing the
> memfile option in ataboot may be necessary.
>

I think anyone with ARanyM should be able to see this problem, by
setting their STRAM to 4MB and removing the "-s" flag from the
bootstra.tos app, to load the kernel in TTRAM.

Alan.

Re: Atari TT (next)

[Michael Schmitz]

Hi Alan,
>> You need to reserve ST-RAM for use by late initializing drivers -
>> stram_pool=512k would be a good start. Not sure this works with only
>> 4MB of ST-RAM though.
> I saw this option and I don't understand why it even exists. ST-RAM is
> being sent by the bootloader with it's start (0) and size. ST-RAM always
> starts at 0. So it's perfectly detectable, so why the need for an option
> to specify the ST-RAM pool size ?
The stram_pool option is just to reserve ST-RAM (DMA-capable) that would 
otherwise be used by the kernel for other purposes. Atari sets the DMA 
memory barrier to the entire memory size, which is wrong in the strict 
sense (but cannot be changed easily). Drivers like SCSI and atafb have 
to resort to a special purpose memory allocator in order to
claim DMA capable memory.

For this option to work, ST-RAM first has to be accepted by memory init 
(i.e. it has to be in the first chunk). We might have to resort to 
reserving the entire ST-RAM for the kernel's use if the kernel is not 
residing in ST-RAM (breaking the above assumption). Something similar is 
done for Amiga chip RAM - exactly how does the chip RAM situation 
differ, Geert? Is chip RAM being claimed by mem_init or is it being left 
aside?

Come to think of it - does the TT video chipset actually require screen 
memory to reside in ST-RAM? If it's fully 32 bit addressed we should not 
have any problems with TT-RAM. The problems you see might be caused by a 
fault in the TT codepath in atafb - I'm unsure this has been tested 
since the last atafb rewrite.
>
>>> But there's also this further up the boot log.
>>>
>>> Ignoring memory chunk at 0x0:0x400000 before the first chunk
>>> Fix your bootloader or use a memfile to make use of this area!
>>>
>>> I tried a memfile, but that just produces the same message.
>> Looks like your kernel gets placed in TT-RAM (because of size?) and
>> hence TT-RAM is listed as the first memory chunk. I don't think
>> ataboot supports a memfile, so it remains the first chunk?
>>
> No, because I don't use "-s" on the bootloader. That means it loads the
> kernel in TTRAM.
That's what I meant - the kernel residing in TT-RAM automatically will 
map this chunk at kernel virtual address 0x0. Something in our mem_init 
logic prevents using RAM with a lower physical address than was used by 
the first chunk. I'm quoting from memory here - Roman Zippel might know 
the exact answer to this.

Can you try to have the kernel placed in ST-RAM?

>
>
>> I've tried to play around with the MM init code to circumvent this in
>> the past, to no avail. I think  memory chunks have to be listed in
>> strict order for MM init to work. I don't think reordering the memory
>> chunk list once the kernel has started will work, so implementing the
>> memfile option in ataboot may be necessary.
>>
> I think anyone with ARanyM should be able to see this problem, by
> setting their STRAM to 4MB and removing the "-s" flag from the
> bootstra.tos app, to load the kernel in TTRAM.
You're right, this should be possible to test with ARAnyM - the behavior 
is not new though. Loading the kernel in TT-RAM has been problematic on 
the Falcon for a long time now.

Cheers,

   Michael

Re: Atari TT (next)

[Andreas Schwab]

Michael Schmitz <schmitzmic@googlemail.com> writes:

> Come to think of it - does the TT video chipset actually require screen
> memory to reside in ST-RAM?

Yes.  Only the SCSI-DMA and SCC-DMA chips can address TT-RAM.

> That's what I meant - the kernel residing in TT-RAM automatically will map
> this chunk at kernel virtual address 0x0. Something in our mem_init logic
> prevents using RAM with a lower physical address than was used by the
> first chunk. I'm quoting from memory here - Roman Zippel might know the
> exact answer to this.

If the kernel resides in TT-RAM all of ST-RAM is supposed to be used by
stram_alloc.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Atari TT (next)

[Alan Hourihane]

On 08/01/12 04:13, Michael Schmitz wrote:
> Hi Alan,
>>> You need to reserve ST-RAM for use by late initializing drivers -
>>> stram_pool=512k would be a good start. Not sure this works with only
>>> 4MB of ST-RAM though.
>> I saw this option and I don't understand why it even exists. ST-RAM is
>> being sent by the bootloader with it's start (0) and size. ST-RAM always
>> starts at 0. So it's perfectly detectable, so why the need for an option
>> to specify the ST-RAM pool size ?
> The stram_pool option is just to reserve ST-RAM (DMA-capable) that
> would otherwise be used by the kernel for other purposes. Atari sets
> the DMA memory barrier to the entire memory size, which is wrong in
> the strict sense (but cannot be changed easily). Drivers like SCSI and
> atafb have to resort to a special purpose memory allocator in order to
> claim DMA capable memory.
>
> For this option to work, ST-RAM first has to be accepted by memory
> init (i.e. it has to be in the first chunk). We might have to resort
> to reserving the entire ST-RAM for the kernel's use if the kernel is
> not residing in ST-RAM (breaking the above assumption). Something
> similar is done for Amiga chip RAM - exactly how does the chip RAM
> situation differ, Geert? Is chip RAM being claimed by mem_init or is
> it being left aside?
>
> Come to think of it - does the TT video chipset actually require
> screen memory to reside in ST-RAM? If it's fully 32 bit addressed we
> should not have any problems with TT-RAM. The problems you see might
> be caused by a fault in the TT codepath in atafb - I'm unsure this has
> been tested since the last atafb rewrite.

Looking at atafb, we always allocate FB memory from STRAM unless it's an
external video card, i.e. VME, ISA etc.

>>
>>>> But there's also this further up the boot log.
>>>>
>>>> Ignoring memory chunk at 0x0:0x400000 before the first chunk
>>>> Fix your bootloader or use a memfile to make use of this area!
>>>>
>>>> I tried a memfile, but that just produces the same message.
>>> Looks like your kernel gets placed in TT-RAM (because of size?) and
>>> hence TT-RAM is listed as the first memory chunk. I don't think
>>> ataboot supports a memfile, so it remains the first chunk?
>>>
>> No, because I don't use "-s" on the bootloader. That means it loads the
>> kernel in TTRAM.
> That's what I meant - the kernel residing in TT-RAM automatically will
> map this chunk at kernel virtual address 0x0. Something in our
> mem_init logic prevents using RAM with a lower physical address than
> was used by the first chunk. I'm quoting from memory here - Roman
> Zippel might know the exact answer to this.
>
> Can you try to have the kernel placed in ST-RAM?

No, the kernel is too big. I've only got 4MB ST-RAM. And getting more on
the TT is pretty rare as the only other option is 10MB using the onboard
2MB and an 8MB upgrade board.

>
>>
>>
>>> I've tried to play around with the MM init code to circumvent this in
>>> the past, to no avail. I think  memory chunks have to be listed in
>>> strict order for MM init to work. I don't think reordering the memory
>>> chunk list once the kernel has started will work, so implementing the
>>> memfile option in ataboot may be necessary.
>>>
>> I think anyone with ARanyM should be able to see this problem, by
>> setting their STRAM to 4MB and removing the "-s" flag from the
>> bootstra.tos app, to load the kernel in TTRAM.
> You're right, this should be possible to test with ARAnyM - the
> behavior is not new though. Loading the kernel in TT-RAM has been
> problematic on the Falcon for a long time now.

Sure, but by default Falcon's have only 4MB ST-RAM too, and yes lots of
people have 14MB of ST-RAM now, but it's not uncommon to have 4MB ST-RAM.

I'll dig in.

Alan.

Re: Atari TT (next)

[Michael Schmitz]

Hi Alan,

>> Come to think of it - does the TT video chipset actually require
>> screen memory to reside in ST-RAM? If it's fully 32 bit addressed we
>> should not have any problems with TT-RAM. The problems you see might
>> be caused by a fault in the TT codepath in atafb - I'm unsure this has
>> been tested since the last atafb rewrite.
>
> Looking at atafb, we always allocate FB memory from STRAM unless it's an
> external video card, i.e. VME, ISA etc.

That's right - but in your case ST-RAM is not being mapped at all so
it can't be used. You will get a chunk of TT-RAM assigned to atafb
(fallback in case there's no more ST-RAM), the framebuffer code will
happily draw there but the shifter cannot access it.

>> Can you try to have the kernel placed in ST-RAM?
>
> No, the kernel is too big. I've only got 4MB ST-RAM. And getting more on
> the TT is pretty rare as the only other option is 10MB using the onboard
> 2MB and an 8MB upgrade board.

You may have to pare the kernel down to the bare minimum (i.e.
modularize about everything you don't need to boot to initrd). Not
sure where the limit for this is these days.

>> You're right, this should be possible to test with ARAnyM - the
>> behavior is not new though. Loading the kernel in TT-RAM has been
>> problematic on the Falcon for a long time now.
>
> Sure, but by default Falcon's have only 4MB ST-RAM too, and yes lots of
> people have 14MB of ST-RAM now, but it's not uncommon to have 4MB ST-RAM.

I think my Falcon is the only machine kernels have been tested on in
the last few years - I've got 14MB ST-RAM so I was never affected. I
had played with getting the kernel run in TT-RAM briefly but MM is not
my strong suit so I never got anywhere.

> I'll dig in.

Much appreciated.

  Michael

Re: Atari TT (next)

[Alan Hourihane]

On 08/01/12 23:51, Michael Schmitz wrote:
> Hi Alan,
>
>>> Come to think of it - does the TT video chipset actually require
>>> screen memory to reside in ST-RAM? If it's fully 32 bit addressed we
>>> should not have any problems with TT-RAM. The problems you see might
>>> be caused by a fault in the TT codepath in atafb - I'm unsure this has
>>> been tested since the last atafb rewrite.
>> Looking at atafb, we always allocate FB memory from STRAM unless it's an
>> external video card, i.e. VME, ISA etc.
> That's right - but in your case ST-RAM is not being mapped at all so
> it can't be used. You will get a chunk of TT-RAM assigned to atafb
> (fallback in case there's no more ST-RAM), the framebuffer code will
> happily draw there but the shifter cannot access it.

I understand, but the STRAM allocator is broken. It gives out TT-RAM. It
should never do that on a TT.

>>> Can you try to have the kernel placed in ST-RAM?
>> No, the kernel is too big. I've only got 4MB ST-RAM. And getting more on
>> the TT is pretty rare as the only other option is 10MB using the onboard
>> 2MB and an 8MB upgrade board.
> You may have to pare the kernel down to the bare minimum (i.e.
> modularize about everything you don't need to boot to initrd). Not
> sure where the limit for this is these days.

Already tried that. Still too big, because we need buffers from STRAM too.

>>> You're right, this should be possible to test with ARAnyM - the
>>> behavior is not new though. Loading the kernel in TT-RAM has been
>>> problematic on the Falcon for a long time now.
>> Sure, but by default Falcon's have only 4MB ST-RAM too, and yes lots of
>> people have 14MB of ST-RAM now, but it's not uncommon to have 4MB ST-RAM.
> I think my Falcon is the only machine kernels have been tested on in
> the last few years - I've got 14MB ST-RAM so I was never affected. I
> had played with getting the kernel run in TT-RAM briefly but MM is not
> my strong suit so I never got anywhere.
>
>> I'll dig in.
> Much appreciated.
>

No probs. I'll report back when I have something.

Alan.

Re: Atari TT (next)

[Michael Schmitz]

Hi Alan,

> I understand, but the STRAM allocator is broken. It gives out TT-RAM. It
> should never do that on a TT.

The ST-RAM allocator is used by a number of drivers, some of those
could actually use TT-RAM fine. But making the allocator fail instead
of returning TT-RAM would be an option.

>> You may have to pare the kernel down to the bare minimum (i.e.
>> modularize about everything you don't need to boot to initrd). Not
>> sure where the limit for this is these days.
>
> Already tried that. Still too big, because we need buffers from STRAM too.

What buffers? Filesystem buffers should be fine in TT-RAM. atafb
buffer requirement could be reduced by using a low-res video mode
perhaps (just to get past this point initially).

Cheers,

  Michael

Re: Atari TT (next)

[Alan Hourihane]

On 09/01/12 00:05, Michael Schmitz wrote:
> Hi Alan,
>
>> I understand, but the STRAM allocator is broken. It gives out TT-RAM. It
>> should never do that on a TT.
> The ST-RAM allocator is used by a number of drivers, some of those
> could actually use TT-RAM fine. But making the allocator fail instead
> of returning TT-RAM would be an option.

Yes, adding a flag to say ONLY_STRAM would work. But the function itself
is called atari_stram_alloc()/free(). And if that goes allocating TT-RAM
there's a function name problem there. Very confusing.

>>> You may have to pare the kernel down to the bare minimum (i.e.
>>> modularize about everything you don't need to boot to initrd). Not
>>> sure where the limit for this is these days.
>> Already tried that. Still too big, because we need buffers from STRAM too.
> What buffers? Filesystem buffers should be fine in TT-RAM. atafb
> buffer requirement could be reduced by using a low-res video mode
> perhaps (just to get past this point initially).
>

I'll try again as I probably didn't try after getting past the
unexpected interrupt issue.

Alan.

Re: Atari TT (next)

[Andreas Schwab]

Michael Schmitz <schmitzmic@googlemail.com> writes:

> Hi Alan,
>
>> I understand, but the STRAM allocator is broken. It gives out TT-RAM. It
>> should never do that on a TT.
>
> The ST-RAM allocator is used by a number of drivers, some of those
> could actually use TT-RAM fine.

There is no point in calling atari_stram_alloc if you don't need ST-RAM.
Of course, all uses are because they *can't* use TT-RAM.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Atari TT (next)

[Michael Schmitz]

Andreas,

On Mon, Jan 9, 2012 at 1:23 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Michael Schmitz <schmitzmic@googlemail.com> writes:
>
>> Hi Alan,
>>
>>> I understand, but the STRAM allocator is broken. It gives out TT-RAM. It
>>> should never do that on a TT.
>>
>> The ST-RAM allocator is used by a number of drivers, some of those
>> could actually use TT-RAM fine.
>
> There is no point in calling atari_stram_alloc if you don't need ST-RAM.
> Of course, all uses are because they *can't* use TT-RAM.

I stand corrected - we should indeed make it fail by default if no
ST-RAM is available then.

Cheers,

  Michael

Re: Atari TT (next)

[Alan Hourihane]

On 09/01/12 00:05, Michael Schmitz wrote:
> What buffers? Filesystem buffers should be fine in TT-RAM. atafb
> buffer requirement could be reduced by using a low-res video mode
> perhaps (just to get past this point initially).

O.k. I've managed to cut down the kernel and boot with atafb enabled and
it works, using the stram_pool option.

Next problem is the SCSI controller.

I get......

Atari SCSI: resetting the SCSI bus... done
scsi0: options CAN_QUEUE=16 CMD_PER_LUN=8 SCAT-GAT=128 TAGGED-QUEUING=no
HOSTID=7 generic options AUTOSENSE REAL DMA SCSI-2 TAGGED QUEUING
generic release=7
scsi0 : Atari native SCSI
scsi0: aborting command
scsi 0:0:0:0: CDB: Inquiry: 12 00 00 00 24 00

NCR5380 core release=7.
NCR5380: coroutine isn't running.
scsi0: no currently connected command
scsi0: issue_queue
scsi0: disconnected_queue
scsi0: destination target 0, lun 0
        command = 18 (0x12) 00 00 00 24 00


NCR5380 core release=7.
NCR5380: coroutine isn't running.
scsi0: no currently connected command
scsi0: issue_queue
scsi0: disconnected_queue
scsi0: destination target 0, lun 0
        command = 18 (0x12) 00 00 00 24 00

scsi 0:0:0:0: Device offlined - not ready after error recovery

I'll start poking at this.

Alan.

Re: Atari TT (next)

[Alan Hourihane]

It's o.k. a nice clean coldboot and things are well again. But a problem
with my initrd I think with process "start-udev" ?

Where's the latest initrd for 3.1 kernels ?

Thanks folks..

I'm booting up the initrd right now :-)
Linux version 3.1.0-atari-00246-gbff0dc7-dirty (root@server) (gcc
version 4.5.3 (Gentoo 4.5.3-r1 p1.0, pie-0.4.5) ) #33 Mon Jan 9 01:12:42
GMT 2012
console [debug0] enabled
Atari hardware found: TT_SHIFTER ST_MFP TT_MFP TT_SCSI_DMA TT_SCSI
YM2149 PCM SCC_DMA SCC VME SCU MICROWIRE TT_CLK FDC_SPEED ACSI
OFFSET 0x0 size 0x400000
On node 0 totalpages: 1024
free_area_init_node: node 0, pgdat 00200afc, node_mem_map 00230000
  DMA zone: 9 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 1015 pages, LIFO batch:0
On node 1 totalpages: 32768
free_area_init_node: node 1, pgdat 00201480, node_mem_map 00239030
  DMA zone: 288 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 32480 pages, LIFO batch:7
initrd: 08d51a08 - 09000000
atari_stram pool: size = 524288 bytes, resource = [???
0x0035a000-0x003d9fff flags 0x0]
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0
Built 2 zonelists in Zone order, mobility grouping on.  Total pages: 33495
Kernel command line: fb=false root=/dev/ram load_ramdisk=1
stram_pool=524288 console=tty video=atafb:ttmid debug=ser2
BOOT_IMAGE=vmlinux.gz
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 128244k/128244k available (1528k kernel code, 5308k data, 92k init)
NR_IRQS:72
sys stat 0x14
vme stat 0x0
Console: colour dummy device 80x25
console [tty0] enabled
Calibrating delay loop... 7.21 BogoMIPS (lpj=36096)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
NET: Registered protocol family 16
bio: create slab <bio-0> at 0
SCSI subsystem initialized
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
Trying to unpack rootfs image as initramfs...
Freeing initrd memory: 687k freed
msgmni has been set to 255
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
io scheduler noop registered
io scheduler cfq registered (default)
atafb_init: start
atafb_init: initializing TT hw
atari_stram_alloc: allocate 311296 bytes
atari_stram_alloc: returning [??? 0x0035a000-0x003a5fff flags 0x0]
atafb: screen_base 0035a000 real_screen_base 0035a000 screen_len 311296
Determined 640x480, depth 4
   virtual 640x972
Console: switching to colour frame buffer device 80x30
fb0: frame buffer device, using 304K of video memory
Non-volatile memory driver v1.3
brd: module loaded
loop: module loaded
Atari SCSI: resetting the SCSI bus... done
scsi0: options CAN_QUEUE=16 CMD_PER_LUN=8 SCAT-GAT=128 TAGGED-QUEUING=no
HOSTID=7 generic options AUTOSENSE REAL DMA SCSI-2 TAGGED QUEUING
generic release=7
scsi0 : Atari native SCSI
scsi 0:0:0:0: Direct-Access     SEAGATE  ST34520N         1498 PQ: 0 ANSI: 2
eth0: Riebl-Card (without battery) at io 0xfe00fff0, mem 0xfe010000, irq
56, hwaddr 00:00:36:04:00:00
eth0: Warning: This is a default ethernet address!
      Use "ifconfig hw ether ..." to set the address.
atarilance.c: v1.3 04/04/96 Roman.Hodek@informatik.uni-erlangen.de
sd 0:0:0:0: [sda] 8888924 512-byte logical blocks: (4.55 GB/4.23 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 93 00 10 08
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports
DPO and FUA
mousedev: PS/2 mouse device common for all mice
WARNING: keyboard self test failed!
input: Atari Keyboard as /devices/virtual/input/input0
TCP cubic registered
NET: Registered protocol family 17
 sda: AHDI sda1 sda2 sda3 XGM< sda4 sda5 sda6 sda7 >
sd 0:0:0:0: [sda] Attached SCSI disk
*** FORMAT ERROR ***   FORMAT=0
Current process id is 768
BAD KERNEL TRAP: 00000000
Modules linked in:
PC: [<000029de>] flush_thread+0x8/0xe
SR: 2300  SP: 07de1e68  a2: 07ddc070
d0: 00000001    d1: 07ddb000    d2: 00220c50    d3: 00000001
d4: 00226e90    d5: 00000000    a0: 003f6660    a1: 00330310
Process start-udev (pid: 768, task=07ddc070)
Frame format=0
Stack from 07de1e9c:
        23000007 0007239e 00000080 00000001 0022af40 07d3b080 08836ba0
07ddf200
        80000002 07def600 000987b2 07d3b080 00000000 07de1fcc fffffff8
00000000
        00000300 efb1a71c 07d3b080 001f614c 00032b28 00043fe4 00000000
07de1f30
        00000020 00071d06 07ddc070 00220c50 efffff92 00000001 00002000
00071d2e
        07d3b104 00000002 00000008 07d3b080 00358ad8 00000003 00071e7e
08fdaf7e
        00071eb2 000716d0 00043fe4 00071710 07d3b080 07de1fcc 00000001
08835000
Call Trace: [<0007239e>] flush_old_exec+0x424/0x434
 [<000987b2>] load_elf_binary+0x22c/0xc72
 [<00032b28>] __request_module+0x0/0xfe
 [<00043fe4>] module_put+0x0/0x24
 [<00071d06>] get_arg_page+0x30/0x96
 [<00220c50>] unlzma+0x284/0xc10
 [<00002000>] _start+0x0/0x8
 [<00071d2e>] get_arg_page+0x58/0x96
 [<00071e7e>] copy_strings+0x112/0x168
 [<00071eb2>] copy_strings+0x146/0x168
 [<000716d0>] search_binary_handler+0x26/0x1be
 [<00043fe4>] module_put+0x0/0x24
 [<00071710>] search_binary_handler+0x66/0x1be
 [<00071d6c>] copy_strings+0x0/0x168
 [<00072896>] do_execve+0x14e/0x224
 [<00002b24>] sys_execve+0x32/0x54
 [<000025b8>] syscall+0x8/0xc

Code: 508f 265f 285f 4e75 598f 357c 0001 01c4 <f357> 588f 4e75 4e68 42a7
42a7 42a7 2f2f 0010 2f08 4878 0011 4eb9 0002 5382 4fef
Disabling lock debugging due to kernel taint
Kernel panic - not syncing: Attempted to kill init!
Call Trace: [<0017b77c>] panic+0x54/0x192
 [<00008b00>] bindec+0x180/0x198
 [<00027d42>] do_exit+0x72/0x52a
 [<00008b00>] bindec+0x180/0x198
 [<00028408>] do_group_exit+0x6a/0x8c
 [<00008b00>] bindec+0x180/0x198
 [<0002843e>] sys_exit_group+0x14/0x1a
 [<00008b00>] bindec+0x180/0x198
 [<000025b8>] syscall+0x8/0xc
 [<00002024>] run_init_process+0x1c/0x22
 [<0000205a>] init_post+0x30/0x9a
 [<0007873e>] sys_dup+0x0/0x42
 [<00216134>] kernel_init+0xe6/0xee
 [<0021604e>] kernel_init+0x0/0xee
 [<00001000>] kernel_pg_dir+0x0/0x1000
 [<00002874>] kernel_thread+0x3a/0x4e

Alan.

Re: Atari TT (next)

[Andreas Schwab]

Alan Hourihane <alanh@fairlite.co.uk> writes:

> *** FORMAT ERROR ***   FORMAT=0
> Current process id is 768
> BAD KERNEL TRAP: 00000000
> Modules linked in:
> PC: [<000029de>] flush_thread+0x8/0xe

void flush_thread(void)
{
	unsigned long zero = 0;

	current->thread.fs = __USER_DS;
	if (!FPU_IS_EMU)
		asm volatile (".chip 68k/68881\n\t"
			      "frestore %0@\n\t"
			      ".chip 68k" : : "a" (&zero));
}

GCC is optimizing away the initialisation of zero, since nothing visible
is using its value.

Andreas.

--------------------------->8----------------------------------------
>From bbf7451db90fcec5eade9d8bc913b78829192b9c Mon Sep 17 00:00:00 2001
From: Andreas Schwab <schwab@linux-m68k.org>
Date: Mon, 9 Jan 2012 11:36:18 +0100
Subject: [PATCH] m68k: fix assembler constraint to prevent overeager gcc
 optimisation

Passing the address of a variable as an operand to an asm statement
doesn't mark the value of this variable as used, so gcc optimized its
initialisation away.  Fix this by using a "m" constraint instead.
---
 arch/m68k/kernel/process_mm.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/m68k/kernel/process_mm.c b/arch/m68k/kernel/process_mm.c
index 1bc223a..aa4ffb8 100644
--- a/arch/m68k/kernel/process_mm.c
+++ b/arch/m68k/kernel/process_mm.c
@@ -189,8 +189,8 @@ void flush_thread(void)
 	current->thread.fs = __USER_DS;
 	if (!FPU_IS_EMU)
 		asm volatile (".chip 68k/68881\n\t"
-			      "frestore %0@\n\t"
-			      ".chip 68k" : : "a" (&zero));
+			      "frestore %0\n\t"
+			      ".chip 68k" : : "m" (zero));
 }
 
 /*
-- 
1.7.8.3


-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Atari TT (next)

[Alan Hourihane]

On 09/01/12 10:40, Andreas Schwab wrote:
> Alan Hourihane <alanh@fairlite.co.uk> writes:
>
>> *** FORMAT ERROR ***   FORMAT=0
>> Current process id is 768
>> BAD KERNEL TRAP: 00000000
>> Modules linked in:
>> PC: [<000029de>] flush_thread+0x8/0xe
> void flush_thread(void)
> {
> 	unsigned long zero = 0;
>
> 	current->thread.fs = __USER_DS;
> 	if (!FPU_IS_EMU)
> 		asm volatile (".chip 68k/68881\n\t"
> 			      "frestore %0@\n\t"
> 			      ".chip 68k" : : "a" (&zero));
> }
>
> GCC is optimizing away the initialisation of zero, since nothing visible
> is using its value.

Great spot!

Seems this also needs massaging into process_no.c too.

But am I at a shell prompt :-)

Alan.

Re: Atari TT (next)

[Geert Uytterhoeven]

On Mon, Jan 9, 2012 at 11:40, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Alan Hourihane <alanh@fairlite.co.uk> writes:
>
>> *** FORMAT ERROR ***   FORMAT=0
>> Current process id is 768
>> BAD KERNEL TRAP: 00000000
>> Modules linked in:
>> PC: [<000029de>] flush_thread+0x8/0xe
>
> void flush_thread(void)
> {
>        unsigned long zero = 0;
>
>        current->thread.fs = __USER_DS;
>        if (!FPU_IS_EMU)
>                asm volatile (".chip 68k/68881\n\t"
>                              "frestore %0@\n\t"
>                              ".chip 68k" : : "a" (&zero));
> }
>
> GCC is optimizing away the initialisation of zero, since nothing visible
> is using its value.
>
> Andreas.
>
> --------------------------->8----------------------------------------
> From bbf7451db90fcec5eade9d8bc913b78829192b9c Mon Sep 17 00:00:00 2001
> From: Andreas Schwab <schwab@linux-m68k.org>
> Date: Mon, 9 Jan 2012 11:36:18 +0100
> Subject: [PATCH] m68k: fix assembler constraint to prevent overeager gcc
>  optimisation
>
> Passing the address of a variable as an operand to an asm statement
> doesn't mark the value of this variable as used, so gcc optimized its
> initialisation away.  Fix this by using a "m" constraint instead.
> ---
>  arch/m68k/kernel/process_mm.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/m68k/kernel/process_mm.c b/arch/m68k/kernel/process_mm.c
> index 1bc223a..aa4ffb8 100644
> --- a/arch/m68k/kernel/process_mm.c
> +++ b/arch/m68k/kernel/process_mm.c
> @@ -189,8 +189,8 @@ void flush_thread(void)
>        current->thread.fs = __USER_DS;
>        if (!FPU_IS_EMU)
>                asm volatile (".chip 68k/68881\n\t"
> -                             "frestore %0@\n\t"
> -                             ".chip 68k" : : "a" (&zero));
> +                             "frestore %0\n\t"
> +                             ".chip 68k" : : "m" (zero));
>  }
>
>  /*
> --
> 1.7.8.3

Thanks!

Tuomas: I think this will fix your problem, too?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Atari TT (next)

[Tuomas Vainikka]

On 01/09/2012 02:14 PM, Geert Uytterhoeven wrote:
> On Mon, Jan 9, 2012 at 11:40, Andreas Schwab<schwab@linux-m68k.org>  wrote:
>> Alan Hourihane<alanh@fairlite.co.uk>  writes:
>>
>>> *** FORMAT ERROR ***   FORMAT=0
>>> Current process id is 768
>>> BAD KERNEL TRAP: 00000000
>>> Modules linked in:
>>> PC: [<000029de>] flush_thread+0x8/0xe
>> void flush_thread(void)
>> {
>>         unsigned long zero = 0;
>>
>>         current->thread.fs = __USER_DS;
>>         if (!FPU_IS_EMU)
>>                 asm volatile (".chip 68k/68881\n\t"
>>                               "frestore %0@\n\t"
>>                               ".chip 68k" : : "a" (&zero));
>> }
>>
>> GCC is optimizing away the initialisation of zero, since nothing visible
>> is using its value.
>>
>> Andreas.
>>
>> --------------------------->8----------------------------------------
>>  From bbf7451db90fcec5eade9d8bc913b78829192b9c Mon Sep 17 00:00:00 2001
>> From: Andreas Schwab<schwab@linux-m68k.org>
>> Date: Mon, 9 Jan 2012 11:36:18 +0100
>> Subject: [PATCH] m68k: fix assembler constraint to prevent overeager gcc
>>   optimisation
>>
>> Passing the address of a variable as an operand to an asm statement
>> doesn't mark the value of this variable as used, so gcc optimized its
>> initialisation away.  Fix this by using a "m" constraint instead.
>> ---
>>   arch/m68k/kernel/process_mm.c |    4 ++--
>>   1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/m68k/kernel/process_mm.c b/arch/m68k/kernel/process_mm.c
>> index 1bc223a..aa4ffb8 100644
>> --- a/arch/m68k/kernel/process_mm.c
>> +++ b/arch/m68k/kernel/process_mm.c
>> @@ -189,8 +189,8 @@ void flush_thread(void)
>>         current->thread.fs = __USER_DS;
>>         if (!FPU_IS_EMU)
>>                 asm volatile (".chip 68k/68881\n\t"
>> -                             "frestore %0@\n\t"
>> -                             ".chip 68k" : : "a" (&zero));
>> +                             "frestore %0\n\t"
>> +                             ".chip 68k" : : "m" (zero));
>>   }
>>
>>   /*
>> --
>> 1.7.8.3
> Thanks!
>
> Tuomas: I think this will fix your problem, too?
>
I'll stop nagging if it works. :)

Tuomas

[PATCH] m68k: fix assembler constraint to prevent overeager gcc optimisation

[Andreas Schwab]

Passing the address of a variable as an operand to an asm statement
doesn't mark the value of this variable as used, so gcc may optimize its
initialisation away.  Fix this by using the "m" constraint instead.

Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
---
 arch/m68k/atari/config.c      |    8 ++++----
 arch/m68k/kernel/process_mm.c |    4 ++--
 arch/m68k/kernel/process_no.c |    4 ++--
 arch/m68k/kernel/traps.c      |   36 +++++++++++++++++-------------------
 arch/m68k/mm/cache.c          |    6 +++---
 5 files changed, 28 insertions(+), 30 deletions(-)

diff --git a/arch/m68k/atari/config.c b/arch/m68k/atari/config.c
index 273c7e8..af78731 100644
--- a/arch/m68k/atari/config.c
+++ b/arch/m68k/atari/config.c
@@ -415,9 +415,9 @@ void __init config_atari(void)
 					 * FDC val = 4 -> Supervisor only */
 		asm volatile ("\n"
 			"	.chip	68030\n"
-			"	pmove	%0@,%/tt1\n"
+			"	pmove	%0,%/tt1\n"
 			"	.chip	68k"
-			: : "a" (&tt1_val));
+			: : "m" (tt1_val));
 	} else {
 	        asm volatile ("\n"
 			"	.chip	68040\n"
@@ -570,10 +570,10 @@ static void atari_reset(void)
 			: "d0");
 	} else
 		asm volatile ("\n"
-			"	pmove	%0@,%%tc\n"
+			"	pmove	%0,%%tc\n"
 			"	jmp	%1@"
 			: /* no outputs */
-			: "a" (&tc_val), "a" (reset_addr));
+			: "m" (tc_val), "a" (reset_addr));
 }
 
 
diff --git a/arch/m68k/kernel/process_mm.c b/arch/m68k/kernel/process_mm.c
index 1bc223a..aa4ffb8 100644
--- a/arch/m68k/kernel/process_mm.c
+++ b/arch/m68k/kernel/process_mm.c
@@ -189,8 +189,8 @@ void flush_thread(void)
 	current->thread.fs = __USER_DS;
 	if (!FPU_IS_EMU)
 		asm volatile (".chip 68k/68881\n\t"
-			      "frestore %0@\n\t"
-			      ".chip 68k" : : "a" (&zero));
+			      "frestore %0\n\t"
+			      ".chip 68k" : : "m" (zero));
 }
 
 /*
diff --git a/arch/m68k/kernel/process_no.c b/arch/m68k/kernel/process_no.c
index 69c1803..5e1078c 100644
--- a/arch/m68k/kernel/process_no.c
+++ b/arch/m68k/kernel/process_no.c
@@ -163,8 +163,8 @@ void flush_thread(void)
 #ifdef CONFIG_FPU
 	if (!FPU_IS_EMU)
 		asm volatile (".chip 68k/68881\n\t"
-			      "frestore %0@\n\t"
-			      ".chip 68k" : : "a" (&zero));
+			      "frestore %0\n\t"
+			      ".chip 68k" : : "m" (zero));
 #endif
 }
 
diff --git a/arch/m68k/kernel/traps.c b/arch/m68k/kernel/traps.c
index 89362f2..eb67469 100644
--- a/arch/m68k/kernel/traps.c
+++ b/arch/m68k/kernel/traps.c
@@ -552,13 +552,13 @@ static inline void bus_error030 (struct frame *fp)
 
 #ifdef DEBUG
 		asm volatile ("ptestr %3,%2@,#7,%0\n\t"
-			      "pmove %%psr,%1@"
-			      : "=a&" (desc)
-			      : "a" (&temp), "a" (addr), "d" (ssw));
+			      "pmove %%psr,%1"
+			      : "=a&" (desc), "=m" (temp)
+			      : "a" (addr), "d" (ssw));
 #else
 		asm volatile ("ptestr %2,%1@,#7\n\t"
-			      "pmove %%psr,%0@"
-			      : : "a" (&temp), "a" (addr), "d" (ssw));
+			      "pmove %%psr,%0"
+			      : "=m" (temp) : "a" (addr), "d" (ssw));
 #endif
 		mmusr = temp;
 
@@ -605,20 +605,18 @@ static inline void bus_error030 (struct frame *fp)
 			       !(ssw & RW) ? "write" : "read", addr,
 			       fp->ptregs.pc, ssw);
 			asm volatile ("ptestr #1,%1@,#0\n\t"
-				      "pmove %%psr,%0@"
-				      : /* no outputs */
-				      : "a" (&temp), "a" (addr));
+				      "pmove %%psr,%0"
+				      : "=m" (temp)
+				      : "a" (addr));
 			mmusr = temp;
 
 			printk ("level 0 mmusr is %#x\n", mmusr);
 #if 0
-			asm volatile ("pmove %%tt0,%0@"
-				      : /* no outputs */
-				      : "a" (&tlong));
+			asm volatile ("pmove %%tt0,%0"
+				      : "=m" (tlong));
 			printk("tt0 is %#lx, ", tlong);
-			asm volatile ("pmove %%tt1,%0@"
-				      : /* no outputs */
-				      : "a" (&tlong));
+			asm volatile ("pmove %%tt1,%0"
+				      : "=m" (tlong));
 			printk("tt1 is %#lx\n", tlong);
 #endif
 #ifdef DEBUG
@@ -668,13 +666,13 @@ static inline void bus_error030 (struct frame *fp)
 
 #ifdef DEBUG
 	asm volatile ("ptestr #1,%2@,#7,%0\n\t"
-		      "pmove %%psr,%1@"
-		      : "=a&" (desc)
-		      : "a" (&temp), "a" (addr));
+		      "pmove %%psr,%1"
+		      : "=a&" (desc), "=m" (temp)
+		      : "a" (addr));
 #else
 	asm volatile ("ptestr #1,%1@,#7\n\t"
-		      "pmove %%psr,%0@"
-		      : : "a" (&temp), "a" (addr));
+		      "pmove %%psr,%0"
+		      : "=m" (temp) : "a" (addr));
 #endif
 	mmusr = temp;
 
diff --git a/arch/m68k/mm/cache.c b/arch/m68k/mm/cache.c
index 5437fff..5550aa4 100644
--- a/arch/m68k/mm/cache.c
+++ b/arch/m68k/mm/cache.c
@@ -52,9 +52,9 @@ static unsigned long virt_to_phys_slow(unsigned long vaddr)
 		unsigned long *descaddr;
 
 		asm volatile ("ptestr %3,%2@,#7,%0\n\t"
-			      "pmove %%psr,%1@"
-			      : "=a&" (descaddr)
-			      : "a" (&mmusr), "a" (vaddr), "d" (get_fs().seg));
+			      "pmove %%psr,%1"
+			      : "=a&" (descaddr), "=m" (mmusr)
+			      : "a" (vaddr), "d" (get_fs().seg));
 		if (mmusr & (MMU_I|MMU_B|MMU_L))
 			return 0;
 		descaddr = phys_to_virt((unsigned long)descaddr);
-- 
1.7.8.3


-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH] m68k: fix assembler constraint to prevent overeager gcc optimisation

[Geert Uytterhoeven]

On Mon, Jan 9, 2012 at 15:10, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Passing the address of a variable as an operand to an asm statement
> doesn't mark the value of this variable as used, so gcc may optimize its
> initialisation away.  Fix this by using the "m" constraint instead.

Thanks! I'll apply and queue for -stable.

> diff --git a/arch/m68k/kernel/process_mm.c b/arch/m68k/kernel/process_mm.c
> index 1bc223a..aa4ffb8 100644
> --- a/arch/m68k/kernel/process_mm.c
> +++ b/arch/m68k/kernel/process_mm.c
> @@ -189,8 +189,8 @@ void flush_thread(void)
>        current->thread.fs = __USER_DS;
>        if (!FPU_IS_EMU)
>                asm volatile (".chip 68k/68881\n\t"
> -                             "frestore %0@\n\t"
> -                             ".chip 68k" : : "a" (&zero));
> +                             "frestore %0\n\t"
> +                             ".chip 68k" : : "m" (zero));
>  }
>
>  /*

This one was changed to:

| asm volatile ("frestore %0@" : : "a" (&zero) : "memory");

in v3.3-rc1.

I take it (but I prefer to ask, asm constraints always make me nervous)
the "memory" is no longer needed with your fix?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] m68k: fix assembler constraint to prevent overeager gcc optimisation

[Geert Uytterhoeven]

On Sun, Jan 22, 2012 at 11:15, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Mon, Jan 9, 2012 at 15:10, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> Passing the address of a variable as an operand to an asm statement
>> doesn't mark the value of this variable as used, so gcc may optimize its
>> initialisation away.  Fix this by using the "m" constraint instead.
>
> Thanks! I'll apply and queue for -stable.

BTW, is it reasonable to assume we never saw the problem before because
there used to be a set_fs() call in flush_thread()?
Cfr. commit b7de110044b4e26adcb7b278d14da93133692ed7 ("m68k, exec:
remove redundant set_fs(USER_DS)"),
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=b7de110044b4e26adcb7b278d14da93133692ed7

That would mean it happens in 3.1 and later only.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] m68k: fix assembler constraint to prevent overeager gcc optimisation

[Andreas Schwab]

Geert Uytterhoeven <geert@linux-m68k.org> writes:

> I take it (but I prefer to ask, asm constraints always make me nervous)
> the "memory" is no longer needed with your fix?

No, it isn't.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Atari TT (next)

[Michael Schmitz]

Hi Alan,

>
> Next problem is the SCSI controller.

My absolute favourite.

> NCR5380 core release=7.
> NCR5380: coroutine isn't running.
> scsi0: no currently connected command
> scsi0: issue_queue
> scsi0: disconnected_queue
> scsi0: destination target 0, lun 0
>        command = 18 (0x12) 00 00 00 24 00
>
> scsi 0:0:0:0: Device offlined - not ready after error recovery
>
> I'll start poking at this.

If you can get the error recovery sorted, I'd be happy to start poking
at Falcon SCSI again.

(Yes, I know a cold boot sorted it for now - just in case you can get
it to get stuck again)

Congrats to getting this far at least - I have no idea on the initrd though.

Cheers,

  Michael

Re: Atari TT (next)

[Thorsten Glaser]

Michael Schmitz <schmitzmic <at> googlemail.com> writes:

> >> Can you try to have the kernel placed in ST-RAM?
> >
> > No, the kernel is too big. I've only got 4MB ST-RAM. And getting more on

The guys at the Atari booth at OpenRheinRuhr had the same problem,
they also had a 4/4 MiB split.

> You may have to pare the kernel down to the bare minimum (i.e.
> modularize about everything you don't need to boot to initrd). Not
> sure where the limit for this is these days.

Note that the Debian kernel does not use initrd to boot (to the
finally installed system), especially as those tools are built
with klibc, which is currently still broken on m68k, and thus
contains everything needed to get into an ext3fs / from disc,
and then some. I don’t think you should be using a distro kernel
made under such constraints (nor should the distro kernel be
stripped more down considering the problems; I think there may
even be flavours that don’t _support_ initrd, outside the image
that is) but compile a stripped-down one yourself.

> >> You're right, this should be possible to test with ARAnyM - the
> >> behavior is not new though. Loading the kernel in TT-RAM has been
> >> problematic on the Falcon for a long time now.

I don’t know about that; ARanyM has a built-in LILO, so I never
saw any TOS (except when using AfrOS, but that’s a whole different
beast)…

bye,
//mirabilos

Re: Atari TT (next)

[Michael Schmitz]

Hi Thorsten,
>>> No, the kernel is too big. I've only got 4MB ST-RAM. And getting more on
> The guys at the Atari booth at OpenRheinRuhr had the same problem,
> they also had a 4/4 MiB split.
OK, worth fixing in this case.

Considering the kernel may fit into the first 4 MB, how much room does 
that leave for RAM allocated through stram_alloc?
Do we need to set aside some RAM right at the end of the kernel code 
segment for things like atafb (like we used to do in 2.2 or thereabouts)?
>> You may have to pare the kernel down to the bare minimum (i.e.
>> modularize about everything you don't need to boot to initrd). Not
>> sure where the limit for this is these days.
> Note that the Debian kernel does not use initrd to boot (to the
> finally installed system), especially as those tools are built
> with klibc, which is currently still broken on m68k, and thus
I wasn't aware of that.
> contains everything needed to get into an ext3fs / from disc,
> and then some. I don’t think you should be using a distro kernel
> made under such constraints (nor should the distro kernel be
> stripped more down considering the problems; I think there may
> even be flavours that don’t _support_ initrd, outside the image
> that is) but compile a stripped-down one yourself.
That's what I was suggesting - a stripped down kernel tailored to the TT 
could then
be 'distributed' (like you do with other stuff from your people.d.o 
page) to those
that need it.

Not that a total of 8 MB RAM would be a lot of fun to run today's kernel 
and userland on.

Cheers,

   Michael

Re: Atari TT (next)

[Thorsten Glaser]

Michael Schmitz <schmitzmic <at> googlemail.com> writes:

> > Note that the Debian kernel does not use initrd to boot (to the
> > finally installed system), especially as those tools are built
> > with klibc, which is currently still broken on m68k, and thus

> I wasn't aware of that.

Yeah. I have started trying to fix that, though ☺ see the other
mail of today.

> That's what I was suggesting - a stripped down kernel tailored to the TT 
> could then
> be 'distributed' (like you do with other stuff from your people.d.o 
> page) to those
> that need it.

That would indeed be possible and not too hard (Debian has tools for
that, and if must, these could even be cross-built).

> Not that a total of 8 MB RAM would be a lot of fun to run today's kernel 
> and userland on.

Indeed. I did that for a friend’s i486 laptop, and I’ve got one of those
myself as well except it has 12 MiB. MirBSD works – barely. (I could go
multiuser on the 12 MiB RAM one, but decided to not do it; it’s enough
for 3 virtual consoles, GNU screen, lynx, ssh client, tinyirc. Not my
regular IRC client sirc, as that one’s written in Perl. So, definitively
no stock Linux distribution…)

bye,
//mirabilos

Re: Atari TT (next)

[Geert Uytterhoeven]

On Sun, Jan 29, 2012 at 01:57, Thorsten Glaser <tg@debian.org> wrote:
>> Not that a total of 8 MB RAM would be a lot of fun to run today's kernel
>> and userland on.
>
> Indeed. I did that for a friend’s i486 laptop, and I’ve got one of those
> myself as well except it has 12 MiB. MirBSD works – barely. (I could go
> multiuser on the 12 MiB RAM one, but decided to not do it; it’s enough
> for 3 virtual consoles, GNU screen, lynx, ssh client, tinyirc. Not my
> regular IRC client sirc, as that one’s written in Perl. So, definitively
> no stock Linux distribution…)

Don't tell me. My Amiga also has only 12 MiB of Fast RAM. Where are
the days my Amiga was mailserver for 70 people, many of them logging
in remotely to read their email with pine? Debian is getted too bloated,
I have less packages (incl.daemons) installed than 12 years ago, but the
system is still much slower.

I really need more time to work on an OpenWRT-based solution ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Atari TT (next)

[Thorsten Glaser]

Geert Uytterhoeven dixit:

>Don't tell me. My Amiga also has only 12 MiB of Fast RAM. Where are
>the days my Amiga was mailserver for 70 people, many of them logging
>in remotely to read their email with pine? Debian is getted too bloated,

;-)

It’s not just that. XFree86 4, for example, is a memory hog compared
to XF86 3, and Unicode support eats up lots and lots of RAM.

>I have less packages (incl.daemons) installed than 12 years ago, but the
>system is still much slower.

Hm, slower too?

On the other hand, in the time since I started with m68k, I think
it got faster (except compiling gcc itself, but that was to be
expected) and, even more important, more responsible.

>I really need more time to work on an OpenWRT-based solution ;-)

Or FreeWRT, or OpenADK, or… ;-)

bye,
//mirabilos
-- 
  “Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool.”
						-- Edward Burr

Re: Atari TT (next)

[Geert Uytterhoeven]

On Sun, Jan 29, 2012 at 20:55, Thorsten Glaser <tg@mirbsd.de> wrote:
> Geert Uytterhoeven dixit:
>>Don't tell me. My Amiga also has only 12 MiB of Fast RAM. Where are
>>the days my Amiga was mailserver for 70 people, many of them logging
>>in remotely to read their email with pine? Debian is getted too bloated,
>
> ;-)
>
> It’s not just that. XFree86 4, for example, is a memory hog compared
> to XF86 3, and Unicode support eats up lots and lots of RAM.

xserver-xfbdev based on kdrive still exists, right?
But AFAIK it lacks Amiga and Atari frame buffer device support. Fixing
that has been on my list for a looooong time...

>>I have less packages (incl.daemons) installed than 12 years ago, but the
>>system is still much slower.
>
> Hm, slower too?

Yep. No free RAM, so everything causes swapping.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Atari TT (next)

[Geert Uytterhoeven]

On Sun, Jan 8, 2012 at 05:13, Michael Schmitz <schmitzmic@googlemail.com> wrote:
> For this option to work, ST-RAM first has to be accepted by memory init
> (i.e. it has to be in the first chunk). We might have to resort to reserving
> the entire ST-RAM for the kernel's use if the kernel is not residing in
> ST-RAM (breaking the above assumption). Something similar is done for Amiga
> chip RAM - exactly how does the chip RAM situation differ, Geert? Is chip
> RAM being claimed by mem_init or is it being left aside?

Chip RAM is different in that Linux (unlike AmigaOS) doesn't use it as
system RAM.
Being on the Zorro II bus (first 16 MiB), it's slow on most machines and doesn't
support RMW cycles (needed for page tables) on Zorro III-capable machines.
In general, we don't use Z2 RAM as system memory on Z3 capable machines.

> Come to think of it - does the TT video chipset actually require screen
> memory to reside in ST-RAM? If it's fully 32 bit addressed we should not
> have any problems with TT-RAM. The problems you see might be caused by a
> fault in the TT codepath in atafb - I'm unsure this has been tested since
> the last atafb rewrite.

static void set_screen_base(void *s_base)
{
        unsigned long addr;

        addr = virt_to_phys(s_base);
        /* Setup Screen Memory */
        shifter.bas_hi = (unsigned char)((addr & 0xff0000) >> 16);
        shifter.bas_md = (unsigned char)((addr & 0x00ff00) >> 8);
        shifter.bas_lo = (unsigned char)(addr & 0x0000ff);
}

It's limited to 24-bit addresses.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Atari TT (next)

[Michael Schmitz]

Hi Geert,

>> ST-RAM (breaking the above assumption). Something similar is done for Amiga
>> chip RAM - exactly how does the chip RAM situation differ, Geert? Is chip
>> RAM being claimed by mem_init or is it being left aside?
>
> Chip RAM is different in that Linux (unlike AmigaOS) doesn't use it as
> system RAM.
> Being on the Zorro II bus (first 16 MiB), it's slow on most machines and doesn't
> support RMW cycles (needed for page tables) on Zorro III-capable machines.
> In general, we don't use Z2 RAM as system memory on Z3 capable machines.

But is its physical address lower than the kernel segment's, as in this case?

(thanks to Andreas for the discontigmem commit pointer ... )

> It's limited to 24-bit addresses.

Thanks, that's what I could not find on the spot.

Looks like we'll have to fix the bootstrap or our discontig memory
support. Is there a strict requirement (from the kernel's early
startup and mem_init POV) that the kernel has to reside in the first
bootinfo memory chunk?

Cheers,

  Michael

Re: Atari TT (next)

[Geert Uytterhoeven]

Hi Michael,

On Sun, Jan 8, 2012 at 20:21, Michael Schmitz <schmitzmic@googlemail.com> wrote:
>>> ST-RAM (breaking the above assumption). Something similar is done for Amiga
>>> chip RAM - exactly how does the chip RAM situation differ, Geert? Is chip
>>> RAM being claimed by mem_init or is it being left aside?
>>
>> Chip RAM is different in that Linux (unlike AmigaOS) doesn't use it as
>> system RAM.
>> Being on the Zorro II bus (first 16 MiB), it's slow on most machines and doesn't
>> support RMW cycles (needed for page tables) on Zorro III-capable machines.
>> In general, we don't use Z2 RAM as system memory on Z3 capable machines.
>
> But is its physical address lower than the kernel segment's, as in this case?

Yes, Zorro II space is the first 16 MiB.
But it's handled completely separately from system RAM.
Its mapping is set up in mmu_init_amiga() in head.S.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Atari TT (next)

[Michael Schmitz]

Hi Geert,

>>> Being on the Zorro II bus (first 16 MiB), it's slow on most machines and doesn't
>>> support RMW cycles (needed for page tables) on Zorro III-capable machines.
>>> In general, we don't use Z2 RAM as system memory on Z3 capable machines.
>>
>> But is its physical address lower than the kernel segment's, as in this case?
>
> Yes, Zorro II space is the first 16 MiB.

Thanks, so there would be a similar situation where Z2 RAM would not
be accessible to mem_init on Amiga.

> But it's handled completely separately from system RAM.
> Its mapping is set up in mmu_init_amiga() in head.S.

Looks like we may need to do the same for the TT then.

Cheers,

  Michael

Re: Atari TT (next)

[Andreas Schwab]

Michael Schmitz <schmitzmic@googlemail.com> writes:

> Looks like we'll have to fix the bootstrap or our discontig memory
> support. Is there a strict requirement (from the kernel's early
> startup and mem_init POV) that the kernel has to reside in the first
> bootinfo memory chunk?

It is a requirement that the kernel is mapped at virtual address zero
since it is not relocatable.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Atari TT (next)

[Michael Schmitz]

Hi Andreas,

>> support. Is there a strict requirement (from the kernel's early
>> startup and mem_init POV) that the kernel has to reside in the first
>> bootinfo memory chunk?
>
> It is a requirement that the kernel is mapped at virtual address zero
> since it is not relocatable.

That much I understand - but can we tweak the bootinfo to report the
chunks in physical address order? What I mean to say is - does the
first bootinfo chunk get mapped at virtual address zero always, or is
there some check to see what physical address corresponds to the
kernel segment?

Cheers,

  Michael

Re: Atari TT (next)

[Alan Hourihane]

On 08/01/12 23:39, Michael Schmitz wrote:
> Hi Andreas,
>
>>> support. Is there a strict requirement (from the kernel's early
>>> startup and mem_init POV) that the kernel has to reside in the first
>>> bootinfo memory chunk?
>> It is a requirement that the kernel is mapped at virtual address zero
>> since it is not relocatable.
> That much I understand - but can we tweak the bootinfo to report the
> chunks in physical address order? What I mean to say is - does the
> first bootinfo chunk get mapped at virtual address zero always, or is
> there some check to see what physical address corresponds to the
> kernel segment?
>

>From what I can see the first mem_info struct is always mapped at VA 0
which is done in paging_init() in mm/motorola.c

Alan.

Re: Atari TT (next)

[Michael Schmitz]

Hi Alan,

>> That much I understand - but can we tweak the bootinfo to report the
>> chunks in physical address order? What I mean to say is - does the
>> first bootinfo chunk get mapped at virtual address zero always, or is
>> there some check to see what physical address corresponds to the
>> kernel segment?
>>
>
> From what I can see the first mem_info struct is always mapped at VA 0
> which is done in paging_init() in mm/motorola.c

Thanks - I've got no kernel tree in front of me (no m68k hacking while
at work) so I'm working from (fuzzy) memory only.

Meaning the kernel has to reside in the first chunk then. B*gger.

OK, let's assume we

1) reorder the mem chunks in PA order

2) keep note which was the first chunk initially, and map that one to
VA 0 (instead of the first reordered one)

Does this break any assumptions in paging_init?

Cheers,

  Michael

Re: Atari TT (next)

[Andreas Schwab]

Alan Hourihane <alanh@fairlite.co.uk> writes:

> Now the next problem is that the console is all corrupted because atafb
> initializes and shows this...
>
> atafb_init: start
> atafb_init: initializing TT hw
> atafb: screen_base 0046e000 real_screen_base 0046e000 screen_len 311296
> Determined 640x480, depth 4
>   virtual 640x972
>
> Now, that screen_base is above 4MB, and I've only got 4MB STRAM.

screen_base is a virtual address, the physical address is actually
0x146e000.

> But there's also this further up the boot log.
>
> Ignoring memory chunk at 0x0:0x400000 before the first chunk

Since 12d810c1b8c2b913d48e629e2b5c01d105029839 (m68k: discontinuous
memory support) there is no longer support for memory regions with
physical addresses that are out of order.  Before that, if the kernel
was loaded to TT-RAM the ST-RAM was virtually mapped just after TT-RAM.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Atari TT (next)

[Alan Hourihane]

On 08/01/12 13:36, Andreas Schwab wrote:
> Alan Hourihane <alanh@fairlite.co.uk> writes:
>
>> Now the next problem is that the console is all corrupted because atafb
>> initializes and shows this...
>>
>> atafb_init: start
>> atafb_init: initializing TT hw
>> atafb: screen_base 0046e000 real_screen_base 0046e000 screen_len 311296
>> Determined 640x480, depth 4
>>   virtual 640x972
>>
>> Now, that screen_base is above 4MB, and I've only got 4MB STRAM.
> screen_base is a virtual address, the physical address is actually
> 0x146e000.

I thought that might be the case, given the TTRAM segment offset. But
still, it's in the wrong area.

>> But there's also this further up the boot log.
>>
>> Ignoring memory chunk at 0x0:0x400000 before the first chunk
> Since 12d810c1b8c2b913d48e629e2b5c01d105029839 (m68k: discontinuous
> memory support) there is no longer support for memory regions with
> physical addresses that are out of order.  Before that, if the kernel
> was loaded to TT-RAM the ST-RAM was virtually mapped just after TT-RAM.
>

Thanks for the pointer.

Alan.

Re: Atari TT (next)

[Michael Schmitz]

Hi Andreas,

>> Ignoring memory chunk at 0x0:0x400000 before the first chunk
>
> Since 12d810c1b8c2b913d48e629e2b5c01d105029839 (m68k: discontinuous
> memory support) there is no longer support for memory regions with
> physical addresses that are out of order.  Before that, if the kernel
> was loaded to TT-RAM the ST-RAM was virtually mapped just after TT-RAM.

Thanks - do we need a new memory model for this now?

Cheers,

  Michael

Re: Atari TT (next)

[Geert Uytterhoeven]

On Sat, Jan 7, 2012 at 02:27, Alan Hourihane <alanh@fairlite.co.uk> wrote:
> O.k. I'm passed the unexpected interrupt problem.

BTW, what was wrong?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Atari TT (next)

[Alan Hourihane]

On 08/01/12 17:45, Geert Uytterhoeven wrote:
> On Sat, Jan 7, 2012 at 02:27, Alan Hourihane <alanh@fairlite.co.uk> wrote:
>> O.k. I'm passed the unexpected interrupt problem.
> BTW, what was wrong?
>

It wasn't TT_MFP_TIMD, it was actually the first VME software interrupt.

I'll get a patch together when I've confirmed it working with atafb,
when that's working too :-)

Alan.