From: Eugene Teo <[EMAIL PROTECTED]>
Date: Sat, 19 May 2007 13:13:07 +0800
> skb_peek() might return an empty list. skb should be checked before calling
> llc_pdu_sn_hdr() with it.
>
> Spotted by the Coverity checker.
>
> Signed-off-by: Eugene Teo <[EMAIL PROTECTED]>
The code checks
On Thursday 17 May 2007 02:42, Dave Jones wrote:
> On Thu, May 17, 2007 at 02:09:16AM +0200, Christian wrote:
> > my small VIA C3_2 box does not boot with 2.6.22-rc1.
> > It even does not uncompress the kernel.
> >
> > The configuration as M386 M486 works. But M586 + MVIAC3_2
> > does not
This is the work-in-progress for supporting the newer Marvell PATA/SATA
chips like the 6145.
SATA support works, but PATA support is not implemented at all.
There is some temporary code that makes sure the PATA port is disabled,
if enabled.
This can be found in the 'mv-ahci' branch of
Hi Randy,
Randy Dunlap wrote:
> On Sat, 19 May 2007 13:13:07 +0800 Eugene Teo wrote:
>
>> skb_peek() might return an empty list. skb should be checked before calling
>> llc_pdu_sn_hdr() with it.
>>
>> Spotted by the Coverity checker.
>>
>> Signed-off-by: Eugene Teo <[EMAIL PROTECTED]>
[...]
>
>
Eugene Teo <[EMAIL PROTECTED]> wrote:
>
> diff --git a/net/llc/llc_conn.c b/net/llc/llc_conn.c
> index 3b8cfbe..28a3994 100644
> --- a/net/llc/llc_conn.c
> +++ b/net/llc/llc_conn.c
> @@ -323,7 +323,8 @@ int llc_conn_remove_acked_pdus(struct sock *sk, u8 nr, u16
> *how_many_unacked)
>
>if
Below is a refresh of my on-going effort to convert sata_mv to the new
exception handling framework. sata_mv is one of the last hold-outs, and
its old-EH implementation blocks new features like hotplug and NCQ.
It works for me on the one 50xx and one 60xx card I tested it on, but
other testers
On Fri, May 18, 2007 at 04:19:20PM -0700, Randy Dunlap wrote:
> On Fri, 18 May 2007 14:46:02 -0700 Linda Walsh wrote:
>
> > Randy Dunlap wrote:
> > > On Fri, 18 May 2007 12:32:47 -0700 Linda Walsh wrote:
> > >
> > >
> > >> Seems there is an include of s390 based config in file
> > >>
Since Alan expressed a desire to see Large Block Transfer (LBT) support
in pata_sil680, I though I would re-post my patch for adding LBT support
to sata_sil.
Silicon Image's Large Block Transfer (LBT) support is a vendor-specific
DMA scatter/gather engine, which enables 64-bit DMA addresses
On Sat, 19 May 2007 13:13:07 +0800 Eugene Teo wrote:
> skb_peek() might return an empty list. skb should be checked before calling
> llc_pdu_sn_hdr() with it.
>
> Spotted by the Coverity checker.
>
> Signed-off-by: Eugene Teo <[EMAIL PROTECTED]>
Hi Eugene,
Networking patches need to be sent
It's out there, both patches/tarballs and git trees are updated (although
mirroring might still be ongoing)
Various random fixes all over - the shortlog (appended) is fairly
readable. The most notable ones are probably more SLUB fixes, and the
epoll optimizations and cleanups.
But there's
On Fri, 18 May 2007, Chris Snook wrote:
[EMAIL PROTECTED] wrote:
On Fri, 18 May 2007, Chris Snook wrote:
> [EMAIL PROTECTED] wrote:
> > ---
> >
> >
> > I have Pentium D CPU, which many Windows utilities like
From: Randy Dunlap <[EMAIL PROTECTED]>
Update dontdiff file by adding entries from many .gitignore files.
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
Documentation/dontdiff | 42 +-
1 file changed, 41 insertions(+), 1 deletion(-)
---
skb_peek() might return an empty list. skb should be checked before calling
llc_pdu_sn_hdr() with it.
Spotted by the Coverity checker.
Signed-off-by: Eugene Teo <[EMAIL PROTECTED]>
diff --git a/net/llc/llc_conn.c b/net/llc/llc_conn.c
index 3b8cfbe..28a3994 100644
--- a/net/llc/llc_conn.c
+++
On Wed, May 16, 2007 at 10:31:30PM +0200, Michal Piotrowski wrote:
>
> Cryptography
>
> Subject: cryptomgr oops
> References : http://lkml.org/lkml/2007/5/14/283
> Submitter : Luca Tettamanti <[EMAIL PROTECTED]>
> Handled-By : Herbert Xu <[EMAIL PROTECTED]>
> Status : problem is being
cr4 is a 32-bit register, so casting the mask to an unsigned char is wrong,
as it clears more than the PGE bit.
Signed-off-by: Brian Gerst <[EMAIL PROTECTED]>
---
arch/i386/kernel/cpu/mtrr/cyrix.c |2 +-
arch/i386/kernel/cpu/mtrr/state.c |2 +-
2 files changed, 2 insertions(+), 2
On Fri, May 18, 2007 at 09:16:45PM +0200, Luca Tettamanti wrote:
>
> Output from serial console is enlightening (sort of...):
>
> Loading IPsec SA/SP database from /etc/ipsec-tools.conf: BUG: unable to
> handle kernel paging request at virtual address 6b6b6ceb printing eip:
> b0141aef
> [oops]
On Friday 18 May 2007 18:31:17 Thomas Gleixner wrote:
> On Thu, 2007-05-17 at 12:11 +0530, Anant Nitya wrote:
> > On Friday 11 May 2007 03:28:46 Thomas Gleixner wrote:
> > > Ok, that's consistent with earlier reports. The problem surfaces when
> > > one of the SMT-"cpus" goes idle. The problem
hoping to avoid the madness following my earlier, innocuous question
about the lonely, defconfig'ed module scsi_wait_scan.ko, i'm curious
about why there is, in the entire tree, just one invocation of
"create_freezeable_workqueue":
$ grep -rw create_freezeable_workqueue *
Nick Piggin wrote:
Aside from using branch constructs or hints that help the predictor
guess the right way... I think gcc will move unlikely paths right past
the end of the "likely" fastpath, so it can increase code size and be
somewhat suboptimal in terms of icache usage.
Thanks for the
Jeff Garzik wrote:
Andrew Morton wrote:
On Fri, 18 May 2007 17:54:32 -0400
Phillip Susi <[EMAIL PROTECTED]> wrote:
But as Jeff said, that's not what unlikely is for. It should only be
used when it is unlikely for everybody, all the time, because when it
is right, it helps rather little,
Daniel Walker writes:
> On Fri, 2007-05-18 at 19:06 +0400, Sergei Shtylyov wrote:
> > Well, the decrementer frequency may change, at least in theory (if the
> > bus
> > clock changes).
>
> Does that happen very often?
If it did, gettimeofday would start reporting seriously wrong values,
Sergei Shtylyov writes:
> Yeah, the classic decrementer is programmed off-by-one.
Actually it's programmed off by slightly less than one half on
average, but it doesn't matter since the error doesn't accumulate.
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
John W. Linville wrote:
> First, please send all wireless patches to
> [EMAIL PROTECTED], and be sure to CC me as well...thanks!
>
> On Sat, May 19, 2007 at 12:50:31AM +0800, Eugene Teo wrote:
>> libertas_upload_rx_packet() calls netif_rx() before returning, and it always
>> return 0.
>> Also
Hi John,
John W. Linville wrote:
> On Sat, May 19, 2007 at 01:06:49AM +0800, Eugene Teo wrote:
>> NULL checks should be performed before the dereference.
>>
>> Spotted by the Coverity checker.
>>
>> Signed-off-by: Eugene Teo <[EMAIL PROTECTED]>
>
> This does not apply against 2.6.22-rc1. Please
On Sat, 2007-05-19 at 00:00 +0200, Segher Boessenkool wrote:
> It's not the compiler who decides -- struct layout is
> dictated by the ABI you're compiling for.
This is true in the case of externally-visible stuff. I think the
compiler is permitted to violate the ABI for purely unit-internal
On Sat, 19 May 2007, Nick Piggin wrote:
> Hugh points out that we should make _count and _mapcount atomic_long_t's,
> which would probably be a better use of the space once your vmemmap goes
> in.
Well Andy was going to merge it:
http://marc.info/?l=linux-kernel=117620162415620=2
Andy when are
[PATCH]serial: make early_uart to use early_prarm instead of console_initcall
Make early_uart to use early_param, so uart console can be used earlier.
Make it to be bootconsole with CON_BOOT flag, so can use console handover
feature. and it will switch to corresponding normal serial console
On Fri, 2007-05-18 at 21:55 +0200, matthieu castet wrote:
> > Are you suggesting that this has changed since I did my testing?
> >
> Which version of gcc did you try ?
It was a while ago -- probably 3.2 or something like that. I think it
might even predate the summary support.
When I get home
On 5/18/07, Sergei Shtylyov <[EMAIL PROTECTED]> wrote:
Albert Cahalan wrote:
>>> Sure, but is there any utility in registering more than the
>>> decrementer on PPC?
>> Not yet. I'm not sure I know any other PPC CPU facility fitting
>> for clockevents. In theory, FIT could be used -- but its
On Fri, May 18, 2007 at 10:42:30AM +0100, David Howells wrote:
> Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > I'd like to be the first to propose an increase to the size of struct page
> > just for the sake of increasing it!
>
> Heh. I'm surprised you haven't got more adverse reactions.
>
> >
On Fri, May 18, 2007 at 11:14:26AM -0700, Christoph Lameter wrote:
> On Fri, 18 May 2007, Nick Piggin wrote:
>
> > However we don't have to let those 8 bytes go to waste: we can use them
> > to store the virtual address of the page, which kind of makes sense for
> > 64-bit, because they can
On Fri, May 18, 2007 at 04:42:10PM +0100, Hugh Dickins wrote:
> On Fri, 18 May 2007, Nick Piggin wrote:
> >
> > If we add 8 bytes to struct page on 64-bit machines, it becomes 64 bytes,
> > which is quite a nice number for cache purposes.
> >
> > However we don't have to let those 8 bytes go to
A few years ago I posted a feature request for a .config variable to
enable/disable screen blanking in console and frame buffer, I was told
it wasn't a real problem as userspace code was adequate.
Having used linux for a couple of years to build embedded devices im
having another go :-) It is a
On Sat, 2007-05-19 at 01:49 +0200, Segher Boessenkool wrote:
> > I find it extremely silly to implement it as edge anyway. The EE line
> > is
> > level triggered, and having a mix of edge and level on the same
> > exception without a clean way to retrigger the DEC one other than
> > waiting one
Robert P. J. Day wrote:
On Fri, 18 May 2007, Randy Dunlap wrote:
On Fri, 18 May 2007 14:46:02 -0700 Linda Walsh wrote:
If the standard that other architectures are using is to put their
devices in the crypto directory, then one might expect all crypto
devices to be there. Why should s390
I find it extremely silly to implement it as edge anyway. The EE line
is
level triggered, and having a mix of edge and level on the same
exception without a clean way to retrigger the DEC one other than
waiting one tick is just causing trouble.
It isn't edge triggered, it just automatically
gcc-4.3 appears to have cunningly converted this:
static inline void timespec_add_ns(struct timespec *a, u64 ns)
{
ns += a->tv_nsec;
while(unlikely(ns >= NSEC_PER_SEC)) {
ns -= NSEC_PER_SEC;
a->tv_sec++;
}
a->tv_nsec = ns;
}
into a
On Fri, 18 May 2007, Randy Dunlap wrote:
> On Fri, 18 May 2007 14:46:02 -0700 Linda Walsh wrote:
> > If the standard that other architectures are using is to put their
> > devices in the crypto directory, then one might expect all crypto
> > devices to be there. Why should s390 stick out and
Kuan Luo wrote:
Thanks for your comment, see the explaination inline.
We'll apply your advice in later patch.
...
Please don't duplicate this code in the driver, this is part of libata
core in libata-scsi.c. Add an export for these functions if you need to
use them in the driver.
[kuan]:
On Sat, 19 May 2007, Tomas Carnecky wrote:
> There's no further processing needed in the kernel. The userspace
> application would receive these input events and act accordingly, like:
> read data from the soundcard and send it to the VoIP server, or only
> certain channels based on which
On Fri, 2007-05-18 at 17:41 +0400, Sergei Shtylyov wrote:
> From the "PowerPC Operating Environment Architecture" that I've
> already
> quoated t follows that POWER4-compatible decremented exception *must*
> be edge
> triggered.
>
> > says that an exception is generated when the MSB
Bernd Eckenfels wrote:
On the other server I have some 2GHz HT Xeons which can't be identified on
Intel site because of strange naming pattern.
Google for model and stepping.
... and use x86info.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Fri, 18 May 2007, Andrew Morton wrote:
>
> gcc-4.3 appears to have cunningly converted this:
Very cunning indeed.
Considerign that gcc converted straightforward and simple code to a total
disaster with a 64-bit divide, I'd call it a gcc bug.
> into a divide-by-10 operation, so it
On Fri, 18 May 2007 14:46:02 -0700 Linda Walsh wrote:
> Randy Dunlap wrote:
> > On Fri, 18 May 2007 12:32:47 -0700 Linda Walsh wrote:
> >
> >
> >> Seems there is an include of s390 based config in file
> >> drivers/crypto/Kconfig: source "arch/s390/crypto/Kconfig"
> >>
> >> The line doesn't
H. Peter Anvin wrote:
Sticking kernel mode values in those fields would add no value, except
as a poison (since %ss == KERNEL_DS and would cause a #GP(0) if it ever
reached IRET.)
#SS(0), rather, of course.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Fri, 2007-05-18 at 15:29 -0700, Andrew Morton wrote:
> We use the above idiom in several places. A suitable fix might be to hunt
> down those various sites and then make them call a helper function which
> does
>
> if (unlikely(ns >= NSEC_PER_SEC)) {
> do_div(...)
>
On Fri, May 18, 2007 at 03:29:35PM -0700, Andrew Morton wrote:
>...
> I expect that this optimisation will remain in gcc-4.3 and we'll end up
> having major kernel releases which don't build on i386 with major gcc
> releases, which isn't altogether desirable. I suspect we'll need to fix this
>
On Fri, 18 May 2007 23:37:01 +0200
Christian Leber <[EMAIL PROTECTED]> wrote:
> Hello,
>
> i hit a problem with suspend to ram and especially resume.
> Hardware: Dell Latitude D810 (some Intel 915 with Intel Pentium M)
>
> With 2.6.19.7 suspend to ram works reliable, but with 2.6.20-rc4
> it
Philipp Kohlbecher wrote:
>>
>> In other words, your patch doesn't actually fix anything, it *masks*
>> potential bugs which would also be triggered by interrupts in kernel
>> mode. This is bad.
>
> I am not sure these potential bugs would also be triggered by interrupts
> in kernel mode. After
In article <[EMAIL PROTECTED]> you wrote:
> I found one more interesting thing related with fork
> bombing attack. i have set following in /etc/security/limits.conf file
>
> [EMAIL PROTECTED]hard nproc 3000
> [EMAIL PROTECTED] hard nproc 500
The # is a comment
Hello,
Trivial unbalanced parenthesis macro fix.
Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
diff -upr linux-2.6.22-rc1-mm1-a/include/asm-arm/arch-at91/at91_adc.h
linux-2.6.22-rc1-mm1-b/include/asm-arm/arch-at91/at91_adc.h
---
Andrew Morton wrote:
On Fri, 18 May 2007 17:54:32 -0400
Phillip Susi <[EMAIL PROTECTED]> wrote:
Andrew Morton wrote:
Yes, if you agree with Jeff's original point.
But I don't, actually. Sure, on some machines+workloads, AIO is more
common than sync IO. But I expect that when we sum across
On Fri, 18 May 2007 12:41:24 -0700
[EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=8501
Problem.
gcc-4.3 appears to have cunningly converted this:
static inline void timespec_add_ns(struct timespec *a, u64 ns)
{
ns += a->tv_nsec;
while(unlikely(ns >=
On Fri, 18 May 2007, Lee Revell wrote:
> > Despite it's a Microsoft product, it's actually very nice and useful. A
> > little pad with a few buttons and connectors for a headset. It's an USB
> > device, but it doesn't represent itself as an input/HID device:
> >HID device not claimed by input
On 5/17/07, Tomas Carnecky <[EMAIL PROTECTED]> wrote:
Despite it's a Microsoft product, it's actually very nice and useful. A
little pad with a few buttons and connectors for a headset. It's an USB
device, but it doesn't represent itself as an input/HID device:
HID device not claimed by input
On Friday 18 May 2007, Andrew Morton wrote:
>On Fri, 18 May 2007 23:46:21 +0200
>
>Mariusz Koz__owski <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> > diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h
>> > index 7053026..111f23d 100644
>> > --- a/drivers/net/smc91x.h
>> > +++
Roger Heflin wrote:
> I am getting this bug under heavy IO/NFS on 2.6.21.1.
>
> BUG: sleeping function called from invalid context at mm/mempool.c:210
>
> So far I have got the error I believe 3 times.
>
Is there a backtrace?
-
To unsubscribe from this list: send the line "unsubscribe
> > > diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h
> > > index 7053026..111f23d 100644
> > > --- a/drivers/net/smc91x.h
> > > +++ b/drivers/net/smc91x.h
> > > @@ -279,6 +279,40 @@ SMC_outw(u16 val, void __iomem *ioaddr, int reg)
> >
> > ...
> >
> > > +#define SMC_outb(v, a, r) __ __
On Fri, 18 May 2007 17:54:32 -0400
Phillip Susi <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > Yes, if you agree with Jeff's original point.
> >
> > But I don't, actually. Sure, on some machines+workloads, AIO is more
> > common than sync IO. But I expect that when we sum across all the
I am getting this bug under heavy IO/NFS on 2.6.21.1.
BUG: sleeping function called from invalid context at mm/mempool.c:210
So far I have got the error I believe 3 times.
Roger
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Hello,
i hit a problem with suspend to ram and especially resume.
Hardware: Dell Latitude D810 (some Intel 915 with Intel Pentium M)
With 2.6.19.7 suspend to ram works reliable, but with 2.6.20-rc4
it stopped working reliable.
I still can suspend, but after the first resume it goes back to sleep
Out of curiosity, why would a compiler ever insert padding in a
structure
that has all its elements properly-aligned?
Well, it might decide it would be nicer if some elements were aligned
to
64 bits. Or to a cache line. Or something. I don't care about _why_ --
the point is that it's
On Fri, May 18, 2007 at 04:35:29PM +0200, Martin Mokrejs wrote:
> > How do you know that the corruption was caused by 2.6.21-rc1 ?
> > Isn't it possible that the corruption was created by an earlier
> > kernel, but only detected when a forced fsck was run - which just
> > happened to be while
On Fri, 18 May 2007 23:46:21 +0200
Mariusz Koz__owski <[EMAIL PROTECTED]> wrote:
> Hello,
>
> > diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h
> > index 7053026..111f23d 100644
> > --- a/drivers/net/smc91x.h
> > +++ b/drivers/net/smc91x.h
> > @@ -279,6 +279,40 @@ SMC_outw(u16 val,
Andrew Morton wrote:
Yes, if you agree with Jeff's original point.
But I don't, actually. Sure, on some machines+workloads, AIO is more
common than sync IO. But I expect that when we sum across all the
machines+workloads in the world, sync IO is more common and is hence the
case we should
Hello,
> diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h
> index 7053026..111f23d 100644
> --- a/drivers/net/smc91x.h
> +++ b/drivers/net/smc91x.h
> @@ -279,6 +279,40 @@ SMC_outw(u16 val, void __iomem *ioaddr, int reg)
...
> +#define SMC_outb(v, a, r)
On Fri, 18 May 2007 23:25:52 +0200
"Jiri Slaby" <[EMAIL PROTECTED]> wrote:
> On 5/18/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Fri, 18 May 2007 22:34:53 +0200 (CEST)
> > Jiri Slaby <[EMAIL PROTECTED]> wrote:
> >
> > > @@ -118,7 +125,9 @@ static int phantom_ioctl(struct inode *inode,
Randy Dunlap wrote:
On Fri, 18 May 2007 12:32:47 -0700 Linda Walsh wrote:
Seems there is an include of s390 based config in file
drivers/crypto/Kconfig: source "arch/s390/crypto/Kconfig"
The line doesn't seem to be need for an i386 build (haven't
tried x86_64 though).
I take it that this
Jiri Kosina wrote:
> On Fri, 18 May 2007, Tomas Carnecky wrote:
>> GameVoice is used for VoIP communication between players. It consists of
>> a software and the small pad with eight buttons and connectors for the
>> headset. One of the buttons can be used to mute the microphone, the
>> others
On 18/05/07, Renato Golin <[EMAIL PROTECTED]> wrote:
Problem is, on joydev_connect, when defining the corrections for every
axis, the joystick is reporting dev->absmax = 127 and dev->absmin =
-127 for both axis 0 and 1, so the correction is based on a signed
range when the joystick is actually
On 5/18/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Fri, 18 May 2007 22:34:53 +0200 (CEST)
Jiri Slaby <[EMAIL PROTECTED]> wrote:
> @@ -118,7 +125,9 @@ static int phantom_ioctl(struct inode *inode, struct file
*file, u_int cmd,
> if (r.reg > 7)
> return
"Anand Jahagirdar" <[EMAIL PROTECTED]> writes:
> ulimit are by default set to some value for all users.. root, guest.
> on my machine with FC4 distribution when i typed command "ulimit -u"
> it gave me output as 3055 and another machine having FC6 distribution
> output is 8050. when root or any
On Fri, 18 May 2007, Tomas Carnecky wrote:
> > We don't want neither the 'Telephony' nor 'LEDs' usages to be claimed
> > by the hid-input system, that seems to make a little sense.
> I changed the IS_INPUT_APPLICATION() macro to accept 'Telephony/Headset'
> and now the kernel has created a new
On Fri, 18 May 2007 12:32:47 -0700 Linda Walsh wrote:
> Seems there is an include of s390 based config in file
> drivers/crypto/Kconfig: source "arch/s390/crypto/Kconfig"
>
> The line doesn't seem to be need for an i386 build (haven't
> tried x86_64 though).
>
> I take it that this was a
"Nitin Gupta" <[EMAIL PROTECTED]> writes:
> Facts for LZO (at least for original code. Should hold true for this
> port also - hence the RFC!):
> - The compressor can never overrun buffer.
> - The "non-safe" version of decompressor can never overrun buffer if
> compressed data is unmodified. I am
Andrew Morton wrote:
Yes, if you agree with Jeff's original point.
But I don't, actually. Sure, on some machines+workloads, AIO is more
common than sync IO. But I expect that when we sum across all the
machines+workloads in the world, sync IO is more common and is hence the
case we should
On Fri, 18 May 2007 16:49:49 -0400
"Alex Volkov" <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton wrote:
> > aio is unlikely
> > Stick an unlikely() around is_aio(): I assert that most IO is
> synchronous.
> >
> > -#define in_aio() !is_sync_wait(current->io_wait)
> > +#define in_aio()
On 5/17/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
hey, cool! Also try -v13 - it should be even more tighter.
I tried -v13. However the scheduling "error" is now 10% (vs 2% with -v12).
I also noticed strange behaviour with CPU hotplug. I offlined cpu1
(echo 0
On Friday, May 18, 2007 12:33 pm Luca Tettamanti wrote:
> > Yeah, there's more sharing that could be done... though I don't
> > think the fb layer has the bits to actually grab EDIDs.
>
> There are the I2C functions (fb_do_probe_ddc_edid, fb_ddc_read - I
> wrote them for the radeon driver, but now
On Fri, 18 May 2007, Jan Engelhardt wrote:
> Do we need *this*? (compare procfs)
>
> I believe that shmfs's inodes remain "more" in memory than those of
> procfs. That is, procfs ones can find their way out (we can regenerate
> it), while shmfs/tmpfs/ramfs/etc. should not do that (we'd lose the
On Fri, 18 May 2007 22:34:53 +0200 (CEST)
Jiri Slaby <[EMAIL PROTECTED]> wrote:
> @@ -118,7 +125,9 @@ static int phantom_ioctl(struct inode *inode, struct file
> *file, u_int cmd,
> if (r.reg > 7)
> return -EINVAL;
>
> + spin_lock(>ioctl_lock);
>
On Fri, 18 May 2007, Jan Engelhardt wrote:
>
> On May 18 2007 11:10, [EMAIL PROTECTED] wrote:
> >+
> >+static struct kmem_cache_ops ext2_kmem_cache_ops = {
> >+ext2_get_inodes,
> >+kick_inodes
> >+};
> >+
>
> We love C99 names:
>
> static struct kmem_cache_ops ext2_kmem_cache_ops = {
>
Make the bay driver send env information on bay events.
Upon any bay event, we will send the string "BAY_EVENT=%d" along with the
KOBJ_CHANGE, and report the event number. What the event number means will
be platform specific. Event 3 is always an eject request, but an insert
may be either
Andrew Morton wrote:
> aio is unlikely
> Stick an unlikely() around is_aio(): I assert that most IO is
synchronous.
>
> -#define in_aio() !is_sync_wait(current->io_wait)
> +#define in_aio() (unlikely(!is_sync_wait(current->io_wait)))
> Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
> > >
Luca Tettamanti wrote:
> Il Fri, May 18, 2007 at 11:14:55PM +1000, Herbert Xu ha scritto:
>> On Fri, May 18, 2007 at 02:09:54PM +0200, Luca wrote:
>>> Well, pretty sure. The OOPS says 2.6.22-rc1-libata-g705962cc-dirty,
>>> git agrees and I've done a full rebuild. The .config is generated
>>>
On Fri, May 18, 2007 at 10:27:06PM +0200, Jan Engelhardt wrote:
>
> On May 18 2007 17:02, John Sigler wrote:
> >
> > I'm getting "disagrees about version of symbol struct_module" messages,
> > and I'm trying to understand why.
> >
> > As far as I understand (which is not very far), if I define
>
On May 18 2007 11:10, [EMAIL PROTECTED] wrote:
>
>Index: slub/mm/shmem.c
>===
>--- slub.orig/mm/shmem.c 2007-05-18 00:54:30.0 -0700
>+++ slub/mm/shmem.c2007-05-18 01:02:26.0 -0700
Do we need *this*?
> I wonder if there are other uses for the free space?
unsigned long moreflags;
Nick and Hugh were just sparring over adding a couple (or perhaps 8)
flag bits. This would supply 64 new bits ... maybe that would keep
them happy for a few more years.
-Tony
-
To unsubscribe from this
On May 18 2007 11:10, [EMAIL PROTECTED] wrote:
>+
>+static struct kmem_cache_ops ext2_kmem_cache_ops = {
>+ ext2_get_inodes,
>+ kick_inodes
>+};
>+
We love C99 names:
static struct kmem_cache_ops ext2_kmem_cache_ops = {
.get = ext2_get_inodes,
.kick = kick_inodes,
};
cleanup_workqueue_thread() and cwq_should_stop() are overcomplicated. Convert
the code to use kthread_should_stop/kthread_stop as was suggested by Gautham
and Srivatsa.
In particular this patch removes the (unlikely) busy-wait loop from the exit
path, it was a temporary and ugly kludge (if not a
phantom, move to unlocked_ioctl
phantom's ioctl is often (4000 times a sec or so) invoked, don't acquire BKL
and block other processes.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
commit 79b7336ec18e967de0026d2cc08de47da6333761
tree d180d46c4bf38ee42adf8949e9f746f893aae32b
parent
In article <[EMAIL PROTECTED]> you wrote:
> Am I right that is chipset on mainboard, who is saying - "I know", not
> CPU itself?
It is a feature bitfield read directly from the CPU.
> Is it better to switch off HT support in BIOS?
The CPU will still report that flag. Might speed up the
Hi,
David Woodhouse wrote:
On Thu, 2007-05-17 at 20:30 +, Matthieu CASTET wrote:
On arch that don't support aligned access, packed struct access will be
done byte per byte (but it could be the expected behavior if there
unaligned access).
When I tested this on ARM, the output for
From: Kumar Gala <[EMAIL PROTECTED]>
Date: Fri, 18 May 2007 11:31:19 -0500
> I asked this earlier, but figured you might have a better insight.
> Is their value in having 'drivers' for more than one clock source?
> I'd say most (of not all) the PPC SoCs have timers on the system side
>
On 05/18, Zilvinas Valinskas wrote:
>
> On Thu, 2007-05-17 at 22:45 +0400, Oleg Nesterov wrote:
> >
> > However, I can't understand why cleanup_workqueue_thread() hangs anyway.
> > It shouldn't. Looks like rpciod/1 was preempted, and can't get CPU.
> > According
> > to kernel-nfs-freeze.log it is
On May 18 2007 17:02, John Sigler wrote:
>
> I'm getting "disagrees about version of symbol struct_module" messages,
> and I'm trying to understand why.
>
> As far as I understand (which is not very far), if I define
> CONFIG_MODVERSIONS, then checksums for various functions (all exported
>
Jesper Juhl wrote:
Various other documents that are worth reading in the kernel source :
I have also compiled some helpful hints on how to get
source code accepted into the upstream kernel:
http://kernelnewbies.org/UpstreamMerge
The kernel-mentors mailing list is another useful
resource you
On Fri, May 18, 2007 at 03:28:31PM +0530, Nitin Gupta wrote:
> +/* lzo1x.h -- public interface of the LZO1X compression algorithm
> +
> + This file is part of the LZO real-time data compression library.
> +
> + Copyright (C) 2005 Markus Franz Xaver Johannes Oberhumer
> + Copyright (C) 2004
David Woodhouse wrote:
On Thu, 2007-05-17 at 20:30 +, Matthieu CASTET wrote:
On Thu, 17 May 2007 10:29:31 -0700, Andrew Morton wrote:
On Thu, 17 May 2007 18:09:50 +0300 Artem Bityutskiy
When I tested this on ARM, the output for je32_to_cpu et al was fine.
For _other_ structures where I'd
[EMAIL PROTECTED] wrote:
On Fri, 18 May 2007, Chris Snook wrote:
[EMAIL PROTECTED] wrote:
---
I have Pentium D CPU, which many Windows utilities like cpuz, wcpuid,
everest identify as D 930 (Dual Core, 3GHz). From
1 - 100 of 773 matches
Mail list logo
