cardbus pirq conflict

2000-12-08 Thread Matthew Galgoci

Hi Folks,

I am running the 2.4.0test12pre7 kernel on my laptop computer, and
I'm having some rather interesting problems.

For the longest time, usb never worked on this machine. As of the 
happy patch that enabled bus mastering for usb controllers, it 
magically started working. I am really happy that it does work
now.

The usb controller and the pcmcia bridge both share the same 
irq, irq 10.

Now, my cardbus cards have stopped working. When I insert a cardbus
nic, I get the following message: "IRQ routing conflict in pirq 
table! Try 'pci=autoirq'"

The card fails to initialize, and upon issuing the halt command, the 
system generates a kernel Oops. I tend to think that the Oops is a
symptom of having a half initialized device. If anyone is interested, 
I'll catch the Oops, run it though ksymoops, and send it to them.

If I try as the kernel suggests, and give the kernel options
pci=autoirq, there seems to be no noticable change.

If I switch to a isa^H^H^H I mean 16 bit version of the same ethernet 
card, the card works find, and the usb controller works. As a matter
of fact, I've had the 16 bit nic and a usb nic both active at the 
same time.

So, beyond reporting this and waiting for the next prepatch from Linus,
I really don't know where to go next. If I can provide anyone with more
information about the hardware or this problem, please ask.

Cheers!

--Matt Galgoci


-
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: cardbus pirq conflict

2000-12-11 Thread Matthew Galgoci


Hello,

I tried this patch against test12-pre7, and all that I get is 
"cs: socket c7604800 timed out during reset. Try increasing
setup_delay." 

Performing cardctl reset yields the same message. I think that 
cardctl reset takes away the possibility that increasing
setup_delay would actually help.

The Oops on shutdown no longer occurs, so I believe that you
have fixed the race contition you descdibed. The Oops was
also occuring on apm resume, but that has ceased as well.

I will try testing some other cardbus cards later today, and will
also experiment with an unpatch test12-pre8

Cheers!

--Matt Galgoci

> 
> Could you please test this stuff?
> 
> 
> 
> --- linux-2.4.0-test12-pre7/include/linux/sched.h Thu Dec  7 22:05:21 2000
> +++ linux-akpm/include/linux/sched.h  Sat Dec  9 01:36:19 2000
> @@ -152,6 +152,7 @@
>  extern int schedule_task(struct tq_struct *task);
>  extern void run_schedule_tasks(void);
>  extern int start_context_thread(void);
> +extern int current_is_keventd(void);
>  
>  /*
>   * The default fd array needs to be at least BITS_PER_LONG,
> --- linux-2.4.0-test12-pre7/include/linux/kernel.hThu Dec  7 22:05:21 2000
> +++ linux-akpm/include/linux/kernel.h Sat Dec  9 01:22:18 2000
> @@ -63,6 +63,8 @@
>  extern int get_option(char **str, int *pint);
>  extern char *get_options(char *str, int nints, int *ints);
>  extern unsigned long memparse(char *ptr, char **retptr);
> +extern void dev_probe_lock(void);
> +extern void dev_probe_unlock(void);
>  
>  extern int session_of_pgrp(int pgrp);
>  
> --- linux-2.4.0-test12-pre7/drivers/pci/pci.c Thu Dec  7 22:05:20 2000
> +++ linux-akpm/drivers/pci/pci.c  Sat Dec  9 01:24:46 2000
> @@ -300,18 +300,25 @@
>  pci_announce_device(struct pci_driver *drv, struct pci_dev *dev)
>  {
>   const struct pci_device_id *id;
> + int ret = 0;
>  
>   if (drv->id_table) {
>   id = pci_match_device(drv->id_table, dev);
> - if (!id)
> - return 0;
> + if (!id) {
> + ret = 0;
> + goto out;
> + }
>   } else
>   id = NULL;
> +
> + dev_probe_lock();
>   if (drv->probe(dev, id) >= 0) {
>   dev->driver = drv;
> - return 1;
> + ret = 1;
>   }
> - return 0;
> + dev_probe_unlock();
> +out:
> + return ret;
>  }
>  
>  int
> @@ -360,9 +367,9 @@
>   if (!hotplug_path[0])
>   return;
>  
> - sprintf(class_id, "PCI_CLASS=%X", pdev->class);
> - sprintf(id, "PCI_ID=%X/%X", pdev->vendor, pdev->device);
> - sprintf(sub_id, "PCI_SUBSYS_ID=%X/%X", pdev->subsystem_vendor, 
>pdev->subsystem_device);
> + sprintf(class_id, "PCI_CLASS=%04X", pdev->class);
> + sprintf(id, "PCI_ID=%04X:%04X", pdev->vendor, pdev->device);
> + sprintf(sub_id, "PCI_SUBSYS_ID=%04X:%04X", pdev->subsystem_vendor, 
>pdev->subsystem_device);
>   sprintf(bus_id, "PCI_SLOT_NAME=%s", pdev->slot_name);
>  
>   i = 0;
> --- linux-2.4.0-test12-pre7/kernel/exit.c Thu Dec  7 22:05:21 2000
> +++ linux-akpm/kernel/exit.c  Fri Dec  8 22:38:30 2000
> @@ -302,9 +302,9 @@
>  {
>   struct mm_struct * mm = tsk->mm;
>  
> + mm_release();
>   if (mm) {
>   atomic_inc(&mm->mm_count);
> - mm_release();
>   if (mm != tsk->active_mm) BUG();
>   /* more a memory barrier than a real lock */
>   task_lock(tsk);
> --- linux-2.4.0-test12-pre7/kernel/kmod.c Thu Dec  7 22:05:21 2000
> +++ linux-akpm/kernel/kmod.c  Sat Dec  9 11:53:32 2000
> @@ -256,21 +256,6 @@
>  
>  #endif /* CONFIG_HOTPLUG */
>  
> -
> -static int exec_helper (void *arg)
> -{
> - long ret;
> - void **params = (void **) arg;
> - char *path = (char *) params [0];
> - char **argv = (char **) params [1];
> - char **envp = (char **) params [2];
> -
> - ret = exec_usermodehelper (path, argv, envp);
> - if (ret < 0)
> - ret = -ret;
> - do_exit(ret);
> -}
> -
>  struct subprocess_info {
>   struct semaphore *sem;
>   char *path;
> @@ -279,73 +264,36 @@
>   int retval;
>  };
>  
> -/*
> - * This is a standalone child of keventd.  It forks off another thread which
> - * is the desired usermode helper and then waits for the child to exit.
> - * We return the usermode process's exit code, or some -ve error code.
> - */
>  static int call_usermodehelper(void *data)
>  {
>   struct subprocess_info *sub_info = data;
> - struct task_struct *curtask = current;
> - void *params [3] = { sub_info->path, sub_info->argv, sub_info->envp };
> - pid_t pid, pid2;
> - mm_segment_t fs;
> - int retval = 0;
> + int retval;
>  
> - if (!curtask->fs->root) {
> - printk(KERN_ERR "call_usermodehelper[%s]: no root fs\n", 
>sub_info->path);
> - retval = -EPERM;
> - goto up_and_out;
> - }
> - if ((pid = kernel_thread(exec_helper, (void *) params,

Re: cardbus pirq conflict

2000-12-11 Thread Matthew Galgoci


I goofed in the report below. I had switched to the i82365
pcmcia driver to see if it was affected by the pirq problems
the night before, and forgotten to switch back to the yenta_socket.

Switching back to the yenta_socket, plus andrewm's keventd patch
allowed the collection of cardbus pcmcia cards to work. Apm suspend
and shutting down the machine do not cause an Oops either.

I do however still recieve a nasty message about a pirq table
conflict, but it does not seem to affect the operation of the 
card.

The pirq conflict message seems a little harsh though, and perhaps 
unnecessary.

Thank you all.

Cheer!

--Matt Galgoci


On Mon, Dec 11, 2000 at 12:48:16PM -0500, Matthew Galgoci wrote:
> 
> Hello,
> 
> I tried this patch against test12-pre7, and all that I get is 
> "cs: socket c7604800 timed out during reset. Try increasing
> setup_delay." 
> 
> Performing cardctl reset yields the same message. I think that 
> cardctl reset takes away the possibility that increasing
> setup_delay would actually help.
> 
> The Oops on shutdown no longer occurs, so I believe that you
> have fixed the race contition you descdibed. The Oops was
> also occuring on apm resume, but that has ceased as well.
> 
> I will try testing some other cardbus cards later today, and will
> also experiment with an unpatch test12-pre8
> 
-
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/



iopener reboot

2001-01-02 Thread Matthew Galgoci

Hi,

I've gone and tried the ultimate acid test of crappy x86 hardware on the 
vanilla prerelease kernel, and installed it on my iopener. The kernel 
loads, uncompresses, initializes hardware, and then immediately reboots.

It all happens so fast that I do not really get a chance to see the last thing
printed before it fails.

The last kernel that I had running on this was a test12 pre something.

Any ideas?

--Matt Galgoci

-- 
"Hey Y'all, Watch this!" --Mike Wangsmo
-
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/