Dedicated Interrupt handling on SMP

[Randy]

I'm trying to find the easiest way to to deidcate one CPU to responding
to a specific Interrupt request.
That CPU should only listen for that request while all other CPU should
ignore the interrupt.

Any suggestions? Do I have to muck with the IO_APIC or is there a
simpler way which I just missed?

Any help would be appreciated!

Thank you!

Randy Schumm
Please CC: answer to [EMAIL PROTECTED]


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

CPU Dedicated Interrupts

[Randy]

What is the easiest way to tell a CPU to ignore certain interrupts from
module?
Is there an IRQ mask for each processor? Is that symbol exported?

Thank you!
Randy Schumm
Please all cc: [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Undocumented configuration symbols in 2.4.6pre2

[Dunlap, Randy]

Hi,

Could you make these 5 instances of "Not unsure" be more
palatable and less confusing?

E.g., "Not sure" or "If not sure".
But not the double negative...

As is, it basically says:  "Sure ? say M."

~Randy

> -Original Message-
> From: Maksim Krasnyanskiy [mailto:[EMAIL PROTECTED]]
> 
> >CONFIG_BLUEZ
> >CONFIG_BLUEZ_HCIEMU
> >CONFIG_BLUEZ_HCIUART
> >CONFIG_BLUEZ_HCIUSB
> >CONFIG_BLUEZ_L2CAP
> 
> Here we go:
> 
> CONFIG_BLUEZ
...
> 
>Say Y here to enable Linux Bluetooth support and to build HCI Core 
>layer.
> 
...
> 
>Not unsure ? say N.
> 
> CONFIG_BLUEZ_L2CAP
...
> 
>Say Y here to compile L2CAP support into the kernel or say 
> M to compile it 
>as module (l2cap.o).
> 
>Not unsure ? say M.
> 
> CONFIG_BLUEZ_HCIUART
...
> 
>Say Y here to compile support for Bluetooth UART devices 
> into the kernel 
>or say M to compile it as module (hci_uart.o).
> 
>Not unsure ? say M.
> 
> 
> CONFIG_BLUEZ_HCIUSB
...
> 
>Say Y here to compile support for Bluetooth USB devices 
> into the kernel 
>or say M to compile it as module (hci_usb.o).
> 
>Not unsure ? say M.
> 
> CONFIG_BLUEZ_HCIEMU
...
> 
>Not unsure ? say M.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: USB problems and 2.4.0 hangs

[Dunlap, Randy]

Hi,

> Hi all.
> 
> I'd installed the backport of the USB patch (to 2.2.16) and had the 
> following problem:
> 
> After a few inches of printing a graphics page (ghostscript 
> output), the
> whole printing job would just hang. Only exit was switching 
> the printer
> on/off and removing the print job. The printer is an HP810C 
> and (I suspect)
> the problem is at the VIA chipset (VT82C586).
> 
> After a few frustrating tries, I moved to kernel 2.4.0-test7, 
> suspecting
> that maybe there was a problem with the backport. Results:
> 
> Exactly the same print problem: hangs after 5 - 10 cm of printing a
> graphics page (text mode works ok).

Please enable all kernel log messages (Alt-SysRq-9 or
boot with: linux_image_name debug), reproduce the problem,
and send the kernel log after the printing hangs.

~Randy

> But, after installing 2.4.0, yesterday, I had two misterious 
> hangs of the
> operating system - apparently nothing to do with the tasks that were
> running - they were completely different.
> 
> Just in case: the printer is driven by the apsfilter, which works fine
> when using the parallel port.
> 
> Thanks on beforehand!
> 
> John
> --

-
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: Availability of kdb

[Dunlap, Randy]

I agree completely.  I'd love to see it there.
I'd even help break^W fix it.

~Randy
_______
|Randy Dunlap Intel Corp., DALSr. SW Engr.|
|randy.dunlap.at.intel.com503-696-2055|
|NOTE:  Any views presented here are mine alone   |
|and may not represent the views of my employer.  |
|_|

> -Original Message-
> From: Daniel Phillips
> [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 06, 2000 11:12 AM
> To: Mike Galbraith; [EMAIL PROTECTED]
> Subject: Availability of kdb
> 
> 
> Mike Galbraith wrote:
> > 
> > On Wed, 6 Sep 2000, Damien Miller wrote:
> > 
> > > Tools like a KDB would make the kernel a lot more 
> accessible to the
> > > time-poor.
> > 
> > Kdb is available to all.  I think it should be _integrated_ mostly
> > because of the (potential) improvement in bug report quality.
> 
> Well, yes and no.  As maintained by SGI, kdb is up to date:
> ftp://oss.sgi.com/www/projects/kdb/download/ix86/kdb-v1.3-2.4.
> 0-test8-pre4.gz
> 
> As maintained in the official ikd package, kdb is unusuably out of
> date, at least for me:
> ftp://ftp.kernel.org/pub/linux/kernel/people/andrea/ikd/v2.4/2
.4.0-test2-ikd2.bz2

Q: If kdb were a kernel option, would the official version be out of
   date, the way it is now?
A: no.

Q: If kdb were a kernel option, would Linus be called on to fix it
   when it breaks?
A: no, obviously not, Linus is too busy

Q: Who would fix it then?
A: Whoever breaks it.

Q: What if Linus breaks it?
A: That's a special case.  I personally will drop whatever I'm doing
   and try to fix it.  I will cordially invite J. Dow, J. Merkey, R.
   Gootch, and various other degenerate powertool lovers to help.

Q: Would kdb in the kernel result in more bugs getting fixed faster?
A: Yes, no doubt

Q: Do we need more bugs fixed faster?
A: Yes, we need that desperately.

Q: Would kdb in the kernel give us more eyes on the bugs, making them
   even shallower than they already are?
A: Why, yes it would.

Q: Will kdb make your kernel bigger or slow it down?
A: Not if you don't use it.

Q: Is kdb a big patch?
A: It's only 93K, zipped.

Q: Then why isn't kdb in the kernel?
A: Uh...

--
Daniel

-
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: usb-uhci forgets to destroy kmem entries

[Dunlap, Randy]

Yes, people use it.

Thanks.

~Randy
___
|Randy Dunlap Intel Corp., DALSr. SW Engr.|
|randy.dunlap.at.intel.com503-696-2055|
|NOTE:  Any views presented here are mine alone   |
|and may not represent the views of my employer.  |
|_|

> From: Oleg Drokin [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 13, 2000 7:40 AM
> 
> Hello!
> 
>I do not know, if anybody really uses this driver ('UHCI 
> (Intel PIIX4, VIA,
>...) support'), but based one the name, I choosen it, and 
> found, that when it
>cannot find any USB host, it forgots to do kmem_destroy_..., and
>because of that any subsequent attempts to load usb-uhci 
> modules ends up
>with BUG in slab.c.
>Here is the patch, below. It is against 2.4.0-test8.
> 
> --- drivers/usb/usb-uhci.c.orig   Wed Sep 13 17:36:20 2000
> +++ drivers/usb/usb-uhci.cWed Sep 13 18:34:33 2000
> @@ -2842,6 +2842,7 @@
>   
>   if(!urb_priv_kmem) {
>   err("kmem_cache_create for urb_priv_t failed 
> (out of memory)");
> + kmem_cache_destroy(urb_priv_kmem);
>   return -ENOMEM;
>   }
>  #endif   
> @@ -2876,6 +2877,15 @@
>   i++;
>   }
>  
> +#ifdef DEBUG_SLAB
> + if (retval < 0 ) {
> + if(kmem_cache_destroy(uhci_desc_kmem))
> + err("uhci_desc_kmem remained");
> + if(kmem_cache_destroy(urb_priv_kmem))
> + err("urb_priv_kmem remained");
> + }
> +#endif
> + 
>   return retval;
>  }
>  
> -

-
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: usb-uhci forgets to destroy kmem entries

[Dunlap, Randy]

> > +#ifdef DEBUG_SLAB
> > + if (retval < 0 ) {
> > + if(kmem_cache_destroy(uhci_desc_kmem))
> 
> Why only #ifdef DEBUG_SLAB?
> AFAICS the driver should always destroy it's slab cache.
> 
> Please cc, I'm not subscribed to linux-kernel.
(why not?  :)
> --
>   Manfred

This driver only uses slab caches when it's debugging.
DEBUG & SLAB go together.

~Randy

-
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: system hang with usb audio driver

[Dunlap, Randy]

> Hi, I have been having problems with the usb audio driver on a set of 
> Philips DSS330. The driver seemed to work properly up until 2.3.99-6.
> The driver included with 2.3.99-6 worked correctly when included with
> kernels up to 2.4.0test6 or so. The current driver (2.4.0test7+) will
> hang my system reliably when I access the audio device. The kernel
> detects the device correctly, the system comes up correctly, I login
> and the system dies when I start up xmms. Is there a newer version of
> the driver than the one in the kernel or usb cvs tree?
> thanks..
>  -nld

Not that I know of.
Which host controller driver are you using?
If it's "uhci", please try "usb-uhci" instead.

~Randy

-
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: webcam II & kernel compiling

[Dunlap, Randy]

Hi Joe,

> I have 2 questions.
> 
> 1) Who is working on the webcam II cpia driver.  Under NT I can get 15
> to 25 fps, while Linux seems to be limited to 15 max.  Is this a hard
> coded value in the lernel somewhere and is there plans for changing
> this?  (I know that this is an experimental driver, but 
> rebooting to NT is just not what I want to do.  8-)

See http://webcam.sourceforge.net/ for current driver.
I don't know if it's any faster though.
Are you using the parallel or USB camera?

> 2) I recently read that when upgrading to a new kernel you should not
> compile the new kernel in /usr/src/linux .  If I upgrade to a 
> new kernel
> what is the 'proper method' and what other program will I need to
> recompile to take full advantage of the new kernel?  (the more detail
> the better and please email just me and not the kernel list )

There was a big email thread about this.
You could do as Linus says that he does and build it
in /home/joeja/..., such as
/home/joeja/kernel/v2.4-test8/ or whatever naming convention
you like. 

For the other software needed for 2.4 kernels,
you'll need to read /your_path_choice/linux/Changes .
It lists all software updates that are needed.
[If you want to read it before downloading all of
the Linux 2.4 kernel, I can send it to you tomorrow
or you should be able to view it at a Linux xref
web site.]

~Randy

-
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: Linux-2.4.0-test9-pre2

[Dunlap, Randy]

> > Ok. I think we're getting to the point where there are no major
> > known bugs. That means that as of the final 2.4.0-test9 I will
> > no longer accept any patches that don't have a critical problem
> > (as defined by Teds list) associated with them.
> > 
> > So when you send me a patch, either bug Ted to mark the issue as
> > "critical" first, or pay me money. It's that easy. 
> 
> Hmm, the new VM doesn't have the out of memory killer
> integrated yet. I'll do some out of memory / low on
> swap work and will send you the patch soon, dependant
> on how connected I will be during Linux Kongress...
> 
> Good thing I promised Ted to bring another bottle of
> that Brazillian liquor to the next event we meet ;)
> 
> cheers,
> 
> Rik

Rik, does it have to be Brazilian liquor?
I still have patches for 2.4.0-final also.

~Randy

-
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: Linux-2.4.0-test9-pre2

[Dunlap, Randy]

Ted,

How does one identify the "critical" items in the
2.4 Status/TODO list?

Will you be adding a "critical" section or adding
"(critical)" on some items on the 2.4 Status/TODO list?

I'm updating the USB list now and wondering how to
mark items as critical.

Thanks,
~Randy

___

> Ok. I think we're getting to the point where there are no major known
> bugs. That means that as of the final 2.4.0-test9 I will no 
> longer accept
> any patches that don't have a critical problem (as defined by 
> Teds list) associated with them. 
> 
> So when you send me a patch, either bug Ted to mark the issue as
> "critical" first, or pay me money. It's that easy. 
> 
>   Linus

-
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: [linux-usb-devel] Logitech USB Wingman Force Joystick...

[Dunlap, Randy]

> Hello all...
> 
>   No joy with this joystick and I'm not sure what I'm doing wrong.
> 
>   I just received a Logitech USB Wingman Force Joystick.  I have
> the iforce module compiled and loaded and the it recognizes the USB
> joystick.
> 
...

>   Trouble is "jstest /dev/js0" says no such device.
> 
...
>   Still no go, but at least I'm not getting the modprobe 
> errors now.
> My USB mouse on c 13, 63 is working like a charm.
> 
>   This is with kernel 2.4.0-test8
> 
>   So, I assume that I'm still missing something obvious 
> here.  What?
> 
>   Any thoughts anyone?
> 
>   Mike

Hi Mike,

Thoughts are cheap.  Well, I guess (these) devices are too,
but I don't have one (yet).

No, you're not doing anything wrong.  That'd be too easy
to fix.

We've known about this problem for several weeks now.
AFAIK it first showed up at the USB PlugFest in early August
(2.4.0-test4 or -test5).
I told Vojtech about it but we haven't tracked it down yet.

I have a USB gamepad on order.  It exhibited the same
problem at the PlugFest, so I hope to be able to track it
down soon.

I'll log this in the Status/TODO list.

Thanks,
~Randy

-
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: PATCH 2.2.18.9: Backport /proc/pci from 2.4.x to 2.2.x

[Dunlap, Randy]

> From: Jeff Garzik [mailto:[EMAIL PROTECTED]]
> 
> On Mon, 25 Sep 2000, Dan Hollis wrote:
> > On Mon, 25 Sep 2000, Jeff Garzik wrote:
> > > I see you suggestion in the same way...  If we keep the 
> PCI device name
> > > data around after boot, then we have a lot of kernel 
> memory locked up
> > > on the off chance that a HotPlug PCI device might appear 
> for which we
> > > need a name.
> > > I would much prefer a userspace solution for naming 
> unnamed PCI devices
> > > after boot...
> 
> > How about the kernel calling lspci?
> 
> Kernel calling a proggie is no problem... CONFIG_KMOD does 
> it, and Linus
> has suggest that hotplugging a device needs to fire off a script, like
> 
>   /sbin/hotplug-net eth0 # new eth0 just inserted
> 
> If hotplugging executes an action, then updating the PCI device name
> should become part of that.  That implies that the kernel won't do any
> of the executing...  /sbin/hotplug-net will initiate the device name
> update, so the kernel needs a way to update the device name at the
> request of userspace.  It could be something as simple as 
>   echo name > /proc/bus/pci/00/0a.0/name
> or something more complex...

2.4.0-testN kernel already calls /sbin/hotplug (for USB),
or whatever the string value in /proc/sys/kernel/hotplug is.

It takes several argv and envp parameters so that different
buses and interfaces can be supported.

~Randy

-
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: system hang with usb audio driver

[Dunlap, Randy]

> From: Narayan Desai [mailto:[EMAIL PROTECTED]]
> 
> >>>>> "Randy" == Dunlap, Randy <[EMAIL PROTECTED]> writes:
> 
> >> Hi, I have been having problems with the usb audio driver on a set
> >> of Philips DSS330. The driver seemed to work properly up until
> >> 2.3.99-6.  The driver included with 2.3.99-6 worked correctly when
> >> included with kernels up to 2.4.0test6 or so. The current driver
> >> (2.4.0test7+) will hang my system reliably when I access the audio
> >> device. The kernel detects the device correctly, the system comes
> >> up correctly, I login and the system dies when I start up xmms. Is
> >> there a newer version of the driver than the one in the kernel or
> >> usb cvs tree?  thanks..  -nld
> 
> Randy> Not that I know of.  Which host controller driver are you
> Randy> using?  If it's "uhci", please try "usb-uhci" instead.
> I have tried both uhci drivers and get 2 different results.
> If I use uhci, the process trying to access the audio device is killed
> with an oops. If I use usb-uhci, the swapper is killed and the system
> is gone. I am not really sure how to intrepret this.
>  -nld

Right.  I've reproduced this with usb-uhci on 2.4.0-test7 (fails)
and test5 (works) and 2.2.18pre9 (works).  I'm slowly looking for
the reason/problem (along with other things).

I have added this to the USB 2.4 TODO list as CRITICAL.

Please let me know if you make any progress on this and I will
do the same.

Thanks,
~Randy

-
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: network drivers interface changes

[Dunlap, Randy]

1.  try [EMAIL PROTECTED]

and/or

2.  search the lkml archives for items/threads below:

a.  email on lkml on 2000-feb-10 from "jamal"
with subject: of "New network driver interface changes, README".

b.  subject: "[ANNOUNCE] SOFTNETing Network Drivers HOWTO",
from jamal, 2000-jan-06

c.  subject: ""softnet" drivers: an attempt to clariry", on
2000-feb-14, from kuznet

~Randy
+=====+
|Randy Dunlap Intel Corp., DALSr. SW Engr.|
|randy.dunlap.at.intel.com503-696-2055|
|NOTE:  Any views presented here are mine alone   |
|and may not represent the views of my employer.  |
+=+

> -Original Message-
> From: Hen, Shmulik [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 27, 2000 1:21 AM
> To: 'LKML'
> Subject: Q: network drivers interface changes
> 
> 
> Hello,
> 
> Is there a good source of information that describes the 
> changes in network
> driver interface between 2.2.x and 2.4.x kernels ?
> 
> 
>   Thanks,
>   Shmulik Hen Software Engineer
>   Linux  Advanced Networking Services
>   Intel Network Communications Group
>   Jerusalem
-
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: Linux 2.2.18pre11

[Dunlap, Randy]

> > > In article <[EMAIL PROTECTED]> you wrote:
> > > > I'm getting this compile time error on 2.2.18pre11:
> > > 
> > > > drivers/usb/usbdrv.o: In function `usb_init':
> > > > drivers/usb/usbdrv.o(.text+0x6deb): undefined reference 
> to `uhci_init'
> > > 
> > > The patch below should fix that.
> > 
> > No it doesn't  read the usb/uhci code.  It uses initcalls.  The
> > solution is to remove call to uhci_init() in usb_init().
> 
> Ah, is this the correct fix, then?  I actually booted this 
> one (I never
> booted the other patch, just compiled it, and it works for me.  :-)
> 
> -Dave
> 
> --- linux/drivers/usb/usb-core.c.orig   Thu Sep 28 08:44:59 2000
> +++ linux/drivers/usb/usb-core.cThu Sep 28 08:47:13 2000
> @@ -60,12 +60,6 @@
>   usb_hub_init();
> 
>  #ifndef CONFIG_USB_MODULE
> -#ifdef CONFIG_USB_UHCI
> - uhci_init();
> -#endif
> -#ifdef CONFIG_USB_UHCI_ALT
> - uhci_init();
> -#endif
>  #ifdef CONFIG_USB_OHCI
>   ohci_hcd_init();
>  #endif
> 
> -

Yes, that looks like 2.4.0-test9 now, except that it should
be done for ohci also, although you don't need it for your
config.

~Randy

-
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: Linux 2.2.18pre11

[Dunlap, Randy]

> On Thu, Sep 28, 2000 at 09:39:22AM -0700, Dunlap, Randy wrote:
> > 
> > Yes, that looks like 2.4.0-test9 now, except that it should
> > be done for ohci also, although you don't need it for your
> > config.
> 
> Right, but it doesn't look like the usb-ohci driver uses 
> initcalls like
> the other functions.  I could be wrong, new at kernel hacking.  :-)
> 
> -Dave
> -

Ack, you're correct...but it should.  8;)

~Randy

-
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: HP Vectra XU 5/90 interrupt problems

[Dunlap, Randy]

> -Original Message-
> From: John William [mailto:[EMAIL PROTECTED]]
> 
> I'm having a problem with kernel 2.4.2-SMP on my HP Vectra XU 
> 5/90. This is an old dual-pentium (Neptune chipset) machine.
> 
...
> 
> OR
> 
> If PCI interrupts are shared, force them to be level 
> triggered? Can shared 
> PCI interrupts be edge triggered? If not, then wouldn't this 
> be the correct 
> solution? This isn't specific to the Vectra, but could 
> possibly prevent problems on any machine with a broken BIOS?

PCI interrupts are defined as "level sensitive" and must
be shareable.

~Randy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

using ioctls (was: RE: Larger dev_t)

[Dunlap, Randy]

Hi-

Tangential question (I think).  Not for an IOCTL request  8;)
[as the JFS request last week].

[When] is it OK to use (new) IOCTLs vs. using procfs read/write?

And are there some alternative methods besides these two?

Thanks,
~Randy


> -Original Message-
> From: Linus Torvalds [mailto:[EMAIL PROTECTED]]
> 
...
> We should encourage people to not need major numbers. It's easy. The
> driver exports a /proc entry in /proc/driver/xxx or similar . Or the
> driver writer says "if you want to use this device, use devfs", and
> exports the name there.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [kbuild-devel] CML2 1.0.0 release announcement

[Dunlap, Randy]

Hi Eric,

> After 11 months of painstaking work and testing, CML2 1.0.0 
> is ready for use,
> and ready to replace the current kernel-configuration system.  You'll
> find it at .  I've made a transition
> guide available at .

Congratulations on taking it this far.

> (For those of you who grumbled about adding Python to the 
> build-tools set,
> Linus has uttered a ukase: CML2's reliance on Python is not 
> an issue.

I'd like to see one of the prominent web pages inform
people that Python version x.yy(?) is required to use CML2.
(I had Python version problems during testing/use of it...)

~Randy_

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [kbuild-devel] CML2 1.0.0 release announcement

[Dunlap, Randy]

> After 11 months of painstaking work and testing, CML2 1.0.0 
> is ready for use,
> and ready to replace the current kernel-configuration system.  You'll
> find it at <http://www.tuxedo.org/~esr/cml2/>.  I've made a transition
> guide available at <http://www.tuxedo.org/~esr/cml2/transition.html>.

> From: Eric S. Raymond [mailto:[EMAIL PROTECTED]]
> 
> Dunlap, Randy <[EMAIL PROTECTED]>:
> > I'd like to see one of the prominent web pages inform
> > people that Python version x.yy(?) is required to use CML2.
> 
> It's in the README.  Is that good enough?
> -- 

Then the README should be listed (linked) on one of the 2 web pages
above.  I can't find it without downloading "CML2 prototype
and documentation," right?  I think that it should be
more visible that Python version x.yy(?) is needed, without
having to download the tarball.  Or did I miss the README
somewhere?

Thanks,
~Randy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [patch] patch-2.4.2-irda1 (irda-usb)

[Dunlap, Randy]

> From: Jean Tourrilhes [mailto:[EMAIL PROTECTED]]
> 
>   First thanks for Dag for bringing me into the conversation. I
> may add my little bit of spice, especially that I was the one pushing
> for having the driver in .../drivers/net/irda.
>   By the way, Greg, sorry if I hurt your feeling, I don't want
> to put down any of the great work that has been done on the USB stack.
> 
>   My feeling is that devices are mostly defined by their higher
> level interface, because this is what is closer to the user.
>   If I look at a Pcmcia Ethernet card, I will tend to associate
> more with a PCI Ethernet card rather than a Pcmcia SCSI card. Both
> card have the same high level interface (TCP/IP) even if their low
> level interface is different (Pcmcia, PCI).
>   People tend to agree with that, and that's why you have
> directories called drivers/net, drivers/scsi and driver/sound, rather
> that drivers/pci, drivers/isa, drivers/mca and drivers/pcmcia.
> 
>   If I get an IrDA-USB dongle, the feature that matter the most
> is that it does IrDA, the fact that it connect to my PC via USB is
> rather secondary.
>   That's it. I hope it explain some of the rationale and why we
> departed from the usual drivers/usb arrangement. Actually, I think
> that stuffing all USB drivers in drivers/usb is not that great, but
> that's not my call...

That has been discussed & Linus like[ds] it that way.

~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: usb dc2xx quirk

[Randy Dunlap]

Hi,

Looks like dc2xx.c shouldn't use __devinit/__devexit
[patch attached]
or you should enable CONFIG_HOTPLUG under General Setup.

David?

The ov511 (usb) driver is the only other USB device driver
that uses __devinit/__devexit.

~Randy

josh wrote:
> 
> Kernel Version: 2.4.0-test11 - 2.4.0-prerelease
> Platform: ix86 (PIII)
> Problem Hardware: Kodac DC280, firmware 1.01
> 
> Ever since test10 or after, removing my dc280 from the usb
> bus causes khubd to crash.  I have tried both UHCI drivers
> and they produce the same effect.
> 
> dmesg, syslog, messages, and .config can be found at:
> http://mammoth.org/~skulcap/usb-problem
> 
> I have looked throug the archives and havent found anything
> like this, so I'm sorry if it has been covered already.
> 
> Thanks in advance!
-- 
___
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
---

--- linux/drivers/usb/dc2xx.c.org   Sun Nov 12 20:40:42 2000
+++ linux/drivers/usb/dc2xx.c   Wed Jan  3 11:15:11 2001
@@ -353,7 +353,7 @@
 
 
 
-static void * __devinit
+static void *
 camera_probe (struct usb_device *dev, unsigned int ifnum, const struct usb_device_id 
*camera_info)
 {
int i;
@@ -451,7 +451,7 @@
return camera;
 }
 
-static void __devexit camera_disconnect(struct usb_device *dev, void *ptr)
+static void camera_disconnect(struct usb_device *dev, void *ptr)
 {
struct camera_state *camera = (struct camera_state *) ptr;
int subminor = camera->subminor;

RE: usb dc2xx quirk

[Dunlap, Randy]

> From: David Brownell [mailto:[EMAIL PROTECTED]]
> 
> If this makes it go away, then by all means apply this patch;
> though I don't quite see what the failure mode would be.

Josh didn't have HOTPLUG defined and he has
confirmed to me that this patch fixes the oops.
I'll forward it again.

> The proximate cause of that Oops looked to be in one of the
> UHCI drivers, but of course it's also possible that it was
> triggered by driver misbehavior.

You didn't look hard enough.  8;)
hub_thread got a disconnect event, called usb_disconnect,
which tried to call driver->disconnect, which wasn't there
due to using __devexit without CONFIG_HOTPLUG defined.

> Have we identified anything that actually does anything with
> code labeled __dev{in,ex}it (or data), beyond putting it into
> a different section?  If so, what's it doing?

That's a great question.  I'd like to know the answer also.
Then we can see what the correct fixes should be.
This patch could just be a short-lived 2.4.0-prerel
fix-the-oops patch.

> I just tried plug/unplug of a dc-240, albeit on a kernel
> with HOTPLUG defined (and using OHCI) and it worked without
> any Oops.

Yes, HOTPLUG (and #define of __devexit) is the key.

~Randy


> - Dave
> 
> 
> - Original Message -
> From: Randy Dunlap <[EMAIL PROTECTED]>
> To: josh <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; l-u-d
> <[EMAIL PROTECTED]>
> Sent: Wednesday, January 03, 2001 11:23 AM
> Subject: Re: usb dc2xx quirk
> 
> 
> > Hi,
> >
> > Looks like dc2xx.c shouldn't use __devinit/__devexit
> > [patch attached]
> > or you should enable CONFIG_HOTPLUG under General Setup.
> >
> > David?
> >
> > The ov511 (usb) driver is the only other USB device driver
> > that uses __devinit/__devexit.
> >
> > ~Randy
> >
> > josh wrote:
> > >
> > > Kernel Version: 2.4.0-test11 - 2.4.0-prerelease
> > > Platform: ix86 (PIII)
> > > Problem Hardware: Kodac DC280, firmware 1.01
> > >
> > > Ever since test10 or after, removing my dc280 from the usb
> > > bus causes khubd to crash.  I have tried both UHCI drivers
> > > and they produce the same effect.
> > >
> > > dmesg, syslog, messages, and .config can be found at:
> > > http://mammoth.org/~skulcap/usb-problem
> > >
> > > I have looked throug the archives and havent found anything
> > > like this, so I'm sorry if it has been covered already.
> > >
> > > Thanks in advance!
> > --
> > ___
> > |randy.dunlap_at_intel.com503-677-5408|
> > |NOTE: Any views presented here are mine alone|
> > |& may not represent the views of my employer.|
> > ---
> 
> 
> --
> --
> 
> 
> > --- linux/drivers/usb/dc2xx.c.org Sun Nov 12 20:40:42 2000
> > +++ linux/drivers/usb/dc2xx.c Wed Jan  3 11:15:11 2001
> > @@ -353,7 +353,7 @@
> >
> >
> >
> > -static void * __devinit
> > +static void *
> >  camera_probe (struct usb_device *dev, unsigned int ifnum, 
> const struct usb_device_id
> *camera_info)
> >  {
> >   int i;
> > @@ -451,7 +451,7 @@
> >   return camera;
> >  }
> >
> > -static void __devexit camera_disconnect(struct usb_device 
> *dev, void *ptr)
> > +static void camera_disconnect(struct usb_device *dev, void *ptr)
> >  {
> >   struct camera_state *camera = (struct camera_state *) ptr;
> >   int subminor = camera->subminor;

-
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: Adding devices to dc2xx.c

[Dunlap, Randy]

> Hello, and thank you to those who responded to my query about 
> adding my
> Agfa ePhoto to the USB mass storage device database. I had no success
> with this (the machine locked hard on connecting the device), 
> so I have decided to try it with the dc2xx driver.
> 
> I have added it to /usr/src/linux/drivers/usb/dc2xx.c as follows:
> ..
> { idVendor: 0x040a, idProduct: 0x0112 },  // Kodak DC-290
> { idVendor: 0xf003, idProduct: 0x6002 },  // HP 
> PhotoSmart C500
> { idVendor: 0x06bd, idProduct: 0x0403 },  // Agfa ePhoto CL18
> ..
> 
> However, after I recompile and reboot with the new boot 
> image, I receive the following:
> ..
> Jan  5 19:37:33 localhost kernel: usb.c: registered new driver dc2xx 
> ..
> Jan  5 19:37:33 localhost kernel: hub.c: USB new device 
> connect on bus1/2, assigned device number 2 
> Jan  5 19:37:33 localhost kernel: usb.c: USB device 2 (vend/prod
> 0x6bd/0x403) is not claimed by any active driver. 
> ..
> 
> Why is dc2xx not being associated with the camera? I note 
> that the vendor
> and product names of the camera omit the leading '0', but I have tried
> adding them to the driver file as both '0x06bd' and '0x6bd' and 
> neither works. I'm
> using 2.4.0-prerelease, in case that helps.
> 
> So, does this sound like a bug with the above driver, or is 
> there something that I've missed?

Either you don't have dc2xx compiled into the kernel, or
if it's a module, you don't have it loaded yet.  You should
load it manually or add hotplug support
and the proper support files for it.
See http://www.linux-usb.org/policy.html.

~Randy
___
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
---

-
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: USB broken in 2.4.0

[Dunlap, Randy]

This rings a small bell with me.
There was a change by Dan Streetman IIRC to limit
usbdevfs bulk transfers to PAGE_SIZE (4 KB for x86,
or 0x1000).  Anything larger than that returns
an error (-EINVAL).

~Randy
___
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
---

> -Original Message-
> From: antirez [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 05, 2001 6:40 PM
> To: antirez
> Cc: Greg KH; Heitzso; '[EMAIL PROTECTED]'; 
> 'Johannes Erdfelt'
> Subject: Re: USB broken in 2.4.0
> 
> 
> On Sat, Jan 06, 2001 at 12:04:29AM +0100, antirez wrote:
> > I'll do some test with the new 2.4 kernel to find if there 
> is a problem
> > in s10sh itself. A good test can be to try if the equivalent driver
> > of gphoto works without problems using the 2.4 kernel 
> (however it also
> > uses the libusb). The s10sh bug may be not necessarly 
> related to the USB
> > subsystem.
> 
> Ok, the problem is the same that I ecountered developing the file
> upload for the powershot USB driver performing a bulk write with
> a big data size, but this time it is present even reading.
> 
> s10sh reads 0x1400 bytes at once downloading jpges from the
> digicam, but the ioctl() that performs the bulk read fails with 2.4
> using this size. If I resize it (for example to 0x300) it 
> works without
> problems (with high performace penality, of course, 60% of slow-down).
> I don't know why. I checked at the time of the file upload the kernel
> code finding nothing.
> 
> Anyway with the old releases of the USB subsystem libusb failed to
> initialize the camera some time, now it seems fixed.
> 
> For the users: just edit usb.c and check the function USB_get_data(),
> substituting all the occurrence of 0x1400 to 0x300 as a work-around.
> 
> Please CC: me since I'm not subscribed to the list.
> 
> regards,
> antirez
> 
> -- 
> Salvatore Sanfilippo  |  
> <[EMAIL PROTECTED]>
> http://www.kyuzz.org/antirez  |  PGP: finger 
> [EMAIL PROTECTED]
> -
> 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/
> 

-
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: USB problems with 2.4.0

[Dunlap, Randy]

What kind of USB host controller is it?
Maybe there are some issues with it.

Maybe 'lspci -vv'...

~Randy
___
|randy.dunlap_at_intel.com503-677-5408|
---

> From: Adam Huffman [mailto:[EMAIL PROTECTED]]
> 
> System is a KA7-100, sole USB peripheral is a Logitech MouseMan Wheel.
> 
> If I use the uhci driver, it doesn't initialise properly (there is a
> message along the lines of "something bad happened".  If I use the
> usb-uhci driver, I frequently get an oops if I move the mouse during
> bootup.
> 
> If anyone is interested I will try to obtain a decoded oops report.
> 
> I've had this problem for a while and have reported it here before, as
> well as to one of the USB maintainers, but with no result so far.
> 
> 
> Adam
> -

-
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: The latest instance in the A20 farce

[Dunlap, Randy]

hpa-

I tested this patch on a Pentium dual-proc system (440GX)
and on a Celeron system[1] (810) that lacks floppy, keyboard
controller, maybe some other things.

Linux 2.4.0 boots fine on each of these systems with this
patch applied.  I couldn't tell which method of
enabling A20 was actually successful.
Have you had any other reports on the patch?


[1] I'm not sure if this system qualifies as "legacy free"
or "legacy reduced."  However, for future (how far?)
reference, on legacy-free systems:
[from PDF file at http://www.pcdesguide.org/pc2001/default.htm]

a. The BIOS isn't required to have int. 0x15, AH=0x2401 [Appx. A],
   but that is handled by your patch.
b. The BIOS isn't required to have int. 0x15, AH=0x88 [Appx. A]
   (Ye Olde Traditional memory-size function).
   Hopefully the other memory-size methods will always have
   priority.
c. A20M# is always de-asserted at the processor [Ch. 3, item SYS-0047]

I bring these up because they may have some impact on SYSLINUX,
LILO, etc., and the data structures that they use (like the
memory_size item) and because some of these systems don't
have a "real mode," so loaders can't reliably assume that
they do (unless it's transparent to the loaders)...
and because you know something about SYSLINUX etc.

~Randy
___
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
---

> From: H. Peter Anvin [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 06, 2000 3:55 PM
> 
> Okay, here is yet another A20 patch (against test12-pre6) this time
> for people to try out.  This patch uses the following algorithm for
> enabling A20:
> 
> 1. Try the BIOS call.  If it works, we're cool.
> 2. Try the KBC (using Linus' lowered timeouts.)
> 3. If the KBC doesn't work, or is very slow, flip port 92.
> 
> After 3 it sits into the same infinite loop waiting for A20 to become
> enabled (necessary on for example some Toshiba notebooks which have an
> extremely slow response to A20.)
> 
> The main differences between this patch and test12-pre6:
> 
> - Trying the BIOS first of all.  This should reduce the risk of the
>   BIOS getting confused while doing a suspend.  This also gives even
>   less of an excuse for any nonstandard arrangement -- if you didn't
>   implement the standard KBC *and* you didn't provide the BIOS call,
>   you have a seriously broken piece of hardware.
> 
> - If the KBC responds quickly enough (within about 1 cycles), we
>   don't ever touch the fast A20 gate.  This is a difference from
>   previous code, where the fast A20 gate was toggled immediately after
>   the KBC, even if the KBC responded instantly.
> 
> - I had to move the A20 code somewhat earlier in setup.S in order for
>   the BIOS to still be available.
> 
> Please try it out and let me know as soon as possible...
> 
>   -hpa
> 
> 
> --- arch/i386/boot/setup.S.12p6   Wed Dec  6 12:49:07 2000
> +++ arch/i386/boot/setup.SWed Dec  6 15:25:01 2000
...
> -- 
> <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!

-
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: The latest instance in the A20 farce

[Dunlap, Randy]

> From: H. Peter Anvin [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 10, 2001 4:10 PM
> 
> "Dunlap, Randy" wrote:
> > 
> > a. The BIOS isn't required to have int. 0x15, AH=0x2401 [Appx. A],
> >but that is handled by your patch.
> 
> Idiots.  This should be required and be a null function; likewise
> AH=0x2400.  The only thing that the current spec means is that 
> 
> > b. The BIOS isn't required to have int. 0x15, AH=0x88 [Appx. A]
> >(Ye Olde Traditional memory-size function).
> 
> Incorrect; see page 226.

Right.  Somehow I looked at that and didn't see it.

> >Hopefully the other memory-size methods will always have
> >priority.
> > c. A20M# is always de-asserted at the processor [Ch. 3, 
> item SYS-0047]
> > 
> > I bring these up because they may have some impact on SYSLINUX,
> > LILO, etc., and the data structures that they use (like the
> > memory_size item) and because some of these systems don't
> > have a "real mode," so loaders can't reliably assume that
> > they do (unless it's transparent to the loaders)...
> > and because you know something about SYSLINUX etc.
> > 
> 
> URRRK.  I get a feeling these specs are either there to make 
> life extra difficult for programmers,
> because the people that design them are too
> stupid to tie their own shoes, or because they want nothing but M$
> factory-installed to work.
> 
> A20M# always deasserted: this is all fine and good if we had 
> nothing else
> to worry about, but they really have managed to fuck up when 
> it comes to
> getting something to work *ACROSS THE BOARD*.  THEY DON'T 
> GIVE ME A WAY
> TO DETECT THE FACT THAT A20M# IS FIXED!  This is 
> particularly nasty
> when going back to real mode, since I don't have a way to 
> figure out that I can't turn A20M# back to its old state.  

I'm not sure about this, but I'm wondering if the
Fixed (as in Static) ACPI Description Table (FADT)
can indicate that the platform is a legacy-free system.

According to the ACPI 2.0 spec, FADT field "Boot Architecture
Flags", bit 0 (LEGACY_DEVICES) indicates whether there are
legacy devices (user-visible) on the system.  I'm not sure
that this is adequate/equivalent.  I'll continue to check into it.
Even if it is adequate/equiv, it's not pretty.

> I also really, really, *REALLY* hate them for killing serial 
> ports.  It's a Bad Idea[TM].

Got the Message.

> Worse, they define that port 92h, bit 1, is no longer 
> A20M#... but they
> don't forbid the system from using it for other things.

I don't quite see it that way.  Where do you see that?
Maybe it just needs to be more explicit.

Ch. 3 (SYS-0047) says that port 92h:bit 1 doesn't toggle/affect A20M#.
Appendix A says that port 92h is (still?) "System Control Port A"
(not defined here AFAIK).
(I haven't checked all of the other chapters/appendices.)

>   -hpa
> -- 
> <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!

~Randy
___
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
---

-
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: [Patch] memparse should return long long

[Dunlap, Randy]

Why not (?):

> diff -uNr 2.4.0-ac/lib/cmdline.c 2.4.0-ac-memparse/lib/cmdline.c
> --- 2.4.0-ac/lib/cmdline.cMon Aug 28 11:42:45 2000
> +++ 2.4.0-ac-memparse/lib/cmdline.c   Mon Jan 15 09:06:14 2001
> @@ -93,9 +93,9 @@
>   *   megabyte, or one gigabyte, respectively.
>   */
>  
> -unsigned long memparse (char *ptr, char **retptr)
> +unsigned long long memparse (char *ptr, char **retptr)
>  {
> - unsigned long ret = simple_strtoul (ptr, retptr, 0);
> + unsigned long long ret = simple_strtoul (ptr, retptr, 0);
! + unsigned long long ret = simple_strtoull (ptr, retptr, 0);

~Randy

-
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: inserting a Forth-like language into the Linux kernel

[Dunlap, Randy]

> > > If someone knows of another example of interpreter-like behavior 
> > > directly in a unix in-kernel thread I'd like to know about it.  
> > 
> > kdb
> > 
> 
> That runs in trap handlers doesn't it? I don't think it's a 
> kernel daemon.

and there's the hangman-in-kernel patch...
interpreter or daemon or app-in-system-space ???

~Randy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] x86 page fault handler not interrupt safe

[Dunlap, Randy]

> From: David Woodhouse [mailto:[EMAIL PROTECTED]]
> 
> [EMAIL PROTECTED] said:
> >  If anybody has such a beast, please try this kernel patch _and_
> > running the F0 0F bug-producing program (search for it on the 'net -
> > it must be out there somewhere) to verify that the code still
> > correctly handles that case. 
> 
> Something along the lines of:
> 
> echo "unsigned long main=0xf00fc7c8;" > f00fbug.c ; make f00fbug

Yes, that's what the (SGI) program uses:
http://lwn.net/2001/0329/a/ltp-f00f.php3

~Randy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: kernel2.2.x to kernel2.4.x

[Dunlap, Randy]

> From: jalaja devi [mailto:[EMAIL PROTECTED]]
> 
> I tried porting a network driver from kernel2.2.x to
> 2.4. When i tried loading the driver, it shows the
> unresolved symbols for
> copy_to_user_ret
> outs
> __bad_udelay
> 
> Could anyone please tell me the corresponding fxns in 2.4.

You need to "unroll" copy_to_user_ret().  There is no
corresponding macro.  Just test the condition and return
-EFAULT (?; not looking at the source code) if it's invalid.

Don't know about "outs".

__bad_udelay means that some module used a too-large-parameter-value
to udelay().  Linker should be telling you which module.

~Randy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: LANANA: To Pending Device Number Registrants

[Dunlap, Randy]

hpa wrote:
> 
> Alan Cox wrote:
> > 
> > > Are FireWire (and USB) disks always detected in the same 
> > > order? Or does it
> > > behave like ADB, where you never know which 
> > > mouse/keyboard is which mouse/keyboard?
> > 
> > USB disks are required (haha etc) to have serial numbers. 
> > Firewire similarly has unique disk identifiers.

Bulk-only USB storage is required to have serial numbers.
E.g., Zip drives, probably USB hard drives and CDs.
Drives that use CBI (control/bulk/interrupt) transport (mostly
floppies) are not required to have serial numbers.
(Cost thing, of course.)

> How about for other device classes?

Mice?  no way.  Keyboards?  nope.
Webcams?  nope.
Printers?  optional.
Audio?  no.
Communication?  not mentioned in the spec.
Hub?  not mentioned in the spec.

~Randy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: kernel2.2.x to kernel2.4.x

[Dunlap, Randy]

see http://www.firstfloor.org/~andi/softnet/

~Randy


> -Original Message-
> From: jalaja devi [mailto:[EMAIL PROTECTED]]
> 
> How can I handle this from kernel2.2 to kernel2.4
> 
> Can I replace like this??
> 
> if (test_and_set_bit (0, (void *)&dev->tbusy)){ return
> EBUSY;} == with  netif_stop_queue (dev);
> 
> clear_bit ((void *)&dev->tbusy); = with
> netif_start_queue(dev);
> 
> Thanks
> Jalaja
> 
> --- Alan Cox <[EMAIL PROTECTED]> wrote:
> > > I tried porting a network driver from kernel2.2.x
> > to
> > > 2.4. When i tried loading the driver, it shows the
> > > unresolved symbols for
> > > copy_to_user_ret
> > 
> > if(copy_to_user(...))
> > return -EFAULT
> > 
> > > outs
> > 
> > Has not gone away, your includes are wrong
> > 
> > > __bad_udelay
> > 
> > You are using too large a udelay use mdelay
> > -
> > To unsubscribe from this list: send the line
> > "unsubscribe linux-kernel" in
> > the body of a message to [EMAIL PROTECTED]
> > More majordomo info at 
> > http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 
> 
> __
> Do You Yahoo!?
> Yahoo! Auctions - buy the things you want at great prices
> http://auctions.yahoo.com/
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Kernel 2.4.x TODO

[Dunlap, Randy]

> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> 
> Was the TODO list at http://linux24.sourceforge.net just 
> meant to be useful before 2.4.0 was released?

I believe that is the case.

> It seems to me that it would still be useful for (amongst 
> other things)
> potential kernel hackers looking for something to have a stab 
> at but it
> doesn't seem to up to date. Is it still supposed to be being 
> maintained by anyone?

Check out the kernel janitor project at
http://bazar.conectiva.com.br/~acme/TODO (original)
and
http://sourceforge.net/projects/kernel-janitor (later)

~Randy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [CHECKER] large stack variables (>=1K) in 2.4.4 and 2.4.4-ac8

[Dunlap, Randy]

> From: Andrew Morton [mailto:[EMAIL PROTECTED]]
> 
> Andreas Dilger wrote:
> > 
> > On a side note, does anyone know if the kernel does checking if the
> > stack overflowed at any time?
> 
> There's a little bit of code in show_task() which calculates
> how close this task ever got to overrunning its kernel stack:
> 
> {
> unsigned long * n = (unsigned long *) (p+1);
> while (!*n)
> n++;
> free = (unsigned long) n - (unsigned long)(p+1);
> }
> printk("%5lu %5d %6d ", free, p->pid, p->p_pptr->pid);
> 
> SYSRQ-T will trigger this.
> 
> However it doesn't work, because do_fork() doesn't zero
> out the stack pages when they're created.

If do_fork() performance is an issue, at least clearing the stack
pages as a build option would be nice for some of us.

~Randy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: changes betwwen 2.2 | 2.4

[Dunlap, Randy]

See http://www.firstfloor.org/~andi/softnet/

~Randy
---

> From: sebastien person [mailto:[EMAIL PROTECTED]]
> 
> Is there any documents that explain how upgrade network 
> driver from 2.2. to 2.4.? that gives details on changes ...
> 
> Or maybe best way is to compare same driver in the twice 
> kernel version ?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: ac15 and 2.4.5-pre6, pwc format conversion

[Dunlap, Randy]

> From: Erik Mouw [mailto:[EMAIL PROTECTED]]
> 
> On Fri, May 25, 2001 at 10:48:12AM +0200, Nemosoft Unv. wrote:
> > On 25-May-01 Norbert Preining wrote:
> > > According to ac ChangeLog:
> > > o   Rip format conversion out of the pwc driver (me)
> > > | It belongs in user space..
> > > 
> > > This change is included in 2.4.5-pre6, but
> > >   drivers/usb/pwc-uncompress.c
> > > pwc-uncompress.c:185: warning: implicit declaration of function
> > > `vcvt_420i_420p'
> > 
> > That´s what you get for ripping out the guts of a driver. 
> Have a nice day.
> 
> The format conversion shouldn't be there in the first place. Format
> conversion is policy, so it doesn't belong in kernel. Note for example
> that none of the sound drivers does sample rate conversion although
> some sound chips are locked at 48kHz only.

Once upon a time there was an agreement (understanding ?) that this
was to be a major 2.5 change (moving video conversion from kernel
drivers to user space) and that lots of apps would need to be
changed for this to be successful.

~Randy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Kernel 2.4.x TODO

[Dunlap, Randy]

> From: Sasi Peter [mailto:[EMAIL PROTECTED]]
> 
> > Check out the kernel janitor project at
> > http://bazar.conectiva.com.br/~acme/TODO (original)
> 
> Is this information up2date? If it is, sad to see we have 
> this many bugs... 

"Last updated in: Mon Feb 26 21:19:49 EST 2001"

The other link that I sent (the kernel janitor project) replaced this list
and should be more up-to-date...although I can't really find a TODO list
there:
http://sourceforge.net/projects/kernel-janitor

Jeff?

~Randy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Dyanmics Thread at Kernel Level

[Dunlap, Randy]

> On 26-Apr-2001 Rajeev Nigam wrote:
> > Can anybody  tell me, How can I create dynamic threads at 
> Kernel level??
> > 
> > If u have any sample code in which Semaphore, threads, events are
> > implemented, Pls send.
> > 
> > Waiting for ur response.
> 
> http://www.linux-mag.com/depts/gear.html

or http://www.scs.ch/~frey/linux/kernelthreads.html

~Randy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: input core pointers, someone?

[Dunlap, Randy]

http://www.suse.cz/development/input/

and Vojtech Pavlik ([EMAIL PROTECTED])


~Randy503-677-5408_
--- 

> -Original Message-
> From: Magnus Bodin [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 02, 2001 7:18 AM
> To: [EMAIL PROTECTED]
> Subject: input core pointers, someone?
> 
> 
> 
> I'm about to write a (IR) KEYBOARD device driver. I guess I'm 
> better off
> using the existing work on the USB-path with input core etc 
> that appeared sometimes around 2.2?
> 
> Is there ANY documentation/schematics on how this works or is 
> it 'Read The
> Fantastic Source' and/or e-mail Pavel Machek that is my way to go?
> 
> _Any_ pointers is of interest.
> 
> /magnus

> 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: USB init order dependencies.

[Dunlap, Randy]

> Personally, I think this fix is less ugly than any of the 
> alternatives I've seen so far.
> 
> It removes the dependency on init order completely, by 
> statically putting 
> the hub driver into the usb_driver_list at compile time.
> 
> Leave the link ordering stuff for 2.5.

David is entitled to his opinion (IMO).
And I dislike this patch, as he and I have already discussed.

Short of fixing the link order, I like Jeff's suggestion
better (if it actually works, that is):  go back to the
way it was a few months ago by calling usb_init()
from init/main.c and making the module_init(usb_init);
in usb.c conditional (#ifdef MODULE).

~Randy

-
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: test10-pre7 (LINK ordering)

[Randy Dunlap]

Linus Torvalds wrote:
> 
[snip]
> 
> That was going to be my next question if somebody actually said "sure".
> 
> The question was rhetorical, since the way LINK_FIRST is implemented
> means
> that it has all the same problems that $(obj-y) has, and is hard to get
> right in the generic case (but you can get it trivially right for the
> subset case, like for USB).


So now we have something in 2.4.0-test10, but there's
still a problem.  Help is appreciated^W wanted. !!!

With CONFIG_USB=y and all other USB modules built as
modules (=m), linking usbdrv.o into the kernel image
gives this:

ld -m elf_i386 -T /work/linsrc/240-test10/arch/i386/vmlinux.lds -e stext
arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o
init/version.o \
--start-group \
arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o
mm/mm.o fs/fs.o ipc/ipc.o \
drivers/block/block.o drivers/char/char.o drivers/misc/misc.o
drivers/net/net.o drivers/media/media.o drivers/parport/parport.a 
drivers/ide/idedriver.o drivers/scsi/scsidrv.o drivers/cdrom/cdrom.a
drivers/sound/sounddrivers.o drivers/pci/pci.a drivers/video/video.o
drivers/usb/usbdrv.o drivers/input/inputdrv.o drivers/i2c/i2c.o \
net/network.o \
/work/linsrc/240-test10/arch/i386/lib/lib.a
/work/linsrc/240-test10/lib/lib.a
/work/linsrc/240-test10/arch/i386/lib/lib.a \
--end-group \
-o vmlinux
drivers/usb/usbdrv.o(.data+0x2f4): undefined reference to
`__this_module'
make: *** [vmlinux] Error 1
[rdunlap@dragon linux]$ 


I believe that this is caused by drivers/usb/inode.c:

static DECLARE_FSTYPE(usbdevice_fs_type, "usbdevfs",
usbdevfs_read_super, 0);

in which this macro uses "THIS_MODULE".  inode.c already #includes
module.h.  What else does it need to do?
(inode.c is part of the usbcore in this case, so it shouldn't be
compiled with -DMODULE.)

Help ?!?

~Randy
-
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: USB Printer, in 2.4.0-test9

[Dunlap, Randy]

Hi,

Can you try the USB printer driver in 2.4.0-test10 and
let me know if it works for you?  [It works for me.]

~Randy_
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
---

> Strange things here.
> 
> I'm testing out 2.4.0-test9 kernel with USB, (reiserfs built in, but,
> hopefully this has nothing to do with it).
> 
> Hardware is a 440FX Dual PPro200/Natoma + 82371SB PIIX3/USB.
> Printer: HP DeskJet 880C USB/Parallel
> Mouse: Microsoft Intellimouse with Intellieye USB
> Other stuff: Belkin "Macintosh" USB hub
> 
> Symptoms:
> 
> USB Mouse appears to work totally fine.
> 
> USB Printer will print a few bytes, and suddenly print garbage
> (bitmap/pcl). I tried printing out some plain text and it's 
> MANGLING bits
> - corrupting random bytes of data.  The general structure of bytes are
> still there, but the resultant printout is gibberish.  
> (source print file
> is a text file printed via "cat file >/dev/usblp0" (which is device
> 180,0))
> 
> I get a bunch of form feeds too but it continues to print a 
> few characters
> fine and some that are totally wrong.  It looks like it's 
> corrupting about
> 5% of the characters, including some high bit 7 characters.
> 
> Any ideas what's going on, and is this repeatable by anyone else?  Bad
> hardware?  This SMP box only supports one form of the MPS, and I'm not
> sure how to tell the difference... I also tried using the 
> printer w/o the hub, and same results...

-
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: test10-pre7 (LINK ordering)

[Dunlap, Randy]

> > > With CONFIG_USB=y and all other USB modules built as
> > > modules (=m), linking usbdrv.o into the kernel image
> > > gives this:
> > 
> > > drivers/usb/usbdrv.o(.data+0x2f4): undefined reference to
> > 
> > Works for me here, .config attached.  Local changes, merge error, or
> > similar?  I don't have any local USB patches...
> 
> I agree.  My (rushed) bad.
> Didn't rm usb/*.o .
> 
> Thanks for catching me.  I'm pleased that there's
> no problem here.

Hi Jeff,

Did I speak too quickly again?

Can you successfully do 'depmod -ae' _before_
booting this kernel?

I still get lots of unresolved USB symbols in
all USB modules.

Is it valid to run depmod like this before
booting the kernel that has usbcore in-kernel?
depmod -ae works after I boot that kernel + usbcore.

~Randy

-
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: test10-pre7 (LINK ordering)

[Dunlap, Randy]

> > With CONFIG_USB=y and all other USB modules built as
> > modules (=m), linking usbdrv.o into the kernel image
> > gives this:
> 
> > drivers/usb/usbdrv.o(.data+0x2f4): undefined reference to
> 
> Works for me here, .config attached.  Local changes, merge error, or
> similar?  I don't have any local USB patches...

I agree.  My (rushed) bad.
Didn't rm usb/*.o .

Thanks for catching me.  I'm pleased that there's
no problem here.

~Randy

-
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: fork in module?

[Dunlap, Randy]

x = kernel_thread(&func, &arg, flags);

might do what you want.

~Randy_
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
--- 

> From: Heusden, Folkert van [mailto:[EMAIL PROTECTED]]
> 
> what would be the way of starting a sub-process in a module 
> which then would
> run in the background? I guess plain fork() won't work?
> -

-
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: 3-order allocation failed

[Dunlap, Randy]

Hi,

> From: Pasi Kärkkäinen [mailto:[EMAIL PROTECTED]]
> 
> On Thu, 26 Oct 2000, Rik van Riel wrote:
> 
> > On Thu, 26 Oct 2000, Forever shall I be. wrote:
> > > On Thu, Oct 26, 2000 at 02:57:30PM +0300, Pasi Kärkkäinen wrote:
> > 
> > > > __alloc_pages: 2-order allocation failed.
> > > > __alloc_pages: 2-order allocation failed.
> > > > __alloc_pages: 5-order allocation failed.
> > > > __alloc_pages: 4-order allocation failed.
> > > > __alloc_pages: 3-order allocation failed.
> > > > __alloc_pages: 2-order allocation failed.
> > > > __alloc_pages: 5-order allocation failed.
> > > > 
> > > > Any ideas?
> > > 
> > > I'm getting __alloc_pages: 7-order allocation failed.
> > > all the time in 2.4.0-test9 on my "pIII (Katmai)".. kernel's
> > > compiled with 2.95.2 + bounds, without -fbounds-checking
~
Are there many places in the kernel that
do that (alloc 2^8 = 256 pages) .. after init?
Do you know where/what it is?  Sound driver maybe?

> > It means something in the system is trying to allocate a
> > large continuous area of memory that isn't available...
> > 
> > The printk is basically a debug output indicating that we
> > don't have the large physically contiguous area available
> > that's being requested.
> > 
> > Basically everything bigger than order-1 (2 contiguous
> > pages) is unreliable at runtime. Orders 2 and 3 should
> > usually be available (if you only allocate very few of
> > them) and higher orders should not be relied upon.
> > 
> > If somebody is seeing a lot of these messages, it means
> > that some driver in the system is asking unreasonable
> > things from the VM subsystem ;)
> > 
> > (and buffer allocations are failing)
> > 
> 
> I got those order-x messages when I was running a script, that looked
> something like this:
> 
>   streamer -s 320x240 -o webcam.jpg
>   sleep 5
> 
> It worked fine for about 20 minutes, and after I started to get those
> messages and the camera didn't work anymore.
> 
> Solution: I'm now using a program, that is "using the camera all the
> time" and it just saves the frames with 5 seconds delay.
~~
Makes sense.  Good, practical workaround solution.

I looked thru cpia_usb_open() and everything that it
calls or causes in your scenario, and the only
order-2 allocation that I see is in cpia_usb_open().

If order-1 allocs are much better than order-2 allocs,
like Rik said, then you could change
drivers/media/video/cpia_usb.c line 41 (in 2.4.0-test10)
to be: #define FRAMES_PER_DESC  8
instead of 10.  That would make the kmalloc()'s in
cpia_usb_open() be order-1 instead of order-2.
All of the other kmalloc()s in the USB subsystem in this
scenarios are already small (less than 1 page).
Please let me/us know how this works if you try it.


> The script I was running previously used streamer, that 
> initializes and 
> opens the v4l-device everytime I run it.
> 
> Is this bug in the usb-driver (usb-uhci), in the camera's driver
> (cpia_usb) or in the v4l?
~~
Could there be a memory leak as well?  But I expect that
it's simply that memory is just fragmented so that enough
contiguous pages aren't available, like Rik said.

~Randy

-
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: 3-order allocation failed

[Dunlap, Randy]

Wow, I bet that's been there awhile.

BTW, did you submit this patch earlier?  I don't
recall having seen it.

I'll forward it.

Thanks,
~Randy_
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
--- 

> -Original Message-
> From: Anthony Towns [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 01, 2000 2:21 PM
> To: unlisted-recipients
> Cc: 'Pasi Kärkkäinen'; Rik van Riel; Forever shall I be.;
> [EMAIL PROTECTED]
> Subject: Re: 3-order allocation failed
> 
> 
> On Wed, Nov 01, 2000 at 01:42:17PM -0800, Dunlap, Randy wrote:
> > > Is this bug in the usb-driver (usb-uhci), in the camera's driver
> > > (cpia_usb) or in the v4l?
> > ~~
> > Could there be a memory leak as well?  But I expect that
> > it's simply that memory is just fragmented so that enough
> > contiguous pages aren't available, like Rik said.
> 
> There is a memory leak, the memory kmalloc'ed in cpia_usb_open for
> sbuf[*].data is never kfree'd (except when an error occurs during
> initialisation). Adding some kfree's in cpia_usb_free_resources fixed
> the problem in test7 or so, here's a patch against -test10.
> 
> --- drivers/media/video/cpia_usb.c.orig   Wed Nov  1 14:14:37 2000
> +++ drivers/media/video/cpia_usb.cWed Nov  1 14:16:05 2000
> @@ -432,10 +432,20 @@
>   ucpia->sbuf[1].urb = NULL;
>   }
>  
> + if (ucpia->sbuf[1].data) {
> + kfree(ucpia->sbuf[1].data);
> + ucpia->sbuf[1].data = NULL;
> + }
> + 
>   if (ucpia->sbuf[0].urb) {
>   usb_unlink_urb(ucpia->sbuf[0].urb);
>   usb_free_urb(ucpia->sbuf[0].urb);
>   ucpia->sbuf[0].urb = NULL;
> + }
> +
> + if (ucpia->sbuf[0].data) {
> + kfree(ucpia->sbuf[0].data);
> + ucpia->sbuf[0].data = NULL;
>   }
>  }
> 
> HTH.
> 
> Cheers,
> aj 
> 
> -- 
> Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
> I don't speak for anyone save myself. GPG signed mail preferred.

-
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: USB init order dependencies.

[Dunlap, Randy]

While Jeff and I basically agree on the short-term
solution (if one is still needed, altho I'm not aware of
any init order problems in USB in 2.4.0-test10), my
recollection of Linus's preference (without
looking it up) is to remove the calls from init/main.c
and to use __initcalls.

~Randy

> -Original Message-
> From: Jeff Garzik [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, November 04, 2000 12:25 AM
> To: Russell King
> Cc: Dunlap, Randy; 'David Woodhouse'; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: USB init order dependencies.
> 
> 
> Russell King wrote:
> > 
> > Dunlap, Randy writes:
> > > David is entitled to his opinion (IMO).
> > > And I dislike this patch, as he and I have already discussed.
> > >
> > > Short of fixing the link order, I like Jeff's suggestion
> > > better (if it actually works, that is):  go back to the
> > > way it was a few months ago by calling usb_init()
> > > from init/main.c and making the module_init(usb_init);
> > > in usb.c conditional (#ifdef MODULE).
> > 
> > However, that breaks the OHCI driver on ARM.  Unless we're 
> going to start
> > putting init calls back into init/main.c so that we can 
> guarantee the order
> > of init calls which Linus will not like, you will end up 
> with a lot of ARM
> > guys complaining.
> > 
> > Linus, your opinion would be helpful at this point.
> 
> Back when some of the initial USB initcall stuff started appearing,
> there were similar discussions, similar problems, and similar
> solutions.  I was also wondering how fbdev (which needs to give you a
> console ASAP) would work with initcalls, etc.  At the time (~6 months
> ago?), Linus' opinion was basically "if the link order 
> hacking starts to
> get ugly, just put it in init/main.c"  So, Randy really should be
> calling the quoted text above "Linus' suggestion" ;-)
> 
> Putting a call into init/main.c isn't a long term solution, but it
> should get us there for 2.4.x...  init/main.c is also the 
> best solution
> for ugly cross-directory link order dependencies.  I would 
> say the link
> order of foo.o's in linux/Makefile is the most delicate/fragile of all
> the Makefiles...  touching linux/Makefile link order this 
> close to 2.4.0
> is asking for trouble.  Compared to that, adding a few lines to
> init/main.c isn't so bad.
> 
> IMHO,
> 
>   Jeff

-
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: USB init order dependencies.

[Dunlap, Randy]

Randy.Dunlap wrote:
> > While Jeff and I basically agree on the short-term
> > solution (if one is still needed, altho I'm not aware of
> > any init order problems in USB in 2.4.0-test10), my
> > recollection of Linus's preference (without
> > looking it up) is to remove the calls from init/main.c
> > and to use __initcalls.
> 
Russell King wrote:
> The problem for ARM is that Linux does a lot of the initialisation for
> some machines,

but not for ARM ?

> which basically means the hardware isn't setup 
> for access
> to the USB device if the USB initialisation was placed in init/main.c
> (this initialisation is done by the very first initcall on 
> ARM).  However,
> that said, we may be able to get away with only adding 
> hw_sa1100_init()
> before the USB call, but this is only one family of the ARM 
> machine types.

I'm not following your argument very well.  I've read it
and reread it several times.
Does adding a call to usb_init() in init/main.c cause
USB to be init 2 times?
I'm not complaining or arguing against you, just
trying to understand better.

> BTW, I've long lost track of what the original problem that 
> sparked off
> this thread was, does someone have a quick reference to it?  (please
> reply in private mail).  Thanks.

There were several threads but I can't find the
"original" one right now.  IIRC, it was simply that
CONFIG_USB=y and CONFIG_USB_*=m (any USB except usbcore
built as modules) caused depmod problems, but that could
be incorrect also.

~Randy

-
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: USB init order dependencies.

[Dunlap, Randy]

> From: Russell King [mailto:[EMAIL PROTECTED]]
> 
> Dunlap, Randy writes:
> > I'm not following your argument very well.  I've read it
> > and reread it several times.
> > Does adding a call to usb_init() in init/main.c cause
> > USB to be init 2 times?
> 
> No.  As I said elsewhere in this thread, the USB OHCI chip is 
> not accessible
> until other board-specific initialisation has happened.  This 
> is done via an
> initcall.  Unfortunately, moving usb_init() back into 
> init/main.c will mean
> that USB is again initialised before any initcalls, which 
> means for these
> boards USB will be non-functional without additional changes 
> over and above just moving usb_init().
> 
> I hope this helps you understand the problem.

Yes, that does help.

David Woodhouse wrote:
> But OHCI init isn't called from usb_init() is it?

No, it's not.  It's another __initcall (module_init).

> The proposal is only to move the single call to usb_init() back into 
> init/main.c - not to move all the USB initcalls back.

Yes, your proposal is to init only "usbcore" from init/main.c.
I still don't see a need to do this in test10.
It's fixed now AFAIK.

~Randy

-
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: USB init order dependencies.

[Dunlap, Randy]

> [EMAIL PROTECTED] said:
> >  Yes, your proposal is to init only "usbcore" from init/main.c. I
> > still don't see a need to do this in test10. It's fixed now AFAIK.
> 
> Not my proposal. The proposal to which Russell was objecting. 
> 
> My proposal was to just make the thing work without having to 
> care about the link order.
> 
> --
> dwmw2

OK, I stand corrected.  My bad.

Sounds like we basically all want the same thing.  :)

~Randy

-
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: PCI-PCI bridges mess in 2.4.x

[Dunlap, Randy]

Hi Jeff-

> Also, should we be setting PCI_CACHE_LINE_SIZE for PCI devices as well
> as bridges?

If/when we do set PCI_CACHE_LINE_SIZE, please don't
set it to a hard-coded, inline constant, like 8 (e.g.),
like some drivers do.

Please use something like (PCI_CACHE_LINE_SIZE / 4)
instead.  ["/ 4" to convert bytes to "dwords" or
whatever, since the PCI_CACHE_LINE_SIZE register
is in 4-byte units.]

~Randy
___
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
--- 

-
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: [bug] usb-uhci locks up on boot half the time

[Dunlap, Randy]

> From: David Ford [mailto:[EMAIL PROTECTED]]
> 
[snip]
> > Is the external hub a externally powered hub, or self 
> powered hub (does
> > it get it's power from a plug in the wall, or from the USB 
> bus)?  Self
> > powered hubs are notoriously flaky and have been known to 
> > evil things to the USB bus.
> 
> Either.  Currently bus (self) powered.  This hub has worked 
> fine on my other
> computers without any adverse affect.

Bus-powered != self-powered.

Self-powered means that it has its own power cord.

Bus-powered means that it gets its power from the USB cable.

Unlike Greg, I would have said that bus-powered hubs
can be a problem -- especially when you plug too many
devices into them that need lots of power.  What we saw
at the USB PlugFest was hubs just shutting down when
we did this.  :(

~Randy

-
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: Porting Linux v2.2.x Ethernet driver to v2.4.x?

[Dunlap, Randy]

Search the lkml archives.  Here are 2 instances
to find:

from jamal, 2000-jan-6: [ANNOUNCE] SOFTNETing Network Drivers HOWTO

from kuznet, 2000-feb-14: "softnet" drivers: an attempt to clarify

from dave miller, 2000-feb-9: new network driver interface changes, README
  http://www.uwsg.indiana.edu/hypermail/linux/kernel/0002.1/0408.html
from jamal, 2000-feb-10:  ditto
  http://www.uwsg.indiana.edu/hypermail/linux/kernel/0002.1/0461.html
from dave miller, 2000-feb-12: ditto

___
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
--- 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 09, 2000 10:01 AM
> To: [EMAIL PROTECTED]
> Subject: Porting Linux v2.2.x Ethernet driver to v2.4.x?
> 
> 
> 
> 
> Hello.
> 
> I am about to modify a Linux v2.2.x-compatible Ethernet 
> driver to allow it to
> work in the new v2.4.x kernel.  Are there any documents which 
> describe the
> differences in the device driver models (particularly PCI and 
> Ethernet) of the 2
> kernel versions?  If so, where can I find them?
> 
> Thank you.
> 
> (Sorry about the advertisement below.)
> 
> 
> 
> 
> PLANET PROJECT will connect millions of people worldwide 
> through the combined
> technology of 3Com and the Internet. Find out more and register now at
> http://www.planetproject.com
> 
> 
> -
> 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/
> 

-
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: latest 2.2.18-X patch?

[Dunlap, Randy]

ftp.??.kernel.org/pub/linux/kernel/v2.2
for linux-2.2.17.tar.{gz,bz2}
and then ftp.??.kernel.org.pub/linux/kernel/people/alan/2.2.18pre
for pre-patch-2.2.18-21.{gz,bz2}

Yes (USB backport).

~Randy_
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
--- 

> From: Michael Rothwell [mailto:[EMAIL PROTECTED]]
> 
> Where's the best place to get the latest 2.2.18 kernel? And does it
> include the USB backport?
> -

-
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: State of Posix compliance in v2.2/v2.4 kernel?

[Dunlap, Randy]

> [EMAIL PROTECTED] wrote:
> > Sorry if this is a FAQ, but I've searched the archives for this list
> > (http://www.uwsg.iu.edu/hypermail/linux/kernel/) and only 
> come with references
> > from 1996!
> > 
> > What is the state of Posix-compliant services (threads, 
> semaphores, timers,
> > etc.) in the current (v2.2/v2.4) Linux kernels?
> 
> IMHO this is a question better asked of glibc people, not 
> kernel people.
> 
> The kernel does its best to facilitate POSIX compliances, but in some
> cases the kernel developers have said "POSIX is braindead here!" and
> solved a particular problem in a non-POSIX way.  [and leaves glibc to
> pick up the pieces, and enforce POSIX compliancy]
> 
> Also, from what I've seen lately on IRC and lkml, the Single Unix
> Specification ("SuS") is generally held in higher regard than 
> POSIX; and
> when spec questions arise, kernel developers tend to check SuS before
> POSIX (if POSIX is checked at all).
> 
>   Jeff

and there's some useful info about libc, threads, etc.,
at the Linux Standard Base CVS (http://www.linuxbase.org/
plus its sf.net project page + CVS links).

~Randy

-
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: Patch(?): linux-2.4.0-test11-pre4/drivers/sound/yss225.c compilefailure

[Dunlap, Randy]

> From: Jeff Garzik [mailto:[EMAIL PROTECTED]]
> 
> Greg KH wrote:
> > On Wed, Nov 15, 2000 at 12:29:15AM -0500, Jeff Garzik wrote:
> > > If we are going to create CONFIG_USB_HOTPLUG, we must -eliminate-
> > > CONFIG_HOTPLUG, and create CONFIG_PCI_HOTPLUG, and
> > > CONFIG_ANOTHERBUS_HOTPLUG and so on, for each hotplug bus.
> > 
> > Argh!
> > I thought the whole point of this was to make there be only 
> one hotplug
> > strategy, due to the fact that this is a real need.
> > 
> > Please let's not go down this path.  It was all starting to look so
> > nice...
> 
> I -want- there to be only one hotplug strategy, but Adam seemed to be
> talking about the opposite, with his CONFIG_USB_HOTPLUG suggestion.

I told Adam that I didn't want that patch, but it's not
up to me now.

> I'm hoping that Linus will disagree with the splintering of
> CONFIG_HOTPLUG too...

And JE.

> I think it's too late in 2.4.x cycle to change now anyway.

And I told Adam that also.

>   Jeff

~Randy

-
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: keyboard lockup after kdb session

[Dunlap, Randy]

Hi,

I have the same problem with kdb.

In a controlled environment, I always start a script
before entering kdb:

  while [ 1 ] ; do
sleep 3
/etc/rc.d/init.d/gpm restart > /dev/null
  done

This will re-enable the kbd every 3 seconds.

But it would be nice to find the problem, eh?

~Randy_
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
---

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 15, 2000 4:51 AM
> To: [EMAIL PROTECTED]
> Subject: keyboard lockup after kdb session
> 
> 
> Hi,
> I am new to kdb. my keyboard is locked after kdb-session (either by
> generating oops or manual).
> is there any way to restore it without rebooting...
> thanks
> anil
> 
> 
> -
> 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/
> 

-
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: CONFIG_USB_HOTPLUG (was Patch(?): linux-2.4.0-test11-pre4/drivers/sound/yss225.c compile failure)

[Dunlap, Randy]

Hi Adam,

> From: Adam J. Richter [mailto:[EMAIL PROTECTED]]
> 
> >From [EMAIL PROTECTED] Wed Nov 15 09:04:36 2000
> >> From: Jeff Garzik [mailto:[EMAIL PROTECTED]]
> >> 
> >> Greg KH wrote:
> >> > On Wed, Nov 15, 2000 at 12:29:15AM -0500, Jeff Garzik wrote:
> >> > > If we are going to create CONFIG_USB_HOTPLUG, we must 
> -eliminate-
> >> > > CONFIG_HOTPLUG, and create CONFIG_PCI_HOTPLUG, and
> >> > > CONFIG_ANOTHERBUS_HOTPLUG and so on, for each hotplug bus.
> >> > 
> >> > Argh!
> >> > I thought the whole point of this was to make there be only 
> >> one hotplug
> >> > strategy, due to the fact that this is a real need.
> >> > 
> >> > Please let's not go down this path.  It was all starting 
> to look so
> >> > nice...
> >> 
> >> I -want- there to be only one hotplug strategy, but Adam 
> seemed to be
> >> talking about the opposite, with his CONFIG_USB_HOTPLUG suggestion.
> 
> >I told Adam that I didn't want that patch, but it's not
> >up to me now.
> 
>   You said you wanted to "hold of on CONFIG_USB_HOTPLUG for now",
> which I take to mean up to 2.4.0.

OK, I stand corrected.
Actually I don't recall what that meant.  You could be right,
but it could have meant that it should be re-evaluated later.

>   I have not asked that CONFIG_USB_HOTPLUG be put in 
> 2.4.0, although
> I would not mind.  I am just agreeing with you (Randy) when you
> identified the problem and wrote in linux-usb-devel "[Why] is 
> it safe to
> use __devinitdata on the usb_device_id table?  It's used 
> during any new
> device connect, after driver init, right ...?"  You were right: the
> __devinitdata being used in the USB drivers will probably crash the
> kernel if CONFIG_HOTPLUG is not defined and the USB code attempts to
> recover from an error by faking disconnect/reconnect.
> 
>   The statements about how we might address this issue more
> fully have been about in the context of after 2.4.0.  To refresh your
> memory, in my first message on this thread I wrote:
> 
> |After 2.4.0, and after the fake disconnect/reconnect code in
>  ^^^
> | drivers/usb/{devio,storage/scsiglue}.c is designed out, then we may
> | want to explore adding __usbdevinit{,data} defines in 
> include/linux/init.h
> | that would be controlled by a new CONFIG_USB_HOTPLUG option, as in
> | the patches that I posted for this to linux-usb-devel. 
> 
>   Until there is __usbdev{init,exit}{,data}, the incorrect
> __devinitdata qualifiers should be removed from the USB device
> drivers (but not from the host controller drivers, which are 
> PCI drivers).

I agreed with you that the __dev qualifiers should be
removed for now, until there is a better solution.
I didn't agree that we should add __usbdev qualifiers.
I think that we should have a unified hotplug strategy,
whatever it is/becomes.

Like Greg and Jeff have said, I'd prefer not to see
CONFIG_whateverbuses_HOTPLUG, but I'm saying that based
on style and KISS, not on technical evaluation,
so I could be wrong.  What you are proposing could be
the right thing to do.  Maybe you are way ahead of my
thinking on this.

>   Would you like to propose a different solution, Randy?

No thanks, I think that we have enough [good] cooks in the
kitchen for now.  If I find that I have some time to
contribute to it, I would like to, but not now.
Obviously I may miss the window of time to contribute
to this if I don't do it now, but c'est la vie.

~Randy

-
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: "SubmittingPatches" text

[Dunlap, Randy]

Hi Jeff,

I compared my personal hints list to yours.
Yours is much more complete and better.

Here are a few comments for you to consider (below).

Thanks,
~Randy_
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
---


> 4) Select e-mail destination.
> 
...

However, your patch(es) must be sent directly to Linus or to
other maintainers to send to Linus.  He doesn't troll linux-kernel
or other mailing lists looking for patches.


> 8) Name your kernel version.
> 
> It is important to note, either in the subject line or in the patch
> description, the kernel version to which this patch applies.

However, your patch should apply cleanly (no failures, little
to no fuzz) to the latest kernel version.

> 9) Don't get discouraged.  Re-submit.
> 
...
> It is quite common for Linus to "drop" your patch without comment.
> That's the nature of the system.  If he drops your patch, it could be
> due to
> * A style issue (see section 2),
> * An e-mail formatting issue (re-read this section)
> * A technical problem with your change
> * He gets tons of e-mail, and yours got lost in the shuffle
> * You are being annoying (See Figure 1)

+ * Your patch fails to apply or has (too much) fuzz.

-
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: 53c400 driver

[Dunlap, Randy]

JE's UHCI driver (drivers/usb/uhci.[hc]) uses
nested_lock() and nested_unlock() for this.
Maybe it could help.

~Randy
___
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
---

> -Original Message-
> From: Alan Cox [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 21, 2000 3:48 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: 53c400 driver
> 
> 
> > 53c400a non-PNP still lock this system hard. It starts 
> barking about a
> > busy SCSI bus, and then I can fsck again.
> > 
> > To Alan : How hard is it to get thing beast (53c400 and 
> family) to be SMP
> > safe ?? Or is it better to start over again ?
> 
> The problem is that the code takes spinlocks recursively. The original
> code (see 2.0's 5380 generic C code) uses cli/sti. It was converted to
> use spin_lock() but not allowing for the recursive locking 
> cases. I tried
> to untangle the code paths but they are so ugly and some of 
> the code is
> sufficiently messy and unmaintained (for about 6 years) that I gave up
> trying to decode it.
> 
> Alan
> 
> -
> 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/
> 

-
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: KERNEL BUG: console not working in linux

[Dunlap, Randy]

Hi,

I've been taking some holidays and haven't followed
all of this thread closely, but:

> From: Albert D. Cahalan [mailto:[EMAIL PROTECTED]]
> 
> H. Peter Anvin writes:
> > [Albert Cahalan]
> >> [Alan Cox]
> 
> >>>> 1) Why did they disable my videocard ?
> >>>
> >>> Because your machine is not properly PC compatible
> >>
> >> The same can be said of systems that don't support the
> >> standard keyboard controller for A20 control.

Just curious: Are you (Alan?) saying this ("standard") based on the
unpublished IBM PC specs (well, it was when I needed it around
1990; don't know about now ???).  Or do you have a copy
of it?  They were mighty hard to come by, and I was working
on a contract for IBM at the time (not at Intel).

> > Yes, it can.  Unfortunately, some "legacy-free" PCs apparently
> > are starting to take the tack that the KBC is legacy.  Therefore,
> > the use of port 92h is mandatory on those systems.
> 
> Not just embedded systems?

Right.  Not just embedded systems.

> > Port 92h dates back to at the very least the IBM PS/2.
> > 
> > Either way, the video card of the original poster is broken in more
> > ways than that.  Ports 0x00-0xFF are reserved for the motherboard
> > chipset and have been since the original IBM PC.
> 
> His video card is the motherboard. He has built-in video.
> So the port is being used by his motherboard chipset.
> -

~Randy

-
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/

usbdevfs mount 2x, umount 1x

[Randy Dunlap]

[I reported this a couple of months back.  Got no
feedback on it.  If it's just a DDT (don't do that)
or a user error, please say so.]

Summary:  After I mount usbdevfs 2 times, and umount it
1 time, the usbcore module use count prevents it from
being rmmod-ed.

This is test12-pre2.


1.  Start by loading usbcore and uhci modules:
 
[root@dragon rdunlap]# lsmod
Module  Size  Used by
uhci   18848   0  (unused)
usbcore50656   0  [uhci]

and the /proc/bus/usb mount point is empty:

[rdunlap@dragon rdunlap]$ ls -l /proc/bus/usb
total 0

2.  I enter "mount usb", which uses this entry
from /etc/fstab:
usb/proc/bus/usbusbdevfs defaults,user  0 0

'mount' then tells me (usb line extracted):

usb on /proc/bus/usb type usbdevfs (rw,noexec,nosuid,nodev)

and 'lsmod' tells me:

[root@dragon rdunlap]# lsmod
Module  Size  Used by
uhci   18848   0  (unused)
usbcore50656   1  [uhci]

3.  Some time passes.  I mount usbdevfs again, by entering:

[root@dragon rdunlap]# mount -t usbdevfs usbdevfs /proc/bus/usb

'lsmod' now tells me:

[root@dragon rdunlap]# lsmod
Module  Size  Used by
uhci   18848   0  (unused)
usbcore50656   2  [uhci]

and 'mount' tells me:

usb on /proc/bus/usb type usbdevfs (rw,noexec,nosuid,nodev)
usbdevfs on /proc/bus/usb type usbdevfs (rw)

4.  I 'umount usbdevfs'.  Now 'lsmod' tells me:

[root@dragon rdunlap]# umount usbdevfs
[root@dragon rdunlap]# lsmod
Module  Size  Used by
uhci   18848   0  (unused)
usbcore50656   1  [uhci]

and 'mount' shows no usb or usbdevfs entries listed.

Now I rmmod uhci and 'lsmod' tells me:

[root@dragon rdunlap]# rmmod uhci
[root@dragon rdunlap]# lsmod
Module  Size  Used by
usbcore50656   1 

and I can't rmmod usbcore.  The /proc/bus/usb mount
point is still populated and the 'drivers' file
contains correct data:

[rdunlap@dragon rdunlap]$ ls -l /proc/bus/usb
total 0
-r--r--r--   1 root root0 Nov 29 16:17 devices
-r--r--r--   1 root root0 Nov 29 16:17 drivers

[rdunlap@dragon rdunlap]$ cat /proc/bus/usb/drivers 
 hub
 usbdevfs
[rdunlap@dragon rdunlap]$


So is this just a case of root being able to shoot self
in foot or a proc-fs or module counter problem? 

Notes:
1. Reversing the order of steps 3 and 4 gives the
same results.
2. Changing the device name in
'mount -t usbdevfs usbdevfs /proc/bus/usb' to be
'mount -t usbdevfs usbfs   /proc/bus/usb' gives the
same results (when followed by 'umount usbfs').

Thanks,
~Randy
-- 
___
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
---
-
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: usbdevfs mount 2x, umount 1x

[Dunlap, Randy]

> > > So umount it twice.
> > I don't see a way to umount it twice or I would have done that.
> > Is there a way?
> 
> Erm... Say umount one more time? If _that_ doesn't work - we've got a
> bug, either in umount(2) or in umount(8). Strace would be welcome.

Or I'm using an old version of umount (from RH 5.2) ?
I'll check on that and the strace.

~Randy

-
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: usbdevfs mount 2x, umount 1x

[Dunlap, Randy]

> From: Alexander Viro [mailto:[EMAIL PROTECTED]]
> 
> On Wed, 29 Nov 2000, Randy Dunlap wrote:
> 
> > [I reported this a couple of months back.  Got no
> > feedback on it.  If it's just a DDT (don't do that)
> > or a user error, please say so.]
> > 
> > Summary:  After I mount usbdevfs 2 times, and umount it
> > 1 time, the usbcore module use count prevents it from
> > being rmmod-ed.
> 
> So umount it twice.
I don't see a way to umount it twice or I would have done that.
Is there a way?

> And yes, it's "don't do it, then".
OK.

> Every mount() increments the use count.
Got that.

> Every umount() decrements it. You want it
> to become 0. Draw your conclusions...
Looks to me like umount unmounted it 2 times and decremented
the use count by 1.

I don't see a way for me to rmmod usbcore.  As it is,
I have to reboot the system (or just DDT).

Thanks,
~Randy

-
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: usbdevfs mount 2x, umount 1x

[Dunlap, Randy]

> From: Jan-Benedict Glaw [mailto:[EMAIL PROTECTED]]
> 
> On Wed, Nov 29, 2000 at 04:47:27PM -0800, Randy Dunlap wrote:
> > 
> > Summary:  After I mount usbdevfs 2 times, and umount it
> > 1 time, the usbcore module use count prevents it from
> > being rmmod-ed.
> 
> > [root@dragon rdunlap]# lsmod
> > usbcore50656   2  [uhci]
> 
> > and 'mount' shows no usb or usbdevfs entries listed.
> 
> Are there usbdevfs entries in /proc/mount? Maybe 'umount' removes
> too many entries from /etc/mtab...

Yes, that's how it looks to me also, so maybe it's not a kernel
problem.  Thanks for the tip.

Here's more info, including the strace that Al Viro asked for.
I also made sure that I'm using mount & umount version 2.10o.
Please let me know if you need anything else.

~Randy


1.  Start with empty slate: no modules, no usb mounts:

[root@localhost rdunlap]# lsmod
Module  Size  Used by

[root@localhost rdunlap]# mount
/dev/hdc5 on / type ext2 (rw)
none on /proc type proc (rw)
/dev/hdc1 on /boot type ext2 (rw)
none on /dev/pts type devpts (rw,mode=0620)
/dev/hdc7 on /home type ext2 (rw)
/dev/hdc6 on /usr type ext2 (rw)

[root@localhost rdunlap]# cat /proc/mounts
/dev/root / ext2 rw 0 0
/proc /proc proc rw 0 0
/dev/hdc1 /boot ext2 rw 0 0
none /dev/pts devpts rw 0 0
/dev/hdc7 /home ext2 rw 0 0
/dev/hdc6 /usr ext2 rw 0 0

2.  insmod usbcore and mount 'usb':

[root@localhost rdunlap]# insmod usbcore
Using /lib/modules/2.4.0-test11/kernel/drivers/usb/usbcore.o

[root@localhost rdunlap]# cat /etc/fstab
/dev/hdc5 / ext2 defaults 1 1
/dev/hdc1 /boot ext2 defaults 1 2
none /dev/pts devpts mode=0620 0 0
/dev/hdc7 /home ext2 defaults 1 2
/dev/cdrom /mnt/cdrom auto user,noauto,nosuid,exec,nodev,ro 0 0
/dev/fd0 /mnt/floppy auto sync,user,noauto,nosuid,nodev 0 0
none /proc proc defaults 0 0
usb /proc/bus/usb usbdevfs defaults,user 0 0
/dev/hdc6 /usr ext2 defaults 1 2
/dev/hdc2 swap swap defaults 0 0

[root@localhost rdunlap]# mount usb

3.  This gives us:

[root@localhost rdunlap]# lsmod
Module  Size  Used by
usbcore52224   1 

[root@localhost rdunlap]# mount
/dev/hdc5 on / type ext2 (rw)
none on /proc type proc (rw)
/dev/hdc1 on /boot type ext2 (rw)
none on /dev/pts type devpts (rw,mode=0620)
/dev/hdc7 on /home type ext2 (rw)
/dev/hdc6 on /usr type ext2 (rw)
usb on /proc/bus/usb type usbdevfs (rw,noexec,nosuid,nodev)

[root@localhost rdunlap]# cat /proc/mounts
/dev/root / ext2 rw 0 0
/proc /proc proc rw 0 0
/dev/hdc1 /boot ext2 rw 0 0
none /dev/pts devpts rw 0 0
/dev/hdc7 /home ext2 rw 0 0
/dev/hdc6 /usr ext2 rw 0 0
usb /proc/bus/usb usbdevfs rw,noexec,nosuid,nodev 0 0

4.  A second mount (slightly different 'device' name = "usbfs") gives:

[root@localhost rdunlap]# mount -t usbdevfs usbfs /proc/bus/usb

[root@localhost rdunlap]# lsmod
Module  Size  Used by
usbcore52224   2 

[root@localhost rdunlap]# mount
/dev/hdc5 on / type ext2 (rw)
none on /proc type proc (rw)
/dev/hdc1 on /boot type ext2 (rw)
none on /dev/pts type devpts (rw,mode=0620)
/dev/hdc7 on /home type ext2 (rw)
/dev/hdc6 on /usr type ext2 (rw)
usb on /proc/bus/usb type usbdevfs (rw,noexec,nosuid,nodev)
usbfs on /proc/bus/usb type usbdevfs (rw)

[root@localhost rdunlap]# cat /proc/mounts
/dev/root / ext2 rw 0 0
/proc /proc proc rw 0 0
/dev/hdc1 /boot ext2 rw 0 0
none /dev/pts devpts rw 0 0
/dev/hdc7 /home ext2 rw 0 0
/dev/hdc6 /usr ext2 rw 0 0
usb /proc/bus/usb usbdevfs rw,noexec,nosuid,nodev 0 0
usbfs /proc/bus/usb usbdevfs rw 0 0

5.  [root@localhost rdunlap]# strace -xv -o umount.st2 umount usb

gives (strace output at end):

[root@localhost rdunlap]# lsmod
Module  Size  Used by
usbcore52224   1 

[root@localhost rdunlap]# mount
/dev/hdc5 on / type ext2 (rw)
none on /proc type proc (rw)
/dev/hdc1 on /boot type ext2 (rw)
none on /dev/pts type devpts (rw,mode=0620)
/dev/hdc7 on /home type ext2 (rw)
/dev/hdc6 on /usr type ext2 (rw)
<<<<<<<<<<<<<<<<< no usb here >>>>>>>>>>>>>>>>>>>>>>

[root@localhost rdunlap]# cat /proc/mounts
/dev/root / ext2 rw 0 0
/proc /proc proc rw 0 0
/dev/hdc1 /boot ext2 rw 0 0
none /dev/pts devpts rw 0 0
/dev/hdc7 /home ext2 rw 0 0
/dev/hdc6 /usr ext2 rw 0 0
usb /proc/bus/usb usbdevfs rw,noexec,nosuid,nodev 0 0 <-

6.  Trying to umount the remaining usb mount:

[root@localhost rdunlap]# umount usb
umount: usb: not found

[root@localhost rdunlap]# umount /proc/bus/usb

[root@localhost rdunlap]#  mount
/dev/hdc5 on / type ext2 (rw)
none on /proc type proc (rw)
/dev/hdc1 on /boot type ext2 (rw)
none on /dev/pts type devpts (rw,mode=0620)
/dev/hdc7 on /home type ext2 (rw)
/dev/hdc6 on /usr type ext2 (rw)

[root@localhost rdunlap]# cat /proc/mounts
/dev/

RE: Nightly usb oops

[Dunlap, Randy]

Hi,

What kernel (test10)?
>  -m /boot/System.map-2.4.0-test10 (specified)

What compiler/version?

Please post a list of your USB devices from
/proc/bus/usb/devices .

Are you inserting or unplugging a USB device when this happens?
If not, are you doing anything with USB when this happens?

Thanks,
~Randy_
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
---

> -Original Message-
> From: J. Nick Koston [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 04, 2000 7:13 AM
> To: [EMAIL PROTECTED]
> Subject: Nightly usb oops
> 
> 
> My machine crashes almost every night with this oops.  I've finally
> managed to catch it before it was totally gone.
> 
> 
> ksymoops 2.3.4 on i686 2.4.0-test10.  Options used
>  -V (default)
>  -k /proc/ksyms (default)
>  -l /proc/modules (default)
>  -o /lib/modules/2.4.0-test10 (specified)
>  -m /boot/System.map-2.4.0-test10 (specified)
> 
> Warning (compare_maps): snd symbol pm_register not found in 
> /lib/modules/2.4.0-test10/misc/snd.o.  Ignoring 
> /lib/modules/2.4.0-test10/misc/snd.o entry
> Warning (compare_maps): snd symbol pm_send not found in 
> /lib/modules/2.4.0-test10/misc/snd.o.  Ignoring 
> /lib/modules/2.4.0-test10/misc/snd.o entry
> Warning (compare_maps): snd symbol pm_unregister not found in 
> /lib/modules/2.4.0-test10/misc/snd.o.  Ignoring 
> /lib/modules/2.4.0-test10/misc/snd.o entry
>   0fef3340 e0 Stalled CRC/Timeo Length=7 MaxLen=7 DT0 
> EndPt=0 Dev=1b, PID=2d(SETUP) (buf=0bd41580)
... (many STALL/CRC/Timeouts for Dev=1b, 22, 25) ...
> Unable to handle kernel NULL pointer dereference at virtual 
> address 0014
> c01faed6
> *pde = 
> Oops: 
> CPU:0
> EIP:0010:[]
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010282
> eax: 0008   ebx: cbd41385   ecx: cbd41380   edx: 0008
> esi:    edi: cfe12400   ebp: 0001   esp: c14fdf0c
> ds: 0018   es: 0018   ss: 0018
> Process khubd (pid: 7, stackpage=c14fd000)
> Stack: cbd41385  cfe12400 0001 0008  
> 0009  
>0001   c01fb1f3 cfe12400  
> cfe12400 c5985802 
>cfe12400  cbd41380 cbd41380 c01fb7f1 cfe12400 
> 0001  
> Call Trace: [] [] [] 
> [] [] [] [] 
>[] [] 
> Code: 8b 42 0c c7 44 24 24 00 00 00 00 0f b6 72 04 39 74 24 24 0f 
> 
> >>EIP; c01faed6<=
> Trace; c01fb1f3 
> Trace; c01fb7f1 
> Trace; c01fcc60 
> Trace; c01fce32 
> Trace; c0293580 
> Trace; c0293647 
> Trace; c01fcfa5 
> Trace; c0105000 
> Trace; c0108c03 
> Code;  c01faed6 
>  <_EIP>:
> Code;  c01faed6<=
>0:   8b 42 0c  mov0xc(%edx),%eax   <=
> Code;  c01faed9 
>3:   c7 44 24 24 00 00 00  movl   $0x0,0x24(%esp,1)
> Code;  c01faee0 
>a:   00 
> Code;  c01faee1 
>b:   0f b6 72 04   movzbl 0x4(%edx),%esi
> Code;  c01faee5 
>f:   39 74 24 24   cmp%esi,0x24(%esp,1)
> Code;  c01faee9 
>   13:   0f 00 00  sldt   (%eax)
> 
> Unable to handle kernel NULL pointer dereference at virtual 
> address 0008
> c013ed99
> *pde = 
> Oops: 
> CPU:0
> EIP:0010:[]
> EFLAGS: 00010246
> eax: 0008   ebx:    ecx: 000c   edx: 0002
> esi:    edi:    ebp: 0008   esp: c36f3f08
> ds: 0018   es: 0018   ss: 0018
> Process initlog (pid: 532, stackpage=c36f3000)
> Stack: c36f2000  0002  000c 000e 
> c013eec3 0002 
>0008 c36f3f48 c36f3f4c c36f2000 0002 0002 
>  c36f2000 
>  c013f133 0002  0002 
> cbd41140 c36f3fb8 
> Call Trace: [] [] [] [] 
> Code: 8b 45 00 85 c0 7c 59 e8 6b 1f ff ff 89 c6 bb 20 00 00 00 85 
> 
> >>EIP; c013ed99<=
> Trace; c013eec3 
> Trace; c013f133 
> Trace; c01203ed 
> Trace; c010a637 
> Code;  c013ed99 
>  <_EIP>:
> Code;  c013ed99<=
>0:   8b 45 00  mov0x0(%ebp),%eax   <=
> Code;  c013ed9c 
>3:   85 c0 test   %eax,%eax
> Code;  c013ed9e 
>5:   7c 59 jl 60 <_EIP+0x60> 
> c013edf9 
> Code;  c013eda0 
>7:   e8 6b 1f ff ffcall   1f77 
> <_EIP+0x1f77> c0130d10 
> Code;  c013eda5 
>c:   89 c6 mov%eax,%esi
> Code;  c013eda7 
>e:   bb 20 00 00 00mov$0x20,%ebx
> Code;  c013edac 
>   13:   85 00 test   %eax,(%eax)
> 
> Unable to handle kernel NULL pointer dereference at virtual 
> address 0040
> c013ed99
> *pde = 
> Oops: 
> CPU:0
> EIP:0010:[]
> EFLAGS: 00210246
> eax: 0040   ebx:    ecx: 0044   edx: 0006
> esi:    edi:    ebp: 0040   esp: c09a7f08
> ds: 0018   es: 001

RE: [bug] vfsmount->count accounting broken again?

[Dunlap, Randy]

Andries wrote Monday 4-dec-2000 about a umount patch
for this:

Now that there was some discussion about umount,
I released a version of mount/umount that perhaps
has a slightly better behaviour. Since the change
was largish (and is untested), don't put it blindly
into your distribution.
Another change was one intended to make things behave
a bit better for Japanese (with variable width characters).
Since I changed the patch a bit, it is quite possible
I broke things both for Japanese and English.

Andries - [EMAIL PROTECTED]

ftp://ftp.win.tue.nl/pub/linux-local/utils/util-linux/
-

I haven't tried it yet.

~Randy
___
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
---

> -Original Message-
> From: Tigran Aivazian [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, December 05, 2000 1:07 PM
> To: [EMAIL PROTECTED]
> Subject: [bug] vfsmount->count accounting broken again?
> 
> 
> Hi,
> 
> Imagine two ext2 filesystems
> 
> /dev/hda1 mounted rw on /boot
> /dev/hda3 mounted rw on /usr/src
> 
> now mount /dev/hda3 also on /boot
> 
> mount -t ext2 /dev/hda3 /boot
> 
> this succeeds, which is expected. Now umount it.
> 
> umount /boot
> 
> this also succeeds, which is expected. Now do df(1) and notice that
> /etc/mtab is corrupted and no longer shows the old /boot 
> filesystem even
> though we know (from /proc/mounts) that it is mounted. This 
> is a bug but a
> userspace one (should mail Andries later, probably 
> util-linux). Now, the
> interesting bit, i.e. the kernel bug:
> 
> umount /boot
> 
> this fails with EBUSY. So, I think the reference count has gone wrong
> somewhere -- I will put debugging code in do_umount() and see, but
> everyone is welcome to fix it before I do so...
> 
> Regards,
> Tigran
> 
> -

-
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: [bug] vfsmount->count accounting broken again?

[Dunlap, Randy]

> > Andries wrote Monday 4-dec-2000 about a umount patch
> > for this:
> 
> Randy, presumably you mean the userspace side, yes? I.e. not 
> the kernel
> bug I reported. I should have put a subject [two bugs] 
> instead of [bug].

Right.  Sorry I wasn't more clear about that.

~Randy

-
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: test12-pre6

[Dunlap, Randy]

> From: Linus Torvalds [mailto:[EMAIL PROTECTED]]
> 
...
> Now, this is with a bog-standard PIIX irq router, so we 
> definitely know
> that we have the pirq table parsing right. I even have unofficial
> confirmation from intel engineers on this.
> 
> But I see something obviously wrong there: you have busmaster 
> disabled.
> 
> Looking into the UHCI controller code, I notice that neither 
> UHCI driver actually does the (required)
> 
>   pci_set_master(dev);
> 
> Please add that to just after a successful 
> "pci_enable_device(dev)", and I
> just bet your USB will start working.
> 
> Johannes, Georg, the above is a fairly embarrassing bug, and 
> is likely to
> explain a _lot_ of USB failures (the OHCI driver does do this, btw).
> 
>   Linus

Gawd, I'm embarrassed even if they aren't.
You probably just wiped out a significant portion of the
USB bug list.

Thanks,
~Randy

-
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/

[Fwd: 2.4.0-test12-pre7]

[Randy Dunlap]

> From: Russell King [mailto:[EMAIL PROTECTED]]
> 
> Linus Torvalds writes:
> > - me: UHCI drivers really need to enable bus mastering.
> 
> But it'll already be turned on if pci_assign_unassigned_resources() is
> called.  This calls pdev_enable_device for every single device, which
> turns on the bus master bit in the PCI command register.
> 
> Is it intentional that pci_assign_unassigned_resources should:
> 1. enable all devices?
> 2. enable bus master on all devices?

Russell beat me to this question (must have something to do
with that .uk location).

I think that Linus's patch is correct and that
pci/setup_res.c::pdev_enable_device() shouldn't be doing this:

/* ??? Always turn on bus mastering.  If the device doesn't support
   it, the bit will go into the bucket. */
cmd |= PCI_COMMAND_MASTER;

First, the ??? makes it iffy.

Second, if the device doesn't support it, OK, but if the device
does support bus mastering and the device has been programmed
from a previous kernel/driver bootup (i.e., the device isn't reset
by a soft boot), then the device still knows some memory addresses
to DMA into, but it shouldn't be using those.  This is addressed
in a Word .doc file at www.pcisig.com/developers/docs/ :
"Warm Boot on PCI Machines".  The short summary is that soft reset
should disable bus mastering and not re-enable it.
This doc says that device drivers (or expansion ROM code) are
responsible for setting the bus master bit.

Third, removing this will help find drivers that don't do
  pci_set_master() when they should (like UHCI HCDs).  :(

~Randy
-- 
___
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
---


> From: Russell King [mailto:[EMAIL PROTECTED]]
> 
> Linus Torvalds writes:
> > - me: UHCI drivers really need to enable bus mastering.
> 
> But it'll already be turned on if pci_assign_unassigned_resources() is
> called.  This calls pdev_enable_device for every single device, which
> turns on the bus master bit in the PCI command register.
> 
> Is it intentional that pci_assign_unassigned_resources should:
> 1. enable all devices?
> 2. enable bus master on all devices?

Russell beat me to this question (must have something to do
with that .uk location).

I think that Linus's patch is correct and that
pci/setup_res.c::pdev_enable_device() shouldn't be doing this:

RE: recommended build environment

[Dunlap, Randy]

> From: Borislav Deianov [mailto:[EMAIL PROTECTED]]
> 
> In article <[EMAIL PROTECTED]> you wrote:
> >> > oWe tell vendors to build RPMv3 , glibc 2.1.x
> >> Curious HOW do you tell vendors??
> 
> > When they ask. More usefully Dan Quinlann and most vendors 
> put together a
> > recommended set of things to build with and use. It warns 
> about library
> > pitfalls, kernel changes and what packaging is supported. 
> It is far from
> > perfect and nothing like the LSB goals but its a start and 
> following it does
> > give you applications that with a bit of care run on everything.
> 
> Is that recommendation available online anywhere? What about RedHat's?
> If not, who do I email for a copy in each case?

The Quinlan et al recommendations are at
http://www.freestandards.org/ldps/ .

~Randy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: 2.4.0-test9-pre8, usb, unresolved symbols

[Dunlap, Randy]

Hi,

> From: f5ibh [mailto:[EMAIL PROTECTED]]
> 
> Hi!
> 
> While doing modprobe hid or modprobe usb-uhci, I get the 
> following unresolved
> symbols. Config is P200MMX, 64Mb SDRAM.

All of the missing symbols are in usb.o (usbcore.o module or
usbdrv.o in-kernel).  Is usbcore.o loaded or do you have
/etc/modules.conf setup to load it automatically?
Did you run depmod after 'make modules_install' ?

~Randy


> -- Versions installed: (if some fields are empty or look
> -- unusual then possibly you have very old versions)
> Linux debian-f5ibh 2.4.0-test9 #1 lun oct 2 14:44:11 CEST 
> 2000 i586 unknown
> Kernel modules 2.3.16
> Gnu C  2.95.2
> Binutils   2.9.5.0.41
> Linux C Library2.1.3
> Dynamic linker ldd: version 1.9.11
> Linux C++ Library  2.9.
> Procps 2.0.6
> Mount  2.10o
> Net-tools  2.05
> Console-tools  0.2.3
> Sh-utils   2.0
> Modules Loaded nls_iso8859-1 ide-cd cdrom isofs 
> parport_pc lp parport input autofs4 rtc serial isa-pnp unix
> 
> 
> 
> /lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: unresolved 
> symbol usb_deregister
> /lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: unresolved 
> symbol usb_set_idle
> /lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: unresolved 
> symbol __usb_get_extra_descriptor
> /lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: unresolved 
> symbol usb_register
> /lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: unresolved 
> symbol usb_set_protocol
> /lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: unresolved 
> symbol usb_string
> /lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: unresolved 
> symbol usb_get_class_descriptor
> /lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: unresolved 
> symbol usb_submit_urb
> /lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: unresolved 
> symbol usb_unlink_urb
> /lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: insmod 
> /lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o failed
> /lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: insmod hid failed
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> unresolved symbol usb_claim_bandwidth
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> unresolved symbol usb_release_bandwidth
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> unresolved symbol usb_check_bandwidth
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> unresolved symbol usb_alloc_bus
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> unresolved symbol usb_free_dev
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> unresolved symbol usb_inc_dev_use
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> unresolved symbol usb_deregister_bus
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> unresolved symbol usb_disconnect
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> unresolved symbol usb_connect
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> unresolved symbol usb_new_device
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> unresolved symbol usb_root_hub_string
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> unresolved symbol usb_alloc_dev
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> unresolved symbol usb_register_bus
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> unresolved symbol usb_free_bus
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> insmod /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o failed
> i/lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> insmod usb-uhci failed
> 
> -
> Regards
>   Jean-Luc

-
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: [PATCH] 2.2.18pre13: USB tweak for VAIO

[Dunlap, Randy]

How about not running your kernel at KERN_DEBUG level <7> ?
That would also eliminate this message.

~Randy

> -Original Message-
> From: Chip Salzenberg [mailto:[EMAIL PROTECTED]]
> Sent: Monday, October 02, 2000 2:12 PM
> To: Alan Cox
> Cc: Linux Kernel
> Subject: [PATCH] 2.2.18pre13: USB tweak for VAIO
> 
> 
> Patch: usbdock-1
> From: Geoff Harrison <[EMAIL PROTECTED]>
> 
> Allow short report frames via USB ... apparently they are normal for
> some Sony VAIOs when docked.
> 
> Index: linux/drivers/usb/hid.c
> diff -u linux/drivers/usb/hid.c:1.2 linux/drivers/usb/hid.c:1.2.2.1
> --- linux/drivers/usb/hid.c:1.2   Wed Sep 27 23:44:24 2000
> +++ linux/drivers/usb/hid.c   Thu Sep 28 11:51:32 2000
> @@ -1096,10 +1096,12 @@
>   return;
>   }
>  
> +#if 0
>   if (len < ((report->size - 1) >> 3) + 1) {
>   dbg("report %d is too short, (%d < %d)", 
> report->id, len, ((report->size - 1) >> 3) + 1);
>   return;
>   }
> +#endif
>  
>   for (n = 0; n < report->maxfield; n++)
>   hid_input_field(device, report->field[n], data);
> 
> -- 
> Chip Salzenberg  - a.k.a. -  
> <[EMAIL PROTECTED]>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: 2.4.0-test9-pre8, usb, unresolved symbols

[Dunlap, Randy]

Well, let's see.
linux/drivers/Makefile did change for test9-pre8.
That's one possibility.

Are you building USB core support in-kernel or as a
module?  (Maybe provide your .config file, or at least
the CONFIG_USB_xxx portion of it.)

Thanks,
~Randy


> From: f5ibh [mailto:[EMAIL PROTECTED]]
> 
> Randy wrote :
> > All of the missing symbols are in usb.o (usbcore.o module or
> > usbdrv.o in-kernel).  Is usbcore.o loaded or do you have
> > /etc/modules.conf setup to load it automatically?
> > Did you run depmod after 'make modules_install' ?
> 
> I've a Debian 2.2 system. With Debian, I use the "make-kpkg" 
> command to build
> the kernel in a Debian package. I ALWAYS use the same process 
> to compile
> kernel. Then, I install the new kernel with dpkg as any .deb 
> package ... I think
> I've built 100's of them now. depmod reports the same error :
> 
> depmod: *** Unresolved symbols in 
> /lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o
> depmod: *** Unresolved symbols in 
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o
> 
> I use the following in my modules.conf to load automatically 
> all the usb related
> stuff when starting 'gpm'. This works with the previous 
> test9-prex patches.
> 
> # USB mouse
> #--
> alias char-major-13 mousedev
> 
> post-install input modprobe -k hid
> post-install hid modprobe -k usb-uhci
> 
> ---

-
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: Proposal: Linux Kernel Patch Management System

[Dunlap, Randy]

> From: Theodore Y. Ts'o [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 13, 2000 7:32 AM
> 
> 
> How can we simplify things?  Part of the design of this new 
> proposal was
> to change as little as possible from the existing setup 
> (people's habits
> are hard to change), and yet to make my life and Linus's life much
> easier.  In the long run, it will make your life easier, to the extent
> that having an up-to-date bug list is easier, and because then I won't
> have to continually pester people about whether certain bugs have been
> fixed.  
> 
> Right now, having to paw through diff files to see when Linus has
> applied a particular patch (add grumble about lack of a source code
> control system) is really not fun.  Alan did it for a while, 
> and burned
> out, and I can tell you, I can't really blame him --- it's a lot of
> work.
> 
> Is it really that hard to annotate the patch with a bit of 
> information,
> and then send it off to a different mailing address instead of sending
> it directly to Linus and the l-k list?  
> 
> What can we do to make things simpler on developers?  Certainly this
> isn't going to work unless the developers use it, and that 
> means we need
> to keep things as easy as possible for the patch submitters.

Ted,

I appreciate Alan and you doing the kernel Status/TODO lists,
but I think that you ought to simplify it for yourself at
least (not that this would help Linus) by having maintainers
do it instead of you do it.

I'm willing to do it for USB, but I'm not willing to duplicate
your work if you continue to do it.  I don't expect you to
know/understand all of the filesystem or I/O subsystem or
VM or process issues and be able to track them without asking
lots of questions.  (Maybe you do, but I don't think that should
be a requirement of the status-bot.)

You should roll up reports from maintainers for a summary
kernel status report.

~Randy

PS:  This is probably too good to be true and would require
the assistance of lots of maintainers, but that's how it
should be done IMO.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: 2.4.0-test9: USB-Mouse half recognized

[Dunlap, Randy]

> From: Jan Niehusmann [mailto:[EMAIL PROTECTED]]
> 
> On Wed, Oct 04, 2000 at 04:15:54PM +0200, Meino Christian 
> Cramer wrote:
> >  I tried it both: uhci and usb.uhci:
> >  Same behaviour for both: Boot into runlevel 2. do a cat on
> >  /dev/input/mouse0 and move the mouse: OK, some glibberish bytes 
> >  found their way onto the console.
> 
> Oh well you're right... but I have a workaround (that made me 
> think the
> other driver works):
> 
> Start X. The mouse doesn't work. Switch to a console. 
> rmmod uhci; modprobe uhci
> Switch back to X. Now the mouse works. (until you switch away 
> from X, again)
> 
> 
> Jan

Well, it's nice if you have a workaround, but I (or we [royal])
really messed some USB stuff up in 2.4.0-test9 -- affects
lots of USB devices.
We're working on fixes.  Sorry about that.

~Randy

-
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: usb-audio, does it work at all?

[Dunlap, Randy]

Eric,

usb audio will be made to work again, but it's
currently broken 2 ways:  usb-uhci was just broken
in 2.4.0-test9.

Besides that, the audio driver
has been broken since 2.4.0-test7 or so.
It worked in 2.4.0-test5 but not in -test7.
I've been searching for the problem but haven't
found it yet.

~Randy

> -Original Message-
> From: Erik Mouw [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, October 05, 2000 11:40 AM
> To: [EMAIL PROTECTED]
> Subject: usb-audio, does it work at all?
> 
> 
> Hi all,
> 
> I just got a "Target USB speaker converter", which is basically a
> USB sound card. I opened the case and found a Philips UDA1321PS
> chip, which seems to be the same chip as used in the Philips
> DSS 330 USB speakers, according to the linux-usb pages[1].
> However, if I connect it to my laptop, nothing happens. Yes, the
> USB layer sees a new device, but nothing happens, even if I have
> the audio module loaded. Does it work with the Philips USB
> speakers, or is the driver just broken?
> 
> I'm using linux-2.4.0-test9 on an Asus P6300 notebook (PII 233, 80MB
> memory, Intel BX/ZX chipset) running SuSE 6.4. USB controller is
> an Intel 82371AB PIIX4 USB and both UHCI drivers fail to do
> something useful with the sound card.
> 
> 
> Erik
> 
> [1] http://linux-usb.sourceforge.net/usb.ids , look for Philips
> 
> -- 
> J.A.K. (Erik) Mouw, Information and Communication Theory 
> Group, Department
> of Electrical Engineering, Faculty of Information Technology 
> and Systems,
> Delft University of Technology, PO BOX 5031,  2600 GA Delft, 
> The Netherlands
> Phone: +31-15-2783635  Fax: +31-15-2781843  Email: 
> [EMAIL PROTECTED]
> WWW: http://www-ict.its.tudelft.nl/~erik/
> -
> 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/
> 

-
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: usb-audio, does it work at all?

[Dunlap, Randy]

> From: Erik Mouw [mailto:[EMAIL PROTECTED]]
> 
> On Thu, Oct 05, 2000 at 11:46:13AM -0700, Dunlap, Randy wrote:
> > usb audio will be made to work again, but it's
> > currently broken 2 ways:  usb-uhci was just broken
> > in 2.4.0-test9.
> 
> Oh? It works perfectly well with my Wacom Graphire.

So you are one of the lucky ones.  :)

> > Besides that, the audio driver
> > has been broken since 2.4.0-test7 or so.
> > It worked in 2.4.0-test5 but not in -test7.
> > I've been searching for the problem but haven't
> > found it yet.
> 
> Hmm, yes, that's a difficult one. I just made a diff between test5 and
> test9, and there are no obvious changes in the audio driver. Except
> the changes in copy_from_user_ret() and mem_map_reserve().

Could have been some changes outside of audio.c that kill it.
In any case, it just hangs the system in 2.4.0-test7 or later.

~Randy

-
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/

TODO UPDATE: RE: Updated 2.4 TODO List

[Dunlap, Randy]

Ted,

Here are some corrections to the published list.
I'm working on new additions now.

~Randy


> 6. In Progress
> 
>  * USB: hotplug (PNP) and module autoloader support
+ Move to "1. Should Be Fixed".  We want more testing of it, of course.

> 9. To Do
> 
>  * USB: OHCI root-hub-timer does not restart on resume {CRITICAL}
>(Paul Mackerras)
+ Move to "1. Should be Fixed".

>  * USB: add bandwidth allocation support to usb-uhci HCD
+ Move to "1. Should be Fixed".

>  * USB: Fix differences in UHCI and OHCI HCD behaviors/semantics:
>   + Only uhci.c does EARLY_COMPLETE (drop EARLY_COMPLETE ?)
+ Move to "Fixed" (actually deleted).

>  * USB: usb-ohci needs to null urb->dev to avoid various
>reboots/hangs/oopses {CRITICAL} (David Brownell;
>[EMAIL PROTECTED])
+ Move to "1. Should be Fixed".

> 10. To Do But Non Showstopper
> 
>  * USB: speed up device enumeration (hub driver has large 
> delays in it)
+ Move to "1. Should be Fixed".


Other updates from linux-usb-devel people?

Thanks,
~Randy

-
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: Updated 2.4 TODO List

[Dunlap, Randy]

Hi Ted,

Here's an updated USB 2.4 TODO list.

The new entries (changes) are marked with '+'.

~Randy


USB Status/Problems in 2.4.0-test9
2000-October-09



1.  Should [already] Be Fixed

. hid joystick handling (patch from Vojtech) (2.4.0.9.4)
. cpia_usb module doesn't handle "no bandwidth" returns (OOPS) (2.4.0.9.4)
. microtek memory handling (patch from Oliver Neukum) (2.4.0.9.4)
+ hotplug (PNP) and module autoloader support
+ OHCI root-hub-timer does not restart on resume {CRITICAL}
  (Paul Mackerras) (2.4.0-test9)
+ add bandwidth allocation support to usb-uhci HCD (2.4.0-test9)
+ usb-ohci needs to null urb->dev to avoid various reboots/hangs/oopses
{CRITICAL}
  (David Brownell; [EMAIL PROTECTED]) (2.4.0-test9)
+ speed up device enumeration (hub driver has large delays in it)

2.  Capable of corrupting your FS

. Problems with USB storage drives (ORB, maybe Zip) during APM sleep/suspend
. OOPS in usb-storage from the error-recovery handler. {CRITICAL}
  (Matthew Dharm; [EMAIL PROTECTED])

3.  Security

4.  Boot-Time Failures

5.  Compile-Time Failures

6.  In Progress

7.  Obvious Projects for People (well if you have the hardware..)

8.  Fix Exists But Isn't Merged

9.  To Do

. race conditions on devices in use and being unplugged
. SANE backend can't communicate to its scanner (sometimes, some scanners)
. OHCI memory corruption problem
. Fix differences in UHCI and OHCI HCD behaviors/semantics:
.   OHCI doesn't do URB timeouts
.   OHCI always does BULK_QUEUE (as David.B said, Bulk queueing is a
UHCI notion; not needed in OHCI; fix not needed)
. Misc locking problems
  - fix MOD_INC races in plusb.c and uss720.c
  - fix concurrent read/write and other SMP like bugs in:
acm.c
printer.c
scanner.c
uss720.c
serial/ftdi_sio.c
serial/omninet.c
. fix USB_QUEUE_BULK problem in uhci.c (oopsen after a while) {CRITICAL}
. system hang with USB audio driver {CRITICAL}
  (David Woodhouse; [EMAIL PROTECTED])
. usb-ohci needs to null urb->dev to avoid various reboots/hangs/oopses
{CRITICAL}
  (David Brownell; [EMAIL PROTECTED])
. printer Device ID string should not be static; printers can update it
. Fix serial/omninet.c to not require a small mtu setting in order to
  get a PPP link to work properly (as reported by Bernhard Reiter)
. pegasus: avoid warning spewage on disconnect
. OHCI optional zero length packet (USB_DISABLE_SPD at send)
. consistent short packet handling OHCI/UHCI (including 0-length packets)
(Roman)
. consistent URB next pointer handling by OHCI/UHCI (Roman)
. booting with USB compiled into kernel causes a lot of syslog entries
  as the root hubs are probed by all drivers (this is especially
  obnoxious as the usb-serial drivers start up)
. pegasus driver locks up on slow OHCI machine; sometimes cannot be
  rmmod-ed (Cyrille Chepelov; [EMAIL PROTECTED])
+ fix setting urb->dev in printer, acm, bluetooth, all serial drivers
  (Greg KH) {CRITICAL}
+ fix usbdevfs memset() on IOC_WRITE (Dan Streetman) {CRITICAL}
+ fix setting urb->dev in plusb, wacom, mdc800) (Greg KH) {CRITICAL}
+ fix usb-uhci setting urb->dev = NULL at correct places only {CRITICAL}
+ fix hub driver allocation/usage of portstr & tempstr (D. Brownell)
  (causes oops and memory corruptoin) {CRITICAL}
+ USB mouse stopped working (2.4.0-test9) ([EMAIL PROTECTED])
+ oops on boot with 2.4.0-test9, usb-uhci, pegasus (in process_transfer)
  ([EMAIL PROTECTED])
+ pegasus driver version 0.4.12: update to work with HCD changes; fix module
  use counting & dev refcounting; fix to work with dhcpd (Petko) {CRITICAL}

10. To Do But Non-Showstopper

. acm (modem) driver is slow compared to Windows drivers for same modems
  (maybe an HCD problem, not acm driver, or acm should use bulk queueing)
. add devfs support to drivers that don't have it
. add DocBook info to main USB driver interfaces (usb.c)
. Printer stalls at random places when printing large graphics.
  When printing big pictures (10..50 meg) the printer stalls halfway. The
  point where it stalls is random but the fact that it stalls is
  reproducable. Printing the same pictures using the parallel interface
  is ok. Printing text is ok anyway.
  Frank van Maarseveen: [EMAIL PROTECTED]
. Misc locking problems: fix concurrent read/write and other SMP-like
  bugs in:
bluetooth.c
mdc800.c
rio800.c
serial/keyspan.c
serial/whiteheat.c
. fix usb_unlink_urb() bug when called with an urb that was used on a
  device that is no longer registered in the USB system.
. control pipe locking (mutual exclusion)
. use pci_alloc_consistent throughout (mostly OHCI; some people want
  UHCI also)

11. To Check

12. Probably Post 2.4

. spread out interrupt frames for devices that use the same
  interrupt period (interval)
. add USB 2.0 EHCI HCD

~Fixed

. usb-uhci not use set PCI Latenc

RE: [PATCH] drivers/usb/Config.in

[Dunlap, Randy]

Not needed.  This is a misunderstanding.  Maybe that needs
some work (in Help maybe), but not this patch.

You have the first USB option ("Support for USB") set to Y,
right?

Then if you select USB HID support, that builds the hid driver,
which handles mice, keyboards, joysticks, gamepads, speaker
buttons, any-old-kind-of buttons, toaster buttons, etc.

OTOH, if you want just some basic USB mouse & keyboard support,
you don't have to use the hid driver, you can use the HIDBP
(HID Boot Protocol) drivers instead.  However, these drivers
(hid and hidbp) are mutually exclusive and you shouldn't
try to select both of them.

~Randy


> This patch fixes a minor config error for 
> drivers/usb/Config.in. When you
> select USB Human Interface Device (HID) support I assume you should be
> able to select a USB mouse and/or USB keyboard. With the 
> current Config.in
> you can't.
> 
> --- Config.in.origTue Oct 10 00:10:06 2000
> +++ Config.in Tue Oct 10 00:10:27 2000
> @@ -80,7 +80,7 @@
>comment '  Input core support is needed for USB HID'
> else
>dep_tristate '  USB Human Interface Device (HID) 
> support' CONFIG_USB_HID $CONFIG_USB $CONFIG_INPUT
> -  if [ "$CONFIG_USB_HID" != "y" ]; then
> +  if [ "$CONFIG_USB_HID" = "y" ]; then
>   dep_tristate '  USB HIDBP Keyboard support' 
> CONFIG_USB_KBD $CONFIG_USB $CONFIG_INPUT
>   dep_tristate '  USB HIDBP Mouse support' 
> CONFIG_USB_MOUSE $CONFIG_USB $CONFIG_INPUT
>fi

-
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: [PATCH] drivers/usb/Config.in

[Dunlap, Randy]

> > Then if you select USB HID support, that builds the hid driver,
> > which handles mice, keyboards, joysticks, gamepads, speaker
> > buttons, any-old-kind-of buttons, toaster buttons, etc.
> > 
> > OTOH, if you want just some basic USB mouse & keyboard support,
> > you don't have to use the hid driver, you can use the HIDBP
> > (HID Boot Protocol) drivers instead.  However, these drivers
> > (hid and hidbp) are mutually exclusive and you shouldn't
> > try to select both of them.
> 
> Would you clarify the difference between the INPUT section drivers
> and the HID and HIDBP drivers?

First, as Harold Oga mentioned, the USB hid driver is a
full-blown driver for all sorts of HID devices.
The HIDBP mouse and keyboard drivers support the
"HID Boot Protocol," which is minimal support for
mice and keyboards during system boot, or it might
be enough support for systems that use basic devices
(no keyboard hot ["internet"] keys, etc.) and/or
for embedded systems.  For example, I can & do often
get by with using HIDBP mouse/keyboard when using X
(but mostly for testing).

Now on to the /dev/input drivers (best answer is to
consult with [EMAIL PROTECTED] or see if there is
anything is linux/Documentation/input*):
These are "logical" device drivers.  They don't
handle any physical devices, but they provide
consistent logical connections between physical device
drivers [whether it's USB, PS/2, AT interface, serial, ...]
for input devices (keyboards, mice, joysticks,
gamepads, & other generic input "events") and
app-level software that uses them.

~Randy

-
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: [PATCH] drivers/usb/Config.in

[Randy Dunlap]

James Simmons wrote:
> > Not needed.  This is a misunderstanding.  Maybe that needs
> > some work (in Help maybe), but not this patch.
> 
> Yes please. It can be very misleading.
> 
> > Then if you select USB HID support, that builds the hid driver,
> > which handles mice, keyboards, joysticks, gamepads, speaker
> > buttons, any-old-kind-of buttons, toaster buttons, etc.
> 
> I didn't realize USB had this level of functionality.
> 
> > OTOH, if you want just some basic USB mouse & keyboard support,
> > you don't have to use the hid driver, you can use the HIDBP
> > (HID Boot Protocol) drivers instead.  However, these drivers
> > (hid and hidbp) are mutually exclusive and you shouldn't
> > try to select both of them.
> 
> Okay I see.

James,

Please let me know if the attached patch helps to clarify this
any (or enough).  I tried adding a line between HID and HIDBP
support options, but that didn't work out, so it's not there.

Thanks,
~Randy

--- linux/Documentation/Configure.help.org  Mon Oct  9 16:47:42 2000
+++ linux/Documentation/Configure.help  Tue Oct 10 17:22:12 2000
@@ -9982,12 +9982,13 @@
   The module will be called usb-ohci.o. If you want to compile it
   as a module, say M here and read Documentation/modules.txt.
 
-USB Human Interface Device (HID) support
+USB Human Interface Device (full HID) support
 CONFIG_USB_HID
-  Say Y here if you want to connect keyboards, mice, joysticks,
-  graphic tablets, or any other HID based devices to your
-  computer via USB. More information is available:
-  Documentation/usb/input.txt.
+  Say Y here if you want full HID support to connect keyboards,
+  mice, joysticks, graphic tablets, or any other HID based devices
+  to your computer via USB. You can't use this driver and the
+  HIDBP (Boot Protocol) keyboard and mouse drivers at the same time.
+  More information is available: Documentation/usb/input.txt.
 
   If unsure, say Y.
 
@@ -9996,11 +9997,11 @@
   The module will be called hid.o. If you want to compile it as a
   module, say M here and read Documentation/modules.txt.
 
-USB HIDBP Keyboard support
+USB HIDBP Keyboard (basic) support
 CONFIG_USB_KBD
   Say Y here if you don't want to use the generic HID driver for your
   USB keyboard and prefer to use the keyboard in its limited Boot
-  Protocol mode. This driver is much smaller than the HID one.
+  Protocol mode instead. This driver is much smaller than the HID one.
 
   This code is also available as a module ( = code which can be
   inserted in and removed from the running kernel whenever you want).
@@ -10009,11 +10010,11 @@
 
   If unsure, say N.
 
-USB HIDBP Mouse support
+USB HIDBP Mouse (basic) support
 CONFIG_USB_MOUSE
   Say Y here if you don't want to use the generic HID driver for your
   USB mouse and prefer to use the mouse in its limited Boot Protocol
-  mode. This driver is much smaller than the HID one.
+  mode instead. This driver is much smaller than the HID one.
 
   This code is also available as a module ( = code which can be
   inserted in and removed from the running kernel whenever you want).
--- linux/drivers/usb/Config.in.org Mon Sep 18 15:23:30 2000
+++ linux/drivers/usb/Config.in Tue Oct 10 17:41:44 2000
@@ -79,10 +79,10 @@
if [ "$CONFIG_INPUT" = "n" ]; then
   comment '  Input core support is needed for USB HID'
else
-  dep_tristate '  USB Human Interface Device (HID) support' CONFIG_USB_HID 
$CONFIG_USB $CONFIG_INPUT
+  dep_tristate '  USB Human Interface Device (full HID) support' CONFIG_USB_HID 
+$CONFIG_USB $CONFIG_INPUT
   if [ "$CONFIG_USB_HID" != "y" ]; then
- dep_tristate '  USB HIDBP Keyboard support' CONFIG_USB_KBD $CONFIG_USB 
$CONFIG_INPUT
- dep_tristate '  USB HIDBP Mouse support' CONFIG_USB_MOUSE $CONFIG_USB 
$CONFIG_INPUT
+ dep_tristate '  USB HIDBP Keyboard (basic) support' CONFIG_USB_KBD 
+$CONFIG_USB $CONFIG_INPUT
+ dep_tristate '  USB HIDBP Mouse (basic) support' CONFIG_USB_MOUSE 
+$CONFIG_USB $CONFIG_INPUT
   fi
   dep_tristate '  Wacom Intuos/Graphire tablet support' CONFIG_USB_WACOM 
$CONFIG_USB $CONFIG_INPUT
fi

RE: SMP irq sharing problem in 2.2.17

[Dunlap, Randy]

> > I had a similar problem with the USB driver assigned to 
> IRQ19 but not receiving any interrupts.
> > 
> > Perhaps someone more knowledgable can explain why linux 
> fails under MPS1.4.
> 
> Linux is fine with MPS1.4. There are two possible causes I see
> 
> 1.Some clown built a USB controller with only 4 bits of 
> the IRQ line
>   writable/checkable. We've seen sound chips with that 'feature'
> 
> 2.The MPS 1.4 tables in the BIOS are wrong. Remarkably 
> common problem


Do we have any [non-kernel] software that will read/analyze MPS
tables?

Thanks,
~Randy

-
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: [PATCH] usb audio.

[Dunlap, Randy]

> > > Only problem is that the sound has a lot of hickups and I 
> get these
> > > messages in my syslog: 
> > 
> > I didn't see that. I think I _do_ have CONFIG_USB_BANDWIDTH 
> enabled. What 
> > else do you have connected and what else were you using at 
> the time? Does 
> > the kernel whinge?
> 
> Just recompiled the USB modules with CONFIG_USB_BANDWIDTH enabled, but
> that doesn't solve the problem. The audio thingy is the only device
> connected, I don't have an USB hub, otherwise I would have used my
> Wacom Graphire and the audio converter at the same time (my laptop has
> only one USB port). FWIW, the audio converter is using a Philips UDA
> 1321 chip.

CONFIG_USB_BANDWIDTH just controls whether usb_submit_urb()
fails or passes based on current bandwidth usage.

You shouldn't see the  messages about bandwidth alloc
increased|reduced unless you are running at console loglevel
7 or higher (KERN_DEBUG) (could be via Alt-SysRq-7).
I'll see about removing them anyway.

I don't know about the sound hickups you are hearing.  Tom Sailer
suggested just a day or two ago something about changing the
latency for the USB controller by using setpci.
BTW, lspci -vv would give much more useful info than just
using lspci.  E.g., it would show the current latency
value being used.

~Randy

-
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: [PATCH] usb audio.

[Dunlap, Randy]

> > I don't know about the sound hickups you are hearing.  Tom Sailer
> > suggested just a day or two ago something about changing the
> > latency for the USB controller by using setpci.
> 
> I tried:
> 
>   setpci -s 00:07.2 latency_timer=20
>   setpci -s 00:07.2 latency_timer=40
>   setpci -s 00:07.2 latency_timer=80
> 
> but without effect. However, the USB device doesn't have a latency
> timer, so that probably explains.

Eric,

How about trying latency_timer=10, which will apparently
show up as being 0 (since 10 is smaller than its
implemented granularity).
This made the audio tolerable for Kees Cook according to
his response to Tom Sailer.

~Randy

-
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: Updated 2.4 TODO List - more on PCI resources...]

[Dunlap, Randy]

I'm not familiar with yenta controllers/devices,
and I'm not trying to throw you a tasty red herring,
but...

yenta_config_init() does
config_writeb(socket, PCI_CACHE_LINE_SIZE, 32);

Is this writing to the CardBus bridge or to the device's
CacheLineSize register?

If the latter, and given that PCI_CACHE_LINE_SIZE is in
units of 4-byte "words", is 32 [= 128 bytes] a good value
to use?  If so, why?

Or is it OK because it is setting a PCI bridge device's
cache line size?

>From TI's PCI1451 GJG CardBus controller spec:
4.8 Cache Line Size Register
The cache line size register is programmed by host software to indicate
the system cache line size.

Thanks,
~Randy

-
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: Updated 2.4 TODO List - more on PCI resources...]

[Dunlap, Randy]

> On Fri, Oct 13, 2000 at 02:22:32PM -0700, Dunlap, Randy wrote:
> > I'm not familiar with yenta controllers/devices,
> > and I'm not trying to throw you a tasty red herring,
> > but...
> > 
> > yenta_config_init() does
> > config_writeb(socket, PCI_CACHE_LINE_SIZE, 32);
> > 
> > Is this writing to the CardBus bridge or to the device's
> > CacheLineSize register?
> 
> It is writing to the bridge.  I think it should probably actually be
> L1_CACHE_BYTES/4.  I am not sure about the impact of an incorrect
> setting.  Maybe Linus knows.
> 
> -- Dave

I agree.  I would expect it to be 8 instead of 32.
Actually I just checked on a new Thinkpad T20 with a TI
PCI 1450 CardBus controller *on a different OS*
and it is 8.

~Randy

-
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: Updated 2.4 TODO List - more on PCI resources...]

[Dunlap, Randy]

> > I agree.  I would expect it to be 8 instead of 32.
> > Actually I just checked on a new Thinkpad T20 with a TI
> > PCI 1450 CardBus controller *on a different OS*
> > and it is 8.
> 
> I'll fix it to be 8.
> 
> Thanks,
> 
>   Linus

Well, preferably to what David said:
  L1_CACHE_BYTES / 4

Thanks,
~Randy

-
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/

test10-pre[23] warnings/BOOT-OOPS

[Randy Dunlap]

Hi,
I'm seeing these gcc warnings in test10-pre[23].
They could have occurred before that also -- I don't know.

I'm using gcc 2.7.2.3.  Is that a problem?

Also, I can't boot test10-pre[23].  I get an oops in swapper.
It's not logged so I can't see where it's actually happening.
I'll try to hook up a serial connection so I can get the info.

Would any of the problems below keep me from being able
to boot?


sched.c:88: warning: alignment of `runqueue_lock' is greater than
maximum object file alignment
sched.c:89: warning: alignment of `tasklist_lock' is greater than
maximum object file alignment
sched.c:103: warning: alignment of `aligned_data' is greater than
maximum object file alignment


tcp_ipv4.c:78: warning: alignment of `tcp_hashinfo' is greater than
maximum object file alignment


socket.c:187: warning: alignment of `sockets_in_use' is greater than
maximum object file alignment


softirq.c:47: warning: section attribute ignored for uninitialized
variable `softirq_vec'


arch/i386/kernel/
irq.c:67: warning: alignment of `irq_desc' is greater than maximum
object file alignment


init_task.c:23: warning: alignment of `init_task_union' is greater than
maximum object file alignment
init_task.c:33: warning: alignment of `init_tss' is greater than maximum
object file alignment


misc.c:197: warning: type mismatch with previous external decl
../../../../lib/inflate.c:311: warning: previous external decl of
`memset'
misc.c:197: warning: type mismatch with previous implicit declaration
../../../../lib/inflate.c:311: warning: previous implicit declaration of
`memset'
misc.c:197: warning: `memset' was previously implicitly declared to
return `int'


Thanks,
~Randy
-
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: Updated 2.4 TODO List

[Dunlap, Randy]

Pavel,

While you should report drivers or other kernel functions
that don't work, I don't think that just saying that
something is broken is sufficient.

~Randy

> Hi!
> 
> > 7. Obvious Projects For People (well if you have the hardware..)
> > 
> >  * Make syncppp use new ppp code
> >  * Fix SPX socket code
> 
> USB: plusb is b0rken.
>   Pavel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test9-pre8, usb, unresolved symbols

[Randy Dunlap]

Keith Owens wrote:
> 
> Objects that export symbols must be explicitly listed before the
> calculation of OX_OBJS.  usb.o is not explicitly listed as an object,
> it is implicitly included via the link of usbcore.
> 
> Index: 0-test10-pre3.1/drivers/usb/Makefile
> --- 0-test10-pre3.1/drivers/usb/Makefile Mon, 02 Oct 2000 15:28:44 +1100
> kaos (linux-2.4/n/b/19_Makefile 1.1.1.10 644)
> +++ 0-test10-pre3.1(w)/drivers/usb/Makefile Wed, 18 Oct 2000 13:17:59
> +1100 kaos (linux-2.4/n/b/19_Makefile 1.1.1.10 644)
> @@ -38,7 +38,7 @@ obj-  :=
> 
>  # Each configuration option enables a list of files.
> 
> -obj-$(CONFIG_USB)  += usbcore.o
> +obj-$(CONFIG_USB)  += usbcore.o usb.o
>  obj-$(CONFIG_USB_UHCI) += usb-uhci.o
>  obj-$(CONFIG_USB_UHCI_ALT) += uhci.o
>  obj-$(CONFIG_USB_OHCI) += usb-ohci.o

Keith-

We still need your help.  Using this usb/Makefile change gives
me errors on all (?) exported symbols when I try to build all
of USB into the kernel.  Example (one of many):

usbcore.o: In function `usb_set_address':
usbcore.o(.text+0x1b90): multiple definition of `usb_set_address'
usb.o(.text+0x1b90): first defined here


I guess that we could go ahead and merge usb-core.c into usb.c
if there's no good/simple solution to this.

Thanks,
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: 2.4.0-test9-pre8, usb, unresolved symbols

[Dunlap, Randy]

Greg,

That's fine with me, especially if it fixes this problem.

Go for it.

~Randy
___
|Randy Dunlap |
|randy.dunlap_at_intel.com503-696-2055|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
---

> -Original Message-
> From: Greg KH [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 18, 2000 1:54 PM
> To: Randy Dunlap
> Cc: Keith Owens; Claude LeFrancois (LMC); [EMAIL PROTECTED]
> Subject: Re: 2.4.0-test9-pre8, usb, unresolved symbols
> 
> 
> On Wed, Oct 18, 2000 at 01:47:40PM -0700, Randy Dunlap wrote:
> > I guess that we could go ahead and merge usb-core.c into usb.c
> > if there's no good/simple solution to this.
> 
> I wanted to do that anyway, so I'd recommend it.  Especially 
> if it fixes
> this problem.
> 
> Want a patch to do it?
> 
> thanks,
> 
> greg k-h
> 
> -- 
> greg@(kroah|wirex).com
> http://immunix.org/~greg
> 
-
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: cpia_usb cameras

[Dunlap, Randy]

> From: John M. Flinchbaugh [mailto:[EMAIL PROTECTED]]
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> did something change in the past 2 months to break cpia_usb cameras?

2.4.0-test9 (and maybe test8) had some significant changes that broke
several USB drivers, including cpia USB.

Should be fixed in 2.4.0-test10-pre3.
If not, please report it.
Also, if there's a problem, please test with both of the
uhci host controller drivers.

~Randy

> the last i remember using my webcam was toward the end of august.
> it hasn't been working with test9 or test8 i don't think.
> 
> the device shows up just fine, the /proc/cpia/video0 is functional,
> and i can set the camera parameters.
> 
> none of my video apps (xawtv, v4lctl, motion 2.0) work.  motion 2.0
> blocks at what seems to be the ioctl(...VIDIOCMCAPTURE...).
> the record light on the camera even comes on just fine.
> i never do get a capture.
> 
> i'm using the uhci.o driver, as usb-uhci.o loads, but trying to
> capture sends the machine into a recurring oops of some sort.
> scrolling way too quickly to read.  power button is only recourse.
> 
> this is of course linux 2.4.0-test9.  i've been staying pretty
> up-to-date.
> 
> thanks.
> - -- 
> }John Flinchbaugh{__
> | [EMAIL PROTECTED] http://www.hjsoft.com/~glynis/ |


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: 2.2.18pre17: usb-uhci verbosity

[Dunlap, Randy]

> From: David Rees [mailto:[EMAIL PROTECTED]]
> 
> On Fri, Oct 20, 2000 at 08:59:00PM -0400, Martin Hicks wrote:
> > 
> > I moved from 2.2.18pre15 to 2.2.18pre17 and now I get the following
> > usb-uhci stuff being spewed to my terminal:
> > 
> > Oct 20 20:54:19 plato kernel: usb-uhci.c: interrupt, status 
> 3, frame# 704
> > Oct 20 20:54:20 plato kernel: usb-uhci.c: interrupt, status 
> 3, frame# 1088
> > Oct 20 20:54:20 plato kernel: usb-uhci.c: interrupt, status 
> 3, frame# 1472
> > Oct 20 20:54:20 plato kernel: usb-uhci.c: interrupt, status 
> 3, frame# 1856
> > 
> > Everything seems to be functioning correctly though.  Reason?
> 
> Not sure, but I saw the same thing on my machine.  No one had 
> any ideas,
> but I moved to the altertative uhci driver and things work 
> great and no more messages.

That's fine, of course, but the subject line is pretty
much correct:  usb-uhci is too verbose on this conditional.
It can safely be deleted/commented out.

~Randy

-
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: oops program

[Dunlap, Randy]

Should be at
ftp://ftp.ora.com/pub/examples/linux/drivers/
according to the book.

~Randy

> -Original Message-
> From: jim M. [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 24, 2000 8:27 PM
> To: [EMAIL PROTECTED]
> Subject: oops program
> 
> 
> Hi,
> 
> Does anyone know what is the exact download path to oops 
> program as brought 
> up in "linux device drivers" by Rubini published by O'reilly?.
> 
> J

-
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/