Quoting Andrew Morton ([EMAIL PROTECTED]):
> On Thu, 4 Jan 2007 12:12:57 -0600
> "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote:
>
> > A process in one user namespace could set a fowner and sigio on a file in a
> > shared vfsmount, ending up killing a task in another user namespace.
> >
> > Prevent
On Sun, Jan 14, 2007 at 09:30:08PM -0800, David Miller wrote:
> From: David Stevens <[EMAIL PROTECTED]>
> Date: Sun, 14 Jan 2007 19:47:49 -0800
>
> > I think it's better to add the fix than withdraw this patch, since
> > the original bug is a crash.
>
> I completely agree.
Great, can someone
* Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> My system hangs on this
> http://www.stardust.webpages.pl/files/tbf/euridica/2.6.20-rc4-mm1/bug2.jpg
> http://www.stardust.webpages.pl/files/tbf/euridica/2.6.20-rc4-mm1/mm-config
>
> Debug plan:
> - revert md-* patches
> - binary search
>
> Does
Björn Steinbrink writes:
> Hi,
>
> with 2.6.20-rc{2,4,5} (no other tested yet) I see SATA exceptions quite
> often, with 2.6.19 there are no such exceptions. dmesg and lspci -v
> output follows. In the meantime, I'll start bisecting.
>
> Thanks
> Björn
>
>
> Linux version 2.6.20-rc2
On Sun, Jan 14, 2007 at 09:37:21AM -0800, Arjan van de Ven wrote:
> On Sun, 2007-01-14 at 19:24 +0200, Ahmed S. Darwish wrote:
> > Substitue intel_rng magic PCI IDs values used in the IDs table
> > with the macros defined in pci_ids.h
> >
> Hi,
>
>
> hmm this is actually the opposite direction
o Modpost generates warnings for i386 if compiled with CONFIG_RELOCATABLE=y
WARNING: vmlinux - Section mismatch: reference to
.init.text:find_unisys_acpi_oem_table from .text between 'acpi_madt_oem_check'
(at offset 0xc0101eda) and 'enable_apic_mode'
WARNING: vmlinux - Section mismatch:
On Monday 15 January 2007 13:14, Peter Antoniac wrote:
> This is more the answer that I expect. But is there a way, function or
> constant from **libdc** that can give you the answer, or you have to get it
...
What was I thinking... not from libdc but from LIBC :)
-
To unsubscribe from this list:
Geert Uytterhoeven wrote:
> It's known to work for the PS3 frame buffer device driver, which copies the
> virtual frame buffer to the GPU on every vsync. Check out ps3fb_mmap() in
> http://www.kernel.org/git/?p=linux/kernel/git/geoff/ps3-linux.git;a=blob_plain;f=drivers/video/ps3fb.c;hb=HEAD
I
Linus, please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git
for-linus
to receive the following updates:
drivers/mmc/imxmmc.c|3 ---
drivers/mmc/omap.c | 15 +--
drivers/mmc/pxamci.c|2 +-
drivers/mmc/tifm_sd.c |3 ---
From: David Stevens <[EMAIL PROTECTED]>
Date: Sun, 14 Jan 2007 19:47:49 -0800
> I think it's better to add the fix than withdraw this patch, since
> the original bug is a crash.
I completely agree.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On Monday 15 January 2007 05:31, Stefan Richter wrote:
> On 14 Jan, Arjan van de Ven wrote:
> > vmalloc space is limited; you really can't assume you can get any more
> > than 64Mb or so (and even then it's thight on some systems already);
>
> I suppose "grep VmallocChunk /proc/meminfo" shows what
On Mon, Jan 15, 2007 at 02:54:10AM +0300, Oleg Nesterov wrote:
> How about the pseudo-code below?
Some quick comments:
- singlethread_cpu needs to be hotplug safe (broken currently)
- Any reason why cpu_populated_map is not modified on CPU_DEAD?
- I feel more comfortable if
Arjan van de Ven wrote:
> I'd be interested in finding out how to best test this; if the bios is
> really broken I'd love to add a test to the Linux-ready Firmware
> Developer Kit for this, so that BIOS developers can make sure future
> bioses do not suffer from this bug...
As reported, this is
Remove an unwanted remnant of the recent revert of AVR32/AT91 SPI
patches in -mm. Without this patch, the AVR32 build of
2.6.20-rc[34]-mm1 breaks.
Signed-off-by: Ben Nizette <[EMAIL PROTECTED]>
---
Index: linux-2.6.20-rc3/arch/avr32/mach-at32ap/at32ap7000.c
I expect this is the failure to join the all-nodes multicast group,
in which case the fix has already been posted to netdev. I
believe the router advertisements are sent to that, and if the
join failed, it wouldn't receive any of them.
I think it's better to add the fix than withdraw this patch,
Hi,
The patch titled "IPV4/IPV6: Fix inet{,6} device initialization order"
shipped in 2.6.19.2 appears to be the cause of this regression:
https://bugs.gentoo.org/show_bug.cgi?id=161907
Is this a known issue? Should this patch be dropped from -stable?
Thanks,
Daniel
-
To unsubscribe from
Alan wrote:
> O> Wouldn't it be better to have ->determine_xfer_mask() and
>> ->set_specific_mode() than having two somewhat overlapping callbacks?
>> Or is there some problem that can't be handled that way?
>
> I'm not sure I follow what you are suggesting - can you explain further.
>
> Right
> Hi Joe,
>
> On 1/12/07, joe jin <[EMAIL PROTECTED]> wrote:
> > @@ -788,7 +786,7 @@ static int rlb_initialize(struct bonding
> >
> > spin_lock_init(&(bond_info->rx_hashtbl_lock));
> >
> > - new_hashtbl = kmalloc(size, GFP_KERNEL);
> > + new_hashtbl = kzalloc(size,
On Sun, Jan 14 2007, Robert Hancock wrote:
> Jeff Garzik wrote:
> >>Looks like all of these errors are from a FLUSH CACHE command and the
> >>drive is indicating that it is no longer busy, so presumably done.
> >>That's not a DMA-mapped command, so it wouldn't go through the ADMA
> >>machinery
On 2007.01.15 01:34:48 +0100, Björn Steinbrink wrote:
> On 2007.01.14 19:22:51 -0500, Jeff Garzik wrote:
> > Robert Hancock wrote:
> > >Björn Steinbrink wrote:
> > >>Hi,
> > >>
> > >>with 2.6.20-rc{2,4,5} (no other tested yet) I see SATA exceptions quite
> > >>often, with 2.6.19 there are no such
Should apply to -mm tree or current libata-dev git tree. Sorry for
attaching, but I seem to have misplaced the magic incantations to make
Thunderbird not destroy inline patches..
---
This cleans up a few issues with the error handling in sata_nv in ADMA
mode to make it more consistent with
Jeff Garzik wrote:
Looks like all of these errors are from a FLUSH CACHE command and the
drive is indicating that it is no longer busy, so presumably done.
That's not a DMA-mapped command, so it wouldn't go through the ADMA
machinery and I wouldn't have expected this to be handled any
Soeren Sonnenburg wrote:
> Jeff & Tejun thanks *a lot* for clarifying this. I am quite happy to see
> that this is working very reliably!
You're welcome. :-)
>>> These messages sound eval - so now the question is should I care ?
>>> ( On the other hand it did not crash the machine )
>> So, no,
> Subject: Enable SPU switch notification to detect currently active SPU tasks.
>
> From: Maynard Johnson <[EMAIL PROTECTED]>
>
> This patch adds to the capability of spu_switch_event_register so that the
> caller is also notified of currently active SPU tasks. It also exports
>
Jiri and Trond,
On Mon, Jan 15, 2007 at 01:14:09AM +0100, Jiri Kosina wrote:
> On Sun, 14 Jan 2007, Florin Iucha wrote:
>
> > All the testing was done via a ssh into the workstation. The console
> > was left as booted into, with the gdm running. The remote nfs4
> > directory was mounted on
Guilt v0.18 is available for download.
Guilt (Git Quilt) is a series of bash scripts which add a Mercurial
queues-like functionality and interface to git.
Tarballs:
http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/
Git repo:
On 15 Jan, Matthias Schniedermeyer wrote:
> Stefan Richter wrote:
>> On 14 Jan, Richard Knutsson wrote:
>>>(Really liked the idea to have a "Maintainer"-button
>>>next to "Help" in *config)
>>
>> Rhetorical question: What will this button be used for?
>
> Having "all(tm)" information of
Pierre Ossman wrote:
>
> Eeeeww... This is a problem as the SD spec. clearly states the order of
> init commands. So I wouldn't be surprised if we find SD cards that choke
> on the MMC init sequence.
>
> I guess what we lose by not supporting these is 8 bit data bus, but as
> we do not currently
On Sun, Jan 14, 2007 at 09:10:45PM +0100, Jan Engelhardt wrote:
> On Jan 14 2007 20:20, David Madore wrote:
> >Implement TCPMSS target for IPv6 by shamelessly copying from
> >Marc Boucher's IPv4 implementation.
>
> Would not it be worthwhile to merge ipt_TCPMSS and
> ip6t_TCPMSS to xt_TCPMSS
On 2007.01.14 19:22:51 -0500, Jeff Garzik wrote:
> Robert Hancock wrote:
> >Björn Steinbrink wrote:
> >>Hi,
> >>
> >>with 2.6.20-rc{2,4,5} (no other tested yet) I see SATA exceptions quite
> >>often, with 2.6.19 there are no such exceptions. dmesg and lspci -v
> >>output follows. In the meantime,
On Mon, Jan 15, 2007 at 01:07:18AM +0200, Ahmed S. Darwish wrote:
> On Mon, Jan 15, 2007 at 06:31:01AM +1100, Dave Airlie wrote:
> > On 1/15/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > >On Sun, 2007-01-14 at 19:24 +0200, Ahmed S. Darwish wrote:
> > >> Substitue intel_rng magic PCI IDs
On Sun, Jan 14, 2007 at 07:24:21PM +0200, Ahmed S. Darwish wrote:
> Substitue intel_rng magic PCI IDs values used in the IDs table
> with the macros defined in pci_ids.h
Why not use the PCI_DEVICE() macro too? It should make the lines even
smaller.
thanks,
greg k-h
-
To unsubscribe from this
> On Mon, 15 Jan 2007 00:52:36 +0100 Tilman Schmidt <[EMAIL PROTECTED]> wrote:
> With kernel 2.6.20-rc4-mm1 and all hotfixes, i810fb fails to load on my
> Dell Optiplex GX110. Here's an excerpt of the diff between the boot logs
> of 2.6.20-rc5 (working) and 2.6.20-rc4-mm1 (non-working):
>
> @@
Robert Hancock wrote:
Björn Steinbrink wrote:
Hi,
with 2.6.20-rc{2,4,5} (no other tested yet) I see SATA exceptions quite
often, with 2.6.19 there are no such exceptions. dmesg and lspci -v
output follows. In the meantime, I'll start bisecting.
...
ata1.00: exception Emask 0x0 SAct 0x0
On Mon, 2007-01-15 at 10:55 +1100, Stephen Rothwell wrote:
> On Sun, 14 Jan 2007 14:54:11 + Alan <[EMAIL PROTECTED]> wrote:
> >
> > This doesn't appea to do the same thing at all. You need to select
> > between two sets of const inode ops instead, otherwise you turn write on
> > arbitarily.
>
On Sun, 14 Jan 2007, Florin Iucha wrote:
> All the testing was done via a ssh into the workstation. The console
> was left as booted into, with the gdm running. The remote nfs4
> directory was mounted on "/mnt". After copying the 60+ GB and testing
> that the keyboard was still functioning,
On Sun, 2007-01-14 at 17:58 -0600, Florin Iucha wrote:
> All the testing was done via a ssh into the workstation. The console
> was left as booted into, with the gdm running. The remote nfs4
> directory was mounted on "/mnt".
>
> After copying the 60+ GB and testing that the keyboard was still
On Sun, Jan 14 2007, Thomas Gleixner wrote:
> On Sun, 2007-01-14 at 11:46 +0100, Thomas Gleixner wrote:
> > > Boot proceeds, but gets stuck hard at:
> > > "Remounting root filesystem in read-write mode:"
> > >
> > > No SysRq-T, nothing.
> > >
> > > The above BUG seems unrelated to that.
Stefan Richter wrote:
> On 14 Jan, Richard Knutsson wrote:
>
>>(Really liked the idea to have a "Maintainer"-button
>>next to "Help" in *config)
>
>
> Rhetorical question: What will this button be used for?
Having "all(tm)" information of something in one place?
Help-Text and
On Sun, Jan 14, 2007 at 04:57:01PM -0600, wrote:
> On Wed, Jan 10, 2007 at 10:54:34AM -0500, Alan Stern wrote:
> > It's still possible that this is hardware related; perhaps some component
> > just began to wear out. If you return to an earlier kernel, does the
> > problem go away?
>
> As
Hello,
In linux-2.6.19.2, do the following lines have bugs in them? It looks
like they dereference a user pointer without first being checked by
the "access_ok" macro to ensure that they point into userspace.
Suhabe
File: sound/isa/sscape.c
Lines: 550, 665
Description:
How about the pseudo-code below?
workqueue_mutex is only used to protect "struct list_head workqueues",
all workqueue operations can run in parallel with cpuhotplug callback path.
take_over_work(), migrate_sequence, CPU_LOCK_ACQUIRE/RELEASE go away.
I'd like to make a couple of cleanups (and fix
On Sun, 14 Jan 2007 14:54:11 + Alan <[EMAIL PROTECTED]> wrote:
>
> This doesn't appea to do the same thing at all. You need to select
> between two sets of const inode ops instead, otherwise you turn write on
> arbitarily.
Or something like below ... (compile tested on pseries, iseries and
With kernel 2.6.20-rc4-mm1 and all hotfixes, i810fb fails to load on my
Dell Optiplex GX110. Here's an excerpt of the diff between the boot logs
of 2.6.20-rc5 (working) and 2.6.20-rc4-mm1 (non-working):
@@ -4,7 +4,7 @@
No module symbols loaded - kernel modules not enabled.
klogd 1.4.1, log
Björn Steinbrink wrote:
Hi,
with 2.6.20-rc{2,4,5} (no other tested yet) I see SATA exceptions quite
often, with 2.6.19 there are no such exceptions. dmesg and lspci -v
output follows. In the meantime, I'll start bisecting.
...
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
Richard Knutsson wrote:
> Matthias Schniedermeyer wrote:
>
>> Richard Knutsson wrote:
>>
>>
>>> Matthias Schniedermeyer wrote:
>>>
>>>
>>>
Richard Knutsson wrote:
> Any thoughts on this is very much appreciated (is there any flaws with
> this?).
From: Simon Budig <[EMAIL PROTECTED]>
This change introduces a mapping for LED indicators between the USB HID
specification and the Linux input subsystem. The previous code properly
mapped the LEDs relevant for Keyboards, but garbeled the remaining ones.
With this change all LED enums from the
> 2. Trying to understand what has happened I found the main difference
> is not in the driver but in ide-dma.c:
>
> --- linux-2.6.17.14/drivers/ide/ide-dma.c 2006-06-18 01:49:35.0
> +
> +++ linux-2.6.18.6/drivers/ide/ide-dma.c2006-09-20 03:42:06.0
> +
> @@ -752,7
On Mon, Jan 15, 2007 at 06:31:01AM +1100, Dave Airlie wrote:
> On 1/15/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> >On Sun, 2007-01-14 at 19:24 +0200, Ahmed S. Darwish wrote:
> >> Substitue intel_rng magic PCI IDs values used in the IDs table
> >> with the macros defined in pci_ids.h
> >>
>
On 14 Jan, Richard Knutsson wrote:
> (Really liked the idea to have a "Maintainer"-button
> next to "Help" in *config)
Rhetorical question: What will this button be used for?
--
Stefan Richter
-=-=-=== ---= -===-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line
On Wed, Jan 10, 2007 at 10:54:34AM -0500, Alan Stern wrote:
> It's still possible that this is hardware related; perhaps some component
> just began to wear out. If you return to an earlier kernel, does the
> problem go away?
As reported in my original e-mail and verified just minutes ago, the
Hi,
There are ITE 8212-based controllers installed in some of my
computers. I had always skipped the build-in RAID things and used them
as plain controllers.
1. Beginning with 2.6.18 there was some trouble, basically slowed data
transfer, sometimes even a totally stalled system (I cannot
On 14 Jan, Richard Knutsson wrote:
> Stefan Richter wrote:
>> gcc -o test3.o test.c test.c
>>
> That produces just an executable file with a misleading name :)
#-)
[...]
>> 3. When people notice that patches are misdirected too often, they will
>>update MAINTAINERS.
>>
> You mean they
Hi,
with 2.6.20-rc{2,4,5} (no other tested yet) I see SATA exceptions quite
often, with 2.6.19 there are no such exceptions. dmesg and lspci -v
output follows. In the meantime, I'll start bisecting.
Thanks
Björn
Linux version 2.6.20-rc2 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115
On Saturday January 13, [EMAIL PROTECTED] wrote:
> On Sat, Jan 13, 2007 at 06:43:07AM +1100, Neil Brown wrote:
> >
> > Ok, thanks. I must have missed something else wrong in the code..
> >
> > Probably this 'break' in the wrong place...
> >
> > Could you try this patch instead please - or
On Sun, Jan 14 2007, Thomas Gleixner wrote:
> On Mon, 2007-01-15 at 09:05 +1100, Jens Axboe wrote:
> > raid seems to have severe problems with the plugging change. I'll try
> > and find Neil and have a chat with him, hopefully we can work it out.
>
> Some hints:
>
> mount(1899): WRITE block
On Mon, 2007-01-15 at 09:05 +1100, Jens Axboe wrote:
> raid seems to have severe problems with the plugging change. I'll try
> and find Neil and have a chat with him, hopefully we can work it out.
Some hints:
mount(1899): WRITE block 16424 on md3
call md_write_start
md3_raid1(438): WRITE block
On Fri, Jan 12 2007, Michal Piotrowski wrote:
> On 12/01/07, Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> >On 12/01/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> >> On Friday, 12 January 2007 14:33, Michal Piotrowski wrote:
> >> > My system hangs on this
> >> >
>
On Sun, Jan 14 2007, Thomas Gleixner wrote:
> On Sun, 2007-01-14 at 11:46 +0100, Thomas Gleixner wrote:
> > > Boot proceeds, but gets stuck hard at:
> > > "Remounting root filesystem in read-write mode:"
> > >
> > > No SysRq-T, nothing.
> > >
> > > The above BUG seems unrelated to that.
Matthias Schniedermeyer wrote:
Richard Knutsson wrote:
Matthias Schniedermeyer wrote:
Richard Knutsson wrote:
Any thoughts on this is very much appreciated (is there any flaws with
this?).
The thought that crossed my mind was:
Why not do the same thing that
Stefan Richter wrote:
On 14 Jan, Richard Knutsson wrote:
Stefan Richter wrote:
[getting a wrong contact from looking at the MAINTAINERS file]
Hopefully, but I think it is asking much of the maintainer and then
there will certanly be confused/frustrated submitter who don't know why
I figured it out! I thought you might be interested --- the reason is the
mismatch between the default mount options stored in the superblock on
disk and the filesystem features compiled into the kernel.
Namely, dumpe2fs on the offending filesystems showed the following default
mount options:
Am Sonntag, 14. Januar 2007 20:47 schrieb [EMAIL PROTECTED]:
> > When the scanner is not in use, the system automatically suspends it after
> > two seconds. When you use sane the scanner is resumed, but it then
> > disconnects itself and reconnects. Sane is left trying to control the
> >
On Sun, 2007-01-14 at 21:31 +0100, Stefan Richter wrote:
> On 14 Jan, Arjan van de Ven wrote:
> > vmalloc space is limited; you really can't assume you can get any more
> > than 64Mb or so (and even then it's thight on some systems already);
>
> I suppose "grep VmallocChunk /proc/meminfo" shows
On 14 Jan, Arjan van de Ven wrote:
> vmalloc space is limited; you really can't assume you can get any more
> than 64Mb or so (and even then it's thight on some systems already);
I suppose "grep VmallocChunk /proc/meminfo" shows what is available?
> it really sounds like vmalloc space isn't the
On Sun, 14 Jan 2007, Robert P. J. Day wrote:
On Sun, 14 Jan 2007, [EMAIL PROTECTED] wrote:
In compiling:
CC [M] net/ipv4/netfilter/ipt_TTL.o
LD [M] drivers/usb/storage/usb-storage.o
CC [M] drivers/usb/gadget/net2280.o
CC [M] net/ipv4/netfilter/arp_tables.o
Hi,
I'm using the new TCP-MD5 option in 2.6.20-rc4 and rc5
to talk BGP to cisco routers.
My box connects to the cisco, and the handshake looks fine:
SYN, SYN/ACK, ACK all have md5 option and correct TCP checksums.
All packets after that, i.e. the ones with payload data,
have wrong TCP checksums,
On Jan 14 2007 20:20, David Madore wrote:
>
>Implement TCPMSS target for IPv6 by shamelessly copying from
>Marc Boucher's IPv4 implementation.
>
>Signed-off-by: David A. Madore <[EMAIL PROTECTED]>
Would not it be worthwhile to merge ipt_TCPMSS and
ip6t_TCPMSS to xt_TCPMSS instead?
-`J'
Hi!
> > Well, you can have it as set of 0-1 "limits"...
>
> I have come up with a similar idea of regarding the ulimit
> value as a bitmask, and I think it may work.
> But it will be confusable for users to add the new concept of
> 0-1 limitation into the traditional resouce limitation feature.
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> Subject: [patch] lockdep: shrink held_lock structure
> From: Dave Jones <[EMAIL PROTECTED]>
>
> shrink the held_lock structure from 40 to 20 bytes. This shrinks struct
> task_struct from 3056 to 2464 bytes.
>
> [ From: Ingo Molnar <[EMAIL
Subject: [patch] lockdep: shrink held_lock structure
From: Dave Jones <[EMAIL PROTECTED]>
shrink the held_lock structure from 40 to 20 bytes. This shrinks struct
task_struct from 3056 to 2464 bytes.
[ From: Ingo Molnar <[EMAIL PROTECTED]>, shrunk hlock->class too. ]
Shrunk MAX_KEYS_BITS from
On Sun, 14 Jan 2007, Alan Stern wrote:
On Sun, 14 Jan 2007, Prakash Punnoor wrote:
Am Sonntag 14 Januar 2007 10:28 schrieb Oliver Neukum:
Am Sonntag, 14. Januar 2007 10:08 schrieb Prakash Punnoor:
Am Donnerstag 11 Januar 2007 18:28 schrieb Oliver Neukum:
Am Donnerstag, 11. Januar 2007
Bill Davidsen <[EMAIL PROTECTED]> wrote:
> My point is, that there is code to handle sparse data now, without
> O_DIRECT involved, and if O_DIRECT bypasses that, it's not a problem
> with the idea of O_DIRECT, the kernel has a security problem.
The idea of O_DIRECT is to bypass the pagecache,
On 1/15/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
On Sun, 2007-01-14 at 19:24 +0200, Ahmed S. Darwish wrote:
> Substitue intel_rng magic PCI IDs values used in the IDs table
> with the macros defined in pci_ids.h
>
Hi,
hmm this is actually the opposite direction than most of the kernel
Implement TCPMSS target for IPv6 by shamelessly copying from
Marc Boucher's IPv4 implementation.
Signed-off-by: David A. Madore <[EMAIL PROTECTED]>
---
Note: The patch for ip6tables to make use of this module can be
obtained from ftp://quatramaran.ens.fr/pub/madore/misc/ip6t-TCPMSS/
> (also
On Sun, 2007-01-14 at 20:19 +0100, Stefan Richter wrote:
> On 10 Jan, Peter Antoniac wrote:
> [...]
> > Problem is: how to get the VMALLOC_RESERVED value for the kernel that is
> > running? I couldn't find any standard way to do that (something to apply to
> > GNU Linux and the like). All the
On Sun, 14 Jan 2007, Prakash Punnoor wrote:
> Am Sonntag 14 Januar 2007 10:28 schrieb Oliver Neukum:
> > Am Sonntag, 14. Januar 2007 10:08 schrieb Prakash Punnoor:
> > > Am Donnerstag 11 Januar 2007 18:28 schrieb Oliver Neukum:
> > > > Am Donnerstag, 11. Januar 2007 18:20 schrieb Prakash Punnoor:
On 10 Jan, Peter Antoniac wrote:
[...]
> Problem is: how to get the VMALLOC_RESERVED value for the kernel that is
> running? I couldn't find any standard way to do that (something to apply to
> GNU Linux and the like). All the things I could get were the default value
> being 128MiB :) and that
Hardware list attached, and config. When scanning disk at the start of
the install, exits with "signal 13 (0)" and no log entry. Just as the
kvm dies there's a switch from the blue install screen to a white on
black screen, and a message displays for a fraction of a sec, unreadably
fast.
I
14 Oca 2007 Paz 20:06 tarihinde, Arjan van de Ven şunları yazmıştı:
> Hi,
Hi,
> I'd be interested in finding out how to best test this; if the bios is
> really broken I'd love to add a test to the Linux-ready Firmware
> Developer Kit for this, so that BIOS developers can make sure future
>
On Sat, 13 Jan 2007, Bill Davidsen wrote:
> Bodo Eggert wrote:
>
> > (*) This would allow fadvise_size(), too, which could reduce fragmentation
> > (and give an early warning on full disks) without forcing e.g. fat to
> > zero all blocks. OTOH, fadvise_size() would allow users to reserve
On Tue, 2007-01-02 at 18:38 -0500, Dave Jones wrote:
> + unsigned char irq_context:1;
> + unsigned char trylock:1;
> + unsigned char read:2;
> + unsigned char check:1;
> + unsigned char hardirqs_off:1;
cool! I totally missed those. I'd even do this for 2.6.20, but
On Sun, 2007-01-14 at 19:59 +0200, Faik Uygur wrote:
> 14 Oca 2007 Paz 03:23 tarihinde, Robert Hancock şunları yazmıştı:
> >> [...]
> >> > Since you're getting to this point I think this has to be some kind of
> > BIOS interaction causing this. The only thing that happens after the
> > "Entering
14 Oca 2007 Paz 03:23 tarihinde, Robert Hancock şunları yazmıştı:
>> [...]
>> > Since you're getting to this point I think this has to be some kind of
> BIOS interaction causing this. The only thing that happens after the
> "Entering sleep state" is that the kernel writes to some ACPI registers
14 Oca 2007 Paz 05:18 tarihinde şunları yazmıştınız:
>> [...]
> > Since you're getting to this point I think this has to be some kind of
> > BIOS interaction causing this. The only thing that happens after the
> > "Entering sleep state" is that the kernel writes to some ACPI registers
> > to tell
On Sun, 2007-01-14 at 19:24 +0200, Ahmed S. Darwish wrote:
> Substitue intel_rng magic PCI IDs values used in the IDs table
> with the macros defined in pci_ids.h
>
Hi,
hmm this is actually the opposite direction than most of the kernel is
heading in, mostly because the pci_ids.h file is a
Substitue intel_rng magic PCI IDs values used in the IDs table
with the macros defined in pci_ids.h
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
I've used a small script to generate this patch then manually tried to
make sure it's (hopefully) correct.
#!/bin/bash
> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Fully agree!
NMI watchdog is high risk in terms of interacting with firmware and
other things (and the code is sort of broken anyway)
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line
On Sun, 2007-01-14 at 14:32 +0100, Jan Engelhardt wrote:
> >There are various files (in my copy of the Ubuntu 2.6.15 source) which
> >have an LGPL licence, but there isn't a copy of the licence in the
> >distribution as there should be. Changing them to GPL seems the best
> >thing to do.
>
>
Remove all traces of raw devices support, which were officially
obsolete since 2.6.3.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
crap. the "allyesconfig" build worked, except when it came to
installing the sanitized headers, whose include/linux/Kbuild file
still had a
[EMAIL PROTECTED] wrote:
On Sat, 13 Jan 2007 15:18:31 EST, Bill Davidsen said:
[EMAIL PROTECTED] wrote:
On Fri, 12 Jan 2007 10:03:49 EST, Lennart Sorensen said:
I would expect any distribution should work on these (as long as the
kernel they use isn't too old.). Of course if it is a Mac, you
Dmitriy Monakhov wrote:
Eric Sandeen <[EMAIL PROTECTED]> writes:
I've been looking at a case where many threads are opening, unlinking, and
hardlinking files on ext3 .
How many concurent threads do you use and how long does it takes to trigger
this race? I've tried to reproduce this with two
Michael Tokarev wrote:
Bill Davidsen wrote:
If I got it right (and please someone tell me if I *really* got it right!),
the problem is elsewhere.
Suppose you have a filesystem, not at all related to databases and stuff.
Your usual root filesystem, with your /etc/ /var and so on directories.
Hi Adrian:
> On Sun, Jan 07, 2007 at 10:40:49AM -0500, Mark M. Hoffman wrote:
> > It's just cruft from the original quirk. The "compatible" printk could have
> > had value as a diagnostic in case the new quirk didn't work for some reason,
> > but I never saw any complaints about it (apart from
Remove all traces of "raw devices" support.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
since this feature is listed as being obsolete since 2.6.3 and was
scheduled for removal back in Dec of 2005, I figure there wasn't much
harm in getting rid of it.
i'm trying a "make
On Sun, 14 Jan 2007, [EMAIL PROTECTED] wrote:
> In compiling:
> CC [M] net/ipv4/netfilter/ipt_TTL.o
> LD [M] drivers/usb/storage/usb-storage.o
> CC [M] drivers/usb/gadget/net2280.o
> CC [M] net/ipv4/netfilter/arp_tables.o
> drivers/usb/gadget/net2280.c: In function 'net2280_probe':
>
In compiling:
CC [M] net/ipv4/netfilter/ipt_TTL.o
LD [M] drivers/usb/storage/usb-storage.o
CC [M] drivers/usb/gadget/net2280.o
CC [M] net/ipv4/netfilter/arp_tables.o
drivers/usb/gadget/net2280.c: In function 'net2280_probe':
drivers/usb/gadget/net2280.c:2969: warning: ignoring return
On Sun, 14 Jan 2007, Ingo Molnar wrote:
> And with this my laptop (Lenovo T60) also stops its sporadic hard
> hanging (sometimes in acpi_init(), sometimes later during bootup,
> sometimes much later during actual use) as well. It hung with both
> nmi_watchdog=1 and nmi_watchdog=2, so it's
> .read = seq_read,
> + .write = lparcfg_write,
> .open = lparcfg_open,
> .release= single_release,
> };
> @@ -581,10 +582,8 @@ int __init lparcfg_init(void)
>
> /* Allow writing if we have FW_FEATURE_SPLPAR */
> if
On Sunday 14 January 2007 1:10 am, Adrian Bunk wrote:
> <-- snip -->
Waiting for Tony to submit bugfixes to his driver...
> ...
> CC drivers/usb/misc/ftdi-elan.o
> /home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/usb/misc/ftdi-elan.c:2307:1:
> warning: "OHCI_QUIRK_ZFMICRO"
1 - 100 of 284 matches
Mail list logo
