* Esben Nielsen <[EMAIL PROTECTED]> wrote:
> I noticed that you changed rw-locks to behave quite diferently under
> real-time preemption: They basicly works like normal locks now. I.e.
> there can only be one reader task within each region. This can can
> however lock the region recursively.
> I thought that this was the original purpose of the "stack randomization"
> which is shipped for example by RedHat kernels, as the randomization is
> quite small and easy to bruteforce, so it can't serve too much as a buffer
> overflow protection.
correct; that was for the p4 hyperthreading
On Thursday 27 January 2005 11:15, Vojtech Pavlik wrote:
> > I think that the very first path ("while true; do xset led 3; xset
> > -led 3; done" makes keyboard miss release events and makes it
> > unusable) should go in 2.6.11 so please do:
> >
> > bk pull bk://dtor.bkbits.net/for-2.6.11
> I will be glad to work with on this, I have some exposure to the BMC. See
> text below in blue.
>
> bukie
>
> Corey Minyard wrote:
>
>> Mark Studebaker wrote:
>>
>> > is there a way to do this solely in i2c-core without having to
>> > add support to all the drivers?
>>
>> Yes and no. In order
* Gene Heskett <[EMAIL PROTECTED]> wrote:
> Normal zone: 225280 pages, LIFO batch:16
> HighMem zone: 32752 pages, LIFO batch:7
> DMI 2.2 present.
> __iounmap: bad address c00f <-why?
> ACPI: RSDP (v000 Nvidia) @ 0x000f7220
I have no idea what is causing
On Saturday 15 January 2005 08:16, Victor Hahn wrote:
> Jan 15 13:33:36 vic kernel: psmouse.c: bad data from KBC - bad parity
> Jan 15 13:33:38 vic kernel: psmouse.c: Wheel Mouse at
> isa0060/serio1/input0 lost
> synchronization, throwing 3 bytes away.
>
> Sometimes, only one of these messages
On Thu, Jan 27 2005, Doug Maxey wrote:
>
> On Thu, 27 Jan 2005 13:02:48 +0100, Jens Axboe wrote:
> >Hi,
> >
> >For the longest time, only the old PATA drivers supported barrier writes
> >with journalled file systems. This patch adds support for the same type
> >of cache flushing barriers that
On Thu, Jan 27 2005, Jeff Garzik wrote:
> Doug Maxey wrote:
> >On Thu, 27 Jan 2005 13:02:48 +0100, Jens Axboe wrote:
> >
> >>Hi,
> >>
> >>For the longest time, only the old PATA drivers supported barrier writes
> >>with journalled file systems. This patch adds support for the same type
> >>of
On Fri, Jan 28, 2005 at 03:09:40PM +, Hugh Dickins wrote:
> > > BTW do you know if there is any plans for 2.6++ to actually use
> > > RLIMIT_RSS? I saw a hint in that direction in mm/thrash.c
> > > grab_swap_token but it is commented out and only skeleton code...
> >
> > Nope, RLIMIT_RSS does
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> But the important elements are lost. The standard provides a
> deterministic scheduling order, and a deterministic scheduling latency
> (of course this doesn't mean a great deal for Linux, but I think we're
> good enough for a lot of soft-rt
Linus Torvalds wrote:
>
> On Fri, 28 Jan 2005, Jaco Kroon wrote:
>
ok, how would I try this? Where can I find an example to code it
from?
Sorry, I should probably be grepping ...
>>>
>>>If the udelay() didn't work, then this one isn't worth worryign about
>>>either. Back to the drawing
Ingo Molnar <[EMAIL PROTECTED]> writes:
>
> interestingly, the x86 spinlock implementation uses a LOCK-ed
> instruction only on acquire - it uses a simple atomic write (and
> implicit barrier assumption) on the way out:
>
> #define spin_unlock_string \
> "movb $1,%0" \
>
* Jirka Kosina <[EMAIL PROTECTED]> wrote:
> Also, besides security implications of stack randomization, there is
> one more aspect that should not be forgotten - stack randomization
> (even for quite small range) could be useful to distribute a pressure
> on cache (which may not be fully
On Thu, 27 Jan 2005, William Lee Irwin III wrote:
>> The intention was to disallow vmas starting at 0 categorically. i.e. it
>> is very intentional to deny the MREMAP_FIXED to 0 case of mremap().
>> It was also the intention to deny the MAP_FIXED to 0 case of mmap(),
>> though I didn't actually
Hi.
On Fri, 2005-01-28 at 13:25, James Morris wrote:
> On Fri, 28 Jan 2005, Nigel Cunningham wrote:
>
> > You normally test cryptoapi functionality while booting?
>
> This happens if you link tcrypt statically into the kernel.
Yes, but why would you? Oh well. Doesn't matter ;>
Nigel
--
Nigel
On Thu, 27 Jan 2005 17:58:37 -0800
Scott Feldman <[EMAIL PROTECTED]> wrote:
> eepro100 does a copy if pkt_len < rx_copybreak, otherwise it send up the
> skb and allocates and links a new one in it's place (see
> speedo_rx_link).
My bad, you're right. So I wonder too what the difference
is that
Ingo wrote:
> if by 'some CPUs' you mean x86 then it's the LOCK prefixed ops ...
Yup - that's the one. Thanks.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373,
Hi Anton,
On Thu, Jan 27, 2005 at 04:58:22PM -0800, Andrew Morton wrote:
> Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
> >
> > What would you propose can I do to perform the required zeroing in a
> > deadlock safe manner whilst also ensuring that it cannot happen that a
> > concurrent
Mark Studebaker wrote:
is there a way to do this solely in i2c-core without having to
add support to all the drivers?
Yes and no. In order to support this async operation, the driver cannot
block and do things like msleep() or schedule(). It has to start the
operation, return, and either let
* Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> Some numbers to make this more transparent.
>
> Machine: PIII Celeron 333MHz
> RT - T0: 1ms cyclic
> RT - T1: 2ms cyclic
>
>
> Load average is ~4.0 for all tests. The numbers are maximum deviation
> from the timeline in microseconds. Test
* George Anzinger wrote:
> Ingo, I have been looking at the code being proposed by John Stultz.
> It looks like it handles all the issues I am talking about here. I
> think it would be best to leave the RT patch as it is WRT this issue
> and work on getting John's patch ready for prime time
* Paul Jackson <[EMAIL PROTECTED]> wrote:
> A long time ago, Linus wrote:
> > An atomic op is pretty much as expensive as a spinlock/unlock pair on x86.
> > Not _quite_, but it's pretty close.
>
> Are both read and modify atomic ops relatively expensive on some CPUs,
> or is it just modify
On Thursday 27 January 2005 11:47, Michael Gernoth wrote:
> Hi,
>
> since the introduction of libps2 in the mainline 2.6 kernel I had the
> issue that my keyboard[1] was no longer recognized.
> The cause of this is that my "keyboard" responds to all commands with
> an acknowledgement (0xFA), even
Hi, Jeff
There is a bug about ULi M526X. It cannot deal with the dummy descriptor.
For example:
Des0:0x8000
Des1:0
Des2:0
Des3:pointer to next descriptor
This patch is applied to kernel 2.6.10. Please apply to new kernels. Thanks
a lot.
Signed-off-by: Clear Zhang <[EMAIL PROTECTED]>
BRs,
your .config can't match that kernel...
all the debugging is from the i830 drm module, so somehow that is
getting loaded at some stage... if you are using X 6.8.0 you need the
i915 (like the config has...)
you might have an i830 module somewhere on your system that is getting loaded..
Dave.
>
Julien TINNES <[EMAIL PROTECTED]> said:
> Not very important but ((get_random_int() % 4096) << 4) could be
> optimized into get_random_int() & 0xFFF0.
Check first if the compiler doesn't do it by itself.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de
On Thu, 27 Jan 2005, Jeff Garzik wrote:
> David Sims wrote:
> > Hi,
> >
> > I have posted a couple of times in the past to no avail... I have an
> > Intel 31244 SATA controller that is supposed to work with the sata_vsc
> > driver module... It does in fact, almost
> >
> > You can
Reading through the tree, I see that some callers of get_user_pages()
release the pages that they got via put_page(), and some callers use
page_cache_release(). Of course has
#define page_cache_release(page) put_page(page)
so this is really not much of a difference, but I'd like
On Fri, 2005-01-28 at 02:33 +0100, Patrick McHardy wrote:
> David S. Miller wrote:
>
> >I've forwarded this to netfilter-devel for inspection.
> >Thanks for collecting all the data points so well.
> >
> Here is the fix for everyone. Please report back if it doesn't
> solve the problem. Thanks.
On Thu, Jan 27, 2005 at 07:43:34PM +0100, Pavel Machek wrote:
> Hi!
>
> It happened for 3rd in a week now...
>
> When problem happens, processes start to segfault, usually right
> during startup. Programs that were loaded prior to problem usualy
> works, and can be restarted. I also seen
I didn't look at the trace. My only problem is in saving new files. I
can copy an old one, rename it and start, empty it and save fine. I just
can't save new ones.
Anyway, I hope this gets fixed. I am running pure rawhide Fedora Core,
just so you know... latest of everything.
Trever
On Thu,
Andy Isaacson wrote:
On Thu, Jan 27, 2005 at 07:00:32PM -0500, Jeff Garzik wrote:
The attached changelog describes what I just pushed out to BitKeeper
(and what should be appearing in the next -mm release from Andrew).
Note to BK users: please re-clone netdev-2.6, don't just 'bk pull'.
It's
On Fri, 28 Jan 2005, Nigel Cunningham wrote:
> You normally test cryptoapi functionality while booting?
This happens if you link tcrypt statically into the kernel.
- James
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Thu, Jan 27, 2005 at 07:00:32PM -0500, Jeff Garzik wrote:
> The attached changelog describes what I just pushed out to BitKeeper
> (and what should be appearing in the next -mm release from Andrew).
>
> Note to BK users: please re-clone netdev-2.6, don't just 'bk pull'.
It's much more
True - thanks - including the part about the cost of locking bugs.
My question was poorly phrased - the code speaks the answer to the
real question I had:
$ grep define.atomic_ include/asm-ia64/atomic.h | head -2
#define atomic_read(v) ((v)->counter)
#define atomic_set(v,i)
Noticed this oops today when setting up a box with a i865G chipset:
I'm using Xorg 6.8.0.
I also experience virtual terminal corruption when I switch to any of
them after X starts up.
Thanks.
-- James Lamanna
drm:i830_dma_initialize] *ERROR* can not find dma buffer map!
[drm:i830_irq_emit]
On Thu, 2005-01-27 at 16:48, David S. Miller wrote:
> On Fri, 28 Jan 2005 00:14:30 +
> Russell King <[EMAIL PROTECTED]> wrote:
>
> > The fact of the matter is that eepro100.c works on ARM, e100.c doesn't.
> > There's a message from me back on 30th June 2004 at about 10:30 BST on
> > this very
David Sims wrote:
Hi,
I have posted a couple of times in the past to no avail... I have an
Intel 31244 SATA controller that is supposed to work with the sata_vsc
driver module... It does in fact, almost
You can insert the module in a running kernel and after barking as
follows (once for
Hi.
You normally test cryptoapi functionality while booting?
Anyway, I can confirm that if suspend2 touches anything remotely related
to this, it's unintentional and I'll fix it :>
Nigel
On Fri, 2005-01-28 at 10:30, Jasper Spaans wrote:
> Hi List,
>
> When booting I see this in dmesg:
>
>
Hi,
I have posted a couple of times in the past to no avail... I have an
Intel 31244 SATA controller that is supposed to work with the sata_vsc
driver module... It does in fact, almost
You can insert the module in a running kernel and after barking as
follows (once for each disk
On Fri, 28 Jan 2005, Jasper Spaans wrote:
> On Thu, Jan 27, 2005 at 07:38:43PM -0500, James Morris wrote:
> > > Is this supposed to happen?
> >
> > No. What is your kernel version?
>
> Current bitkeeper + latest swsusp2 patches and hostap driver, however, those
> two don't come near touching
On Fri, Jan 28, 2005 at 12:17:01AM +, Russell King wrote:
> On Thu, Jan 27, 2005 at 12:33:26PM -0800, David S. Miller wrote:
> > So they won't be listed in /proc/net/rt_cache (since they've been
> > removed from the lookup table) but they will be accounted for in
> > /proc/net/stat/rt_cache
David S. Miller wrote:
I've forwarded this to netfilter-devel for inspection.
Thanks for collecting all the data points so well.
Here is the fix for everyone. Please report back if it doesn't
solve the problem. Thanks.
= net/ipv4/netfilter/ip_nat_proto_tcp.c 1.10 vs edited =
---
On Thu, 2005-01-27 at 14:08 +, David Howells wrote:
> Signed-Off-By: David Howells <[EMAIL PROTECTED]>
Excellent. Thanks David!
Rusty.
--
A bad analogy is like a leaky screwdriver -- Richard Braakman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Roland Dreier wrote:
Julien> Not very important but ((get_random_int() % 4096) << 4)
Julien> could be optimized into get_random_int() & 0xFFF0.
HPA> .. and gcc knows that.
HPA>8: 25 ff 0f 00 00 and$0xfff,%eax
HPA>d: 83 c4 0cadd
On Thu, 27 Jan 2005, Paul Jackson wrote:
>
> A long time ago, Linus wrote:
> > An atomic op is pretty much as expensive as a spinlock/unlock pair on x86.
> > Not _quite_, but it's pretty close.
>
> Are both read and modify atomic ops relatively expensive on some CPUs,
> or is it just modify
Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
>
> What would you propose can I do to perform the required zeroing in a
> deadlock safe manner whilst also ensuring that it cannot happen that a
> concurrent ->readpage() will cause me to miss a page and thus end up
> with non-initialized/random data
On Fri, 28 Jan 2005 00:14:30 +
Russell King <[EMAIL PROTECTED]> wrote:
> The fact of the matter is that eepro100.c works on ARM, e100.c doesn't.
> There's a message from me back on 30th June 2004 at about 10:30 BST on
> this very list which generated almost no interest from anyone...
I see.
On Thu, Jan 27, 2005 at 07:38:43PM -0500, James Morris wrote:
> > Is this supposed to happen?
>
> No. What is your kernel version?
Current bitkeeper + latest swsusp2 patches and hostap driver, however, those
two don't come near touching the crypto stuff[1] so they're not really on my
suspect
A long time ago, Linus wrote:
> An atomic op is pretty much as expensive as a spinlock/unlock pair on x86.
> Not _quite_, but it's pretty close.
Are both read and modify atomic ops relatively expensive on some CPUs,
or is it just modify atomic ops?
(Ignoring for this question the possibility
On Fri, Jan 28, 2005 at 12:14:30AM +, Russell King wrote:
> The fact of the matter is that eepro100.c works on ARM, e100.c doesn't.
Hmmm, I recall e100 working fine on a Radisys ENP-2611, which has a
IXP2400 (xscale) in big-endian mode, running 2.6. This particular
board had its root fs
This patch removes references to the pcxx driver in MAINTAINERS.
Signed-off-by: James Nelson <[EMAIL PROTECTED]>
diff -urN --exclude='*~' linux-2.6.11-rc2-mm1-original/MAINTAINERS
linux-2.6.11-rc2-mm1/MAINTAINERS
--- linux-2.6.11-rc2-mm1-original/MAINTAINERS 2005-01-24 17:16:10.0
Hi,
On Thu, 27 Jan 2005, Andries Brouwer wrote:
> In short - raw mode in 2.6 is badly broken.
I think not just that. The whole keyboard input layer needs some serious
review. Just the complete lack of any locking is frightening, I'd really
like to know how the input layer could become the
On Fri, 28 Jan 2005 00:17:01 +
Russell King <[EMAIL PROTECTED]> wrote:
> Yes. Someone suggested this evening that there may have been a recent
> change to do with some IPv6 refcounting which may have caused this
> problem. Is that something you can confirm?
Yep, it would be this change
On Fri, 28 Jan 2005, Jasper Spaans wrote:
> Is this supposed to happen?
No. What is your kernel version?
- James
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
This series of patches is to remove the pcxx driver. It is obsoleted by the
epca
driver.
These patches go together.
Diffstat:
MAINTAINERS |7
drivers/char/Kconfig | 17
drivers/char/Makefile|1
drivers/char/digi_bios.h | 177 ---
drivers/char/digi_fep.h | 517
Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
>
> And they had not necessairly hardware access. They "might" have hardware
> access.
On x86 we could perhaps test for non-nullness of tsk->thread->io_bitmap_ptr?
> I thought I could wait the other patches
> to be merged to avoid confusion before
On Thursday 27 January 2005 18:04, Len Brown wrote:
> Thanks for the patch Adrian.
>
> I agree that this is the right direction to go -- enforcing APIs with
> the use of static reduces the possibility of programming errors --
> particularly with many cooks in the kitchen. ÂIndeed, just on Monday
Hi,
some thoughts and observations.
I'm running -RT + a port of UTIME (the grandfather of HRT, IIRC) on a
couple of machines (x86,ppc,arm - all UP) here.
One part of the problem is the gettimeofday() issue, which seems to be
already addressed by John Stulz's patches.
The more interresting
On Thu, Jan 27, 2005 at 03:35:35PM -0800, Andrew Morton wrote:
> On x86 we could perhaps test for non-nullness of tsk->thread->io_bitmap_ptr?
yes for ioports. But I'm afraid I was too optimistic about eflags for
iopl, that's not in the per-task tss, it's only stored at the very top
of the kernel
This patch adds CAP_SYS_ADMIN checks to the potentially dangerous ioctls
FLASH_Erase and FLASH_Burn
in the Cobalt LCD interface driver.
Signed-off-by: James Nelson <[EMAIL PROTECTED]>
diff -purN --exclude='*~' linux-2.4.29-original/drivers/char/lcd.c
linux-2.4.29/drivers/char/lcd.c
---
This patch fixes a memory leak in the FLASH_Burn ioctl for the Cobalt LCD
interface driver.
Signed-off-by: James Nelson <[EMAIL PROTECTED]>
diff -purN --exclude='*~' linux-2.4.29-original/drivers/char/lcd.c
linux-2.4.29/drivers/char/lcd.c
--- linux-2.4.29-original/drivers/char/lcd.c
On Thu, 27 Jan 2005, John Richard Moser wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill Davidsen wrote:
On Thu, 27 Jan 2005, Zan Lynx wrote:
On Thu, 2005-01-27 at 10:37 -0600, Jesse Pollard wrote:
On Wednesday 26 January 2005 13:56, Bill Davidsen wrote:
On Wed, 26 Jan 2005, Jesse
Julien> Not very important but ((get_random_int() % 4096) << 4)
Julien> could be optimized into get_random_int() & 0xFFF0.
HPA> .. and gcc knows that.
HPA>8: 25 ff 0f 00 00 and$0xfff,%eax
HPA>d: 83 c4 0cadd$0xc,%esp
HPA> 10:
On Thu, Jan 27, 2005 at 12:33:26PM -0800, David S. Miller wrote:
> So they won't be listed in /proc/net/rt_cache (since they've been
> removed from the lookup table) but they will be accounted for in
> /proc/net/stat/rt_cache until the final release is done on the
> routing cache object and it can
is there a way to do this solely in i2c-core without having to
add support to all the drivers?
Corey Minyard wrote:
I have an IPMI interface driver that sits on top of the I2C code. I'd
like to get it into the mainstream kernel, but I have a few problems
to solve first before I can do that. The
On Thu, Jan 27, 2005 at 03:31:14PM -0800, David S. Miller wrote:
> Therefore the only missing sync would be of the new RX descriptor
> when linking things in like that, ie. at the end of e100_rx_alloc_skb()
> if rx->prev->skb is non-NULL.
And that is inherently unsafe, since the chip may be
Zan Lynx <[EMAIL PROTECTED]> writes:
> In the reality I'm familiar with, the defense contractor's secure
> projects building had one entrance, guarded by security guards who were
> not cheap $10/hr guys, with strict instructions. No computers or
> computer media were allowed to leave the
The attached changelog describes what I just pushed out to BitKeeper
(and what should be appearing in the next -mm release from Andrew).
Note to BK users: please re-clone netdev-2.6, don't just 'bk pull'.
Most of this is simply stuff that is "hanging out for a while" in
netdev-2.6 while it --
Hi List,
When booting I see this in dmesg:
testing tea ECB encryption
test 1 (128 bit key):
0a3aea4140a9ba94
fail
test 2 (128 bit key):
775d2a6af6ce9209
fail
test 3 (128 bit key):
be7abb81952d1f1edd89a1250421df95
fail
test 4 (128 bit key):
On Thu, 27 Jan 2005, Evgeniy Polyakov wrote:
> On Thu, 27 Jan 2005 10:19:51 -0500
> Bill Davidsen <[EMAIL PROTECTED]> wrote:
>
> > Evgeniy Polyakov wrote:
> > > On Mon, 24 Jan 2005 18:54:49 +0100
> > > Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > >>It seems noone who reviewed the
Followup to: <[EMAIL PROTECTED]>
By author:Julien TINNES <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Not very important but ((get_random_int() % 4096) << 4) could be
> optimized into get_random_int() & 0xFFF0. Because 4096 is a power of 2
> you won't loose any entropy by doing &
On Fri, 28 Jan 2005, ierdnah wrote:
>
> is this patch better? should i test this too?
You probably should. The patch you've tested is really ugly, and not a fix
at all - it's really just depending on the compiler generating a specific
code sequence that will hide the race. As such, it's a
On Thu, 27 Jan 2005 22:57:25 +
Russell King <[EMAIL PROTECTED]> wrote:
> Has e100 actually been fixed to use the PCI DMA API correctly yet?
It seems to be doing the right thing. I see the DMA sync calls
(properly using cpu vs. device syncing variants) at the right
spots, and the only thing
I've forwarded this to netfilter-devel for inspection.
Thanks for collecting all the data points so well.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 27 Jan 2005, Zan Lynx wrote:
> On Thu, 2005-01-27 at 10:37 -0600, Jesse Pollard wrote:
> > On Wednesday 26 January 2005 13:56, Bill Davidsen wrote:
> > > On Wed, 26 Jan 2005, Jesse Pollard wrote:
> > > > On Tuesday 25 January 2005 15:05, linux-os wrote:
> > > > > This isn't relevant at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill Davidsen wrote:
> On Thu, 27 Jan 2005, Zan Lynx wrote:
>
>
>>On Thu, 2005-01-27 at 10:37 -0600, Jesse Pollard wrote:
>>
>>>On Wednesday 26 January 2005 13:56, Bill Davidsen wrote:
>>>
On Wed, 26 Jan 2005, Jesse Pollard wrote:
>On
On Thu, 2005-01-27 at 22:45 +0100, Timo Kamph wrote:
> I guess you did somthing like this:
>
> 2.6.7 -patch-> 2.6.8 -patch-> 2.6.8.1 -patch-> 2.6.9 -patch-> 2.6.10.
>
> And you didn't noticed that the 2.6.9 patch failed, because it is diffed
> against 2.6.8 and not 2.6.8.1!
You're perfectly
On Thursday 27 January 2005 17:36, Linus Torvalds wrote:
> > I also tried increasing the total timeout value to about 5 seconds
> > (versus the default half second), still no success, so the device is
> > simply not sending back the requested values.
>
> If it was the other way around (that it
From strace output which Trever sent, OO.o seems to be getting many
-EINTRs (Interrupted System Call) which are attempted to be restarted
but again recieve EINTR when restarted. (futex, accept and poll are the
ones which get EINTR).
Whereas, when OO.o successfully starts up on my machine, I
This patch removes drivers/char/fep.h
It depends on the previous patches.
Signed-off-by: James Nelson <[EMAIL PROTECTED]>
diff -urN --exclude='*~' linux-2.6.11-rc2-mm1-original/drivers/char/fep.h
linux-2.6.11-rc2-mm1/drivers/char/fep.h
--- linux-2.6.11-rc2-mm1-original/drivers/char/fep.h
This patch removes drivers/char/digi_bios.h
It depends on the previous patches.
Signed-off-by: James Nelson <[EMAIL PROTECTED]>
diff -urN --exclude='*~' linux-2.6.11-rc2-mm1-original/drivers/char/digi_bios.h
linux-2.6.11-rc2-mm1/drivers/char/digi_bios.h
---
This patch removes drivers/char/digi_fep.h
It depends on the previous patches.
Signed-off-by: James Nelson <[EMAIL PROTECTED]>
diff -urN --exclude='*~' linux-2.6.11-rc2-mm1-original/drivers/char/digi_fep.h
linux-2.6.11-rc2-mm1/drivers/char/digi_fep.h
---
This patch removes drivers/char/pcxx.h
It depends on the previous patches.
Signed-off-by: James Nelson <[EMAIL PROTECTED]>
diff -urN --exclude='*~' linux-2.6.11-rc2-mm1-original/drivers/char/pcxx.h
linux-2.6.11-rc2-mm1/drivers/char/pcxx.h
--- linux-2.6.11-rc2-mm1-original/drivers/char/pcxx.h
This patch removes drivers/char/pcxx.c
It depends on the previous patches.
Signed-off-by: James Nelson <[EMAIL PROTECTED]>
diff -urN --exclude='*~' linux-2.6.11-rc2-mm1-original/drivers/char/pcxx.c
linux-2.6.11-rc2-mm1/drivers/char/pcxx.c
--- linux-2.6.11-rc2-mm1-original/drivers/char/pcxx.c
This patch removes references to the pcxx driver in drivers/char/Kconfig
It depends on the previous patch.
Signed-off-by: James Nelson <[EMAIL PROTECTED]>
diff -urN --exclude='*~' linux-2.6.11-rc2-mm1-original/drivers/char/Kconfig
linux-2.6.11-rc2-mm1/drivers/char/Kconfig
---
This patch removes references to the pcxx driver drivers/char/Makefile
It depends on the previous patches.
Signed-off-by: James Nelson <[EMAIL PROTECTED]>
diff -urN --exclude='*~' linux-2.6.11-rc2-mm1-original/drivers/char/Makefile
linux-2.6.11-rc2-mm1/drivers/char/Makefile
---
> > Only the ready flag was lost.
> No, note that if there was valid data we would see 0xa5 instead of
> 0x5a that was in the buffer - because in i8042_command we invert data
> coming from AUX port.
We misunderstand each other.
Let me repeat. The following happens:
We wait, then write d3, wait,
Pierre Ossman wrote:
I recently tried out adding PNP support to my driver to remove the
hassle of finding the correct parameters for it. This, however, causes
it to show up under the pnp bus, where as it previously was located
under the platform bus.
Is the idea that PNP devices should only
Hi.
On Fri, 2005-01-28 at 10:01, Pavel Machek wrote:
> Yes, it happened even in cases when machine was not ever suspended. I
> guess I should also add that kernel is "tainted: pavel", (that means I
> have my own patches in; but I really believe that my changes are not
> responsible).
I often
The receiver of my Logitech Cordeless Desktop fails to report the
keyboard's class descriptor most times I insert the usb-hid module
since I changed to linux 2.6. The modell of the receiver is C-BD9-DUAL
REV C.
The request seems not to fail but the count of received characters is zero.
As I
On Thu, 2005-01-27 at 15:53 +, Alan Cox wrote:
> On Mer, 2005-01-26 at 22:10, Benjamin Herrenschmidt wrote:
> > On Wed, 2005-01-26 at 10:34 -0600, Brian King wrote:
> > Well, I honestly think that this is unnecessary burden. I think that
> > just dropping writes & returning data from the cache
Applied.
thanks,
-Len
On Thu, 2005-01-27 at 06:04, Adrian Bunk wrote:
> The prototype of the unused global function
> acpi_ut_create_pkg_state_and_push was already #ifdef
> ACPI_FUTURE_USAGE'd, but the actual function wasn't.
>
> Most likely this was a bug in my patch that added
>
--- Andreas Gruenbacher <[EMAIL PROTECTED]> escribió:
> Hello again,
>
> this looks like a good candidate. Could you please
> try if it fixes the
> problem?
The Oops went away with this one.
> Thanks,
Your welcome.
Cheers,
Albert
On Thu, 27 Jan 2005, Viktor Horvath wrote:
> Hello everybody,
>
> today I patched myself up from 2.6.7 vanilla to 2.6.10 vanilla, but
> after all patches succeeded, "make menuconfig" shows "v2.6.8.1
> Configuration". Even worse, a compiled kernel calls in his bootlog
> himself "2.6.8.1". When
On Thu, 2005-01-27 at 06:01, Adrian Bunk wrote:
> Before I'm getting flamed to death:
> This patch isn't meant for being immediately applied.
>
> This patch makes all needlessly global code under drivers/acpi/
> static.
> Please review this patch.
Thanks for the patch Adrian.
I agree that this
I just got an interesting "I see these problems too" report. It
may provide a useful clue. According to "Art Haas" <[EMAIL PROTECTED]>:
> I'm running the current BK kernel now, and I'm not seeing the problems
> right now because, I found, I do not have some of the IP masquerading
> modules
Hello again,
this looks like a good candidate. Could you please try if it fixes the
problem?
Thanks,
--
Andreas Gruenbacher <[EMAIL PROTECTED]>
SUSE Labs, SUSE LINUX GMBH
--- Begin Message ---
This pattern from 2.4 times doesn't work very well anymore :(
Signed-off-by: Andreas Gruenbacher
Hi!
> > Unfortunately I do not know how to reproduce it. I tried
> > parallel-building kernels for few hours and that worked okay. Swsusp
> > is not involved (but usb, bluetooth, acpi and sound may be).
>
> I take it you're sure suspending is not involved because it happens
> before you've ever
Doug Maxey wrote:
On Thu, 27 Jan 2005 13:02:48 +0100, Jens Axboe wrote:
Hi,
For the longest time, only the old PATA drivers supported barrier writes
with journalled file systems. This patch adds support for the same type
of cache flushing barriers that PATA uses for SCSI, to be utilized with
1 - 100 of 729 matches
Mail list logo
