From: Brian M. <bm...@ne...> - 2004-05-25 13:10:30
|
A few people asked for the kernel patch I used to get my iRiver to mount under Linux. The first thing is to read the following page: https://nirodha.ath.cx/ifp-590t-linux.txt I don't know the person, but it's basically the path I followed. The only trick was his patch was for kernel 2.6.4, It didn't work for 2.6.5 or 2.6.6; things had changed a little and 3 hunks didn't apply. So here's my very first kernel patch, and I hope it works for you on your 2.6.6 kernel. --------------- CUT HERE ------------------ --- linux-2.6.6-clean/include/scsi/scsi_devinfo.h Mon May 10 12:31:58 2004 +++ linux-2.6.6/include/scsi/scsi_devinfo.h Thu May 20 22:48:11 2004 @@ -20,4 +20,5 @@ #define BLIST_MS_SKIP_PAGE_3F 0x4000 /* do not send ms page 0x3f */ #define BLIST_USE_10_BYTE_MS 0x8000 /* use 10 byte ms before 6 byte ms */ #define BLIST_MS_192_BYTES_FOR_3F 0x10000 /* 192 byte ms page 0x3f request */ +#define BLIST_NORMB 0x10000 /* Known to be not removable */ #endif --- linux-2.6.6-clean/drivers/scsi/scsi_scan.c Mon May 10 12:33:13 2004 +++ linux-2.6.6/drivers/scsi/scsi_scan.c Thu May 20 22:46:01 2004 @@ -554,7 +554,8 @@ scsi_device_set_state(sdev, SDEV_OFFLINE); } - sdev->removable = (0x80 & inq_result[1]) >> 7; + sdev->removable = (((0x80 & inq_result[1]) >> 7) && + !(*bflags & BLIST_NORMB)); sdev->lockable = sdev->removable; sdev->soft_reset = (inq_result[7] & 1) && ((inq_result[3] & 7) == 2); --- linux-2.6.6-clean/drivers/scsi/scsi_devinfo.c Mon May 10 12:32:27 2004 +++ linux-2.6.6/drivers/scsi/scsi_devinfo.c Thu May 20 22:49:29 2004 @@ -183,6 +183,7 @@ {"TOSHIBA", "CDROM", NULL, BLIST_ISROM}, {"TOSHIBA", "CD-ROM", NULL, BLIST_ISROM}, {"XYRATEX", "RS", "*", BLIST_SPARSELUN | BLIST_LARGELUN}, + {"iRiver", "iFP Mass Driver", NULL, BLIST_NORMB}, {"Zzyzx", "RocketStor 500S", NULL, BLIST_SPARSELUN}, {"Zzyzx", "RocketStor 2000", NULL, BLIST_SPARSELUN}, { NULL, NULL, NULL, 0 }, ------------------------ CUT HERE --------------------------------- I applied it with the following commands: $ cd /usr/src/linux $ patch -p1 < /path/to/patch-file Brian Miller |
From: Tobias L. <lit...@gm...> - 2004-05-25 14:57:33
|
hi the first patch, which works up to 2.6.4 ist from a developper who develops the kernel yesterday i wrote a mail to the author of the ums-tutorial with a patch too. Tobias Lieber On Tue, 25 May 2004 23:10:22 +1000 Brian Miller <bm...@ne...> wrote: > A few people asked for the kernel patch I used to get my iRiver to mount > under Linux. > > The first thing is to read the following page: > > https://nirodha.ath.cx/ifp-590t-linux.txt > > I don't know the person, but it's basically the path I followed. > > The only trick was his patch was for kernel 2.6.4, It didn't work for > 2.6.5 or 2.6.6; things had changed a little and 3 hunks didn't apply. So > here's my very first kernel patch, and I hope it works for you on your > 2.6.6 kernel. > > --------------- CUT HERE ------------------ > --- linux-2.6.6-clean/include/scsi/scsi_devinfo.h Mon May 10 > 12:31:58 2004 > +++ linux-2.6.6/include/scsi/scsi_devinfo.h Thu May 20 22:48:11 2004 > @@ -20,4 +20,5 @@ > #define BLIST_MS_SKIP_PAGE_3F 0x4000 /* do not send ms page 0x3f */ > #define BLIST_USE_10_BYTE_MS 0x8000 /* use 10 byte ms before 6 byte > ms */ > #define BLIST_MS_192_BYTES_FOR_3F 0x10000 /* 192 byte ms page > 0x3f request */ > +#define BLIST_NORMB 0x10000 /* Known to be not removable */ > #endif > --- linux-2.6.6-clean/drivers/scsi/scsi_scan.c Mon May 10 12:33:13 2004 > +++ linux-2.6.6/drivers/scsi/scsi_scan.c Thu May 20 22:46:01 2004 > @@ -554,7 +554,8 @@ > scsi_device_set_state(sdev, SDEV_OFFLINE); > } > > - sdev->removable = (0x80 & inq_result[1]) >> 7; > + sdev->removable = (((0x80 & inq_result[1]) >> 7) && > + !(*bflags & BLIST_NORMB)); > sdev->lockable = sdev->removable; > sdev->soft_reset = (inq_result[7] & 1) && ((inq_result[3] & 7) > == 2); > > --- linux-2.6.6-clean/drivers/scsi/scsi_devinfo.c Mon May 10 > 12:32:27 2004 > +++ linux-2.6.6/drivers/scsi/scsi_devinfo.c Thu May 20 22:49:29 2004 > @@ -183,6 +183,7 @@ > {"TOSHIBA", "CDROM", NULL, BLIST_ISROM}, > {"TOSHIBA", "CD-ROM", NULL, BLIST_ISROM}, > {"XYRATEX", "RS", "*", BLIST_SPARSELUN | BLIST_LARGELUN}, > + {"iRiver", "iFP Mass Driver", NULL, BLIST_NORMB}, > {"Zzyzx", "RocketStor 500S", NULL, BLIST_SPARSELUN}, > {"Zzyzx", "RocketStor 2000", NULL, BLIST_SPARSELUN}, > { NULL, NULL, NULL, 0 }, > ------------------------ CUT HERE --------------------------------- > > I applied it with the following commands: > > $ cd /usr/src/linux > $ patch -p1 < /path/to/patch-file > > Brian Miller > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > Ifp-driver-common mailing list > Ifp...@li... > https://lists.sourceforge.net/lists/listinfo/ifp-driver-common |
From: P. <or...@fo...> - 2004-05-25 18:09:09
|
Brian Miller (bm...@ne...) wrote: > The only trick was his patch was for kernel 2.6.4, It didn't work for > 2.6.5 or 2.6.6; things had changed a little and 3 hunks didn't apply. So > here's my very first kernel patch, and I hope it works for you on your > 2.6.6 kernel. > Hello, I've manually added the changes to the kernel source quite a few times now since the 2.6 has been released in new flavours. The patches that are lying around often doesn't apply since I use the kernel source that Debian has in their archives. Therefor I would just like to know, why hasn't this been fixed upstream? Are the iRiver's considered broken, or is the USB mass storage support attacked by bugs? I recall that I read somewhere that the kernel developers had been informed about this, so one could wonder why we still need to pretend to be kernel hackers. (Tho, who doesn't like the feeling of modifying it's own OS' source code in it's favorite editor? :)) Örjan |
From: Tobias L. <lit...@gm...> - 2004-05-25 18:41:17
|
hi the first patch was on the linux kernel mailing list. so the developers sho= uld now the problem. and if i remember right, it is not a problem with the = scsi module, where this patch patches, i think i read it is a problem with = the ums driver from kernel 2.6 Tobias Lieber On Tue, 25 May 2004 20:08:57 +0200 =D6rjan Persson <or...@fo...> wrote: > Brian Miller (bm...@ne...) wrote: > > The only trick was his patch was for kernel 2.6.4, It didn't work for=20 > > 2.6.5 or 2.6.6; things had changed a little and 3 hunks didn't apply. S= o=20 > > here's my very first kernel patch, and I hope it works for you on your= =20 > > 2.6.6 kernel. > >=20 >=20 > Hello, >=20 > I've manually added the changes to the kernel source quite a few times > now since the 2.6 has been released in new flavours. The patches that > are lying around often doesn't apply since I use the kernel source that > Debian has in their archives. Therefor I would just like to know, why > hasn't this been fixed upstream? Are the iRiver's considered broken, or > is the USB mass storage support attacked by bugs? >=20 > I recall that I read somewhere that the kernel developers had been > informed about this, so one could wonder why we still need to pretend to > be kernel hackers. (Tho, who doesn't like the feeling of modifying it's > own OS' source code in it's favorite editor? :)) >=20 > =D6rjan >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g.= =20 > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick > _______________________________________________ > Ifp-driver-common mailing list > Ifp...@li... > https://lists.sourceforge.net/lists/listinfo/ifp-driver-common |
From: Javier M. <li...@ma...> - 2004-05-26 19:34:58
Attachments:
015_iriver_NORMB.patch
|
* Brian Miller <bm...@ne...> [040525 15:15]: >A few people asked for the kernel patch I used to get my iRiver to mount >under Linux. >The first thing is to read the following page: > https://nirodha.ath.cx/ifp-590t-linux.txt >I don't know the person, but it's basically the path I followed. >The only trick was his patch was for kernel 2.6.4, It didn't work for >2.6.5 or 2.6.6; things had changed a little and 3 hunks didn't apply. So >here's my very first kernel patch, and I hope it works for you on your >2.6.6 kernel. That person was me. I wrote it for kernel 2.6.3, indeed, but in 2.6.4 there were no changes which affected it one or other way. Those came in 2.6.5 as you correctly said... However, although you apparently fixed the rejects -it is not rejected anymore-, you missed the most important bit in the patch, which must be changed for 2.6.5+, although very slightly: >--------------- CUT HERE ------------------ >--- linux-2.6.6-clean/include/scsi/scsi_devinfo.h Mon May 10 >12:31:58 2004 >+++ linux-2.6.6/include/scsi/scsi_devinfo.h Thu May 20 22:48:11 2004 >@@ -20,4 +20,5 @@ >#define BLIST_MS_SKIP_PAGE_3F 0x4000 /* do not send ms page 0x3f */ >#define BLIST_USE_10_BYTE_MS 0x8000 /* use 10 byte ms before 6 byte >ms */ >#define BLIST_MS_192_BYTES_FOR_3F 0x10000 /* 192 byte ms page ~~~~~~~ >0x3f request */ >+#define BLIST_NORMB 0x10000 /* Known to be not removable */ ~~~~~~~ >#endif Ok, do you see the two bitmasks I marked above? They MUST be different, I had made 0x100000 up for the BLIST_NORMB flag I wrote for iRiver devices, but since that valu is already used we must go to the next one, 0x12000. Hence, the right patch for 2.6.5+ -I'm using 2.6.6 right now-, is as I attach to this e-mail :) Happy iRiver ing :) P.S Brian, I haven't read your document explaining how to do it, but in the coming days I'll try to put online the patch with instructions and some other tips, which might well be FAQ, if added together :) If anyone is willing to give a hand and is good with web design we might put some pictures and make it nice-looking too. -- Smear the road with a runner!! Javier Marcet <ja...@ma...> |
From: Tobias L. <lit...@gm...> - 2004-05-26 21:05:36
|
hi i have changed the patch from javier Marcet to 2.6.6 in the Tutuorial: https://nirodha.ath.cx/ifp-590t-linux.txt so i have one question why you write: +#define BLIST_NORMB 0x12000 /* Known to be not removable */ i wrote: +#define BLIST_NORMB 0x20000 /* Known to be not removable */ i thought this way: the 0x..... are hex-values. If you calculate them to the deceimal system, each following decimal-value is the last deciaml-value muliplied with 2. so i multiplied 0x10000, which is nothing other than 65536 with 2 and my result was 131072, which is in hex: 0x20000. but your 0x12000 is in decimal-system 73728. so is there any matter, why you broke this sequence? And what is interesting to me: why was this patch not included into the Kernel, instead of posting it on lkml? Tobias Lieber On Wed, 26 May 2004 21:33:39 +0200 Javier Marcet <li...@ma...> wrote: > * Brian Miller <bm...@ne...> [040525 15:15]: > > >A few people asked for the kernel patch I used to get my iRiver to mount > >under Linux. > >The first thing is to read the following page: > > > https://nirodha.ath.cx/ifp-590t-linux.txt > > >I don't know the person, but it's basically the path I followed. > > >The only trick was his patch was for kernel 2.6.4, It didn't work for > >2.6.5 or 2.6.6; things had changed a little and 3 hunks didn't apply. So > >here's my very first kernel patch, and I hope it works for you on your > >2.6.6 kernel. > > That person was me. I wrote it for kernel 2.6.3, indeed, but in 2.6.4 > there were no changes which affected it one or other way. Those came in > 2.6.5 as you correctly said... > However, although you apparently fixed the rejects -it is not rejected > anymore-, you missed the most important bit in the patch, which must be > changed for 2.6.5+, although very slightly: > > >--------------- CUT HERE ------------------ > >--- linux-2.6.6-clean/include/scsi/scsi_devinfo.h Mon May 10 > >12:31:58 2004 > >+++ linux-2.6.6/include/scsi/scsi_devinfo.h Thu May 20 22:48:11 2004 > >@@ -20,4 +20,5 @@ > >#define BLIST_MS_SKIP_PAGE_3F 0x4000 /* do not send ms page 0x3f */ > >#define BLIST_USE_10_BYTE_MS 0x8000 /* use 10 byte ms before 6 byte > >ms */ > >#define BLIST_MS_192_BYTES_FOR_3F 0x10000 /* 192 byte ms page > ~~~~~~~ > >0x3f request */ > >+#define BLIST_NORMB 0x10000 /* Known to be not removable */ > ~~~~~~~ > >#endif > > Ok, do you see the two bitmasks I marked above? They MUST be different, > I had made 0x100000 up for the BLIST_NORMB flag I wrote for iRiver > devices, but since that valu is already used we must go to the next one, > 0x12000. Hence, the right patch for 2.6.5+ -I'm using 2.6.6 right now-, > is as I attach to this e-mail :) > > Happy iRiver ing :) > > P.S Brian, I haven't read your document explaining how to do it, but in > the coming days I'll try to put online the patch with instructions and > some other tips, which might well be FAQ, if added together :) > If anyone is willing to give a hand and is good with web design we might > put some pictures and make it nice-looking too. > > > -- > Smear the road with a runner!! > > Javier Marcet <ja...@ma...> > |
From: Javier M. <li...@ma...> - 2004-05-26 21:43:31
|
* Tobias Lieber <lit...@gm...> [040526 23:11]: >i have changed the patch from javier Marcet to 2.6.6 in the Tutuorial: https://nirodha.ath.cx/ifp-590t-linux.txt :) >so i have one question why you write: >+#define BLIST_NORMB 0x12000 /* Known to be not removable */ >i wrote: >+#define BLIST_NORMB 0x20000 /* Known to be not removable */ How come? You did not write 0x20000 but 0x10000 which in 2.6.5+ kernels is used by the mew flag BLIST_MS_192_BYTES_FOR_3F. Had you written 0x20000, it would be working fine, you simply would not be using the same step every other flag on th header file uses... >i thought this way: the 0x..... are hex-values. If you calculate them to the deceimal system, each following decimal-value is the last deciaml-value muliplied with 2. so i multiplied 0x10000, which is nothing other than 65536 with 2 and my result was 131072, which is in hex: 0x20000. but your 0x12000 is in decimal-system 73728. so is there any matter, why you broke this sequence? I did not. I'll explain. What matters here is the number in binary base, since it'll be used for bit-AND, bit-OR, or/and bit-XOR operations. If you convert the numbers (in hexadecimal base) to binary base, you'll see they do indeed follow order: 0001, 0010, 0100, ... -- <dhd> perl < /dev/bdsm <knghtbrd> you have a /dev/bdsm? <dhd> sure, it's a pseudosadomasochistic random number generator Javier Marcet <ja...@ma...> |
From: Tobias L. <lit...@gm...> - 2004-05-26 23:04:14
|
On Wed, 26 May 2004 23:43:30 +0200 Javier Marcet <li...@ma...> wrote: Hi > * Tobias Lieber <lit...@gm...> [040526 23:11]: > > >i have changed the patch from javier Marcet to 2.6.6 in the Tutuorial: https://nirodha.ath.cx/ifp-590t-linux.txt > > :) > > >so i have one question why you write: > >+#define BLIST_NORMB 0x12000 /* Known to be not removable */ > > >i wrote: > >+#define BLIST_NORMB 0x20000 /* Known to be not removable */ > > How come? You did not write 0x20000 but 0x10000 which in 2.6.5+ kernels > is used by the mew flag BLIST_MS_192_BYTES_FOR_3F. > Had you written 0x20000, it would be working fine, you simply would not > be using the same step every other flag on th header file uses... i wrote 0x20000: i quote from the text file: -----quote---- If you have 2.6.6, Tobias Lieber runs to the rescue. Here's a patch sent by him for 2.6.6: ===============================================8< snip=============== --- linux-2.6.6/include/scsi/scsi_devinfo.h 2004-05-10 04:31:58.000000000 +0200 +++ /usr/src/linux/include/scsi/scsi_devinfo.h 2004-05-24 23:39:05.000000000 +0200 @@ -20,4 +20,5 @@ #define BLIST_MS_SKIP_PAGE_3F 0x4000 /* do not send ms page 0x3f */ #define BLIST_USE_10_BYTE_MS 0x8000 /* use 10 byte ms before 6 byte ms */ #define BLIST_MS_192_BYTES_FOR_3F 0x10000 /* 192 byte ms page 0x3f request */ +#define BLIST_NORMB 0x20000 /* Known to be not removable*/ i think this is 0x20000, is it? #endif --- linux-2.6.6/drivers/scsi/scsi_scan.c 2004-05-10 04:33:13.000000000 +0200 +++ /usr/src/linux/drivers/scsi/scsi_scan.c 2004-05-24 23:44:01.000000000 +0200 @@ -554,7 +554,8 @@ scsi_device_set_state(sdev, SDEV_OFFLINE); } - sdev->removable = (0x80 & inq_result[1]) >> 7; + sdev->removable = (((0x80 & inq_result[1]) >> 7) && +!(*bflags & BLIST_NORMB)); sdev->lockable = sdev->removable; sdev->soft_reset = (inq_result[7] & 1) && ((inq_result[3] & 7) == 2); --- linux-2.6.6/drivers/scsi/scsi_devinfo.c 2004-05-10 04:32:27.000000000 +0200 +++ /usr/src/linux/drivers/scsi/scsi_devinfo.c 2004-05-24 23:45:05.000000000 +0200 @@ -183,6 +183,7 @@ {"TOSHIBA", "CDROM", NULL, BLIST_ISROM}, {"TOSHIBA", "CD-ROM", NULL, BLIST_ISROM}, {"XYRATEX", "RS", "*", BLIST_SPARSELUN | BLIST_LARGELUN}, + {"iRiver", "iFP Mass Driver", NULL, BLIST_NORMB}, {"Zzyzx", "RocketStor 500S", NULL, BLIST_SPARSELUN}, {"Zzyzx", "RocketStor 2000", NULL, BLIST_SPARSELUN}, { NULL, NULL, NULL, 0 }, ===============================================8< snip=============== -----end------ > >i thought this way: the 0x..... are hex-values. If you calculate them to the deceimal system, each following decimal-value is the last deciaml-value muliplied with 2. so i multiplied 0x10000, which is nothing other than 65536 with 2 and my result was 131072, which is in hex: 0x20000. but your 0x12000 is in decimal-system 73728. so is there any matter, why you broke this sequence? > > I did not. I'll explain. > What matters here is the number in binary base, since it'll be used for > bit-AND, bit-OR, or/and bit-XOR operations. > If you convert the numbers (in hexadecimal base) to binary base, you'll > see they do indeed follow order: 0001, 0010, 0100, ... > i do not understand......if i follow the binary base 0x10000 is : 10000000000000000 = a one with 16 * 0 when i counted correctly so the next one should be a one with 17 * 0 right? --> 100000000000000000 = in hex : 0x20000 so my patch hase the correct hex. is this right? your patch: qoute: -----quote---- --- linux/include/scsi/scsi_devinfo.h.orig 2004-01-13 04:03:19.000000000 +0100 +++ linux/include/scsi/scsi_devinfo.h 2004-01-13 04:12:19.509266640 +0100 @@ -19,4 +19,5 @@ #define BLIST_MS_SKIP_PAGE_3F 0x4000 /* do not send ms page 0x3f */ #define BLIST_USE_10_BYTE_MS 0x8000 /* use 10 byte ms before 6 byte ms */ #define BLIST_MS_192_BYTES_FOR_3F 0x10000 /* 192 byte ms page 0x3f request */ +#define BLIST_NORMB 0x12000 /* Known to be not removable */ #endif --- linux/drivers/scsi/scsi_scan.c.orig 2004-01-13 04:03:19.000000000 +0100 +++ linux/drivers/scsi/scsi_scan.c 2004-01-13 04:13:07.728936136 +0100 @@ -536,7 +536,8 @@ -----end------ there is 0x12000 which is in binary: 10010000000000000 ! i do not see a sequence in your patch :( ok an why had this patch not been added to the kernel, do you no anything? Tobias Lieber |
From: Javier M. <ja...@ma...> - 2004-05-27 00:14:11
|
* Tobias Lieber <lit...@gm...> [040527 01:09]: >> How come? You did not write 0x20000 but 0x10000 which in 2.6.5+ kernels >> is used by the mew flag BLIST_MS_192_BYTES_FOR_3F. >> Had you written 0x20000, it would be working fine, you simply would not >> be using the same step every other flag on th header file uses... >i wrote 0x20000: i quote from the text file: I beg you pardon. I thought I was still talking to Brian and referred to his post on this list and not to your correctly written info you posted on the web. >> >i thought this way: the 0x..... are hex-values. If you calculate them to the decimal system, each following decimal-value is the last decimal-value multiplied with 2. so i multiplied 0x10000, which is nothing other than 65536 with 2 and my result was 131072, which is in hex: 0x20000. but your 0x12000 is in decimal-system 73728. so is there any matter, why you broke this sequence? >> I did not. I'll explain. >> What matters here is the number in binary base, since it'll be used for >> bit-AND, bit-OR, or/and bit-XOR operations. >> If you convert the numbers (in hexadecimal base) to binary base, you'll >> see they do indeed follow order: 0001, 0010, 0100, ... >i do not understand......if i follow the binary base 0x10000 is : 10000000000000000 = a one with 16 * 0 when i counted correctly >so the next one should be a one with 17 * 0 right? --> 100000000000000000 = in hex : 0x20000 >so my patch has the correct hex. is this right? So again my brain dead... Yep you are right again. I thought I had spotted something odd in the header file when I initially wrote the patch and intended to do The Right Thing (TM), but, alas!, I obviously did not. Hence, even if what I wrote might initially work a conflict might happen and behave in an unexpected way. You did it right :) BTW, what's that homepage of mine you tried to access? smarcet is the username of my sister -- Bore, n.: A person who talks when you wish him to listen. -- Ambrose Bierce, "The Devil's Dictionary" Javier Marcet <ja...@ma...> |
From: Brian M. <bm...@ne...> - 2004-05-27 11:01:51
|
Javier, Thanks for the original patch. When I made the patch for 2.6.6 I knew about the duplicate 0x1000's. In another email I even mentioned it and said I felt it should be 0x20000, but 0x10000 worked for me, so I left it. It was a bit sloppy, but I stayed with what worked for me at the time. Brian Javier Marcet wrote: > * Brian Miller <bm...@ne...> [040525 15:15]: > >> A few people asked for the kernel patch I used to get my iRiver to >> mount under Linux. >> The first thing is to read the following page: > > >> https://nirodha.ath.cx/ifp-590t-linux.txt > > >> I don't know the person, but it's basically the path I followed. > > >> The only trick was his patch was for kernel 2.6.4, It didn't work for >> 2.6.5 or 2.6.6; things had changed a little and 3 hunks didn't apply. >> So here's my very first kernel patch, and I hope it works for you on >> your 2.6.6 kernel. > > > That person was me. I wrote it for kernel 2.6.3, indeed, but in 2.6.4 > there were no changes which affected it one or other way. Those came in > 2.6.5 as you correctly said... > However, although you apparently fixed the rejects -it is not rejected > anymore-, you missed the most important bit in the patch, which must be > changed for 2.6.5+, although very slightly: > >> --------------- CUT HERE ------------------ >> --- linux-2.6.6-clean/include/scsi/scsi_devinfo.h Mon May 10 >> 12:31:58 2004 >> +++ linux-2.6.6/include/scsi/scsi_devinfo.h Thu May 20 22:48:11 2004 >> @@ -20,4 +20,5 @@ >> #define BLIST_MS_SKIP_PAGE_3F 0x4000 /* do not send ms page 0x3f */ >> #define BLIST_USE_10_BYTE_MS 0x8000 /* use 10 byte ms before 6 >> byte ms */ >> #define BLIST_MS_192_BYTES_FOR_3F 0x10000 /* 192 byte ms page > > ~~~~~~~ > >> 0x3f request */ >> +#define BLIST_NORMB 0x10000 /* Known to be not removable */ > > ~~~~~~~ > >> #endif > > > Ok, do you see the two bitmasks I marked above? They MUST be different, > I had made 0x100000 up for the BLIST_NORMB flag I wrote for iRiver > devices, but since that valu is already used we must go to the next one, > 0x12000. Hence, the right patch for 2.6.5+ -I'm using 2.6.6 right now-, > is as I attach to this e-mail :) > > Happy iRiver ing :) > > P.S Brian, I haven't read your document explaining how to do it, but in > the coming days I'll try to put online the patch with instructions and > some other tips, which might well be FAQ, if added together :) > If anyone is willing to give a hand and is good with web design we might > put some pictures and make it nice-looking too. > > >------------------------------------------------------------------------ > >--- linux/include/scsi/scsi_devinfo.h.orig 2004-01-13 04:03:19.000000000 +0100 >+++ linux/include/scsi/scsi_devinfo.h 2004-01-13 04:12:19.509266640 +0100 >@@ -19,4 +19,5 @@ > #define BLIST_MS_SKIP_PAGE_3F 0x4000 /* do not send ms page 0x3f */ > #define BLIST_USE_10_BYTE_MS 0x8000 /* use 10 byte ms before 6 byte ms */ > #define BLIST_MS_192_BYTES_FOR_3F 0x10000 /* 192 byte ms page 0x3f request */ >+#define BLIST_NORMB 0x12000 /* Known to be not removable */ > #endif >--- linux/drivers/scsi/scsi_scan.c.orig 2004-01-13 04:03:19.000000000 +0100 >+++ linux/drivers/scsi/scsi_scan.c 2004-01-13 04:13:07.728936136 +0100 >@@ -536,7 +536,8 @@ > */ > > sdev->inq_periph_qual = (inq_result[0] >> 5) & 7; >- sdev->removable = (0x80 & inq_result[1]) >> 7; >+ sdev->removable = (((0x80 & inq_result[1]) >> 7) && >+ !(*bflags & BLIST_NORMB)); > sdev->lockable = sdev->removable; > sdev->soft_reset = (inq_result[7] & 1) && ((inq_result[3] & 7) == 2); > >--- linux/drivers/scsi/scsi_devinfo.c.orig 2004-01-13 04:03:19.000000000 +0100 >+++ linux/drivers/scsi/scsi_devinfo.c 2004-01-13 04:13:40.591940200 +0100 >@@ -183,6 +183,7 @@ > {"XYRATEX", "RS", "*", BLIST_SPARSELUN | BLIST_LARGELUN}, > {"Zzyzx", "RocketStor 500S", NULL, BLIST_SPARSELUN}, > {"Zzyzx", "RocketStor 2000", NULL, BLIST_SPARSELUN}, >+ {"iRiver", "iFP Mass Driver", NULL, BLIST_NORMB}, > { NULL, NULL, NULL, 0 }, > }; > > > |
From: Javier M. <li...@ma...> - 2004-05-27 17:18:14
|
* Brian Miller <bm...@ne...> [040527 13:06]: >Thanks for the original patch. No problem :) I really needed it. >When I made the patch for 2.6.6 I knew about the duplicate 0x1000's. In >another email I even mentioned it and said I felt it should be 0x20000, All right, I only read a few posts on the list. You know, if everything is working fine, what else can you ask for? :) >but 0x10000 worked for me, so I left it. It was a bit sloppy, but I >stayed with what worked for me at the time. Ditto. -- Unnamed Law: If it happens, it must be possible. Javier Marcet <ja...@ma...> |
From: Tobias L. <tob...@we...> - 2004-06-28 19:38:49
|
Hi all today i compiled todays linux-cvs and............ my iriver ifp 599T worked without any patch Tobias Lieber On Tue, 25 May 2004 23:10:22 +1000 Brian Miller <bm...@ne...> wrote: > A few people asked for the kernel patch I used to get my iRiver to mount > under Linux. > > The first thing is to read the following page: > > https://nirodha.ath.cx/ifp-590t-linux.txt > > I don't know the person, but it's basically the path I followed. > > The only trick was his patch was for kernel 2.6.4, It didn't work for > 2.6.5 or 2.6.6; things had changed a little and 3 hunks didn't apply. So > here's my very first kernel patch, and I hope it works for you on your > 2.6.6 kernel. > > --------------- CUT HERE ------------------ > --- linux-2.6.6-clean/include/scsi/scsi_devinfo.h Mon May 10 > 12:31:58 2004 > +++ linux-2.6.6/include/scsi/scsi_devinfo.h Thu May 20 22:48:11 2004 > @@ -20,4 +20,5 @@ > #define BLIST_MS_SKIP_PAGE_3F 0x4000 /* do not send ms page 0x3f */ > #define BLIST_USE_10_BYTE_MS 0x8000 /* use 10 byte ms before 6 byte > ms */ > #define BLIST_MS_192_BYTES_FOR_3F 0x10000 /* 192 byte ms page > 0x3f request */ > +#define BLIST_NORMB 0x10000 /* Known to be not removable */ > #endif > --- linux-2.6.6-clean/drivers/scsi/scsi_scan.c Mon May 10 12:33:13 2004 > +++ linux-2.6.6/drivers/scsi/scsi_scan.c Thu May 20 22:46:01 2004 > @@ -554,7 +554,8 @@ > scsi_device_set_state(sdev, SDEV_OFFLINE); > } > > - sdev->removable = (0x80 & inq_result[1]) >> 7; > + sdev->removable = (((0x80 & inq_result[1]) >> 7) && > + !(*bflags & BLIST_NORMB)); > sdev->lockable = sdev->removable; > sdev->soft_reset = (inq_result[7] & 1) && ((inq_result[3] & 7) > == 2); > > --- linux-2.6.6-clean/drivers/scsi/scsi_devinfo.c Mon May 10 > 12:32:27 2004 > +++ linux-2.6.6/drivers/scsi/scsi_devinfo.c Thu May 20 22:49:29 2004 > @@ -183,6 +183,7 @@ > {"TOSHIBA", "CDROM", NULL, BLIST_ISROM}, > {"TOSHIBA", "CD-ROM", NULL, BLIST_ISROM}, > {"XYRATEX", "RS", "*", BLIST_SPARSELUN | BLIST_LARGELUN}, > + {"iRiver", "iFP Mass Driver", NULL, BLIST_NORMB}, > {"Zzyzx", "RocketStor 500S", NULL, BLIST_SPARSELUN}, > {"Zzyzx", "RocketStor 2000", NULL, BLIST_SPARSELUN}, > { NULL, NULL, NULL, 0 }, > ------------------------ CUT HERE --------------------------------- > > I applied it with the following commands: > > $ cd /usr/src/linux > $ patch -p1 < /path/to/patch-file > > Brian Miller > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > Ifp-driver-common mailing list > Ifp...@li... > https://lists.sourceforge.net/lists/listinfo/ifp-driver-common |