Re: debian kernel m68k patches for 2.6.29

Re: debian kernel m68k patches for 2.6.29

[Geert Uytterhoeven]

On Thu, Mar 26, 2009 at 15:10, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Thu, Mar 26, 2009 at 13:38, Stephen R Marenka <stephen@marenka.net> wrote:
>> So 2.6.29 has hit sid. Anyone want to update the kernel patches? Also,
>> what patches to apply now that we have git-based goodness?
>
> You can start with the ones on the for-next branch.
> I still have to cherry-pick the others to the (to be created) queue branch.
> I'll let you know when I'm finished.

Now my git skills have been growing, I created two new branches:
  - m68k-v2.6.29
  - queue

Currently they're identical, but queue will soon be updated (rebased),
to track Linus' latest.

The idea is that:
  - master is never rebased, as it's a continuous development branch,
  - queue contains everything sufficiently stable, against Linus' latest.
    I.e. it contains cherry-picked and rebased commits from master.
  - m68k-vX.y.Z contains the stable stuff you want to see in e.g. Debian,
    against a vX.Y.Z tag (I don't track stable vX.Y.Z.T)

m68k-v2.6.29 contains commits from the following topic branches:
  - for-2.6.30
        Already taken by Linus, incl. mac-swim
  - atari-aranym
  - atari-ethernat
  - atari-ethernec
  - atari-scc
  - atari-fat
        Should this be dropped? Last time nobody spoke up to care about it
  - device-model
        Only "Add Amiga Zorro bus modalias and uevent support",
        I'm working on converting Amiga drivers to the platform device framework
  - misc
        "m68k: Fix debug=mem on Amiga"
        "m68k-allow-all-kernel-traps-to-be-handled-via-exception-fixups-all.diff"
        "m68k: Add support for EARLY_PRINTK on MVME16x" and
        "Update for m68k: Add support for EARLY_PRINTK on MVME16x"
And a few things from master, the continuous development branch:
  - atari mouse/keyboard fixes (are they complete? IIRC not yet)
  - adb raw (anyone who cares?)
  - defconfigs updates (may still need some work, comments are welcome!)

If you want to create a patch series from m68k-v2.6.29 against v2.6.29:

    git format-patch v2.6.29..m68k-v2.6.29


git shortlog v2.6.29.. says:
Andreas Schwab (1):
      m68k-allow-all-kernel-traps-to-be-handled-via-exception-fixups-all.diff

Geert Uytterhoeven (22):
      MAINTAINERS: Replace dead link to m68k CVS repository by link to new git r
      m68k: irq_node.handler() should return irqreturn_t
      m68k: Export ARAnyM native feature API
      m68k/ARAnyM: early_param() does not exist in the modular case
      m68k: Wrap nfblock natfeat calls
      m68k: Atari EtherNAT warning fixes
      m68k: Atari SCC serial driver needs atari_SCC_init_done
      m68k: Atari SCC serial driver needs CONFIG_ATARI_SCC
      m68k: Atari SCC serial driver checkpatch cleanups
      m68k: Atari SCC serial driver gs update
      m68k: Atari SCC serial driver break_ctl update
      m68k: Disable Atari serial console support if modular
      m68k: Atari SCC support for ST
      m68k: atari_scc - kill warn_unused_result warnings
      m68k: atari_scc - kill fake config variables
      Revert "msdos fs: remove unsettable atari option"
      Add Amiga Zorro bus modalias support
      m68k: Fix debug=mem on Amiga
      Update for m68k: Add support for EARLY_PRINTK on MVME16x
      m68k: atari_scc - Upstream updates
      m68k: atari - Rename "mfp" to "st_mfp"
      m68k: Update defconfigs for 2.6.29

Kars de Jong (1):
      m68k: Add support for EARLY_PRINTK on MVME16x

Laurent Vivier (3):
      m68k: Add install target
      m68k: mac - Add a new entry in mac_model to identify the floppy controller
      m68k: mac - Add SWIM floppy support

Linux/m68k legacy (2):
      Atari FAT updates
      ADB raw packets

Michael Schmitz (13):
      m68k: section mismatch fixes: DMAsound for Atari
      m68k: section mismatch fixes: Atari SCSI
      m68k: Atari ARAnyM support
      m68k: Atari EtherNAT (SMC91C111) driver
      m68k: Atari EtherNAT updates
      m68k: section mismatch fixes: EtherNAT
      m68k: Atari ROM port ISA adapter support
      m68k: Atari io.h fixes for EtherNAT driver
      m68k: Atari EtherNEC driver
      atari-ethernec-fixes.diff
      m68k: Atari SCC serial driver
      atari: Use the correct mouse interrupt hook
      m68k: Fix atarimouse init

Roman Zippel (1):
      m68k: Add support for ARAnyM block and console access


If you (talking to `owners' of the stuff on the big topic branches now ;-) think
something is finished and ready for upstream, I can squash the commits together
using `git rebase -i' and submit them upstream...


Other stuff (a.o. garbage? :-) still on master:
  - Amiga/Atari/Mac platform device beginnings
  - Make SERIAL_PORT_DFNS depend on CONFIG_ISA
  - Amiga GVP I/O Extender PLIP
  - MC68681 DUART register definitions for the Amiga MultiFace III serial
  - scsi: Clean up mvme147.c
  - CONFIG_SWAP=n: include/linux/swap.h needs <linux/pagemap.h>
  - module: Kill warning: label 'free_init' defined but not used
  - drivers/net/dnet.c needs <linux/io.h>

Enjoy!

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: debian kernel m68k patches for 2.6.29

[Michael Schmitz]

Hi Geert,

> Now my git skills have been growing, I created two new branches:
>   - m68k-v2.6.29
>   - queue

Cool... 

I had to fix a merge conflict in atari_defconfig and multi_defconfig 
when pulling the m68k-v2.6.29 branch (EtherNEC builtin vs. module, which is the 
correct setting?). Looks like I better restart from a fresh clone just for the 
Debian stuff. 
 
> m68k-v2.6.29 contains commits from the following topic branches:
>   - for-2.6.30
>         Already taken by Linus, incl. mac-swim
>   - atari-aranym
>   - atari-ethernat
>   - atari-ethernec
>   - atari-scc
>   - atari-fat
>         Should this be dropped? Last time nobody spoke up to care about it

My problem with FAT as I remember it was the limitation on the cluster size to 
be less or equal to the MMU page size in 2.6. My FAT filesystems are all 
configured the wrong way... so the cluster size is too big and I could never 
test the FAT modifications in a meaningful way. 

I've reformatted one of the IDE disks on my Falcon in the meantime - I'll look 
into that problem over Easter. 

> And a few things from master, the continuous development branch:
>   - atari mouse/keyboard fixes (are they complete? IIRC not yet)

There's a bit of Eiffel emulation code missing (mouse wheel IIRC) that I could 
not test on ARAnyM at that time. My development tree has the necessary bits 
already, I just need to test them. The mouse driver (input driver part) looks 
incredibly messy as a result of all this, and could need a review. 

> If you (talking to `owners' of the stuff on the big topic branches now ;-) think
> something is finished and ready for upstream, I can squash the commits together
> using `git rebase -i' and submit them upstream...

Hint, hint ... what's the policy regarding driver duplication these days? 

Cheers,

  Michael
 

Re: debian kernel m68k patches for 2.6.29

[Geert Uytterhoeven]

On Tue, Apr 7, 2009 at 01:48, Michael Schmitz
<schmitz@biophys.uni-duesseldorf.de> wrote:
>> Now my git skills have been growing, I created two new branches:
>>   - m68k-v2.6.29
>>   - queue
>
> Cool...
>
> I had to fix a merge conflict in atari_defconfig and multi_defconfig
> when pulling the m68k-v2.6.29 branch (EtherNEC builtin vs. module, which is the
> correct setting?). Looks like I better restart from a fresh clone just for the
> Debian stuff.

If you pulled from my master branch before, and now try to merge the
m68k-v2.6.29 branch,
then you will get conflicts.

>> And a few things from master, the continuous development branch:
>>   - atari mouse/keyboard fixes (are they complete? IIRC not yet)
>
> There's a bit of Eiffel emulation code missing (mouse wheel IIRC) that I could
> not test on ARAnyM at that time. My development tree has the necessary bits
> already, I just need to test them. The mouse driver (input driver part) looks
> incredibly messy as a result of all this, and could need a review.

IIRC, there were still some other problems with the version I have, when I last
tried on ARAnyM. Don't remember the details, I'll have to dig into my
mail archive.

>> If you (talking to `owners' of the stuff on the big topic branches now ;-) think
>> something is finished and ready for upstream, I can squash the commits together
>> using `git rebase -i' and submit them upstream...
>
> Hint, hint ... what's the policy regarding driver duplication these days?

Avoid it. Extract the common part. I guess you mean for scc?

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
--
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: debian kernel m68k patches for 2.6.29

[Michael Schmitz]

Hi Geert,

> > I had to fix a merge conflict in atari_defconfig and multi_defconfig
> > when pulling the m68k-v2.6.29 branch (EtherNEC builtin vs. module, which is the
> > correct setting?). Looks like I better restart from a fresh clone just for the
> > Debian stuff.
> 
> If you pulled from my master branch before, and now try to merge the
> m68k-v2.6.29 branch,
> then you will get conflicts.

Figured that when v2.6.29 or m68k-v2.6.29 would not show up no matter what...

> > There's a bit of Eiffel emulation code missing (mouse wheel IIRC) that I could
> > not test on ARAnyM at that time. My development tree has the necessary bits
> > already, I just need to test them. The mouse driver (input driver part) looks
> > incredibly messy as a result of all this, and could need a review.
> 
> IIRC, there were still some other problems with the version I have, when I last
> tried on ARAnyM. Don't remember the details, I'll have to dig into my
> mail archive.

I've updated ARAnyM on my devel system and we'll see about that shortly. My 
latest changes are stuck in my old git tree, should be trivial to merge over. 
 
> > Hint, hint ... what's the policy regarding driver duplication these days?
> 
> Avoid it. Extract the common part. I guess you mean for scc?

Nope, EtherNAT/EtherNEC. I've found some bits in the CTPCI docs regarding 
interrupt vectors used on the EtherNAT, that should make it possible to mostly 
use the common code there. 

Using the platform interface, it should be possible to use a specialized driver 
probe function while keeping the other code, right? 

Regarding SCC - there's three separate zilog drivers in drivers/serial already. 
The m68k SCC drivers should all move there eventually. What common code should 
we use there? (ip22 and sun drivers appear to be complicated by keyboard/mouse 
use, pmac is quirky...)

I cannot find the Mac serial driver anymore (in the m68k-v2.6.29 branch). Leaves 
VME and Atari SCC to be merged and ported to the serial core model. 

If further merge is intended, the ip22 seems the most generic, can anyone 
confirm this? 

	Michael
 

Re: debian kernel m68k patches for 2.6.29

[Michael Schmitz]

Hi Geert,

>   - atari-fat
>         Should this be dropped? Last time nobody spoke up to care about it

The only GEMDOS FAT partition I could mount using this code was a 16 MB one 
which would have been correctly detected as 16 bit FAT by the generic code 
anyway. The 12 bit FAT fallback (which is the main point of the code) fails 
because of the FAT table overflow check later on. The only way the FAT can be 
prevented from overflowing is using a logical sector size larger than 4k (and 
that's impossible on Linux). 

So the whole thing seems a bit pointless to have. I have no legacy GEMDOS 
filesystems that might benefit from having this code, so I cannot be sure it is 
totally pointless. If someone could provide a disk image to test in ARAnyM, I'd 
be happy to give it a try. 

At the very least, the default should be changed to atari=off on modern systems 
like the CT60:
 
Using the wrong mount option on 2.6.29 refused to mount a regular MSDOS fat 
volume as GEMDOS volume (number of clusters too big for FAT), whereas 2.4.30 
happily mounted it (and scribbled the files in random places - had me spooked 
trying to boot the new kernel off it). 

	Michael

Re: debian kernel m68k patches for 2.6.29

[Petr Stehlik]

Michael Schmitz píše v Út 14. 04. 2009 v 09:50 +0200:

> If someone could provide a disk image to test in ARAnyM, I'd be happy to give it a try. 

I could create a disk image for testing real quick. Say with 255, 511
and 1023 MB partitions?

> At the very least, the default should be changed to atari=off on modern systems 
> like the CT60:

Why? How is the CPU accelerator related to disk filesystem?

Petr


--
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: debian kernel m68k patches for 2.6.29

[Michael Schmitz]

Hi,

> > If someone could provide a disk image to test in ARAnyM, I'd be happy to give it a try. 
> 
> I could create a disk image for testing real quick. Say with 255, 511
> and 1023 MB partitions?

Reasonable sizes - as long as these are useable as GEMDOS partitions that should 
be fine. 
 
> > At the very least, the default should be changed to atari=off on modern systems 
> > like the CT60:
> 
> Why? How is the CPU accelerator related to disk filesystem?

Only in so far as no one would want to use 16 or 32 MB partitions these days. 
Not related to the accelerator at all. 

	Michael

Re: debian kernel m68k patches for 2.6.29

[Petr Stehlik]

Michael Schmitz píše v Út 14. 04. 2009 v 10:26 +0200:
> > > At the very least, the default should be changed to atari=off on modern systems 
> > > like the CT60:
> > 
> > Why? How is the CPU accelerator related to disk filesystem?
> 
> Only in so far as no one would want to use 16 or 32 MB partitions these days. 

Well, many years ago it used to be suggested to create a smallish boot
partition and then larger data/application partition(s). I think the
reason for this was that some of the early Atari disk drivers used to
loose the first partition's contents occasionally. 

Anyway, the point is that even these days you can encounter a small
partitions on Atari.

BTW, does it mean that there is a problem with mounting small GEMDOS
partitions in Linux (<32 MB?)? And at the same time you can't mount
larger partitions because of the logical sector size limit (>511 MB)?

Petr


--
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: debian kernel m68k patches for 2.6.29

[Michael Schmitz]

Hi,

> Well, many years ago it used to be suggested to create a smallish boot
> partition and then larger data/application partition(s). I think the
> reason for this was that some of the early Atari disk drivers used to
> loose the first partition's contents occasionally. 
> 
> Anyway, the point is that even these days you can encounter a small
> partitions on Atari.

OK, 
 
> BTW, does it mean that there is a problem with mounting small GEMDOS
> partitions in Linux (<32 MB?)? And at the same time you can't mount
> larger partitions because of the logical sector size limit (>511 MB)?

Small partitions I can mount as regular MSDOS FAT (-o atari=no) only, unless 
they are <32 MB (in which case it's a 16 bit FAT with few enough clusters to be 
treated as 16 bit FAT by the Atari FAT patch).

I'll try your disk image and see what I get. What disk driver did you create 
these partitions with?

	Michael

Re: debian kernel m68k patches for 2.6.29

[Petr Stehlik]

Michael Schmitz píše v St 15. 04. 2009 v 03:25 +0200:
> > BTW, does it mean that there is a problem with mounting small GEMDOS
> > partitions in Linux (<32 MB?)? And at the same time you can't mount
> > larger partitions because of the logical sector size limit (>511 MB)?
> 
> Small partitions I can mount as regular MSDOS FAT (-o atari=no) only, unless 
> they are <32 MB (in which case it's a 16 bit FAT with few enough clusters to be 
> treated as 16 bit FAT by the Atari FAT patch).

I don't think I understand it.

What if I created a disk image with 15, 31, 63, 127, 255 and 511 MB
partitions and sent it to you? Would you please list what partition
sizes are mountable with _and_ without the Atari FAT patch that we are
discussing here? That could finally clear it up (for me at least).

> What disk driver did you create these partitions with?

HDDRIVER, so it should be fully AHDI compatible.

Petr


--
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: debian kernel m68k patches for 2.6.29

[Michael Schmitz]

Hi,

> > Small partitions I can mount as regular MSDOS FAT (-o atari=no) only, unless 
> > they are <32 MB (in which case it's a 16 bit FAT with few enough clusters to be 
> > treated as 16 bit FAT by the Atari FAT patch).
> 
> I don't think I understand it.

It is a bit weird, yes. I may have to get the vfat module to dump more 
information about the volume format to see what goes wrong. 

> What if I created a disk image with 15, 31, 63, 127, 255 and 511 MB
> partitions and sent it to you? Would you please list what partition
> sizes are mountable with _and_ without the Atari FAT patch that we are
> discussing here? That could finally clear it up (for me at least).

I'm happy to do that. Can you please specify what parameters (logical sector 
size, number of sectors per cluster) the partitions were generated with? I'd 
like to compare that with what the vfat module figures out from the disk image.
 
> > What disk driver did you create these partitions with?
> 
> HDDRIVER, so it should be fully AHDI compatible.

Yup - did AHDI use particular values for logical sector size and sectors per 
cluster that we'd need to make sure will still work? 

	Michael

Re: debian kernel m68k patches for 2.6.29

[Petr Stehlik]

Michael Schmitz píše v Čt 16. 04. 2009 v 01:38 +0200:
> > What if I created a disk image with 15, 31, 63, 127, 255 and 511 MB
> > partitions and sent it to you? Would you please list what partition
> > sizes are mountable with _and_ without the Atari FAT patch that we are
> > discussing here? That could finally clear it up (for me at least).
> 
> I'm happy to do that. Can you please specify what parameters (logical sector 
> size, number of sectors per cluster) the partitions were generated with?

Atari GEMDOS and Atari partition programs always use 2 sectors per
cluster. Since FAT16 can hold max 32k entries you can compute the rest
of information from this (example: 63 MB partition needs 2 kB clusters
to fit into 32k cluster limit so the logical sector size for 32-63 MB
partition needs to be 1 kB).

> Yup - did AHDI use particular values for logical sector size and sectors per 
> cluster that we'd need to make sure will still work? 

See above - 2 logical sectors in a cluster. That is actually the only
difference from MS-DOS where they stick with fixed logical sector size
and are adding more sectors to a cluster, IIRC.

Petr


--
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: debian kernel m68k patches for 2.6.29

[Michael Schmitz]

Hi,

> Atari GEMDOS and Atari partition programs always use 2 sectors per
> cluster. Since FAT16 can hold max 32k entries you can compute the rest
> of information from this (example: 63 MB partition needs 2 kB clusters
> to fit into 32k cluster limit so the logical sector size for 32-63 MB
> partition needs to be 1 kB).

There's something wrong with the Atari FAT option code then - this is what I get 
with atari=yes on the first of your partitions (128MB?):

FAT (before atari): FAT bits 0 clusters 32622 sectors 65280 
FAT (option atari): FAT bits 12 clusters 32622 sectors 65280 
FAT (after atari): FAT bits 12 clusters 32622 sectors 65280 

The GEMDOS option code picks a 12 bit FAT even though it should clearly fit into 
a 16 bit FAT. 

With atari=no:

FAT (before atari): FAT bits 0 clusters 32622 sectors 65280 
FAT (after atari): FAT bits 16 clusters 32622 sectors 65280 

The larger two partitions exceed the logial sector size of 4k. 
 
> > Yup - did AHDI use particular values for logical sector size and sectors per 
> > cluster that we'd need to make sure will still work? 
> 
> See above - 2 logical sectors in a cluster. That is actually the only
> difference from MS-DOS where they stick with fixed logical sector size
> and are adding more sectors to a cluster, IIRC.

Thanks, that'll help me to find a fix for this patch. 

	Michael

Re: debian kernel m68k patches for 2.6.29

[Petr Stehlik]

Michael Schmitz píše v Čt 16. 04. 2009 v 09:45 +0200:
> There's something wrong with the Atari FAT option code then - this is what I get 
> with atari=yes on the first of your partitions (128MB?):

255 MB, IIRC (same sector/cluster size as 128 MB)

> FAT (before atari): FAT bits 0 clusters 32622 sectors 65280 
> FAT (option atari): FAT bits 12 clusters 32622 sectors 65280 
> FAT (after atari): FAT bits 12 clusters 32622 sectors 65280 
> 
> The GEMDOS option code picks a 12 bit FAT even though it should clearly fit into 
> a 16 bit FAT. 

I don't know what you mean by "before/after atari" but it's clearly all
wrong. FAT12 is on floppies only... Besides that how could 32622 value
fit into 12 bit number?

Petr


--
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: debian kernel m68k patches for 2.6.29

[Michael Schmitz]

Hi Petr,

> > There's something wrong with the Atari FAT option code then - this is what I get 
> > with atari=yes on the first of your partitions (128MB?):
> 
> 255 MB, IIRC (same sector/cluster size as 128 MB)

Right - 
 
> > FAT (before atari): FAT bits 0 clusters 32622 sectors 65280 
> > FAT (option atari): FAT bits 12 clusters 32622 sectors 65280 
> > FAT (after atari): FAT bits 12 clusters 32622 sectors 65280 
> > 
> > The GEMDOS option code picks a 12 bit FAT even though it should clearly fit into 
> > a 16 bit FAT. 
> 
> I don't know what you mean by "before/after atari" but it's clearly all

'before' is right before the FAT bit size is set in inode.c - without the GEMDOS
option, the FAT is assumed to be 16 bit if it's not set to 32 bit. 

'after' is the final result once the GEMDOS option has been processed. If the 
total number of clusters is found to be larger than the maximum for 16 bit FAT, 
the FAT size is assumed to be 12 bit (with no further adjustment of logical 
sector size or sectors per cluster).

That test clearly goes wrong here.

> wrong. FAT12 is on floppies only... Besides that how could 32622 value
> fit into 12 bit number?

That's the beauty of it, apparently. Just kidding. 

I'll go back to the pre-2.6 code to see if it made sense there. 

	Michael

[PATCH] m68k: Atari GEMDOS FAT option fix: use correct logical sector size

[Michael Schmitz]

Fix erroneous use of device blocksize instead of logical sector size in 
Atari GEMDOS FAT code (GEMDOS uses a 16 bit FAT and a constant 2 logical 
sectors per cluster, and modifies the logical sector size to cope with the 
limits imposed by the 16 bit FAT). The bug was probably introduced by me when 
porting this code forward from 2.4.
With this fix, I can successfully mount GEMDOS partitons up to 256 MB in size as 
prepared by Petr Stehlik. 512 MB require 8k sector size, sorry. 

Signed-off-by: Michael Schmitz <schmitz@debian.org>
---
 fs/fat/inode.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/fat/inode.c b/fs/fat/inode.c
index 34dda7a..8156229 100644
--- a/fs/fat/inode.c
+++ b/fs/fat/inode.c
@@ -1387,7 +1387,7 @@ int fat_fill_super(struct super_block *sb, void *data, int silent,
 		 * it's a real MSDOS partition with 12-bit fat.
 		 */
 		if (sbi->fat_bits != 32 && total_clusters+2 > sbi->
-			fat_length*SECTOR_SIZE*8/sbi->fat_bits)
+			fat_length*sb->s_blocksize*8/sbi->fat_bits)
 			sbi->fat_bits = 12;
 		/* if it's a floppy disk --> 12bit fat */
 		if (sbi->fat_bits != 32 && MAJOR(sb->s_dev) == FLOPPY_MAJOR)
-- 
1.5.6.5

Re: [PATCH] m68k: Atari GEMDOS FAT option fix: use correct logical sector size

[Geert Uytterhoeven]

On Sun, Apr 19, 2009 at 03:20, Michael Schmitz
<schmitz@biophys.uni-duesseldorf.de> wrote:
> Fix erroneous use of device blocksize instead of logical sector size in
> Atari GEMDOS FAT code (GEMDOS uses a 16 bit FAT and a constant 2 logical
> sectors per cluster, and modifies the logical sector size to cope with the
> limits imposed by the 16 bit FAT). The bug was probably introduced by me when
> porting this code forward from 2.4.
> With this fix, I can successfully mount GEMDOS partitons up to 256 MB in size as
> prepared by Petr Stehlik. 512 MB require 8k sector size, sorry.

Thanks, added.

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

[PATCH] m68k: Atari ST-RAM: reserve some ST-RAM for late allocations

[Michael Schmitz]

Hi Geert,

this patch adds the ST-RAM reserve for late allocation as had been previously 
added to the 2.6.28 Debian kernel patches. Without this patch, loading a large 
ramdisk at boot will eat up ST-RAM suitable for atafb, leaving atafb drawing to 
memory that cannot be used by the VIDEL. 
Also, without this patch the Atari SCSI driver will allocate memory unsuitable 
for DMA as DMA dribble buffer. 

  Michael

---
 arch/m68k/atari/stram.c |   61 +++++++++++++++++++++++++++++++++++++++++++---
 1 files changed, 57 insertions(+), 4 deletions(-)

diff --git a/arch/m68k/atari/stram.c b/arch/m68k/atari/stram.c
index 6ec3b7f..f242947 100644
--- a/arch/m68k/atari/stram.c
+++ b/arch/m68k/atari/stram.c
@@ -30,7 +30,7 @@
 #include <asm/atari_stram.h>
 #include <asm/io.h>
 
-#undef DEBUG
+#define DEBUG
 
 #ifdef DEBUG
 #define	DPRINTK(fmt,args...) printk( fmt, ##args )
@@ -91,11 +91,15 @@ typedef struct stram_block {
 /* values for flags field */
 #define BLOCK_FREE	0x01	/* free structure in the BLOCKs pool */
 #define BLOCK_KMALLOCED	0x02	/* structure allocated by kmalloc() */
+#define BLOCK_POOL	0x04	/* block allocated from static pool */
 #define BLOCK_GFP	0x08	/* block allocated with __get_dma_pages() */
 
 /* list of allocated blocks */
 static BLOCK *alloc_list;
 
+static BLOCK *stram_free_list;
+static unsigned long stram_pool, stram_pool_start, stram_pool_end;
+
 /* We can't always use kmalloc() to allocate BLOCK structures, since
  * stram_alloc() can be called rather early. So we need some pool of
  * statically allocated structures. 20 of them is more than enough, so in most
@@ -156,6 +160,10 @@ void __init atari_stram_reserve_pages(void *start_mem)
 	if (!kernel_in_stram)
 		reserve_bootmem(0, PAGE_SIZE, BOOTMEM_DEFAULT);
 
+	stram_pool       = (unsigned long) alloc_bootmem_low(1024*1024);
+	stram_pool_start = stram_pool;
+	stram_pool_end   = stram_pool + 1024*1024 - 1;
+	DPRINTK("atari_stram pool, start=%08lx, end=%08lx\n", stram_pool, stram_pool_end);
 }
 
 void atari_stram_mem_init_hook (void)
@@ -163,6 +171,39 @@ void atari_stram_mem_init_hook (void)
 	mem_init_done = 1;
 }
 
+/* find a region (by size) in the free list */
+static void *find_free_stram( long size )
+{
+	BLOCK *p,*q,*r;
+	unsigned long item;
+
+	q=NULL;
+	r=stram_free_list;
+	for( p = stram_free_list; p; p = p->next ) {
+		if (p->size >= size) {
+			q=p;
+			break;
+		}
+		r=p;
+	}
+
+	/* remove from free list - FIXME, untested! */
+	if (q) {
+		item = (unsigned long) q->start;
+		r->next = q->next;
+		return (void *) item;
+	}
+
+	/* not taken from free list? take from pool */
+	if ( (stram_pool_end - stram_pool) > size) {
+		item = stram_pool;
+		stram_pool += size;
+		return (void *) item;
+	}
+
+	return( NULL );
+}
+
 
 /*
  * This is main public interface: somehow allocate a ST-RAM block
@@ -189,11 +230,17 @@ void *atari_stram_alloc(long size, const char *owner)
 	if (!mem_init_done)
 		return alloc_bootmem_low(size);
 	else {
+	        if ((addr = find_free_stram(size)) != NULL) {
+		  flags = BLOCK_POOL;
+		  DPRINTK( "atari_stram_alloc: after mem_init, "
+				 "find_free_Stram=%p\n", addr );
+	        } else {
 		/* After mem_init(): can only resort to __get_dma_pages() */
-		addr = (void *)__get_dma_pages(GFP_KERNEL, get_order(size));
-		flags = BLOCK_GFP;
-		DPRINTK( "atari_stram_alloc: after mem_init, "
+		  addr = (void *)__get_dma_pages(GFP_KERNEL, get_order(size));
+		  flags = BLOCK_GFP;
+		  DPRINTK( "atari_stram_alloc: after mem_init, "
 				 "get_pages=%p\n", addr );
+		}
 	}
 
 	if (addr) {
@@ -226,6 +273,12 @@ void atari_stram_free( void *addr )
 	DPRINTK( "atari_stram_free: found block (%p): size=%08lx, owner=%s, "
 			 "flags=%02x\n", block, block->size, block->owner, block->flags );
 
+        if (block->flags & BLOCK_POOL) {
+                block->next=stram_free_list->next;
+        	stram_free_list=block;
+        	return;
+        }
+
 	if (!(block->flags & BLOCK_GFP))
 		goto fail;
 
-- 
1.5.6.5

Re: [PATCH] m68k: Atari SCSI - ST-DMA locking and error handling fixes

[Michael Schmitz]

Hi Geert,

some fixes to the Atari NCR5380 SCSI driver: if the ST-DMA lock cannot be taken 
in the queue function, indicate host busy to the block layer. Fix return codes 
of abort and reset functions, and add scsi_unregister to module exit. 
Error handling is still messed up, most likely due to missing ST-DMA lock in 
abort and reset. This is still WIP, but might benefit users with a Falcon less 
prone to SCSI lockups, i.e. more stable SCSI clock signal.

Signed-off-by: Michael Schmitz <schmitz@debian.org>

  Michael

---
 drivers/scsi/atari_NCR5380.c |   78 +++++++++++++++++++++++++++--------------
 drivers/scsi/atari_scsi.c    |   47 +++++++++++++++++++++----
 2 files changed, 91 insertions(+), 34 deletions(-)

diff --git a/drivers/scsi/atari_NCR5380.c b/drivers/scsi/atari_NCR5380.c
index 0471f88..3ba46d5 100644
--- a/drivers/scsi/atari_NCR5380.c
+++ b/drivers/scsi/atari_NCR5380.c
@@ -966,13 +966,6 @@ static int NCR5380_queue_command(Scsi_Cmnd *cmd, void (*done)(Scsi_Cmnd *))
 
 	cmd->result = 0;
 
-	/*
-	 * Insert the cmd into the issue queue. Note that REQUEST SENSE
-	 * commands are added to the head of the queue since any command will
-	 * clear the contingent allegiance condition that exists and the
-	 * sense data is only guaranteed to be valid while the condition exists.
-	 */
-
 	local_irq_save(flags);
 	/* ++guenther: now that the issue queue is being set up, we can lock ST-DMA.
 	 * Otherwise a running NCR5380_main may steal the lock.
@@ -987,10 +980,32 @@ static int NCR5380_queue_command(Scsi_Cmnd *cmd, void (*done)(Scsi_Cmnd *))
 	 * alter queues and touch the lock.
 	 */
 	if (!IS_A_TT()) {
+		int rv;
+		/* MSch: since we may now get called from softirq context here, 
+		 * we cannot always sleep while waiting for the lock.
+		 * Use status from falcon_get_lock() to detect if the lock was
+		 * successfully taken, and return appropriate status to midlevel
+		 * otherwise.
+		 * We used to pause the midlevel SCSI timer here; races between 
+		 * command timeout and lowlevel error handling should not hurt
+		 * because the command isn't in any of the queues yet.
+		 */
 		/* perhaps stop command timer here */
-		falcon_get_lock();
+		rv = falcon_get_lock();
 		/* perhaps restart command timer here */
+		if (rv) {
+			local_irq_restore(flags);
+			return SCSI_MLQUEUE_HOST_BUSY;
+		}
 	}
+
+	/*
+	 * Insert the cmd into the issue queue. Note that REQUEST SENSE
+	 * commands are added to the head of the queue since any command will
+	 * clear the contingent allegiance condition that exists and the
+	 * sense data is only guaranteed to be valid while the condition exists.
+	 */
+
 	if (!(hostdata->issue_queue) || (cmd->cmnd[0] == REQUEST_SENSE)) {
 		LIST(cmd, hostdata->issue_queue);
 		SET_NEXT(cmd, hostdata->issue_queue);
@@ -1014,10 +1029,12 @@ static int NCR5380_queue_command(Scsi_Cmnd *cmd, void (*done)(Scsi_Cmnd *))
 	 * If we're not in an interrupt, we can call NCR5380_main()
 	 * unconditionally, because it cannot be already running.
 	 */
-	if (in_interrupt() || ((flags >> 8) & 7) >= 6)
+	/* As of 2.6.19, the coroutine has to be put on the task queue instead
+	 * of being called directly. It might still be called directly if not 
+	 * in softirq, though. Need to test this.  
+	 */
 		queue_main();
-	else
-		NCR5380_main(NULL);
+
 	return 0;
 }
 
@@ -1463,6 +1480,7 @@ static int NCR5380_select(struct Scsi_Host *instance, Scsi_Cmnd *cmd, int tag)
 	ARB_PRINTK("scsi%d: arbitration complete\n", HOSTNO);
 
 	if (hostdata->connected) {
+		
 		NCR5380_write(MODE_REG, MR_BASE);
 		return -1;
 	}
@@ -2065,7 +2083,6 @@ static void NCR5380_information_transfer(struct Scsi_Host *instance)
 				/*
 				 * The preferred transfer method is going to be
 				 * PSEUDO-DMA for systems that are strictly PIO,
-				 * since we can let the hardware do the handshaking.
 				 *
 				 * For this to work, we need to know the transfersize
 				 * ahead of time, since the pseudo-DMA code will sit
@@ -2631,7 +2648,7 @@ static void NCR5380_reselect(struct Scsi_Host *instance)
  *	host byte of the result field to, if zero DID_ABORTED is
  *	used.
  *
- * Returns : 0 - success, -1 on failure.
+ * Returns : SUCCESS - success, FAILED on failure.
  *
  * XXX - there is no way to abort the command that is currently
  *	 connected, you have to wait for it to complete.  If this is
@@ -2701,11 +2718,12 @@ int NCR5380_abort(Scsi_Cmnd *cmd)
 			local_irq_restore(flags);
 			cmd->scsi_done(cmd);
 			falcon_release_lock_if_possible(hostdata);
-			return SCSI_ABORT_SUCCESS;
+			return SUCCESS;
 		} else {
-/*			local_irq_restore(flags); */
+			/* not sure */
+			local_irq_restore(flags);
 			printk("scsi%d: abort of connected command failed!\n", HOSTNO);
-			return SCSI_ABORT_ERROR;
+			return FAILED;
 		}
 	}
 #endif
@@ -2729,7 +2747,7 @@ int NCR5380_abort(Scsi_Cmnd *cmd)
 			 * yet... */
 			tmp->scsi_done(tmp);
 			falcon_release_lock_if_possible(hostdata);
-			return SCSI_ABORT_SUCCESS;
+			return SUCCESS;
 		}
 	}
 
@@ -2747,7 +2765,7 @@ int NCR5380_abort(Scsi_Cmnd *cmd)
 	if (hostdata->connected) {
 		local_irq_restore(flags);
 		ABRT_PRINTK("scsi%d: abort failed, command connected.\n", HOSTNO);
-		return SCSI_ABORT_SNOOZE;
+		return FAILED;
 	}
 
 	/*
@@ -2782,7 +2800,7 @@ int NCR5380_abort(Scsi_Cmnd *cmd)
 			ABRT_PRINTK("scsi%d: aborting disconnected command.\n", HOSTNO);
 
 			if (NCR5380_select(instance, cmd, (int)cmd->tag))
-				return SCSI_ABORT_BUSY;
+				return FAILED;
 
 			ABRT_PRINTK("scsi%d: nexus reestablished.\n", HOSTNO);
 
@@ -2809,7 +2827,7 @@ int NCR5380_abort(Scsi_Cmnd *cmd)
 					local_irq_restore(flags);
 					tmp->scsi_done(tmp);
 					falcon_release_lock_if_possible(hostdata);
-					return SCSI_ABORT_SUCCESS;
+					return SUCCESS;
 				}
 			}
 		}
@@ -2835,7 +2853,9 @@ int NCR5380_abort(Scsi_Cmnd *cmd)
 	 */
 	falcon_release_lock_if_possible(hostdata);
 
-	return SCSI_ABORT_NOT_RUNNING;
+	/* NCR5380 has FAILED here */
+	/* return SUCCESS; */
+	return FAILED;
 }
 
 
@@ -2844,16 +2864,18 @@ int NCR5380_abort(Scsi_Cmnd *cmd)
  *
  * Purpose : reset the SCSI bus.
  *
- * Returns : SCSI_RESET_WAKEUP
+ * Returns : SUCCESS
  *
  */
 
+#undef	FALCON_RESET_KILL_QUEUES
+
 static int NCR5380_bus_reset(Scsi_Cmnd *cmd)
 {
 	SETUP_HOSTDATA(cmd->device->host);
 	int i;
 	unsigned long flags;
-#if 1
+#if defined(FALCON_RESET_KILL_QUEUES)
 	Scsi_Cmnd *connected, *disconnected_queue;
 #endif
 
@@ -2878,7 +2900,8 @@ static int NCR5380_bus_reset(Scsi_Cmnd *cmd)
 	 * through anymore ... */
 	(void)NCR5380_read(RESET_PARITY_INTERRUPT_REG);
 
-#if 1	/* XXX Should now be done by midlevel code, but it's broken XXX */
+#if defined(FALCON_RESET_KILL_QUEUES)	
+	/* XXX Should now be done by midlevel code, but it's broken XXX */
 	/* XXX see below                                            XXX */
 
 	/* MSch: old-style reset: actually abort all command processing here */
@@ -2934,7 +2957,7 @@ static int NCR5380_bus_reset(Scsi_Cmnd *cmd)
 	 * the midlevel code that the reset was SUCCESSFUL, and there is no
 	 * need to 'wake up' the commands by a request_sense
 	 */
-	return SCSI_RESET_SUCCESS | SCSI_RESET_BUS_RESET;
+	return SUCCESS;
 #else /* 1 */
 
 	/* MSch: new-style reset handling: let the mid-level do what it can */
@@ -2982,6 +3005,7 @@ static int NCR5380_bus_reset(Scsi_Cmnd *cmd)
 	local_irq_restore(flags);
 
 	/* we did no complete reset of all commands, so a wakeup is required */
-	return SCSI_RESET_WAKEUP | SCSI_RESET_BUS_RESET;
-#endif /* 1 */
+	/* The new error handler code implicitly does this for us anyway */
+	return SUCCESS;
+#endif /* defined(FALCON_RESET_KILL_QUEUES) */
 }
diff --git a/drivers/scsi/atari_scsi.c b/drivers/scsi/atari_scsi.c
index ad7a23a..9ebfbc6 100644
--- a/drivers/scsi/atari_scsi.c
+++ b/drivers/scsi/atari_scsi.c
@@ -196,7 +196,7 @@ static unsigned long atari_dma_xfer_len(unsigned long wanted_len,
 static irqreturn_t scsi_tt_intr(int irq, void *dummy);
 static irqreturn_t scsi_falcon_intr(int irq, void *dummy);
 static void falcon_release_lock_if_possible(struct NCR5380_hostdata *hostdata);
-static void falcon_get_lock(void);
+static int falcon_get_lock(void);
 #ifdef CONFIG_ATARI_SCSI_RESET_BOOT
 static void atari_scsi_reset_boot(void);
 #endif
@@ -498,6 +498,16 @@ static int falcon_dont_release = 0;
  * again (but others waiting longer more probably will win).
  */
 
+/*
+ * MSch 20061228: in 2.6.x, the fairness wait appears to open a race with
+ * concurrent use of the lock by the IDE driver. Once the lock is taken by
+ * IDE, the SCSI queuecmd function can no longer schedule because it is run
+ * from softirq context a lot. 
+ * Disable the fairness wait until I have had time to sort out the lock issues.
+ */
+#undef FALCON_FAIRNESS_WAIT
+#define FALCON_NEVER_SLEEP 1
+
 static void falcon_release_lock_if_possible(struct NCR5380_hostdata *hostdata)
 {
 	unsigned long flags;
@@ -519,7 +529,9 @@ static void falcon_release_lock_if_possible(struct NCR5380_hostdata *hostdata)
 		}
 		falcon_got_lock = 0;
 		stdma_release();
+#if defined(FALCON_FAIRNESS_WAIT)
 		wake_up(&falcon_fairness_wait);
+#endif
 	}
 
 	local_irq_restore(flags);
@@ -540,21 +552,37 @@ static void falcon_release_lock_if_possible(struct NCR5380_hostdata *hostdata)
  * Complicated, complicated.... Sigh...
  */
 
-static void falcon_get_lock(void)
+/* MSch 20061229: in order to avoid sleeping when the lock is not available, 
+ * return the current lock state here. atari_queue_command() will then return
+ * with error, causing the midlevel code to pause request submission.
+ */
+static int falcon_get_lock(void)
 {
 	unsigned long flags;
 
 	if (IS_A_TT())
-		return;
+		return 0;
 
 	local_irq_save(flags);
 
-	while (!in_irq() && falcon_got_lock && stdma_others_waiting())
+#if defined(FALCON_FAIRNESS_WAIT)
+	/* MSch: we may not sleep even while in softirq ! */
+	while (!in_interrupt() && falcon_got_lock && stdma_others_waiting())
 		sleep_on(&falcon_fairness_wait);
-
+#endif
 	while (!falcon_got_lock) {
 		if (in_irq())
 			panic("Falcon SCSI hasn't ST-DMA lock in interrupt");
+		/* we may not sleep in soft interrupts neither, so bail out */
+#if defined(FALCON_NEVER_SLEEP)
+		if (stdma_islocked()) {
+#else
+		if (in_softirq() && stdma_islocked()) {
+#endif
+			// printk(KERN_INFO "Falcon SCSI does not hold ST-DMA lock in softirq!\n" );
+			local_irq_restore(flags);
+			return 1;
+		}
 		if (!falcon_trying_lock) {
 			falcon_trying_lock = 1;
 			stdma_lock(scsi_falcon_intr, NULL);
@@ -569,6 +597,8 @@ static void falcon_get_lock(void)
 	local_irq_restore(flags);
 	if (!falcon_got_lock)
 		panic("Falcon SCSI: someone stole the lock :-(\n");
+
+	return 0;
 }
 
 
@@ -589,7 +619,7 @@ int atari_queue_command(Scsi_Cmnd *cmd, void (*done)(Scsi_Cmnd *))
 #endif
 
 
-int __init atari_scsi_detect(struct scsi_host_template *host)
+int atari_scsi_detect(struct scsi_host_template *host)
 {
 	static int called = 0;
 	struct Scsi_Host *instance;
@@ -652,6 +682,8 @@ int __init atari_scsi_detect(struct scsi_host_template *host)
 		}
 		atari_dma_phys_buffer = virt_to_phys(atari_dma_buffer);
 		atari_dma_orig_addr = 0;
+		printk(KERN_ERR "atari_scsi_detect: ST-RAM "
+			"double buffer at %p\n", atari_dma_phys_buffer);
 	}
 #endif
 	instance = scsi_register(host, sizeof(struct NCR5380_hostdata));
@@ -745,6 +777,7 @@ int atari_scsi_release(struct Scsi_Host *sh)
 {
 	if (IS_A_TT())
 		free_irq(IRQ_TT_MFP_SCSI, sh);
+	scsi_unregister(atari_scsi_host);
 	if (atari_dma_buffer)
 		atari_stram_free(atari_dma_buffer);
 	return 1;
@@ -828,7 +861,7 @@ int atari_scsi_bus_reset(Scsi_Cmnd *cmd)
 	} else {
 		atari_turnon_irq(IRQ_MFP_FSCSI);
 	}
-	if ((rv & SCSI_RESET_ACTION) == SCSI_RESET_SUCCESS)
+	if (rv == SUCCESS)
 		falcon_release_lock_if_possible(hostdata);
 
 	return rv;
-- 
1.5.6.5

[PATCH] m68k: Atari - leave out spurious request_irq for Falcon IDE

[Michael Schmitz]

Hi Geert,

I found I need to have this patch in order to avoid doubly registering the 
ST-DMA interrupt for IDE on Falcon.

The interrupt is registered in stdma_init and the current user of the interrupt 
is set by stdma_get_lock. Without the lock held, no interrupt should be 
delivered anyway, so this patch will make it easier to debug locking problems.

Signed-off-by: Michael Schmitz <schmitz@debian.org>

---
 drivers/ide/ide-probe.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/ide/ide-probe.c b/drivers/ide/ide-probe.c
index 7f264ed..f8a86b7 100644
--- a/drivers/ide/ide-probe.c
+++ b/drivers/ide/ide-probe.c
@@ -843,6 +843,9 @@ static int init_irq (ide_hwif_t *hwif)
 	if (io_ports->ctl_addr)
 		hwif->tp_ops->write_devctl(hwif, ATA_DEVCTL_OBS);
 
+#if defined(__mc68000__) && defined (CONFIG_BLK_DEV_FALCON_IDE)
+	if (!MACH_IS_ATARI)
+#endif
 	if (request_irq(hwif->irq, irq_handler, sa, hwif->name, hwif))
 		goto out_up;
 
-- 
1.5.6.5

Re: [PATCH] m68k: Atari - leave out spurious request_irq for Falcon IDE

[Geert Uytterhoeven]

On Tue, Apr 28, 2009 at 07:41, Michael Schmitz
<schmitz@biophys.uni-duesseldorf.de> wrote:
> I found I need to have this patch in order to avoid doubly registering the
> ST-DMA interrupt for IDE on Falcon.

But further it has no ill effects, as it works fine on ARAnyM? Or does
it fail on real hardware?

> The interrupt is registered in stdma_init and the current user of the interrupt
> is set by stdma_get_lock. Without the lock held, no interrupt should be
> delivered anyway, so this patch will make it easier to debug locking problems.
>
> Signed-off-by: Michael Schmitz <schmitz@debian.org>
>
> ---
>  drivers/ide/ide-probe.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/ide/ide-probe.c b/drivers/ide/ide-probe.c
> index 7f264ed..f8a86b7 100644
> --- a/drivers/ide/ide-probe.c
> +++ b/drivers/ide/ide-probe.c
> @@ -843,6 +843,9 @@ static int init_irq (ide_hwif_t *hwif)
>        if (io_ports->ctl_addr)
>                hwif->tp_ops->write_devctl(hwif, ATA_DEVCTL_OBS);
>
> +#if defined(__mc68000__) && defined (CONFIG_BLK_DEV_FALCON_IDE)
> +       if (!MACH_IS_ATARI)
> +#endif
>        if (request_irq(hwif->irq, irq_handler, sa, hwif->name, hwif))
>                goto out_up;

Ugh, adding an m68k dependency in generic code is not nice...
Would it work to add a generic test for hwif->irq, and set hwif->irq to zero in
falconide.c?

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
--
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: [PATCH] m68k: Atari - leave out spurious request_irq for Falcon IDE

[Michael Schmitz]

Hi Geert,

> > I found I need to have this patch in order to avoid doubly registering the
> > ST-DMA interrupt for IDE on Falcon.
> 
> But further it has no ill effects, as it works fine on ARAnyM? Or does
> it fail on real hardware?

IDE reports lost interrupts at the same time as SCSI locks up, but that did 
happen before the patch the same as after. I'll re-check that if you like ...

And yes, the IDE/SCSI combination fails on real hardware. IDE remains alive, 
SCSI offlines the timed out device. ARAnyM has no SCSI driver...

	Michael

Re: [PATCH] m68k: Atari SCSI - ST-DMA locking and error handling fixes

[Geert Uytterhoeven]

On Sun, Apr 26, 2009 at 09:24, Michael Schmitz
<schmitz@biophys.uni-duesseldorf.de> wrote:
> some fixes to the Atari NCR5380 SCSI driver: if the ST-DMA lock cannot be taken
> in the queue function, indicate host busy to the block layer. Fix return codes
> of abort and reset functions, and add scsi_unregister to module exit.
> Error handling is still messed up, most likely due to missing ST-DMA lock in
> abort and reset. This is still WIP, but might benefit users with a Falcon less
> prone to SCSI lockups, i.e. more stable SCSI clock signal.

Any news on this one ("still WIP")?

> Signed-off-by: Michael Schmitz <schmitz@debian.org>
>
>  Michael
>
> ---
>  drivers/scsi/atari_NCR5380.c |   78 +++++++++++++++++++++++++++--------------
>  drivers/scsi/atari_scsi.c    |   47 +++++++++++++++++++++----
>  2 files changed, 91 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/scsi/atari_NCR5380.c b/drivers/scsi/atari_NCR5380.c
> index 0471f88..3ba46d5 100644
> --- a/drivers/scsi/atari_NCR5380.c
> +++ b/drivers/scsi/atari_NCR5380.c
> @@ -966,13 +966,6 @@ static int NCR5380_queue_command(Scsi_Cmnd *cmd, void (*done)(Scsi_Cmnd *))
>
>        cmd->result = 0;
>
> -       /*
> -        * Insert the cmd into the issue queue. Note that REQUEST SENSE
> -        * commands are added to the head of the queue since any command will
> -        * clear the contingent allegiance condition that exists and the
> -        * sense data is only guaranteed to be valid while the condition exists.
> -        */
> -
>        local_irq_save(flags);
>        /* ++guenther: now that the issue queue is being set up, we can lock ST-DMA.
>         * Otherwise a running NCR5380_main may steal the lock.
> @@ -987,10 +980,32 @@ static int NCR5380_queue_command(Scsi_Cmnd *cmd, void (*done)(Scsi_Cmnd *))
>         * alter queues and touch the lock.
>         */
>        if (!IS_A_TT()) {
> +               int rv;
> +               /* MSch: since we may now get called from softirq context here,
> +                * we cannot always sleep while waiting for the lock.
> +                * Use status from falcon_get_lock() to detect if the lock was
> +                * successfully taken, and return appropriate status to midlevel
> +                * otherwise.
> +                * We used to pause the midlevel SCSI timer here; races between
> +                * command timeout and lowlevel error handling should not hurt
> +                * because the command isn't in any of the queues yet.
> +                */
>                /* perhaps stop command timer here */
> -               falcon_get_lock();
> +               rv = falcon_get_lock();
>                /* perhaps restart command timer here */
> +               if (rv) {
> +                       local_irq_restore(flags);
> +                       return SCSI_MLQUEUE_HOST_BUSY;
> +               }
>        }
> +
> +       /*
> +        * Insert the cmd into the issue queue. Note that REQUEST SENSE
> +        * commands are added to the head of the queue since any command will
> +        * clear the contingent allegiance condition that exists and the
> +        * sense data is only guaranteed to be valid while the condition exists.
> +        */
> +
>        if (!(hostdata->issue_queue) || (cmd->cmnd[0] == REQUEST_SENSE)) {
>                LIST(cmd, hostdata->issue_queue);
>                SET_NEXT(cmd, hostdata->issue_queue);
> @@ -1014,10 +1029,12 @@ static int NCR5380_queue_command(Scsi_Cmnd *cmd, void (*done)(Scsi_Cmnd *))
>         * If we're not in an interrupt, we can call NCR5380_main()
>         * unconditionally, because it cannot be already running.
>         */
> -       if (in_interrupt() || ((flags >> 8) & 7) >= 6)
> +       /* As of 2.6.19, the coroutine has to be put on the task queue instead
> +        * of being called directly. It might still be called directly if not
> +        * in softirq, though. Need to test this.
> +        */
>                queue_main();
> -       else
> -               NCR5380_main(NULL);
> +
>        return 0;
>  }
>
> @@ -1463,6 +1480,7 @@ static int NCR5380_select(struct Scsi_Host *instance, Scsi_Cmnd *cmd, int tag)
>        ARB_PRINTK("scsi%d: arbitration complete\n", HOSTNO);
>
>        if (hostdata->connected) {
> +
>                NCR5380_write(MODE_REG, MR_BASE);
>                return -1;
>        }
> @@ -2065,7 +2083,6 @@ static void NCR5380_information_transfer(struct Scsi_Host *instance)
>                                /*
>                                 * The preferred transfer method is going to be
>                                 * PSEUDO-DMA for systems that are strictly PIO,
> -                                * since we can let the hardware do the handshaking.
>                                 *
>                                 * For this to work, we need to know the transfersize
>                                 * ahead of time, since the pseudo-DMA code will sit
> @@ -2631,7 +2648,7 @@ static void NCR5380_reselect(struct Scsi_Host *instance)
>  *     host byte of the result field to, if zero DID_ABORTED is
>  *     used.
>  *
> - * Returns : 0 - success, -1 on failure.
> + * Returns : SUCCESS - success, FAILED on failure.
>  *
>  * XXX - there is no way to abort the command that is currently
>  *      connected, you have to wait for it to complete.  If this is
> @@ -2701,11 +2718,12 @@ int NCR5380_abort(Scsi_Cmnd *cmd)
>                        local_irq_restore(flags);
>                        cmd->scsi_done(cmd);
>                        falcon_release_lock_if_possible(hostdata);
> -                       return SCSI_ABORT_SUCCESS;
> +                       return SUCCESS;
>                } else {
> -/*                     local_irq_restore(flags); */
> +                       /* not sure */
> +                       local_irq_restore(flags);
>                        printk("scsi%d: abort of connected command failed!\n", HOSTNO);
> -                       return SCSI_ABORT_ERROR;
> +                       return FAILED;
>                }
>        }
>  #endif
> @@ -2729,7 +2747,7 @@ int NCR5380_abort(Scsi_Cmnd *cmd)
>                         * yet... */
>                        tmp->scsi_done(tmp);
>                        falcon_release_lock_if_possible(hostdata);
> -                       return SCSI_ABORT_SUCCESS;
> +                       return SUCCESS;
>                }
>        }
>
> @@ -2747,7 +2765,7 @@ int NCR5380_abort(Scsi_Cmnd *cmd)
>        if (hostdata->connected) {
>                local_irq_restore(flags);
>                ABRT_PRINTK("scsi%d: abort failed, command connected.\n", HOSTNO);
> -               return SCSI_ABORT_SNOOZE;
> +               return FAILED;
>        }
>
>        /*
> @@ -2782,7 +2800,7 @@ int NCR5380_abort(Scsi_Cmnd *cmd)
>                        ABRT_PRINTK("scsi%d: aborting disconnected command.\n", HOSTNO);
>
>                        if (NCR5380_select(instance, cmd, (int)cmd->tag))
> -                               return SCSI_ABORT_BUSY;
> +                               return FAILED;
>
>                        ABRT_PRINTK("scsi%d: nexus reestablished.\n", HOSTNO);
>
> @@ -2809,7 +2827,7 @@ int NCR5380_abort(Scsi_Cmnd *cmd)
>                                        local_irq_restore(flags);
>                                        tmp->scsi_done(tmp);
>                                        falcon_release_lock_if_possible(hostdata);
> -                                       return SCSI_ABORT_SUCCESS;
> +                                       return SUCCESS;
>                                }
>                        }
>                }
> @@ -2835,7 +2853,9 @@ int NCR5380_abort(Scsi_Cmnd *cmd)
>         */
>        falcon_release_lock_if_possible(hostdata);
>
> -       return SCSI_ABORT_NOT_RUNNING;
> +       /* NCR5380 has FAILED here */
> +       /* return SUCCESS; */
> +       return FAILED;
>  }
>
>
> @@ -2844,16 +2864,18 @@ int NCR5380_abort(Scsi_Cmnd *cmd)
>  *
>  * Purpose : reset the SCSI bus.
>  *
> - * Returns : SCSI_RESET_WAKEUP
> + * Returns : SUCCESS
>  *
>  */
>
> +#undef FALCON_RESET_KILL_QUEUES
> +
>  static int NCR5380_bus_reset(Scsi_Cmnd *cmd)
>  {
>        SETUP_HOSTDATA(cmd->device->host);
>        int i;
>        unsigned long flags;
> -#if 1
> +#if defined(FALCON_RESET_KILL_QUEUES)
>        Scsi_Cmnd *connected, *disconnected_queue;
>  #endif
>
> @@ -2878,7 +2900,8 @@ static int NCR5380_bus_reset(Scsi_Cmnd *cmd)
>         * through anymore ... */
>        (void)NCR5380_read(RESET_PARITY_INTERRUPT_REG);
>
> -#if 1  /* XXX Should now be done by midlevel code, but it's broken XXX */
> +#if defined(FALCON_RESET_KILL_QUEUES)
> +       /* XXX Should now be done by midlevel code, but it's broken XXX */
>        /* XXX see below                                            XXX */
>
>        /* MSch: old-style reset: actually abort all command processing here */
> @@ -2934,7 +2957,7 @@ static int NCR5380_bus_reset(Scsi_Cmnd *cmd)
>         * the midlevel code that the reset was SUCCESSFUL, and there is no
>         * need to 'wake up' the commands by a request_sense
>         */
> -       return SCSI_RESET_SUCCESS | SCSI_RESET_BUS_RESET;
> +       return SUCCESS;
>  #else /* 1 */
>
>        /* MSch: new-style reset handling: let the mid-level do what it can */
> @@ -2982,6 +3005,7 @@ static int NCR5380_bus_reset(Scsi_Cmnd *cmd)
>        local_irq_restore(flags);
>
>        /* we did no complete reset of all commands, so a wakeup is required */
> -       return SCSI_RESET_WAKEUP | SCSI_RESET_BUS_RESET;
> -#endif /* 1 */
> +       /* The new error handler code implicitly does this for us anyway */
> +       return SUCCESS;
> +#endif /* defined(FALCON_RESET_KILL_QUEUES) */
>  }
> diff --git a/drivers/scsi/atari_scsi.c b/drivers/scsi/atari_scsi.c
> index ad7a23a..9ebfbc6 100644
> --- a/drivers/scsi/atari_scsi.c
> +++ b/drivers/scsi/atari_scsi.c
> @@ -196,7 +196,7 @@ static unsigned long atari_dma_xfer_len(unsigned long wanted_len,
>  static irqreturn_t scsi_tt_intr(int irq, void *dummy);
>  static irqreturn_t scsi_falcon_intr(int irq, void *dummy);
>  static void falcon_release_lock_if_possible(struct NCR5380_hostdata *hostdata);
> -static void falcon_get_lock(void);
> +static int falcon_get_lock(void);
>  #ifdef CONFIG_ATARI_SCSI_RESET_BOOT
>  static void atari_scsi_reset_boot(void);
>  #endif
> @@ -498,6 +498,16 @@ static int falcon_dont_release = 0;
>  * again (but others waiting longer more probably will win).
>  */
>
> +/*
> + * MSch 20061228: in 2.6.x, the fairness wait appears to open a race with
> + * concurrent use of the lock by the IDE driver. Once the lock is taken by
> + * IDE, the SCSI queuecmd function can no longer schedule because it is run
> + * from softirq context a lot.
> + * Disable the fairness wait until I have had time to sort out the lock issues.
> + */
> +#undef FALCON_FAIRNESS_WAIT
> +#define FALCON_NEVER_SLEEP 1
> +
>  static void falcon_release_lock_if_possible(struct NCR5380_hostdata *hostdata)
>  {
>        unsigned long flags;
> @@ -519,7 +529,9 @@ static void falcon_release_lock_if_possible(struct NCR5380_hostdata *hostdata)
>                }
>                falcon_got_lock = 0;
>                stdma_release();
> +#if defined(FALCON_FAIRNESS_WAIT)
>                wake_up(&falcon_fairness_wait);
> +#endif
>        }
>
>        local_irq_restore(flags);
> @@ -540,21 +552,37 @@ static void falcon_release_lock_if_possible(struct NCR5380_hostdata *hostdata)
>  * Complicated, complicated.... Sigh...
>  */
>
> -static void falcon_get_lock(void)
> +/* MSch 20061229: in order to avoid sleeping when the lock is not available,
> + * return the current lock state here. atari_queue_command() will then return
> + * with error, causing the midlevel code to pause request submission.
> + */
> +static int falcon_get_lock(void)
>  {
>        unsigned long flags;
>
>        if (IS_A_TT())
> -               return;
> +               return 0;
>
>        local_irq_save(flags);
>
> -       while (!in_irq() && falcon_got_lock && stdma_others_waiting())
> +#if defined(FALCON_FAIRNESS_WAIT)
> +       /* MSch: we may not sleep even while in softirq ! */
> +       while (!in_interrupt() && falcon_got_lock && stdma_others_waiting())
>                sleep_on(&falcon_fairness_wait);
> -
> +#endif
>        while (!falcon_got_lock) {
>                if (in_irq())
>                        panic("Falcon SCSI hasn't ST-DMA lock in interrupt");
> +               /* we may not sleep in soft interrupts neither, so bail out */
> +#if defined(FALCON_NEVER_SLEEP)
> +               if (stdma_islocked()) {
> +#else
> +               if (in_softirq() && stdma_islocked()) {
> +#endif
> +                       // printk(KERN_INFO "Falcon SCSI does not hold ST-DMA lock in softirq!\n" );
> +                       local_irq_restore(flags);
> +                       return 1;
> +               }
>                if (!falcon_trying_lock) {
>                        falcon_trying_lock = 1;
>                        stdma_lock(scsi_falcon_intr, NULL);
> @@ -569,6 +597,8 @@ static void falcon_get_lock(void)
>        local_irq_restore(flags);
>        if (!falcon_got_lock)
>                panic("Falcon SCSI: someone stole the lock :-(\n");
> +
> +       return 0;
>  }
>
>
> @@ -589,7 +619,7 @@ int atari_queue_command(Scsi_Cmnd *cmd, void (*done)(Scsi_Cmnd *))
>  #endif
>
>
> -int __init atari_scsi_detect(struct scsi_host_template *host)
> +int atari_scsi_detect(struct scsi_host_template *host)
>  {
>        static int called = 0;
>        struct Scsi_Host *instance;
> @@ -652,6 +682,8 @@ int __init atari_scsi_detect(struct scsi_host_template *host)
>                }
>                atari_dma_phys_buffer = virt_to_phys(atari_dma_buffer);
>                atari_dma_orig_addr = 0;
> +               printk(KERN_ERR "atari_scsi_detect: ST-RAM "
> +                       "double buffer at %p\n", atari_dma_phys_buffer);
>        }
>  #endif
>        instance = scsi_register(host, sizeof(struct NCR5380_hostdata));
> @@ -745,6 +777,7 @@ int atari_scsi_release(struct Scsi_Host *sh)
>  {
>        if (IS_A_TT())
>                free_irq(IRQ_TT_MFP_SCSI, sh);
> +       scsi_unregister(atari_scsi_host);
>        if (atari_dma_buffer)
>                atari_stram_free(atari_dma_buffer);
>        return 1;
> @@ -828,7 +861,7 @@ int atari_scsi_bus_reset(Scsi_Cmnd *cmd)
>        } else {
>                atari_turnon_irq(IRQ_MFP_FSCSI);
>        }
> -       if ((rv & SCSI_RESET_ACTION) == SCSI_RESET_SUCCESS)
> +       if (rv == SUCCESS)
>                falcon_release_lock_if_possible(hostdata);
>
>        return rv;
> --
> 1.5.6.5
>
>



-- 
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

[PATCH] m68k: Atari SCC verbosity fix

[Michael Schmitz]

Fix verbosity level of SCC driver (leftover 'info' message) as reported by 
Patrice Mandin.

Signed-off-by: Michael Schmitz <schmitz@debian.org>
---
 drivers/char/atari_scc.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/char/atari_scc.c b/drivers/char/atari_scc.c
index 2bbd44c..7d7abe5 100644
--- a/drivers/char/atari_scc.c
+++ b/drivers/char/atari_scc.c
@@ -1351,7 +1351,7 @@ static int scc_open(struct tty_struct *tty, struct file *filp)
 	pr_debug(KERN_WARNING "SCC: enable rx ints ...\n");
 	scc_enable_rx_interrupts(port);
 	pr_debug(KERN_WARNING "SCC: enable rx ints done!\n");
-	pr_info("SCC: open port done!\n");
+	pr_debug("SCC: open port done!\n");
 	return 0;
 }
 
-- 
1.5.6.5

Re: [PATCH] m68k: Atari SCC verbosity fix

[Geert Uytterhoeven]

On Sun, Apr 19, 2009 at 03:24, Michael Schmitz
<schmitz@biophys.uni-duesseldorf.de> wrote:
> Fix verbosity level of SCC driver (leftover 'info' message) as reported by
> Patrice Mandin.

Thanks, added.

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: debian kernel m68k patches for 2.6.29

[Stephen R Marenka]

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

On Sun, Mar 29, 2009 at 03:07:57PM +0200, Geert Uytterhoeven wrote:
> On Thu, Mar 26, 2009 at 15:10, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Thu, Mar 26, 2009 at 13:38, Stephen R Marenka <stephen@marenka.net> wrote:
> >> So 2.6.29 has hit sid. Anyone want to update the kernel patches? Also,
> >> what patches to apply now that we have git-based goodness?
> >
> > You can start with the ones on the for-next branch.
> > I still have to cherry-pick the others to the (to be created) queue branch.
> > I'll let you know when I'm finished.
> 
> Now my git skills have been growing, I created two new branches:
>   - m68k-v2.6.29
>   - queue

That pretty much rocks! Here's my process in case someone else wants
it or wants to fix it. :)

The only downside seems to be the 47 patch difference between m68k
and the point release or whatever else happened on top of 2.6.29. 
Those pretty much all conflicted.

I just pushed the patches for debian 2.6.29-4.

http://wiki.debian.org/M68k/Kernel/Patches

Thanks,

Stephen

-- 
Stephen R. Marenka     If life's not fun, you're not doing it right!
<stephen@marenka.net>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: debian kernel m68k patches for 2.6.29

[Geert Uytterhoeven]

On Tue, Apr 21, 2009 at 19:20, Stephen R Marenka <stephen@marenka.net> wrote:
> On Sun, Mar 29, 2009 at 03:07:57PM +0200, Geert Uytterhoeven wrote:
>> On Thu, Mar 26, 2009 at 15:10, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> > On Thu, Mar 26, 2009 at 13:38, Stephen R Marenka <stephen@marenka.net> wrote:
>> >> So 2.6.29 has hit sid. Anyone want to update the kernel patches? Also,
>> >> what patches to apply now that we have git-based goodness?
>> >
>> > You can start with the ones on the for-next branch.
>> > I still have to cherry-pick the others to the (to be created) queue branch.
>> > I'll let you know when I'm finished.
>>
>> Now my git skills have been growing, I created two new branches:
>>   - m68k-v2.6.29
>>   - queue
>
> That pretty much rocks! Here's my process in case someone else wants
> it or wants to fix it. :)
>
> The only downside seems to be the 47 patch difference between m68k
> and the point release or whatever else happened on top of 2.6.29.
> Those pretty much all conflicted.

Yeah, that was my biggest fear. I'll refrain from merging any stable
revisions in the
future.

> I just pushed the patches for debian 2.6.29-4.
>
> http://wiki.debian.org/M68k/Kernel/Patches

A few comments:
  - If you cloned from linux-m68k.git, you don't have to do the `git
remote add',
    as `origin' is already the same remote.
  - You may want to put a `sort' in the `find ../bugfix/m68k/2.6.29
-print | sed -e 's;../;+ ;' | sed -e 's;$; m68k;' >> $series`
    pipeline.

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
--
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: debian kernel m68k patches for 2.6.29

[Stephen R Marenka]

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

On Wed, Apr 22, 2009 at 09:20:31AM +0200, Geert Uytterhoeven wrote:
> On Tue, Apr 21, 2009 at 19:20, Stephen R Marenka <stephen@marenka.net> wrote:

> > http://wiki.debian.org/M68k/Kernel/Patches
> 
> A few comments:
>   - If you cloned from linux-m68k.git, you don't have to do the `git
> remote add',
>     as `origin' is already the same remote.

Added.

>   - You may want to put a `sort' in the `find ../bugfix/m68k/2.6.29
> -print | sed -e 's;../;+ ;' | sed -e 's;$; m68k;' >> $series`
>     pipeline.

The patches come out numbered 0001-0090. I'm not sure what I can sort.

Thanks,

Stephen

-- 
Stephen R. Marenka     If life's not fun, you're not doing it right!
<stephen@marenka.net>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: debian kernel m68k patches for 2.6.29

[Geert Uytterhoeven]

On Wed, Apr 22, 2009 at 14:57, Stephen R Marenka <stephen@marenka.net> wrote:
> On Wed, Apr 22, 2009 at 09:20:31AM +0200, Geert Uytterhoeven wrote:
>> On Tue, Apr 21, 2009 at 19:20, Stephen R Marenka <stephen@marenka.net> wrote:
>
>> > http://wiki.debian.org/M68k/Kernel/Patches

>>   - You may want to put a `sort' in the `find ../bugfix/m68k/2.6.29
>> -print | sed -e 's;../;+ ;' | sed -e 's;$; m68k;' >> $series`
>>     pipeline.
>
> The patches come out numbered 0001-0090. I'm not sure what I can sort.

The numbers ;-) `find' is not guaranteed to return them in order.

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
--
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: debian kernel m68k patches for 2.6.29

[Stephen R Marenka]

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

On Wed, Apr 22, 2009 at 03:41:31PM +0200, Geert Uytterhoeven wrote:
> On Wed, Apr 22, 2009 at 14:57, Stephen R Marenka <stephen@marenka.net> wrote:
> > On Wed, Apr 22, 2009 at 09:20:31AM +0200, Geert Uytterhoeven wrote:
> >> On Tue, Apr 21, 2009 at 19:20, Stephen R Marenka <stephen@marenka.net> wrote:
> >
> >> > http://wiki.debian.org/M68k/Kernel/Patches
> 
> >>   - You may want to put a `sort' in the `find ../bugfix/m68k/2.6.29
> >> -print | sed -e 's;../;+ ;' | sed -e 's;$; m68k;' >> $series`
> >>     pipeline.
> >
> > The patches come out numbered 0001-0090. I'm not sure what I can sort.
> 
> The numbers ;-) `find' is not guaranteed to return them in order.

Color me an idiot. You are correct. :)

Thanks!

Stephen

-- 
Stephen R. Marenka     If life's not fun, you're not doing it right!
<stephen@marenka.net>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]