Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 05:39:45PM -0700, Denys Vlasenko wrote: > On Tuesday 13 November 2007 10:56, Adrian Bunk wrote: > > On Tue, Nov 13, 2007 at 12:13:56PM -0500, Theodore Tso wrote: > > > On Tue, Nov 13, 2007 at 04:52:32PM +0100, Benoit Boissinot wrote: > > > > Btw, I used to test every -mm kernel. But since I've switched distros > > > > (gentoo->ubuntu) > > > > and I have less time, I feel it's harder to test -rc or -mm kernels (I > > > > know this isn't a lkml problem > > > > but more a distro problem, but I would love having an ubuntu blessed > > > > repo with current dev kernel > > > > for the latest stable ubuntu release). > > > > > > There are two parts to this. One is a Ubuntu development kernel which > > > we can give to large numbers of people to expand our testing pool. > > > But if we don't do a better job of responding to bug reports that > > > would be generated by expanded testing this won't necessarily help us. > > >... > > > > The main problem aren't missing testers [1] - we already have relatively > > experienced people testing kernels and/or reporting bugs, and we slowly > > scare them away due to the many bug reports without any reaction. > > > > The main problem is finding experienced developers who spend time on > > looking into bug reports. > > > > Getting many relatively unexperienced users (who need more guidance for > > debugging issues) as additional testers is therefore IMHO not > > necessarily a good idea. > > And where experienced developrs are coming from? > They are not born with Linux kernel skills. > They grow up from within user base. > > Bigger user base -> more developers (eventually) You missed the following in my email: "we slowly scare them away due to the many bug reports without any reaction." The problem is that bug reports take time. If you go away from easy things like compile errors then even things like describing what does no longer work, ideally producing a scenario where you can reproduce it and verifying whether it was present in previous kernels can easily take many hours that are spent before the initial bug report. If the bug report then gets ignored we discourage the person who sent the bug report to do any work related to the kernel again. > vda cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 03:13:46PM -0500, Mark Lord wrote: > Adrian Bunk wrote: >> On Tue, Nov 13, 2007 at 02:26:05PM -0500, Mark Lord wrote: > .. >>> If you've been making significant updates to a driver/subsystem, >>> and people are reporting that it is now broken for them, >> >> What are "significant updates"? >> >> Sometimes one person makes one small patch and this patch contains >> a typo. > .. > > Then that person should double check their changes against > the problems reported, and re-convince themselves that the > breakage wasn't from those. Simple. Simple? Everything you have in mind with "should double check their changes" is simply not realistic with dozens of known unfixed regressions within more than half a million changed or new lines of code written by more than 800 people - all numbers only counted since 2.6.23. >... >>> The reporters can help, >>> and many may even git-bisect or send patches. But you cannot *expect* or >>> *insist* upon them doing your job. >> >> Bullshit. >> >> Bug fixing is not about finding someone to blame, it's about getting the >> bug fixed. > .. > > It's not about blame, it's about paying attention to breakages in code that a > person claims to be supporting, and then doing their best to resolve the > issues. Maintainers are just humans with limited time. You were the one who suggested to "distribute code maintainership", so you should explain how to find the additional maintainers. > Again, if one has the time to actively write/modify code such that something > breaks, > then that person should also make time to fix the breakages. code writer != subsystem maintainer And git-bisect is the tool that tells you who broke it. >> The bug reporter is the person who can reproduce the problem, and if it's >> a regression then bisecting is the natural way of getting nearer at >> getting it fixed. > .. > For the third time, no disagreement here. git-bsect can help in many cases, > but not in all cases. And it requires a great time commitment from somebody > who's system used to work and now doesn't work. The person who broke it has > a fair bit of responsibility there, too. git-bisect can help only for regressions, and it can help for most regressions. And you shouldn't try to make a problem out of something that isn't a problem: Bug submitters are either volunteers who test -rc or even -git or -mm kernels for finding bugs or people who want a problem they experience fixed. In both cases the submitters are usually willing to invest some time for helping to get the bug fixed. > cheers cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 07:32:19PM +, Russell King wrote: >... > There's another issue I want to raise concerning bugzilla. We have the > classic case of "not enough people reading bugzilla bugs" - which is one > of the biggest problems with bugzilla. Virtually no one in the ARM > community looks for ARM bugs in bugzilla. > > Let's not forget that it would be a waste of time for people to manually > check bugzilla for ARM bugs. There's soo few people reporting ARM bugs > into bugzilla that a weekly manual check by every maintainer would just > return the same old boring results for months and months at a time. >... What about having all ARM bugs in Bugzilla by default assigned to [EMAIL PROTECTED] [1] > Russell King cu Adrian [1] Either directly or through a pseudo address, but that's just a technical detail. -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 07:46:49PM +, Russell King wrote: > On Tue, Nov 13, 2007 at 08:30:35PM +0100, Adrian Bunk wrote: > > There is this silly limit that noone can work more than 168 hours per > > week on the Linux kernel, and some kernel developers seem to take the > > liberty of spending even less time on kernel development... > > That limit of 168 hours applies all around the world to everyone. > Moreover, not all kernel developers are employed to hack on the > kernel for 168 hours a week. > > For me, personally, that figure is in reality about 24 hours a > week. Yes, just 24. The rest of the time (like *now*) is time I'm > volunteering because I happen to be reading my email... > > ... and happen to be wasting replying to discussions like this rather > than reading that message which has just arrived on the ARM kernel > mailing list from someone having problems using copy_from_user() > with a kernel pointer. > > So, please, stop this idea that somehow kernel developers can > somehow spend infinite amounts of time solving lots and lots of > bugs. Sorry, that happens when using irony in a non-native language... What I wanted to express: Noone has unlimited time for kernel development. > Russell King cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 02:26:05PM -0500, Mark Lord wrote: > Adrian Bunk wrote: >> On Tue, Nov 13, 2007 at 01:47:10PM -0500, Mark Lord wrote: >>> Adrian Bunk wrote: > .. >> Another point is that it shifts the work from the few experienced >> developers to the many users. Users (and voluntary testers) we have >> many, but developer time for debugging bug reports is a quite scarce >> resource. >> >>> And when a "maintainer" is too busy to find/fix their own bugs, >>> that could be a sign that they've bitten off too big of a chunk >>> of the kernel, and it's time for them to distribute code maintainership. >> >> The problem is: Maintainers don't grow on trees. > .. > > Hey, if somebody has time to break things, then they damn well ought > to be able to make time to fix them again. And the best developers > here on LKML do just that (fix what they break). > > You broke it, you fix it. A simple rule. > > Translation for the particularly daft: > > If you've been making significant updates to a driver/subsystem, > and people are reporting that it is now broken for them, What are "significant updates"? Sometimes one person makes one small patch and this patch contains a typo. > then it's your job to make it right. We have some open drivers/ata/ regressions. I see some person named "Mark Lord" being responsible for 4 commits. What pubishment do you plan for him if 2.6.24 ships with any libata regressions? Let George W. Bush wrongly accuse him of possessing weapons of mass destructions and invade Canada? > The reporters can help, > and many may even git-bisect or send patches. > But you cannot *expect* or *insist* upon them doing your job. Bullshit. Bug fixing is not about finding someone to blame, it's about getting the bug fixed. The bug reporter is the person who can reproduce the problem, and if it's a regression then bisecting is the natural way of getting nearer at getting it fixed. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 02:12:57PM -0500, Mark Lord wrote: > Adrian Bunk wrote: >> On Tue, Nov 13, 2007 at 01:47:10PM -0500, Mark Lord wrote: >>> Adrian Bunk wrote: >>> ... >>>> I did bisecting myself, and I know that it costs time and work. >>>> >>>> But the first point is the above one that it makes otherwise nearly >>>> undebuggable problems debuggable and fixable. >>> .. >>> >>> Definitely useful, no question. >>> >>> But the problem is now that kernel devs are addicted to it, >>> many won't even consider resolving a problem any other way. >>> >>> That's not "maintaining" (or supporting) one's code. >> >> What you replaced with two dots contained the answer to this: >> >> Another point is that it shifts the work from the few experienced >> developers to the many users. Users (and voluntary testers) we have >> many, but developer time for debugging bug reports is a quite scarce >> resource. >> >>> And when a "maintainer" is too busy to find/fix their own bugs, >>> that could be a sign that they've bitten off too big of a chunk >>> of the kernel, and it's time for them to distribute code maintainership. >> >> The problem is: Maintainers don't grow on trees. >> >> You need people who are both technically capable and willing to spend time >> on the non-sexy task of debugging problems. >> >> Where do you plan to find them? >> >> If you don't believe me, please find a maintainer for the currently >> unmaintained parallel port support. >> >> Or if you want a harder task, find a maintainer for the floppy driver... > .. > > Again, the problem is: > >> But the problem is now that kernel devs are addicted to it, >> many won't even consider resolving a problem any other way. > > And that's simply not good enough. There is this silly limit that noone can work more than 168 hours per week on the Linux kernel, and some kernel developers seem to take the liberty of spending even less time on kernel development... Considering our problems to cope with the amount of incoming bug reports, everything that would require a kernel developer to spend more time for getting a bug fixed would be a horrible mistake. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 01:47:10PM -0500, Mark Lord wrote: > Adrian Bunk wrote: > ... >> I did bisecting myself, and I know that it costs time and work. >> >> But the first point is the above one that it makes otherwise nearly >> undebuggable problems debuggable and fixable. > .. > > Definitely useful, no question. > > But the problem is now that kernel devs are addicted to it, > many won't even consider resolving a problem any other way. > > That's not "maintaining" (or supporting) one's code. What you replaced with two dots contained the answer to this: Another point is that it shifts the work from the few experienced developers to the many users. Users (and voluntary testers) we have many, but developer time for debugging bug reports is a quite scarce resource. > And when a "maintainer" is too busy to find/fix their own bugs, > that could be a sign that they've bitten off too big of a chunk > of the kernel, and it's time for them to distribute code maintainership. The problem is: Maintainers don't grow on trees. You need people who are both technically capable and willing to spend time on the non-sexy task of debugging problems. Where do you plan to find them? If you don't believe me, please find a maintainer for the currently unmaintained parallel port support. Or if you want a harder task, find a maintainer for the floppy driver... > Cheers cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 01:18:43PM -0500, Mark Lord wrote: > Adrian Bunk wrote: >> On Tue, Nov 13, 2007 at 12:50:08PM -0500, Mark Lord wrote: >>> Ingo Molnar wrote: >>>> for example git-bisect was godsent. I remember that years ago bisection >>>> of a bug was a very laborous task so that it was only used as a final, >>>> last-ditch approach for really nasty bugs. Today we can autonomouly >>>> bisect build bugs via a simple shell command around "git-bisect run", >>>> without any human interaction! This freed up testing resources >>> .. >>> >>> It's only a godsend for the few people who happen to be kernel developers >> >> It's also godsend for users who want a regression they observe fixed. >> >> If you can tell which patch broke it you often turned a very hard to debug >> problem into a relatively easy fixable problem. > .. > > Oh yes, definitely. When that use happens to be a kernel dev + git user, > it saves the *fool who broke it* a hell of a lot of time, because they can > slough it off onto the poor bloke who notices it. "fool who broke it" are hard works. Bugs are part of software development, so you'd have to name everyone who develops software a fool. But the main point is that often you don't know who broke it until you know which commit broke it. > Mind you, no arguing that this is effective when that poor bloke > has a day free to download the git-tree and build/reboot a dozen times. I did bisecting myself, and I know that it costs time and work. But the first point is the above one that it makes otherwise nearly undebuggable problems debuggable and fixable. Another point is that it shifts the work from the few experienced developers to the many users. Users (and voluntary testers) we have many, but developer time for debugging bug reports is a quite scarce resource. And why "poor bloke"? Bisecting takes time, but that's not different from e.g. writing code or cleaning up code or going through bug reports. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 12:50:08PM -0500, Mark Lord wrote: > Ingo Molnar wrote: >> >> for example git-bisect was godsent. I remember that years ago bisection of >> a bug was a very laborous task so that it was only used as a final, >> last-ditch approach for really nasty bugs. Today we can autonomouly bisect >> build bugs via a simple shell command around "git-bisect run", without any >> human interaction! This freed up testing resources > .. > > It's only a godsend for the few people who happen to be kernel developers It's also godsend for users who want a regression they observe fixed. If you can tell which patch broke it you often turned a very hard to debug problem into a relatively easy fixable problem. As an example, [1] was an issue a normal user could discover, and bisecting made the difference between "nearly undebuggable" and "easily fixable by revertng a commit". > and who happen to already use git. As already said in thread, the required instructions for bisecting are relatively short and simple (assuming the user can build his own kernels). > It's a 540MByte download over a slow link for everyone else. Not everyone has a slow connection. For me, the speed of cloning a tree from git.kernel.org is completely cpu bound and limited by the speed of the 1.8 Ghz Athlon in my computer... But if there is a real life problem like people with extremely slow and expensive internet connections not being able to bisect bugs these problems should be named and fixed (e.g. by sending CDs). > -ml cu Adrian [1] http://lkml.org/lkml/2007/11/12/154 -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 12:13:56PM -0500, Theodore Tso wrote: > On Tue, Nov 13, 2007 at 04:52:32PM +0100, Benoit Boissinot wrote: > > Btw, I used to test every -mm kernel. But since I've switched distros > > (gentoo->ubuntu) > > and I have less time, I feel it's harder to test -rc or -mm kernels (I > > know this isn't a lkml problem > > but more a distro problem, but I would love having an ubuntu blessed > > repo with current dev kernel > > for the latest stable ubuntu release). > > There are two parts to this. One is a Ubuntu development kernel which > we can give to large numbers of people to expand our testing pool. > But if we don't do a better job of responding to bug reports that > would be generated by expanded testing this won't necessarily help us. >... The main problem aren't missing testers [1] - we already have relatively experienced people testing kernels and/or reporting bugs, and we slowly scare them away due to the many bug reports without any reaction. The main problem is finding experienced developers who spend time on looking into bug reports. Getting many relatively unexperienced users (who need more guidance for debugging issues) as additional testers is therefore IMHO not necessarily a good idea. > - Ted cu Adrian [1] and e.g. when Greg says he has a few hundred people who want to write drivers it would most likely be possible to find a few dozen additional -rc testers among them -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 07:57:54AM -0800, Ray Lee wrote:
> On Nov 13, 2007 7:24 AM, Giacomo A. Catenazzi <[EMAIL PROTECTED]> wrote:
> > As a long time kernel tester, I see some problem with the
> > newer "new development model". In the short merge windows,
> > after to much time, there are to many patches.
>
> I think the root issue there is that it's hard to get all testers to
> run a bisect, but easy to ask them to test snapshots. Right now the
> snapshots are generated nightly, but I think it would make more sense
> if they were generated every N patches, for some value of N...
>...
I don't see a point in doing that - that would be a more manual
bisecting, and the result would not be one guilty commit.
Testers are not expected to be able to hack a kernel, but it's
reasonable to expect testers to be able to build their own kernels
(and your proposal wouldn't change that).
The small instruction below is enough for everyone who is able to
build his own kernel to do a git bisect.
> Ray
cu
Adrian
<-- snip -->
# install git
# clone Linus' tree:
git clone \
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
# start bisecting:
cd linux-2.6
git bisect start
git bisect bad v2.6.21
git bisect good v2.6.20
cp /path/to/.config .
# start a round
make oldconfig
make
# install kernel, check whether it's good or bad, then:
git bisect [bad|good]
# start next round
After at about 10-15 reboots you'll have found the guilty commit
("... is first bad commit").
More information on git bisecting:
man git-bisect
[RFC: 2.6 patch] remove the USB_STORAGE_ONETOUCH driver
Nearly two years ago, USB_STORAGE_ONETOUCH got a dependency on !PM.
Considering that this also implies that the driver is not available
e.g. when ACPI is enabled in the kernel that's not far from a dependency
on BROKEN.
This patch therefore removes this driver.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/usb/storage/Kconfig| 12 -
drivers/usb/storage/Makefile |1
drivers/usb/storage/onetouch.c | 237 -
drivers/usb/storage/onetouch.h |9 -
drivers/usb/storage/unusual_devs.h | 17 --
drivers/usb/storage/usb.c |3
6 files changed, 279 deletions(-)
876e6730e6fb60856da318ad652a912757359f44
diff --git a/drivers/usb/storage/Kconfig b/drivers/usb/storage/Kconfig
index 7e5..9b7df5f 100644
--- a/drivers/usb/storage/Kconfig
+++ b/drivers/usb/storage/Kconfig
@@ -121,18 +121,6 @@ config USB_STORAGE_ALAUDA
These devices are based on the Alauda chip and support both
XD and SmartMedia cards.
-config USB_STORAGE_ONETOUCH
- bool "Support OneTouch Button on Maxtor Hard Drives (EXPERIMENTAL)"
- depends on USB_STORAGE && INPUT_EVDEV && EXPERIMENTAL && !PM
- help
- Say Y here to include additional code to support the Maxtor OneTouch
- USB hard drive's onetouch button.
-
- This code registers the button on the front of Maxtor OneTouch USB
- hard drive's as an input device. An action can be associated with
- this input in any keybinding software. (e.g. gnome's keyboard short-
- cuts)
-
config USB_STORAGE_KARMA
bool "Support for Rio Karma music player"
depends on USB_STORAGE
diff --git a/drivers/usb/storage/Makefile b/drivers/usb/storage/Makefile
index 023969b..a93ae7a 100644
--- a/drivers/usb/storage/Makefile
+++ b/drivers/usb/storage/Makefile
@@ -19,7 +19,6 @@ usb-storage-obj-$(CONFIG_USB_STORAGE_ISD200) += isd200.o
usb-storage-obj-$(CONFIG_USB_STORAGE_DATAFAB) += datafab.o
usb-storage-obj-$(CONFIG_USB_STORAGE_JUMPSHOT) += jumpshot.o
usb-storage-obj-$(CONFIG_USB_STORAGE_ALAUDA) += alauda.o
-usb-storage-obj-$(CONFIG_USB_STORAGE_ONETOUCH) += onetouch.o
usb-storage-obj-$(CONFIG_USB_STORAGE_KARMA)+= karma.o
usb-storage-objs :=scsiglue.o protocol.o transport.o usb.o \
diff --git a/drivers/usb/storage/onetouch.c b/drivers/usb/storage/onetouch.c
deleted file mode 100644
index dfd42fe..000
--- a/drivers/usb/storage/onetouch.c
+++ /dev/null
@@ -1,237 +0,0 @@
-/*
- * Support for the Maxtor OneTouch USB hard drive's button
- *
- * Current development and maintenance by:
- * Copyright (c) 2005 Nick Sillik <[EMAIL PROTECTED]>
- *
- * Initial work by:
- * Copyright (c) 2003 Erik Thyren <[EMAIL PROTECTED]>
- *
- * Based on usbmouse.c (Vojtech Pavlik) and xpad.c (Marko Friedemann)
- *
- */
-
-/*
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- *
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include "usb.h"
-#include "onetouch.h"
-#include "debug.h"
-
-void onetouch_release_input(void *onetouch_);
-
-struct usb_onetouch {
- char name[128];
- char phys[64];
- struct input_dev *dev; /* input device interface */
- struct usb_device *udev;/* usb device */
-
- struct urb *irq;/* urb for interrupt in report */
- unsigned char *data;/* input data */
- dma_addr_t data_dma;
- unsigned int is_open:1;
-};
-
-static void usb_onetouch_irq(struct urb *urb)
-{
- struct usb_onetouch *onetouch = urb->context;
- signed char *data = onetouch->data;
- struct input_dev *dev = onetouch->dev;
- int status = urb->status;
- int retval;
-
- switch (status) {
- case 0: /* success */
- break;
- case -ECONNRESET: /* unlink */
- case -ENOENT:
- case -ESHUTDOWN:
- return;
- /* -EPIPE: should clear the halt */
- default:/* error */
- goto resubmit;
- }
-
- input_report_key(dev, ONETOUCH_BUTTON, data[0] & 0x02);
- input_sync(dev);
-
-resubmit:
- retval = usb_submit_urb (urb, G
[2.6 patch] input/serio/hp_sdc.c section fix
hp_sdc_exit() mustn't be __exit since it's called from the
__init hp_sdc_register().
This patch fixes the following section mismatch:
<-- snip -->
...
MODPOST vmlinux.o
...
WARNING: vmlinux.o(.init.text+0x1af68): Section mismatch: reference to
.exit.text:hp_sdc_exit (between 'hp_sdc_register' and 'hp_sdc_mlc_init')
...
<-- snip -->
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
4022ed345d1b61dc5b6ac0fc35877656e444a11d
diff --git a/drivers/input/serio/hp_sdc.c b/drivers/input/serio/hp_sdc.c
index 6af1998..02b3ad8 100644
--- a/drivers/input/serio/hp_sdc.c
+++ b/drivers/input/serio/hp_sdc.c
@@ -944,11 +944,7 @@ static int __init hp_sdc_init_hppa(struct parisc_device *d)
#endif /* __hppa__ */
-#if !defined(__mc68000__) /* Link error on m68k! */
-static void __exit hp_sdc_exit(void)
-#else
static void hp_sdc_exit(void)
-#endif
{
write_lock_irq(&hp_sdc.lock);
[-mm patch] mousedev.c:mixdev_open_devices() bugfix
On Wed, Aug 22, 2007 at 02:06:48AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.23-rc2-mm2:
>...
> git-input.patch
>...
> git trees
>...
This patch fixes an obvious bug in mixdev_open_devices().
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
bb574366744163ff84609843ee43e84a39f57d5a
diff --git a/drivers/input/mousedev.c b/drivers/input/mousedev.c
index 2ad8633..4ca0ad3 100644
--- a/drivers/input/mousedev.c
+++ b/drivers/input/mousedev.c
@@ -461,7 +461,7 @@ static void mixdev_open_devices(void)
list_for_each_entry(mousedev, &mousedev_mix_list, mixdev_node) {
if (!mousedev->mixdev_open) {
- if (mousedev_open_device(mousedev));
+ if (mousedev_open_device(mousedev))
continue;
mousedev->mixdev_open = 1;
[2.6 patch] make the dummy touchkit_ps2_detect() static
The dummy touchkit_ps2_detect() for the CONFIG_MOUSE_PS2_TOUCHKIT=n case
shouldn't be a global function.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch has been sent on:
- 14 Aug 2007
--- a/drivers/input/mouse/touchkit_ps2.h
+++ b/drivers/input/mouse/touchkit_ps2.h
@@ -15,7 +15,8 @@
#ifdef CONFIG_MOUSE_PS2_TOUCHKIT
int touchkit_ps2_detect(struct psmouse *psmouse, int set_properties);
#else
-inline int touchkit_ps2_detect(struct psmouse *psmouse, int set_properties)
+static inline int touchkit_ps2_detect(struct psmouse *psmouse,
+ int set_properties)
{
return -ENOSYS;
}
Re: [PATCH] Console keyboard events and accessibility
On Tue, Aug 21, 2007 at 10:22:51PM +0200, Samuel Thibault wrote: > Hi, > > Andrew Morton, le Tue 21 Aug 2007 13:02:33 -0700, a écrit : > > On Tue, 21 Aug 2007 02:57:18 +0200 > > Samuel Thibault <[EMAIL PROTECTED]> wrote: > > > > > Some external modules like Speakup need to use the PC keyboard to control > > > them and also need to get keyboard feedback (caps lock status, etc.) > > > > > > This adds a keyboard notifier that such modules can use to get the > > > keyboard > > > events and possibly eat them, at several stages: > > > > Adding hooks for non-merged modules is considered sinful. Making these new > > exports EXPORT_SYMBOL_GPL might ease the pain. > > That should be fine. > > I'll soon propose a notifier for the console writes too, same story. > > > Is there any prospect of getting at least one of these "external modules > > like Speakup" merged into mainline? > > I'm working on it. The problem is that the current code quality is > still far from mainline requirements (though improving over time). This > hook (and the other one I'll post) is a step toward merging. If these > hooks can go mainline, then great, that will make life easier for the > few distributions that want to provide speakup as modules. How long does it take you for getting the first users submitted for review? If you are working on it it should be in the order of "a few months", and earlier merging would anyway gain you only one or two kernel releases. > If they > remain in -mm for some time and people don't complain, well that's good > too: at least we know how speakup may hook into the kernel when it gets > merged. >... Without any users it's dead code noone uses, and complaints will most likely not occur until you submit the first users for review... > Samuel cu Adrian BTW: Are these the speakup patches that were in -ac five years ago? -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
[2.6 patch] make the dummy touchkit_ps2_detect() static
The dummy touchkit_ps2_detect() for the CONFIG_MOUSE_PS2_TOUCHKIT=n case
shouldn't be a global function.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
64d15c53e66b200d832a6009aa24c344883bcbcf
diff --git a/drivers/input/mouse/touchkit_ps2.h
b/drivers/input/mouse/touchkit_ps2.h
index 61e9dfd..8a0dd35 100644
--- a/drivers/input/mouse/touchkit_ps2.h
+++ b/drivers/input/mouse/touchkit_ps2.h
@@ -15,7 +15,8 @@
#ifdef CONFIG_MOUSE_PS2_TOUCHKIT
int touchkit_ps2_detect(struct psmouse *psmouse, int set_properties);
#else
-inline int touchkit_ps2_detect(struct psmouse *psmouse, int set_properties)
+static inline int touchkit_ps2_detect(struct psmouse *psmouse,
+ int set_properties)
{
return -ENOSYS;
}
Re: [patch 1/3] m68k/mac: Make mac_hid_mouse_emulate_buttons() declaration visible
On Fri, Jul 20, 2007 at 02:51:02PM -0400, Dmitry Torokhov wrote: > On 7/20/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: >> On Fri, Jul 20, 2007 at 01:47:36PM -0400, Dmitry Torokhov wrote: >> > Hi Geert, >> > >> > On 7/20/07, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote: >> >> From: Geert Uytterhoeven <[EMAIL PROTECTED]> >> >> >> >> m68k/mac: Make mac_hid_mouse_emulate_buttons() declaration visible >> >> >> >> drivers/char/keyboard.c: In function 'kbd_keycode': >> >> drivers/char/keyboard.c:1142: error: implicit declaration of function >> >> 'mac_hid_mouse_emulate_buttons' >> >> >> >> The forward declaration of mac_hid_mouse_emulate_buttons() is not >> visible >> >> on >> >> m68k because it's hidden in the middle of a big #ifdef block. >> >> >> >> Move it to , correct the type of the second parameter, and >> >> include where needed. >> > >> > linux/hid.h contains definitions needed for drivers speaking HID >> > protocol, I don't think we want to put quirks for legacy keyboard >> > driver there. I'd just move the #ifdef within drivers/char/keyboard.c >> > for now. >> >... >> >> If you only move it you will keep the bug of the wrong second parameter. >> >> But if you move it to any header file gcc is able to figure out such >> errors itself instead of them being nasty runtime errors. >> >> Such prototypes in C files are really bad since (like in this case) they >> prevent the finding of bugs. It doesn't matter which header file you put >> the prototype into (it can even be a new one), but it belongs into a >> header file. > > I am OK with adding a new header file. I was just saying that placing > that declaration in linux/hid.h makes about the same sense as putting > it into linux/scsi.h scsi.h would also be fine with me. ;-) Are you making a patch or should I send one? [1] > Dmitry cu Adrian [1] for a new header file, not scsi.h -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: [patch 1/3] m68k/mac: Make mac_hid_mouse_emulate_buttons() declaration visible
On Fri, Jul 20, 2007 at 01:47:36PM -0400, Dmitry Torokhov wrote: > Hi Geert, > > On 7/20/07, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote: >> From: Geert Uytterhoeven <[EMAIL PROTECTED]> >> >> m68k/mac: Make mac_hid_mouse_emulate_buttons() declaration visible >> >> drivers/char/keyboard.c: In function 'kbd_keycode': >> drivers/char/keyboard.c:1142: error: implicit declaration of function >> 'mac_hid_mouse_emulate_buttons' >> >> The forward declaration of mac_hid_mouse_emulate_buttons() is not visible >> on >> m68k because it's hidden in the middle of a big #ifdef block. >> >> Move it to , correct the type of the second parameter, and >> include where needed. > > linux/hid.h contains definitions needed for drivers speaking HID > protocol, I don't think we want to put quirks for legacy keyboard > driver there. I'd just move the #ifdef within drivers/char/keyboard.c > for now. >... If you only move it you will keep the bug of the wrong second parameter. But if you move it to any header file gcc is able to figure out such errors itself instead of them being nasty runtime errors. Such prototypes in C files are really bad since (like in this case) they prevent the finding of bugs. It doesn't matter which header file you put the prototype into (it can even be a new one), but it belongs into a header file. > Dmitry cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
appletouch quirk doesn't run at resume
On Sat, Mar 17, 2007 at 11:07:38AM +0100, Thomas Meyer wrote: > Thomas Gleixner schrieb: > > I finally found a dual core box, which survives suspend/resume without > > crashing in the middle of nowhere. Sigh, I never figured out from the > > code and the bug reports what's going on. > > > > The observed hangs are caused by a stale state transition of the clock > > event devices, which keeps the RCU synchronization away from completion, > > when the non boot CPU is brought back up. > > > > The suspend/resume in oneshot mode needs the similar care as the > > periodic mode during suspend to RAM. My assumption that the state > > transitions during the different shutdown/bringups of s2disk would go > > through the periodic boot phase and then switch over to highres resp. > > nohz mode were simply wrong. > > > > Add the appropriate suspend / resume handling for the non periodic > > modes. > > > > Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]> > > > > Excellent work. Now suspend to disk is working again. But: > > 1.) The quirk added in commit a417a21e10831bca695b4ba9c74f4ddf5a95ac06 > for the appletouch driver doesn't seem to work after resume. >... Not a regression, but still a bug. Appropriate people added to the Cc. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
[2/6] 2.6.21-rc2: known regressions
This email lists some known regressions in 2.6.21-rc2 compared to 2.6.20 that are not yet fixed in Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: ThinkPad doesn't resume from suspend to RAM References : http://lkml.org/lkml/2007/2/27/80 http://lkml.org/lkml/2007/2/28/348 Submitter : Jens Axboe <[EMAIL PROTECTED]> Jeff Chua <[EMAIL PROTECTED]> Status : unknown Subject: beeps get longer after suspend References : http://lkml.org/lkml/2007/2/26/276 Submitter : Pavel Machek <[EMAIL PROTECTED]> Status : unknown Subject: ThinkPad T60: no screen after suspend to RAM References : http://lkml.org/lkml/2007/2/22/391 Submitter : Michael S. Tsirkin <[EMAIL PROTECTED]> Status : unknown Subject: ThinkPad Z60m: usb mouse stops working after suspend to ram References : http://lkml.org/lkml/2007/2/21/413 http://lkml.org/lkml/2007/2/28/172 Submitter : Arkadiusz Miskiewicz <[EMAIL PROTECTED]> Caused-By : Konstantin Karasyov <[EMAIL PROTECTED]> commit 0a6139027f3986162233adc17285151e78b39cac Handled-By : Konstantin Karasyov <[EMAIL PROTECTED]> Status : problem is being debugged Subject: AE_NOT_FOUND ACPI messages References : http://bugzilla.kernel.org/show_bug.cgi?id=8066 http://lkml.org/lkml/2007/2/27/263 Submitter : Thomas Meyer <[EMAIL PROTECTED]> Meelis Roos <[EMAIL PROTECTED]> Handled-By : Alexey Starikovskiy <[EMAIL PROTECTED]> Patch : http://bugzilla.kernel.org/show_bug.cgi?id=8066 Status : patch available Subject: Asus M6Ne notebook: ACPI: First battery is not detected References : http://bugzilla.kernel.org/show_bug.cgi?id=8080 Submitter : Janosch Machowinski <[EMAIL PROTECTED]> Status : unknown Subject: AT keyboard only works with pci=noacpi References : http://lkml.org/lkml/2007/3/3/68 Submitter : Ash Milsted <[EMAIL PROTECTED]> Status : unknown
[2.6 patch] drivers/hid/hid-debug.c should #include
Every file should include the headers containing the prototypes for
it's global functions.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
--- linux-2.6.20-mm2/drivers/hid/hid-debug.c.old2007-02-20
23:07:32.0 +0100
+++ linux-2.6.20-mm2/drivers/hid/hid-debug.c2007-02-21 00:00:41.0
+0100
@@ -29,6 +29,7 @@
*/
#include
+#include
struct hid_usage_entry {
unsigned page;
