From: Patrick N. <pat...@gm...> - 2008-02-18 16:21:08
|
Thank you all for the very helpful info thus far. (More below.) On 2/17/08, Jonathan Woithe <jw...@ph...> wrote: > > Hi Patrick > > > > > For the sniffing, should I run the MOTU windows software (I haven't used > > this yet), and sniff on the same PC? Or do I need to stick another > > PC (with the PCILynx card) between the windows PC and the MOTU? What > s/w do > > you use to do the sniffing? I've got XP installed on my windows PC, and > I > > have another spare desktop that I can put whatever on (currently has > FC4). > > You require at least 2 PCs. One running the MOTU-supplied software under > a > MOTU-supported OS with a standard OHCI firewire card, the other running > Linux with a PCILynx card which has at least 2 external ports. The MOTU > is > connected to the Linux PC, as is the other "supported" PC. In other > words, > the Linux PC is in the "middle" of the bus. Okay. I also found the nosy software you referred to earlier. Here's a link for anyone else interested: http://bitplanet.net/nosy/ > IOI were also making PCILynx cards when I was out looking for them. From > memory at the time they were quite reasonably priced too - around US$50. > I ended up buying direct from IOI since they had no Australian distributor > and I was very pleased with the way it turned out. Being in the US you'd > have a local distributor I guess. The product URL is > > http://www.ioi.com.tw/products/proddetail.aspx?ProdID=1060006 > > The model number is IOI-1394TT. I called IOI, and they said they aren't selling this card anymore (even though it's still listed on their web site). My google/ebay searching hasn't turned up any other active sources either. > > What exactly does PCILynx enable? > > The PCILynx chipset passes ALL async firewire packets to its host even if > they are not addressed to the host. Since all firewire audio device > configuration occurs via async packets this is kind of important if you're > doing protocol analysis. The "standard" OHCI-based cards on the other > hand > do not pass async packets unless they are addressed to it. This is not a > driver issue - it's in the hardware. The OHCI chips are physically > incapable of passing packets unless they are addressed to it because the > OHCI specification dictates this. I read the (rather short) datasheet for the TI TSB12LV21B (PCILynx-2) chip, and I couldn't see any mention of this capability. Granted, it may be there and my limited knowledge of 1394 may be blinding me of it. Does anyone else have another reference that explains how this works (at the chip level)? I'd like this mainly for my own understanding, but also so I know what to look for on the off chance that another chip exists. > > Would it be worth another try to request the protocol from MOTU? When > was > > the last time anyone contacted them? Can you share any past > correspondence > > with them? > > Hey, you can try, but don't be offended if you get stonewalled. The > biggest > problem is that MOTU only provide access to the standard tech support > people > via their website - it's not possible to contact someone else higher up > the > chain. These people are simply told that that they support X and Y > operating systems and anything else is a no-go. They simply parrot this > company policy back to you and end the exchange. If it were possible to > get > access to someone higher up the chain to whom we could explain precisely > what we wanted things *might* be different. Note that even this is > doubtful > since the entire company seems convinced that giving out their protocol > amounts to a release of their precious intellectual property. However, > they'd be more chance of success at the upper levels than with the plebs > manning the tech support email address. > > It's possible that a phone-based approach might get further but it would > have to be well thought out in advance. You need to avoid getting > switched > through to technical support at all costs because otherwise you'll just > get > the standard company line repeated back to you yet again. I've toyed with > the idea of trying this but (a) I really can't afford the (potentially > lengthy) international phone call and (b) 3am local time isn't the best > time > of day to make such a phone call. > > The last time I tried MOTU tech support was in November 2005. At that > time > they told me that: > > This information is not available through MOTU's tech support as of right > now. However, you can try sending a suggestion that MOTU should provide > this information to suggestions@MOTU.com > > This I did, and received no reply at all - not even an acknowledgement > that > the email was received. I then sent something to sa...@mo... informing > them of all the earlier correspondance. I received the following terse > reply: > > The Traveler is supported with Windows and Mac OS drivers. > MOTU has no current plans to develop products for Linux. > > I then explained that I didn't want them to develop for Linux and only > wanted the protocol documentation to allow myself to do the development. > Not unsurprisingly, in response to this I received the following two line > reply: > > I'm sorry but the answer is no. The APIs and internal control > information are proprietary and not available to outside developers. > > Game over, and hense the protocol analysis approach. > > I would be interested in discussing the possibility of a fresh approach. > Contact me off-list if you're interested or want further details of the > exchanges mentioned above. Thanks again for all this info. I'm willing to contact them and attempt to speak to a product manager or someone at that level. I just didn't want to waste time (mine and theirs) if someone had recently contacted them. I understand every company views their IP differently. But I think it's worth another shot given it's been over 2 years. And perhaps a product manager never got the chance to consider this option if the sales team "handled" it themselves. Still, if the answer is no, I won't be shocked. Jonathan, if you like, we can speak further off-list about a plan. Regards, Patrick |
From: Patrick N. <pat...@gm...> - 2008-02-18 18:55:13
|
(Answering one of my own questions below.) On 2/18/08, Patrick Noffke <pat...@gm...> wrote: > Thank you all for the very helpful info thus far. (More below.) > > > On 2/17/08, Jonathan Woithe <jw...@ph...> wrote: > > Hi Patrick > > > > > > > > > > What exactly does PCILynx enable? > > > > The PCILynx chipset passes ALL async firewire packets to its host even if > > they are not addressed to the host. Since all firewire audio device > > configuration occurs via async packets this is kind of important if you're > > doing protocol analysis. The "standard" OHCI-based cards on the other hand > > do not pass async packets unless they are addressed to it. This is not a > > driver issue - it's in the hardware. The OHCI chips are physically > > incapable of passing packets unless they are addressed to it because the > > OHCI specification dictates this. > > > I read the (rather short) datasheet for the TI TSB12LV21B (PCILynx-2) chip, and I couldn't see any mention of this capability. Granted, it may be there and my limited knowledge of 1394 may be blinding me of it. Does anyone else have another reference that explains how this works (at the chip level)? I'd like this mainly for my own understanding, but also so I know what to look for on the off chance that another chip exists. I looked at the nosy source code, which writes to a register with the name: LINK_CONTROL_SNOOP_ENABLE. I googled a little and came across the "PCILynx Functional Specification." This is (currently) available here: http://www.eettaiwan.com/ARTICLES/2001APR/PDF/2001APR25_NTEK_CT_AN905.PDF?SOURCES=DOWNLOAD Some excerpts from this document: ----------------------------------------------------------------------------------- Appendix I Using SNOOP Mode Set bit 6 SNOOP_ENABLE in the link control register @F04. This forces all received data to DMA channel 0 and ACKs are inhibited. Only DMA channel 0 should be programmed. Set up the largest possible receive FIFO. An extra quadlet is appended on the end of received packets. This quadlet contains the received ACK (ls bits) or 0 for ISO or cycle_start packets. ----------------------------------------------------------------------------------- 4.2.5.5.1 Snoop Mode When the SNOOP_ENABLE bit is set in the link layer control register, the PCILynx enters a special mode where only DMA channel 0 is used for all received packets. The RCV_COMP_VALID bit is ignored as well as various comparator bits. All packets seen on the 1394 bus are received into DMA channel 0 PCLs. The SNOOPED packet quadlets contain all data quadlets observed on the 1394 bus, including the 1394 header quadlets, header CRC quadlet, any payload quadlets, and the payload CRC quadlet. These CRC quadlets are not normally received into the FIFO. The header CRC follows the 1 quadlet isochronous header or the 3 or 4 quadlet asynchronous header. The payload CRC follows the last payload quadlet, and is aligned on a quadlet boundary. Runt packets, PHY configuration, SELFID, and Link-on, do not have any additional CRCs that will show up in the received packet. A SNOOPED ACK quadlet containing the ACK information as seen on the 1394 bus is inserted into the FIFO following the received packet. If a SNOOPing node is specifically addressed by an asynchronous packet, then the SNOOPing node will never return an ACK on the 1394 bus and will insert a SNOOPED ACK of 0 into the receive FIFO. A SNOOPED ACK of 0 is always stored for isochronous packets. ----------------------------------------------------------------------------------- (This table didn't copy that well, so I'm attempting to reformat it for plain text.) Table C–5. General Receive FIFO Snoop Mode Packet Format* 32 31 0 1 START_OF_PACKET_CONTROL_WORD 0 SNOOPED_PACKET 0 SNOOPED_ACK 1 END_OF_PACKET_CONTROL_WORD Field Name: START_OF_PACKET_CONTROL_WORD Bit Positions: 31-0 Description: FIFO start control word. Marks the start of a snooped packet in the FIFO. Contains control information that will be used by DMA channel 0 for controlling the transfer of the snooped packets from the FIFO to PCI host memory. The details of this control word are specified in Appendix D. Field Name: SNOOPED_PACKET Bit Positions: 31 – 0 Description: N number of quadlets that comprise the packet that was snooped. The SNOOPED_PACKET will include any 1394 header CRC or payload CRC quadlets. These CRC quadlets are not received in a normal receive operation. Field Name: SNOOPED_ACK Bit Positions: 3–0 Description: The 4-bit ack status that was snooped. If the link receiver does not detect a ack for the snooped packet, the SNOOPED_ACK value will be set to 0000. Field Name: END_OF_PACKET_CONTROL_WORD Bit Positions: 31 – 0 Description: FIFO end control word. Marks the end of the packet in the FIFO. Contains control information that is used by DMA channel 0 for transferring the snooped packet from the FIFO to host memory. The bit field definitions for this control word are specified in Appendix D. *PCILynx Pev A and Higher (The leading bit of SNOOPED_PACKET and all 28 leading bits of SNOOPED_ACK are 0.) ----------------------------------------------------------------------------------- Appendix D details the FIFO Control Word and Transmit ACK Formats, but it is too much detail to paste here and reformat. If you need this information and cannot in the future find this spec, I'd be happy to email a copy. Regards, Patrick |
From: Jonathan W. <jw...@ph...> - 2008-02-18 23:00:01
|
Hi Patrick > (Answering one of my own questions below.) > > > > I read the (rather short) datasheet for the TI TSB12LV21B (PCILynx-2) chip, and I couldn't see any mention of this capability. Granted, it may be there and my limited knowledge of 1394 may be blinding me of it. Does anyone else have another reference that explains how this works (at the chip level)? I'd like this mainly for my own understanding, but also so I know what to look for on the off chance that another chip exists. > > I looked at the nosy source code, which writes to a register with the > name: LINK_CONTROL_SNOOP_ENABLE. I googled a little and came across > the "PCILynx Functional Specification." This is (currently) available > here: > http://www.eettaiwan.com/ARTICLES/2001APR/PDF/2001APR25_NTEK_CT_AN905.PDF?SOURCES=DOWNLOAD And at TI's website. > Some excerpts from this document: > : > Appendix D details the FIFO Control Word and Transmit ACK Formats, but > it is too much detail to paste here and reformat. If you need this > information and cannot in the future find this spec, I'd be happy to > email a copy. No need - I have the functional description myself. However, none of this information is usable or even helpful if you don't have a PCILynx-equipped PCI card. The features described in this document apply only to the PCILynx chip and are not implemented in any so-called OHCI cards (which are the only chips used in "consumer" PCI firewire cards). It comes down to the original assertion: if you want to do protocol analysis you must obtain either a standalone bus analyser ("firespy" for example) or a firewire card equipped with a PCILynx chip. These are the only options and unfortunately neither of them are particularly cheap. The card option is definitely the cheaper of the two though, even if it does potentially require more programming. Regards jonathan |
From: Jonathan W. <jw...@ph...> - 2008-02-18 22:51:16
|
Hi Patrick > > > For the sniffing, should I run the MOTU windows software (I haven't used > > > this yet), and sniff on the same PC? Or do I need to stick another > > > PC (with the PCILynx card) between the windows PC and the MOTU? What s/w do > > > you use to do the sniffing? I've got XP installed on my windows PC, and I > > > have another spare desktop that I can put whatever on (currently has FC4). > > > > You require at least 2 PCs. One running the MOTU-supplied software under a > > MOTU-supported OS with a standard OHCI firewire card, the other running > > Linux with a PCILynx card which has at least 2 external ports. The MOTU is > > connected to the Linux PC, as is the other "supported" PC. In other > > words, the Linux PC is in the "middle" of the bus. > > Okay. I also found the nosy software you referred to earlier. Yep, that's the one. Note that for working out the details regarding the control protocol I ended up using a highly modified version of nosy in order to target events I was interested in. Without this certain types events were very hard to find in amongst everything else which was going on. I can provide more details later if it is relevant. > > IOI were also making PCILynx cards when I was out looking for them. From > > memory at the time they were quite reasonably priced too - around US$50. > > I ended up buying direct from IOI since they had no Australian distributor > > and I was very pleased with the way it turned out. Being in the US you'd > > have a local distributor I guess. The product URL is > > > > http://www.ioi.com.tw/products/proddetail.aspx?ProdID=1060006 > > > > The model number is IOI-1394TT. > > I called IOI, and they said they aren't selling this card anymore (even > though it's still listed on their web site). Hmm, that's too bad. I can't say I blame them though - they can't have been moving more than a few hundred a year at the most. It's a pity really. I know when I went looking there weren't many people selling these cards and it now looks like only the more expensive vendors are left in this product space. > My google/ebay searching hasn't turned up any other active sources either. Ebay may be your best bet given that it seems the supply of these cards is drying up fast. The problem is that generally they were only ever owned by people who knew what they could be used for and these people are unlikely to want to part with them. Still, you might get lucky. > > > What exactly does PCILynx enable? > > > > The PCILynx chipset passes ALL async firewire packets to its host even > > if they are not addressed to the host. Since all firewire audio device > > configuration occurs via async packets this is kind of important if > > you're doing protocol analysis. The "standard" OHCI-based cards on the > > other hand do not pass async packets unless they are addressed to it. > > This is not a driver issue - it's in the hardware. The OHCI chips are > > physically incapable of passing packets unless they are addressed to it > > because the OHCI specification dictates this. > > I read the (rather short) datasheet for the TI TSB12LV21B (PCILynx-2) chip, > and I couldn't see any mention of this capability. Granted, it may be there > and my limited knowledge of 1394 may be blinding me of it. Does anyone else > have another reference that explains how this works (at the chip level)? > I'd like this mainly for my own understanding, but also so I know what to > look for on the off chance that another chip exists. Not at the chip level, no. I doubt there would be any chip-level documents out there since hardware manufacturers tend to keep that kind of information fairly close to their chest. For a programming level description, try "Initialization and Asynchronous Programming of the PCILynx TSB12LV21A 1394 Device", application report SLLA023 dated 15 December 1997 for starters - it describes the initialisation of the chip although it doesn't explicitly mention the sniffing capability. A more detailed functional description can be found in "PCILynx 1394 to PCI Bus Interface TSB12LV21BPGF Functional Specification", SCPA020A, April 1999. The capability we utilise is known as "snoop mode" in the PCILynx documentation. You'll find reference to this in sections 4.2.5.5 and 4.2.5.5.1 of the functional description document. The register referred to in these sections is defined in section 5.5.6 ("1394 Link Layer Control @F04"). If you can't lay your hand on the above documents (which should be available on the TI website), your best bet at finding out how this works is probably to look at the nosy kernel driver. It covers all the important bits. Note that the standard PCILynx kernel driver does not do the passthrough thing so that won't help. As to "another chip", the short answer is that there isn't one. PCILynx is the only chip used on PC PCI cards which ever did the async packet passthrough to my knowledge. Note that TI still make the PCILynx chips but the target market still does not include PCI cards (quoting from their website, "This product is for high-volume CE [consumer electronics] applications only"). I seem to recollect that PCILynx wasn't really ever designed for PCI cards - it was made by TI for consumer electronics and standalone firewire bus analysers (which incidently are still sold, but they are and always have been expensive). Some enterprising people popped the chips onto PCI cards as a "cheap" way of getting a bus analyser but operating system drivers were never provided. This was because the upstream chip provider (TI) never did OS drivers since that wasn't the product space they were targetting. The result of this was that PCILynx PCI cards couldn't be used as "consumer" cards and therefore the volume for PCILynx-equipped PCI cards has been low - too low it seems for the cheaper vendors to stay in the market. For the sake of completeness I have heard that the "Blue and White" Mac G3 used PCILynx as its firewire chip. There are reports of people successfully using these machines for protocol analysis but I don't know the details aside from the fact that some people use "FireBug". The original "Yikes" G4 desktop also reportedly used the PCILynx chip but I haven't seen this confirmed and don't know if anyone's successfully used that for analysis. Regards jonathan |
From: Heikki L. <hol...@cs...> - 2008-02-19 09:06:17
|
Jonathan Woithe kirjoitti: > > For the sake of completeness I have heard that the "Blue and White" Mac G3 > used PCILynx as its firewire chip. There are reports of people successfully > using these machines for protocol analysis but I don't know the details > aside from the fact that some people use "FireBug". The original "Yikes" G4 > desktop also reportedly used the PCILynx chip but I haven't seen this > confirmed and don't know if anyone's successfully used that for analysis. So, let's confirm it: Power Mac "Yikes" G4, the one with a PCI graphics adapter, does have a PCILynx and works fine for fw capture. It even has two fw ports. FireBug is Apple's protocol capture software, but the Linux pcilynx drivers seems to work on the box as well - I haven't tried "nosy" myself, though. -- Heikki Lindholm |
From: Jonathan W. <jw...@ph...> - 2008-02-19 22:31:53
|
Hi Heikki > > For the sake of completeness I have heard that the "Blue and White" Mac G3 > > used PCILynx as its firewire chip. There are reports of people successfully > > using these machines for protocol analysis but I don't know the details > > aside from the fact that some people use "FireBug". The original "Yikes" G4 > > desktop also reportedly used the PCILynx chip but I haven't seen this > > confirmed and don't know if anyone's successfully used that for analysis. > > So, let's confirm it: Power Mac "Yikes" G4, the one with a PCI graphics > adapter, does have a PCILynx and works fine for fw capture. It even has > two fw ports. Thanks for this - it's good to know. It's also helpful to know that it has two ports since putting the sniffer between the two devices being sniffed tends to work much better and is more reliable. > FireBug is Apple's protocol capture software I figured. > but the Linux pcilynx drivers seems to work on the box as well - I haven't > tried "nosy" myself, though. The standard Linux pcilynx driver does not do arbitary capture and so can't be used for protocol analysis. However, if it works then there's a reasonable chance nosy's kernel driver would. FYI the kernel's PCILynx driver is suffering somewhat from bitrot. It provides only the older kernel ieee1394 interfaces only. In practice this means that the "current" raw1394 interface is not provided, making it unusable with most current-generation "user" software under Linux). This isn't really a big problem though since most people with a PCILynx card aren't interested in using it with "standard" software anyway. Regards jonathan |
From: Patrick N. <pat...@gm...> - 2008-03-06 02:07:10
|
Okay, I have a PCILynx card, and I'm trying to build nosy on a fresh Fedora 8 installation. I'm getting these errors: make -C /lib/modules/2.6.23.1-42.fc8/build SUBDIRS=/home/pnoffke/Download/nosy-0.3 modules make[1]: Entering directory `/usr/src/kernels/2.6.23.1-42.fc8-i686' CC [M] /home/pnoffke/Download/nosy-0.3/nosy.o /home/pnoffke/Download/nosy-0.3/nosy.c:21:26: error: linux/config.h: No such file or directory /home/pnoffke/Download/nosy-0.3/nosy.c: In function 'packet_buffer_get': /home/pnoffke/Download/nosy-0.3/nosy.c:154: warning: ignoring return value of 'copy_to_user', declared with attribute warn_unused_result /home/pnoffke/Download/nosy-0.3/nosy.c:160: warning: ignoring return value of 'copy_to_user', declared with attribute warn_unused_result /home/pnoffke/Download/nosy-0.3/nosy.c:161: warning: ignoring return value of 'copy_to_user', declared with attribute warn_unused_result /home/pnoffke/Download/nosy-0.3/nosy.c: In function 'add_card': /home/pnoffke/Download/nosy-0.3/nosy.c:621: warning: 'deprecated_irq_flag' is deprecated (declared at include/linux/interrupt.h:64) /home/pnoffke/Download/nosy-0.3/nosy.c:621: warning: passing argument 2 of 'request_irq' from incompatible pointer type /home/pnoffke/Download/nosy-0.3/nosy.c: In function 'nosy_init': /home/pnoffke/Download/nosy-0.3/nosy.c:662: error: implicit declaration of function 'pci_module_init' make[2]: *** [/home/pnoffke/Download/nosy-0.3/nosy.o] Error 1 make[1]: *** [_module_/home/pnoffke/Download/nosy-0.3] Error 2 make[1]: Leaving directory `/usr/src/kernels/2.6.23.1-42.fc8-i686' make: *** [nosy.ko] Error 2 If I comment out the #include for linux/config.h, I'm only left with the implicit declaration error (and the other warnings). Do you guys know how to get around this error, and are the remaining warnings cause for concern? Thanks, Patrick |
From: Jonathan W. <jw...@ph...> - 2008-03-06 02:28:08
|
Hi Patrick > Okay, I have a PCILynx card That was quick. > and I'm trying to build nosy on a fresh Fedora 8 installation. I'm > getting these errors: > > make -C /lib/modules/2.6.23.1-42.fc8/build > SUBDIRS=/home/pnoffke/Download/nosy-0.3 modules > make[1]: Entering directory `/usr/src/kernels/2.6.23.1-42.fc8-i686' > CC [M] /home/pnoffke/Download/nosy-0.3/nosy.o > /home/pnoffke/Download/nosy-0.3/nosy.c:21:26: error: linux/config.h: > No such file or directory Do you have a configured Linux kernel source tree on your system? I'm pretty sure nosy needs a kernel tree in order to compile. It may also need to be a *configured* kernel tree (the fact that it's looking for linux/config.h suggests this). > If I comment out the #include for linux/config.h, I'm only left with > the implicit declaration error (and the other warnings). I'm inclined to think that you should keep this in there and fix the root cause of the problem. Because nosy plugs into the kernel it needs to know how the kernel is configured. If it assumes the wrong thing for certain size-related parameters things could get messy. > Do you guys know how to get around this error, and are the remaining > warnings cause for concern? Get a kernel source tree on your system and perhaps run "make menuconfig" to get rough configuration. Make sure the build symlink in your modules root directory (normally /lib/modules/<kernel version>/) points to the kernel source and then try again. I expect some of the warnings will go away once this is done. As to whether the remaining ones are a cause for concern, I'll tell you once I see what the remaining warnings are. :-) Regards jonathan |
From: Jonathan W. <jw...@ph...> - 2008-03-06 02:53:27
|
Hi again everyone > Okay, I have a PCILynx card, and I'm trying to build nosy on a fresh > Fedora 8 installation. I'm getting these errors: > > make -C /lib/modules/2.6.23.1-42.fc8/build > SUBDIRS=/home/pnoffke/Download/nosy-0.3 modules > make[1]: Entering directory `/usr/src/kernels/2.6.23.1-42.fc8-i686' > CC [M] /home/pnoffke/Download/nosy-0.3/nosy.o > /home/pnoffke/Download/nosy-0.3/nosy.c:21:26: error: linux/config.h: > No such file or directory Some further info just remembered (it's been a while since I last compiled nosy). With recent kernels (2.6.19 and beyond I think from memory) the structure of the kernel include files changed somewhat. Therefore even with a configured kernel source tree on your system you'll still get this error by default. Fortunately the fix is simple enough. Go to the root of your kernel source tree, then: cd include/linux/ ln -s autoconf.h config.h Alternatively, get nosy to include linux/autoconf.h instead of config.h. There is one other thing to do. In 2.6.20 the internal PCI device driver API was restructured and this will break nosy. The fix is simple enough: go to line 662 in nosy.c and change ret = pci_module_init(&lynx_pci_driver); to ret = pci_register_driver(&lynx_pci_driver); Now try to recompile nosy again and see what happens. A warning about the pointer type of argument 2 to request_irq can be ignored from memory. I've just tried all this on a 2.6.23.16 box here at work and it compiles. Regards jonathan |
From: Patrick N. <pat...@gm...> - 2008-03-06 03:19:52
|
On Wed, Mar 5, 2008 at 8:53 PM, Jonathan Woithe <jw...@ph...> wrote: > Hi again everyone > > > > Okay, I have a PCILynx card, and I'm trying to build nosy on a fresh > > Fedora 8 installation. I'm getting these errors: > > > > make -C /lib/modules/2.6.23.1-42.fc8/build > > SUBDIRS=/home/pnoffke/Download/nosy-0.3 modules > > make[1]: Entering directory `/usr/src/kernels/2.6.23.1-42.fc8-i686' > > CC [M] /home/pnoffke/Download/nosy-0.3/nosy.o > > /home/pnoffke/Download/nosy-0.3/nosy.c:21:26: error: linux/config.h: > > No such file or directory > > Some further info just remembered (it's been a while since I last compiled > nosy). With recent kernels (2.6.19 and beyond I think from memory) the > structure of the kernel include files changed somewhat. Therefore even with > a configured kernel source tree on your system you'll still get this error > by default. > > Fortunately the fix is simple enough. Go to the root of your kernel source > tree, then: > > cd include/linux/ > ln -s autoconf.h config.h > > Alternatively, get nosy to include linux/autoconf.h instead of config.h. > > There is one other thing to do. In 2.6.20 the internal PCI device driver > API was restructured and this will break nosy. The fix is simple enough: go > to line 662 in nosy.c and change > > ret = pci_module_init(&lynx_pci_driver); > > to > > ret = pci_register_driver(&lynx_pci_driver); > > Now try to recompile nosy again and see what happens. A warning about > the pointer type of argument 2 to request_irq can be ignored from memory. > I've just tried all this on a 2.6.23.16 box here at work and it compiles. > > Regards > jonathan > Okay, that worked. I had to install popt-devel as well. Now to throw the card in and reboot. Thanks, Patrick |