Thread: Which kernel source is best?
Brought to you by:
aeb,
bencollins
From: John P. <je...@sw...> - 2000-10-05 04:49:57
|
Hello and thank you for all your hard work. I have been trying to patch 2.2.16 kernels for two days now and have had little success with the 2000-06-16 patch. Using the 2.2.216-9mdk release my Adaptec 8945 is never found and has build errors due to the source being only i386. On the 2.2.16 from kernel.org, I still don't find the card although the compile goes fine. I still just get the no adapters found message in /var/log. The card does work under win98 and the SCSI portion is running my 3 drive md0 RAID0 array which works great. I don't really need over 3.7MB per second, but the contiguous space is nice. Is there some dependency I could be missing? I have seen nothing about it so far. Unless I missed something, it makes no difference whether I make the drivers modules or not. What is preferred? I am dl'ing a 2.4.0-test9 kernel at the moment, please let me know what you recommend. As for my background, I am a technician for MicroSearch in Houston. I build NT based video editing systems and do light programming on the side. I have access to just about any 1394 card and many cameras for testing by simply borrowing one from the office. I hope to contribute in any way I can. Thanks, John Perkins Houston Texas |
From: Dan D. <dde...@co...> - 2000-10-05 21:21:49
|
The adaptec driver is no longer supported, so you may have difficulty get answers on that. Some users have reported some success getting the Miro and DPS-based versions of those cards working. Can you try a nice, cheap OHCI compliant card like the Pyro or SIIG? In your initial testing, please avoid a Panasonic camera. Most linux 1394 applications are having difficulty with them due to some timing and error handling issues that are just now being addressed. Also, have you tried disabling Plug-n-Play? +-DRD-+ "John P." wrote: > > Hello and thank you for all your hard work. > > I have been trying to patch 2.2.16 kernels for two days now and have had > little success with the 2000-06-16 patch. > > Using the 2.2.216-9mdk release my Adaptec 8945 is never found and has build > errors due to the source being only i386. > > On the 2.2.16 from kernel.org, I still don't find the card although the > compile goes fine. I still just get the no adapters found message in > /var/log. > > The card does work under win98 and the SCSI portion is running my 3 drive > md0 RAID0 array which works great. I don't really need over 3.7MB per > second, but the contiguous space is nice. > > Is there some dependency I could be missing? I have seen nothing about it > so far. > > Unless I missed something, it makes no difference whether I make the drivers > modules or not. What is preferred? > > I am dl'ing a 2.4.0-test9 kernel at the moment, please let me know what you > recommend. > > As for my background, I am a technician for MicroSearch in Houston. I build > NT based video editing systems and do light programming on the side. I have > access to just about any 1394 card and many cameras for testing by simply > borrowing one from the office. I hope to contribute in any way I can. > > Thanks, > John Perkins > Houston Texas > > _______________________________________________ > mailing list Lin...@li... > http://lists.sourceforge.net/mailman/listinfo/linux1394-user |
From: Andreas M. <am...@iv...> - 2000-10-06 10:30:14
|
Hello, On Thu, Oct 05, 2000 at 05:23:28PM -0500, Dan Dennedy wrote: > cheap OHCI compliant card like the Pyro or SIIG? In your initial > testing, please avoid a Panasonic camera. Most linux 1394 applications > are having difficulty with them due to some timing and error handling > issues that are just now being addressed. Well not exactly. There were also people with Sony cameras reporting the same type of problem. I now came to think that the timing issues have little to do with the used 1394 devices, but with PCs getting faster. When I first started to use Panasonic DV equipment, I also started developing on an Athlon600. This machine simply sends out requests to the DV equipment to fast. -- Andreas Micklei IVISTAR Kommunikationssysteme AG Ehrenbergstr. 19 / 10245 Berlin http://www.ivistar.de |
From: Damien D. <ddo...@te...> - 2000-10-06 11:12:39
|
Andreas Micklei wrote: > > Well not exactly. There were also people with Sony cameras reporting the same > type of problem. I now came to think that the timing issues have little to do > with the used 1394 devices, but with PCs getting faster. When I first started > to use Panasonic DV equipment, I also started developing on an Athlon600. This > machine simply sends out requests to the DV equipment to fast. Hi Andreas, Just a thought: the user manual of some Sony cameras says you have to wait at least 2ms between CSR accesses (up to 10ms for some registers). If this value depends on the camera, this means we should somehow probe for that delay. But how? Damien -- Damien Douxchamps URL : http://www.tele.ucl.ac.be/MEMBERS/Douxchamps_Damien_e.html |
From: Andreas M. <am...@iv...> - 2000-10-06 13:06:50
|
Hi Damien, On Fri, Oct 06, 2000 at 01:06:21PM +0200, Damien Douxchamps wrote: > Just a thought: the user manual of some Sony cameras says you have to > wait at least 2ms between CSR accesses (up to 10ms for some registers). > If this value depends on the camera, this means we should somehow probe > for that delay. But how? Probing for that should no longer be neccessary, because the device should return an ACK BUSY when requests are coming in to fast. Here is what I do in gscanbus now: ---------- snip ---------- /* Mask and shift macros */ #define RAW1394_MASK_ACK(x) ((x) >> 16) #define RAW1394_MASK_RCODE(x) ((x) & 0xffff) /* Ack codes */ #define ACK_COMPLETE 0x1 #define ACK_PENDING 0x2 #define ACK_BUSY_X 0x4 #define ACK_BUSY_A 0x5 #define ACK_BUSY_B 0x6 #define ACK_DATA_ERROR 0xd #define ACK_TYPE_ERROR 0xe #define ACK_LOCAL 0x10 /* Return codes */ #define RCODE_COMPLETE 0x0 #define RCODE_CONFLICT_ERROR 0x4 #define RCODE_DATA_ERROR 0x5 #define RCODE_TYPE_ERROR 0x6 #define RCODE_ADDRESS_ERROR 0x7 int cooked1394_read(raw1394handle_t handle, nodeid_t node, nodeaddr_t addr, size_t length, quadlet_t *buffer) { int retval, ackcode, rcode; while(1) { retval = raw1394_read(handle, node, addr, length, buffer); if( retval < 0 ) return retval; ackcode = RAW1394_MASK_ACK(retval); rcode = RAW1394_MASK_RCODE(retval); if( ackcode == ACK_BUSY_X || ackcode == ACK_BUSY_A || ackcode == ACK_BUSY_B ) { usleep(100); } else { break; } } if( ackcode != ACK_PENDING && ackcode != ACK_COMPLETE && ackcode != ACK_LOCAL) return -1; return retval; } ---------- snap ---------- The write function is left as an exercise to the reader. ;^) Can someone please comment if this is correct? -- Andreas Micklei IVISTAR Kommunikationssysteme AG Ehrenbergstr. 19 / 10245 Berlin http://www.ivistar.de |