Sorry for the nitpicking, bust since 2.4 is now "stable"...
-- Pete
diff -ur -X dontdiff linux-2.4.0-ac9/drivers/sound/cs46xx.c
linux-2.4.0-ac9-p3/drivers/sound/cs46xx.c
--- linux-2.4.0-ac9/drivers/sound/cs46xx.c Sun Jan 14 15:27:58 2001
+++ linux-2.4.0-ac9-p3/drivers/sound/cs46xx.c Wed
A minor problem here - module_init(irda_proto_init) got bracketed
by #ifdef MODULE and became ineffective if compiled without modules.
-- Pete
diff -ur -X dontdiff linux-2.4.1-pre11/net/irda/af_irda.c
linux-2.4.1-pre11-p3/net/irda/af_irda.c
--- linux-2.4.1-pre11/net/irda/af_irda.cSat
From: Gregory Maxwell ([EMAIL PROTECTED])
Date: Sun Jan 28 2001 - 14:42:04 EST
On Sun, Jan 28, 2001 at 01:29:52PM +, James Sutherland wrote:
There is nothing silly with the decision, davem is simply a modern day
internet hero.
No. If it were something essential, perhaps,
From: Simon Cahuk ([EMAIL PROTECTED])
Date: Tue Jan 30 2001 - 14:22:26 EST
I have a ymfpci sound chip on my motherboard. I'm using ymfpci module.
Under Q3A I get this:
sound inilializations:
Sorry but your soundcard can't do this
Probably an mmap-ed sound problem or some ioctl is
How about this (with documentation fixes by David-B):
diff -ur -X dontdiff linux-2.4.4/Documentation/DMA-mapping.txt
linux-2.4.4-niph/Documentation/DMA-mapping.txt
--- linux-2.4.4/Documentation/DMA-mapping.txt Thu Apr 19 08:38:48 2001
+++ linux-2.4.4-niph/Documentation/DMA-mapping.txt
As for the language CML2 is written in, surely C would work just as well as
Python if the config-ruleset file is in a known format. GCC is required
for the kernel to build, I don't see why anything else should be required
simply to configure it.
Menuconfig is fairly popular, and
[about Aunt Tullie]
Because, for example, a kernel compile can be a part of the standard
install now, and you will end up with a kernel built specifically for
your machine that doesn't print 50 initialization failed messages on boot.
[...]
And you can also now run a kernel built for your
May 23 02:46:24 localhost kernel: Process kudzu (pid: 219,
stackpage=c7845000)
May 23 02:46:24 localhost kernel: Stack: c12607e0 0400 0400
c73aa000 c122a060 c122a05c c122a058 c88fbb20
May 23 02:46:24 localhost kernel:03f1 03f1 c014ab80
c73aa3f1 c7845f9c
I am sorry to be a poor maintainer, people were sending me patches
to enable PM support for a long time. I took most of this from
Paul Stewart, fixed a buglet, and factored common parts into
a function.
-- Pete
* PM support for suspend/resume (without pm_register, proper PCI API);
* Killed some
From: Jeff Garzik [EMAIL PROTECTED]
Looks ok, only a small nit: an include and 'pmdev' are left over from
the older PM implementation, and can be removed.
Oops, here's a better one.
-- Pete
-
PM support for
From: Adam J. Richter [EMAIL PROTECTED]
Date: Sun, 22 Apr 2001 12:53:48 -0700
To: [EMAIL PROTECTED]
Subject: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
[...]
I believe this infringinges the copyrights of the authors
of the code used in these drivers who released
From: Oleg Drokin [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Date: Sat, 26 May 2001 14:37:24 +0400
EIP; c01a3162 call_policy+162/1f0 =
Trace; c01a42fc usb_disconnect+fc/130
Trace; c01a5f9c hub_disconnect+1c/80
Trace; c01a42e0
Aattached is a (large, but self contained) patch for Cobalt Networks suport
for x86 systems (RaQ3, RaQ4, Qube3, RaQXTR). Please let me know if there
is anything that would prevent this from general inclusion in the next
release.
Looks interesting. Seemingly literate use of spinlocks.
From: Tim Hockin [EMAIL PROTECTED]
Date: Thu, 31 May 2001 23:57:48 -0700 (PDT)
i2c framework is not used, I wonder why. Someone thought that
it was too heavy perhaps? If so, I disagree.
i2c is only in our stuff because the i2c core is not in the standard kernel
yet. As soon as it is,
But, each time a user cats this proc file, the user is banging the
hardware. What happens when a malicious user forks off 100 processes to
continually cat this file? :)
Nothing good, probably. Same story as /proc/apm, which only
hits BIOS instead (and it's debateable what is better).
I told device to go to sleep, it reported (over serial console that I
looked at with minicom), that it turned off internal devices
(including USB client), reported it is going to sleep, and turned
serial and itself off.
What does it mean I told device to go to sleep?
What device?
Is it a coincidence that E1 is officially declared obsolete today?
Sun never allows us to use the latest and greatest hardware.
--Pete
Date: Wed, 27 Sep 2000 17:28:49 +1100
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
From: Anton Blanchard [EMAIL PROTECTED]
Patches for Sun
Hello:
I was investigating an oops and the trace looked like this:
EIP; c01c54a9 lvm_do_remove_proc_entry_of_vg+9/c0 =
Trace; c01c3654 lvm_do_vg_rename+84/250
Trace; c01c0f0f lvm_chr_ioctl+30f/6d0
Trace; c015e7e2 ext2_getblk+72/e0
Trace; c01155a6 do_page_fault+166/440
Trace; c01272a9
Date: Fri, 09 Mar 2001 10:29:22 -0800
From: David Brownell [EMAIL PROTECTED]
extern void *
pci_pool_dma_to_cpu (struct pci_pool *pool, dma_addr_t handle);
Do lots of drivers need the reverse mapping? It wasn't on my todo list
yet.
Some hardware (like OHCI) talks to drivers
Is my fix to khubd going anywhere? Randy, David?
I have an actual, reproducible bug that I need to close.
Here's my message to linux-usb-devel with explanations:
http://marc.theaimsgroup.com/?l=linux-usb-develm=98411157628404w=2
-- Pete
diff -ur -X ../dontdiff
From: Andree Leidenfrost ([EMAIL PROTECTED])
I am experiencing problems with a USB mouse: The machine boots, X
starts, I log on, everything works as expected. When I restart X or just
change to an alpha terminal and back to x the mouse does not work any
more. [...]
Hardware is an ASUS
From: Andree Leidenfrost [EMAIL PROTECTED]
To: Pete Zaitcev [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Date: 18 Mar 2001 22:50:32 +1100
I am experiencing problems with a USB mouse: The machine boots, X
starts, I log on, everything works as expected. When I restart X or just
change
Date: Wed, 6 Dec 2000 13:12:13 -0500 (EST)
From: Pavel Roskin [EMAIL PROTECTED]
cc: Jaroslav Kysela [EMAIL PROTECTED], Pete Zaitcev [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]
The native YMF PCI driver from Linux-2.4.0-test12-pre5 works on my card:
I did not have
Date: Wed, 6 Dec 2000 15:00:38 -0500 (EST)
From: Pavel Roskin [EMAIL PROTECTED]
To: Pete Zaitcev [EMAIL PROTECTED]
Subject: Re: YMF PCI - thanks, glitches, patches (fwd)
Date: Wed, 6 Dec 2000 13:12:13 -0500 (EST)
From: Pavel Roskin [EMAIL PROTECTED]
cc: Jaroslav Kysela [EMAIL
Date: Fri, 8 Dec 2000 11:41:07 -0500 (EST)
From: Pavel Roskin [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED], Pete Zaitcev [EMAIL PROTECTED],
Jaroslav Kysela [EMAIL PROTECTED]
--- ./drivers/sound/Config.in Thu Dec 7 10:59:06 2000
+++ ./drivers/sound/Config.in Fri
Hi, Linus:
The attached patch fixes the following problems with ymfpci in 2.4 tree:
1. Enumeration was wrong, this bit people with several soundcards
(Abhijit Menon-Sen).
2. Must use semaphore to guard open/close.
3. Old ymfpci locks up if compiled with CONFIG_SMP due to
recursive calls
Jeff's descriprion is very informative, but his emphasis
is somewhat different from what I find difficult with patches.
First, for the life of me I was unable to remeber which
argument goes first (DaveM was mad every time). Second, I kept
forgetting to keep the base tree a diff against that
Are we going to use Miquel's patch? I cannot build fresh 2.2.x
on plain RH6.2 without it. The 2.2.19-pre6 comes out without it.
Or is "install new bash" the official answer? Alan?
-- Pete
--- linux-2.2.19-pre3/scripts/kwhichSun Dec 10 16:49:45 2000
+++ linux-2.2.19-pre3-p3/scripts/kwhich
Date:Wed, 03 Jan 2001 22:08:33 -0800
From: Pete Zaitcev [EMAIL PROTECTED]
Are we going to use Miquel's patch? I cannot build fresh 2.2.x on
plain RH6.2 without it. The 2.2.19-pre6 comes out without it. Or
is "install new bash" the official answer? Ala
o Fix kwhich versus old bash (Pete Zaitcev)
A small clarification may be in order here.
First, this patch comes from Miquel Smoorenburg, not from me.
Second, DaveM pointed out that it fixes a non-problem.
I stepped on a bug with an obscure kernel, I think it
was 2.2.18-pre3, which called
Hi,
In the recent 2.2.x I discovered that saa7xxx driver expects norm
to be an int, while struct video_channel defines it as __u16.
This bombs if video_channel has something dirty next to it
on the stack.
Only one file is touched by the patch: drivers/char/buz.c, but
some more code is related.
While trying to compile the 2.4.4 kernel on a SPARC-20, I encounter the
following error.
make[1]: Entering directory `/usr/src/linux-2.4.4/mm'
make all_targets
make[2]: Entering directory `/usr/src/linux-2.4.4/mm'
gcc -D__KERNEL__ -I/usr/src/linux-2.4.4/include -Wall -Wstrict-prototypes
One of our customers has a Fujitsu laptop, poor thing...
It shares IRQ10 between Eepro, additional IDE for CD-ROM (CMD646),
and USB controllers. I talked this over with DaveM briefly,
and if I understood him right, something like the attached
patch may be in order. Anyone cares to comment?
Thank
Hello:
Here are updates from ALSA. The interrupt acknowledge has a
potential bug report for it in RH bugzilla. Power-up fix I include
just because, Alan bounced it to me from sound-hackers;
Also Jeff Garzik asked for it. I wanted to include it with
full PM support, but perhaps not.
-- Pete
---
Due to a pilot error, my ymfpci update would not compile
(forgot to submit .h change). Here is the missing part:
--- linux-2.4.4/drivers/sound/ymfpci.h Fri Jan 26 23:31:16 2001
+++ linux-2.4.4-niph/drivers/sound/ymfpci.h Fri May 4 11:07:17 2001
@@ -135,6 +135,8 @@
#define PCIR_LEGCTRL
David,
Russel King complained that you might be calling pci_consistent_free
from an interrupt, which is unsafe on ARM. Why don't you remove this
part from pci_pool_free():
+ else if (!is_page_busy (pool-blocks_per_page, page-bitmap))
+ pool_free_page (pool, page);
In that
Hi:
I found that every time I run a 2.4 on my laptop, APM locks up
the machine. Apparently, legacy YMF code enabled decoding of
10 bits of I/O address. A call to APM BIOS touched that and
somehow the system locked up.
If Pavel Roskin, Daisuke Nagano or someone else do not mind,
I want this in
switching it back on, a problem occurs with reenabling the ports on
that USB hub. The kernel output follows.
Comments anyone?
Next time, post your /proc/version.
There were similar things recently (missing urb-dev
reinitialization in usb_hub_reset).
-- Pete
-
To unsubscribe from this list:
May 9 10:05:11 localhost kernel: EIP:0010:[call_policy+427/608]
I saw it before, but was unable to track it down.
What is your kernel version?
-- Pete
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
From: David S. Miller [EMAIL PROTECTED]
Date: Tue, 8 May 2001 17:52:45 -0700 (PDT)
Ummm... What Alan's saying is:
1) Whatever driver is trying to shut down from IRQ context
is broken must be fixed. pci_pool is fine.
2) The Documentation/ files which suggest that such device
This [code morphing and binary tranlation]
was set off to provide compensation for the biggest hurdle
of VLIW design - insane code size and partially huge memmory
bus bandwidth designs due to this. (Why do you think the itanim
sucks on integer performance?)
First, Merced does not suck on
Then again JavaOS was an abortion on top of Slowaris. [...]
This is a false statemenet, Rob. It was an abortion, all right,
but not related to Solaris in any way at all.
JavaOS existed in two flavours minimum, which had very little
in common. The historically first of them (Luna), was a
There is no such thing as a user mode interrupt service routine.
There never was one, and there will never be one on any machine
that fetches instructions from memory for execution. [...]
If memory does not deceive me, SunLab Spring processed interrupts
in user space. I do not remember for
I'd like to find out if anyone has thought about how Linux will handle
some of the new network technologies people are starting to push.
Specifically I'm talking about System Area Networks, that is, things
like Infiniband, as well as TCP/IP offload.
Infiniband is doing relatively well, as
Well you have device drivers like the symbios scsi driver for instance that
tries to determine if it's seen a card before. It does this by looking at the
bus,dev etc numbers...
Can it be done by comparing struct pci_dev pointers for equal?
-- Pete
-
To unsubscribe from this list: send the
Lately, I have been having problems reading from from my HP Colorado IDE
tape drive. I can use mt to get the status of the drive and to forward the
drive to a different file. I can even use tar to write to the tape.
But whenever I try to read the tar files that I have written to tape, I
When I do anything (print to it, query its ink levels with escputil,
etc.) with my Epson 870 while it's hooked to my computer via USB, the
whole machine locks hard. [...]
Has anyone else has seen this problem? I posted to the gimp-print and
linux-usb lists, but there was nary a response.
I
This patch adds a missing semicolon that is noticed only if you define
IDETAPE_DEBUG_LOG_VERBOSE:
John Guthrie
[EMAIL PROTECTED]
It makes me curious, why do you need to define
IDETAPE_DEBUG_LOG_VERBOSE?
I fixed some stuff with files not restoring properly
with last block corrupt. Talking
In linux-kernel, you wrote:
Peter Zaitsev wrote:
That's why I thought this problem is related to raid1 swapping I'm
using.
Well there is the potential problem that RAID1 has that it can't avoid allocating
memory in some occasions, for the 2nd bufferhead. ATARAID raid0 has the same
Courtesy of Manish Singh, little bit extended
(I hope I did not break it too badly).
Supposedly it fixes bad skipping with xmms.
-- Pete
diff -ur -X dontdiff linux-2.4.1/drivers/sound/ymfpci.c
linux-2.4.1-p3/drivers/sound/ymfpci.c
--- linux-2.4.1/drivers/sound/ymfpci.c Fri Jan 26 23:31:16
Here is the deal:
we have a guy here with a webcam and the following scenario:
1. ov511 disconnects, everything dies/releases/closes fine,
2. webcam soft starts polling open/sleep/open/sleep/...
3. ov511_probe works and reaches ov511_configure,
calls video_register_device().
4. Webcam
Hello, All:
I have a situation where a Dell laptop would loose its
keyboard after resume (thanks to Ben LaHaise for
diagnosing this probelm). BIOS enables touchpad
when resumed and if a user touches touchpad, "hardware"
delivers IRQ 12 and will not deliver IRQ 1 until we
process the mouse event.
Date: Sun, 1 Apr 2001 03:35:03 +0200 (CEST)
From: Ketil Froyn [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
While running kernel 2.4.2-ac28, I switched on spinlock debugging and
verbose BUG() reporting (I always use sysrq). Anyway, while running this I
got an oops after about 2 or 3
Hello:
Suppose for a moment, that I have an in-kernel daemon, listening
on a TCP socket, and that the said daemon is interested to
know when connection becomes established. To that end it
puts something into sk-state_change. However, when connection
is established, state_chenge is not called (in
usb-uhci.c: interrupt, status 3, frame# 1876
This is a known problem, here is the discussion that I initiated
on linux-usb-devel:
http://marc.theaimsgroup.com/?t=9860950851w=2r=1
The right fix is to comment that printout out.
In fact, that is what I commited for Red Hat 7.1 release.
On Fri, 9 Mar 2007 09:28:49 -0500, Dmitry Torokhov [EMAIL PROTECTED] wrote:
On 2/28/07, Pete Zaitcev [EMAIL PROTECTED] wrote:
Dmitry, please consider getting rid of the list of handles entirely.
The other major user is drivers/char/keyboard.c.
I agree that handlers should not access
On Tue, 13 Feb 2007 20:13:06 -0500, Chuck Ebbert [EMAIL PROTECTED] wrote:
OK I'll keep looking for the cause of the oops then:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228231
Feb 12 01:11:29 MyComputer kernel: ohci_hcd :00:02.1: auto-wakeup
Feb 12 01:11:30 MyComputer
On Sun, 18 Mar 2007 12:40:45 -0400, Jim Gettys [EMAIL PROTECTED] wrote:
Also more seriously, a somewhat hybrid approach is in order for mode
setting: simple mode setting isn't much code and is required for sane
behavior on crash (it is nice to get oopses onto a screen); but the full
blown
On Wed, 7 Mar 2007 17:23:05 -0500, Dmitry Torokhov [EMAIL PROTECTED] wrote:
It seems that if a process keeps a character device open then other
processes will also be able to get into filp-f_op-open(inode,filp)
in chrdev_open() even after a driver called cdev_del() as part of its
unwind
On Thu, 22 Mar 2007 17:56:13 -0400, Chuck Ebbert [EMAIL PROTECTED] wrote:
_Something_ is generating those overcurrent
warnings, and it sure looks like a hardware malfunction.
But it works with 2.6.20.
Generation 1 iPod Shuffle is notorious for high current draw.
You should be able
), value 1987
- warp here, by the difference of 3687 and 1987, plus
some small frac_dy value. Easily jumps half the screen.
Event: time 1174703243.356246, -- Report Sync
Signed-off-by: Pete Zaitcev [EMAIL PROTECTED]
--- linux-2.6/drivers/input
On Sun, 25 Mar 2007 01:34:02 -0400, Dmitry Torokhov [EMAIL PROTECTED] wrote:
+ * Without this, a touchpad may report an unchanged
position,
+ * then a sync. The input_event() eats the position report,
but
+ * lets the sync through. We
On Sun, 25 Mar 2007 23:19:38 -0400, Dmitry Torokhov [EMAIL PROTECTED] wrote:
I tried to reproduce warping on console but could not for some reason. Could
you
please try the patch below and tell me if it fixes the problem for you?
+++ work/drivers/input/mousedev.c
@@ -124,32 +124,33 @@
On Sun, 25 Mar 2007 11:27:33 +0400, Cyrill Gorcunov [EMAIL PROTECTED] wrote:
This patch adds checking of driver registration status
and if it fails release allocated resources.
+ if (status_queue) {
+ destroy_workqueue(status_queue);
+ status_queue = NULL;
+
On Mon, 26 Mar 2007 15:30:42 -0400, Dmitry Torokhov [EMAIL PROTECTED] wrote:
Regarding the synaptics driver and scroll problem. Yesterday I
scrolled twice through entire Remarque's Spark of Life off lib.ru
(once with 0.14.2 and once with latest git pull) and did not see any
scrollbar getting
On a certain keyboard, when BIOS sets NumLock LED on, it survives the takeover
by Linux and thus confuses users.
Eating of an increasibly scarce quirk bit is unfortunate. We do it for safety,
given the history of nervous input devices which crash if anything unusual
happens.
Signed-off-by: Pete
On Thu, 5 Apr 2007 16:54:17 -0400, Dmitry Torokhov [EMAIL PROTECTED] wrote:
On a certain keyboard, when BIOS sets NumLock LED on, it survives the
takeover
by Linux and thus confuses users.
Eating of an increasibly scarce quirk bit is unfortunate. We do it for
safety,
given the
Hi, Peter:
There's one thing I wanted to report, just in case... It does not affect
anything, but it's odd.
Every time I lift a finger from the pad, the driver sends an event with
odd values (X is 1 and Y is 5855):
Event: time 1174695694.561806, type 1 (Key), code 330 (Touch), value 0
Event:
On Fri, 13 Apr 2007 12:56:47 -0400, Jeremy C. Andrus [EMAIL PROTECTED]
wrote:
I recently ran into a couple of USB devices which insisted on using 1024
byte packets in bulk transfer mode (despite the hard limit of 512
established in the spec). I really wanted to use these devices, so I
On Sat, 14 Apr 2007 09:14:25 -0400 (EDT), Jeremy C. Andrus [EMAIL
PROTECTED] wrote:
On Fri, April 13, 2007 22:16, Pete Zaitcev wrote:
The transfer size in the URB is not limited by the maximum packet
size. The HC driver splits up the transfer as specified by URB into
the required number
On Tue, 20 Feb 2007 16:15:41 +, Russell King [EMAIL PROTECTED] wrote:
Never call __exit code from __init code - it causes errors such as:
Oh heh, just saw this now.
Signed-off-by: Russell King [EMAIL PROTECTED]
I ack this. Greg, please either apply Dobriyan's patch, or this one,
they are
On Tue, 20 Feb 2007 09:02:53 +0100 (CET), Jiri Kosina [EMAIL PROTECTED] wrote:
On Mon, 19 Feb 2007, Veronique Vincent wrote:
Hi again Marcel and Jiri,
I've set up the hid-core.c to DEBUG mode... and it literally got pretty
verbose...
thanks for the output. Is this really the full
On Mon, 19 Feb 2007 21:15:49 +0300, Cyrill Gorcunov [EMAIL PROTECTED] wrote:
+++ b/drivers/usb/misc/ftdi-elan.c
@@ -57,9 +57,9 @@ module_param(distrust_firmware, bool, 0);
MODULE_PARM_DESC(distrust_firmware, true to distrust firmware
power/overcurren
t setup);
extern struct
Here's a curious code I found in drivers/input/input.c (2.6.21-rc1):
void input_release_device(struct input_handle *handle)
{
if (handle-handler-start)
handle-handler-start(handle);
}
Is the above supposed to be this way, or you meant -stop here?
The commit comment
On Thu, 22 Feb 2007 11:43:38 +0100, Duncan Sands [EMAIL PROTECTED] wrote:
+ /* the module/device has probably been removed */
+ if (urb-status == -ESHUTDOWN)
+ return;
+
if (printk_ratelimit())
On Fri, 23 Feb 2007 10:06:14 -0500, Dmitry Torokhov [EMAIL PROTECTED] wrote:
On 2/23/07, Pete Zaitcev [EMAIL PROTECTED] wrote:
void input_release_device(struct input_handle *handle)
{
if (handle-handler-start)
handle-handler-start(handle);
It should
On Fri, 23 Feb 2007 11:10:05 +0300, Cyrill Gorcunov [EMAIL PROTECTED] wrote:
I may be wrong, but a lot of the kernel code have static pointers
initialized to NULL with explicit manner... More over I always thought
that _static_ is not mean _initialized to zero_. I think _static_ is
just the
On Sat, 24 Feb 2007 11:57:07 -0500, Dmitry Torokhov [EMAIL PROTECTED] wrote:
To tell you the truth, all I really want is to hold a static mutex
across a call to input_close_device(). Can I do that?
Are you trying to fix locking in mousedev?
Yes.
-- Pete
-
To unsubscribe from this list:
On Sat, 24 Feb 2007 10:41:15 +0300, Cyrill Gorcunov [EMAIL PROTECTED] wrote:
Thanks a lot for comments and Ack the patch please.
Cyrill, I forgot to mention a couple of points, sorry.
printk(KERN_INFO driver %s built at %s on %s\n,
ftdi_elan_driver.name,
-
On Tue, 27 Feb 2007 09:06:21 -0500, Eric Buddington [EMAIL PROTECTED] wrote:
sd 1:0:0:0: rejecting I/O to offline device
...
SoftDog: Initiating system reboot.
Now, the USB problem may well be a device or cabling issue, but I
don't think that this drive failure should trigger a reboot - I
/null /dev/input/mice; done
This way, it oopses on 2nd or 3rd disconnect reliably. With the patch,
I can disconnect the mouse 20 times.
Signed-off-by: Pete Zaitcev [EMAIL PROTECTED]
---
Discussion
One of the race scenarios is related to the list of handles. The cat
calls mousedev_close
On Wed, 7 Mar 2007 17:18:29 -0500 (EST), Alan Stern [EMAIL PROTECTED] wrote:
I've never heard of a process failing to show up in a SysRq-t listing. It
suggests something is wrong with the process management in the kernel you
were using. That leads me to think a non -mm kernel might give
On Tue, 27 Mar 2007 19:14:05 +0400, Cyrill Gorcunov [EMAIL PROTECTED] wrote:
--- a/drivers/usb/misc/ftdi-elan.c
@@ -2903,7 +2903,7 @@ static struct usb_driver ftdi_elan_driver = {
};
static int __init ftdi_elan_init(void)
{
-int result;
+int result = 0;
Why do you need
from the previous device tree to the current one.
From Pete Zaitcev
What does happen if a user suspends, unplugs a USB key, modifies its contents,
plugs it back, and resumes? In such a case, there would be no change between
the state of USB bus between the before-suspend state and after-resume
On Wed, 28 Mar 2007 20:00:32 +0400, Cyrill Gorcunov [EMAIL PROTECTED] wrote:
result = usb_register(ftdi_elan_driver);
-if (result)
+if (result) {
+ destroy_workqueue(status_queue);
+ destroy_workqueue(command_queue);
+
This is a patch for comments only, please do not apply (at least not as-is).
I haven't got the test results yet.
Dell people (Stuart and Charles) complained that on some USB keyboards,
if BIOS enables NumLock, it stays on even after Linux has started. Since
we always start with NumLock off, this
On Fri, 30 Mar 2007 14:14:20 -0400, Dmitry Torokhov [EMAIL PROTECTED] wrote:
I didn't like a) layering violation, and b) that they defeat filtering
unconditionally. Why have any filtering then?
Instead, I propose for USB HID driver to reset NumLock on probe. Like this:
---
On Sat, 31 Mar 2007 21:35:19 +0200 (CEST), Jiri Kosina [EMAIL PROTECTED]
wrote:
On Fri, 30 Mar 2007, Pete Zaitcev wrote:
I think I see an issue here. Imagine that you boot a system initially with
one keyboard connected (usb, ps/2, doesn't matter), and after some time
you connect second USB
On Sun, 1 Apr 2007 14:49:59 +0300, Pekka Enberg [EMAIL PROTECTED] wrote:
On 3/30/07, Pete Zaitcev [EMAIL PROTECTED] wrote:
Dell people (Stuart and Charles) complained that on some USB keyboards,
if BIOS enables NumLock, it stays on even after Linux has started. Since
we always start
On Sat, 31 Mar 2007 21:35:19 +0200 (CEST), Jiri Kosina [EMAIL PROTECTED]
wrote:
I think I see an issue here. Imagine that you boot a system initially with
one keyboard connected (usb, ps/2, doesn't matter), and after some time
you connect second USB keyboard (the NumLock is 'on' on the
On Mon, 2 Apr 2007 16:48:24 +0200 (CEST), Jiri Kosina [EMAIL PROTECTED] wrote:
On Sun, 1 Apr 2007, Pete Zaitcev wrote:
could you please change the order of the two functions, so that you
don't have to put the forward declaration here?
[...]
I'd say this is a little bit overcommented
On Tue, 3 Apr 2007 01:04:05 -0400, Dmitry Torokhov [EMAIL PROTECTED] wrote:
What do you think?
The patch looks sane, although I haven't yet tested it. I'll live with
it until next quarterly update, then consider if I should take it or use
my patch for RHEL 5 and RHEL 4.
-- Pete
-
To
On Tue, 03 Apr 2007 08:22:28 -0700, Kok, Auke [EMAIL PROTECTED] wrote:
Having the gspca driver move into the main tree would help a lot though.
I think we need to articulate better why this is an issue and not just
an excuse. We know that scheduling issues with ISO transfers exist, but
with the
On Thu, 13 Sep 2007 09:43:13 -0700 (PDT), Linus Torvalds [EMAIL PROTECTED]
wrote:
So why not make the 64 sector limit be the default? Get rid of the quirk:
we already allow people to override it in /sys if they really want to, but
realistically, it's probably not going to make any
On Sat, 15 Sep 2007 03:48:19 -0700, Andrew Morton [EMAIL PROTECTED] wrote:
I have an error message with 2.6.23-rc6.
This did not happen with 2.6.22.
Another one for Michal's dirt file.
No, I think it's the module ordering again.
2.6.23-rc6 boot.msg extract ( hub/usb )
I wish users
On Fri, 21 Dec 2007 00:00:04 -0800, Daniel Walker [EMAIL PROTECTED] wrote:
I converted the usu_init_notify semaphore to normal mutex usage, and it
should still prevent the request_module before the init routine is
complete. Before it acted more like a complete, now the mutex protects
two
On Sat, 22 Dec 2007 09:01:50 -0800, Daniel Walker [EMAIL PROTECTED] wrote:
Then in usu_probe_thread() your basically stopping it at the start of
the function with a down(), and the up() is just ancillary .. So you
could easily move the up() further down in the function and still have
the same
On Thu, 29 Nov 2007 09:04:28 +0100, Oliver Neukum [EMAIL PROTECTED] wrote:
Isn't it possible to fix this in option's module table?
At first thought it'll need adding a field to struct usb_serial to save
the driver_info from the ID table in usb_serial_probe. It's something I'd
Why? It
On Sat, 1 Dec 2007 09:07:38 +0100, Norbert Preining [EMAIL PROTECTED] wrote:
is this the only addition that should be needed, ortogether with the
changes in option to call the huawei init function?
The only one.
I tried 2.6.24-rc3 with this patch only and it I again got the infinite
loop of
.
Signed-off-by: Pete Zaitcev [EMAIL PROTECTED]
-- Pete
--
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/
1 - 100 of 521 matches
Mail list logo
