Convert uio from nopage to fault.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Cc: linux-kernel@vger.kernel.org
---
drivers/uio/uio.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
Index: linux-2.6/drivers/uio/uio.c
This patchset removes the 'nopage' from the tree.
I've gone through all the drivers and converted them to use fault as best
I can. When using fault, I've also tried to use vmf->pgoff rather than the
virtual address to index the content (which is preferred). Mostly it has
been OK, but DRM is a bit
On Dec 4, 2007 9:59 PM, Hollis Blanchard <[EMAIL PROTECTED]> wrote:
> Hi, I found this thread: http://lkml.org/lkml/2007/4/1/237
>
> I guess the complete patch was never finished? I could sure it (for
> pretty much the same reason as lguest).
It was, but untested (widely). The (google) search
Kjartan Maraas wrote:
> fr., 30.11.2007 kl. 19.39 +0900, skrev Tejun Heo:
>> Kjartan Maraas wrote:
>>> on., 28.11.2007 kl. 10.09 +0900, skrev Tejun Heo:
Kjartan Maraas wrote:
> I get this exact error message on a normal first time boot here. I'm
> using the latest fedora development
On Tue, Dec 04, 2007 at 11:34:32PM -0800, David Miller wrote:
>
> TCP has some built-in assumptions about characteristics of
> interent links and what constitutes a timeout which is "too long"
> and should thus result in a full connection failure.
>
> IPSEC changes this because of IPSEC route
Tejun Heo wrote:
>> It would also simplify the kbuild integration if depmod
>> could read the modules as a space separated list where
>> duplicates are allowed.
>> If we do so then the is no reason to escape to the shell
>> in Makeilfe.build and we do not have to remove duplicates either.
>
> I'm
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 18:16:07 +1100
> Right. This is definitely bad for protocols without a retransmission
> mechanism.
>
> However, is the 0 setting ever useful for TCP and in particular, TCP's
> connect(2) call? Perhaps we can just make that one always
Sam Ravnborg wrote:
> Hi Tejun.
> On Tue, Dec 04, 2007 at 10:55:48PM +0900, Tejun Heo wrote:
>> Kbuild now generates and installs modules.order along with modules.
>> This patch updates depmod such that it sorts module list according to
>> the file before generating output files. Modules which
Tejun Heo wrote:
> WANG Cong wrote:
I think, you forgot to free(3) the memory you calloc(3)'ed and
malloc(3)'ed above.
>>> It's a simple program where whole body is in main(). Why bother?
>>> What's the benefit of adding hash-table iterating free logic?
>>>
>> Personally, I think memory
Hi Tejun.
On Tue, Dec 04, 2007 at 10:55:48PM +0900, Tejun Heo wrote:
> Kbuild now generates and installs modules.order along with modules.
> This patch updates depmod such that it sorts module list according to
> the file before generating output files. Modules which aren't on
> modules.order are
On Tue, Dec 04, 2007 at 11:12:00PM -0800, David Miller wrote:
> From: Herbert Xu <[EMAIL PROTECTED]>
> Date: Wed, 5 Dec 2007 17:51:32 +1100
>
> > Does anybody actually need the 0 setting? What would we break if
> > the default became 1?
>
> I bet there are UDP apps out there that would break if
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 17:51:32 +1100
> Does anybody actually need the 0 setting? What would we break if
> the default became 1?
I bet there are UDP apps out there that would break if we
didn't do this.
Actually, consider even a case like DNS. Let's say the
WANG Cong wrote:
>>> I think, you forgot to free(3) the memory you calloc(3)'ed and
>>> malloc(3)'ed above.
>> It's a simple program where whole body is in main(). Why bother?
>> What's the benefit of adding hash-table iterating free logic?
>>
>
> Personally, I think memory leaks are bugs. And
>> I think, you forgot to free(3) the memory you calloc(3)'ed and
>> malloc(3)'ed above.
>
>It's a simple program where whole body is in main(). Why bother?
>What's the benefit of adding hash-table iterating free logic?
>
Personally, I think memory leaks are bugs. And we hate bugs. ;)
Regards.
On Tue, Dec 04, 2007 at 10:30:23PM -0800, David Miller wrote:
>
> We made an explicit decision not to do things this way.
Thanks for pointing this out.
> Non-blocking has a meaning dependant upon the xfrm_larval_drop sysctl
> setting, and this is across the board. If xfrm_larval_drop is zero,
On Tue, 4 Dec 2007, Robert Hancock wrote:
> Guennadi Liakhovetski wrote:
> >
> > I've got an old 2xP-II @ 400MHz Compaq AP400 system, which I'm still using.
> > It has many peculiarities, so, I wouldn't be surprised if the answer to my
> > questions would be "sorry, the patient is rather dead
The current pci_assign_unassigned_resources() code doesn't work properly
on 32 bits platforms with 64 bits resources. The main reason is the use
of unsigned long in various places instead of resource_size_t.
This fixes it, along with some tricks to avoid casting to 64 bits on
platforms that don't
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 11:12:32 +1100
> [INET]: Export non-blocking flags to proto connect call
>
> Previously we made connect(2) block on IPsec SA resolution. This is
> good in general but not desirable for non-blocking sockets.
>
> To fix this properly
I have am in the process of writing a driver that is software only. I would
like to avoid the caveats of a kernel mode installable module. I found FUSD
(http://svn.xiph.org/trunk/fusd/), but would like to know if this is a stable
project.
If you have any other suggestions on projects,
On 04-12-2007 23:26, Jarek Poplawski wrote:
...
> But, IMHO, blowing ASSERT_RTNL up in a few places shouldn't be much
> worse. After all, how long such a debugging code should be kept. It
> seems, at least sometimes we should be a bit more confident of how
> it's called.
I see this won't be done
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Tue, 04 Dec 2007 12:17:57 -0700
> Ben Greear <[EMAIL PROTECTED]> writes:
>
> > If I *do* need to add some sort of namespace
> > awareness to just achieve today's functionality, I don't mind making the
> > changes,
> > so long as I don't need to
Thanks for clarifying that Linus.
Regards,
David Holmes
Linus Torvalds said the following on 5/12/07 04:06 PM:
On Wed, 5 Dec 2007, David Holmes - Sun Microsystems wrote:
While this was observed with process control signals, my concern was that
other signals might cause
[ CCed netdev ]
On Tue, Dec 04, 2007 at 11:59:32PM -0500, Amos Waterland wrote:
> The difference between ip=off and ip=::off has been a cause of much
> confusion. Document how each behaves, and do not contradict ourselves
> by saying that "off" is the default when in fact "any" is the
From: Ben Greear <[EMAIL PROTECTED]>
Date: Tue, 04 Dec 2007 10:57:01 -0800
> echo add_my_bridge my_br1 eth0 namespaceX eth1 namespaceY >
> /proc/net/foo/config
Each process executes in a namespace, so specifying the namespace
is redundant, just fetch the current process's namespace to pass
into
On Wed, 5 Dec 2007, David Holmes - Sun Microsystems wrote:
>
> While this was observed with process control signals, my concern was that
> other signals might cause pthread_cond_timedwait to return immediately in the
> same way. The test program allows for SIGUSR1 and SIGRTMIN testing as well,
From: Simon Arlott <[EMAIL PROTECTED]>
Date: Tue, 04 Dec 2007 18:53:19 +
> If I have a IPsec rule like:
> spdadd 192.168.7.8 1.2.3.4 any -P out ipsec esp/transport//require;
> (i.e. a remote host 1.2.3.4 which will not respond)
>
> Then any attempt to communicate with 1.2.3.4 will
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Tue, 04 Dec 2007 11:03:01 -0700
> I am confused. I don't see a path forward that feels right.
Eric, instead of writing a book about how you feel, look
at the simple facts and resolve this quickly.
You added a new key, the namespace, to the
2007/12/5, Herbert Xu <[EMAIL PROTECTED]>:
> The idea is to not touch the unicast stuff at all on the multicast path.
>
> Anyway, this was discussed on netdev so please check the archives because
> there is more to this than just changing the multicast handling. We also
> talked about
On Tue, 4 Dec 2007, Linus Torvalds wrote:
>
> Patch looks fine to me.
>
> On Tue, 4 Dec 2007, Steven Rostedt wrote:
> >
> > Note: I'm a bit nervious to add "linux/types.h" and use u32 and u64
> > in thread_info.h, when there's a #ifdef __KERNEL__ just below that.
> > Not sure what that is there
Linus Torvalds said the following on 5/12/07 01:41 PM:
So here's a question for David Holmes: What caused you to actually notice
this behaviour? Can this actually be seen in real life usage?
We observed an application "hang" that turned out to be caused by a
clock mismatch between that used
> I am sorry, i don't understand how this is related to the semantics of
> e.g. longjmp. But, i am sure my patch solves all overflows. Ingo's patch
> can't catch the overflow which is caught by "int i[1000];" in the handler
> function.
Please read the long explanation I wrote, which Ingo
On Wed, Dec 05, 2007 at 02:30:10PM +0900, Joonwoo Park wrote:
>
> @@ -140,9 +147,11 @@ int dev_mc_sync(struct net_device *to, struct net_device
> *from)
> da = next;
> }
> if (!err)
> - __dev_set_rx_mode(to);
> + pending = __dev_set_rx_mode(to);
>
2007/12/5, Herbert Xu <[EMAIL PROTECTED]>:
> Joonwoo Park <[EMAIL PROTECTED]> wrote:
> > Hi,
> > dev_set_rx_mode calls __dev_set_rx_mode with softirq disabled (by
> > netif_tx_lock_bh)
> > therefore __dev_set_promiscuity can be called with softirq disabled.
> > It will cause in_interrupt() to
Roland McGrath wrote::
>>> Thank you for your detailed explanation and patch. I tested your
>>> patch, unfortunately it can not stop all kinds of overflow.
>> [...]
>>> So, the patch I posted is still needed
>> thanks, i've picked up your fix for x86.git, for 2.6.25 merging.
>
> I just
Temporarily at
http://userweb.kernel.org/~akpm/2.6.24-rc4-mm1/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/
- Lots of device IDs have been removed from the e1000 driver and moved over
to e1000e. So if your e1000 stops
* Andrew Morton ([EMAIL PROTECTED]) wrote:
> On Tue, 04 Dec 2007 20:35:32 + Paulo Marques <[EMAIL PROTECTED]> wrote:
>
> > When resolving symbol names from addresses with aliased symbol names,
> > kallsyms_lookup always returns the first symbol, even if it is a weak
> > symbol.
> >
> >
The difference between ip=off and ip=::off has been a cause of much
confusion. Document how each behaves, and do not contradict ourselves
by saying that "off" is the default when in fact "any" is the default
and is descibed as being so lower in the file.
Signed-off-by: Amos Waterland <[EMAIL
Geert Uytterhoeven wrote:
> On Mon, 3 Dec 2007, Milton Miller wrote:
>> Chris, as you can see, PS3 needs to allocate 1/8th of total initial memory to
>> add any more memory. Geoff, can you predict what linear address the
>> additional memory will occupy? Judging from the attempted address toa
Milton Miller wrote:
> On Dec 2, 2007, at 9:59 PM, Geoff Levand wrote:
>
>> Hi.
>>
>> I'm finding that recently kexec'ed kernels on PS3 will
>> panic on startup. It seems the trouble was introduced
>> with the ppc64 SPARSEMEM_VMEMMAP support. The problem
>> is the same when starting either new
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix kernel-doc in drivers/dio/ so that it is formatted correctly
and the parameter names match the function parameters.
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
drivers/dio/dio-driver.c | 70 +
1 file
On Tue, 4 Dec 2007 16:57:38 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Thu, 29 Nov 2007 13:31:50 +0100
> Anders Henke <[EMAIL PROTECTED]> wrote:
>
> > On November 28 2007, Anders Henke wrote:
> > > As "everything is reported as being zero" is quite odd an Jan took a
> > > guess that it
On Tue, 4 Dec 2007, Randy Dunlap wrote:
>
> Steve/David,
>
> where can I find the test case, please?
David attached it to the RH Bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=408321
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Tue, 4 Dec 2007 19:41:32 -0800 (PST) Linus Torvalds wrote:
>
> Patch looks fine to me.
>
> On Tue, 4 Dec 2007, Steven Rostedt wrote:
> >
> > Note: I'm a bit nervious to add "linux/types.h" and use u32 and u64
> > in thread_info.h, when there's a #ifdef __KERNEL__ just below that.
> > Not
Patch looks fine to me.
On Tue, 4 Dec 2007, Steven Rostedt wrote:
>
> Note: I'm a bit nervious to add "linux/types.h" and use u32 and u64
> in thread_info.h, when there's a #ifdef __KERNEL__ just below that.
> Not sure what that is there for.
Hmm. I'd not expect user-mode headers to ever
Use msecs_to_jiffies() and jiffies_to_msecs() in scsi_ioctl().
Sometimes callers use very large values for e.g. vendor specific media
clear command and calculation can overflow.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
block/scsi_ioctl.c |4 ++--
1 file changed, 2 insertions(+), 2
On Wed, 5 Dec 2007 00:41:12 +0100 [EMAIL PROTECTED] (Thomas Bogendoerfer) wrote:
> On Mon, Dec 03, 2007 at 03:53:17PM -0800, Andrew Morton wrote:
> > On Sun, 2 Dec 2007 20:43:46 +0100 (CET)
> > Thomas Bogendoerfer <[EMAIL PROTECTED]> wrote:
> >
> > > New serial driver for SC2681/SC2691 uarts.
David Holmes found a bug in the RT patch with respect to
pthread_cond_timedwait. After trying his test program on the latest git
from mainline, I found the bug was there too. The bug he was seeing
that his test program showed, was that if one were to do a "Ctrl-Z" on a
process that was in the
The current code use a linear algorithm which causes scaling issues
on larger SMP machines. This patch replaces that algorithm with a
2-dimensional bitmap to reduce latencies in the wake-up path.
Signed-off-by: Gregory Haskins <[EMAIL PROTECTED]>
CC: Christoph Lameter <[EMAIL PROTECTED]>
---
We move the rt-overload data as the first global to per-domain
reclassification. This limits the scope of overload related cache-line
bouncing to stay with a specified partition instead of affecting all
cpus in the system.
Finally, we limit the scope of find_lowest_cpu searches to the domain
We add the notion of a root-domain which will be used later to rescope
global variables to per-domain variables. Each exclusive cpuset
essentially defines an island domain by fully partitioning the member cpus
from any other cpuset. However, we currently still maintain some
policy/state as
>>> On Tue, Dec 4, 2007 at 4:27 PM, in message <[EMAIL PROTECTED]>,
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> * Gregory Haskins <[EMAIL PROTECTED]> wrote:
>
>> Ingo,
>>
>> This series applies on GIT commit
>> 2254c2e0184c603f92fc9b81016ff4bb53da622d (2.6.24-rc4 (ish) git HEAD)
>
> please
On Tue, 04 Dec 2007 20:35:32 + Paulo Marques <[EMAIL PROTECTED]> wrote:
> When resolving symbol names from addresses with aliased symbol names,
> kallsyms_lookup always returns the first symbol, even if it is a weak
> symbol.
>
> This patch changes this by sorting the symbols with the weak
Overall, looks nice. Good work.
comments inline below...
On Tue, 04 Dec 2007 20:44:19 -0400, [EMAIL PROTECTED] wrote:
> On Wed, Nov 28, 2007 at 07:34:22PM -0400, Konrad Rzeszutek wrote:
> >
> > This patch adds /sysfs/firmware/ibft/[initiator|targetX|ethernetX]
> > directories along with text
On Tue, 04 Dec 2007 20:35:32 + Paulo Marques <[EMAIL PROTECTED]> wrote:
> When resolving symbol names from addresses with aliased symbol names,
> kallsyms_lookup always returns the first symbol, even if it is a weak
> symbol.
>
> This patch changes this by sorting the symbols with the weak
Sam,
This piece of the top-level Makefile in current git causes an
out-of-tree driver Makefile to fail.
101 ifdef O
102 ifeq ("$(origin O)", "command line")
103 KBUILD_OUTPUT := $(O)
104 endif
105 endif
The out-of-tree driver Makefile contains an O=... directive that
(correctly) does
I finally got around to testing Linux 2.6.24 (2.6.24-rc4) and found
that the it87 driver fails to probe and consequently, my sensors no
longer work. This was fine with Linux 2.6.23.8 (the last kernel I was
using)
The necessary modules load, but:
it87: Found IT8718F chip at 0x290, revision 2
On Wed, 05 Dec 2007 10:30:54 +0900 FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> On Tue, 4 Dec 2007 17:11:55 -0800
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 05 Dec 2007 10:04:03 +0900
> > FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> >
> > > On Tue, 4 Dec 2007 16:57:38 -0800
> > >
On Tue, 2007-12-04 at 17:08 +1100, Benjamin Herrenschmidt wrote:
> The current pci_assign_unassigned_resources() code doesn't work properly
> on 32 bits platforms with 64 bits resources. The main reason is the use
> of unsigned long in various places instead of resource_size_t.
>
> This fixes
Guennadi Liakhovetski wrote:
Hi,
I've got an old 2xP-II @ 400MHz Compaq AP400 system, which I'm still
using. It has many peculiarities, so, I wouldn't be surprised if the
answer to my questions would be "sorry, the patient is rather dead than
alive".
Some of the problems lie in ACPI area,
From: Casey Schaufler <[EMAIL PROTECTED]>
Addresses comments from akpm.
Clean out unnecessary mutex initializations for Smack list locks.
Once this is done, there is no need for them to be shared among
multiple files, so pull them out of the header file and put them
in the files where they
On Wednesday 05 December 2007 07:35:32 Paulo Marques wrote:
> When resolving symbol names from addresses with aliased symbol names,
> kallsyms_lookup always returns the first symbol, even if it is a weak
> symbol.
Thanks, this looks great.
Rusty.
--
To unsubscribe from this list: send the line
On Tue, 4 Dec 2007, Steven Rostedt wrote:
>
> Since arg3 is out, which do you prefer? Creating an arg4 (and perhaps
> more) in the block or having a u64 arg? Changing all the args to u64 may
> be the best.
I suspect that the best option is probably to make that thing a unnamed
union of the
On Tue, Dec 04, 2007 at 06:23:32PM -0500, Jun'ichi Nomura wrote:
> Hi Gary,
>
> Gary Hade wrote:
> > On Tue, Dec 04, 2007 at 02:35:48PM -0500, Jun'ichi Nomura wrote:
> >> On a system with PCI-to-PCI bridges, following errors are observed:
> >>
> >> PCI: Failed to allocate mem resource #8:[EMAIL
On Tue, 4 Dec 2007 17:11:55 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Wed, 05 Dec 2007 10:04:03 +0900
> FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 4 Dec 2007 16:57:38 -0800
> > Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > > On Thu, 29 Nov 2007 13:31:50 +0100
> > >
Justin Piszcz wrote:
The badblocks did not do anything; however, when I built a software raid
5 and the performed a dd:
/usr/bin/time dd if=/dev/zero of=fill_disk bs=1M
I saw this somewhere along the way:
[30189.967531] RAID5 conf printout:
[30189.967576] --- rd:3 wd:3
[30189.967617] disk
On Tue, 4 Dec 2007, Linus Torvalds wrote:
> On Tue, 4 Dec 2007, Steven Rostedt wrote:
> >
> > Seems that arg3 is not used here and since the timer is 64 bits, we can
> > store the bottom 32 bits in arg2 and the top in arg3 (this will work for
> > both 32 and 64 bit archs).
>
> Yes. That should
On Tue, 04 Dec 2007 15:07:49 -0500
Jeff Garzik wrote:
> Vitaly Bordug wrote:
> > With that patch fixed.c now fully emulates MDIO bus, thus no need
> > to duplicate PHY layer functionality. That, in turn, drastically
> > simplifies the code, and drops down line count.
> >
> > As an additional
On Wed, 05 Dec 2007 10:04:03 +0900
FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> On Tue, 4 Dec 2007 16:57:38 -0800
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 29 Nov 2007 13:31:50 +0100
> > Anders Henke <[EMAIL PROTECTED]> wrote:
> >
> > > On November 28 2007, Anders Henke wrote:
>
Chris Friesen wrote:
Over on comp.os.linux.development.system someone asked an interesting
question, and I thought I'd mention it here.
Given a fast low-latency solid state drive, would it ever be beneficial
to simply wait in the kernel for synchronous read/write calls to
complete? The
Jeff Garzik wrote:
Robert Hancock wrote:
This fixes some problems with ATAPI devices on nForce4 controllers in
ADMA mode
on systems with memory located above 4GB. We need to delay setting the
64-bit
DMA mask until the PRD table and padding buffer are allocated so that
they don't
get
On Thu, 29 Nov 2007 13:31:50 +0100
Anders Henke <[EMAIL PROTECTED]> wrote:
> On November 28 2007, Anders Henke wrote:
> > As "everything is reported as being zero" is quite odd an Jan took a
> > guess that it might be block-layer or driver-related, I've assumed
> > that the driver is responsible
Only saw this once, but it's a relatively short time since I moved
to Fedora 8 (i686, UP) and began building my custom kernels
there... apparently starting my 11.1.0.6 Oracle instance caused
lockdep to trigger this (hoping GMail doesn't mangle the
text too badly):
On Tue, 4 Dec 2007 16:44:41 -0800
"Brett T. Warden" <[EMAIL PROTECTED]> wrote:
> Setting aggressive=1 bypasses the friendly auto-detection by polling the
> status register, and instead attempts to initialize the qcam directly. Not
> friendly to other parallel devices, but much more reliable
Add RTC support for DS1511 RTC/WDT chip.
Incorprate changes from feedback:
Remove noinline;
Remove code checking/setting jiffies since last read;
Remove enum typedef.
Signed-off-by: Andy Sharp <[EMAIL PROTECTED]>
---
drivers/rtc/Kconfig | 10 +
On Wed, Nov 28, 2007 at 07:34:22PM -0400, Konrad Rzeszutek wrote:
>
> This patch adds /sysfs/firmware/ibft/[initiator|targetX|ethernetX]
> directories along with text properties which export the the iSCSI Boot
> Firmware Table (iBFT) structure.
>
> What is iSCSI Boot Firmware Table? It is a
Setting aggressive=1 bypasses the friendly auto-detection by polling the status
register, and instead attempts to initialize the qcam directly. Not friendly to
other parallel devices, but much more reliable than the auto-detection.
Signed-off-by: Brett T. Warden <[EMAIL PROTECTED]>
---
On Tue, 4 Dec 2007 13:26:49 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> * Len Brown <[EMAIL PROTECTED]> wrote:
>
> > So while the irq compression code on i386 should really
> > be deleted -- even before merging the x86_64 irq-overhaul,
> > this patch simply disables it on all high
On Thu, Nov 29, 2007 at 11:36:21AM -0400, [EMAIL PROTECTED] wrote:
> > >
> > > /sys/firmware/ibft/ethernet0/pci-bdf
> > > 5:1:0
> >
> > shouldn't this somehow also have a symlink to the kernels ethX view of
> > ethernet devices?
> > (and if so.. how much of the info is duplicated..)
>
> That
On Tue, 4 Dec 2007 16:08:07 -0800
"Jared Hulbert" <[EMAIL PROTECTED]> wrote:
> On Dec 4, 2007 3:24 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
> > > Right. The trend is to hide the nastiness of NAND technology changes
> > > behind controllers. In general I think this is a good thing.
> >
> > You
As usually, if someone finds errors in http://kernelnewbies.org/Linux_2_6_24 ,
let me know it or change it yourself.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
---
diff --git a/drivers/media/video/bw-qcam.c b/drivers/media/video/bw-qcam.c
index 5842352..b74a9cb 100644
--- a/drivers/media/video/bw-qcam.c
+++ b/drivers/media/video/bw-qcam.c
@@ -82,11 +82,16 @@ OTHER DEALINGS IN THE SOFTWARE.
static unsigned int maxpoll=250; /* Maximum busy-loop count
On Wed, Dec 05, 2007 at 12:15:19AM +0100, Adrian Bunk wrote:
> UML can't switch to the regparm(3) convention on i386 since it links
> with userspace code, so if assembler code uses this calling convention
> we need the C prototype of it annotated accordingly.
We're not talking about a global
On Tue, Dec 04, 2007 at 11:45:43PM +0100, Adrian Bunk wrote:
> > the removal of FASTCALL is fine: the default (and only) compiler model
> > for x86 (32-bit) is regparm(3), so the regparm(3) macro is equivalent to
> > the empty one in linux/linkage.h.
> >...
>
> But please ensure that they stay
On Tue, Dec 04, 2007 at 06:53:19PM +, Simon Arlott wrote:
> If I have a IPsec rule like:
> spdadd 192.168.7.8 1.2.3.4 any -P out ipsec esp/transport//require;
> (i.e. a remote host 1.2.3.4 which will not respond)
>
> Then any attempt to communicate with 1.2.3.4 will block, even when
On Dec 4, 2007 3:24 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
> > Right. The trend is to hide the nastiness of NAND technology changes
> > behind controllers. In general I think this is a good thing.
>
> You miss the point - any controller you hide it behind almost inevitably
> adds enough latency
Hi list,
Just built a new machine with a Pioneer SATA DVD drive and linux
distro install CDs are not recognising it. The drive is connected to
the ICH9R southbridge of an Intel P35 chipset motherboard.
I can boot from the CD/DVD so the drive itself is working, but the
kernel reports the
Hi,
On Tuesday, 4 of December 2007, Kristoffer Ericson wrote:
> Hey rafael,
>
> For obvious reasons it would be great to have serial output to be the last to
> enter suspend, thus giving every last drop of debugging
> before actually turning the machine "off".
>
> I'm not aware of any specific
> > Maybe I'm missing something but I don't see it. We want a block
> > interface for these devices, we just need a faster slimmer interface.
> > Maybe a new mtdblock interface that doesn't do erase would be the
> > place for?
>
> Doesn't do erase? MTD has to learn almost all tricks from the
On Tue, Dec 04, 2007 at 12:45:16PM +, Alan Cox wrote:
> > I tried to numbers several months ago and didn't get any response
>
> Please raise it with the relevant people. If our LANANA administrator is
> not doing their job then the Linuxfoundation need to find a replacement,
> or hand
On Mon, Dec 03, 2007 at 03:53:17PM -0800, Andrew Morton wrote:
> On Sun, 2 Dec 2007 20:43:46 +0100 (CET)
> Thomas Bogendoerfer <[EMAIL PROTECTED]> wrote:
>
> > New serial driver for SC2681/SC2691 uarts. Older SNI RM400 machines are
> > using these chips for onboard serial ports.
> >
>
> Little
On Tue, 04 Dec 2007 00:00:01 -0800
Daniel Walker <[EMAIL PROTECTED]> wrote:
> I couldn't find any users, so removing it..
>
> Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>
Acked-by: Alan Cox <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
> Right. The trend is to hide the nastiness of NAND technology changes
> behind controllers. In general I think this is a good thing.
You miss the point - any controller you hide it behind almost inevitably
adds enough latency you don't want to use it synchronously.
Alan
--
To unsubscribe
Hi Gary,
Gary Hade wrote:
> On Tue, Dec 04, 2007 at 02:35:48PM -0500, Jun'ichi Nomura wrote:
>> On a system with PCI-to-PCI bridges, following errors are observed:
>>
>> PCI: Failed to allocate mem resource #8:[EMAIL PROTECTED] for :02:00.0
>> PCI: Failed to allocate mem resource #6:[EMAIL
On Tue, Dec 04, 2007 at 02:57:55PM -0800, Harvey Harrison wrote:
>
> On Tue, 2007-12-04 at 23:45 +0100, Adrian Bunk wrote:
> > On Tue, Dec 04, 2007 at 11:27:17PM +0100, Ingo Molnar wrote:
> > >
> > > * Harvey Harrison <[EMAIL PROTECTED]> wrote:
> > >
> > > > On Tue, 2007-12-04 at 22:32 +0100,
On Tue, 2007-12-04 at 23:45 +0100, Adrian Bunk wrote:
> On Tue, Dec 04, 2007 at 11:27:17PM +0100, Ingo Molnar wrote:
> >
> > * Harvey Harrison <[EMAIL PROTECTED]> wrote:
> >
> > > On Tue, 2007-12-04 at 22:32 +0100, Ingo Molnar wrote:
> > > > * Harvey Harrison <[EMAIL PROTECTED]> wrote:
> > > >
On Tue, 4 December 2007 13:54:21 -0800, Jared Hulbert wrote:
>
> Maybe I'm missing something but I don't see it. We want a block
> interface for these devices, we just need a faster slimmer interface.
> Maybe a new mtdblock interface that doesn't do erase would be the
> place for?
Doesn't do
On Tue, Dec 04, 2007 at 11:27:17PM +0100, Ingo Molnar wrote:
>
> * Harvey Harrison <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 2007-12-04 at 22:32 +0100, Ingo Molnar wrote:
> > > * Harvey Harrison <[EMAIL PROTECTED]> wrote:
> > >
> > > > I'm not sure if the definition of asmlinkage and
Hi Avi,
On Tue, Dec 04, 2007 at 11:07:05PM +0200, Avi Kivity wrote:
> Willy Tarreau wrote:
>
>
> >>>With 10Gbit/s ethernet working you start to care about every cycle.
> >>>
> >>>
> >>If you have 10M packets/sec no amount of cycle-saving will help you.
> >>You need
On Tue, 4 Dec 2007, Steven Rostedt wrote:
>
> Seems that arg3 is not used here and since the timer is 64 bits, we can
> store the bottom 32 bits in arg2 and the top in arg3 (this will work for
> both 32 and 64 bit archs).
Yes. That should work fine.
The restart logic sometimes results in odd
On Tue, Dec 04, 2007 at 04:25:43PM -0500, Liam Howlett wrote:
> @@ -433,15 +433,11 @@ static int nfs_wait_schedule(void *word)
> */
> static int nfs_wait_on_inode(struct inode *inode)
> {
> - struct rpc_clnt *clnt = NFS_CLIENT(inode);
> struct nfs_inode *nfsi = NFS_I(inode);
> -
1 - 100 of 1006 matches
Mail list logo
