On Friday 04 March 2005 00:53, Alan Jenkins wrote:
> Having a GeForce FX 5200 which I expected to work under rivafb (kernel
> version 2.6.11), I found the attached message on google groups.
>
> I know it is a little later now, but would you think about getting the
> work you've done committed?
>
>
On Friday 04 March 2005 01:03, Oded Shimon wrote:
> - ods15
Oops.
diff -U 3 -r -N -X /usr/src/diffignore -- linux-2.6.6/drivers/video/riva/fbdev.c linux/drivers/video/riva/fbdev.c
--- linux-2.6.6/drivers/video/riva/fbdev.c 2004-05-10 05:32:54.0 +0300
+++ linux/drivers/video/riva/fbdev.c
On Thu, 2005-03-03 at 13:53 -0800, David Lang wrote:
> > Actually, the >5 was pretty pointless anyway. What I got
> > from talking to people is that they wanted a release that only got fixes
> > that would crash the machine, or cause a root exploit. That's what I
> > thought Linus was trying to
Hi!
I had accidently chosen CONFIG_PNP and noticed that my keyboard didn't
work with bk-dtor-input.patch in the tree (backing out makes keyboard
work).
diff -up working_dmesg nokeyboard_dmesg
--- working_dmesg 2005-03-03 22:15:52.0 +0100
+++ nokeyboard_dmesg2005-03-03
On Thu, 3 Mar 2005, Hua Zhong wrote:
>
> Indeed. What I have in mind (and suggested in the past) is that we have a
> real 2.6 stable release maintainer. The only difference is that he starts
> from a random 2.6.x release he picks, and releases 2.6.x.y until he thinks
> stable enough, and he
On Fri, Mar 04, 2005 at 09:30:22AM +1100, Paul Mackerras wrote:
> > I nominate this as a candidate for linux-2.6.11 release branch. :)
>
> No. Unfortunately if you fix ppc64 here you will break ppc, and vice
> versa. Yes, we are going to reconcile the cur_cpu_spec definitions
> between ppc and
On Thu, Mar 03, 2005 at 01:37:26PM -0800, Trond Myklebust wrote:
> to den 03.03.2005 Klokka 10:19 (+0100) skreiv Andi Kleen:
> > The problem here is that glibc uses stat64() which supports
> > 64bit inode numbers. But glibc does the overflow checking itself
> > and generates the EOVERFLOW in user
This patch contains the following cleanups:
- make a needlessly global function static
- remove the unused global function do_posix_clock_notimer_create
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
include/linux/posix-timers.h |3 +--
kernel/posix-timers.c|9 ++---
2
Because Xen is compiled with -Wall -Werror, has inherited
processor.h from Linux and Fedora is now built with gcc4,
I discovered this bug.
The few callers I verified all call cpuid with unsigned
ints, but the function is defined with signed ints. This
trivial patch fixes that.
Signed-off-by: Rik
On Fri, Mar 04, 2005 at 09:30:22AM +1100, Paul Mackerras wrote:
> Jeff Garzik writes:
> > Rene Rebe wrote:
> > > Hi,
> > >
> > >
> > > --- linux-2.6.11/drivers/md/raid6altivec.uc.vanilla2005-03-02
> > > 16:44:56.407107752 +0100
> > > +++ linux-2.6.11/drivers/md/raid6altivec.uc2005-03-02
On Thu, Mar 03, 2005 at 04:28:52PM -0500, Jeff Garzik wrote:
> Bill Rugolsky Jr. wrote:
> >I've watched you periodically announce "hey, I'm doing an update for
> >FC3/FC2, please test" on the mail list, and a handful of people go test.
> >If we could convince many of the the less risk-averse but
Hi,
Jody McIntyre wrote:
I'll apply this to the 1394 tree and send it to Linus after testing if
you add a Signed-off-by: line per Documentation/SubmittingPatches .
Also, please cc [EMAIL PROTECTED] with ieee1394
changes.
Sure! Thanks!
Adds the missing failure handling for a __copy_to_user call.
As I read the code the driver task (A) should _not_ be removed from the
runqueue. It has to be waken up to call schedule_timeout() such it gets
back on the runqueue after 10 ms. If it is taken out of the runqueue at
line 76 it will stay off the runqueue forever in the TASK_UNINTERRUBTIBLE
state!
On Thu, 3 Mar 2005 22:01:19 +0100, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> This patch contains cleanups including the following:
Are you cleaning up all of that annoying trailing whitespace too? It
is always giving me problems on diffs.
--
Jon Smirl
[EMAIL PROTECTED]
-
To unsubscribe from this
I agree.
But what if the file systems can handle certain errors better than
what the drivers can do now ? Take for e.g., data corruption. If the
driver finds a corrupted sector that it cannot recover, it is going to
convert this specific error in to a more generic error code (-EIO) and
report it
On Iau, 2005-03-03 at 00:32, Dave Jones wrote:
> On Wed, Mar 02, 2005 at 03:44:58PM -0800, Linus Torvalds wrote:
> The only thing that would make a difference afaics, would be you putting
> your foot down and just ignoring such submissions ?
ROTFL. You've not watched Linus for a long time have
Jeff Garzik writes:
> Rene Rebe wrote:
> > Hi,
> >
> >
> > --- linux-2.6.11/drivers/md/raid6altivec.uc.vanilla2005-03-02
> > 16:44:56.407107752 +0100
> > +++ linux-2.6.11/drivers/md/raid6altivec.uc2005-03-02
> > 16:45:22.424152560 +0100
> > @@ -108,7 +108,7 @@
> > int
On Thu, Mar 03, 2005 at 10:15:46PM +, Alan Cox wrote:
> We still need 2.6.x.y updates on a more official footing and with more
> than one person as the "2.6.x.y" maintainer. I think that is actually
> more important.
That appears to be the consensus conclusion we've arrived at.
Jeff
to den 03.03.2005 Klokka 22:46 (+0100) skreiv Andi Kleen:
> > As far as the kernel is concerned, asm/posix_types defines
> > __kernel_ino_t as "unsigned long" on most platforms (except a few which
> > define is as "unsigned int). We don't care what size type glibc itself
> > uses.
>
> That could
On Iau, 2005-03-03 at 01:27, Dave Jones wrote:
> In an ideal world, we'd see a single 'y' release of 2.6.x.y, but if x+1 takes
> too long to be released, bits of x+1 should also appear in x.y+1
> The only question in my mind is 'how critical does a bug have to be to
> justify a .y release. Once a
Hi.
Here are the stats:
1GB P4, 2.6.11+Suspend2 2.1.8.
Soft image size limit set to 2MB to emulate Pavel's implementation (eat
as much memory as we can).
Without patch:
Freed 16545 pages in 4000 jiffies = 16.16 MB/s
Freed 83281 pages in 14060 jiffies = 23.14 MB/s
Freed 237754 pages in 41482
On Thu, 2005-03-03 at 11:27, Marcelo Tosatti wrote:
> Hi Thomas,
>
> I'm forwarding your message to Mikael and Len, who have knowledge
> on the IOAPIC infrastructure.
>
> - Forwarded message from [EMAIL PROTECTED] -
>
> From: [EMAIL PROTECTED]
> Date: Wed, 2 Mar 2005 13:37:03 +0800
>
I'm not sure the change is any better. AMD now use Geode for two totally
unrelated CPU families and they need different configuration.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Mer, 2005-03-02 at 22:21, Linus Torvalds wrote:
> - 2.6.: still a stable kernel, but accept bigger changes leading up
>to it (timeframe: a month or two).
> - 2..x: aim for big changes that may destabilize the kernel for
>several releases (timeframe: a year or two)
> - .x.x: Linus
Mikael Pettersson <[EMAIL PROTECTED]> wrote:
>
> > > perfctr has one API update pending, and then the API should be
> > > in it final-ish form. David Gibson at IBM has done a ppc64 port,
> > > which is about ready to be merged, and someone else has just
> > > started working on a mips port.
On Thu, 3 Mar 2005, Andrew Morton wrote:
> Christoph Lameter <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, 2 Mar 2005, Andrew Morton wrote:
> >
> > > > This is not relevant since it only deals with file pages.
> > >
> > > OK. And CONFIG_DEBUG_PAGEALLOC?
> >
> > Its a debug feature that can be
Moving this back to LKML from a private e-mail thread between Alan,
Marcelo and I...
Bhavesh P. Davda | Distinguished Member of Technical Staff | Avaya |
1300 West 120th Avenue | B3-B03 | Westminster, CO 80234 | U.S.A. |
Voice/Fax: 303.538.4438 | [EMAIL PROTECTED]
On Thu, Mar 03, 2005 at
Hi!
> This patch makes a needlessly global variable static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
ACK
Pavel,
wondering if we have single Adrian or 1000 small gnomes going through
code night and day.
> ---
On Thu, 2005-03-03 at 13:38 -0800, Stephen Hemminger wrote:
> In all this discussion, I see a couple of underlying problems. The first
> is what is the definition of stability. To many (mostly kernel developers)
> the definition of stability "S" depends on number of bug reports "B":
>
>
I didn't find any possible modular usage of console_unblank in the
kernel.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.11-rc5-mm1-full/kernel/printk.c.old 2005-03-03
17:04:18.0 +0100
+++ linux-2.6.11-rc5-mm1-full/kernel/printk.c 2005-03-03 17:04:24.0
Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> My point is simply:
>
> The help text for an option you need only under very specific
> circumstances shouldn't sound as if this option was nearly was
> mandatory.
I think the sort of sell-your-cycles service which this patch enables is a
neat
On Thu, 2005-03-03 at 16:52 -0500, Dave Jones wrote:
> On Thu, Mar 03, 2005 at 01:49:50PM -0800, John Cherry wrote:
> > On Thu, 2005-03-03 at 00:21 -0500, Dave Jones wrote:
> >
> > > compile time regressions we should be able to nail down fairly easily.
> > > (someone from OSDL is already
> In other words, I'm really talking about something different
> from what you seem to envision.
Indeed. What I have in mind (and suggested in the past) is that we have a
real 2.6 stable release maintainer. The only difference is that he starts
from a random 2.6.x release he picks, and releases
> Thanks. Here's my third try :-)
>
> With friendly regards,
> Takis
I'll apply this to the 1394 tree and send it to Linus after testing if
you add a Signed-off-by: line per Documentation/SubmittingPatches .
Also, please cc [EMAIL PROTECTED] with ieee1394
changes.
Thanks,
Jody
>
> --
>
On Thu, 2005-03-03 at 13:24 -0800, David Lang wrote:
> I don't think you are understanding the proposal
>
You're probably right. :-)
> 2.6.11.y will be released as 2.6.12 is being developed.
>
> once 2.6.12 is released (or shortly after that if 2.6.12 ends up being a
> _real_ mess) 2.6.11.y
This patch makes a needlessly global variable static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.11-rc5-mm1-full/kernel/power/smp.c.old2005-03-03
17:00:30.0 +0100
+++ linux-2.6.11-rc5-mm1-full/kernel/power/smp.c2005-03-03
17:00:38.0 +0100
@@ -42,7
This patch makes a needlessly global function static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
include/linux/irq.h |1 -
kernel/irq/spurious.c |2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
--- linux-2.6.11-rc5-mm1-full/include/linux/irq.h.old 2005-03-03
This patch makes a needlessly global struct static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
include/linux/kexec.h |1 -
kernel/kexec.c|2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
--- linux-2.6.11-rc5-mm1-full/include/linux/kexec.h.old 2005-03-03
to den 03.03.2005 Klokka 10:19 (+0100) skreiv Andi Kleen:
> The problem here is that glibc uses stat64() which supports
> 64bit inode numbers. But glibc does the overflow checking itself
> and generates the EOVERFLOW in user space. Nothing we can do
> about that. The 64bit inodes work under 32bit
In all this discussion, I see a couple of underlying problems. The first
is what is the definition of stability. To many (mostly kernel developers)
the definition of stability "S" depends on number of bug reports "B":
S(infinite) = B(0)
S(X) > S(Y) iff B(X) < B(Y)
The problem is
Bill Rugolsky Jr. wrote:
I've watched you periodically announce "hey, I'm doing an update for
FC3/FC2, please test" on the mail list, and a handful of people go test.
If we could convince many of the the less risk-averse but lazy users to
grab kernels automatically from updates/3/testing/ or
> So what do you actually suggest? On the one hand you say even 32bit userspace
> supports 64bit inodes, if it wants. On the other hand you say the truncation
> needs to be done on file system level.
> To my mind this is contradicting, the first statement suggests to do the
> truncation in
This patch makes a needlessly global function static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
include/linux/sched.h |1 -
kernel/exit.c |4 +++-
2 files changed, 3 insertions(+), 2 deletions(-)
--- linux-2.6.11-rc5-mm1-full/include/linux/sched.h.old 2005-03-03
Hi James,
> A revised adt7461 patch addressing all of Jean's comments is
> attached.
>
> This driver will detect the adt7461 chip only if boot firmware
> has left the chip in its default lm90-compatible mode.
I'm fine with the idea but not quite with your implementation:
> @@ -221,6 +229,8 @@
Dave Jones wrote:
Other failures have been somewhat more dramatic.
I know ipsec-tools, and alsa-lib have both caused pain
on at least one occasion after the last 2-3 kernel updates.
alsa-lib is a special case.
alsa-lib exists so that it can mitigate changes between the kernel and
userland. If
On Thu, 3 Mar 2005, Steven Rostedt wrote:
A couple of weeks ago I was at LinuxWorldExpo in Boston and was talking
to several people about the stability of the 2.6 kernel. Every one I
talked to seemed to be nervous about using it. Some did, and some did
not and stayed with 2.4. But each one had
On Thu, Mar 03, 2005 at 01:09:01PM -0800, Andrew Morton wrote:
> [*] I don't know any details of the /proc incompatibility which davej
> mentions, and I'd like to. That sounds like a screw-up.
We changed the format of /proc/slabinfo. Running slabtop threw up
an error message complaining
Hi Thomas,
I'm forwarding your message to Mikael and Len, who have knowledge
on the IOAPIC infrastructure.
- Forwarded message from [EMAIL PROTECTED] -
From: [EMAIL PROTECTED]
Date: Wed, 2 Mar 2005 13:37:03 +0800
To: [EMAIL PROTECTED]
Subject: Kernel 2.4.28 can't boot into OS without
As a further elaboration...
The problem with the current 2.6-rc setup is a _human_ _communications_
problem.
Users have been trained in a metaphor that is applied uniformly across
all software projects that use the metaphor:
test release: a useful merge/testing point
The offb code did not take into account a remapped pci address. Adding
in the pci_mem_offset fixed a DSI in offb.
Signed-off-by: Jake Moilanen <[EMAIL PROTECTED]>
---
diff -puN drivers/video/offb.c~offb_dsi drivers/video/offb.c
--- linux-2.6.11/drivers/video/offb.c~offb_dsi Wed Mar 2
On Thu, Mar 03, 2005 at 12:07:18PM -0800, Chris Wright wrote:
> * Jeff Garzik ([EMAIL PROTECTED]) wrote:
> > Greg KH wrote:
> >
> > Two procedural suggestions...
> >
> > >Ok, I've fixed up the patch and applied it to a local tree that I've set
> > >up to catch these things (it will live at
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Olaf Hering wrote:
> On Thu, Mar 03, Jeff Mahoney wrote:
>
>
>>Is whitespace (in any form) allowed in the compatible value?
>
>
> Yes, whitespace is used at least in the toplevel compatible file, like
> 'Power Macintosh' in some Pismo models.
>
Sam,
If `mkimage` is either not found in search path or returns non-zero status,
`make uImage` succeeds when it should fail. This changes scripts/mkuboot.sh
to return status so build succeeds or fails as appropriate.
Source: MontaVista Software, Inc.
MR: 10761
Type: Defect Fix
Disposition:
Andries Brouwer <[EMAIL PROTECTED]> wrote:
>
> API stability: Stable series like 2.0, 2.2, 2.4 try to maintain
> the guarantee that user-visible APIs do not change. That goal
> has disappeared, meaning that anything might break when one
> upgrades from 2.6.14 to 2.6.16.
> This is one of the
This patch contains cleanups including the following:
- make needlessly global code static
- remove the needlessly #ifdef MODULE from several module_exit
- remove or #if 0 the following unused global functions:
- fbmon.c: fb_create_modedb
- fbmon.c: fb_get_monitor_limits
- nvidia/nv_i2c.c:
A couple of weeks ago I was at LinuxWorldExpo in Boston and was talking
to several people about the stability of the 2.6 kernel. Every one I
talked to seemed to be nervous about using it. Some did, and some did
not and stayed with 2.4. But each one had a different level of faith in
which kernel
On Fri, Mar 04, 2005 at 03:50:42AM +0800, Antonino A. Daplas wrote:
>...
> > Is there any reason for these being three modules?
> > It seems the best solution would be to make this one module composed of
> > up to three object files?
>
> Yes.
Two possible solutions:
- rename savagefb.c and link
Linus Torvalds <[EMAIL PROTECTED]> said:
> On Thu, 3 Mar 2005, Horst von Brand wrote:
> > [I'm pulling bk daily, and have it mixed with the ipw tree too, so I'm just
> > the kind of tester you are looking for... haven't seen any of the
> > showstopper bugs everybody is talking about, or I'd have
David Howells <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> >
> > > +#define BDI_CAP_MAP_COPY0x0001 /* Copy can be mapped
> (MAP_PRIVATE) */
> > > +#define BDI_CAP_MAP_DIRECT 0x0002 /* Can be mapped
> directly (MAP_SHARED) */
> >
This patch fixes the following compile warning:
<-- snip -->
...
CC sound/oss/awe_wave.o
In file included from sound/oss/os.h:31,
from sound/oss/sound_config.h:21,
from sound/oss/awe_wave.c:37:
include/linux/soundcard.h:195:1: warning: "_PATCHKEY"
Greg KH wrote:
On Thu, Mar 03, 2005 at 12:07:18PM -0800, Chris Wright wrote:
Don't see why not, we were thinking of making it just an alias at
kernel.org.
An alias would probably be easier, unless you think everything sent
there should be archived?
I do. But I don't have a strong opinion on the
Trever L. Adams wrote:
On Thu, 2005-03-03 at 08:48 -0700, Jeff V. Merkey wrote:
Patent law in the US is based on section 113 of the United States
Constitution, and patents
are not going away.
Merkey aren't you supposed to be a lawyer? Unless you do some funky
concatenation of articles
David Howells <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > Yup. In this application the fields are initialised once (usually at
> > compile time) and are never modified.
>
> That's not exactly so. The block layer appears to modify them. See
>
On Friday 04 March 2005 04:20, Adrian Bunk wrote:
> On Fri, Mar 04, 2005 at 03:50:42AM +0800, Antonino A. Daplas wrote:
> >...
> >
> > > Is there any reason for these being three modules?
> > > It seems the best solution would be to make this one module composed of
> > > up to three object files?
El Thu, 3 Mar 2005 00:21:01 -0500,
Dave Jones <[EMAIL PROTECTED]> escribió:
> bunch of IBM thinkpads. As it turns out there are quite a lot of these
> out there, so when I released a 2.6.10 update for Fedora, bugzilla lit
> up like a christmas tree with "Hey, where'd my sound go?" reports.
> (It
On Thu, Mar 03, 2005 at 02:33:58PM -0500, Dave Jones wrote:
> If you accelerate the merging process, you're lowering the review process.
> The only answer to get regressions fixed up as quickly as possible
> (because prevention is nigh on impossible at the current rate, so
> any faster is just
On Thu, 3 Mar 2005, Sean wrote:
>
> Wait a second though, this tree will be branched from the development
> mainline. So it will contain many patches that entered with less
> testing.
Well, since I'd pull basically all the time, all the patches _do_ get
testing the the -rc kernels.
But
To close this issue out of the LKML and alsa-devel, a bug report has been
written.
It appears to be an issue with the 'headphone jack sense' (as kde labels
it). The issue is in the way the 8x0 addresses the docking station/port
replicator's audio output jack. The mentioned quick fix does not
On Thu, 2005-03-03 at 14:52 -0500, Jeff Garzik wrote:
> I disagree it's unsolvable:
>
> 1) At some point in the -rc cycle, you put your foot down and say
> "nothing but bugfixes."
Release candidates are supposed to be bugfix only from -rc1. Everything
else can only be called the "ridiculous
Chris Wright <[EMAIL PROTECTED]> writes:
> I like this definition. The only remaining question is what determines
> a 2.6.x.y release? One patch? Sure if it's critical enough.
Sure. Or a patch for 1-2 days, will less critical things.
And probably no .tar* balls for them. Just a patch
Thomas Gleixner wrote:
On Thu, 2005-03-03 at 18:08 +0100, Adrian Bunk wrote:
This only attacks part of the problem.
It still does not solve the problem of "untested" releases. Users will
still ignore the linus-tree-rcX kernels.
So we move the real -rcX phase after the so called stable release.
On Thu, Mar 03, 2005 at 02:35:29PM -0500, Sean wrote:
> On Thu, March 3, 2005 12:53 pm, Linus Torvalds said:
> > On Thu, 3 Mar 2005, Jens Axboe wrote:
> >>
> >> Why should there be one? One of the things I like about this concept is
> >> that it's just a moving tree. There could be daily snapshots
On Thu, 2005-03-03 at 14:42 -0500, Jeff Garzik wrote:
> 1) Release maintainers need to avoid merging non-bugfixes. Lately, the
> key penguins _have_ been doing their job here. This manifested in
> 2.6.11-rc4, 2.6.11-rc5.
True, but the confidence of users in -rc is gone already. So testing
On Thu, 3 Mar 2005, V P wrote:
Hi,
I have a question on how disk errors get propagated to
the file systems.
From looking at the SCSI/IDE drivers, it looks like there
could be many reasons for an I/O to fail. It could be
bus timeout, media errors, and so on.
Does all these errors get reported to
On Thu, Mar 03, Jeff Mahoney wrote:
> Is whitespace (in any form) allowed in the compatible value?
Yes, whitespace is used at least in the toplevel compatible file, like
'Power Macintosh' in some Pismo models.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Jeff Garzik wrote:
:
o [netdrvr 8139cp] add PCI ID
This one seems to be already present in 2.6.11 under a different name
(PCI_DEVICE_ID_TTTECH_MC322). Also, the corresponding entry in pci_ids.h is
not in the order of the file.
Daniel
-
To unsubscribe from this list: send the line "unsubscribe
David S. Miller wrote:
On Thu, 03 Mar 2005 14:52:21 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
I disagree it's unsolvable:
1) At some point in the -rc cycle, you put your foot down and say
"nothing but bugfixes."
Linus actually did, as Andrew showed you, and it was actually followed
quite
On Thu, 3 Mar 2005 14:06:38 -0500 (EST), Mark Canter
<[EMAIL PROTECTED]> wrote:
>
> Correct, but if you want to use your headphones you would have to enable
> headphones on your mixer, which would negate your speaker output through
> your docking station's output. If you want to use the docking
On Thu, 2005-03-03 at 08:48 -0700, Jeff V. Merkey wrote:
> Patent law in the US is based on section 113 of the United States
> Constitution, and patents
> are not going away.
Merkey aren't you supposed to be a lawyer? Unless you do some funky
concatenation of articles and sections you can't
Am Donnerstag, 3. März 2005 20:48 schrieb Pasi Savolainen:
> * Oliver Neukum <[EMAIL PROTECTED]>:
> > Am Donnerstag, 3. März 2005 14:38 schrieb Adrian Bunk:
> >> USB_HPUSBSCSI was marked as BROKEN in 2.6.11 since libsane is the
> >> preferred way to access these devices.
> >
> > That is true only
* Jeff Garzik ([EMAIL PROTECTED]) wrote:
> Greg KH wrote:
>
> Two procedural suggestions...
>
> >Ok, I've fixed up the patch and applied it to a local tree that I've set
> >up to catch these things (it will live at
> >bk://kernel.bkbits.net:gregkh/linux-2.6.11.y until Chris Wright and I
> >set
This is the place to report any more information on this issue:
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=852
Lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Jeff Garzik <[EMAIL PROTECTED]> writes:
> 1) There is no clear, CONSISTENT point where "bugfixes only"
> begins. Right now, it could be -rc2, -rc3, -rc4... who knows.
>
> We need to send a clear signal to users "this is when you can really
> start hammering it." A signal that does not change
On Thu, 03 Mar 2005 14:52:21 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> I disagree it's unsolvable:
>
> 1) At some point in the -rc cycle, you put your foot down and say
> "nothing but bugfixes."
Linus actually did, as Andrew showed you, and it was actually followed
quite well.
You keep
On Friday 04 March 2005 00:56, Adrian Bunk wrote:
> On Tue, Mar 01, 2005 at 09:15:27PM +0800, Antonino A. Daplas wrote:
> > On Tuesday 01 March 2005 10:41, Adrian Bunk wrote:
> > > Hi,
> > >
> > > while looking how to fix modular FB_SAVAGE_* (both FB_SAVAGE_I2C=m and
> > > FB_SAVAGE_ACCEL=m are
Andries Brouwer <[EMAIL PROTECTED]> writes:
> API stability: Stable series like 2.0, 2.2, 2.4 try to maintain
> the guarantee that user-visible APIs do not change. That goal
> has disappeared, meaning that anything might break when one
> upgrades from 2.6.14 to 2.6.16.
Both 2.4 and 2.6 are IMHO
On Thu, 2005-03-03 at 11:37 -0800, Linus Torvalds wrote:
> > It still does not solve the problem of "untested" releases. Users will
> > still ignore the linus-tree-rcX kernels.
>
> .. and maybe that problem is unsolvable. People certainly argued
> vehemently that anything we do to try to make
* Oliver Neukum <[EMAIL PROTECTED]>:
> Am Donnerstag, 3. März 2005 14:38 schrieb Adrian Bunk:
>> USB_HPUSBSCSI was marked as BROKEN in 2.6.11 since libsane is the
>> preferred way to access these devices.
>
> That is true only if you limit yourself to users of SANE.
> Other, rarer scan systems
Linus Torvalds wrote:
On Thu, 3 Mar 2005, Thomas Gleixner wrote:
It still does not solve the problem of "untested" releases. Users will
still ignore the linus-tree-rcX kernels.
.. and maybe that problem is unsolvable. People certainly argued
vehemently that anything we do to try to make test
Greg KH wrote:
Two procedural suggestions...
Ok, I've fixed up the patch and applied it to a local tree that I've set
up to catch these things (it will live at
bk://kernel.bkbits.net:gregkh/linux-2.6.11.y until Chris Wright and I
set up how we are going to handle all of this.)
My suggestion would
Hi James,
> A revised ds1337 patch addressing all of Jean's comments is attached.
Fine with me except for:
> + if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA |
> + I2C_FUNC_SMBUS_I2C_BLOCK))
I don't this it is correct. You are using
On Thu, March 3, 2005 12:53 pm, Linus Torvalds said:
> On Thu, 3 Mar 2005, Jens Axboe wrote:
>>
>> Why should there be one? One of the things I like about this concept is
>> that it's just a moving tree. There could be daily snapshots like the
>> -bkX "releases" of Linus's tree, if there are
Hi,
> On the same path sk_set_owner also gets called twice, I think this
> causes double module use count when creating sockets. Module use count
> need some attention all over x25.
I'm working on it already. I hope to send patches soon.
Is linux-x25 list alive? if not, perhaps we should add
please consider the following scenario for full RT kernel.
Task A is running then an irq is occured which in turn wakes up irq
related thread (B) of a higher priority than A.
my current understanding that actual context switch between A and B will
occure at preempt_schedule_irq() on the "return
Hi,
I have a question on how disk errors get propagated to
the file systems.
>From looking at the SCSI/IDE drivers, it looks like there
could be many reasons for an I/O to fail. It could be
bus timeout, media errors, and so on.
Does all these errors get reported to the file system ?
It looks
On Thu, Mar 03, 2005 at 12:07:59PM -0500, Bill Rugolsky Jr. wrote:
> IMHO, Jeff Garzik has made two very useful points in this thread:
>
> 1. The number of changesets flowing towards the Linus kernel is accelerating,
>so the kernel developers should be trying to accelerate the merging
On Wed, Mar 02, 2005 at 05:43:59PM -0500, Jeff Garzik wrote:
> Joerg Sommrey wrote:
> >Jeff Garzik wrote:
> >>Patch:
> >>http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/2.6.11-rc5-bk4-libata-dev1.patch.bz2
> >
> >
> >Still not usable here. The same errors as before when backing up:
>
Hi,
I like the rapid cycling that Linux has switched to,
but I also like to know how stable something is. At
first sight, it's not obvious you can have both,
without the split trees that were causing headaches.
However, there may be an alternative, if there's any
agreement on testing. (There are
On Thu, 2005-03-03 at 13:46 -0500, Mark Canter wrote:
> The same issue exists on a T42p (ICH4). Doesn't that kind of defeat the
> purpose? The thought of having to disable the headphone jack and reenable
> it each time is trivial considering you can go with the fact that sound
> did not
On Thu, Mar 03, 2005 at 01:26:36PM -0500, Jeff Garzik wrote:
> Rene Rebe wrote:
> >Hi,
> >
> >
> >--- linux-2.6.11/drivers/md/raid6altivec.uc.vanilla2005-03-02
> >16:44:56.407107752 +0100
> >+++ linux-2.6.11/drivers/md/raid6altivec.uc2005-03-02
> >16:45:22.424152560 +0100
> >@@ -108,7
201 - 300 of 1028 matches
Mail list logo
