| From | Subject | Date |
|---|---|---|
| Nick Piggin | Re: General slowness with using 64Gb HIGHMEM option on 32-bi...
If you have a gcc that can compile 64-bit code, then I found it was as
simple as doing a 'make ARCH=x86_64' and building the kernel with 32-bit
program support.
-
| Sep 27, 11:22 pm 2007 |
| Nick Piggin | Re: [PATCH 05/12] mm: trylock_page
I have such a thing queued too, for the lock bitops patches for when 2.6.24
opens, Andrew promises me :).
I guess they should be identical, except I don't like doing trylock_page in
place of SetPageLocked, for memory ordering performance and aesthetic
reasons... I've got an init_page_locked (or set_page_locked... I can't
remember, the patch is at home).
Fine idea to lockdep the page lock, anyway. Does it show up any of the
buffered write deadlock possibilities? :)
buffer lock is another nota...
| Sep 27, 11:11 pm 2007 |
| Anna Csilla | Anna, Csilla
Szia!
Oszinte leszek! En egy spam vagyok ... igen megint egy levelszemet.
Mar akinek szemet ... ha ugy erzed irj vissza, kuldj el a fenebe ...
de kenyszert erzek hogy tudassam veled az alabbiakat:
Van egy oldal ahol perverz szexfilmek vannak igen perverzek ...
sot meg allatok is felbukkannak itt ott egy ket filmben ...
ha erdekel klikk ra:
http://xxx.bnh.hu
ja igen es ha hiszed hanem tenyleg vannak fenn filmek rollam.
Van egy par jo jatek is ami magyar nyelvu es erdekelhet:
MAGY...
| Sep 27, 9:52 am 2007 |
| Neil Brown | Re: [patch 2/2] VFS: allow filesystem to override mknod capa...
I must admit that I don't feel very comfortable about this. I wonder
how many more flags we might be tempted to add to allow
user-controlled filesystems to do interesting things. Somehow I doubt
this will be the last, so we should be very careful allowing it to be
the first (or is it the second already?)
A more concrete comment on the patch: Is it really necessary to
introduce IS_MNT_NODEV?? Why not simply test both the flags
(MS_MKNOD_NOCAP and MNT_NODEV) before allowing the mknod? That wou...
| Sep 27, 10:40 pm 2007 |
| linux | 2.6.23-rc8 network problem. Mem leak? ip1000a?
Uniprocessor Althlon 64, 64-bit kernel, 2G ECC RAM,
2.6.23-rc8 + linuxpps (5.0.0) + ip1000a driver.
(patch from http://marc.info/?l=linux-netdev&m=118980588419882)
After a few hours of operation, ntp loses the ability to send packets.
sendto() returns -EAGAIN to everything, including the 24-byte UDP packet
that is a response to ntpq.
-EAGAIN on a sendto() makes me think of memory problems, so here's
meminfo at the time:
### FAILED state ###
# cat /proc/meminfo
MemTotal: 2059384 kB
...
| Sep 27, 10:06 pm 2007 |
| Dave Airlie | [PATCH] i915: make vbl interrupts work properly on i965g/gm
Hi Linus,
The attached patch is to fix a bug reported on 965gm chipsets (lots of new
laptops), I think distros will all have to patch this in to fix it, so can
we get it into the 2.6.23 final?
(Otherwise I'll wait until stable..)
Dave.
| Sep 27, 10:05 pm 2007 |
| Jesse Barnes | Re: [PATCH] i915: make vbl interrupts work properly on i965g...
Without this patch, my 965GM drops vblank interrupts, so I'd really like to
see it upstream ASAP too.
Acked-by: Jesse Barnes <jesse.barnes@intel.com>
-
| Sep 27, 10:09 pm 2007 |
| Benjamin Herrenschmidt | iwl4965 and driver merging policy
Hi !
Just a little question in the light of the discussion we had at Kernel
Summit about merging drivers upstream (and here, I strongly agree with
Linus, hence my message).
I just got that new T61 laptop which happens to have an iwl4xxx chip.
The distro I installed on it (ubuntu) has a driver for it. I suspect
others do too and most users get it from some random external tree and
use it.
Thus my question, why are we about to release 2.6.23 without it ?
It doesn't seem to pull any depedency ...
| Sep 27, 9:39 pm 2007 |
| John W. Linville | Re: iwl4965 and driver merging policy
You must not have been watching me SPAM netdev for the past two
It is queued for 2.6.24. I'm not even sure it was originally posted
in time for the 2.6.23 merge window, but even if it was there was
a lot of opposition to merging it until fairly recently. In fact,
I'm sure there are still some wireless developers that are less than
happy about merging it now.
Anyway, coming soon to a kernel near you...
John
--
John W. Linville
linville@tuxdriver.com
-
| Sep 27, 10:30 pm 2007 |
| Benjamin Herrenschmidt | Re: iwl4965 and driver merging policy
Allright, thanks. I was mostly trying to figure out where we standed
with this whole idea that driver additions were not necessarily
constrainted by the merge window (which I think is fair to do) and this
looked like a good example to pick since it affects my new laptop :-)
Out of curiosity, what's the main source of opposition ? Since it's
being shipped by distro or built out of tree by most users -anyway-, I
think it's pretty clear that we'd be better off having it merged asap
rather than try...
| Sep 27, 11:15 pm 2007 |
| Theodore Tso | Re: iwl4965 and driver merging policy
Well, pulling in iwlwifi would require also pulling in the mac80211
subsystem, so it's not quite that simple (although I'm not sure what's
holding back that going into the kernel.)
I had no problem building my personal production kernel by taking
2.6.23-rc8, and doing a git pull from the everything branch in John
Linville's wireless-dev git tree. It's probably too late to pull it
for 2.6.23-rc8 (although if Linux wanted to do it it's only one git
pull command away :-), but it would be really nic...
| Sep 27, 10:47 pm 2007 |
| Benjamin Herrenschmidt | Re: iwl4965 and driver merging policy
I though that was already in 2.6.23 ... my bad if I missed something
Yes, I agree -rc8 seems to be a tad too late, I'm just surprised we
didn't get it in earlier though since it seems it's been around and
useable for some time.
Cheers,
Ben.
-
| Sep 27, 11:07 pm 2007 |
| akepner | [4/4] mthca: allow setting "dmabarrier" on user-allocated me...
Use the dma_flags_set_dmabarrier() interface to allow a "dmabarrier"
attribute to be associated with user-allocated memory. (For now,
it's only implemented for mthca.)
Signed-off-by: Arthur Kepner <akepner@sgi.com>
---
drivers/infiniband/core/umem.c | 7 +++++--
drivers/infiniband/hw/amso1100/c2_provider.c | 2 +-
drivers/infiniband/hw/cxgb3/iwch_provider.c | 2 +-
drivers/infiniband/hw/ehca/ehca_mrmw.c | 2 +-
drivers/infiniband/hw/ipath/ipath_mr.c ...
| Sep 27, 9:13 pm 2007 |
| akepner | [3/4] dma: document dma_flags_set_dmabarrier()
Document dma_flags_set_dmabarrier().
Signed-off-by: Arthur Kepner <akepner@sgi.com>
---
DMA-API.txt | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+)
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index cc7a8c3..5fc0bba 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -544,3 +544,29 @@ size is the size (and should be a page-sized multiple).
The return value will be either a pointer to the processor virtual
address of...
| Sep 27, 9:13 pm 2007 |
| Grant Grundler | Re: [3/4] dma: document dma_flags_set_dmabarrier()
This looks really good!
thanks,
grant
-
| Sep 27, 11:33 pm 2007 |
| akepner | [2/4] dma: redefine dma_flags_set_dmabarrier() for sn-ia64
define dma_flags_set_dmabarrier() for sn-ia64 - it "borrows"
bits from the direction argument (renamed "flags") to the
dma_map_* routines to pass an additional "dmabarrier" attribute.
Also define routines to retrieve the original direction and
attribute from "flags".
Signed-off-by: Arthur Kepner <akepner@sgi.com>
---
arch/ia64/sn/pci/pci_dma.c | 35 ++++++++++++++++++++++++++---------
include/asm-ia64/sn/io.h | 24 ++++++++++++++++++++++++
2 files changed, 50 insertions(+), 9 del...
| Sep 27, 9:12 pm 2007 |
| akepner | [1/4] dma: add dma_flags_set_dmabarrier() to dma interface
Introduce the dma_flags_set_dmabarrier() interface and give it
a default no-op implementation.
Signed-off-by: Arthur Kepner <akepner@sgi.com>
---
dma-mapping.h | 6 ++++++
1 files changed, 6 insertions(+)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 2dc21cb..4d1d199 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -99,4 +99,10 @@ static inline void dmam_release_declared_memory(struct device *dev)
}
#endif /* ARCH...
| Sep 27, 9:10 pm 2007 |
| akepner | [PATCH 0/4] allow drivers to flush in-flight DMA v2
On Altix, DMA may be reordered between a device and host memory.
This reordering can happen in the NUMA interconnect, and it usually
results in correct operation and improved performance. In some
situations it may be necessary to explicitly synchronize DMA from
the device.
This patchset allows a memory region to be mapped with a "dmabarrier".
Writes to the memory region will cause in-flight DMA to be flushed,
providing a mechanism to order DMA from a device.
There are 4 patches in this p...
| Sep 27, 9:09 pm 2007 |
| roel | [PATCH] removes array_size duplicates
This patch removes some ARRAY_SIZE macro duplicates. There is also one in
arch/um/include/user.h, which isn't fixed here because comments in that file
explicitly state a preference for the 'less fancy' version. If that's the
case as well for any of the other replacements please comment.
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
---
Documentation/spi/spidev_test.c | 2 --
arch/i386/boot/compressed/relocs.c | 1 -
arch/m68k/amiga/amisound.c | 3 +--
arch/powerpc/boot...
| Sep 27, 6:51 pm 2007 |
| H. Peter Anvin | More E820 brokenness
As luck would have it, it's not just an obscure Geode system which has a
broken E820 implementation. Today I received a bug report about a Dell
system (XPS M1330) with broken E820.
Unfortunately, the workaround for the Geode breaks this system, because
x86-64 doesn't fall back to the e801/88 information like the i386 kernel
does.
I wonder if the relevant people could test out this patch to see how it
works on their respective system. This patch reverts to 2.6.23-rc8
behaviour of simply truncat...
| Sep 27, 6:17 pm 2007 |
| Jordan Crouse | Re: More E820 brokenness
Breaks on the Geode - original behavior.
I think that having boot_prams.e820_entries != 0 makes the kernel
I'm inclined to agree.
Jordan
-
| Sep 27, 6:33 pm 2007 |
| H. Peter Anvin | Re: More E820 brokenness
Okay, now I'm utterly baffled how 2.6.22 ever worked on this Geode,
because this, to the best of my reading, mimics the 2.6.22 behavior
exactly. DID IT REALLY, and/or did you make any kind of configuration
Arguably the right thing to do is to find the responsible BIOS engineer
and shoot them, but that's hard to do without robotics.
-hpa
-
| Sep 27, 6:47 pm 2007 |
| Jordan Crouse | Re: More E820 brokenness
I copied in a 2.6.22 kernel to see that it really did work, and it did.
But here's the crazy part - I did a dmesg, and it looks like it
*is* using e820 data, and it looks complete (I see the entire map -
including the ACPI and reserved blocks way up high).
So apparently it was the 2.6.22 code that was buggy, but reading it,
I don't immediately see how.
Jordan
--
Jordan Crouse
Systems Software Development Engineer
Advanced Micro Devices, Inc.
-
| Sep 27, 7:15 pm 2007 |
| H. Peter Anvin | Re: More E820 brokenness
Oh bugger, looks like this one might be genuinely my fault after all.
The ID check in the new code is buggy.
Can you please test this revised patch out (against current -git)?
-hpa
| Sep 27, 7:27 pm 2007 |
| Jordan Crouse | Re: More E820 brokenness
That looks the same as the previous patch you sent?
Jordan
--
Jordan Crouse
Systems Software Development Engineer
Advanced Micro Devices, Inc.
-
| Sep 27, 7:34 pm 2007 |
| H. Peter Anvin | Re: More E820 brokenness
Sorry, this is the right one...
-hpa
| Sep 27, 7:36 pm 2007 |
| Jordan Crouse | Re: More E820 brokenness
Worked, but that just raises more questions. Why didn't more x86 boxes
break or, alternatively, why did a new version of the BIOS fix the problem?
I guess we shouldn't look a gift horse in the mouth. Or something.
Thanks very much for your help.
Jordan
--
Jordan Crouse
Systems Software Development Engineer
Advanced Micro Devices, Inc.
-
| Sep 27, 7:54 pm 2007 |
| H. Peter Anvin | Re: More E820 brokenness
Why didn't more x86 boxes break... well, it's pretty natural an
implementation of the BIOS to not clobber registers that aren't outputs.
Arguably the BIOSes that do are still buggy, since there isn't a
well-defined calling sequence for the BIOS and the convention that has
evolved is "don't clobber anything unless it's an output."
It's still wrong, however, especially since it means omitting the *real*
SMAP check.
-hpa
-
| Sep 27, 8:12 pm 2007 |
| H. Peter Anvin | Re: More E820 brokenness
Was this a stock 2.6.22 kernel, or might it have been modified?
There is, of course, also the possibility that triggering the BIOS bug
in your case depends on some delicate combination of input state.
-hpa
-
| Sep 27, 7:22 pm 2007 |
| Thomas Gleixner | [PATCH] clockevents: fix bogus next_event reset for oneshot ...
In periodic broadcast mode the next_event member of the broadcast device
structure is set to KTIME_MAX in the interrupt handler. This is wrong,
as we calculate the next periodic interrupt with this variable.
Remove it.
Noticed by Ralf. MIPS is the first user of this mode, it does not affect
existing users.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-and-tested-by: Ralf Baechle <ralf@linux-mips.org>
---
diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-br...
| Sep 27, 6:17 pm 2007 |
| Zan Lynx | 2.6.23-rc8-mm2 NULL dereference in __mnt_is_readonly in ftru...
Kernel 2.6.23-rc8-mm2 on a AMD-64, filesystems mounted are reiserfs,
reiser4 and tmpfs.
netconsole dmesg output and .config are included below.
Near the end of my boot sequence, there is a kernel error. I am not
sure exactly what user-space is doing to make this happen, but I know
that a simple shell and some filesystem operations do not cause it.
This error also occurred in 2.6.23-rc8-mm1 but I didn't have time to
post it and hoped it would just go away. I never tested 2.6.23-rc7-mm*,
and the...
| Sep 27, 5:54 pm 2007 |
| roel | [PATCH] spin_lock_unlocked cleanups
Replace some SPIN_LOCK_UNLOCKED with DEFINE_SPINLOCK
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
---
diff --git a/arch/mips/pci/ops-pmcmsp.c b/arch/mips/pci/ops-pmcmsp.c
index 09fa007..059eade 100644
--- a/arch/mips/pci/ops-pmcmsp.c
+++ b/arch/mips/pci/ops-pmcmsp.c
@@ -206,7 +206,7 @@ static void pci_proc_init(void)
}
#endif /* CONFIG_PROC_FS && PCI_COUNTERS */
-spinlock_t bpci_lock = SPIN_LOCK_UNLOCKED;
+DEFINE_SPINLOCK(bpci_lock);
/************************************...
| Sep 27, 5:36 pm 2007 |
| Mark Lord | Problems with SMP & ACPI powering off
Question: do we disable all CPUs except 0 when doing ACPI power off?
Background:
I have a machine here dedicated to running MythTV.
It powers up to record, and then sets the RTC alarm for next time
and powers down again in between recordings.
It has an Intel Core2duo E6300 CPU, currently on an ICH8 motherboard.
Previously it was on a completely different (vendor,bios,...) ICH7 motherboard.
In both cases, "halt -p" sometimes fails to actually turn off the power,
which means that it later then ...
| Sep 27, 5:29 pm 2007 |
| Rafael J. Wysocki | Re: Problems with SMP & ACPI powering off
May be.
Same chipset, perchance?
Greetings,
Rafael
-
| Sep 27, 6:00 pm 2007 |
| Mark Lord | Re: Problems with SMP & ACPI powering off
Latest 2.6.23-rc-git. Same problem from time to time on 2.6.17, as well.
Dunno about in between those Revs., but it's much more common on the latest
Mmmm I originally didn't think so.
But actually one board is ICH8, the other ICH8R,
so yes, they use the same chipset.
Cheers
-
| Sep 27, 7:07 pm 2007 |
| Mark Lord | Re: Problems with SMP & ACPI powering off
Oh, and two different power-supplies, too.
-ml
-
| Sep 27, 5:30 pm 2007 |
| Vegard Nossum | [RFC] New kernel-message logging API (take 2)
Hello,
A big thanks to everybody who read and replied to my first e-mail; I
have tried my best to incorporate your feedback and suggestions. I
also added some CCs who recently participated in logging-related
discussions.
Changes (since Sept. 22):
* Extensibility -> Allowing the compiler to eliminate messages below
a certain threshold requires changing the API.
* Add some special-purpose logging functions
(printk_detected(), _registered(), _settings(), and _copyright())
* F...
| Sep 27, 5:18 pm 2007 |
| linux | Re: [RFC] New kernel-message logging API (take 2)
Assuming that kprint_block_flush() is a combination of
kprint_block_printit() and kprint_block_abort(), you
coulld make a macro wrapper for this to preclude leaks:
#define KPRINT_BLOCK(block, level, code) \
do { \
struct kprint_block block; \
kprint_block_init(&block, KPRINT_##level); \
do { \
code ; \
kprint_block_printit(&block); \
while (0); \
kprint_block_abort(&block); \
} while(0)
The inner do { } while(0) region is so you can abort with "break".
(Or you can ...
| Sep 27, 9:38 pm 2007 |
| Rik van Riel | [PATCH] kswapd should only wait on IO if there is IO
The current kswapd (and try_to_free_pages) code has an oddity where the
code will wait on IO, even if there is no IO in flight. This problem is
notable especially when the system scans through many unfreeable pages,
causing unnecessary stalls in the VM.
Signed-off-by: Rik van Riel <riel@surriel.com>
diff -up linux-2.6.22.x86_64/mm/vmscan.c.wait linux-2.6.22.x86_64/mm/vmscan.c
--- linux-2.6.22.x86_64/mm/vmscan.c.wait 2007-09-25 11:33:30.000000000 -0400
+++ linux-2.6.22.x86_64/mm/vmscan.c 20...
| Sep 27, 5:08 pm 2007 |
| Andrew Morton | Re: [PATCH] kswapd should only wait on IO if there is IO
On Thu, 27 Sep 2007 17:08:16 -0400
The comparison with swap_cluster_max is unobvious, and merits a
comment. What is the thinking here?
Also, we now have this:
if (total_scanned > sc.swap_cluster_max +
sc.swap_cluster_max / 2) {
wakeup_pdflush(laptop_mode ? 0 : total_scanned);
sc.may_writepage = 1;
}
/* Take a nap, wait for some writeback to complete */
if (sc.nr_scanned && priority < DEF_PRIORITY - 2 &&
sc.nr_io_pages > sc.swap_cluste...
| Sep 27, 5:47 pm 2007 |
| Rik van Riel | Re: [PATCH] kswapd should only wait on IO if there is IO
On Thu, 27 Sep 2007 14:47:02 -0700
Kswapd was no longer sitting in "D" state as often and pages got
freed more promptly. The test was done on a RHEL kernel with
this change though - I guess I should redo it with a current upstream
If the number of pages undergoing IO is really small, waiting
for them may be a waste of time.
Actually, nr_io_pages is also incremented when we run into pages that
It is incrementing sc.nr_io_pages and will wait on IO to complete if
the amount of pages in fligh...
| Sep 27, 6:13 pm 2007 |
| Andrew Morton | Re: [PATCH] kswapd should only wait on IO if there is IO
On Thu, 27 Sep 2007 18:13:25 -0400
The thinking sounds good to me, but I'm looking for weirdo side-effects in
corner cases. And I'm trying to work out what actual design we want to
Buggered if I know ;)
It may have the accidental effect that it opens a window in which some
may_enter_fs-capable process can get scheduled and do some writeout,
OK, thanks. Perhaps a few words tacked onto the nr_io_pages definition
yup, I didn't think of that. Hopefully someone else will be in there
work...
| Sep 27, 6:21 pm 2007 |
| Rik van Riel | Re: [PATCH] kswapd should only wait on IO if there is IO
On Thu, 27 Sep 2007 15:21:21 -0700
if (PageDirty(page)) {
if (sc->order <= PAGE_ALLOC_COSTLY_ORDER && referenced)
goto keep_locked;
if (!may_enter_fs)
goto keep_locked;
I think we can fix that problem by adding a sc->nr_io_pages++
between the last if and the goto keep_locked in shrink_page_list.
That way !GFP_IO or !GFP_FS tasks will cause themselves ...
| Sep 27, 6:50 pm 2007 |
| Andrew Morton | Re: [PATCH] kswapd should only wait on IO if there is IO
On Thu, 27 Sep 2007 18:50:27 -0400
As did that one. Ho hum :( Maybe it's in the git history somewhere.
-
| Sep 27, 6:59 pm 2007 |
| Rik van Riel | Re: [PATCH] kswapd should only wait on IO if there is IO
On Thu, 27 Sep 2007 15:59:07 -0700
Good point.
The current kswapd (and try_to_free_pages) code has an oddity where the
code will wait on IO, even if there is no IO in flight. This problem is
notable especially when the system scans through many unfreeable pages,
causing unnecessary stalls in the VM.
Additionally, tasks without __GFP_FS or __GFP_IO in the direct reclaim
path will sleep if a significant number of pages are encountered that
should be written out. This gives kswapd a chance to w...
| Sep 27, 7:08 pm 2007 |
| David Rientjes | [patch 1/2] pci: use size stored in proc_dir_entry for proc ...
On pci_proc_attach_device(), the size of the PCI configuration space is
stored in the proc_dir_entry as the size of the file. Thus, the procfs
interface to PCI devices should use it instead of the device directly.
Signed-off-by: David Rientjes <rientjes@google.com>
---
drivers/pci/proc.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
--- a/drivers/pci/proc.c
+++ b/drivers/pci/proc.c
@@ -60,7 +60,7 @@ proc_bus_pci_read(...
| Sep 27, 4:41 pm 2007 |
| David Rientjes | [patch 2/2] pci: write file size to inode on proc bus file w...
When a /proc/bus/pci file is written to, the size of that PCI device's
configuration space must be written to the inode. Otherwise, it is
possible for the file to specify a size of 0 on stat if a task is holding
the same file open.
Signed-off-by: David Rientjes <rientjes@google.com>
---
drivers/pci/proc.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
--- a/drivers/pci/proc.c
+++ b/drivers/pci/proc.c
@@ -129,7 +129,7 @...
| Sep 27, 4:41 pm 2007 |
| Administrator | [MailServer Notification]Attachment Blocking Notification
Warning to Recipient: Action taken by attachment blocking.
-
| Sep 27, 4:24 pm 2007 |
| Dmitry Tyschenko | NO_HZ hangs up AMD MK-36
Hello,
I have laptop Asus X50M. Using old Debian Etch from February.
Kernel from 2.6.21 doesn't boot, hangs up just in 10seconds - 1minute
after GRUB screen.
I have tryed different versions of gcc (4.1.1, 4.1.2, 4.2.1) to build
2.6.22.8 kernel, but no results.
But if I disable NO_HZ option 2.6.21 is working fine for me.
I think this is important problem, because some of the project, Debian
for example,
are building kernel with this options enabled (in
linux-image-2.6.22-1-k7 package it is en...
| Sep 27, 4:28 pm 2007 |
| Rafael J. Wysocki | Re: NO_HZ hangs up AMD MK-36
You can use the "nohz=off" kernel command line switch. Please check if it
works for you.
Greetings,
Rafael
-
| Sep 27, 4:59 pm 2007 |
| previous day | today | next day |
|---|---|---|
| September 26, 2007 | September 27, 2007 | September 28, 2007 |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Nigel Cunningham | Re: [PATCH] Remove process freezer from suspend to RAM pathway |
| Paul Mundt | Re: 2.6.22-rc4-mm2 |
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
git: | |
| Arjan van de Ven | Re: [GIT]: Networking |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Natalie Protasevich | [BUG] New Kernel Bugs |
