Linus Torvalds writes:
On Sun, 4 Nov 2007, Bart Van Assche wrote:
Has it already been decided who will do this audit, and when this
audit will happen ? Has a target date been set when this audit
should be complete, or is the completion of this audit a
requirement for the
config DMAR_FLOPPY_WA
bool
depends on DMAR
...
In patch 8 the remaining PCI_* options and DMAR_FLOPPY_WA end in a
completely different place in the Kconfig file than the options moved
here.
Please keep options that belong together grouped together no matter
whether all
On 11/4/07, Linus Torvalds [EMAIL PROTECTED] wrote:
On Sun, 4 Nov 2007, Bart Van Assche wrote:
Has it already been decided who will do this audit, and when this
audit will happen ? Has a target date been set when this audit should
be complete, or is the completion of this audit a
If people set something like CFLAGS in their environment, they must
understand what that means, and it means that universally it will
influence your Makefile based builds. Yes, this means all of them and
even potentially the kernel build.
I definitely think the new kbuild CFLAGS
On Sun, 4 Nov 2007 12:31:38 -0500 (EST) Robert P. J. Day wrote:
given the recent patches to remove duplicated #include preprocessor
directives in source files, let it be known that there are a number of
them:
http://www.crashcourse.ca/wiki/index.php/Duplicate_include_files
help
On 11/4/07, Hugh Dickins [EMAIL PROTECTED] wrote:
Fair enough, that does match the documentation of size=0 better.
Though either way, someone who typos is going to get one kind of surprise
or another. Do you mind if we do it slightly differently, achieving the
same effect without a special
Hi Linus.
Please apply following fix.
Pull from:
ssh://master.kernel.org/pub/scm/linux/kernel/git/sam/fix-kbuild.git
Sam
From 69ee0b3522428a07ff1765446d631ecc7da6ae0f Mon Sep 17 00:00:00 2001
From: Sam Ravnborg [EMAIL PROTECTED]
Date: Sun, 4 Nov 2007 19:00:46 +0100
Subject: [PATCH]
(untested, needs an ack from maintainer)
Spotted by Nick [EMAIL PROTECTED], hopefully can explain the second trace in
http://bugzilla.kernel.org/show_bug.cgi?id=9180.
If -async_idle_cfqq != NULL cfq_put_async_queues() puts it IOPRIO_BE_NR times
in a loop. Fix this.
Signed-off-by: Oleg Nesterov
On Sun, 4 Nov 2007, Michael Marineau wrote:
On 11/4/07, Hugh Dickins [EMAIL PROTECTED] wrote:
Fair enough, that does match the documentation of size=0 better.
Though either way, someone who typos is going to get one kind of surprise
or another. Do you mind if we do it slightly differently,
Mikael Pettersson wrote:
The machine in question is a ca 1993 vintage Siemens 486 with
a Quadtel S3 / Phoenix BIOS from 1994, booting via grub-0.95-13
from Fedora Core 4.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
---
arch/x86/boot/compressed/head_32.S |5 +
1 files changed, 5
Adrian Bunk wrote:
On Sun, Nov 04, 2007 at 05:19:45PM +0100, Giacomo Catenazzi wrote:
Adrian Bunk wrote:
On Sun, Nov 04, 2007 at 02:31:33AM -0800, David Miller wrote:
From: Ingo Molnar [EMAIL PROTECTED]
Date: Sun, 4 Nov 2007 11:04:29 +0100
* Adrian Bunk [EMAIL PROTECTED] wrote:
I also have
On Sun, 4 Nov 2007, Randy Dunlap wrote:
On Sun, 4 Nov 2007 12:31:38 -0500 (EST) Robert P. J. Day wrote:
given the recent patches to remove duplicated #include preprocessor
directives in source files, let it be known that there are a number of
them:
Here the number of false positives is overhelming, but perhaps there
are also _real_ duplicated include somewhere in the bunch:
include/acpi/acpi_bus.h:
#include linux/device.h
include/asm-alpha/core_cia.h:
#include asm/io_trivial.h
include/asm-arm/atomic.h:
#include asm/system.h
On Sun, 4 Nov 2007 13:37:31 -0500 (EST) Robert P. J. Day wrote:
On Sun, 4 Nov 2007, Randy Dunlap wrote:
On Sun, 4 Nov 2007 12:31:38 -0500 (EST) Robert P. J. Day wrote:
given the recent patches to remove duplicated #include preprocessor
directives in source files, let it be known
On Sun, 4 Nov 2007, Marco Costalba wrote:
Here the number of false positives is overhelming, but perhaps there
are also _real_ duplicated include somewhere in the bunch:
include/acpi/acpi_bus.h:
#include linux/device.h
... snip header file output ...
i deliberately left out header files
On 11/4/07, Robert P. J. Day [EMAIL PROTECTED] wrote:
On Sun, 4 Nov 2007, Marco Costalba wrote:
Here the number of false positives is overhelming, but perhaps there
are also _real_ duplicated include somewhere in the bunch:
include/acpi/acpi_bus.h:
#include linux/device.h
... snip
Chris Snook [EMAIL PROTECTED] writes:
Marking TSC unstable due to TSCs unsynchronized
This is probably wrong. The TSC is on the northbridge on Barcelona
chips, so every core on the die should be in sync. Hypothetically you
could have different speed northbridges in different sockets, but
On Tue 2007-10-30 11:11:59, Dan Williams wrote:
On Tue, 2007-10-30 at 12:22 +0100, Pavel Machek wrote:
Hi!
You are listed as author of IS89C35 802.11bg WLAN USB Driver. That
driver has clear MODULE_LICENSE(GPL) tag, but not other notices.
Is it safe to assume whole sources are to be
Urk, -ENOTAWAKEYET. Try *THIS* patch, please.
-hpa
diff --git a/arch/x86/boot/pmjump.S b/arch/x86/boot/pmjump.S
index 2e55923..17e6dec 100644
--- a/arch/x86/boot/pmjump.S
+++ b/arch/x86/boot/pmjump.S
@@ -28,27 +28,37 @@
* void protected_mode_jump(u32 entrypoint, u32 bootparams);
*/
On Sun, Nov 04, 2007 at 08:12:02AM -0600, James Bottomley wrote:
On Wed, 2007-10-31 at 10:29 -0700, Greg KH wrote:
On Wed, Oct 31, 2007 at 09:38:04AM -0500, James Bottomley wrote:
On Tue, 2007-10-30 at 20:55 -0700, Greg KH wrote:
OSame problem here, if grp-is_visible is not set,
On Sun, 4 Nov 2007, Marco Costalba wrote:
On 11/4/07, Robert P. J. Day [EMAIL PROTECTED] wrote:
On Sun, 4 Nov 2007, Marco Costalba wrote:
Here the number of false positives is overhelming, but perhaps
there are also _real_ duplicated include somewhere in the bunch:
On Sun, Nov 04, 2007 at 01:37:31PM -0500, Robert P. J. Day wrote:
On Sun, 4 Nov 2007, Randy Dunlap wrote:
On Sun, 4 Nov 2007 12:31:38 -0500 (EST) Robert P. J. Day wrote:
given the recent patches to remove duplicated #include preprocessor
directives in source files, let it be
Hi Thomas,
I reviewed yor code and have ome remarks:
* All watchdog device drivers should work with seconds. Your driver works
with minutes. Please change to seconds.
* The misc_register function (which opens your driver towards user-space)
should be the last iregister-action you take into the
On Sun, 4 Nov 2007, Adrian Bunk wrote:
BTW: make includecheck already does the same...
oh ... well, then, let's just ignore the last few postings, shall we?
:-P
rday
--
Robert P. J. Day
Linux Consulting, Training and
Hi,
On Sun, Oct 28, 2007 at 09:40:41PM +0100, Krzysztof Halasa wrote:
Stefan Richter [EMAIL PROTECTED] writes:
Compile with the usual spell: gcc -Wall -O2 vt6307ohciver.c -o
vt6307ohciver
I also had to specify -lpci on Mandrake 10.1, -lpci -lz on Gentoo.
Of course you're right,
If no address is given for the W83697HF/HG watchdog IO port, stop looping
through possible locations when a watchdog device has been found.
Signed-off-by: Samuel Tardieu [EMAIL PROTECTED]
---
drivers/watchdog/w83697hf_wdt.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff
On Sun, 04 Nov 2007 10:29:34 -0800, H. Peter Anvin wrote:
Could you send me your /proc/cpuinfo?
Sure. It's a 100Mhz Intel 486 DX4:
processor : 0
vendor_id : GenuineIntel
cpu family : 4
model : 8
model name : 486 DX/4
stepping: 0
cache size : 0 KB
make includecheck does not work for me. Linux tree is from latest git.
bash-3.2$ pwd
/git/linux-2.6
bash-3.2$ make includecheck
find * \( -name SCCS -o -name BitKeeper -o -name .svn -o -name CVS -o
-name .pc -o -name .hg -o -name .git \) -prune -o \
-name '*.[hcS]' -type f -print
Mikael Pettersson wrote:
First patch didn't build. Second patch builds and boots Ok.
So this means the 486 DX4 has a buggy mov to %cr0?
Apparently.
-hpa
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
On 11/4/07, Marco Costalba [EMAIL PROTECTED] wrote:
make includecheck does not work for me. Linux tree is from latest git.
bash-3.2$ pwd
/git/linux-2.6
bash-3.2$ make includecheck
find * \( -name SCCS -o -name BitKeeper -o -name .svn -o -name CVS -o
BTW what's that 'BitKeeper' fossil here?
On Sun, 4 Nov 2007, Marco Costalba wrote:
On 11/4/07, Marco Costalba [EMAIL PROTECTED] wrote:
make includecheck does not work for me. Linux tree is from latest git.
bash-3.2$ pwd
/git/linux-2.6
bash-3.2$ make includecheck
find * \( -name SCCS -o -name BitKeeper -o -name .svn -o
On Sun, 4 Nov 2007 20:43:01 +0100 Marco Costalba wrote:
On 11/4/07, Marco Costalba [EMAIL PROTECTED] wrote:
make includecheck does not work for me. Linux tree is from latest git.
bash-3.2$ pwd
/git/linux-2.6
bash-3.2$ make includecheck
find * \( -name SCCS -o -name BitKeeper -o
From: Randy Dunlap [EMAIL PROTECTED]
Add 'includecheck' to the Static analyzers help list.
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
Makefile |1 +
1 file changed, 1 insertion(+)
--- linux-2.6.24-rc1-git13.orig/Makefile
+++ linux-2.6.24-rc1-git13/Makefile
@@ -1169,6 +1169,7 @@
On 11/3/07, Ahmed S. Darwish [EMAIL PROTECTED] wrote:
static int smk_open_load(struct inode *inode, struct file *file)
{
- return seq_open(file, load_seq_ops);
+ if ((file-f_flags O_ACCMODE) == O_RDONLY)
+ return seq_open(file, load_seq_ops);
+
+ if
On Sun, 2007-11-04 at 11:38 +0100, Ingo Molnar wrote:
I.e. keep the namespace functionality but use a modulo 1.000.000 base
for the PIDs so that it all looks nicer to the user. Minimal visibility
difference but maximum compatibility. (The resulting limits are
reasonable: 1 million tasks per
On Sat, 2007-11-03 at 12:48 -0700, Stephen Hemminger wrote:
The sizeof(struct device) is way too big, especially in the network device
case.
We want to support 1000's of device's and the change from class_device to
net_device has caused needless bloat.
sizeof(struct device) = 272
From: Donald E. Porter [EMAIL PROTECTED]
In the bulk page allocation/free routines in mm/page_alloc.c, the zone
lock is held across all iterations. For certain parallel workloads, I
have found that releasing and reacquiring the lock for each iteration
yields better performance, especially at
On Sun, 2007-11-04 at 19:52 +0100, Andi Kleen wrote:
Chris Snook [EMAIL PROTECTED] writes:
Marking TSC unstable due to TSCs unsynchronized
This is probably wrong. The TSC is on the northbridge on Barcelona
chips, so every core on the die should be in sync. Hypothetically you
could
Michael Tokarev wrote:
Justin Piszcz wrote:
On Sun, 4 Nov 2007, Michael Tokarev wrote:
[]
The next time you come across something like that, do a SysRq-T dump and
post that. It shows a stack trace of all processes - and in particular,
where exactly each task is stuck.
Yes I got it before
Hi Ted,
Below is the new version of a time-based UUID generator, in which I addressed
your feedback.
New features in this patch include
- a new /proc/sys/kernel/random/uuid_time_clockseq sysfs entry to read/write
the clock_seq value (to be able to be retained across system bootups)
- keep
During booting of last vanilla kernel I got:
Trying to free nonexistent resource...
This because of if ENABLE_APRICOT is on we do:
request_region(ioaddr,...)
if (checksum test failed)
goto out1;
dev-base_addr = ioaddr;//-here mistake
out1:
release_region(dev-base_addr,...)
Here patch which
On Sunday November 4, [EMAIL PROTECTED] wrote:
# ps auxww | grep D
USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND
root 273 0.0 0.0 0 0 ?DOct21 14:40 [pdflush]
root 274 0.0 0.0 0 0 ?DOct21 13:00 [pdflush]
On Mon, 5 Nov 2007, Neil Brown wrote:
On Sunday November 4, [EMAIL PROTECTED] wrote:
# ps auxww | grep D
USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND
root 273 0.0 0.0 0 0 ?DOct21 14:40 [pdflush]
root 274 0.0 0.0 0 0 ?
On Sun, 04 Nov 2007 11:41:58 -0800, H. Peter Anvin wrote:
Mikael Pettersson wrote:
First patch didn't build. Second patch builds and boots Ok.
So this means the 486 DX4 has a buggy mov to %cr0?
Apparently.
Maybe not. I had a look in Intel's SDM Vol3, and the
section switching to
Ow sorry... the warning:
BUG: scheduling while atomic: gnome-cups-icon/0x0101/3827
[c02aefe6] __sched_text_start+0x56/0x7c8
[c0130139] autoremove_wake_function+0x14/0x33
[c0119284] __wake_up_common+0x35/0x53
[c01197f6] __wake_up+0x32/0x43
[c02af847] wait_for_completion+0x6a/0x9f
From: Vegard Nossum [EMAIL PROTECTED]
This makes sure printk format strings contain no more than a single
line.
Signed-off-by: Vegard Nossum [EMAIL PROTECTED]
[the message was tweaked.]
Signed-off-by: OGAWA Hirofumi [EMAIL PROTECTED]
---
fs/fat/inode.c |6 ++
fs/fat/misc.c |5
On large partition, scanning the free clusters is very slow if users
doesn't use usefree option.
For optimizing it, this patch uses sb_breadahead() to read of FAT
sectors. On some user's 15GB partition, this patch improved it very
much (1min = 600ms).
The following is the result of 2GB partition
On 11/04/2007 11:05 PM, Felipe Dias wrote:
Ow sorry... the warning:
BUG: scheduling while atomic: gnome-cups-icon/0x0101/3827
[c02aefe6] __sched_text_start+0x56/0x7c8
[c0130139] autoremove_wake_function+0x14/0x33
[c0119284] __wake_up_common+0x35/0x53
[c01197f6] __wake_up+0x32/0x43
On 11/04/2007 11:16 PM, Jiri Slaby wrote:
On 11/04/2007 11:05 PM, Felipe Dias wrote:
Ow sorry... the warning:
BUG: scheduling while atomic: gnome-cups-icon/0x0101/3827
[c02aefe6] __sched_text_start+0x56/0x7c8
[c0130139] autoremove_wake_function+0x14/0x33
[c0119284]
Mikael Pettersson wrote:
Maybe not. I had a look in Intel's SDM Vol3, and the
section switching to protected mode specifies that
a move to %cr0 that sets PE should immediately be
followed by a far jmp or call. They write that random
failures can occur if other instructions exist between
[the
On Sun, Nov 04, 2007 at 12:01:55PM -0800, Randy Dunlap wrote:
From: Randy Dunlap [EMAIL PROTECTED]
Add 'includecheck' to the Static analyzers help list.
Thanks Randy - applied.
Sam
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
Hi all.
Please excuse me if this has already been answered. I'm not currently
subscribed to LKML.
I've just been preparing a new tux-on-ice release against Linus' current tree,
and encountered a failure to freeze pid 1 when seeking to resume, using an
initrd:
[ 74.192734] Freezing of tasks
Prism54: Convert mgmt_sem to the mutex API
Signed-off-by: Matthias Kaehlcke [EMAIL PROTECTED]
--
diff --git a/drivers/net/wireless/prism54/islpci_dev.c
b/drivers/net/wireless/prism54/islpci_dev.c
index 219dd65..dbb538c 100644
--- a/drivers/net/wireless/prism54/islpci_dev.c
+++
I change the algo, from bm to kmp and probably resolve. I will
make more tests and if error occour i post latter...
Thanks so much.
Felipe Dias
On 11/4/07, Jiri Slaby [EMAIL PROTECTED] wrote:
On 11/04/2007 11:16 PM, Jiri Slaby wrote:
On 11/04/2007 11:05 PM, Felipe Dias wrote:
Ow sorry...
Hi Linus; please pull:
git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup.git
for-linus
H. Peter Anvin (1):
x86 setup: correct booting on 486DX4
arch/x86/boot/pmjump.S | 32 +---
1 files changed, 21 insertions(+), 11 deletions(-)
[Full
Andreas Mohr [EMAIL PROTECTED] writes:
EEPROM dump (VT6306)
00: 00 11 06 66 45 55 56 E1 04 04 32 55 F8 00 A2 02
- GUID
10: A1 00 40 63 06 11 44 30 03 DF 40 80 00 20 00 73
- subs ID -
20: 3C 10 00 00 00 00 FF FF FF FF FF FF FF FF FF FF
Your VT6307
Mikael Pettersson [EMAIL PROTECTED] writes:
Maybe not. I had a look in Intel's SDM Vol3, and the
section switching to protected mode specifies that
a move to %cr0 that sets PE should immediately be
followed by a far jmp or call. They write that random
failures can occur if other instructions
Would it not be as simple as looking at the BIOS provided topology
information? If nr sockets 4 assume multiple board.
There is no reason multiple two socket boards couldn't be connected
with HT cables to form a larger system. Then you might end up
with a 4 socket system with multiple
Mikael Pettersson wrote:
On Sun, 04 Nov 2007 11:41:58 -0800, H. Peter Anvin wrote:
Mikael Pettersson wrote:
First patch didn't build. Second patch builds and boots Ok.
So this means the 486 DX4 has a buggy mov to %cr0?
Apparently.
Maybe not. I had a look in Intel's
Jeremy Fitzhardinge wrote:
Yes, that's what the spec says. I queried this a few months ago, but
hpa used his convincing voice and said that in practice it isn't
necessary; there are no known cpus which need this, and any that do
would cause other things to break. But I guess now we have the
On Sun, 4 Nov 2007, H. Peter Anvin wrote:
Apparently, the 486DX4 does not correctly serialize a mov to %cr0, so
we really do need the far jump immediately afterwards.
Hmm. I'm not sure I agree with the commit message.
This is documented behaviour on i386 and i486: instruction
On Thu, 25 Oct 2007 14:58:10 -0700, H. Peter Anvin [EMAIL PROTECTED] wrote:
J.A. Magallon wrote:
Hi...
I have some Quad-Opteron boxes with 4Gb memory and two of them are
running two different Linux distros.
Box one sees 4Gb of memory, but box two just sees 3.
Their mtrr setups
Robert P. J. Day wrote:
actually, one wonders if there's any value in keeping any references
to other version control systems such as subversion, SCCS, CVS,
mercurial, etc.
What do you mean by other? git doesn't have a monopoly, and the
kernel should support people using a reasonable set
* Mathieu Desnoyers ([EMAIL PROTECTED]) wrote:
* Mathieu Desnoyers ([EMAIL PROTECTED]) wrote:
* Mike Mason ([EMAIL PROTECTED]) wrote:
Hi Mathieu,
Are you aware of any working being done to allow multiple handlers to be
attached to a marker? Something like what kprobes allows.
On Sun, 4 Nov 2007, Linus Torvalds wrote:
I'm not entirely sure that it needs to be a long-jump, btw. I think any
regular branch is sufficient. You obviously *do* need to make the long
jump later (to reload %cs in protected mode), but I'm not sure it's needed
in that place. I forget the
On Sunday, 4 of November 2007, Nigel Cunningham wrote:
Hi all.
Please excuse me if this has already been answered. I'm not currently
subscribed to LKML.
I've just been preparing a new tux-on-ice release against Linus' current
tree, and encountered a failure to freeze pid 1 when seeking
Linus Torvalds wrote:
I'm not entirely sure that it needs to be a long-jump, btw. I think any
regular branch is sufficient. You obviously *do* need to make the long
jump later (to reload %cs in protected mode), but I'm not sure it's needed
in that place. I forget the exact rules (but they
Linus Torvalds wrote:
On Sun, 4 Nov 2007, H. Peter Anvin wrote:
Apparently, the 486DX4 does not correctly serialize a mov to %cr0, so
we really do need the far jump immediately afterwards.
Hmm. I'm not sure I agree with the commit message.
This is documented behaviour on i386
Am Sonntag, 4. November 2007 14:17:23 schrieben Sie:
On Sunday, 4 of November 2007, Romano Giannetti wrote:
On Fri, 2007-11-02 at 17:08 +0100, Rafael J. Wysocki wrote:
On Friday, 2 November 2007 00:14, Andrew Morton wrote:
On Mon, 29 Oct 2007 11:11:04 +0100
Hello!
[OOPS removed]
On Thursday 01 November 2007 08:19:02 Matthias Kaehlcke wrote:
Prism54: Convert mgmt_sem to the mutex API
Signed-off-by: Matthias Kaehlcke [EMAIL PROTECTED]
--
diff --git a/drivers/net/wireless/prism54/islpci_dev.c
b/drivers/net/wireless/prism54/islpci_dev.c
index 219dd65..dbb538c
Linus Torvalds wrote:
On Sun, 4 Nov 2007, Linus Torvalds wrote:
I'm not entirely sure that it needs to be a long-jump, btw. I think any
regular branch is sufficient. You obviously *do* need to make the long
jump later (to reload %cs in protected mode), but I'm not sure it's needed
in that
Maybe we could set a limit here. If the ATAPI device keeps DRQ=1 and
exceeds the limit, we consider it as HSM violation and have EH handle it.
On a DMA transfer its basically out of our control (and a PIO drain will
lock some controllers solid until power cycle), but on PIO we know we
never set
On Sun, 2007-11-04 at 14:49 -0500, Robert P. J. Day wrote:
[...]
actually, one wonders if there's any value in keeping any references
to other version control systems such as subversion, SCCS, CVS,
mercurial, etc.
Lots of people have their working trees in CVS, Subversion,
So it probably
Jeremy Fitzhardinge wrote:
Maybe not. I had a look in Intel's SDM Vol3, and the
section switching to protected mode specifies that
a move to %cr0 that sets PE should immediately be
followed by a far jmp or call.
Yes, that's what the spec says. I queried this a few months ago, but
hpa used his
Mikael, can you try this patch (rev 3) on your 486?
-hpa
diff --git a/arch/x86/boot/pmjump.S b/arch/x86/boot/pmjump.S
index 2e55923..d93a0c2 100644
--- a/arch/x86/boot/pmjump.S
+++ b/arch/x86/boot/pmjump.S
@@ -28,17 +28,21 @@
* void protected_mode_jump(u32 entrypoint, u32 bootparams);
Hi,
I'm trying to make the b43 driver work on an HP nx6325 with openSUSE 10.3
(64-bit). In short, it sort of works, but some things are a bit ugly.
The kernel is the current -git (approx. 2.6.24-rc1-git13) with the following
extra patches applied:
b43: Fix rfkill callback deadlock
b43: debugfs
On Sun, 4 Nov 2007, H. Peter Anvin wrote:
It's not an instruction-decoding issue at all (that's a 16- vs 32-bit issue,
which can only be changed by a ljmp). Apparently the 486DX4 mis-executes the
load to segment register, which is an EU function in that context. (And yes,
it's
On Monday, 5 of November 2007, Michael (rabenkind) Brandstetter wrote:
Am Sonntag, 4. November 2007 14:17:23 schrieben Sie:
On Sunday, 4 of November 2007, Romano Giannetti wrote:
On Fri, 2007-11-02 at 17:08 +0100, Rafael J. Wysocki wrote:
On Friday, 2 November 2007 00:14, Andrew Morton
Alan Cox wrote:
Maybe we could set a limit here. If the ATAPI device keeps DRQ=1 and
exceeds the limit, we consider it as HSM violation and have EH handle it.
On a DMA transfer its basically out of our control (and a PIO drain will
lock some controllers solid until power cycle),
Do such
Linus Torvalds wrote:
And Linux always did it correctly. I don't understand why you disagree,
and why Jeremy says
Having successfully broken the rules for a long time so far,
maybe we can get away with still cutting corners...
when the fact is, we used to *not* cut corners, we used to
Tejun Heo wrote:
However, there's still remaining issues. What does happen if you raise
allocation length and buffersize of the test program to 16? ie. Change
0x0a in cmd[] to 0x10 and increase buffer[10] to buffer[16].
Eek. The process hangs in D state for a good 60 seconds or so.
Caught a
H. Peter Anvin [EMAIL PROTECTED] writes:
Hi Linus; please pull:
git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup.git
for-linus
H. Peter Anvin (1):
x86 setup: correct booting on 486DX4
arch/x86/boot/pmjump.S | 32 +---
1 files
On Sun, 4 Nov 2007, H. Peter Anvin wrote:
Joy. Apparently the Intel documentation is actually self-inconsistent.
Section 9.9.1, page 9-17 does indeed have the far jump or call injunction,
whereas the sample code in section 9.10.1, page 9-27, line 180 does a near
jump!
See the older code.
H. Peter Anvin wrote:
Apparently because the Intel documentation disagrees with itself. That's
all.
Just to be perfectly clear: I much prefer the code with the short (near)
jump, because it keeps the code cleaner. I have sent a patch to Mikael
to test out.
-hpa
-
To
On Sun, 4 Nov 2007, Linus Torvalds wrote:
So I'd suggest having both jumps back-to-back, but realistically, the
first regular short jump is actually the one that is more important.
That's the one that really matters on i386/i486 class machines, and later
CPU's will generally do the
Rafael J. Wysocki wrote:
Hi,
I'm trying to make the b43 driver work on an HP nx6325 with openSUSE 10.3
(64-bit). In short, it sort of works, but some things are a bit ugly.
The kernel is the current -git (approx. 2.6.24-rc1-git13) with the following
extra patches applied:
b43: Fix
H. Peter Anvin [EMAIL PROTECTED] writes:
Linus Torvalds wrote:
And Linux always did it correctly. I don't understand why you disagree, and
why Jeremy says
Having successfully broken the rules for a long time so far,maybe
we can get away with still cutting corners...
when the
On Sat, Nov 03, 2007 at 06:43:06PM +0200, Ahmed S. Darwish wrote:
On Fri, Nov 02, 2007 at 01:50:55PM -0700, Casey Schaufler wrote:
Still to come:
- Final cleanup of smack_load_write and smack_cipso_write.
Hi All,
After agreeing with Casey on the load input grammar yesterday,
Hi Linus,
Please pull from 'drm-patches' branch of
master.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-patches
to receive the following updates:
drivers/char/drm/radeon_cp.c |5 +++--
drivers/char/drm/radeon_drv.h |1 +
drivers/char/drm/sis_mm.c |1 +
3 files
On Sun, 4 Nov 2007, Eric W. Biederman wrote:
I do seem to recall etherboot having a far jump in that spot and it
working on everything from a 386 on up. So I'm not certain if the
kind of jump matters. Still the kernel has a lot more exposure.
I actually suspect you could have just about
All,
I found in recent kernel that dev_() macros will print out duplicate
device name, which is a bit ugly. And this is true at least for platform_device.
The reason is due to dev_printk() printing out both dev_driver_string(dev)
and (dev)-bus_id, the latter is assigned with the same driver
On Sun, 04 Nov 2007 15:51:43 -0800, H. Peter Anvin wrote:
Mikael, can you try this patch (rev 3) on your 486?
It works fine.
/Mikael
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Thu, 2007-11-01 at 11:02 +0100, Cyrus Massoumi wrote:
Zhang, Yanmin wrote:
On Wed, 2007-10-31 at 17:57 +0800, Zhang, Yanmin wrote:
On Tue, 2007-10-30 at 16:36 +0800, Zhang, Yanmin wrote:
On Tue, 2007-10-30 at 08:26 +0100, Ingo Molnar wrote:
* Zhang, Yanmin [EMAIL PROTECTED] wrote:
On Sun, Nov 04, 2007 at 12:19:19PM +0100, Torsten Kaiser wrote:
On 11/2/07, David Chinner [EMAIL PROTECTED] wrote:
That's stalled waiting on the inode cluster buffer lock. That implies
that the inode lcuser is already being written out and the inode has
been redirtied during writeout.
On Sun, 4 Nov 2007, Jeff Garzik wrote:
The end to CD-ROM polling... newer SATA ATAPI hardware will emit
'asynchronous notification' events when media is changed. This adds
support.
I *really* didn't want to pull this.
Not only is it after the -rc1 period, but I also think you pushed
This series of six proposed patches fix the same kind of bug. The size
passing to memset is the size of a pointer i.e. sizeof(ptr), and normally
the right thing is sizeof(*ptr).
Li Zefan
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Hi Linus; please pull:
git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup.git
for-linus
H. Peter Anvin (2):
x86 setup: add a near jump to serialize %cr0 on 386/486
x86 setup: set %ebx == %ebp == %edi == 0 on protected mode entry
arch/x86/boot/pmjump.S | 12
Typical of me, I found another issue so I've just repushed the tree..
If you have or haven't pulled, please re-pull..
Please pull from 'drm-patches' branch of
master.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-patches
to receive the following updates:
drivers/char/drm/drmP.h
The size passing to memset is wrong. And here we can replace
kmalloc with kzalloc.
Signed-off-by Li Zefan [EMAIL PROTECTED]
---
arch/arm/common/uengine.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/common/uengine.c b/arch/arm/common/uengine.c
index
The size arguments passing to memset is wrong.
Signed-off-by Li Zefan [EMAIL PROTECTED]
---
drivers/video/ps3fb.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/ps3fb.c b/drivers/video/ps3fb.c
index b3463dd..75836aa 100644
--- a/drivers/video/ps3fb.c
+++
301 - 400 of 442 matches
Mail list logo
