Subject: ACPI: fix processor throttling set error
From: Yi Yang <[EMAIL PROTECTED]>
When echo some invalid values to /proc/acpi/processor/*/throttling,
there isn't any error info returned, on the contray, it sets
throttling value to some T* successfully, obviously, this is incorrect,
a correct
Hello,
On Sun, 06 Jan 2008 23:42:07 -0800 (PST)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Paul Rolland <[EMAIL PROTECTED]>
> Date: Mon, 7 Jan 2008 08:37:04 +0100
>
> > I remember reading some time ago about a network driver to "simulate"
> > network default, for example packet loss...
> >
From: Paul Rolland <[EMAIL PROTECTED]>
Date: Mon, 7 Jan 2008 08:37:04 +0100
> I remember reading some time ago about a network driver to "simulate"
> network default, for example packet loss...
> Unfortunately, I can't find the post, neither in my mailbox nor in
> archives...
>
> Does anyone has
Hello,
I remember reading some time ago about a network driver to "simulate"
network default, for example packet loss...
Unfortunately, I can't find the post, neither in my mailbox nor in
archives...
Does anyone has an URL that you could send me ?
Regards,
Paul
--
To unsubscribe from this list:
As much as I hate to touch either subject, let alone both at
once... Eric, would you mind explaining what exactly do you want
sysfs to do in presense of your "namespaces"? On the "what does user
see if we do <...>" level.
a) what happens if I do chdir("/sys/class/net/eth42/")
On Sun, 06 Jan 2008 16:34:16 -0500 Mark Lord <[EMAIL PROTECTED]> wrote:
> Venki Pallipadi wrote:
> > Reintroduce run time configurable max_cstate for !CPU_IDLE case.
> >
> > Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
> >
> > Index: linux-2.6.24-rc/drivers/acpi/processor_idle.c
> >
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sun, 06 Jan 2008 23:57:57 -0700
> Why do we need 1 interfaces? Why isn't network device creation a
> slow path?
Because people create virtual devices like mad.
> So is this a bug report telling me that there are users with
> 10k or 100k
>PS. Mikael - should Jesper be mentioned in MAINTAINERS?
Yes, that is a good idea. Down the road Jesper will take over maintainership
I guess.
-Original Message-
From: Sam Ravnborg [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 01, 2008 11:20 AM
To: WANG Cong
Cc: Mikael Starvik; LKML;
Benjamin LaHaise <[EMAIL PROTECTED]> writes:
> Hello folks,
>
> 2.6.24-rc6 regresses on the 1 network interface creation test relative to
> 2.6.23. The cause appears to be the new code in sysctl_check_lookup(), which
> shows up as the #1 item while profiling. Is a revert of this new code
On Sun, 23 Dec 2007 13:09:05 +0200
Boaz Harrosh <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 21 2007 at 4:30 +0200, Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> wrote:
> > The sense buffer ins scsi_cmnd can nowadays be DMA'ed into directly
> > by some low level drivers (that typically happens with
On Saturday 05 January 2008 14:25, Linda Walsh wrote:
> A question that comes to mind every time I go through the settings
> for "Preemption Model" and "Preempt The Big Kernel Lock".
>
> Do each of the combinations "make sense", or are some "no-ops"?
> For model, we have 1) no forced (server), 2)
> [EMAIL PROTECTED] <[EMAIL PROTECTED]> :
>> Kernel is 2.6.24-rc6 + linuxpps patches, which are all to the serial
>> port driver.
>>
>> 2.6.23 was known stable. I haven't tested earlier 2.6.24 releases.
>> I think it happened once before; I got a black-screen lockup with
>> keyboard LEDs
Rusty Russell wrote:
> On Monday 07 January 2008 16:01:40 Tejun Heo wrote:
>>> But we hit the same problems:
>>>
>>> 1) sg_chain loses information. The clever chain packaging makes reading
>>> easy, but manipulation is severely limited. You can append to your own
>>> chains by padding, but not
On Sun, 6 Jan 2008 21:03:42 +0100
"Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
> On Jan 6, 2008 2:33 PM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> > On Sun, 6 Jan 2008 12:35:35 +0100
> > "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
> > > On Jan 6, 2008 12:23 PM, FUJITA Tomonori <[EMAIL
Hell Roman!
Thank you for your answer.
On Montag, 7. Januar 2008, Roman Zippel wrote:
> On Thursday 3. January 2008, Ph. Marek wrote:
> > So I took a look at "Help", and saw that blob:
...
> > That is a _bit_ unreadable.
>
> What you see here is the internal representation of the select
> [ 1687.358730] [] sys_sync+0xa/0x17
duh.
--
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/
Hi
After physical memory upgrade from 3GB to 4GB (also it happens on 5GB) got
kernel panic.
Because it is happening on early stage and my machine doesn't contain serial
port, i had to take photo.
Kernel boots fine with 64GB highmem, no highmem, or highmem4G with limited
memory by mem=3G. All
This patch replaces my 2007-12-20 patch by the same title, and has to take
its place in the order of applying that whole series.
Further testing revealed a bug that resulted in regset-based core dumps of
32-bit processes on 64-bit kernels having r0..r3 cleared to zero. The fix
(interdiff from
1) In tty.c the BUG_ON at line 115 will never be called, because the the before
list_del_init in this same function.
115 BUG_ON(!list_empty(>list));
So move the list_del_init to rfcomm_dev_del
2) The rfcomm_dev_del could be called from diffrent path
Eric,
Any decision for this patch, if not, currently we prefer to add all our
code to quirks.c.
BRs
Peer Chen
-Original Message-
From: Peer Chen
Sent: Wednesday, January 02, 2008 5:58 PM
To: 'Eric W. Biederman'
Cc: peerchen; linux-kernel; akpm; Andy Currid
Subject: RE: [PATCH] msi: set
On Sun, 2008-01-06 at 12:29 -0800, Andrew Morton wrote:
> On Sun, 06 Jan 2008 19:01:10 +0100 Mike Galbraith <[EMAIL PROTECTED]> wrote:
>
> >
> > On Sun, 2008-01-06 at 10:42 +0100, Mike Galbraith wrote:
> > > FWIW, here's box having same seizure writing to /dev/pktcdvd/sr0.
> >
> > Ugh, horrid
On Monday 07 January 2008 16:01:40 Tejun Heo wrote:
> > But we hit the same problems:
> >
> > 1) sg_chain loses information. The clever chain packaging makes reading
> > easy, but manipulation is severely limited. You can append to your own
> > chains by padding, but not someone elses. This
Rusty Russell wrote:
> I realize that sg chaining is a ploy to make the rest of the kernel
> devs feel the pain of the SCSI subsystem. But this was a little
> unsubtle.
>
> Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
Embarrassingly Acked-by: Tejun Heo <[EMAIL PROTECTED]>
Thanks.
--
Hello,
Rusty Russell wrote:
>> The other thing I note is that the problem you're claiming to solve with
>> sg_ring (the ability to add extra scatterlists to the front or the back
>> of an existing one) is already solved with sg_chain, so the only real
>> advantage of sg_ring was that it contains
Steven Rostedt wrote:
On Thu, 3 Jan 2008, Mathieu Desnoyers wrote:
I would propose to try to see how we can #ifdef two different __mcount
assembly functions that would prepare the stack appropriately for each
REGPARM cases.
I have to confess that I've been testing this mostly on x86_64,
On Sun, 6 Jan 2008 19:22:37 -0600
Olof Johansson <[EMAIL PROTECTED]> wrote:
> This comment in oops_enter threw me off of using it:
>
> debug_locks_off(); /* can't trust the integrity of the kernel
> anymore */
>
> Since we can very well depend on the integrity of the kernel when
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
>
> * Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
>
> > > @@ -34,6 +34,7 @@ mctracer_add_trace_entry(struct mctracer
> > > {
> > > unsigned long idx, idx_next;
> > > struct mctracer_entry *entry;
> > > + struct task_struct *tsk = current;
> >
> >
I realize that sg chaining is a ploy to make the rest of the kernel
devs feel the pain of the SCSI subsystem. But this was a little
unsubtle.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r b3aec596b841 include/linux/scatterlist.h
--- a/include/linux/scatterlist.h Mon Jan 07
On Sunday 06 January 2008 02:31:12 James Bottomley wrote:
> On Wed, 2007-12-19 at 17:31 +1100, Rusty Russell wrote:
> > This patch series is the start of my attempt to simplify and make
> > explicit the chained scatterlist logic.
> >
> > It's not complete: my SATA box boots and seems happy, but
Linda Walsh wrote:
Mikael Pettersson wrote:
Linda Walsh writes:
> Mikael Pettersson wrote:
> > Linda Walsh writes:
> > > > Linda Walsh wrote:
> > > read rate began falling; (.25 - .3); > > > more
importantly; a chronic error message associated
> > > with drive may be causing
Hi All,
Please CC me on your responses
I am working on Kernel 2.6.22.1 mmc host drivers. I recently found that
mmc driver in kernel 2.6.23.1 supports bounce buffers. I wanted to use
bounce buffer feature.
I do not want to go to Kernel 2.6.23.1. I want to be at 2.6.22.1, but
I need mmc driver
On Sunday 06 January 2008, Yi Yang wrote:
>
> > How about not changing a userland-visible interface gratuitously?
>
> "empty" can't tell a user the state of wakeup of a device, so it is
> necessary to change it.
Words don't say anything at all in isolation. For example,
here the current
Hi,
On Thursday 3. January 2008, Ph. Marek wrote:
> So I took a look at "Help", and saw that blob:
>
> Selected by: NETFILTER_XT_TARGET_CONNMARK && NET && INET && NETFILTER &&
> NETFILTER_XTABLES && (IP_NF_MANGLE || IP6_NF_MANGLE) && NF_CONNTRACK
> || NETFILTER_XT_MATCH_CONNMARK && NET &&
Hi,
On Wednesday 2. January 2008, Eric Sandeen wrote:
> Roman, with this on top does it look better to you?
Looks good, thanks.
> I'll get hfsplus done in a bit.
I'm mainly concerned about brec.c/bfind.c, the patch should be pretty much
identical.
bye, Roman
--
To unsubscribe from this
Is this an issue in the Totem code or in the kernel?
Please, let me know if you need my .config file.
[ 5446.835007] WARNING: at kernel/lockdep.c:2662 check_flags()
[ 5446.835022] Pid: 6060, comm: totem-plugin-vi Not tainted 2.6.24-rc7 #1
[ 5446.835027] [] show_trace_log_lvl+0x1a/0x2f
[
Hi,
Yesterday, I have encountered an issue when the kernel size is more than 1.3MB.
Info on problem encountered as follows:
1) I am using Atmel AT91SAM9261 part. Circuit similar to that of AT91SAM9261EK
evaluation board.
2) I am booting the kernel through NFS. Bootloader
used is UBoot 1.1.5.
Hi,
Lately, I have observed an odd behviour in kernel 2.6.23.1 on a 800x480 TFT LCD
unit.
The odd behviour as follows:
1) I am using Atmel AT91SAM9261 part. Circuit similar to that of AT91SAM9261EK
evaluation board.
2) I am booting the kernel and mounting root filesystem through NFS.
Hi all,
Could someone please help me understand what's happening with, what
looks like inconsistent behavior, between getpwd and procfs readlink.
Basically, from a bash shell, setting working directory to a mounted
directory all is fine with "pwd" and "/proc//cwd". Following a
"umount - l" on
On Sat, Jan 05, 2008 at 01:31:21AM -0800, Andrew Morton wrote:
> On Wed, 2 Jan 2008 22:10:52 +0100 Karel Zak <[EMAIL PROTECTED]> wrote:
> > The second util-linux-ng 2.13.1 release candidate is available at
> > ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/
> Interesting. Thanks. Which
On Sun, Jan 06, 2008 at 03:30:16PM +0300, Dmitry Baryshkov wrote:
> Support using VOLTAGE_* properties for apm calculations. It's pretty
> dummy, but useful for batteries for which we can only get voltages.
By the way...
> diff --git a/drivers/power/apm_power.c b/drivers/power/apm_power.c
>
Hello,
Tejun Heo wrote:
> 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
On Mon, 2008-01-07 at 02:57 +0100, Rafael J. Wysocki wrote:
> On Monday, 7 of January 2008, Yi Yang wrote:
> > On Fri, 2008-01-04 at 08:09 -0800, David Brownell wrote:
> > > > > This patch changes empty output to "unsupported" in order that a user
> > > > > knows
> > > > > wakeup feature isn't
On Fri, 2008-01-04 at 18:20 +0100, Oliver Neukum wrote:
> Am Freitag, 4. Januar 2008 17:52:14 schrieb Olivier Galibert:
> > On Fri, Jan 04, 2008 at 11:38:29AM -0500, Alan Stern wrote:
> > > How about changing it to say "unavailable"? That doesn't imply
> > > permanence.
> >
> > How about not
On Sun, Jan 06, 2008 at 07:41:29PM +0100, Stefan Richter wrote:
> Dave Young wrote:
> > Convert semaphore to mutex in struct class.
> > All the patches in this series should be applyed simultaneously
>
> Therefore you eventually need to repost it as a single patch. It can't
> go into one of the
Hi Ingo,
> this is about the bttv driver in 2.6.24-rc6/(rc7?) hanging. So whatever
> the devel tree does, this fix (if it's a correct fix) needs to be
> commited upstream ASAP.
You are right, my misunderstood. Sorry guys!
Cheers,
Douglas
--
To unsubscribe from this list: send the line
On Fri, 2008-01-04 at 17:52 +0100, Olivier Galibert wrote:
> On Fri, Jan 04, 2008 at 11:38:29AM -0500, Alan Stern wrote:
> > How about changing it to say "unavailable"? That doesn't imply
> > permanence.
>
> How about not changing a userland-visible interface gratuitously?
"empty" can't tell a
On Fri, 2008-01-04 at 11:38 -0500, Alan Stern wrote:
> On Fri, 4 Jan 2008, David Brownell wrote:
>
> > > > This patch changes empty output to "unsupported" in order that a user
> > > > knows
> > > > wakeup feature isn't supported by this device when he/she
> > > > 'cat
On Fri, 2008-01-04 at 08:31 -0800, David Brownell wrote:
> > This patch changes empty output to "unsupported" in order that a user knows
> > wakeup feature isn't supported by this device when he/she
> > 'cat /sys/devices/.../power/wakeup', please consider to apply, thanks.
>
> I don't much like
On Monday, 7 of January 2008, Yi Yang wrote:
> On Fri, 2008-01-04 at 08:09 -0800, David Brownell wrote:
> > > > This patch changes empty output to "unsupported" in order that a user
> > > > knows
> > > > wakeup feature isn't supported by this device when he/she
> > > > 'cat
Hi,
The patch below is intended as a replacement for
gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch that deadlocked
suspend and hibernation on some systems. The present patch contains some
safeguards against deadlocks in that cases and a mechanism to print warnings
if a deadlock
On 2008.01.04 23:26:33 +0100, Björn Steinbrink wrote:
> For cards that initially have the MAC address stored in reverse order,
> the forcedeth driver uses a flag to signal whether the address was
> already corrected, so that it is not reversed again on a subsequent
> probe.
>
> Unfortunately this
On Fri, 2008-01-04 at 08:09 -0800, David Brownell wrote:
> > > This patch changes empty output to "unsupported" in order that a user
> > > knows
> > > wakeup feature isn't supported by this device when he/she
> > > 'cat /sys/devices/.../power/wakeup', please consider to apply,
> > > thanks.
> >
>
On 2008.01.06 19:49:49 -0200, Adolfo R. Brandes wrote:
> I have this forcedeth MAC address reversal problem when suspending
> on 2 distinct boxes. I can confirm Steinbrink's patch fixes the
> problem on only one of them:
>
> 00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev f3)
Change origin chipset name i965G_1 to market name G35.
Signed-off-by: Zhenyu Wang <[EMAIL PROTECTED]>
---
drivers/char/agp/intel-agp.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
index
On Fri, 2008-01-04 at 07:44 -0500, Lee Revell wrote:
> On Jan 4, 2008 3:10 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > http://redhat.com/~mingo/cfs-scheduler/tools/hackbench.c
> >
>
> Why not lose the #ifdef and just use PTHREAD_STACK_MIN?
That's a good idea.
Thanks,
-yanmin
---
---
On Fri, 2008-01-04 at 12:48 +0100, Pavel Machek wrote:
> Hi!
>
> > If a device can't support wakeup, its /sys/devices/.../power/wakeup output
> > is
> > empty, this is confusing, a user doesn't know if it supports wakeup feature
> > unless he/she read the ralated source code, for this case, it
On Monday 07 January 2008 10:18:50 Arjan van de Ven wrote:
> Subject: show being-loaded/being-unloaded indicator for modules in oopses
> From: Arjan van de Ven <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
>
> It's rather common that an
On Monday 07 January 2008 10:19:46 Arjan van de Ven wrote:
> Subject: track and print last unloaded module in the oops trace
> From: Arjan van de Ven <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
>
> Based on a suggestion from Andi:
> In various cases,
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Sun, 6 Jan 2008 02:15:54 -0800
> On Sun, 6 Jan 2008 11:03:02 +0100 Mariusz Kozlowski <[EMAIL PROTECTED]> wrote:
>
> > This is from allnoconfig on sparc64:
> >
> > LD .tmp_vmlinux1
> > arch/sparc64/kernel/head.o: In function
On Sun, Jan 06, 2008 at 01:38:17PM -0800, Arjan van de Ven wrote:
> On Sun, 6 Jan 2008 14:22:23 -0600
> Olof Johansson <[EMAIL PROTECTED]> wrote:
>
> > Powerpc uses the generic report_bug() from lib/bug.c to report
> > warnings, and I'm guessing other arches do as well.
> >
> > Add the module
On Fri, 2008-01-04 at 13:51 +0200, T�r�k Edwin wrote:
> Ingo Molnar wrote:
> > * Zhang, Yanmin <[EMAIL PROTECTED]> wrote:
> >
> >
> >> hackbench is to test Linux scheduler. The original program is at
> >> http://devresources.linux-foundation.org/craiger/hackbench/src/hackbench.c
> >> Based on
On Monday 07 January 2008 04:33:53 Glauber de Oliveira Costa wrote:
> On Dec 25, 2007 9:54 PM, Rusty Russell <[EMAIL PROTECTED]> wrote:
> > My only question is whether we should go further and vpu-ify routines
> > like lgread and kill_guest, so that we can avoid more "lg" temporary
> >
On Monday, 7 of January 2008, Rafael J. Wysocki wrote:
> On Monday, 7 of January 2008, Johannes Berg wrote:
> > Rafael J. Wysocki wrote:
> >
> > >> I don't see anything wrong with it. All that will happen is that the
> > >> removal will start before the suspend and finish after the resume.
> > >
Hello,
Linus Torvalds wrote:
> On Sun, 6 Jan 2008, Mark Lord wrote:
>> We're still missing the sata_qstor regression fix from Tejun,
>> and the patch from Venkatesh Pallipadi that reinstates max_cstate
>> in sysfs for !CPU_IDLE.
>
> I'm not seeing those in my inbox. I don't go out trolling for
[EMAIL PROTECTED] <[EMAIL PROTECTED]> :
> Kernel is 2.6.24-rc6 + linuxpps patches, which are all to the serial
> port driver.
>
> 2.6.23 was known stable. I haven't tested earlier 2.6.24 releases.
> I think it happened once before; I got a black-screen lockup with
> keyboard LEDs blinking, but
On Sun, 6 Jan 2008, Mark Lord wrote:
>
> We're still missing the sata_qstor regression fix from Tejun,
> and the patch from Venkatesh Pallipadi that reinstates max_cstate
> in sysfs for !CPU_IDLE.
I'm not seeing those in my inbox. I don't go out trolling for patches,
because I expect that if
On Monday, 7 of January 2008, Johannes Berg wrote:
> Rafael J. Wysocki wrote:
>
> >> I don't see anything wrong with it. All that will happen is that the
> >> removal will start before the suspend and finish after the resume.
> >
> > In that case, we'll attempt to call the device's .suspend()
Linus Torvalds wrote:
..
Both git trees and tar-balls/patches pushed out, should be mirroring out
within minutes. So there are no excuses to not try it out, and see if your
favorite regression has been fixed.
..
We're still missing the sata_qstor regression fix from Tejun,
and the patch from
(Adding the kernel list back. Any reason you did not send the reply there?)
Sorry for the late reply: Christmas, New Year, the flue, etc.
On Friday 28 December 2007, Zhao Yakui wrote:
> On Mon, 2007-12-24 at 06:12 +0100, Frans Pop wrote:
> > During boot with v2.6.24-rc6-125-g5356f66 on my
On Sun, Jan 06, 2008 at 10:15:16PM +0100, Berthold Cogel wrote:
> I did that and got this in 'make modules':
>
> CC [M] drivers/input/joydev.o
> CC [M] drivers/input/evdev.o
> drivers/input/evdev.c: In function 'evdev_do_ioctl':
> drivers/input/evdev.c:749: error: 'struct input_dev' has no
Hi,
2008/1/7, Anton Vorontsov <[EMAIL PROTECTED]>:
> On Mon, Jan 07, 2008 at 02:13:07AM +0300, Dmitry wrote:
> > Hi,
> >
> > 2008/1/7, Anton Vorontsov <[EMAIL PROTECTED]>:
> > > On Mon, Jan 07, 2008 at 01:15:32AM +0300, Dmitry wrote:
> > > [...]
> > > > > > + POWER_SUPPLY_ATTR(voltage_max),
>
On Mon, Jan 07, 2008 at 02:13:07AM +0300, Dmitry wrote:
> Hi,
>
> 2008/1/7, Anton Vorontsov <[EMAIL PROTECTED]>:
> > On Mon, Jan 07, 2008 at 01:15:32AM +0300, Dmitry wrote:
> > [...]
> > > > > + POWER_SUPPLY_ATTR(voltage_max),
> > > > > + POWER_SUPPLY_ATTR(voltage_min),
> > > >
> > > >
* Douglas Landgraf <[EMAIL PROTECTED]> wrote:
> Hi guys,
>
> Gregor, we have converted bttv driver to use vidioc_ioctl2 some
> days ago. Could you check and create your patch against v4l
> development tree? Bttv driver does not have anymore bttv_do_ioctl().
this is about the bttv driver
Subject: track and print last unloaded module in the oops trace
From: Arjan van de Ven <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Based on a suggestion from Andi:
In various cases, the unload of a module may leave some bad state around
that causes a
Subject: show being-loaded/being-unloaded indicator for modules in oopses
From: Arjan van de Ven <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
It's rather common that an oops/WARN_ON/BUG happens during the load or
unload of a module. Unfortunatly, it's not
Kernel is 2.6.24-rc6 + linuxpps patches, which are all to the serial
port driver.
2.6.23 was known stable. I haven't tested earlier 2.6.24 releases.
I think it happened once before; I got a black-screen lockup with
keyboard LEDs blinking, but that was with X running so I couldn't see a
console
Hi,
2008/1/7, Anton Vorontsov <[EMAIL PROTECTED]>:
> On Sun, Jan 06, 2008 at 03:30:16PM +0300, Dmitry Baryshkov wrote:
> > Support using VOLTAGE_* properties for apm calculations. It's pretty
> > dummy, but useful for batteries for which we can only get voltages.
>
> Here Signed-off-by: line is
Hi,
2008/1/7, Anton Vorontsov <[EMAIL PROTECTED]>:
> On Mon, Jan 07, 2008 at 01:15:32AM +0300, Dmitry wrote:
> [...]
> > > > + POWER_SUPPLY_ATTR(voltage_max),
> > > > + POWER_SUPPLY_ATTR(voltage_min),
> > >
> > > I'd suggest keep Documentation/power_supply_class.txt in sync
> > > wrt new
On Sun, Jan 06, 2008 at 03:30:16PM +0300, Dmitry Baryshkov wrote:
> Support using VOLTAGE_* properties for apm calculations. It's pretty
> dummy, but useful for batteries for which we can only get voltages.
Here Signed-off-by: line is missing, please provide one so I could
apply the patch.
I mean video_ioctl2 not vidioc_ioctl2, sorry.
Cheers,
Douglas
On Jan 6, 2008 8:53 PM, Douglas Landgraf <[EMAIL PROTECTED]> wrote:
> Hi guys,
>
> Gregor, we have converted bttv driver to use vidioc_ioctl2 some days ago.
> Could you check and create your patch against v4l development tree?
>
Hi guys,
Gregor, we have converted bttv driver to use vidioc_ioctl2 some days ago.
Could you check and create your patch against v4l development tree?
Bttv driver does not have anymore bttv_do_ioctl().
Cheers,
Douglas
On Jan 6, 2008 12:15 PM, Gregor Jasny <[EMAIL PROTECTED]> wrote:
> From:
On Sun, 06 Jan 2008 12:25:10 -0800
Linda Walsh <[EMAIL PROTECTED]> wrote:
> Robert Hancock wrote:
> >
> > If this is a Seagate, I believe that they don't have AAM enabled on
> > any of their newer drives (something about a lawsuit for patent
> > infringement on that feature, or something).
On Dec 10, 2007 8:08 AM, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
> Thanks for the report. Instead of applying your patch, I decided to
> better analyze the issue, fixing it with the proper solution. The issue
> is that vivi_register changes iminor, but this change were not properly
>
On Sunday, 6 of January 2008, Alan Stern wrote:
> On Sun, 6 Jan 2008, Rafael J. Wysocki wrote:
>
> > > No -- the whole idea here is to print an error message in the system
> > > log if a driver's resume method tries to call device_del(). Deadlock
> > > is unavoidable in this case, but at least
On Mon, Jan 07, 2008 at 01:15:32AM +0300, Dmitry wrote:
[...]
> > > + POWER_SUPPLY_ATTR(voltage_max),
> > > + POWER_SUPPLY_ATTR(voltage_min),
> >
> > I'd suggest keep Documentation/power_supply_class.txt in sync
> > wrt new properties, to distinct their meanings and usage.
> >
> > I assume
On Sun 2008-01-06 17:26:17, Alan Stern wrote:
> On Sun, 6 Jan 2008, Oliver Neukum wrote:
>
> > Am Sonntag 06 Januar 2008 schrieb Alan Stern:
> > > What about people who want to suspend to RAM instead of hibernating and
> > > _do_ want to unplug the USB device containing their root filesystem
> >
On Sun, 6 Jan 2008, Rafael J. Wysocki wrote:
> > No -- the whole idea here is to print an error message in the system
> > log if a driver's resume method tries to call device_del(). Deadlock
> > is unavoidable in this case, but at least we'll know which driver is
> > guilty.
>
> Still, if we
On Sunday, 6 of January 2008, Arjan van de Ven wrote:
> On Sun, 6 Jan 2008 10:55:01 +0100
> Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> >
> > * Mark Lord <[EMAIL PROTECTED]> wrote:
> >
> > > Rafael J. Wysocki wrote:
> > >> This message contains a list of some regressions from 2.6.23
> > >>
On Sunday, 6 of January 2008, Alan Stern wrote:
> On Sun, 6 Jan 2008, Rafael J. Wysocki wrote:
>
> > > Still, shouldn't we fail the removal of the device apart from giving the
> > > warning?
> >
> > Actually, having thought about it a bit more, I don't see the point in
> > preventing the removal
On Sun, 6 Jan 2008, Rafael J. Wysocki wrote:
> Still, our present approach doesn't seem to be correct overall. For example,
> I think we should prevent a suspend from happening while a device is being
> removed.
We could, however I don't think it's dangerous to allow it. The two
problems to
On Sun, 6 Jan 2008, Oliver Neukum wrote:
> Am Sonntag 06 Januar 2008 schrieb Alan Stern:
> > What about people who want to suspend to RAM instead of hibernating and
> > _do_ want to unplug the USB device containing their root filesystem
> > while the machine is asleep? In this case we will
On Sun, Jan 06, 2008 at 10:08:13PM +0100, Willy Tarreau wrote:
> On Sun, Jan 06, 2008 at 09:58:02PM +0200, Adrian Bunk wrote:
> > On Sun, Jan 06, 2008 at 08:10:44PM +0100, Willy Tarreau wrote:
> > > I, as an end user of ntpd, have been harrassed to use it to get an
> > > ntp bug reported "because
On Sun, 6 Jan 2008 10:55:01 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Mark Lord <[EMAIL PROTECTED]> wrote:
>
> > 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
On Sunday, 6 of January 2008, Alan Stern wrote:
> On Sun, 6 Jan 2008, Rafael J. Wysocki wrote:
>
> > On Sunday, 6 of January 2008, Alan Stern wrote:
>
> > Still, shouldn't we fail the removal of the device apart from giving the
> > warning?
>
> We can't. device_del() can't fail -- it returns
On Sun, 6 Jan 2008, Rafael J. Wysocki wrote:
> > Still, shouldn't we fail the removal of the device apart from giving the
> > warning?
>
> Actually, having thought about it a bit more, I don't see the point in
> preventing the removal of the device from the list in device_pm_remove() if
> we
It's been two weeks since rc6, but let's face it, with xmas and new years
(and birthdays) in between, there hasn't actually been a lot of working
days, and the incremental patch from -rc6 is about half the size of the
one from rc5->rc6.
And I'll be charitable and claim it's because it's all
On Sunday, 6 of January 2008, Rafael J. Wysocki wrote:
> On Sunday, 6 of January 2008, Rafael J. Wysocki wrote:
> > On Sunday, 6 of January 2008, Alan Stern wrote:
> > > On Sun, 6 Jan 2008, Rafael J. Wysocki wrote:
> > >
> > > > > If you can figure out a way to disable the warning in device_del()
Hi,
2008/1/6, Anton Vorontsov <[EMAIL PROTECTED]>:
> On Sun, Jan 06, 2008 at 03:27:18PM +0300, Dmitry Baryshkov wrote:
> > Add LiMn (one of the most common for small non-rechargable batteries)i
> > battery technology and voltage_min/_max properties support.
> >
> > Signed-off-by: Dmitry Baryshkov
On Sun, 6 Jan 2008, Rafael J. Wysocki wrote:
> On Sunday, 6 of January 2008, Alan Stern wrote:
> Still, shouldn't we fail the removal of the device apart from giving the
> warning?
We can't. device_del() can't fail -- it returns void. Besides, how
can a driver hope to deal with an
>
> Also, future of the linux codebase with Chinese comments in C or in
> ASM is kind of wired nightmare. Those, who cannot read actual source
> code (i.e. C) will not go too far.
$subject is purely about the kernel configuration - if that was not clear.
Sam
--
To unsubscribe from this
1 - 100 of 635 matches
Mail list logo
