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 way
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/") and
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 inte
>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 US
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) V
> [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
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 so
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 PROTECTED]
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 expressio
> [ 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 d
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 o
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(&dev->list));
So move the list_del_init to rfcomm_dev_del
2) The rfcomm_dev_del could be called from diffrent path
(rfcomm_tty_hangup/rfcomm_dev_
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 work
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.
--
tejun
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 e
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, which
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 i
* 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;
> >
> > Ar
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 12:43
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 all
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 som
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 i
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 tristate
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 list:
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
[ 5446.8350
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. Ker
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. Bootloade
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 the
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 d
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
> index
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 exclusion,
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 sup
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 cha
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 m
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 "unsubscri
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 u
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 /sys/devices/.../power/wake
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 th
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 /sys/devices/.../power/
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 d879619..7f8
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
---
--- hackbe
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 is
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 oops/WARN_ON/BUG
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 `kvmap_vmemmap'
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 lis
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
> > variable
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 pa
[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 th
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 th
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() and
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 V
(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 Toshiba
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 m
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),
> > > >
> > > > I'd
* 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 i
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 ker
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 a
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 oo
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 mi
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 p
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.
Thanks
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?
> Bt
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: G
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). Quite
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
> retur
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 w
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 d
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
> > >> report
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 avo
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 _know_
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 b
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 t
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 vo
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 allo
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 st
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 unregistrat
>
> 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 li
1 - 100 of 334 matches
Mail list logo
