From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Sat, 5 Jan 2008 23:46:16 +0200
> This was missed when commit e2ac455a18806b31c2d0da0a51d8740af5010b7a
> fixed the compile errors in drivers/net/netx-eth.c caused by
> commit 09f75cd7bf13720738e6a196cc0107ce9a5bd5a0.
>
> Signed-off-by: Adrian Bunk <[EMA
On Sun, Jan 06, 2008 at 04:36:06PM +0900, Tetsuo Handa wrote:
> Hello.
>
> Willy Tarreau wrote:
> > Your patch is very confusing. In your description, as well as in the
> > comments you talk about tmpfs, but your patch does not touch even one
> > line of tmpfs and only changes ramfs. Even your var
Hello.
Willy Tarreau wrote:
> Your patch is very confusing. In your description, as well as in the
> comments you talk about tmpfs, but your patch does not touch even one
> line of tmpfs and only changes ramfs. Even your variables and arguments
> refer to tmpfs. The Kconfig entry indicates that th
From: Amos Waterland <[EMAIL PROTECTED]>
Date: Sat, 5 Jan 2008 22:58:16 -0500
> ADDRESS ASSIGNED
>
> qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=on"
> qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=dhcp"
> qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append
Hi David,
I've reported before a lockdep warning when block2mtd is modloaded, and a
device is initialized, as in
modprobe block2mtd block2mtd=/dev/loop0
A typical warning looks like this:
BUG: key f88565c0 not in .data!
WARNING: at kernel/lockdep.c:2331 lockdep_init_map()
Pid: 1823, com
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sun, 06 Jan 2008 11:22:04 +1100
> [IPV4] raw: Strengthen check on validity of iph->ihl
>
> We currently check that iph->ihl is bounded by the real length and that
> the real length is greater than the minimum IP header length. However,
> we did not che
Hello,
On Sun, Jan 06, 2008 at 03:20:00PM +0900, Tetsuo Handa wrote:
> Hello.
>
> Changes from previous posting:
>
> (1) Added kernel config so that users can choose
> whether to compile this filesystem or not.
>
> I didn't receive any ACK/NACK regarding whether I'm permitted to
>
Hello.
Changes from previous posting:
(1) Added kernel config so that users can choose
whether to compile this filesystem or not.
I didn't receive any ACK/NACK regarding whether I'm permitted to
implement this filesystem as an extension to tmpfs or not.
So, I continued imple
On Sun, 06 Jan 2008 02:20:45 +0100, Miguel =?utf-8?q?Bot=C3=B3n?= said:
> #ifdef CONFIG_X86_32
> asmlinkage long sys_iopl(unsigned long regsp)
> {
> volatile struct pt_regs *regs = (struct pt_regs *)®sp;
> unsigned int level = regs->bx;
> #else
> asmlinkage long sys_iopl(unsigned int le
On Sat, Jan 05, 2008 at 04:46:05PM +0100, Bartlomiej Zolnierkiewicz wrote:
> Hmm, no. The driver is called ide-floppy (ide_floppy) and it is more
> readable this way.
>
> > {
> > idefloppy_t *floppy = drive->driver_data;
> > struct gendisk *g = floppy->disk;
> > @@ -1479,7 +1450,7 @@ sta
Sam Ravnborg wrote:
> On Sat, Jan 05, 2008 at 11:03:30PM +0200, Adrian Bunk wrote:
> > For kconfig users, "select" is _much_ better than sending them through
> > different menus.
>
> Only if used within the current limitations of Kconfig.
> And that requires you to use select only to select symbols
Alan Cox wrote:
> Al Boldi <[EMAIL PROTECTED]> wrote:
> > What's hindering the ability to force a mode in libata, as is possible
> > with the normal ide-driver?
>
> We want it to be correct and race free. That means we have to synchronize
> all the devices on the controller, quiesce them and recomp
On Sun, Jan 06, 2008 at 02:02:14AM +, Al Viro wrote:
>
> E.g. what about ipt_REJECT.c::send_reset()? Or myri10ge_get_frag_header()?
Yes both look wrong.
Patrick, please have a look at the former. In fact it's not just
that ihl may be bogus (which might be harmless as long as the REJECT
hoo
On Sat, 5 Jan 2008, Rafael J. Wysocki wrote:
> On Saturday, 5 of January 2008, Alan Stern wrote:
> > On Sat, 5 Jan 2008, Rafael J. Wysocki wrote:
> > > Still, even doing that is not enough, since someone can call
> > > destroy_suspended_device() from a .suspend() routine and then the device
> > >
The recent changes for ip command line processing fixed some problems
but unfortunately broke some common usage scenarios. In current
2.6.24-rc6 the following command line results in no IP address
assignment, which is surely a regression:
ip=10.0.2.15::10.0.2.2:255.255.255.0::eth0:off
Please fi
Hello,
Al Viro wrote:
> On Sun, Jan 06, 2008 at 11:54:43AM +0900, Tejun Heo wrote:
>> That means sysfs_remove_dir() is called on parent while other operations
>> are in progress on children, right? sysfs has never allowed such things
>> && AFAIK no one does that. It's somewhat implied in the int
> Maybe, but we can usually work around it pretty comfortably.
>
> If smu_set_fan() is only ever called by a kernel thread then we can simply
> flip it over to using wait_for_completion_interruptible().
Hrm... as of today, it's mostly called from a kernel thread but I don't
totally iron out the
On Sat, Jan 05, 2008 at 07:31:29PM -0800, Arjan van de Ven wrote:
> Andi Kleen wrote:
> >Arjan van de Ven <[EMAIL PROTECTED]> writes:
> >>Rank 4: remove_proc_entry
> >>Was also ranked 4th last week
> >>Only in tainted oopses
> >>Reported 3 times (12 total reports)
> >>More info:
>
On Sat, 6 Jan 2008, Peter Osterlund wrote:
>
> The problem is that pktcdvd opens the cd device in non-blocking mode
> when pktsetup is run, and doesn't close it again until pktsetup -d
> is run. The effect is that if you meanwhile open the cd device,
> blkdev.c:do_open() doesn't call bd_set_size
On Sun, Jan 06, 2008 at 11:54:43AM +0900, Tejun Heo wrote:
> That means sysfs_remove_dir() is called on parent while other operations
> are in progress on children, right? sysfs has never allowed such things
> && AFAIK no one does that. It's somewhat implied in the interface (such
> as recursive
Andi Kleen wrote:
Arjan van de Ven <[EMAIL PROTECTED]> writes:
Rank 4: remove_proc_entry
Was also ranked 4th last week
Only in tainted oopses
Reported 3 times (12 total reports)
More info: http://www.kerneloops.org/search.php?search=remove_proc_entry
Likely a br
Arjan van de Ven <[EMAIL PROTECTED]> writes:
>
> Rank 4: remove_proc_entry
> Was also ranked 4th last week
> Only in tainted oopses
> Reported 3 times (12 total reports)
> More info: http://www.kerneloops.org/search.php?search=remove_proc_entry
Likely a broken module_exit()
On Sat, 5 Jan 2008 17:25:24 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Sat, 5 Jan 2008 23:10:17 +0100 "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
>
> > On Jan 5, 2008 3:52 PM, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> > > On Jan 5, 2008 11:13 AM, Jarek Poplawski <[EMAIL PROTECTED]> wro
On Sat, Jan 05, 2008 at 05:14:08PM -0800, mathewss wrote:
> I have been trying to figure this out a while now with printk's all over my
> kernel as well as adding kdb and tracing the int3 events.
>
> I have tried various 2.6 kernels and so far all i have tried do this.
>
> My current tests are
On Jan 5, 2008 11:10 PM, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> 2.6.24-rc6 + mm-patches up to git.battery (includes git-net and
> git-netdev-all) worked for 110 packages, then I proclaimed it good.
> 2.6.24-rc6 + mm-patches up to (including) git.nfsd is currently
> getting testet (9 packages d
On Sun, Jan 06, 2008 at 03:09:01AM +1030, David Newall wrote:
> On Tue, 1 Jan 2008 15:36:32 +0100 Andi Kleen <[EMAIL PROTECTED]> wrote:
>
>> ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/remove-aout-interpreter
>>
>> Also removal of the old unused iBCS hooks while I was on it
>>
>> ftp://ftp
From: Olof Johansson <[EMAIL PROTECTED]>
No need to have the HAVE_ARCH_BUG.* / HAVE_ARCH_WARN.* defines, when
the generic implementation can just use #ifndef on the macros themselves.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PR
From: Olof Johansson <[EMAIL PROTECTED]>
Not using the ppc-specific WARN_ON/BUG_ON constructs actually saves about
4K text on a ppc64_defconfig. The main reason seems to be that prepping
the arguments to the conditional trap instructions is more work than just
doing a compare and branch.
Signed-
Subject: Add the end-of-trace marker and the module list to WARN_ON()
From: Arjan van de Ven <[EMAIL PROTECTED]>
CC: Ingo Molnar <[EMAIL PROTECTED]>
CC: Andrew Morton <[EMAIL PROTECTED]>
CC: Olof Johansson <[EMAIL PROTECTED]>
Unlike oopses, WARN_ON() currently does't print the loaded modules list.
Subject: move WARN_ON() out of line
From: Arjan van de Ven <[EMAIL PROTECTED]>
CC: Ingo Molnar <[EMAIL PROTECTED]>
CC: Andrew Morton <[EMAIL PROTECTED]>
CC: Olof Johansson <[EMAIL PROTECTED]>
Acked-by: Matt Meckall <[EMAIL PROTECTED]>
A quick grep shows that there are currently 1145 instances of W
From: Olof Johansson <[EMAIL PROTECTED]>
Introduce __WARN() in the generic case, so the generic WARN_ON()
can use arch-specific code for when the condition is true.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
inc
3rd try for this patch series; now with a split up patch for __WARN_ON
This series has the goal of extending the usefulness of the WARN_ON()
information,
at least on architectures that use the generic WARN_ON() infrastructure. (Those
who
do their own thing either already have the extra informati
On Sat, 05 Jan 2008 21:18:52 +1100 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
wrote:
> On Sat, 2008-01-05 at 02:04 -0800, Robin H. Johnson wrote:
> > On Sat, Jan 05, 2008 at 01:30:37AM -0800, Andrew Morton wrote:
> > > >From that I'd suspect that kwindfarm is being a bad citizen.
> > > If a proce
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Wed, 2 Jan 2008, James Bottomley wrote:
>
> > Look at the taxonomy of the bug. This is the form of the error:
> >
> > buffer I/O error on device sr0, logical block 20304
> > attempt to access beyond end of device
> > sr0: rw=0, want=81224, limit=4
Hello, Al Viro.
Al Viro wrote:
> On Sun, Jan 06, 2008 at 11:07:52AM +0900, Tejun Heo wrote:
>
>> Right, I haven't thought about that. When sysfs_get_dentry() is called,
>> @sd is always valid so unless there was existing negative dentry, lookup
>> is guaranteed to return positive dentry, but by
On Fri, 4 Jan 2008 21:24:15 +0530 Dhaval Giani <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 04, 2008 at 05:58:16PM +0530, Dhaval Giani wrote:
> > On Thu, Jan 03, 2008 at 10:42:00PM +0100, Rafael J. Wysocki wrote:
> > > On Thursday, 3 of January 2008, Dhaval Giani wrote:
> > > > On Mon, Dec 31, 2007 at
On Sun, Jan 06, 2008 at 11:07:52AM +0900, Tejun Heo wrote:
> Right, I haven't thought about that. When sysfs_get_dentry() is called,
> @sd is always valid so unless there was existing negative dentry, lookup
> is guaranteed to return positive dentry, but by populating dcache with
> negative dentr
Hi Michael,
On Wednesday 02 January 2008, Michael Tokarev wrote:
> What I'm thinking about is: why ACPI events are
> routed over input subsystem, instead of hotplug
> subsystem? With input, there's a need for a
> special daemon/application listening on the
> specific "keyboard" device, while with
Hello,
Al Viro wrote:
> On Sat, Jan 05, 2008 at 11:30:25PM +0900, Tejun Heo wrote:
>>> Assuming that this is what we get, everything looks explainable - we
>>> have sysfs_rename_dir() calling sysfs_get_dentry() while the parent
>>> gets evicted. We don't have any exclusion, so while we are playin
On Sun, Jan 06, 2008 at 11:22:04AM +1100, Herbert Xu wrote:
> Actually if you read the code for ip_fast_csum it's obvious what has
> happened. %o1 == iph->ihl contains the value 2 which is bogus.
>
> [IPV4] raw: Strengthen check on validity of iph->ihl
>
> We currently check that iph->ihl is bo
Hi.
Berthold Cogel wrote:
> Al Viro schrieb:
>> On Tue, Jan 01, 2008 at 08:26:05PM +0100, Berthold Cogel wrote:
>>
>>> Jan 1 17:34:39 wonderland kernel: BUG: unable to handle kernel
>>> paging request at virtual address 00100100
>>
>> LIST_POISON1
>>
>>> Jan 1 17:34:39 wonderland kernel: EIP is
I have been trying to figure this out a while now with printk's all over my
kernel as well as adding kdb and tracing the int3 events.
I have tried various 2.6 kernels and so far all i have tried do this.
My current tests are on 2.6.22.10
I have a simple init binary I compiled static that is
On Sat, 5 Jan 2008 23:10:17 +0100 "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
> On Jan 5, 2008 3:52 PM, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> > On Jan 5, 2008 11:13 AM, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> > > On Sat, Jan 05, 2008 at 09:01:02AM +0100, Torsten Kaiser wrote:
> > > > On
convert byte order of constant instead of variable,
which can be done at compile time (vs run time)
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
---
fs/udf/directory.c |4 ++--
fs/udf/inode.c | 16
fs/udf/misc.c | 12 ++--
fs/udf/super.c | 16 +
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
---
fs/udf/balloc.c | 309 ---
1 files changed, 157 insertions(+), 152 deletions(-)
diff --git a/fs/udf/balloc.c b/fs/udf/balloc.c
index d1d4b8f..5ce7926 100644
--- a/fs/udf/balloc.c
+++ b/fs/ud
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
---
fs/udf/balloc.c | 49 -
1 files changed, 20 insertions(+), 29 deletions(-)
diff --git a/fs/udf/balloc.c b/fs/udf/balloc.c
index 17b67dc..d1d4b8f 100644
--- a/fs/udf/balloc.c
+++ b/fs/udf/balloc
I just realize that in some cases 'regs->flags' is a long instead of an
unsigned long so... this would be a proper solution?
static long do_iopl(unsigned int level, long *flags)
{
...
}
#ifdef CONFIG_X86_32
asmlinkage long sys_iopl(unsigned long regsp)
{
volatile struct pt_regs *
Hi
This patchset contains various UDF fs cleanups.
[PATCH 1/7] udf: fix coding style
This is really big (~170kB) and boring (style cleanup) patch,
so I'm not sending it to LKML. You can find it here:
http://www.kadu.net/~joi/kernel/2008.01.06/0001-udf-fix-coding-style.patch
[PATCH 2/7] udf: crea
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
---
fs/udf/inode.c | 15 ++-
fs/udf/misc.c| 24 +++-
fs/udf/namei.c |9 +
fs/udf/super.c | 16 ++--
fs/udf/udfdecl.h | 12
5 files changed, 20 insertions(+), 56
Stefan Richter wrote:
Adrian Bunk wrote:
Whether or not an option requires an additional subsystem like e.g. SCSI
or SSB are hardware and implementation details we shouldn't bother
kconfig users with.
What is an implementation detail and what is not? In the end,
everything that we configure
On Sun, Jan 06, 2008 at 01:57:13AM +0100, Jan Engelhardt wrote:
>
> >@@ -304,7 +305,8 @@ static int raw_send_hdrinc(struct sock *sk, void *from,
> >size_t length,
> > goto error_fault;
> >
> > /* We don't modify invalid header */
> >-if (length >= sizeof(*iph) && iph->ihl * 4U
Al Viro schrieb:
On Tue, Jan 01, 2008 at 08:26:05PM +0100, Berthold Cogel wrote:
Jan 1 17:34:39 wonderland kernel: BUG: unable to handle kernel paging
request at virtual address 00100100
LIST_POISON1
Jan 1 17:34:39 wonderland kernel: EIP is at evdev_disconnect+0x65/0x9e
and by the look
On Sunday 06 January 2008 01:47:47 Arnd Bergmann wrote:
> This #ifdef overload could probably be avoided if you just move
> the body of this function into an extra place and do
>
> static int do_iopl(unsigned int level, unsigned long *flags)
> {
> unsigned int old = (*flags >> 12) & 3;
>
On Sun, Jan 06, 2008 at 01:35:21AM +0100, Stefan Richter wrote:
> Adrian Bunk wrote:
> > Whether or not an option requires an additional subsystem like e.g. SCSI
> > or SSB are hardware and implementation details we shouldn't bother
> > kconfig users with.
>
> What is an implementation detail an
On Jan 6 2008 11:22, Herbert Xu wrote:
>@@ -271,6 +271,7 @@ static int raw_send_hdrinc(struct sock *sk, void *from,
>size_t length,
> int hh_len;
> struct iphdr *iph;
> struct sk_buff *skb;
>+ unsigned int iphlen;
> int err;
>
> if (length > rt->u.dst.dev->mtu)
Ehh, forgot to add patching order :(
Should be:
[PATCH 1/6] udf: fix coding style of super.c
[PATCH 2/6] udf: remove some ugly macros
[PATCH 3/6] udf: convert UDF_SB_ALLOC_PARTMAPS macro to
udf_sb_alloc_partition_maps function
[PATCH 4/6] udf: check if udf_load_logicalvol failed
[PATCH 5/6] udf:
On Sunday 06 January 2008, Miguel Botón wrote:
> +#ifdef CONFIG_X86_32
> +asmlinkage long sys_iopl(unsigned long regsp)
> +#else
> +asmlinkage long sys_iopl(unsigned int level, struct pt_regs *regs)
> +#endif
> +{
> +#ifdef CONFIG_X86_32
> + volatile struct pt_regs *regs = (struct pt_regs *)®
convert UDF_SB_ALLOC_BITMAP macro to udf_sb_alloc_bitmap function
convert UDF_SB_FREE_BITMAP macro to udf_sb_free_bitmap function
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
CC: Christoph Hellwig <[EMAIL PROTECTED]>
---
fs
fix sparse warnings:
fs/udf/super.c:1431:24: warning: symbol 'bh' shadows an earlier one
fs/udf/super.c:1347:21: originally declared here
fs/udf/super.c:472:6: warning: symbol 'udf_write_super' was not declared.
Should it be static?
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennem
- convert UDF_SB_ALLOC_PARTMAPS macro to udf_sb_alloc_partition_maps function
- convert kmalloc + memset to kcalloc
- check if kcalloc failed (partially)
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
Acked-by: Christoph Hellw
udf_load_logicalvol may fail eg in out of memory conditions - check it
and propagate error further
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
CC: Christoph Hellwig <[EMAIL PROTECTED]>
---
fs/udf/super.c |7 ++-
1
fix coding style errors found by checkpatch:
- assignments in if conditions
- braces {} around single statement blocks
- no spaces after commas
- printks without KERN_*
- lines longer than 80 characters
before: total: 50 errors, 207 warnings, 1835 lines checked
after: total: 0 errors, 164 warnings
Hi
This patchset converts macros related to super_block into
functions. Besides that it fixes some sparse warnings (6th),
improves coding style (1st) and fixes error handling (4th).
Note that udf files has really long lines and these patches won't
validate by checkpatch. Next patchset will clean i
Adrian Bunk wrote:
> Whether or not an option requires an additional subsystem like e.g. SCSI
> or SSB are hardware and implementation details we shouldn't bother
> kconfig users with.
What is an implementation detail and what is not? In the end,
everything that we configure in Kconfig is imple
On Saturday 05 January 2008 17:52:06 Rémi Hérilier wrote:
> What about finding what does this BIOS function and writing
> an equivalent in C? There would be no BIOS call anymore and
> this module could be used in the x86-64 port.
>
> But, is it a sane solution?
The problem is that the BIOS call wo
(Resending as there were no replies on my first post mid December; issue
is still there with -rc6.)
This is the first time I've seen this error. Last time I used the printer
was with 2.6.24-rc3 and that time this error did not occur.
The error occurs when I start a print job, not when I turn the
Al Viro <[EMAIL PROTECTED]> wrote:
>
> ip_fast_csum() called from raw_send_hdrinc() from raw_sendmsg() ran through
> the page boundary into unmapped page... Bloody odd, that, seeing that
> we have checked iph->ihl * 4U <= length and had done
>err = memcpy_fromiovecend((void *)iph, from, 0
On Sat, 5 Jan 2008, Davide Libenzi wrote:
A solution may be to move the call to ep_poll_safewake() (that'd become a
simple wake_up()) inside a tasklet or whatever is today trendy for delayed
work. But his kinda scares me to be honest, since epoll has already a
bunch of places where it could be as
On Sun, Jan 06, 2008 at 01:14:40AM +0100, Berthold Cogel wrote:
> >There are only 4 changesets between 2.6.23 and this one affecting
> >drivers/input
> >and only
> >8006479c9b75fb6594a7b746af3d7f1fbb68f18f and
> >6addb1d6de1968b84852f54561cc9a09b5a9
> >appear to be relevant. Apply to your ke
paravirt_patch_{32|64}.c unification.
This patch unifies the code from the paravirt_patcht_32.c and
paravirt_patch_64.c files.
I couldn't test this modification but it shouldn't have any bugs
(it's a very simple modification).
Signed-off-by: Miguel Botón <[EMAIL PROTECTED]>
diff --git a/arch/x8
ioport_{32|64}.c unification.
This patch unifies the code from the ioport_32.c and ioport_64.c files.
Tested and working fine with i386 and x86_64 kernels.
Signed-off-by: Miguel Botón <[EMAIL PROTECTED]>
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 0903bbf..5ed68b4 100
On Wed 2008-01-02 12:56:40, Michael Tokarev wrote:
> (Not so) recently, ACPI events started appearing as
> key press events over linux input subsystem. The
> question regarding this is simple: how it's supposed
> to be handled?
>
> First of all, I don't know any software so far that
> can handle
On Sat, Jan 05, 2008 at 03:22:14PM -0800, Randy Dunlap wrote:
>...
> For Aunt Tillie cases, "select" makes sense. For other cases,
> I'd argue that it makes sense for config users to know when they
> do something that causes an entire subsystem to be added to their
> kernel (like SCSI or NET).
We
Rafael J. Wysocki wrote:
This message contains a list of some regressions from 2.6.23 reported since
2.6.24-rc1 was released, for which there are no fixes in the mainline I know
of. If any of them have been fixed already, please let me know.
..
Subject : 2+ wake-ups/second in 2.6.2
On Saturday, 5 of January 2008, Alan Cox wrote:
> > Subject : PATA_HPT37X embezzles two ports
> > Submitter : "Bjoern Olausson" <[EMAIL PROTECTED]>
> > Date: 2007-12-12 11:05
> > References : http://lkml.org/lkml/2007/12/12/161
> > http://bugzilla.kernel
On Saturday, 5 of January 2008, Gregor Jasny wrote:
> Hi,
>
> During some tests I've noticed that the VIDIOCGMBUF ioctl hangs on my
> bttv video device. It simply does not return and the process is stuck in
> the D+ state. With Kernel 2.6.22.9 the (attached) testcase works like a
> charm. The V4L2
Sam Ravnborg wrote:
On Sat, Jan 05, 2008 at 11:03:30PM +0200, Adrian Bunk wrote:
On Sat, Jan 05, 2008 at 11:30:24AM -0800, Randy Dunlap wrote:
On Sat, 5 Jan 2008 18:41:39 +0300 Al Boldi wrote:
Select SCSI for USB Mass Storage support.
Cc: David Brownell <[EMAIL PROTECTED]>
Cc: Greg KH <[EMA
Hi.
Pavel Machek wrote:
> On Fri 2008-01-04 21:54:06, Oliver Neukum wrote:
>> Am Donnerstag, 3. Januar 2008 23:06:07 schrieb Nigel Cunningham:
>>> Oliver Neukum wrote:
Am Donnerstag, 3. Januar 2008 10:52:53 schrieb Nigel Cunningham:
> Oliver Neukum wrote:
>> Am Donnerstag 03 Januar 20
Hi,
During some tests I've noticed that the VIDIOCGMBUF ioctl hangs on my
bttv video device. It simply does not return and the process is stuck in
the D+ state. With Kernel 2.6.22.9 the (attached) testcase works like a
charm. The V4L2 interface is working with 2.6.24, too (at least displays
xawtv
The kernel has a divide by zero crash when trying to run the system
timer less than 100Hz. The problem is x/(HZ/USER_HZ) and related.
Now x*(USER_HZ/HZ) will be used if HZ
--
David Fries <[EMAIL PROTECTED]>
http://fries.net/~david/ (PGP encryption key available)
diff --git a/include/linux/acct
On Sat, 29 Dec 2007 00:11:42 -0800
Philip Langdale <[EMAIL PROTECTED]> wrote:
> As pci config space is reinitialised on a suspend/resume cycle, the
> disabler needs to work its magic at resume time. For symmetry this
> change also explicitly enables the controller at suspend time but
> it's not st
On Saturday 05 January 2008, Haavard Skinnemoen wrote:
> On Sat, 5 Jan 2008 12:10:56 -0800
> David Brownell <[EMAIL PROTECTED]> wrote:
>
> > From: David Brownell <[EMAIL PROTECTED]>
> >
> > Teach AVR32 to use the "GPIO Library" when exposing its GPIOs, so that
> > signals on external chips (like
On Saturday 05 January 2008, Russell King wrote:
> Not everything in drivers/ is suitable for every ARM configuration. It
> was felt at the time better for ARM to remain separate because people
> didn't want to pollute drivers/Kconfig with the ARM specific conditionals.
We made drivers/Kconfig wo
On Jan 5, 2008 3:52 PM, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> On Jan 5, 2008 11:13 AM, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> > On Sat, Jan 05, 2008 at 09:01:02AM +0100, Torsten Kaiser wrote:
> > > On Jan 5, 2008 1:07 AM, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> > > > I think it wou
On Saturday, 5 of January 2008, Alan Stern wrote:
> On Sat, 5 Jan 2008, Rafael J. Wysocki wrote:
>
> > On Saturday, 5 of January 2008, Alan Stern wrote:
> > > On Sat, 5 Jan 2008, Rafael J. Wysocki wrote:
> > >
> > > > > Another thing to watch out for: Just in case somebody ends up calling
> > > >
On Jan 5, 2008 9:47 AM, Hauke Mehrtens <[EMAIL PROTECTED]> wrote:
> Hi
>
> Now the compat-wireless-2.6 package is working and I get an Internet
> connection with my rtl8187 based card. (It's on an ASUS P5B Deluxe)
>
> I used the compat-wireless-2.6 package for this log, but I have the same
> proble
On Wed 2008-01-02 15:23:30, Alan Stern wrote:
> On Wed, 2 Jan 2008, Oliver Neukum wrote:
>
> > Am Dienstag 01 Januar 2008 schrieb Pavel Machek:
> > > Hi1
> > >
> > > > I would like to request a feature in the Linux kernel that would allow
> > > > a user to unplug a live read-only root file system
On Sun 2007-12-30 12:15:52, Ingo Molnar wrote:
>
> * Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> > Todays hardware is mostly capable of doing better: with correctly set
> > up wakeups, machine can sleep and successfully pretend it is not
> > sleeping -- by waking up whenever something interesti
On Sat, 5 Jan 2008 12:10:56 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> From: David Brownell <[EMAIL PROTECTED]>
>
> Teach AVR32 to use the "GPIO Library" when exposing its GPIOs, so that
> signals on external chips (like GPIO expanders) can easily be used.
>
> This mostly reorganizes some
This was missed when commit e2ac455a18806b31c2d0da0a51d8740af5010b7a
fixed the compile errors in drivers/net/netx-eth.c caused by
commit 09f75cd7bf13720738e6a196cc0107ce9a5bd5a0.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
15e5efb728c61333ca10648334185efba86c4815
diff --git a/drivers/net
Hi!
> > > On kohjinsha, wakeup code does not seem to be reached at all. I tried
> > > looking around FACS, but it seems very empty:
> > >
> > > ...
> >
> > The same on my laptop:
> >
> > FACS @ 0x2fefafc0
signature length hwsignature waking_vector
> > : 46 41 43 53 40 00
On Sat, 5 Jan 2008, Rafael J. Wysocki wrote:
> On Saturday, 5 of January 2008, Alan Stern wrote:
> > On Sat, 5 Jan 2008, Rafael J. Wysocki wrote:
> >
> > > > Another thing to watch out for: Just in case somebody ends up calling
> > > > destroy_suspended_device(dev) from within dev's own resume me
On Sat, Jan 05, 2008 at 01:06:17PM -0800, Arjan van de Ven wrote:
> The http://www.kerneloops.org website collects kernel oops and
> warning reports from various mailing lists and bugzillas as well as
> with a client users can install to auto-submit oopses.
> Below is a top 10 list of the oopses co
On Sat, 5 Jan 2008, Peter Zijlstra wrote:
>
> On Sat, 2008-01-05 at 17:53 +0100, Peter Zijlstra wrote:
> > On Sat, 2008-01-05 at 18:12 +1100, Herbert Xu wrote:
> > > On Fri, Jan 04, 2008 at 09:30:49AM +0100, Ingo Molnar wrote:
> > > >
> > > > > > [ 1310.670986] ===
HI!
> > On kohjinsha, wakeup code does not seem to be reached at all. I tried
> > looking around FACS, but it seems very empty:
> >
> > ...
>
> The same on my laptop:
>
> FACS @ 0x2fefafc0
> : 46 41 43 53 40 00 00 00 62 12 00 00 00 00 00 00 [EMAIL PROTECTED]
> 0010: 00 00 00 00 00 00 00
On Sun, 6 Jan 2008 00:20:50 +0300
Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
> netconsole should be more quick:
Thanks a lot for the tip, I'll try that.
Alexander
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordo
On Sat, Jan 05, 2008 at 01:06:17PM -0800, Arjan van de Ven wrote:
> Rank 3: d_splice_alias
> NULL pointer deref
> Reported 3 times
> Happens in the isofs code
> Only seen in 2.6.24-rc5-mm1
> More info: http://www.kerneloops.org/search.php?search=d_splice_alias
in -rc6
On Jan 4 2008 19:39, Theodore Tso wrote:
>On Sat, Jan 05, 2008 at 01:12:44AM +0100, Paolo Ciarrocchi wrote:
>
>But because running some kind of mechanical script and fixing up the
>problems is relatively mindless, it doesn't *add* anything. Only the
>maintainer knows when it is a reasonably conve
On Sun, Jan 06, 2008 at 12:30:34AM +0400, Alexander Shaduri wrote:
> > Get a serial console? Take another box, plug e.g. pl2303-based
> > usb-to-serial (several bucks these days) into it, stick null-modem
> > convertor (ditto) on its serial end and attach to ttyS0 on the
> > victim. console=ttyS0
On Fri 2008-01-04 21:54:06, Oliver Neukum wrote:
> Am Donnerstag, 3. Januar 2008 23:06:07 schrieb Nigel Cunningham:
> > Hi.
> >
> > Oliver Neukum wrote:
> > > Am Donnerstag, 3. Januar 2008 10:52:53 schrieb Nigel Cunningham:
> > >> Hi.
> > >>
> > >> Oliver Neukum wrote:
> > >>> Am Donnerstag 03 Jan
1 - 100 of 244 matches
Mail list logo
