Messages in this thread | | | Date | Tue, 21 Aug 2001 06:58:09 -0700 (PDT) | Subject | Re: Qlogic/FC firmware | From | "David S. Miller" <> |
| |
From: Jes Sorensen <jes@sunsite.dk> Date: 21 Aug 2001 15:51:55 +0200
The much cleaner way to solve this problem is to write a user space tool to upgrade the image in the flash ram on the QL with your latest favorite image found at www.qlogic.com. It's a 128KB image, you can write directly to the flash in two banks by setting the read/write bit and setting the 2nd bank bit for the last 64KB.
When the Qlogic,FC sees a master abort, the firmware is essentially cleared to zero.
This is what was happening to me.
Now what if I cannot boot now because this was on my root block device. I cannot even go back to a previous rev of the kernel I was working on to get it back.
If you're going to say "put the user thing in initrd", I'm going to say "bite me". I build a static kernel with no initrd and that is how I'd like it to stay. It is one thing to do initrd firmware loading for devices not necessary for booting and mounting root, that is acceptable, this isn't.
Jes, I think your arguments are wrong. I think the driver should have been removed in whole and replaced with something like this in qlogicfc.c so everyone would know what the problem is:
/* This driver was removed due to licensing in the firmware * which conflicts with the GPL. The driver is only really * fully functional with the firmware included, so instead of * breaking half of the qlogic/fc users out there we removed * this driver outright. */
I would have never sent out the email which started this thread had this been done. I would not have questioned anything, and would have instead said "unfortunate" to myself and left it at that.
Later, David S. Miller davem@redhat.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |