On Sun, Oct 20, 2002 at 10:03:12PM +0200, Oliver Neukum wrote:
Hi,
this removes an error case that cannot happen.
This is against 2.5BK. Please apply.
Applied, thanks.
greg k-h
---
This sf.net emial is sponsored by: Influence the future
On Sun, Oct 20, 2002 at 06:23:20PM -0700, David Brownell wrote:
This is a slightly cleaned up version of that earlier patch:
- Makes both copies of the clear_halt() logic know that
usb_pipein() returns boolean (zero/not) not integer (0/1).
This resolves a problem folk have had with
On Mon, Oct 21, 2002 at 06:57:08PM -0700, John Tyner wrote:
The following patch removes the old framebuf_size and framebuf_read_start
values from the cam structure and simplifes the read function. It also
moves the needs dummy read check into the read_frame function. cp and dd
should both
On Mon, Oct 21, 2002 at 09:52:49PM -0700, John Tyner wrote:
The following patch removes the old framebuf_size and framebuf_read_start
values from the cam structure and simplifes the read function. It also
moves the needs dummy read check into the read_frame function. cp and dd
should both
Note: there were some usbfs failures on system startup,
and hotplug was not run, but no oops. The oops occurred
on system shutdown. It was followed by another one which
didn't get as far as the system logs.
Ciao, Duncan.
drivers/usb/core/hcd-pci.c: remove: 00:0b.0, state 3
Hi
In the function parse_ethernet_functional_descriptor
if (ether_dev-wNumberMCFilters (1 15)) {
ether_dev-properties |= PERFECT_FILTERING;
dbg(Perfect filtering support);
} else {
dbg(Imperfect filtering support - need sw
Title: Dear Friend
Dear Friend,
We would like to introduce ourselves
Creativeskulls, We are a new media concern having a setup of 11 high end
workstations. We are looking for business partners/clients who are interested in
offloading their work. Our rate is only 5 US$ for an hour of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 22 Oct 2002 17:08, Vaibhav Madan wrote:
Hi
In the function parse_ethernet_functional_descriptor
if (ether_dev-wNumberMCFilters (1 15)) {
ether_dev-properties |= PERFECT_FILTERING;
dbg(Perfect
At 09:52 PM 10/21/2002 -0700, John Tyner wrote:
This is in addition to the previous patch. It should allow any programs
that read entire frames to receive a new frame with each successive read.
Programs that read less than the entire frame will read until they reach
the end of the frame. They
At 03:55 AM 10/22/2002 -0700, Joe Burks wrote:
from your patch file:
+ down_interruptible(cam-busy_lock);
[...]
+ if (*ppos = VICAM_MAX_FRAME_SIZE) {
+ *ppos = 0;
+ return 0;
}
I'm betting that semaphore needs to be upped before returning :)
Now if only I had upped it in my patch... Ignore
Hi,
here we go:
vicam_open()
- if you do down_interruptible, you must check for being interrupted
- cam-raw_image = kmalloc(VICAM_MAX_READ_SIZE, GFP_KERNEL);
This allocates 129KB. If possible switch to vmalloc
- initialize_camera(cam);
check the return value. This can fail.
-
You no longer check buf against NULL, can a misbehaved program cause a
problematic seg fault in the kernel?
I put the onus of checking buf != NULL and count != 0 on copy_to_user.
I'm betting that semaphore needs to be upped before returning :)
Yes, it does. I'll leave that to you.
On Tue, Oct 22, 2002 at 08:47:04AM +0200, Duncan Sands wrote:
Note: there were some usbfs failures on system startup,
Mind sending what those failures were? I haven't heard of this before.
and hotplug was not run, but no oops. The oops occurred
on system shutdown. It was followed by
James McMechan [EMAIL PROTECTED] writes:
I sent out a version for uml-2.4.18-52um on August 21 to the
uml-devel list Alas while I have finally gotten a version ported to
2.5 and it enumerates the devices it does not create the usbfs files
correctly. The orignal version by Johan Verrept was
On Sun, Oct 20, 2002 at 12:29:39PM +0200, Henning Meier-Geinitz wrote:
Hi,
On Fri, Oct 18, 2002 at 04:05:45PM -0700, Greg KH wrote:
Anyway, I think I've handled everything that has been sent to me, with
the exception of Oliver's change configuration patch, and my previous
device
Hi,
On Tue, Oct 22, 2002 at 09:18:08AM -0700, Greg KH wrote:
No one answered my question last time which was:
Can the scanner driver be deleted in 2.5, as everything now
works properly using libusb from SANE?
Oh, I did, but it looks like I only sent the answer to linux-usb-devel.
Hi,
this is the same fix as for microtek. It's against 2.5.
Please apply.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
This is a bug fixing patch against 2.5.44, it contains
John Tyner's simplified vicam_read
Bug fixes per Oliver Neukum
Other assorted bug fixes
--- linux-2.5.44/drivers/usb/media/vicam.c Mon Oct 21 14:09:13 2002
+++ linux-2.5.44-vicam/drivers/usb/media/vicam.cTue Oct 22 11:18:15
On Tue, Oct 22, 2002 at 09:04:06PM +0200, Oliver Neukum wrote:
Hi,
this is the same fix as for microtek. It's against 2.5.
Please apply.
Applied, thanks,
greg k-h
---
This sf.net emial is sponsored by: Influence the future
of Java(TM)
Hi,
IMHO usb_stor_clear_halt and usb_stor_reset_common should take dev_semaphore.
What do you think? If so, I'll make a patch.
Regards
Oliver
---
This sf.net emial is sponsored by: Influence the future
of Java(TM)
On Tuesday 22 October 2002 18:16, Greg KH wrote:
On Tue, Oct 22, 2002 at 08:47:04AM +0200, Duncan Sands wrote:
Note: there were some usbfs failures on system startup,
Mind sending what those failures were? I haven't heard of this before.
drivers/usb/core/usb.c: registered new driver usbfs
On Tue, Oct 22, 2002 at 10:07:31PM +0200, Duncan Sands wrote:
On Tuesday 22 October 2002 18:16, Greg KH wrote:
On Tue, Oct 22, 2002 at 08:47:04AM +0200, Duncan Sands wrote:
Note: there were some usbfs failures on system startup,
Mind sending what those failures were? I haven't heard of
Am Dienstag, 22. Oktober 2002 21:49 schrieb Joe Burks:
This is a bug fixing patch against 2.5.44, it contains
John Tyner's simplified vicam_read
Bug fixes per Oliver Neukum
Other assorted bug fixes
Very well.
There's an issue still. You put a parser into kernel space. I think
it's correct,
Mahlzeit
I could now run successfully 20 readers with 2.4.20-pre11 measuring the
timing of a command sequence consisting of three commands for the smart
card. I made a plot of this, where the x-axis is the overall runtime (20
minutes) and the y-axis is the runtime of a command sequence. Every
On Tuesday 22 October 2002 22:15, Greg KH wrote:
...
usbfs: usb_submit_urb returned -90
Ah, if you get rid of the usbmodules binary on your system those will go
away :)
They did!
(I don't like usbmodules, but it's necessary for loading drivers for
devices plugged in at boot time if the
On Tue, Oct 22, 2002 at 12:49:06PM -0700, Joe Burks wrote:
static int
-vicam_write_proc(struct file *file, const char *buffer,
+vicam_write_proc(struct file *file, const char *buf,
unsigned long count, void *data)
Thanks to Oliver, I just noticed this.
Ick. Please
At 02:30 PM 10/22/2002 -0700, Greg KH wrote:
On Tue, Oct 22, 2002 at 12:49:06PM -0700, Joe Burks wrote:
static int
-vicam_write_proc(struct file *file, const char *buffer,
+vicam_write_proc(struct file *file, const char *buf,
unsigned long count, void *data)
Thanks to
On Tue, Oct 22, 2002 at 03:23:31PM -0700, Joe Burks wrote:
At 02:30 PM 10/22/2002 -0700, Greg KH wrote:
On Tue, Oct 22, 2002 at 12:49:06PM -0700, Joe Burks wrote:
static int
-vicam_write_proc(struct file *file, const char *buffer,
+vicam_write_proc(struct file *file, const char *buf,
Am Mittwoch, 23. Oktober 2002 00:34 schrieb David Brownell:
IMHO usb_stor_clear_halt and usb_stor_reset_common should take
dev_semaphore.
What's the race?
usb_stor_clear_halt uses a synchronous control message.
It will not be unlinked upon disconnect. Disconnect must not
return until the
At 03:27 PM 10/22/2002 -0700, Greg KH wrote:
Do user programs actually try to write to these proc files? If no, then
yes, tradition should be broken here.
thanks,
greg k-h
Because of the very limited scope of V4L controls, it has been used to
allow users to adjust camera settings that
On Tue, Oct 22, 2002 at 03:46:34PM -0700, Joe Burks wrote:
Because of the very limited scope of V4L controls, it has been used to
allow users to adjust camera settings that could not otherwise be
manipulated. Applications don't write to the proc files, but users
do. I'll shoot a message
Hi,
The attached patch removes vicam.c's proc interface and replaces it with a
driverfs file called shutter_speed through which the shutter speed can be
changed for each device.
This patch also removes the usb_put_dev call from the disconnect routine
as well as adding the up call for the busy
The EHCI driver was never adjusting the full speed maximum packet size up
(when enumerating through a transaction translating hub). This broke the
enumeration of some devices (maxpacket != 8) pretty early.
This patch updates EHCI to fix the bug, and does minor cleanup to usbcore
logic that
Am Mittwoch, 23. Oktober 2002 01:25 schrieb David Brownell:
IMHO usb_stor_clear_halt and usb_stor_reset_common should take
dev_semaphore.
What's the race?
usb_stor_clear_halt uses a synchronous control message.
It will not be unlinked upon disconnect. Disconnect must not
return until
On Tue, 22 Oct 2002, Pete Zaitcev wrote:
| Out of the blue an ALi engineer contacted me and offered a fix for
| lockups in IBM i-series laptops (RH Bugzilla #50225). I would
| really appreciate if someone ran it on their _regular_ ohci
| to ensure that it does not break non-ALi silicon. Both 2.4
Am Mittwoch, 23. Oktober 2002 05:55 schrieb John Tyner:
Hi,
The attached patch removes vicam.c's proc interface and replaces it with a
driverfs file called shutter_speed through which the shutter speed can be
changed for each device.
1. Who can write these settings? How do you control that?
On Tue, Oct 22, 2002 at 08:55:49PM -0700, John Tyner wrote:
This patch also removes the usb_put_dev call from the disconnect routine
as well as adding the up call for the busy mutex that I forgot in my
previous patch to the read function.
Why take out the usb_put_dev() call?
thanks,
greg
At 08:55 PM 10/22/2002 -0700, John Tyner wrote:
I saw some discussion as to whether we want to break V4L standard by
removing the proc interface, but the driverfs interface provides what was
required of the proc interface: shutter_speed to be settable for each
attached camera individually by a
1. Who can write these settings? How do you control that?
I set permissions to rw-r--r--. Don't these files get owned by root when
created?
2. The module count handling is wrong.
These methods don't sleep. Either they are racy or safe with or without
manipulating the usage count.
I
Why take out the usb_put_dev() call?
It seemed to be keeping the driver from being inserted, remove, and
re-inserted. I didn't figure out why... just that this was the cause.
John
---
This sf.net emial is sponsored by: Influence the future
Please don't remove the proc interface. This is a V4L issue. It's in
there because this is a V4L driver.
I saw that you were going to raise the issue on that list. I said the patch
can wait. Regardless, though, I think that the driverfs is where this kind
of thing is supposed to be going.
At
On Tue, Oct 22, 2002 at 11:04:54PM -0700, John Tyner wrote:
Please don't remove the proc interface. This is a V4L issue. It's in
there because this is a V4L driver.
I saw that you were going to raise the issue on that list. I said the patch
can wait. Regardless, though, I think that the
Hi ! I am JD, and I have been searching the web for a driver(core)
it seems I have lost it!! My pc tells me the Driver(core)winerr=2
is not found..Do you have any idea what this means??
Yup , you guessed it!! I'm one of those dumb blondes!!Need HELP!!
Hope you can help.I'm lost!!
On Sun, Oct 20, 2002 at 08:24:36PM +0200, Andries Brouwer wrote:
The oops is a dereference of fff0 in base/bus.c:driver_attach().
I have seen several such oopses lately, various places in the kernel.
The cause here is a NULL pointer that is turned into fff0 by
container_of() and then
44 matches
Mail list logo
