From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on m68knommu.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-m68knommu/atomic.h2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-m68kno
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on m68k.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-m68k/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-m68k/atomic.h 2007
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on parisc.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-parisc/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-parisc/atomic.h
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on s390.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-s390/atomic.h 2007-08-13
03:14:13.0 -0400
+++ linux-2.6.23-rc3/include/asm-s390/atomic.h 2007
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on mips.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-mips/atomic.h 2007-08-13
03:14:13.0 -0400
+++ linux-2.6.23-rc3/include/asm-mips/atomic.h 2007
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on v850.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-v850/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-v850/atomic.h 2007
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on alpha.
Leave sparc-internal atomic24_t type alone.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-sparc/atomic.h2007-07-08
19:32:17.0 -0400
+++ linu
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on sparc64.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-sparc64/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-sparc64/atomic.h
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on sh64.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-sh64/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-sh64/atomic.h 2007
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on sh.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-sh/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-sh/atomic.h2007
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on x86_64.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-x86_64/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-x86_64/atomic.h
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on xtensa.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-xtensa/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-xtensa/atomic.h
On Mon, Aug 13, 2007 at 01:19:31PM +0100, Russell King wrote:
> On Mon, Aug 13, 2007 at 07:09:46AM -0400, Chris Snook wrote:
> > By popular demand, I've redone the patchset to include volatile casts in
> > atomic_set as well. I've also converted the macros to inline functions, to
Joe Perches wrote:
On Mon, 2007-08-13 at 02:49 -0400, Chris Snook wrote:
Actually, now that I've seen the format in the intro patch,
it would be simpler just to use this:
F: drivers/net/atl1/
ATL1 ETHERNET DRIVER
P: Jay Cliburn
M: [EMAIL PROTECTED]
P: Chris Snook
M
Luck, Tony wrote:
Use volatile consistently in atomic.h on ia64.
This will do weird things without Andreas Schwab's fix:
http://lkml.org/lkml/2007/8/10/410
The build is very noisy with the inline versions of atomic_{read,set}
and their 64-bit siblings. Here are the prime culprits (some of
Christoph Lameter wrote:
On Tue, 14 Aug 2007, Luck, Tony wrote:
I re-tried the macros ... the three warnings from mm/slub.c all result in
broken code ... and quite rightly too, they all come from code that does:
atomic_read(>nr_slabs)
But the nr_slabs field is an atomic_long_t, so we
Christoph Lameter wrote:
On Thu, 9 Aug 2007, Chris Snook wrote:
This patchset makes the behavior of atomic_read uniform by removing the
volatile keyword from all atomic_t and atomic64_t definitions that currently
have it, and instead explicitly casts the variable as volatile in
atomic_read
Christoph Lameter wrote:
On Mon, 13 Aug 2007, Chris Snook wrote:
@@ -38,7 +45,7 @@
Next, we have:
- #define atomic_read(v) ((v)->counter)
+ #define atomic_read(v) (*(volatile int *)&(v)->counter)
which simply reads the current value of the counter.
vola
Satyam Sharma wrote:
On Tue, 14 Aug 2007, Christoph Lameter wrote:
On Thu, 9 Aug 2007, Chris Snook wrote:
This patchset makes the behavior of atomic_read uniform by removing the
volatile keyword from all atomic_t and atomic64_t definitions that currently
have it, and instead explicitly
Christoph Lameter wrote:
On Tue, 14 Aug 2007, Chris Snook wrote:
volatile means that there is some vague notion of "read it now". But that
really does not exist. Instead we control visibility via barriers (smp_wmb,
smp_rmb). Would it not be best to not have volatile at all in atomic
Herbert Xu wrote:
Chris Snook <[EMAIL PROTECTED]> wrote:
Because atomic operations are generally used for synchronization, which requires
volatile behavior. Most such codepaths currently use an inefficient barrier().
Some forget to and we get bugs, because people assume that atomi
Herbert Xu wrote:
Andi Kleen <[EMAIL PROTECTED]> wrote:
My config with march=pentium-m and gcc (GCC) 4.1.2 (Gentoo 4.1.2):
textdata bss dec hex filename
3434150 249176 176128 3859454 3ae3fe atomic_normal/vmlinux
3435308 249176 176128 3860612 3ae884
In the fallout from the recent atomic_t volatility discussions, patches
have been posted to moot the compiler correctness issues by implementing
atomic[64]_[read|set] in inline assembly on powerpc, i386, and x86_64.
While I personally don't consider such implementations to be critically
Eduard-Gabriel Munteanu wrote:
*This message was transferred with a trial version of CommuniGate(r) Pro*
Currently, the kernel has the following properties:
1) initramfs can be used to boot the system. We don't need any
predefined /dev entries.
2) udev can be started from the initramfs to
Jan Engelhardt wrote:
Hi,
this more of an informational question. So:
kernel version is 2.6.22.1 on i686
/proc/uptime
9917.81 9140.90 (2h45m)
/proc/cpuinfo:
CPU0
0:282 IO-APIC-edge timer
this is kinda neat, I expected much more interrupts than just 282 since
Jan Engelhardt wrote:
On Aug 6 2007 09:47, Chris Snook wrote:
this more of an informational question. So:
kernel version is 2.6.22.1 on i686
/proc/uptime 9917.81 9140.90 (2h45m)
/proc/cpuinfo:
CPU0
0:282 IO-APIC-edge timer
this is kinda neat, I expected much more
Jerry Jiang wrote:
Is there some feedback on this point ?
Thank you
./Jerry
On Sun, 1 Jul 2007 08:49:37 -0400 (EDT)
"Robert P. J. Day" <[EMAIL PROTECTED]> wrote:
prompted by the earlier post on "volatile"s, is there a reason that
most atomic_t typedefs use volatile int's, while the rest
Chris Friesen wrote:
Chris Snook wrote:
If your architecture doesn't support SMP, the volatile keyword doesn't
do anything except add a useless memory fetch.
I was under the impression that there were other cases as well
(interrupt handlers, for instance) where the value could be modified
Chris Friesen wrote:
Chris Snook wrote:
But if you're not using SMP, the only way you get a race condition is
if your compiler is reordering instructions that have side effects
which are invisible to the compiler. This can happen with MMIO
registers, but it's not an issue with an atomic_t
Chris Friesen wrote:
Chris Snook wrote:
That's why we define atomic_read like so:
#define atomic_read(v) ((v)->counter)
This avoids the aliasing problem, because the compiler must
de-reference the pointer every time, which requires a memory fetch.
Can you guaran
paul wrote:
Since 2-3 month I have some random data corruption on my Linux server, after
checking disks independently (i'm using raid1on 2 sata disk, the problem is
the same w/o raid) and memory, hardware simce to be out of cause...
Here is my problem:
=> head --bytes=300m /dev/urandom >
Zan Lynx wrote:
On Tue, 2007-08-07 at 15:38 -0600, Chris Friesen wrote:
Chris Snook wrote:
That's why we define atomic_read like so:
#define atomic_read(v) ((v)->counter)
This avoids the aliasing problem, because the compiler must de-reference
the pointer every time, wh
Jerry Jiang wrote:
On Tue, 07 Aug 2007 16:32:23 -0400
Chris Snook <[EMAIL PROTECTED]> wrote:
It seems like this would fall more into the case of the arch providing
guarantees when using locked/atomic access rather than anything
SMP-related, no?.
But if you're not using SMP, the only w
Chris Friesen wrote:
Chris Snook wrote:
This is not a problem, since indirect references will cause the CPU to
fetch the data from memory/cache anyway.
Isn't Zan's sample code (that shows the problem) already using indirect
references?
Yeah, I misinterpreted his conclusion. I thought
Yishai Hadas wrote:
Hi List,
I'm looking for any mechanism in a multi-threaded process to monitor the
health of its running threads - or by a specific monitor thread or by
any other mechanism.
It includes the following aspects:
1) Threads are running and not stuck on any lock.
If
From: Chris Snook <[EMAIL PROTECTED]>
Unambiguously document the fact that atomic_read() and atomic_set()
do not imply any ordering or memory access, and that callers are
obligated to explicitly invoke barriers as needed to ensure that
changes to atomic variables are visible in all co
Venkat Subbiah wrote:
Most of the load in my system is triggered by a single ethernet IRQ.
Essentially the IRQ schedules a tasklet and most of the work is done in the
taskelet which is scheduled in the IRQ. From what I read looks like the
tasklet would be executed on the same CPU on which it was
Jesse Barnes wrote:
I just narrowed down a weird problem where I was losing more than 50% of
my vblank interrupts to what seems to be the hires timers patch. Stock
2.6.23-rc5 works fine, but the latest (171) kernel from rawhide drops
most of my interrupts unless I also have another interrupt
From: Chris Snook <[EMAIL PROTECTED]>
The volatile keyword has already been removed from the declaration of atomic_t
on x86_64. For consistency, remove it from atomic64_t as well.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- a/include/asm-x86_64/atomic.h 2007
Venkat Subbiah wrote:
Since most network devices have a single status register for both
receiver and transmit (and errors and the like), which needs a lock to
protect access, you will likely end up with serious thrashing of moving
the lock between cpus.
Any ways to measure the trashing of
from the
declaration of atomic64_t. The following patch fixes that inconsistency,
without delving into anything more controversial.
From: Chris Snook <[EMAIL PROTECTED]>
The volatile keyword has already been removed from the declaration of atomic_t
on x86_64. For consistency, remove i
Justin Piszcz wrote:
Kernel: 2.6.23-rc8 (older kernels do this as well)
When running the following command:
/usr/bin/time /usr/sbin/bonnie++ -d /x/test -s 16384 -m p34 -n
16:10:16:64
It hangs unless I increase various parameters md/raid such as the
stripe_cache_size etc..
# ps auxww |
Giuliano Gagliardi wrote:
Hello,
I have a server that has to switch to different user ids, but because it does
other complex things, I would rather not have it run as root.
Well, it's probably going to have to *start* as root, or use something like
sudo. It's probably easiest to have it
Pavel Machek wrote:
Hi!
I've found that gbit vs. 100mbit power consumption difference is about
1W -- pretty significant. (Maybe powertop should include it in the
tips section? :).
Energy Star people insist that machines should switch down to 100mbit
when network is idle, and I guess that makes
Lukas Hejtmanek wrote:
Hello,
is it expected that application sending 8900bytes datagram through 10Gbps NIC
utilizes CPU to 100% and similarly the receiver also utilizes CPU to 100%.
Is it something wrong or this is quite OK?
(The box is dual single core Opteron 2.4GHz with Myricom 10GE NIC.)
David Madore wrote:
On Mon, Sep 17, 2007 at 11:11:52AM -0700, Jeremy Fitzhardinge wrote:
Boot memtest86 for a little while before booting the kernel? And if you
haven't already run it for a while, then that would be your first step
anyway.
Indeed, that does the trick, thanks for the
Zurk Tech wrote:
Hi guys,
I have a tyan s3992 h2000 with single barcelona amd quad core cpu (the
other cpu socket is empty). cat /proc/cpuinfo shows amd quad core
processor
but core : 1ive compiled the kernel from scratch with smp and
amd64 + the numa stuff. i also tried debian etchs amd64
Don Porter wrote:
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
ciol wrote:
Hi, I'd like to ask you a few questions:
* Do you like the way linux distributions integrate the kernel?
* Wouldn't you prefer they ship with the stable and still maintained
2.6.16.X, while providing optionally the latest kernel for those who
want or just have a new hardware?
*
Benny Halevy wrote:
Greetings,
I would like to hear peoples opinion about the indentation convention
described below that I personally found the most practical with
several different editors.
The gist of it is that tabs should be used for nesting, not for decoration.
Indent your code with as
ciol wrote:
Chris Snook wrote:
Why are you asking the developers? We do this for the sake of the users.
The kernel is the software of the developers.
The kernel is a technology. A distribution is a product. When decisions about
technology and decisions about products are made
Yoav Artzi wrote:
According to my knowledge the PAGE_SIZE on 32bit architectures in 4KB.
Logically, the PAGE_SIZE on 64bit architectures should be 8KB. That's at
least the way I understand it. However, looking at the kernel code of
x86_64, I see the PAGE_SIZE is 4KB.
Can anyone explain to
Florian Boelstler wrote:
While running that test driver a delay of about 10ms _exactly_ occurs
every 10 minutes.
This is precisely the sort of thing that BIOS/firmware-level SMI handlers do,
particularly those that have monitoring or management features. Try to
determine if the kernel is
[EMAIL PROTECTED] wrote:
Linux version 2.4.9-e.38smp ([EMAIL PROTECTED]) (gcc
version 2.96 2731 (Red Hat Linux 7.2 2.96-124.7.2)) #1 SMP Wed Feb
11 00:09:01 EST 2004
Ancient vendor kernels are very out of scope for this mailing list. The
following links may be useful:
Konstantin Kalin wrote:
P.S. It's simple to add DEV_HAS_CORRECT_MACADDR to pci_device_tlb for
these types of Ethernet. But I think it's not right decision because it
would break older revisions of these models.
Any reason you can't distinguish based on PCI ID?
-- Chris
-
To
From: Chris Snook <[EMAIL PROTECTED]>
Most of types_32.h and types_64.h are the same. Merge the common definitions
into types.h, keeping the differences in their own files. Also #error if
types_{32,64}.h is included directly. Tested with allmodconfig on x86_64.
Signed-off-by: Chris
From: Chris Snook <[EMAIL PROTECTED]>
Merge mmu_32.h and mmu_64.h into mmu.h.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
diff -Nurp a/include/asm-x86/mmu_32.h b/include/asm-x86/mmu_32.h
--- a/include/asm-x86/mmu_32.h 2007-10-20 02:42:24.0 -0400
+++ b/include/asm-x86/mm
From: Chris Snook <[EMAIL PROTECTED]>
Unify x86 a.out_32.h and a.out_64.h
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
diff -Nurp a/include/asm-x86/a.out_32.h b/include/asm-x86/a.out_32.h
--- a/include/asm-x86/a.out_32.h2007-10-20 06:20:01.0 -0400
+++ b/inc
From: Chris Snook <[EMAIL PROTECTED]>
Unify x86 div64.h headers.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
diff -Nurp a/include/asm-x86/div64_32.h b/include/asm-x86/div64_32.h
--- a/include/asm-x86/div64_32.h2007-10-20 07:33:53.0 -0400
+++ b/include/asm-x8
Latchesar Ionkov wrote:
Sample ramfs file server that uses the in-kernel 9P file server support.
This code is for reference only.
Reference code generally goes in Documentation/
-- Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Zurk Tech wrote:
dmesg (new) with disabled GART error reporting if anyone wants to
compare to previous dmesg with GART error reporting :
A few unrelated observations about Barcelona support...
Marking TSC unstable due to TSCs unsynchronized
This is probably wrong. The TSC is on the
The full text of the preceding comment explains the need:
/*
* The atl1c chip can DMA to 64-bit addresses, but it uses a single
* shared register for the high 32 bits, so only a single, aligned,
* 4 GB physical address range can be used at a time.
*
* Supporting 64-bit DMA on this hardware is
On Tue, Nov 17, 2020 at 1:01 AM Heiner Kallweit wrote:
>
> Am 17.11.2020 um 08:43 schrieb Chris Snook:
> > The full text of the preceding comment explains the need:
> >
> > /*
> > * The atl1c chip can DMA to 64-bit addresses, but it uses a single
> > * shar
Andre Noll wrote:
we are experiencing massive performance problems with two of our
Linux servers that contain 3ware controllers on a Tyan mainboard and
a couple of 1T disks.
During the daily cron job that uses rsync to sync a 500G file system
from another machine to the raid on the 3ware
Vineet Gupta wrote:
I'm trying to implement atomic ops for a CPU which has no inherent
support for Read-Modify-Write Ops. Instead of using a global spin lock
which protects all the atomic APIs, I want to use a spin lock per
instance of atomic_t.
What operations are you using to implement
Muhammad Nowbuth wrote:
Hi all,
Could anyone give some ideas of future pending works which are needed
on the linux kernel?
http://kernelnewbies.org/KernelHacking
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Gene Heskett wrote:
Greetings all;
This line showed up in my log a couple of hours ago, several minutes removed
from anything else I was doing at the time:
rarian-sk-get-c[31855]: segfault at eip 00b7c153 esp bf9ddf0c error 4
The system acts and feels normal.
Does anyone have a
Yinghai Lu wrote:
why not rename relocs.c to relocs_32.c?
Because we're trying to get rid of all the _32 and _64 files?
-- Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Yinghai Lu wrote:
On Jan 31, 2008 12:33 AM, Chris Snook <[EMAIL PROTECTED]> wrote:
Yinghai Lu wrote:
why not rename relocs.c to relocs_32.c?
Because we're trying to get rid of all the _32 and _64 files?
but that file is not need for x86_64
Which means there's no conflict with any
Lars Noschinski wrote:
Hello!
For an university project, we had to write a toy filesystem (ext2-like),
for which I would like to implement sparse file support. For this, I
digged through the ext2 source code; but I could not find the point,
where ext2 detects holes.
As far as I can see from
veerasena reddy wrote:
I have a requirement where i need to execute a user process even when
the kernel is utilizing 100% of CPU time.
In the realtime kernel, hardware interrupt handlers are prioritized
threads, so you can give the userspace process a higher realtime priority.
--
Gene Heskett wrote:
Greetings;
I just rebooted to a new config of 2.6.24, basically trying to strip out the
building of modules I don't use. And I enabled a couple of checks that
weren't checked in the kernel-hacking menu. .config posted on request.
Now the messages log is being spammed
Jay Cliburn wrote:
On Tue, 22 Jan 2008 04:56:11 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
From: Jay Cliburn <[EMAIL PROTECTED]>
Update initialization parameters to match the current vendor driver
version 1.2.40.2.
[...]
ACK without any better knowledge... but
Al Boldi wrote:
Greetings!
data=ordered mode has proven reliable over the years, and it does this by
ordering filedata flushes before metadata flushes. But this sometimes
causes contention in the order of a 10x slowdown for certain apps, either
due to the misuse of fsync or due to inherent
this one any better?
This satisfies me.
Acked-by: Chris Snook <[EMAIL PROTECTED]>
From df475e2eea401f9dc18ca23dab538b99fb9e710c Mon Sep 17 00:00:00 2001
From: Jay Cliburn <[EMAIL PROTECTED]>
Date: Wed, 23 Jan 2008 21:36:36 -0600
Subject: [PATCH] atl1: simplify tx packet descriptor
The tr
Martin Knoblauch wrote:
Hi,
currently I am tracking down an "interesting" effect when writing to a
Solars-10/Sparc based server. The server exports two filesystems. One UFS,
one VXFS. The filesystems are mounted NFS3/TCP, no special options. Linux
kernel in question is 2.6.24-rc6, but it
While pondering ways to optimize I/O and swapping on large NUMA machines, I
noticed that the numa_node field in struct device isn't actually used anywhere.
We just have a couple dozen lines of code to conditionally create a sysfs file
that will always return -1. Is anyone even working on code
CTED]>
Cc: Chris Snook <[EMAIL PROTECTED]>
Acked-By: Chris Snook <[EMAIL PROTECTED]>
-
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
H. Peter Anvin wrote:
NOTE: This patch uses a bc(1) script to compute the appropriate
constants.
Perhaps dc would be more appropriate? That's included in busybox.
-- Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Ben Crowhurst wrote:
Has Objective-C ever been considered for kernel development?
No. Kernel programming requires what is essentially assembly language with a
lot of syntactic sugar, which C provides. Higher-level languages abstract away
too much detail to be suitable for the sort of
Joe Perches wrote:
drivers/net/atl1/atl1_hw.c |2 +-
drivers/net/atl1/atl1_main.c |2 +-
The atl1 code will be heavily reworked in the 2.6.25 merge window, so this may
cause headaches. Please remove these chunks before merging.
The spelling
Dhaval Giani wrote:
I am getting the following oops on bootup on 2.6.25-rc1
...
I am booting using kexec with maxcpus=1. It does not have any problems
with maxcpus=2 or higher.
Sounds like another (the same?) kexec cpu numbering bug. Can you
post/link the entire dmesg from both a cold boot
Stephen Rothwell wrote:
Hi all,
Initial status can be seen here
http://kisskb.ellerman.id.au/kisskb/branch/9/ (I hope to make a better
URL soon). Suggestions for more compiler/config combinations are
welcome, but we can't necessarily commit to fulfilling all you
wishes. :-)
i386
Tony Breeds wrote:
On Thu, Feb 14, 2008 at 08:24:27PM -0500, Chris Snook wrote:
Stephen Rothwell wrote:
Hi all,
Initial status can be seen here
http://kisskb.ellerman.id.au/kisskb/branch/9/ (I hope to make a better
URL soon). Suggestions for more compiler/config combinations are
welcome
From: Chris Snook <[EMAIL PROTECTED]>
Make LKDTM depend on BLOCK to prevent build failures with certain configs.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index a370fe8..24b327c 100644
--- a/lib/Kconfig.debug
+++ b/lib/K
From: Chris Snook <[EMAIL PROTECTED]>
Make MARKERS depend on MODULES to prevent build failures with certain configs.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
diff --git a/init/Kconfig b/init/Kconfig
index dcef8b5..933df15 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -
On Fri, Jun 21, 2019 at 11:33 AM Joe Perches wrote:
>
> On Fri, 2019-06-21 at 13:12 -0500, Bjorn Helgaas wrote:
> > On Fri, Jun 21, 2019 at 12:27 PM Joe Perches wrote:
> []
> > > Subsystem specific local PCI #defines without generic
> > > naming is poor style and makes treewide grep and
> > >
"Qualcomm Atheros Inc., ");
> -MODULE_DESCRIPTION("Qualcom Atheros 100/1000M Ethernet Network Driver");
> +MODULE_DESCRIPTION("Qualcomm Atheros 100/1000M Ethernet Network Driver");
> MODULE_LICENSE("GPL");
> MODULE_VERSION(ATL1C_DRV_VERSION)
401 - 488 of 488 matches
Mail list logo
