Re: query: IP over PCI?
Josh Fryman wrote: > there have been many references in the past (notably in the beowulf > community) about TCP/IP over PCI -- that was way back with kernel > 2.2.9 and thereabouts (1999). at that time, there were some patches > available to implement this... There are four versions of this that I know of. They come from MontaVista, LynuxWorks, Ziatech, and myself. Mine is based on code originally written for ARM by Mark van Doesburg, and ported to PowerPC by myself. This is probably what you know from the Strongarm Beowulf project. I made quite large changes, which haven't been completely ported back to ARM. I also added a console over PCI, to avoid the need for a serial cable to each plug-in card. This code is available as a patch for 2.2 kernels at: ftp://ftp.agelectronics.co.uk/pub/pcimsg-patch-20001201.gz - Adrian Cox - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Allocating my own skbuff data
I'm working on network drivers emulating ethernet over a PCI backplane. For receives I need packet data located in a region of memory visible to the backplane. I also want this data to be referenced by an skb, without the expense of an extra memcpy. This region of memory will be somewhere between 4MB and total memory in size, and must be located at a local address which is a multiple of its size. Which is least ugly: 0) Making ZONE_DMA the smaller of my region and 16MB, 1) making a new zone, so I can use kmalloc/kfree or 2) using my own allocator and doing the free with skb->destructor? 0 is a bit of a hack, and I'm using it now in PowerPC systems with no ISA bus. 1 has logical consistency, but requires changes to the mm code. 2 has the huge advantage of not requiring changes to the mm code, but I'm not sure that destructors are really meant for this sort of trick. - Adrian Cox, AG Electronics - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Michael Elizabeth Chastain wrote: > (c) With separate source and build trees, which I've implemented, > it becomes a lot more feaasible to manage kernel builds for > multiple platforms. Is this released? I build most of my kernels for both x86 and PowerPC, plus I build several configurations for diskless clients from the same source tree. > Linus writes ... > > Hey, maybe you have a few 18GB disks lying around, but none of the > > machines I use every day could afford to have another 5-6 cross- > > compilation environments lying around. It's just not practical. About 30MB for a cross-compilation environment capable of building kernels. Then add whatever libraries you need if you want to build userspace, and another 5 or so MB for C++. It's less than a built kernel tree. - Adrian Cox, AG Electronics - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: cPCI development
[EMAIL PROTECTED] wrote: > Am I right in assumming that 2.2.14 (as from RH6.2) supports cPCI? Or do I > need to start developing on 2.4? > > I really do need to do some research into this, if I knew where to start. I > need some docs! (either paper, URL, or the straight-jacket kind) cPCI is PCI + hotswap. Most people seem to ignore the hotswap, except at tradeshows. - Adrian Cox, AG Electronics - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: pdev_enable_device no longer used ?
"David S. Miller" wrote: > Interpreting physical BAR values is another issue altogether. Kernel > wide interfaces for this may be easily added to include/asm/pci.h > infrastructure, please just choose some sane name for it and I will > compose a patch ok? :-) There's a semi-respectable use for BAR values: peer-to-peer mastering. A new kernel interface could actually make that portable, eg: int pci_peer_master_address(struct pci_dev *master, struct pci_dev *target, int resource, unsigned long offset, unsigned long *address); Return values PCI_PEER_OK, PCI_PEER_NOWAY, PCI_PEER_FXBUG, PCI_PEER_YOURE_JOKING_RIGHT, ... Bus address usable by master placed in address. Implementing something like this with a single hostbridge is simple. It's harder on boards like my Intel 840 motherboard here, where the 33MHz and 66MHz buses don't talk to each other. It could eventually grow into a big list of platform specific workarounds, but at least they'd all be in one place where we could see them. - Adrian Cox, AG Electronics - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: static scheduling - SCHED_IDLE?
george anzinger wrote: > Seems like you are sneaking up on priority inherit mutexes. The locking > over head is not so bad (same as spinlock, except in UP case, where it > is the same as the SMP case). The unlock is, however, the same as the > lock overhead. It is hard to beat the store of zero which is the > spin_unlock. Unfortunately the kernel is already full of counting semaphores. Priority inheritance won't save you, as the task which is going to call up() need not be the same one that called down(). Jamie Lokier's suggestion of raising priority when in the kernel doesn't help. You need to raise the priority of the task which is currently in userspace and will call up() next time it enters the kernel. You don't know which task that is. There are three solutions I can think of: 1) don't have SCHED_IDLE 2) promote all SCHED_IDLE tasks into SCHED_OTHER whenever *any* task is waiting on a semaphore. 3) an audit of semaphores for 2.5 I'm quite fond of option 1. - Adrian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: static scheduling - SCHED_IDLE?
Jamie Lokier wrote: > Adrian Cox wrote: >> Jamie Lokier's suggestion of raising priority when in the kernel doesn't >> help. You need to raise the priority of the task which is currently in >> userspace and will call up() next time it enters the kernel. You don't >> know which task that is. > Dear oh dear. I was under the impression that kernel semaphores are > supposed to be used as mutexes only -- there are other mechanisms for > signalling between processes. I think most of the kernel semaphores are used as mutexes, with occasional producer/consumer semaphores. I think the core kernel code is fine, the risk mostly comes from miscellaneous character devices. I've written code that does this for a specialised device driver. I wanted only one process to have the device open at once, and for others to block on open. Using semaphores meant that multiple shells could do "cat > /dev/mywidget" and be serialised. Locking up users of this strange piece of hardware doesn't bring down the system, so your suggestion could work. We need a big fat warning in semaphore.h, and a careful examination of the current code. - Adrian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cool Road Runner (was CFA as Ide.)
Richard A. Smith wrote: > IIRC SanDisk was the original people to come out with IDE CFA and everyone else just >copied > them. I have the SanDisk datasheets that I can send you if you need them to verify >stuff. I > believe that if you verify it with the SanDisk then all the other MFG's should work >as well. If only. In my limited experience SanDisk cards have been the most tolerant. I suspect that Sandisk actually implement the full range of timings documented in the spec, and nobody else bothers. This isn't normally a problem on PC hardware, but if you try to implement an interface to talk to a CF card in an embedded system you find this out. - Adrian Cox - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cool Road Runner (was CFA as Ide.)
Richard A. Smith wrote: > On Mon, 02 Apr 2001 21:50:59 +0100, Adrian Cox wrote: >> If only. In my limited experience SanDisk cards have been the most >> tolerant. I suspect that Sandisk actually implement the full range of >> timings documented in the spec, and nobody else bothers. [...] > We do actually use SST (Silcon Storage Technolog) CF's as well and they seem to >function just > identical to the SanDisk but not quite as robust... I have had several of the SST's >develope > a problem in the partition table and as thus the just error when you try to mount >them. > Several people on the liunx-embedded list also have similar experiences. > > That seems to follow your observations... > > Will it be worth while for you if I break out the scope and examine how our CF's >handle the > PDIAG signal or can we just go on faith that they do indeed work as expected? Might be interesting to see. The worst trouble I've had has been with noname parts from high street computer stores, and I don't know who the original manufacturer was. If I knew what subset of functionality digital cameras used I'd know what could be relied on. - Adrian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: More on the VIA KT133 chipset misbehaving in Linux
Dylan Griffiths wrote: > The VIA KT133 chipset exhibits the following bugs under Linux 2.2.17 and > 2.4.0: > 1) PS/2 mouse cursor randomly jumps to upper right hand corner of screen and > locks for a bit This happens to me about once a month on a BX chipset PII machine here, and on a KT133 chipset machine I have. I have to hit ctrl-alt-backspace to regain control of the console. I always assumed it was a bug in X, but it never caused me enough trouble to actually make me pursue it. - Adrian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: More on the VIA KT133 chipset misbehaving in Linux
safemode wrote: > Adrian Cox wrote: > > Dylan Griffiths wrote: > > > 1) PS/2 mouse cursor randomly jumps to upper right hand corner of screen and > > > locks for a bit > > This happens to me about once a month on a BX chipset PII machine here, > > and on a KT133 chipset machine I have. I have to hit ctrl-alt-backspace > > to regain control of the console. I always assumed it was a bug in X, > > but it never caused me enough trouble to actually make me pursue it. > turn off gpm.. fixes the mouse problem immediately. as in killall -9 gpm > before starting X. I don't even have gpm installed on these machines, precisely for this reason. Whatever it is, it isn't gpm. But I also believe it isn't Via, and I'm not convinced that it's the kernel. - Adrian Cox - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Animated framebuffer logo for 2.4.1
Mike Galbraith wrote: > I give users more credit in the curiosity/observation department. In > my experience, when a user fires up his/her box, independent of OS, > they watch it pretty closely. This behavior begins roughly the first > time they lose a chunk of work ;-) I want to use this for embedded systems. For example, last weekend I was on a bus where the advertising screen at the front went through a complete (uncustomised) Windows 2000 boot. I want to do better than that, and build an application specific splash screen early into the boot process, with the detailed messages coming out through the serial port. - Adrian Cox - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
Marc Lehmann wrote: > Aren't PCI delayed transaction supposed to be handled by the pci master > (e.g. my northbridge), not by the (software) driver for my pdc(?) I would > also be surprised if my pdc actually used that feature, not to speak of > the fact that the promise + harddisk worked fine in another computer (the > data corruption was easily detectable, one couldn't even write 500megs > without altered bytes). Wrong way round. You're right that the pci master is supposed to handle delayed transactions, but during data transfer the pdc is the pci master and the northbridge is the PCI target. -- Adrian Cox http://www.humboldt.co.uk/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Probable endianess problem in TLAN driver
Paulo Afonso Graner Fessel wrote: > [...] > He said me that these funtions don't address the endianess question, and > sent me a patch. He said that this probably wouldn't work, but I've > decided to give a try anyway. Here is the patch: > > --- tlan.c.old Thu Jun 7 21:24:25 2001 > +++ tlan.c Thu Jun 7 21:37:42 2001 > @@ -172,6 +172,12 @@ > #include > #include > > +#if defined(__powerpc__) > +#define inw(addr) le32_to_cpu(inw(addr)) > +#define inl(addr) le32_to_cpu(inl(addr)) > +#define outw(val, addr)outw(cpu_to_le32(val), addr) > +#define outl(val, addr)outl(cpu_to_le32(val), addr) > +#endif On ppc the inw, inl, outw, and outl functions already byteswap, so by adding the extra byteswap you're now passing unswapped data to the chip. Take a look at include/asm-ppc/io.h and you'll see it uses byte reversed load and store instructions. Which means that either the chip is running in a big-endian mode, or that the problem is actually with data structures placed in host memory. Often when porting a driver from i386 to ppc all that is required is to add the cpu_to_le32() macros around data in host memory that the device accesses, and to remove any #ifdef __powerpc__ code written by people who don't realise that ppc uses the standard linux pci code. -- Adrian Cox http://www.humboldt.co.uk/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Via82cxxx Codec rate locked at 48Khz
Ariel Molina Rueda wrote: > When i used Redhat 7 and kernel 2.2.x y was happy with my souncard, now I > use RedHat 7.1 and Kernel 2.4.x, but sndconfig doesn't configure my > Via82c686 soundcard at all. At the ending it says > > via82cxxx codec rate locked at 48khz Is this with 2.4.6 or an earlier version? 2.4.6 contained new code for talking to the codec. -- Adrian Cox http://www.humboldt.co.uk/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Via82cxxx Codec rate locked at 48Khz
Jeff Garzik wrote: > For the message "Codec rate locked at 48Khz", that is a hardware > limitation of your codec. You need to find software which supports > software rate conversion, so that you may play music at speeds other > than 48Khz. One of the symptoms of broken communication with the codec was often false reporting of codec capabilities. So I'd recommend trying 2.4.6, to see if the codec really is locked at 48kHz. -- Adrian Cox http://www.humboldt.co.uk/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AC'97 (VT82C686A) & IRQ reassignment (I/O APIC)
Richard B. Johnson wrote: > Woof... More GAWDAUFULL junk. You mean that if I write 0xff to the R/W > interrupt line register and read it back, it's only 0x0f? Yes, and that disables generation of audio interrupts. > This didn't > save any money. There are only 4 interrupt 'pins', i.e., interrupt lines > that go to the PCI bus (A thru D). What these lines connect to for > actual IRQs is known only to the motherboard manufacturer hence the > BIOS has to check the pin value and write the appropriate IRQ value > into the interrupt line register. This register is used only as a > scratch-pad so that a driver "knows" what IRQ goes to the board. The > board, itself, never accesses this register. The board only gets one > interrupt connected (A thru D), and to the board, all interrupts are > the same. I'm currently writing the BIOS for a PowerPC embedded system using the 686B southbridge. On the 686 the 8259 interrupt controller and the audio system are inside the same physical device. The value you write to offset 0x3c actually makes the internal connection between the audio interrupt and the PIC. There is a trick to route that interrupt to an external APIC involving config register 0x58 in function 0, but I've not used it. Most southbridge functions work this way. The USB on the 686B is like this, and the the IDE controller always generates the legacy IRQ 14/15. - Adrian Cox - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
