So far, so good as far as the >16 disk problem goes. I applied the patch and
am now running an AIM VII file server bench on the system. I'll let y'all know
if there are any interesting performance differences between this and the
results we got on 2.3.29. Cool! :)
- Pete
Eric Youngdale wrote:
> I have figured out a couple more of the open issues. I *believe* that this
> may correct all of the outstanding issues as of last night (details below),
> that is of course assuming that the patches themselves don't break anything.
> Also, I am flying a little blind here, as I cannot test live kernels until I
> get back home from Christmas, so I don't want to forward patches to Linus
> until I get good feedback from a number of people.
>
> I am enclosing cumulative diffs against 2.3.34.
>
> 1) The problem with HIGHMEM is that in ll_rw_blk.c we are automatically
> getting a bounce buffer, but from this it is impossible to do queue
> management to combine requests. I simply added some code to dereference the
> thing. The fix is a bit of a hack, but I don't completely understand
> HIGHMEM anyways, so this will do for now, I guess.
>
> 2) Some people were reporting problems scanning the bus with ppa and imm
> host adapters. The problem here was that I was incrementing the host usage
> count too soon, and thus hosts that could only queue a single command would
> deadlock attempting to scan the bus. I think I have fixed this - it was a
> relic of the old way of doing things (and a maintainence problem as well) to
> bump the usage count in two separate functions. I moved this over so that
> it is all done in the same place now. There is a danger that I missed
> something here, and thus there is a slight possibility that usage counts
> will get out of synch and the system will wedge.
>
> 3) The problem involving > 16 disks was a weird one. The symptom was that
> ext2 didn't recognize the superblock, and as a result it went onto the next
> filesystem - iso9660 in this case. There were spew messages on the console
> complaining about the fact that the disk drive didn't support multi-session.
> There were actually two bugs - the first one I had fixed some time ago. I
> am not 100% certain that I have fixed the second bug, but I believe the
> underlying problem was caused by the incorrect usage of the MINOR() macro in
> sd.c. Whether or not this fully corrects the problem, the second thing was
> a real bug.
>
> 4) I fixed a bug in a previous patch which would have probably led to
> spurious messages about running low on DMA memory.
>
> -Eric
>
> ------------------------------------------------------------------------
> Name: linux34.diff
> linux34.diff Type: unspecified type (application/octet-stream)
> Encoding: quoted-printable
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
