Re: [PATCH] Finally eradicate CONFIG_HOTPLUG
Are you changing the code to have HOTPLUG always -on- or -off- ? From the commit message I had expected always -on-. Stephen Rothwell wrote: > --- a/include/asm-generic/vmlinux.lds.h > +++ b/include/asm-generic/vmlinux.lds.h > @@ -68,14 +68,6 @@ > * are handled as text/data or they can be discarded (which > * often happens at runtime) > */ > -#ifdef CONFIG_HOTPLUG > -#define DEV_KEEP(sec)*(.dev##sec) > -#define DEV_DISCARD(sec) > -#else > -#define DEV_KEEP(sec) > -#define DEV_DISCARD(sec) *(.dev##sec) > -#endif > - > #ifdef CONFIG_HOTPLUG_CPU > #define CPU_KEEP(sec)*(.cpu##sec) > #define CPU_DISCARD(sec) > @@ -182,8 +174,6 @@ > *(.data)\ > *(.ref.data)\ > *(.data..shared_aligned) /* percpu related */ \ > - DEV_KEEP(init.data) \ > - DEV_KEEP(exit.data) \ .. > @@ -503,7 +489,6 @@ > /* init and exit section handling */ > #define INIT_DATA\ > *(.init.data) \ > - DEV_DISCARD(init.data) \ Shouldn't the effect of one of the above remain? //Peter pgp6iJEqnd6v0.pgp Description: PGP signature ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: PATCH : linux-2.6.35.4 drivers pcmcia cs.c
Dominik Brodowski wrote: > indeed, on a IBM ThinkPad 770Z there seems to be some bug -- the CardBus > hardware doesn't tell the OS that it is CardBus capable. What hardware is this, and how would it tell the OS? Is it certain that the hardware *is* actually cardbus capable? > 2) What's the output of "lspci -n -v" > 3) What's the output of "sudo lspcmcia -vvv" Yes please. > 4) Are there any BIOS options you may toggle to enable CardBus? //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [PATCH 1/1] pcmcia: do not initialize the present flag too late.
Dominik Brodowski wrote: > The "present" flag was initialized too late -- possibly, a card > was already registered at this time, so re-setting the flag to 0 > caused pcmcia_dev_present() to fail. Might this have caused irq 16: nobody cared when I insert a pcmcia card during resume? //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: pci_bus_for_each_resource, transparent bridges and rsrc_nonstatic.c
Dominik Brodowski wrote: > can we safely trust BIOS authors to get it right? As a long time member of the coreboot project I can assure you that the answer to that is "No!!" //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: PCMCIA cards not detected
Dominik Brodowski wrote: > > e840-e84f : PCI Bus :03 > > e840-e840 : :03:00.0 > > ec00-efff : PCI CardBus :06 > > Whoa... there isn't _any_ iomem free and available to use below > 0x. Looks like there's some room from e850 to ebff. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [git pull] more PCMCIA updates for 2.6.34 (including ioctl deprecation)
Russell King wrote: > > Do any graphical environments even support the ancient user space > > pcmcica helper stuff ? > > I believe so - the platform I have is based around the Open Embedded > stuff, and there's a button on the desktop which communicates with the > kernel via the PCMCIA ioctls. One of the things it offers is to allow > media (eg, CF) to be safely ejected without ending up pulling the card > out while the FS is still mounted. So if you upgrade that system to a kernel without that call I guess you may have to either also upgrade that GUI software, or install a .so to wrap ioctl() and provide backwards compatibility for the app? //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: module loading ignores install script
Orm Finnendahl wrote: > I'm trying to convince my laptop to start a custom script on > inserting a pc express audio interface card. Is this the HDSPe ExpressCard? ExpressCard contains a PCI-Express and a USB connection. While cheap cards often only use the USB connection it seems the HDSPe uses the PCIe. This means that the card is a hotplugged PCI device in your system. (Yes, PCI, not PCIe, there's almost no difference between the two outside firmware and kernel.) You could add a one-line udev rule in order to execute stuff when this device is added (or removed) in your system. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: ioports 0x100-0x3af and iomem 0xd000-0xdffff, 0xa0000000-0xa0ffffff -- safe to use on x86 for pcmcia?
Dominik Brodowski wrote: > include port 0x100-0x3af > include memory 0xc-0xf > include memory 0xa000-0xa0ff .. > Do you think it would be safe to enable these areas by (kernel) > default on x86? c-f is option ROM and BIOS land. Maybe every BIOS out there is being a good boy/girl and actually adds entries to e820 or similar but I would kindof like to stay away from the region anyway. 0xa000 is 2.5GB, so it's doomed on systems with >=2.5GB RAM. :( //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: PCMCIA bring up fails on ide_register()
Kevin Wu wrote: > I don't know. We just use Linux 2.6.14.2 as our code base to > develop our code. Sorry, wrong answer. It seems your development model is absolutely incompatible with the Linux community. I think you are on your own. If you for whatever reason insist on shipping age old Linux that's fine - but when you want to approach the community you must really understand that the very latest version is the only one receiving developer attention. You would at the very least test your code on a recent kernel, ideally several recent kernels, to provide more data points. It is essentially your job to know, if you work with Linux, since there is no guarantee. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: yenta_socket: PCMCIA-Cards are not recognised by kernel
Wolfram Sang wrote: > Well, the PCI config space (which lspci needs) should be visible > without an assigned IRQ. There is some issue (only? also?) with the bridge. //Peter pgpHRylnNEAIW.pgp Description: PGP signature ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: yenta_socket: PCMCIA-Cards are not recognised by kernel
Hi, Frans Pop wrote: > Summary: WLAN Card (Proxim Orinoco Gold 8470-WD) is not recognized > by either 2.6.24 or 2.6.30. After inserting it, 'lspci' does not > list the card, but 'lspci -H1' does. > Original message with lspci and dmesg output for .24 is at: > http://lkml.org/lkml/2009/9/2/199 It would help to also see dmesg from .30 or newer, and, say, .9 or something similarly old. The issue is that the PCI bridge (which is what a CardBus controller is) isn't completely configured by the kernel. Parts of the kernel believe it is ok, which is why lspci says irq 11 for 00:02.0 and 00:02.1, but the value actually configured in the CardBus controller hardware is 255 = unconfigured. lspci -H1 -s 2.0 -xxx might be interesting. The .24 dmesg shows an error initializing the PCI bus: --8<-- PCI: Probing PCI hardware sysfs: duplicate filename 'bridge' can not be created WARNING: at fs/sysfs/dir.c:424 sysfs_add_one() Pid: 1, comm: swapper Not tainted 2.6.24-gentoo-r7 #1 [] sysfs_add_one+0x54/0xb8 [] sysfs_create_link+0xaf/0xfd [] pci_bus_add_devices+0xba/0xff [] pcibios_scan_root+0x25/0x80 [] printk+0x1b/0x1f [] pci_legacy_init+0x53/0xe1 [] kernel_init+0x154/0x2b6 [] ret_from_fork+0x6/0x20 [] kernel_init+0x0/0x2b6 [] kernel_init+0x0/0x2b6 [] kernel_thread_helper+0x7/0x10 === pci :00:02.0: Error creating sysfs bridge symlink, continuing... -->8-- This is bad, and is either the cause for the problem, or another symptom. .24 is a bit old, so it would be interesting to see dmesg from recent (vanilla) sources. Christian Krämer wrote: > > That means that the card should be supported by the ath5k > > wireless driver if it was correctly initialized by the cardbus > > drivers. Frans is right, but the bridge isn't set up right, so cards behind it will not work correctly either. > Yes, but on the LiveCD, when I load the module via "modprobe ath5k", > ifconfig > doesn't show any interface except for lo and also dmesg don't > display anything about a found device. In the gentoo-system I > installed, I also tried the madwifi-ng driver package, but with the > same result. This is expected, until the CardBus PCI bridge starts working. > > I don't think I can help you any further. Hopefully one of the > > PCMCIA developers can. To be clear, this looks like a CardBus/PCI issue. CardBus is more like PCI and PCMCIA is more like ISA. It could maybe be an ACPI issue, but first get to the bottom of the pci error. > I admit I'am not very familiar with the community around the > linux-kernel and this is my first request on the official mailing > list. I hope it'll be resolved, but at this point more information is needed. Try the latest vanilla kernel. Try combinations of some kernel parameters: lapic pci=biosirq They will change how the kernel reads and thinks about interrupts. It's important to have interrupts working right, but at this point it seems there's a more fundamental PCI problem with the CardBus bridges. :\ //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: yenta-socket IRQ problems
Hi Robert, Robert Kentish wrote: > I've spent the last couple of days attempting to get my Epia MII > board to boot from the onboard CF slot. I'm using coreboot v2 Lovely! :) > and have successfully created a working kernel that will load from > a CF card and detect both the socket and the card. How are you loading that kernel? If you're using FILO or another payload to read it off the CF card, note that the Ricoh PCMCIA chip is a little peculiar. If it is set up to behave comfortably for simple payload ATA drivers, it doesn't get along well with the kernel drivers, and vice versa. There is a hack (resetcf.c in coreboot utils repo) that resets the Ricoh, intended to run out of initrd/initramdisk. IIRC I used a DOM with this board to get around the CF trouble. I did spend some time with it but didn't find a really satisfactory solution. Lately the resetcf.c code was included into FILO, so maybe that works for you. > The problem I have is that I have to boot the kernel with the > irqpoll option otherwise I get "qc timeout (cmd 0x91)" and "failed > to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x4)" errors when the > pata_pcmcia module is inserted and the card is not accessible. .. > Are the interrupts setup by the yenta-socket module or the > pata_pcmcia module, which one should I start to look at? Neither. They are set up by coreboot, and because noone has tested this board successfully in quite a while it is entirely possible that something has broken since 2006 when I had it in my car. :) Maybe better move over to the coreboot list though. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Pcmcia: 16 bit card does not work in 2.6.18+ kernel
(Please don't cc me, I get mails from the list. Thanks! :) pius.br...@t-systems.com wrote: > Peter: What modules do you mean when you say "Something is wrong > with the setup"? I have no idea. Sorry I couldn't be more helpful. > We did some more based on Wolfram's hint: > > We compiled the kernel 2.6.18 with the "drivers/pcmcia/ti113x.h" > from the working kernel 2.6.9. Did'nt have any effect. The error is > still the same. I am not surprised. To really find the problem change in the source I recommend that you use git bisect: http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html http://kerneltrap.org/node/11753 //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Pcmcia: 16 bit card does not work in 2.6.18+ kernel
pius.br...@t-systems.com wrote: > 0 = No PC Card functional interrupt detected (default). > 1 = PC Card functional interrupt detected. .. > So it seams the there is a problem with the IRQ. > Can anybody confirm this estimation? I disagree. > Any idea, how to set "Card Control" to "1". I believe the register in question only mirrors the current state of the interrupt signal. Such registers can be found also in other bridges. This register bit is read-only and is set only by hardware. It should become 1 again when the card is delivering interrupts. Something is wrong with the setup, causing it to not run. You could always bisect between working and non-working kernels to find the commit which breaks the support. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Problem with exclusive interrupt in hostap_cs
Larry Finger wrote: > I would have no problem changing the driver interrupt registration > in the link->irq structure, but I was not quite sure how change > prism2_interrupt() to detect the shared case when the interrupt > status register is 0x. Another option would be for Jack to try the orinoco_cs driver. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: pcmcia disk drive not detected
Hi John, John McGrath wrote: > IT just does not seem to get picked up by pata_pcmcia. > > prod_id(1): "CNF " (0x46d7db81) > prod_id(2): "CD-ROM" (0x66536591) > prod_id(3): "I2" (0xe96ca5cc) Try adding a PCMCIA_DEVICE_PROD_ID123 line with these strings and numbers to the end of pata_pcmcia.c //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: pata_pcmcia client driver
kiran vedere wrote: > Interface to read/write CF Storage cards. I implemented the CF Host > Controller and I am using the existing pata_pcmcia client driver to > read/write to a Compact Flash Storage Card. Nice. > However when I insert the Card I cannot see any ata block device > which I can use to mount the card. Note that you will need SCSI disks enabled in your kernel to get a device, because all sata_ and pata_ drivers piggyback on the SCSI layer. > Below are the messages when I insert the card (I enabled debug > messages and also added my own). .. > ata1: PATA max PIO0 cmd 0xc8818030 ctl 0xc8818050 irq 24 The "SCSI" controller is found. That's good. > probe begin > port EH scheduled > ata_scsi_error:ENTER > ata_port_flush_task:ENTER > ata_port_flush_task:EXIT > ata_bmdma_error_handler:ENTER > ata_bmdma_drive_eh:ENTER > ata_bmdma_drive_eh:qc=0x0 > ata_eh_link_autopsy:ENTER > ata_eh_recover:ENTER > ata1 port frozen > ENTER > ata_std_softreset:ENTER > about to softreset, devmask=0 > ata1: bus reset via SRST Maybe not so good? The port appears to have frozen and is then reset. > found ATA device by sig > found ATA device by sig > EXIT, classes[0]=9 [1]=9 > ata_std_postreset:ENTER > EXIT, no device > ata1 port thawed Two ATA devices seem to be found, but I don't know what "by sig" means. I also don't know what classes[] means. In the end, whatever was found does not qualify as a device anyway. > I was able to use /sys/bus/pcmcia/devices/ to read some CF card > details such as Manf_ID/Prod ID, etc however there was no > /sys/bus/scsi entry available. > > Do I need anything more to access the CF Storage card or I am > missing any of the steps in the process? Please clarify. Again, you need CONFIG_BLK_DEV_SD. Perhaps it will be more fruitful to contact linux-scsi or wherever you can find libata experts. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Possible bug in ide_cs module
Dave Flogeras wrote: > Let me know if you need any more info/testing I would suggest using pcmcia_pata instead. I don't think it has the same issues. (And ide_cs doesn't do DMA either, right?) //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: OZ6933 and atheros NIC
Komuro wrote: > Currently, the pcmcia-maintainer Dominik does not respond at all. It seems he does pcmcia work in bursts. Every 3-4 months or so there is usually a bunch of activity. > Could you post your patch to linux-kernel mailing list > if you want? Unless you can afford to wait for Dominik's next burst. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: pcmcia compact flash recognized, but not mounted
striper wrote: > Jan 5 14:57:59 d600 kernel: pccard: PCMCIA card inserted into slot 0 > Jan 5 14:57:59 d600 kernel: pcmcia: registering new device pcmcia0.0 OK so far, but.. > It actually isn't important to me that it automount ... but I > haven't figured out how to mount it by hand. ..you should also see a new storage device. > Any help would be appreciated. Try enabling CONFIG_PATA_PCMCIA or CONFIG_IDE_CS in your kernel configuration. They are the two options for generic PCMCIA storage devices such as CF cards. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Dell Inspiron 5150 PCMCIA troubles
Alex Buell wrote: > I'd like to report a problem with my Dell Inspirion 5150. Inserting a > PCMCIA cardbus card causes a freeze, everything just locks up solidly. Unfortunately this problem description does not have very much helpful information with regard to finding the problem. :\ Please try several different cardbus cards. Please try setting up a serial console in the hope that you can get some useful error messages from the kernel on card insertion. > Gentoo Linux on this laptop, release 2.6.25-gentoo-r7. Please also try syncing portage and emerging the latest sources. Please try both gentoo-sources and vanilla-sources. Until you've confirmed the same behavior with vanilla-sources I don't think anyone on the list will put much effort into the problem. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [PATCH 39/39] pcmcia: don't add extra DEBUG cflag bugfix
On Thu, Aug 21, 2008 at 11:55:49PM +0200, Dominik Brodowski wrote: > > There is one warning left in the compilations, namely > > > > CC [M] drivers/pcmcia/cardbus.o > > include/asm/io_32.h: In function ???memcpy_fromio???: > > include/asm/io_32.h:151: warning: passing argument 2 of ???__memcpy??? > > discards qualifiers from pointer target type > > > > I don't know how to get rid of it, but I'll look for your fix. > > Hm, that doesn't seem to be pcmcia-specific... still, if you find a > fix for it, I'm all ears. It's caused by the following line in pcmcia/cardbus.c:read_cb_mem(): memcpy_fromio(ptr, s->cb_cis_virt + addr, len); s->cb_cis_virt is void __iomem * per include/pcmcia/ss.h while memcpy() takes const void * for argument 2. I don't have a recent tree, but adding a cast to the call should silence the warning: memcpy_fromio(ptr, (const void *)s->cb_cis_virt + addr, len); //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [PATCH 10/23] pcmcia: switch cm4000_cs.c to unlocked_ioctl
On Mon, Jul 14, 2008 at 10:14:12AM +0200, Dominik Brodowski wrote:
> if (test_bit(IS_CMM_ABSENT, &dev->flags)) {
> DEBUGP(4, dev, "CMM_ABSENT flag set\n");
> - return -ENODEV;
> + goto out;
> }
> + rc = EINVAL;
Shouldn't this be rc = -EINVAL; ?
//Peter
___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: PCMCIA Client Drivers for accessing CF Storage Card
On Thu, Jun 19, 2008 at 02:44:35PM -0400, kiran vedere wrote: > 2. The TrueDMA mode also supports Multiword DMA and Ultra DMA modes of > data transfer. How does the pata-pcmcia Client Driver support these > modes? I believe it doesn't, I think pata_pcmcia only does PIO. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: problem z karta flash pcmcia
On Wed, Jun 04, 2008 at 04:40:20PM +0200, [EMAIL PROTECTED] wrote: > Witam, Sorry, do not understand polish. Please repost in english. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Segmentation fault when running binaries off a CF card on arcom pxa255 SBC
On Thu, Apr 24, 2008 at 06:10:21PM -0700, Ajay Pal S Grewal wrote: > In general it has been observed that any binary residing on > /dev/hda1 partition (mounted on /usr) when executed for the first > time, second or even third time gives segmentation fault. However, > it is able to run fourth time and onwards. Examples: > ... > > [EMAIL PROTECTED] bin# pwd > /usr/bin > [EMAIL PROTECTED] bin# ./scp > Segmentation fault > [EMAIL PROTECTED] bin# ./scp > usage: scp [-1246BCpqrv] [-c cipher] [-F ssh_config] [-i identity_file] >[-l limit] [-o ssh_option] [-P port] [-S program] >[EMAIL PROTECTED]:]file1 [...] [EMAIL PROTECTED]:]file2 Have you verified using a separate system that the source file you copied and the new file on CF are identical? (Please boot the system only using old files on MTD to get checksum on the system. Put the CF in a CF reader on another, trusted, system to get checksum of the copies.) If it was reliably a single failure maybe dynamic linking could be blamed. I am not sure since you say that it sometimes takes more retries before the binary work. Another matter is the CF - maybe there is a bit error and sometimes internal error correction in the CF will fix it, sometimes it gets the bit wrong. Are your flash cards new? Could you try more than two easily? It would be interesting to see ldd and strace for some binaries that you try to execute. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [2.6 patch] the long overdue pcmcia_ioctl.c removal
(Really cross-post like this?) On Wed, Feb 27, 2008 at 08:44:07PM +, Russell King wrote: > TBH I've given up trying to fight this continue "lets remove these > IOCTLs which no one uses" crap. Obviously, _I_ use them. I suppose critical mass or other powers that be have decided they aren't good enough. If your userspace will never change, settling on a kernel as well shouldn't be too big a deal. Closed source sure sucks. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: PCMCIA wireless CDMA card
On Mon, Feb 18, 2008 at 09:00:34PM +, Russell King wrote: > However, I'm not sure if its worth submitting into the kernel tree > or not - are these cards current technology? Better working support for old technology than broken. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Orinoco IRQ problem?
On Sat, Feb 09, 2008 at 08:51:11AM +0900, Komuro wrote: > Please add > exclude irq 3 > to /etc/pcmcia/config.opts. Sorry, this will not work with 2.6 kernels no longer using pcmcia-cs. I don't know how to exclude interrupts from PCMCIA allocation in 2.6. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Unable to access PCMCIA with O2 Micro OZ711MP1/MS1
On Mon, Feb 04, 2008 at 03:01:44PM +0100, Mader, Alexander (N-MSR) wrote: > I hope I am contacting the appropriate list for this. Please, let > me know if I should search somewhere else. This is probably the right place, but I'm afraid you probably will not get much help since there is not a lot of activity here. You could also try sending a message to lkml, with just a summary of the problem. Perhaps someone there knows more about it. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: pcnet_cs: use axnet_cs instead
Hi Diego, On Fri, Jan 25, 2008 at 07:01:46PM +0100, Diego Rondini wrote: > I have a PCMCIA net card with no brand. During boot up kernel says: > > pcnet_cs: this is an AX88190 card! > pcnet_cs: use axnet_cs instead. > pcnet_cs: unable to read hardware net address for io base 0x300 .. > I tried manually blacklisting pcnet_cs (with success) and manually > modprobing axnet_cs (with success) but still no interface is found > in /sys/class/net. I think this is your best chance of success. Do you get any kernel messages (dmesg) when loading axnet_cs? I would recommend you to build a new kernel for your system with everything you need built-in and modules completely disabled. Then insert the card and see if the axnet_cs driver is picked up and initialized at all. > I'm asking here because the problem seems to be related from the > change from pcmcia-cs to pcmciautils. I understand, but keep in mind that pcmcia-cs has not been replaced by pcmciautils. Much of what pcmcia-cs used to do is now within the kernel. pcmciautils are much less involved. (A good thing since more generic kernel stuff like udev is made available "for free" but yes, there is certainly a migration cost for users.) One of these things is binding drivers to cards. That used to be the job of cardmgr, but now the kernel does it, through the device table in each driver, which lists the cards that the particular driver works for. I would suggest adding an entry in the table for your card and rebuilding the driver to see if it now binds to the card. Insert the card and run lspcmcia -v or worst case pccardctl ident, then we can help you with the proper values to put into the device table for your card. (If you want to experiment yourself have a look at /usr/src/linux/Documentation/pcmcia/devicetable.txt) > P.S.: if you need more infos about quite the same problem (same > error, similar cards): > http://ubuntuforums.org/showthread.php?t=400105 > http://ubuntuforums.org/showthread.php?t=141739 > http://ubuntuforums.org/showthread.php?t=264954 > http://cnycomputerservice.com/deblap.html Aye. I suppose the intent was to add the neccessary IDs to the axnet_cs device table as soon as bug reports came in, too bad not many have shown up here. Let's hope we can get it working for you! //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Yenta TI on MIPS
On Fri, Jan 18, 2008 at 07:31:03PM -0700, RB wrote: > > What does the oops look like? > Here's one from the crash induced by reading I365_INTCTL; Symbol names would help. But I think you should find MIPS experts who can help you sort out the low level problem. Try linux-mips or simply lkml for a good mix. Once the bus is back in order we may be able to help. (Maybe) > I don't have the rest immediately available, but this thread has > most of what I've posted on this: > http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/506 I'll have a look. > Data bus error, epc == c00c4178, ra == c00c5c94 > Cpu 0 > $ 0 : 1000a800 c00aa000 8024 > $ 4 : 803ab000 0001 0001 > $ 8 : 80239b00 8024 8028 8028 > $12 : 8028 80e03bd2 80278d04 > $16 : 8011 0066 803ab000 8011 > $20 : c00d 1000 80023454 c00d > $24 : 80203c24 > $28 : 80e02000 80e03ce0 c00d c00c5c94 > Hi: 0063 > Lo: 126fa800 > epc : c00c4178 Not tainted > Using defaults from ksymoops -t elf32-i386 -a i386 Register dump is good, but.. > Cause : 001c > 803ab000 8011 c00c5c94 c00c5b1c 802c20ec 1000 > 0066 > 0066 80e03d48 1066 c00d c00c54b0 > c00d > 80108b28 80108aa0 802c2000 c00d 803ab000 c00c89ac 802c20b0 > c00c9018 > 0200 003e 0028 802100c3 802c0340 1c00 1c000fff > 80e8ebc0 > Call > Trace:[<8011>][<80023478>][<8011>][<8011>][][][][<80108b28>][<80108aa0>][][<801287c8>][<8010ed2c>][<8012c2a4>][<801f7f5c>][<800bd85c>][<8012c714>][<8012af2c>][<800f9570>][<8012c5ac>][<8012b098>][<801287c8>][<8012b4b8>][<80066a34>][<8010ef44>][<80047898>][<8000bc60>][<8024b920>][<8024b920>] > Code: afb00018 8c82000c 00809021 <90500803> 3c11c00d 321000ff > 3c028002 3c05c00d 26249040 This doesn't mean much.. Enable the option to include the symbol table in the kernel for oops printouts. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Yenta TI on MIPS
On Fri, Jan 18, 2008 at 12:28:23PM -0700, RB wrote: > Specifically, when yenta_socket tries to disable interrupts by > writing 0x0 to CB_SOCKET_MASK or check if they're enabled by > reading from I365_INTCTL (ti_init in ti113x.h), the driver loading > fails with a data bus error and there's a resulting oops. > > Any hope you guys could help me work this out? This is tough to debug. What does the oops look like? //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Question regarding IRQF_SHARED and pcmcia driver
On Fri, Jan 11, 2008 at 03:25:23PM -0800, Kristoffer Ericson wrote: > > > pcmcia (16bit). hd64461 is a companion chip that provides > > > features like pcmcia, lcd,... > > > > Ok. Is it actually a PCI device? If not, the driver for it should > > probably be a platform driver, like ISA hardware drivers. > > > > I had to do some digging to find an example of this in the > > kernel, there aren't that many simple ISA drivers left. > > Hmmm, I've never actually considerd that. I assumed all PCMCIA > systems were PCI similiar. CardBus is much like PCI. PCMCIA not so much. > > So then you should be taking care of the interrupt, right? > > I install a handler to take care of both interrupts (pccard & slot) > but it then looks where the interrupt came from and if its > generated by the pccard it returns IRQ_NONE to let the driver > interrupt handler take care of it. For this to work there must obviously be a card driver loaded when the interrupt comes, yes. Are you testing this with a card yet? I guess so, otherwise you wouldn't be getting card interrupts. Until the card driver succeeds in (also) requesting the interrupt you'll for sure continue to see the oops. > > Also in this case you would already have identified the source as > > being the socket rather than a card - which is actually a stronger > > indication that your driver needs to take action. > > All slot interrupts (card status changed.../../) is detected > properly and forwarded through the pcmcia subsystem. However when a > pccard interrupt is generated I get a kernel oops "nobody cared". Ok, so then your controller driver is pretty much done and you're looking at writing a card driver, right? > >From what I can see the slot is working as it should but no > >handler for the pccard interrupt is available. "pccard" can be ambiguous, let's try to reserve that term for the Linux subsystem so I don't get confused. :) Indeed the slot seems to be working properly, and you have an issue with a card driver. But then we're not talking about the hd64461 anymore, right? > > > This driver is based on an old one which used port-translations, > > > you know the crappy PORT 0xblablabla = (real adress) 0xblobloblo, > > > > Hm - no? > > This existed in LinuxSH tree until 2.6.19, in essence everything > was considerd a port number. The number was then translated into > the real adress whenever access was needed. No idea why it was > implemented. > > >From what I gatherd from Paul (linuxsh maintainer) it was to fix > >some problems on other archs rather than SuperH specific. > > Anyhow this has been removed so now we are working with real > adresses. It created alot of issues for me though since I needed to > remake the driver, theres always a chance that I translated a port > adress wrong. I have never ran or even seen a SuperH platform I think, and have not been hacking around all that much in pcmcia land either, so I don't think I've come across this. Anyway, I understand the problem, may be a good idea to double check those translations. > > I guess you'll have to add gobs of printk() to find out what is > > actually happening. > > I was thinking to add printk's to the orinoco driver since I have > such a card here. It has worked in the past and could perhaps give > me some info during the probing. If it fails to probe the device > properly I must have some configuration/memadress wrong. Sounds like a good plan! //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Question regarding IRQF_SHARED and pcmcia driver
On Fri, Jan 11, 2008 at 01:20:58AM -0800, Kristoffer Ericson wrote: > > > 2) Best way to reserve pccard irq interrupt? And does the > > > handler get replaced by the proper driver handler? > > > > Again, do you mean cardbus or pcmcia? And what exactly is the > > hd64461 - card host or card? > > pcmcia (16bit). hd64461 is a companion chip that provides features > like pcmcia, lcd,... Ok. Is it actually a PCI device? If not, the driver for it should probably be a platform driver, like ISA hardware drivers. I had to do some digging to find an example of this in the kernel, there aren't that many simple ISA drivers left. > > > From what I can tell the socket interrupt is working fine > > > (detecting changes properly) but everytime it pushes IRQ_NONE > > > (interrupt ment for pccard interrupt) it oopses with "nobody > > > cared..". > > > > Because there is no driver that requested the irq I guess? > > Haven't thought about it like that, but you are correct. I always > suspected the driver simply had issues getting the irq, but it > could also mean that no driver is loaded (and thus no irq request). So then you should be taking care of the interrupt, right? Also in this case you would already have identified the source as being the socket rather than a card - which is actually a stronger indication that your driver needs to take action. > This driver is based on an old one which used port-translations, > you know the crappy PORT 0xblablabla = (real adress) 0xblobloblo, Hm - no? > so I might have gotten an adress wrong and in there > caused the driver to fail its probing. Thoughts? I guess you'll have to add gobs of printk() to find out what is actually happening. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [PATCH] [Coding Style]: fs/ext{3,4}/ext{3,4}_jbd{,2}.c
On Fri, Jan 11, 2008 at 12:42:40PM +0900, Paul Mundt wrote: > How about throwing out hand-rolled debug printk wrappers for the > brain-damage they are and using the ones the kernel provides > instead? Sounds great! //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [PATCH] [Coding Style]: fs/ext{3,4}/ext{3,4}_jbd{,2}.c
On Thu, Jan 10, 2008 at 10:03:58PM +0100, Roel Kluin wrote:
> -#define DEBUG(x,args...) printk(__FUNCTION__ ": " x,##args)
> +#define DEBUG(x, args...)printk("%s: ", __func__, x, ##args)
Can this really be expected to work when x contains conversions?
How about:
#define DEBUG(x, args...) printk("%s: " x, __func__, ##args)
//Peter
___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Question regarding IRQF_SHARED and pcmcia driver
Hi, On Wed, Jan 09, 2008 at 09:02:57PM -0800, Kristoffer Ericson wrote: > Still debugging hd64461 pcmcia driver. My best guess is that it for > some reason cannot register the pccard irq and therefore bugs out > when socket IRQ returns IRQ_NONE. Is this an "ISA" device? pccard=pcmcia or pccard=cardbus? The socket itself has one interrupt, which will be used at least for Cardbus cards, which are really just PCI devices AFAIK. PCMCIA is more like ISA and it may not neccessarily be the same interrupt that is used for them? > More specificly I suspect it tries to request the pccard irq > without IRQF_SHARED flag and therefore is unable to aquire it. > > Anyhow, short questions: I'll speculate a bit, maybe it'll help. > 1) purpose of socket->functions? I see its checked in > pcmcia_request_irq and if > 1 it should set pccard IRQ to type > IRQF_SHARED. > I thought if socket.irq = pci.irq it would guess that its dealing > with a shared interrupt. I think socket.irq will always be = pci.irq since the socket is pretty much the PCI device. I don't know exactly how linux-pcmcia works, maybe socket->functions is linux-pcmcia interrupt sharing for PCMCIA cards? > 2) Best way to reserve pccard irq interrupt? And does the handler > get replaced by the proper driver handler? Again, do you mean cardbus or pcmcia? And what exactly is the hd64461 - card host or card? > From what I can tell the socket interrupt is working fine > (detecting changes properly) but everytime it pushes IRQ_NONE > (interrupt ment for pccard interrupt) it oopses with "nobody > cared..". Because there is no driver that requested the irq I guess? //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [PATCH] pcmcia: include bad CIS filename in error message
On Wed, Nov 28, 2007 at 03:17:13PM -0800, Randy Dunlap wrote:
> if (strlen(filename) > 14) {
> - printk(KERN_WARNING "pcmcia: CIS filename is too long\n");
> + printk(KERN_WARNING "pcmcia: CIS filename is too long [%s]\n",
> + filename);
> return -EINVAL;
> }
Why is this check there anyway? Is there a filename length limitation
in request_firmware() ?
//Peter
___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: CompactFlash performance - pio5 and pio6 on TI1510 (no DMA)
On Tue, Nov 20, 2007 at 12:06:54AM -0500, Iain Barker wrote: > System is running Linux 2.6.23, using yenta ide-cs One thing you could try is the pata_pcmcia driver instead. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [BUG] New Kernel Bugs
Please stop cross-posting this thread at least to linux-pcmcia until your post is relevant to PCMCIA. Sorry for being a bore. (Not that I don't love reading LKML discussions, but I found that it took too much time, and now they're over at linux-pcmcia too! :) Thank you in advance. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Sandisk 6-in-1 card reader
On Sun, Nov 11, 2007 at 05:07:53PM +, Michael Robb wrote: > Any suggestions on what I can do to get the card to work? .. > hde: MEMORYSTICK, CFA DISK drive > ide2 at 0x100-0x107,0x10e on irq 3 This indicates that you're using the old ide-cs driver (under CONFIG_IDE in the kernel config) and I would like to suggest that you try to use the new libata based pata_pcmcia driver (under CONFIG_ATA) instead. Disable CONFIG_BLK_DEV_IDECS and enable CONFIG_PATA_PCMCIA. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Problem with pcmcia serial GPRS/EDGE modem
On Wed, Oct 10, 2007 at 10:23:58PM +0200, Grzeniek wrote: > found is if i boot system with kernel parameter acpi=off everything > work great. I have got transfer about 20KB/s. When I boot with acpi > enabled I have transfers about 900B/s and a lot of ppp0 rx errors > (about 25%). Please provide dmesg output from a boot with ACPI and another one without ACPI. > I tried few Linux distributions (FC5, FC7, Ubuntu 6.04, Ubuntu > 7,04, Ubuntu 7.10). It may be useful to build your own kernel from vanilla sources. > I still don't know if this problem is related to pcmcia > (yenta_socket), Note that yenta_socket is not PCMCIA, but CardBus, as Dominik pointed out. > I really need to have this modem working, Well then maybe you will have to stay with acpi=off. But please send dmesg output so someone can compare them and maybe come to a useful conclusion. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: old bug report PCMCIA and diskless
On Fri, Oct 05, 2007 at 02:34:59PM -0700, Stephen Hemminger wrote: > See: > http://bugzilla.kernel.org/show_bug.cgi?id=3258 > > Is it still a bug? Isn't this the same issue as with all other pluggable buses? Ie. that they are handled by separate kernel threads, and when the kernel wants to mount root it doesn't (and shouldn't, at least not by default) wait for any of them. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: speedstream wlan card
Hi Gerald, On Mon, Sep 17, 2007 at 09:04:11PM +0200, Gerald Willmann wrote: > Hi Peter: thanks for your reply. I have to admit that I'm just a > simple user. It is polite to keep the discussion on the mailing list. I write to the list partly in order to help people who ask for help, but more importantly to help people who search the archives in the future. This only works when the mailing list forum is respected. > How would I add those checksums to the driver. Looked at modinfo > orinoco_cs but that did help me. It requires making a one line addition to the driver source code. If you don't think you can do it all on your own I'd be happy to make a patch for you - which you could apply to your kernel sources and after a rebuild of your kernel and reboot/driver reload the driver should bind to the card. If this is all too much then I guess you're stuck waiting for the patch to first make it into the upstream kernel branch, and then from there into your distribution of choice - which probably takes a couple of months. Again, please make sure to keep the discussion on the mailing list. This goes for every single open source project. Mailing lists will usually have headers in the email message that allow smart email programs to recognize that the message came from a list, and offer a special list reply function. Very useful feature but unfortunately not ubiquituos quite yet. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: speedstream wlan card
Hi Gerald, On Mon, Sep 17, 2007 at 02:57:31PM +0200, Gerald Willmann wrote: > prod_id(1): "Siemens" (0xd936153f) > prod_id(2): "SpeedStream Wireless PCMCIA" (0xbe6a5a90) > > but no driver gets loaded and if I modprobe orinoco_cs by hand it > doesn't seem to find the card. Could someone pls point me in the > right direction towards getting this to work again. Many thanks, Those two CRC32 checksums in paratheses need to be added to the driver so the driver knows it works with this card. Please send a patch once you've got it working. Thanks! //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Mon, Aug 13, 2007 at 10:09:46AM -0600, Bjorn Helgaas wrote: > > [ 2207.986873] smsc_ircc_present: can't get sir_base of 0x2e8 > > As of 2.6.23-rc2, we should have: > - probes for 8250 legacy devices (as in 2.6.21 and previous) > - smsc PNP probes turned off by default (2.6.21 and previous had > no PNP probes for smsc at all) > - some complicated PNP quirks for SMCf010 devices > > In other words, I think we're basically back where we started. The > 8250 driver should find a ttyS3 device at 0x2e8, and it should > claim those ports, which will prevent smsc from claiming them. I use 8250.nr_uarts=1 appended to my kernel parameters on my laptop. Perfectly reliable workaround, but if it is possible to detect, then all the better! //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Very slow disk access via PCMCIA adapter
On Sat, Aug 11, 2007 at 08:35:56AM +0100, Simon Atkinson wrote: > The stages described above take similar lengths of time when I > issue the equivalent commands via a terminal window at the command > line. This is the only metric that should be used to diagnose the problem. > Any ideas what the problem is? I think there are several. > cardmgr This is the first. cardmgr is deprecated and should not be used. > Linux version 2.6.19 There are many newer kernels out there.. > Yenta: ISA IRQ mask 0x06b8, PCI irq 11 Everything in your laptop seems to use IRQ 11. > pcmcia: Detected deprecated PCMCIA ioctl usage from process: cardmgr. > pcmcia: This interface will soon be removed from the kernel; please > expect breakage unless you upgrade to new tools. > pcmcia: see http://www.kernel.org/pub/linux/utils/kernel/pcmcia/pcmcia.html > for details. So, please check that webpage out, and get rid of cardmgr. > pccard: PCMCIA card inserted into slot 1 > cs: memory probe 0xa000-0xa0ff: excluding 0xa000-0xa0ff > cs: memory probe 0x6000-0x60ff: clean. > pcmcia: registering new device pcmcia1.0 > Probing IDE interface ide2... > hde: IBM-DSCM-10512, CFA DISK drive > ide2 at 0x100-0x107,0x10e on irq 3 > hde: max request size: 128KiB > hde: 1052352 sectors (538 MB) w/60KiB Cache, CHS=1044/16/63 For some reason the card gets irq 3 while the controller has irq 11. > hde:<4>hde: lost interrupt > hde: lost interrupt > hde: lost interrupt > hde: lost interrupt > hde1 > ide-cs: hde: Vpp = 0.0 > hde: lost interrupt > hde: lost interrupt And here is some fun. No interrupts are coming through, which probably leads to long timeouts here and there in the IDE code. Try 2.6.22.1 with pata_pcmcia, get udev and pcmciautils and get rid of cardmgr. That may just work out of the box. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Re[2]: Compact Flash Card in PCMCIA Adapter
On Wed, Aug 08, 2007 at 04:55:40PM +0200, Felix Brack wrote: > After some more testing I found that the problem must be related > to a specific CF card from Transcend. Aha. > However when I insert the Transcend CF card it is not detected. I > get the following information then: > > from 'pccardctl status' (again socket 1 is the CF card): > > Socket 0: > 3.3V 32-bit PC Card > Socket 1: > 3.3V 16-bit PC Card > > and from 'dmesg' I get only one line: > > [ 5334.476000] pccard: PCMCIA card inserted into slot 1 > > This CF card (the one from Transcend that is not working) supports > Ultra DMA; might this be the problem? No, should work anyway. > I really have no idea of what could be wrong. The tiny bit of > output from 'dmesg' is not really helpful. Is there some kind > of debugging I could enable to get more information? The card ID needs to be included in ide-cs and pata_pcmcia to be bound automatically. Can you try running: pccardctl info pccardctl ident When the card is inserted? Thanks. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Compact Flash Card in PCMCIA Adapter
On Tue, Aug 07, 2007 at 03:46:04PM +0200, Felix Brack wrote: > I'm using a PCMCIA adapter to which I can plug CF cards. I believe > the adapter itself consist of nothing more then 'some wires'. > > Everything was working quite fine with some 2.6 kernel (I do not > remember the exact version) and card manager. Plugging in the > adapter (including CF card of course) loaded the memory_cs driver > and I was able to access the card. Really? memory_cs? How did you access the card? What kind of CF card is it? > Now, with kernel 2.6.20 things don't work anymore. After some > research I found that now 'pcmciautils' is responsible for managing > the PCMCIA adapters (16 and 32 bit?). I believe that the driver the > kernel should load when I plug in my card is 'pcmciamtd'. It depends on the card. If it's a "normal" CF memory card they are usually used in an IDE mode where they behave like a hard drive, using the driver ide_cs (old ATA/ATAPI/MFM/RLL drivers) or pata_pcmcia. (new libata SATA/PATA drivers) Which to choose is mostly a matter of which other ATA drivers you are using in the kernel. ide_cs is tried and proven while the PATA drivers using libata are still marked experimental. (But I've used them without problems for some time.) Both drivers should support the same cards. > I found the source file 'pcmciamtd.c' in the kernel source tree but > I do not know how to enable it. There's one sure way to enable any kernel driver and a second option available for most drivers. 1. Compile the driver built-in to the kernel (*) in menuconfig 2. Compile the driver as a module (M) in menuconfig Built-in drivers are loaded automatically when the kernel is loaded and activated/bound to devices sometimes automatically, sometimes with a little help from userspace. (udev, pcmciautils, etc) Modules have to be loaded into the kernel after it has been started, either manually with the modprobe command or by distribution-specific startup scripts usually found in /etc/init.d. Modules are activated/bound just like built-in drivers. > I think there should be some file called 'pcmciamtd.ko' after > kernel compilation, but there isn't. Is it possible that this > driver always gets linked to the kernel, i.e. there is no module > for 'pcmciamtd'? This depends on your particular configuration. pcmciamtd may not be built at all, or built into the kernel, or built as a module. > I use 'make menuconfig' to configure the kernel, but as I said, I > can't find the switch to turn 'pcmciamtd' on. Does anybody know how > to do this; Make sure you have enabled PCMCIA and then look in the MTD driver section, but.. > maybe this is a very stupid configuration error on my part? ..depending on the CF card pcmciamtd isn't the best driver. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: more about PCMCIA
Hello Karolina, On Mon, Jul 30, 2007 at 03:15:54PM +0200, Karolina Rybak wrote: > Anybody could suggest the best PCMCIA for Linux? > > Any opinions which one to choose and why it is better than others? > > I would be greatful for your help. Answering this is difficult without knowing more about your reason for asking. The question is pretty vague. "PCMCIA" is a bus interface, it standardizes a connector, plug-in card behavior and form factor and more. In the Linux kernel scope there is a PCMCIA API used by drivers for PCMCIA controllers and cards. If you are looking for a PCMCIA controller to include in a system that your are designing we could probably help but I would also suggest looking at the kernel sources for a list of supported controllers. (There is a known issue with Ricoh RL5C476 controllers that may be a hardware problem so you may want to investigate that if you're looking at that particular part.) If you are looking for a PCMCIA plug-in card you would need to say what type of card in order to get some suggestions. Note that PCMCIA plug-in cards are rare these days, rather Cardbus plug-in cards are the norm because of their higher performance. Cardbus does require a Cardbus controller, and a PCI bus in the machine. If you are looking for the right software packages to use in a GNU/Linux system in order to get both PCMCIA and Cardbus plug-in cards to work the answer is that for 2.4 kernels you need the pcmcia-cs package from your distribution or from sourceforge, while for 2.6 you need udev which is already a central component in several distributions. With 2.6 it's also useful to install the pcmciautils package. Hope this helps. If not, please tell us more about what you are doing and why. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: PCI1620 with an integrated memory card reader
On Sat, Jul 28, 2007 at 11:25:39PM +0300, Cristian Onet wrote: > I have realized that the problem was the way that the PIO data > transfer was made in pata_pcmcia. It was on 16 bits and it seems > that the emulated ATA device only handled 8 bit transfers Good find! > I would really like to share this with other users of this device > but I don't really know how. Alan (the author of pata_pcmcia) > suggested that the modifications would be better in a new module > (which I named pata_1620). Yeah, that's a good idea. It would also be a natural home for the firmware loading. Might be worth a shot to clean up the driver (I would call it pata_pci1620) and try to get it included in the kernel proper. > I hope it will help whoever needs it. For now the process to set up > the device is very unfriendly but it could be made better. I haven't checked your wiki page but I've seen plenty of out-of-tree modules and setup isn't that awkward; just include a Makefile that builds against /lib/modules/$(uname -r)/build and most would get it to work out of the box. > The first issue would be if the firmware could be distributed with > this Linux driver. This raises some copyright issues... I think. This is a licensing issue that you would have to discuss with the firmware author. I doubt TI will allow re-distribution, but I hope I'm wrong. :) Also, if they do, I don't see Linux distributing the firmware - that would have to be done by you. Anyway, you can always provide instructions and helper utilities to extract the firmware from the Windows driver which is probably distributed free of charge by TI already. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: PCI1620 with an integrated memory card reader
On Thu, Jul 19, 2007 at 07:13:56PM +0300, Cristian Onet wrote: > There is only the firmware loader. Once the firmware is loaded it > should ^^ > provide an ATA interface to any inserted memory card or at > least this is what I understood Sure. Obviously this is not what happens. > This problem was already signaled at > http://bugzilla.kernel.org/show_bug.cgi?id=6991 but, I do not know > why, the developers blamed the firmware loader. Because it is the most likely source of error. Many other memory cards and readers that do not require the firmware loader work without problems. > From what I can tell the firmware loader works just fine because > if it would not (which would mean that we have a bad firmware > loaded) the machine would freeze upon insertion of a card (I know > from experience). The firmware loader is not just responsible for transmitting a firmware to the device. The firmware loader is responsible for communicating with a device and set it up so that it behaves like another, new, device. > My question is: Is there a problem with the pata_pcmcia > implementation or there should be a separate pata_pcmcia_pci1620 > implementation that would handle only this deviece? The third party module is probably causing the problem by not initializing the hardware correctly. A separate driver for this special device is a possible solution, but I think an attempt to fix the special initializer module is a better first step. That needs to be reliable before a separate driver is written anyway. Do you have contact with the developers of the module? Could you point them to these bugs and see if they can help get it fixed? //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: PCI1620 with an integrated memory card reader
On Wed, Jul 18, 2007 at 11:47:02AM +0300, Onet Cristian wrote:
> hde: status timeout: status=0x98 { Busy }
> ide: failed opcode was: 0xde
> hde: drive not ready for command
[..]
> Maybe ide-cs is not appropriate for this kind of device and a
> driver must be written, how are other PCMCIA memory card readers
> handled?
Either ide-cs or pcmcia_pata. You could try the latter driver and see
if it works better, it is the future after all.
> it's a shame that they can't use their hardware just because TI
> only provided a driver for Windows.
It is. You can also let TI and your laptop manufacturer know how you
feel about this, maybe they will listen.
//Peter
___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Aircard 850 on a Thinkpad Z61m
On Wed, Jun 20, 2007 at 06:43:36PM -0400, [EMAIL PROTECTED] wrote: > >> cardmgr[7219]: could not adjust resource: IO ports 0xa00-0xaff: > >> Function not implemented [..] > > cardmgr is deprecated with 2.6, try using pcmcia-socket-startup > > instead. > > Interesting. I am running Debian (unstable) pcmciautils version > 014-3. I ran /lib/udev/pcmcia-socket-startup, and no TTY gets > assigned to the Aircard. A tty does get assigned after I run > cardmgr. As I mentioned before I'm running kernel 2.6.18-3. I'm afraid I can't say whether this is a regression in 2.6.18-3 or just an error in cardmgr. Either way, cardmgr can not work with newer kernels. > When I run cardmgr /dev/modem gets created as a symlink to > /dev/ttyS0. As I mentioned I tried running minicom /dev/ttyS0 and > typing AT but did not see the text showup. The "Function not implemented" errors mean that cardmgr is unable to do things it wants to do to get the card working because the kernel no longer supports that way of doing things. Can you try the latest vanilla kernel? 2.6.21.5? //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Aircard 850 on a Thinkpad Z61m
On Wed, Jun 20, 2007 at 06:18:09PM -0400, [EMAIL PROTECTED] wrote: > cardmgr[7219]: could not adjust resource: IO ports 0xa00-0xaff: Function not > implemented > > Any ideas what is causing the input/output error in wvdial on > /dev/ttyS0? Is that connected to the errors I see when starting > cardmgr? Possible. Just replied in private, but here's the important parts for reference; cardmgr is deprecated with 2.6, try using pcmcia-socket-startup instead. /Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Aircard 850 on a Thinkpad Z61m
On Sun, Jun 17, 2007 at 05:26:45PM -0400, [EMAIL PROTECTED] wrote: > > Sorry, no. :\ Also strange that the device is a network function > > but gets the serial_cs driver. > > Could that be due of the following lines in /etc/pcmcia/config > > card "Serial or Modem" >function serial_port > bind "serial_cs" Not as far as I know, I am under the impression that userspace is not at all involved in associating drivers with pcmcia devices in 2.6. > > Could you send the full dmesg after insertion? > > pccard: PCMCIA card inserted into slot 0 > pcmcia: registering new device pcmcia0.0 Not a lot, is that really all there is? //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Aircard 850 on a Thinkpad Z61m
On Sun, Jun 17, 2007 at 05:09:34PM -0400, [EMAIL PROTECTED] wrote:
> > PCMCIA_DEVICE_PROD_ID12("Sierra Wireless", "AC850", 0xd85f6206, 0x42a2c018),
>
> Thanks Peter, unfortunately this didn't seem to help. Any other
> ideas?
Sorry, no. :\ Also strange that the device is a network function but
gets the serial_cs driver.
Could you send the full dmesg after insertion?
//Peter
___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Aircard 850 on a Thinkpad Z61m
On Sun, Jun 17, 2007 at 03:39:28PM -0400, [EMAIL PROTECTED] wrote:
> lspcmcia returns the following:
>
> Socket 0 Device 0: [serial_cs] (bus ID: 0.0)
> Configuration: state: on
> Product Name: Sierra Wireless AC850 3G Network Adapter R1
> Identification: manf_id: 0x0192 card_id: 0x0710
> function: 6 (network)
> prod_id(1): "Sierra Wireless" (0xd85f6206)
> prod_id(2): "AC850" (0x42a2c018)
> prod_id(3): "3G Network Adapter" (0xab3c6f47)
> prod_id(4): "R1" (0xd9533fec)
>
> Any ideas on what I'm missing?
Perhaps this line anywhere among the other similar lines in
drivers/serial/serial_cs.c in your kernel sources:
PCMCIA_DEVICE_PROD_ID12("Sierra Wireless", "AC850", 0xd85f6206, 0x42a2c018),
//Peter
___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Unable to access PCMCIA/CF Card in Common Memory Mode (neewbie)
Hello, why send your email twice? It never helps. On Fri, May 18, 2007 at 12:07:40PM +0530, Gururaja Hebbar K R wrote: > ide-cs: ide_register() at 0xc2802000 & 0xc280200e, irq 22 failed I guess the IRQ sharing requires special love in all drivers. > I have installed pcmciautil tools but none is running on startup. > is their any scripts or tools that i need to call at system > startup. pcmcia-socket-startup, if a CIS override file is needed for your CF cards. > # lspcmcia -v > Socket 0 Bridge:[69xx_cf] (bus ID: 69xx_cf) > Configuration: state: on ready: yes > Voltage: 3.3V Vcc: 3.3V Vpp: 0.0V > Available IRQs: none > Socket 0 Device 0: [-- no driver --] (bus ID: 0.0) > Configuration: state: on > Product Name: HITACHI FLASH 5.0 > Identification: manf_id: 0x0007 card_id: 0x > function: 4 (fixed disk) > prod_id(1): "HITACHI" (0xf4f43949) > prod_id(2): "FLASH" (0x9eb86aae) > prod_id(3): "5.0" (0x0f7e1efb) > prod_id(4): --- (---) See if adding the ids for this flash device to the ide_cs and pata_pcmcia drivers helps. Look at the source and the mailing list re a Transcend flash that was added very recently. See /usr/src/linux/Documentation/pcmcia/ too. If your bridge driver is correct then it should work. The IRQ issue worries me though. :\ //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [PATCH] ide-cs: recognize 2GB CompactFlash from Transcend
On Fri, Apr 27, 2007 at 07:01:43PM -0700, Andrew Morton wrote:
> This one-liner is turning into a fiasco.
> diff -puN
> drivers/ide/legacy/ide-cs.c~ide-cs-recognize-2gb-compactflash-from-transcend
> drivers/ide/legacy/ide-cs.c
> ---
> a/drivers/ide/legacy/ide-cs.c~ide-cs-recognize-2gb-compactflash-from-transcend
> +++ a/drivers/ide/legacy/ide-cs.c
> @@ -401,6 +401,8 @@ static struct pcmcia_device_id ide_ids[]
> PCMCIA_DEVICE_PROD_ID12("TOSHIBA", "MK2001MPL", 0xb4585a1a, 0x3489e003),
> PCMCIA_DEVICE_PROD_ID1("TRANSCEND512M ", 0xd0909443),
> PCMCIA_DEVICE_PROD_ID12("TRANSCEND", "TS1GCF80", 0x709b1bf1,
> 0x2a54d4b1),
> + PCMCIA_DEVICE_PROD_ID12("TRANSCEND", "TS2GCF120", 0x709b1bf1,
> 0xf54a91c8),
> + PCMCIA_DEVICE_PROD_ID12("TRANSCEND", "TS2GCF120", 0x709b1bf1,
> 0x969aa4f2),
> PCMCIA_DEVICE_PROD_ID12("TRANSCEND", "TS4GCF120", 0x709b1bf1,
> 0xf54a91c8),
> PCMCIA_DEVICE_PROD_ID12("WIT", "IDE16", 0x244e5994, 0x3e232852),
> PCMCIA_DEVICE_PROD_ID12("WEIDA", "TWTTI", 0xcc7cf69c, 0x212bb918),
> _
>
>
> Is this really supposed to add a TS2GCF120 entry with the same IDs
> as TS4GCF120?
That's probably a copy and paste error. 0x969aa4f2 is the correct ID.
> And pata_pcmcia-recognize-2gb-compactflash-from-transcend.patch:
This one is all right so for what it's worth, it gets:
Acked-by: Peter Stuge <[EMAIL PROTECTED]>
//Peter
___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [PATCH] ide-cs: recognize 2GB CompactFlash from Transcend
On Wed, Apr 25, 2007 at 11:27:09AM +0200, Aeschbacher, Fabrice wrote:
> I'm not sure which correct values must be assigned to the 3th and
> 4th parameters (here: 0x709b1bf1, 0xf54a91c8). Anyway, the patch is
> working with these values. Tested on arch=mips.
>
> + PCMCIA_DEVICE_PROD_ID12("TRANSCEND", "TS2GCF120", 0x709b1bf1,
> 0xf54a91c8),
According to /usr/src/linux/Documentation/pcmcia/devicetable.txt and
crc32hash.c the 4th parameter should be 0x969aa4f2.
//Peter
___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: PCMCIA / compact flash / au1x00
On Fri, Apr 20, 2007 at 02:17:28PM +0200, Aeschbacher, Fabrice wrote: > > > CONFIG_BLK_DEV_IDECS=m > > > > Try using the PCMCIA PATA driver instead. > > This does not seem to work either. In this case, which would be the > device? /dev/hda? or /dev/sda? something else? The first of hda, hdc, hde, hdg, hdi etc. that is free. > I tried to run pcmcia-socket-startup, without success. It does not > display any message, neither on stdout nor in dmesg. I tried > without parameters, with 0 then with and 0.0 as parameter. Should not need parameters. > Moreover, 'pccardctl status' display the subdevice 0 as 'unbound' > (should be 'bound', I imagine): Yes. Perhaps the CF device id isn't added to the pcmcia_pata and/or ide-cs drivers. I don't know exactly how to retrieve the number, but I think it's all covered in /usr/src/linux/Documentation/pcmcia/ If the kernel driver doesn't know about the id, userspace tools are required for reading the card CIS and then for starting it up. > # pccardctl status > Socket 0: > 3.3V 16-bit PC Card > Subdevice 0 (function 0) [unbound] > > But the kernel recognizes when I plug the CF card in and out (I can > see messages on the console). Aye, you're good on your way but not quite there. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: PCMCIA / compact flash / au1x00
On Thu, Apr 19, 2007 at 02:42:44PM +0200, Aeschbacher, Fabrice wrote: > CONFIG_BLK_DEV_IDECS=m Try using the PCMCIA PATA driver instead. > Neither hotplug nor udev is installed (I only installed > /sbin/pccardctl). Then you'll have to run pcmcia-socket-startup manually. This may actually work also with ide-cs. Try this before PCMCIA PATA. > I know cardmgr is no more used in recent kernels. Anyway, if I try > to run it, I become following result: It's the wrong fix, don't use it. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Looking for a driver for Compact Flash access
On Sun, Apr 08, 2007 at 08:38:51AM +0200, Michael wrote: > Is connecting a CF directly to the local bus an unusual practice? At least if it's operating as an PCMCIA or IDE device, but probably otherwise too. If you have a local bus just tack on the flash directly. Also I just read that memory mode only gives you 2kb of data since it has 11 address lines. > Would it be significantly easier to connect the CF in IO mode, or > in true IDE mode? Connections don't matter, but memory mode is definately the easiest to program. > Also, using memory mode, what drivers should I consider for using > with minimal adaptation - is it just ide-ata? Check out linux-mtd, but maybe the 2kb isn't worth the effort.. If you're designing a new board just stuff a 2Gbit flash chip on that local bus and be done with it. :) Seriously, it's difficult to impossible to give good advice without understanding even more about what you want to do, how the system will be used and so on, but this is probably not the best forum for that discussion. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: using PCMCIA driver for CF access
Hi, On Thu, Apr 12, 2007 at 08:46:35AM +0200, Michael wrote: > Hi. > It's a long story: > The reason is the HW configuration of the board I have. > The CF is connected to the host bus in memory mode. > In this mode, the CF does not issue interrupts, and utilizing the > IDE code in its current state to work in polling mode is a > significant effort. Aha. And you have no IDE controller. How about linux-mtd then? > We could enable the interrupts in PC Card ATA IO mode, but not in > TRUE IDE mode. The interface in PC Card ATA mode is, well, PC Card > ATA (PCMCIA) compatible. Right, but there's no PCMCIA controller on your host bus, only the PCMCIA card. > This make PCMCIA driver a natural choice Not really.. You would have to implement a PCMCIA controller in software. :( I think linux-mtd does what you want, but I haven't used it myself OTOH. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: using PCMCIA driver for CF access
On Wed, Apr 11, 2007 at 07:04:43PM +0200, Michael wrote: > I have a CF connected in PC Card ATA compatible IO mode. > It is connected directly to the host local bus. > The CPU is MPC8541 PowerQUICC III. > > I'd like to use PCMCIA driver (ide-cs) to access the CF. I still don't understand why you want to PCMCIA drivers when you have no PCMCIA or Cardbus controller. I think the regular ATA drivers or even linux-mtd (Memory Technology Devices) drivers would be a better fit. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: PCMCIA IRQ problems on 2.4.34
On Mon, Apr 09, 2007 at 09:20:41PM -0400, Marc wrote: > but I'm having problems getting an IRQ assigned to it. Does anyone > know the magic kernel options, boot options > Linux Kernel Card Services 3.1.22 > options: [pci] [cardbus] [pm] > PCI: No IRQ known for interrupt pin A of device 00:02.0. > PCI: No IRQ known for interrupt pin B of device 00:02.1. This is bad. > Yenta ISA IRQ mask 0x06b8, PCI irq 0 irq 0, it can not work. > cs: cb_alloc(bus 4): vendor 0x168c, device 0x0013 > PCI: Enabling device 04:00.0 ( -> 0002) > PCI: No IRQ known for interrupt pin A of device 04:00.0. Again, bad. Check /usr/src/linux/Documentation/kernel-parameters.txt and look for anything named irq. Here are some suggestions: acpi=noirq irqpoll pci=biosirq pci=usepirqmask pci=routeirq Check for success by reviewing dmesg and confirming that devices do get valid IRQs assigned. You can also confirm this with: cat /proc/interrupts There you'll also see if interrupts actually arrive as they should. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Looking for a driver for Compact Flash access
On Thu, Apr 05, 2007 at 06:53:07PM +0200, Peter Stuge wrote: > But none of this really applies to you because you have an IDE > device connected to a local bus instead of an IDE controller. I > think the linux-ide developers could help you better. Or possibly linux-mtd of course. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Looking for a driver for Compact Flash access
On Thu, Apr 05, 2007 at 05:07:24PM +0200, Michael wrote: > The CF is connected directly to MPC8541 CPU (PowerQUICC III, > Freescale), via local bus. > It is connected in Memory Mode, with 8-bit interface. > > The questions I have: > 1. What is the appropriate driver? Since memory mode is > PCMCIA-compatible PC Card ATA, I assume it is ide-cs. > Is it right? I don't think so. ide-cs expects an IDE controller, but you don't have one. There is no driver for this hardware yet. Does the hardware support hotplugging? If not, ide-cs is definately wrong. Third, there's pcmcia_ata instead of ide-cs. But none of this really applies to you because you have an IDE device connected to a local bus instead of an IDE controller. I think the linux-ide developers could help you better. > 2. The card doesn't issue interrupts in this mode. I got the > impression the IDE driver relies on interrupts. Does it make it > unusable for accessing a CF in Memory Mode? The non-PCMCIA IDE drivers can do PIO. It makes sense to investigate the IDE drivers because you don't really have any PCMCIA-like hardware. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Question about yenta and the TI1520 PCI-CardBus bridge
On Thu, Mar 01, 2007 at 06:07:55PM -0800, [EMAIL PROTECTED] wrote: > What is a 'yanta-compatible device' and how do I know if a device > is 'yenta-compatible'? Is it related to PCI-CardBus bridges? Exactly. It's the base register interface of most if not all modern Cardbus bridges. > A second question: has anyone successfully gotten the TI1520 > PCI-CardBus bridge to work in linux? Not me. > TI isn't talking to us I would try to find a product using the chip already and do some tests with the peripherals you need. Worst case get some samples and build a simple PCI->Cardbus design of your own. The PCI ID is listed in the yenta_socket driver though, so it might just work. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: PCMCIA on EPIA ITX M12000 problems
On Thu, Mar 01, 2007 at 07:51:41PM +0100, Johan Bilien wrote: > I'm trying to get a WLAN PCCard working on my IPX EPIA MII12000 > board. > By I'm seeing a number of problems. > > First of all I was getting the > kernel: cs: pcmcia_socket0: unable to apply power. [..] > The board has a Ricoh bridge: > :00:0a.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 80) This bridge is known to be problematic. It's even documented in the FAQ. I believe the problem is a lack of knowledge about how to make it behave correctly. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Why separate CIS files in 2.6?
Why not include them within the drivers in 2.6? Licensing? //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: 3c574 NIC support with recent 2.6 kernels.
On Fri, Feb 09, 2007 at 02:21:23PM -0500, cga2000 wrote: > Since I wasn't sure where to look for the correct version of > 3CCFEM556.dat I don't think the CIS files have changed a lot over time. They're bound to the hardware so they either work with a card or not. >, I told the installer that I didn't have a network card, > rebooted into the new system .. found a 3CCFEM556.dat file in the > /etc tree .. pcmcia Version 3.2.8, IIRC, copied/renamed it to > /lib/firmware as 3CCFEM556.cis .. rebooted .. and sure enough > "ifconfig -a" and other tell-tale signs such as boot-up messages > and the light on the NIC's dongle coming on .. showed that the card > had been recognized. Right. This means that the kernel PCMCIA configuration is in order.. > After that it was just a matter of running dhclient to bring up eth0. > > I needed to add the magical "auto eth0" and "iface eth0 inet dhcp" > to /etc/network/interfaces to ensure that all this is done > automatically when I reboot .. and that was it. ..and this part depends on the particular distribution. > I could kick myself for wasting so much time over what turns out to > be a trivial problem. Once you know the solution of course. It was documented though. Whoever created the netinstall system should have taken more care to make PCMCIA work right. Also it shows that reading docs helps if one is stuck. :) > Can't thank you enough for your help. You're welcome. I'm glad that it works. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: 3c574 NIC support with recent 2.6 kernels.
On Sun, Feb 04, 2007 at 11:06:58PM -0500, cga2000 wrote: > > > > > product info: "3Com", "Megahertz 3CCFEM556", "LAN + 56k Modem", "" > > > > > > > > This looks like a 32-bit CardBus card, not a 16-bit PCMCIA card. The 3CCFEM556 is a 16-bit PCMCIA card, not a CardBus card. > > Possibly there's a PCI ID missing from the 3c59x driver. What > > does lspci tell you about the card? Do you have yenta_socket > > loaded so you can see the card in the slot? > > Update: > > rebooted the debian "etch" installer and tried the 3c59x driver but > am still getting the same result.. You're definately looking for the 3c574_cs driver in 2.6 kernels. pcmcia-cs-3.2.8 comes with a .cis and a .dat file for this card, have you made the information within available to the 2.6 pcmcia drivers? See http://kernel.org/pub/linux/utils/kernel/pcmcia/howto.html under "2.5. The difficult cases: CIS overrides" (Basically copy 3CCFEM556.dat to /lib/firmware/3CCFEM556.cis) > are you suggesting that I might need a patched version so my modem/nic > combo is recognized? I think it should just work. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Configure pc card on Mandriva 9.2
On Fri, Dec 22, 2006 at 04:01:51AM -0800, Allein Stark wrote: > Hello! > After inserted the pcmcia in the slot, I face a > problem. As newbie on such subject, I am looking for > help in order to make it running. I proceeded urpmi > install pcmcia. After that I try to see it through > ifconfig -a, nothing similar pcmci is there but eth0 > and only it. > Please, howto configure it to run? Waiting for any > help I thank in advance. More information is required for anyone to help. Boot the system, log in, then insert the card. Then, please tell us: * Version of Linux (the kernel, not the distribution; run uname -r) * Which files are in the pcmcia package (I think run urpmq -l pcmcia) * The output of lspci * The output of dmesg * The output of pccardctl info //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Cardbus Failure "cs: warning: no high memory space available!"
On Tue, Dec 05, 2006 at 04:35:00PM -, Mark Fortescue wrote: > I am using a generic Linux-2.6.16.29 kernel Ouch, that's a bit old. > 1) What (if any) patches need to be applied to the kernel and where > can I get them. I would suggest a fresh 2.6.19 kernel from ftp..kernel.org. > 2) What (if any) special configuration options do I need to set > (build time and/or kernel command line). My current kernel is > mostly not modular. Mine too. You'll need Yenta and either PCMCIA IDE or PCMCIA PATA support, or possibly both of the latter. I've started to use the experimental PCMCIA PATA code with success. > 3) What additional pieces of software do I need (including version > numbers and patches as there appears to be a great deal of > incompatibility between different versions of tools like UDEV). Updating from udev-084/087 to udev-104 made hotplugging work on a system I worked on yesterday. With the older udev I had to run pcmcia-socket-startup manually to get the socket going. Generally, try the latest version of both kernel and udev and see if it works better. There have been a lot of changes lately, all for the better. :) //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: How to investigate PCMCIA driver loading (freeze)
On Thu, Nov 30, 2006 at 09:46:25AM +0100, Fab G. wrote: > Er..yes I meant hostap_cs, but when I load it manually through > modprobe it does not do anything (when orinoco[_cs] is blacklisted). Oh, ok. Then you could try removing the blacklisting and moving away the orinoco_cs driver, then hostap_cs should be used instead. > Ok, I will have to go to the source then. > > IIRC from previous experience with modules, I will need to > recompile the whole kernel and it's going to take some time on this > machine... No need to compile on the target. You can compile the kernel on any other machine and just copy arch/i386/boot/bzImage over to the Pentium system. > My question remains, though, how does the kernel choose which > driver to use when the same card is referenced in both (at least in > wireless/orinoco_cs.c and wireless/hostap/hostap_cs.c) ? I guess > this general selection mechanism must be explained somewhere but I > haven"t been able to find it. I have not fully explored all the > code though. I would assume it depends on the order in which drivers register with the core. My guess is that that depends on the order in which they are built by the kernel build system. That in turn depends on the order in which they were added to the build system since most new additions are simply appended. I don't believe there is (or should be) any infrastructure for arbitration between multiple drivers. The user has to control that. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: How to investigate PCMCIA driver loading (freeze)
On Wed, Nov 29, 2006 at 11:01:03PM +0100, Fab G. wrote: > I know I have the hostap driver available (I can even modprobe it > at will) but it does not seem to be loaded when the card is plugged > in (and no Wifi interface is created). The module I think you want is named hostap_cs, not just hostap. The latter is a set of common code used by hostap_cs, hostap_pci and hostap_plx. If you load hostap_cs it will automatically pull in hostap, but without hostap_cs no driver will care about your card. Please try loading hostap_cs manually. If everything works well then you could compile a new kernel that excludes orinoco_cs but includes hostap_cs to avoid the problem. Of course it would be nice if you also wanted to help debug this problem, but I'm afraid I can't suggest anything simpler than diving into the code to add debug printouts. Well, you could start with a serial console, maybe it would show something that doesn't make it to the syslog file before the system locks up. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: PLEASE HELP! *** DANGER *** unable to remove socket power (***PART1***)
On Fri, Nov 17, 2006 at 11:48:09PM +, Russell King wrote: > Or to put it another way - if we enable the D3 state, do we have > more breakage than if we keep it disabled. > > Since you're the first to report this I suggest that it's far > _safer_ to keep the code as-is. > > However, I no longer maintain PCMCIA, so it's really up to Dominik > to work out what he wants to do about this problem. Are there means of system identification in Linux that would allow yenta_socket to determine what it is running on? ACPI DSDT? Can other systems with this same Toshiba bridge be found for testing? In the long run noone obviously wants any breakage, especially if it only is a matter of formalizing consistent hardware behavior in code. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: udev for pcmcia/cardbus at startup?
On Fri, Nov 10, 2006 at 11:50:46AM -0800, Bill Brelsford wrote: > The cards (network and modem) come up ok, but no udev rules are > applied. > > I'm running Debian sid with a custom 2.6.18 kernel. > > Suggestions? Which udev version? With >2.6.14 and udev>=96 do /sbin/udevtrigger --attr-match=dev to coldplug. With older kernel or udev do /sbin/udevstart These are async. /sbin/udevsettle --timeout=60 will wait for completion. Learnt from /lib/rcscripts/addons/udev-start.sh on Gentoo. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Option error
On Sun, Oct 08, 2006 at 09:51:50PM +0200, Dariusz Dwornikowski wrote: > > Software has to deal with the problem (checking which of several > > IO devices actually yanked the IRQ line) but not all of the Linux > > PCMCIA card drivers in 2.6 do this yet. > > yes, i am using yenta driver. yenta is the socket driver. That's not the problem. The warning comes from the serial_cs driver, which is the card driver for serial port cards. (Which is what the option cards look like.) > is there a even dirty workaround for this problem ? maybe is there a > way to check which interrupts cause the collision ? Well, if you can disable all other sources of interrupts on irq 11 the card will work fine. Most laptop designs just connect all devices to the same interrupt however. :\ You can check how interrupts are connected in your system. This is what mine looks like: --8<-- $ cat /proc/interrupts CPU0 0: 69131347 XT-PIC timer 1: 144940 XT-PIC i8042 2: 0 XT-PIC cascade 3: 2 XT-PIC Intel ICH6 Modem 5:4137359 XT-PIC yenta, ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb5, [EMAIL PROTECTED]::01:00.0 7: 836937 XT-PIC Intel ICH6 8: 62683 XT-PIC rtc 9: 20771246 XT-PIC acpi 10: 8236 XT-PIC uhci_hcd:usb3 11:4333622 XT-PIC uhci_hcd:usb4 12:1059462 XT-PIC i8042 14: 91751 XT-PIC libata 15:126 XT-PIC libata NMI: 0 ERR: 0 -->8-- As you can see I have cardbus, USB and graphics sharing irq 5. In order to change what goes where you'll have to fiddle with interrupt settings in your BIOS, but it's not really possible to change the fact that yenta and radeon are wired together in my case. > i could then not use this hardware during using option > card. It is crucial to make it work for me as I administrate > high-availibility servers. Just a quick reminder; Linux comes with no warranty. But please do feel free to help fix the problem. I know I would appreciate it. :) //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Option error
On Sun, Oct 08, 2006 at 03:30:23PM +0200, Dariusz Dwornikowski wrote: > pcmcia: the driver needs updating to supported shared IRQ lines. > 0.0: ttyS2 at I/O 0x3e8 (irq = 11) is a 16550A The above is indeed the source of your problems. The root evil is that the PC architecture has way too few IRQ lines (signals from IO devices to the CPU that something has happened in the IO device, like that data has come in or that it's now ok to send more data) and computer makers don't care about spending extra $ to improve only slightly on the situation by designing mainboards more carefully. Software has to deal with the problem (checking which of several IO devices actually yanked the IRQ line) but not all of the Linux PCMCIA card drivers in 2.6 do this yet. //Peter ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
root on pcmcia (EPIA-MII rl5c476 slot 1 CF)
I want to boot my EPIA-MII with LinuxBIOS in ROM and kernel and root filesystem on a CF card in the CF slot while still being able to use the Cardbus slot as usual. For added fun it's a Ricoh RL5c476 controller. I've tried 2.6.17.6, 2.6.18rc6 and am currently at 2.6.18rc7. Several issues: 1. Booting Is it possible to let the regular IDE driver control slot 1 while having yenta_socket running slot 0? This probably requires tricks to make yenta_socket not reset the 5c476 completely on boot, since it's being used by someone else as well.. Is it doable? Recommended? If not, should I be able to have my root behind ide-cs? Currently ide2 does not show up until after root has been mounted, long after "pccard: PCMCIA card inserted into slot 1." 2. Socket power I can confirm intermittent occurences of: cs: pcmcia_socket0: unable to apply power for both sockets. This is lots of fun. Same board, same LinuxBIOS, on some boots everything works, on some boots I get the error. Working is more common than the error, but once I start getting the error it didn't go away until I left the board powered off for several hours. (Over night, next day it would be working again.) I'll contribute more info if/when I can reproduce more reliably. 3. Ejecting the CF causes slot 1 to stop working On "working boots", I get this output: --8<-- epia dev # dmesg|tail -n 22 VFS: Mounted root (nfs filesystem) readonly. Freeing unused kernel memory: 200k freed spurious 8259A interrupt: IRQ7. cs: IO port probe 0x100-0x3af: excluding 0x170-0x177 0x1f0-0x1f7 0x370-0x37f cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7 cs: IO port probe 0x820-0x8ff: clean. cs: IO port probe 0xc00-0xcf7: clean. cs: IO port probe 0xa00-0xaff: clean. cs: IO port probe 0x100-0x3af: excluding 0x170-0x177 0x1f0-0x1f7 0x370-0x37f cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7 cs: IO port probe 0x820-0x8ff: clean. cs: IO port probe 0xc00-0xcf7: clean. cs: IO port probe 0xa00-0xaff: clean. cs: memory probe 0xa000-0xa0ff: clean. pcmcia: registering new device pcmcia1.0 Probing IDE interface ide2... hde: SanDisk SDCFX-1024, CFA DISK drive ide2 at 0x100-0x107,0x10e on irq 7 hde: max request size: 128KiB hde: 2001888 sectors (1024 MB) w/1KiB Cache, CHS=1986/16/63 hde: hde1 ide-cs: hde: Vpp = 0.0 -->8-- All is good. The card works. (Why Vpp=0 though?) I just tried ejecting the CF and then resetting the board. It looks pretty good.. --8<-- VFS: Mounted root (nfs filesystem) readonly. Freeing unused kernel memory: 200k freed spurious 8259A interrupt: IRQ7. cs: IO port probe 0x100-0x3af: excluding 0x170-0x177 0x1f0-0x1f7 0x370-0x37f cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7 cs: IO port probe 0x820-0x8ff: clean. cs: IO port probe 0xc00-0xcf7: clean. cs: IO port probe 0xa00-0xaff: clean. cs: IO port probe 0x100-0x3af: excluding 0x170-0x177 0x1f0-0x1f7 0x370-0x37f cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7 cs: IO port probe 0x820-0x8ff: clean. cs: IO port probe 0xc00-0xcf7: clean. cs: IO port probe 0xa00-0xaff: clean. -->8-- ..until I insert the CF: --8<-- pccard: PCMCIA card inserted into slot 1 cs: memory probe 0xa000-0xa0ff: excluding 0xa000-0xa0ff cs: memory probe 0x6000-0x60ff: excluding 0x6000-0x60ff cs: warning: no high memory space available! -->8-- I am now unable to get the CF slot working again. Last night the slot wasn't working but after being turned off over night it worked per the first paste above. Leaving the system off for several hours could possibly make the slot work again, but why? Uninitialized register bits? Are register docs available anywhere and are they known to be correct? I've made a few attempts to tickle it but no progress: I leave the card in the slot and reset (reset button) and get: --8<-- VFS: Mounted root (nfs filesystem) readonly. Freeing unused kernel memory: 200k freed cs: IO port probe 0x100-0x3af: excluding 0x170-0x177 0x1f0-0x1f7 0x370-0x37f cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7 cs: IO port probe 0x820-0x8ff: clean. cs: IO port probe 0xc00-0xcf7: clean. cs: IO port probe 0xa00-0xaff: clean. cs: memory probe 0xa000-0xa0ff: excluding 0xa000-0xa0ff cs: memory probe 0x6000-0x60ff: excluding 0x6000-0x60ff cs: warning: no high memory space available! cs: IO port probe 0x100-0x3af: excluding 0x170-0x177 0x1f0-0x1f7 0x370-0x37f cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7 cs: IO port probe 0x820-0x8ff: clean. cs: IO port probe 0xc00-0xcf7: clean. cs: IO port probe 0xa00-0xaff: clean. cs: warning: no high memory space available! -->8-- I try a power cycle leaving power off for just a few seconds: --8<-- VFS: Mounted root (nfs filesystem) readonly. Freeing unused kernel memory: 200k freed cs: IO port probe 0x100-0x3af: excluding 0x170-0x177 0x1f0-0x1f7 0x370-0x37f cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7 cs: IO port probe 0x820-0x8ff: clean. cs: IO port probe 0xc00-0xcf7: clean. cs: IO
