Based on something I did for the xserver specfile. Essentially this
makes it so you only have to name the patches once, in the order you
want to apply them, which makes it both easier to work with and harder
to forget things.
I've tried to make this as friendly and robust as possible, including
bailing out appropriately when faced with a bad patch, and explicitly
naming patches that fail to apply right at the end of build output.
Feedback would be appreciated, even if it's of the form "no, that's
Bonjour, excusez-moi de vous importuner, j'ai besoin de votre assistance dans la transaction de la somme de dix millions sept cents mille dollars américains. Je vais vous donner 20% en contrepartie. Pour plus de détails, veuillez me recontacter. Merci.
Reply to your messages and manage your action items at Xianz
This message has been automatically generated by Xianz
Please do not reply to this message.
Xianz.com - Friends Faith Fellowship
First of all sorry for the somewhat massive cross-posting, I've spend a
significant amount of time hunting down this bug, and so far the response has
been less the overwhelming.
The problem is with the HP PSC 1350 (my printer and confirmed by 2 others) and
atleast also the HP PSC 1610 (confirmed by Guillaume Bedot, in the CC).
The cardreader of the multi function printers will "crash" and from that moment
on no longer communicate in any sane way, if you try to read the last sector of
an sdcard* in a read that is more then 1 sector, so trying to read 8 sectors
starting at sector capicity-8 will crash it, as will reading 2 sectors starting
at sector capicity-2, however reading the last sector in a one 1 sector read
will succeed! (* xdcards seem to be fine).
I haven't tried if it will crash on larger then 1 sector writes which include
the last sector too, I immediately added code to not do that in both the read
and write paths. I have tested reading and writing the end of the disk with
this kludge in and it works.
I currently have a somewhat ugly proof of concept patch for this, which adds
another type of usb-massstorage quirk. When this quirk flag is set, the
usb-massstorage driver modifies READ_10 and WRITE_10 commands of more then 1
sector which includes the last sector to become one sector less. I've been told
by scsi subsystem developers that doing a shorter read / write then requested
is not a problem, the scsi subsystem is designed to handle getting less then it
asked for and will send a seperate request for the last sector.
I and 3 others (2 on a PSC 1350 too, one on a PSC1610) have tested this patch
with success. I'm not asking for this patch to be included to the kernel as is,
I'm asking for the now known workaround for this to be added to the kernel in
Perhaps its an idea to add the posibility to have a scsi command filter
function / callback to the scsi or usb-massstorage subsystem, and then add a
mechanism to set this filter depending on usb id's and if added to the scsi
layer, a mechanism to set it based on scsi device and manufacturer
identification strings. Such a mechanism might be usefull in the future to work
around other broken hardware too, and has the added advantage of not having
todo much changes to the normal code path, keep that readable.
I'm willing to come up with a patch for such a filter mechanism, provided I get
some pointers where this is best added.
Thanks & Regards,
I've also included the fedora-kernel list in the addressee's because I was
hoping that maybe someone can take one of these printers to the kernel hackfest
in the weekend's fudcon and take a look at this.
I downloaded kernel-184.108.40.206-113.fc8 from koji and wanted to boot it on
my NF4 SLI / Opteron 170 based box (x86_64) and the system reboots
immediately when booting this kernel.
I was using 220.127.116.11-99.fc8 before which is working fine.
I suspect that this "Set x86 CONFIG_PHYSICAL_START=0x400000" change
caused the breakage; currently I am downloading the srpm to verify that
this indeed was causing it (the other changes look unreleated) before
filling a bug.
What was this supposed to fix/improve ?
I noticed that config-x86 and config-x86_64 both have tpm_infineon=m but
config-ia64 does not. I enabled that on my system and rebuild the
kernel rpm and everything just worked. Could tpm_infineon be built as a
module by default for ia64?
Couple of PowerPC related config things we might want to change.
1) CONFIG_TUNE_CELL. Right now, this is set to Y on config-powerpc64.
That's fine only because it doesn't do anything until GCC 4.3 shows
up. GCC 4.3 will hit rawhide soon, and we might want to turn this off
before then or the kernel will likely run slower on non-Cell CPU based
2) Why are we still building a separate powerpc32-smp kernel? SMP
kernel's work on UP machines, even for PowerPC IIRC.