Re: Kernel SCM saga..

Linus Torvalds writes: > NOTE! I detest the centralized SCM model, but if push comes to shove, > and we just _can't_ get a reasonable parallell merge thing going in > the short timeframe (ie month or two), I'll use something like SVN > on a trusted site with just a few committers, and at least

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

(Henning Makholm, I assume; I seem to be missing the actual message and David's mailer forgot to put a quote header on the original reply): > > >> I think the "derivative work" angle is a red herring. I do not think > > >> that either of the two parts that are being linked together (i.e. the > >

[PATCH linux-misc-2.6] scsi: remove volatile from scsi data structures

Hello, James. Hello, Christoph. This patch removes volatile qualifier from scsi_device->device_busy, Scsi_Host->host_busy and ->host_failed as the volatile qualifiers don't serve any purpose now. While at it, convert those fields from unsigned short to unsigned int as suggested by Christoph.

Re: Kernel SCM saga..

Linus wrote: > Almost everything > else keeps the in the ASCII hexadecimal representation, and I > should have done that here too. Why? Not because it's a - hey, the > binary representation is certainly denser and equivalent Since the size of ASCII sha1's is only about 18% larger than the

Re: Processes stuck on D state on Dual Opteron

On Sunday 10 April 2005 03:53, Nick Piggin wrote: > > Looks like you may possibly have a memory allocation deadlock > (although I can't explain the NMI oops). > > I would be interested to see if the following patch is of any > help to you. > Hi Nick, I'll build a kernel with your patch and

Re: Processes stuck on D state on Dual Opteron

On Sunday 10 April 2005 03:47, Andrew Morton wrote: > > Suggest you boot with `nmi_watchdog=0' to prevent the nmi watchdog from > cutting in during long sysrq traces. > > Also, capture the `sysrq-m' output so we can see if the thing is out of > memory. OK, will do it ASAP and report back.

RE: non-free firmware in kernel modules, aggregation and unclear copyright notice.

> Scripsit "David Schwartz" <[EMAIL PROTECTED]> > >> I think the "derivative work" angle is a red herring. I do not think > >> that either of the two parts that are being linked together (i.e. the > >> driver and the firmware) are derivates of the other. The relevant > >> point is that

Re: Processes stuck on D state on Dual Opteron

Claudio Martins wrote: On Tuesday 05 April 2005 03:12, Andrew Morton wrote: Claudio Martins <[EMAIL PROTECTED]> wrote: While stress testing 2.6.12-rc2 on an HP DL145 I get processes stuck in D state after some time. This machine is a dual Opteron 248 with 2GB (ECC) on one node (the other node

Re: Processes stuck on D state on Dual Opteron

Claudio Martins <[EMAIL PROTECTED]> wrote: > > I repeated the test to try to get more output from alt-sysreq-T, but it > oopsed again with even less output. >By the way, I have also tested 2.6.11.6 and I get stuck processes in the > same way. With 2.6.9 I get a hard lockup with no

Re: Re: more git updates..

Dear diary, on Sun, Apr 10, 2005 at 01:31:10AM CEST, I got a letter where Linus Torvalds <[EMAIL PROTECTED]> told me that... > On Sat, 9 Apr 2005, Linus Torvalds wrote: > > > > Actually, I guess I wouldn't have to change the format. I could just > > extend the existing "tree" object to be able

increasing scsi_max_sg / max_segments for scsi writes/reads

Hi, I had posted a question on increasing the scsi read/write sectors per command. I figured out some of the things, but many questions still exist. I was wondering why the maximum writes I could get from a single scsi write command could never exceed 204 4096B segments . I traced it to :

Re: Processes stuck on D state on Dual Opteron

On Tuesday 05 April 2005 03:12, Andrew Morton wrote: > Claudio Martins <[EMAIL PROTECTED]> wrote: > >While stress testing 2.6.12-rc2 on an HP DL145 I get processes stuck > > in D state after some time. > >This machine is a dual Opteron 248 with 2GB (ECC) on one node (the > > other node

Re: more git updates..

>From before: The sha1 (ascii) digests for 16817 files take: 689497 bytes before compression 397475 bytes after minigzip New numbers: The sha1 (binary) digests for 16817 files take: 336340 bytes before compression 334943 bytes after minigzip So compressing

Re: more git updates..

> Then a "tree" object would point to a "directory" object, Ah - light bulb flickers - in _separate_ files. Yes, that obviously makes a difference. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL

Re: more git updates..

Linus wrote: > Damn, that's painful. I suspect I will have to change the format somehow. The sha1 (ascii) digests for 16817 files take: 689497 bytes before compression 397475 bytes after minigzip The pathnames, relative to top of tree, for these 16817 files take: 503983

Re: Kernel SCM saga..

Chris wrote: > How many is alot? Are we talking 100k, 1m, 10m? I pulled some numbers out of my bk tree for Linux. I have 16817 source files. They average 12.2 bitkeeper changes per file (counting the number of changes visible from doing 'bk sccslog' on each of the 16817 files). These 16817

Re: Re: Re: Kernel SCM saga..

On Apr 10, 2005 2:42 AM, Petr Baudis <[EMAIL PROTECTED]> wrote: > Dear diary, on Sun, Apr 10, 2005 at 03:01:12AM CEST, I got a letter > where Phillip Lougher <[EMAIL PROTECTED]> told me that... > > On Apr 9, 2005 3:53 AM, Petr Baudis <[EMAIL PROTECTED]> wrote: > > > > > FWIW, I made few small

Re: Re: Re: Kernel SCM saga..

Dear diary, on Sun, Apr 10, 2005 at 03:01:12AM CEST, I got a letter where Phillip Lougher <[EMAIL PROTECTED]> told me that... > On Apr 9, 2005 3:53 AM, Petr Baudis <[EMAIL PROTECTED]> wrote: > > > FWIW, I made few small fixes (to prevent some trivial usage errors to > > cause cache corruption)

Re: more git updates..

Bernd wrote: > more parser friendly to have single records for diffs. good point [looks like you trimmed the cc list - folks around here don't like that ;)] -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson

Re: more git updates..

In article <[EMAIL PROTECTED]> you wrote: > Ralph wrote: >> Watch out for when xargs invokes do_something more than once and the `<' >> is parsed by a different one than the `>'. > It will take a pretty long list to do that. It seems that > GNU xargs on top of a Linux kernel has a 128 KByte

Re: Re: Kernel SCM saga..

On Apr 9, 2005 3:53 AM, Petr Baudis <[EMAIL PROTECTED]> wrote: > FWIW, I made few small fixes (to prevent some trivial usage errors to > cause cache corruption) and added scripts gitcommit.sh, gitadd.sh and > gitlog.sh - heavily inspired by what already went through the mailing > list.

Re: more git updates..

Ralph wrote: > Watch out for when xargs invokes do_something more than once and the `<' > is parsed by a different one than the `>'. It will take a pretty long list to do that. It seems that GNU xargs on top of a Linux kernel has a 128 KByte ARG_MAX. In the old days, with 4 KByte ARG_MAX

Re: Kernel SCM saga..

David wrote: > recovery is more difficult when you corrupt some > file in your repository. Agreed. I too have recovered RCS and SCCS files by hand editing. Linus wrote: > I don't want people editing repostitory files by hand. Tyrant !;) >From Wikipedia: A tyrant is a usurper of rightful

Re: Kernel SCM saga..

On Sat, Apr 09, 2005 at 04:13:51PM -0700, Linus Torvalds wrote: > > I understand the arguments for compression, but I hate it for one > > simple reason: recovery is more difficult when you corrupt some > > file in your repository. I've had this too. Magic binary blobs are horrible here for data

RE: [2.6 patch] drivers/serial/jsm/: make 2 functions static

Thanks Adrian for helping clean up the driver. Wendy will integrate your patch into our source tree. Scott From: Adrian Bunk [mailto:[EMAIL PROTECTED] Sent: Sat 4/9/2005 1:04 PM To: Andrew Morton Cc: Kilau, Scott; linux-kernel@vger.kernel.org Subject: [2.6

Re: [PATCH] radeonfb: (#2) Implement proper workarounds for PLL accesses

On Sat, 2005-04-09 at 18:24 +0200, Andreas Schwab wrote: > Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes: > > > Can you redo the counting of the workarounds with the patch ? > > Switching from X to console: > > radeon_write_pll_regs: INPLL > radeon_write_pll_regs: INPLL > radeon_write_mode:

Re: Kernel SCM saga..

Roman Zippel wrote: It seems you exported the complete parent information and this is exactly the "nitty-gritty" I was "whining" about and which is not available via bkcvs or bkweb and it's the most crucial information to make the bk data useful outside of bk. Larry was previously very clear

Re: [PATCH] Add Mac mini sound support

On Sat, 2005-04-09 at 13:51 +0200, Per Christian Henden wrote: > The patch below adds sound support on the Mac Mini by making a small change > to the PowerMac sound card detection code. > > Details: > > Original code: > >From sound/ppc/pmac.c __init snd_pmac_detect(pmac_t *chip) : > >

Re: more git updates..

On Sat, 9 Apr 2005, Linus Torvalds wrote: > > Actually, I guess I wouldn't have to change the format. I could just > extend the existing "tree" object to be able to point to other trees, and > that's it. Done, and pushed out. The current git.git repository seems to do all of this correctly.

Re: Status of new kernel.org servers

H. Peter Anvin wrote: For those of you that are interested... I kind of sort of miss the load and bandwidth statistics on the kernel.org front page. Did they just go boring now with sufficient hardware resources? :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

Re: more git updates..

Hi Linus, > Btw, the NUL-termination makes this really easy to use even in shell > scripts, ie you can do > > diff-tree | xargs -0 do_something > > and you'll get each line as one nice argument to your "do_something" > script. So a do_diff could be based on something like > >

[2.6 patch] sound/pci/ymfpci/ymfpci_main.c: remove dead code

This patch removes some dead code found by the Coverity checker. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- sound/pci/ymfpci/ymfpci_main.c | 31 --- 1 files changed, 8 insertions(+), 23 deletions(-) ---

[patch] MAINTAINERS: remove obsolete ACP/MWAVE MODEM entry

Both maintainer email addresses are bouncing and the web address is no longer valid. Seems to be a good time to remove the entry. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- linux-2.6.12-rc2-mm2-full/MAINTAINERS.old 2005-04-10 01:12:58.0 +0200 +++

Re: Status of new kernel.org servers

Andre Tomt wrote: H. Peter Anvin wrote: For those of you that are interested... I kind of sort of miss the load and bandwidth statistics on the kernel.org front page. Did they just go boring now with sufficient hardware resources? :-) No; the issue there is that with multiple servers we have to

[2.6 patch] drivers/scsi/sym53c416.c: fix a wrong check

The Coverity checker found that this for loop was wrong. This patch changes it to what seems to be intended. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- linux-2.6.12-rc2-mm2-full/drivers/scsi/sym53c416.c.old 2005-04-09 22:16:04.0 +0200 +++

Re: Kernel SCM saga..

On Sat, 9 Apr 2005, David S. Miller wrote: > > I understand the arguments for compression, but I hate it for one > simple reason: recovery is more difficult when you corrupt some > file in your repository. Trust me, the way git does things, you'll have so much redundancy that you'll have to

Re: [patch] sched: unlocked context-switches

On Sat, 9 Apr 2005 00:15:37 -0700 David Mosberger <[EMAIL PROTECTED]> wrote: > Yes, of course. The deadlock was due to context-switching, not > switch_mm() per se. Hopefully someone else beats me to remembering > the details before Monday. Sparc64 has a deadlock because we hold

[2.6 patch] drivers/media/dvb/b2c2/skystar2.c: remove an impossible code path

This patch removes an impossible code path found by the Coverity checker (look at the assignement in the first line of the context). Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- drivers/media/dvb/b2c2/skystar2.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) ---

[2.6 patch] drivers/scsi/qla2xxx/qla_os.c: remove dead code

This patch removes some dead code found by the Coverity checker (rval can't be FAILED at the time of this check). Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- linux-2.6.12-rc2-mm2-full/drivers/scsi/qla2xxx/qla_os.c.old 2005-04-09 22:24:09.0 +0200 +++

$B!y!!(BNEW$B!!(BOPEN$B!!!y(B

$B!!!z!y!z!!$D$$$K#O#P#E#N!*!!!z!y!z(B $B4JC1A`:n$G4JC1EPO?!*(B $B!!??7u$J=P2q$$$O$3$3$+$i(B $B!!(B $B=i$a$F$NJ}$OL5NA%(%s%H%j!<$+$i$I$&$>(B $B(Bhttp://www.getluck.net/ $B"(GIhttp://vger.kernel.org/majordomo-info.html Please read the

[2.6 patch] drivers/char/mwave/tp3780i.c: remove dead code

This patch removes some dead code found by the Coverity checker. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- drivers/char/mwave/tp3780i.c |6 +- 1 files changed, 1 insertion(+), 5 deletions(-) --- linux-2.6.12-rc2-mm2-full/drivers/char/mwave/tp3780i.c.old 2005-04-09

[2.6 patch] drivers/video/matrox/matroxfb_misc.c: remove dead code

This patch removes some obviously dead code found by the Coverity checker. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- linux-2.6.12-rc2-mm2-full/drivers/video/matrox/matroxfb_misc.c.old 2005-04-09 21:40:17.0 +0200 +++

[2.6 patch] drivers/net/ewrk3.c: remove dead code

This patch removes some obviously dead code found by the Coverity checker. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- drivers/net/ewrk3.c | 12 +++- 1 files changed, 3 insertions(+), 9 deletions(-) --- linux-2.6.12-rc2-mm2-full/drivers/net/ewrk3.c.old 2005-04-09

[2.6 patch] drivers/block/sx8.c: remove unused code

Is it planned to ever #define IF_64BIT_DMA_IS_POSSIBLE ? If not, the patch below removes this currently completely unused code. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- drivers/block/sx8.c | 30 ++ 1 files changed, 6 insertions(+), 24 deletions(-) ---

Re: Kernel SCM saga..

On Fri, 8 Apr 2005 22:45:18 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> wrote: > Also, I don't want people editing repostitory files by hand. Sure, the > sha1 catches it, but still... I'd rather force the low-level ops to use > the proper helper routines. Which is why it's a raw zlib

Re: [patch] sched: unlocked context-switches

On Sat, 09 Apr 2005 19:22:23 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > ppc64 already has a local_irq_save/restore in switch_to, around the low > level asm bits, so it should be fine. Sparc64 essentially does as well. In fact, it uses an IRQ disable which is stronger than

Re: [RFC,PATCH 3/4] Change synchronize_kernel to _rcu and _sched

Manfred Spraul <[EMAIL PROTECTED]> : [...] > I always thought that all callers of dev->hard_start_xmit() acquire > dev->xmit_lock before calling hard_start_xmit(). > > Is that assumption wrong? I think I even rely on that in one of my > drivers. Afaik, no, it is right. This part of the r8169

Status of new kernel.org servers

For those of you that are interested... The second new kernel.org server, named, ironically enough, zeus1.kernel.org went into the racks and, shortly thereafter, into production Friday. The only service that isn't served from both servers at this time is mirrors.kernel.org for the simple reason

Re: Kernel SCM saga..

* David Lang: >> Databases supporting replication are called high end. You forgot >> the cats dance around the network this issue involves. > > And Postgres (which is Free in all senses of the word) is high end by this > definition. I'm not aware of *any* DBMS, commercial or not, which can

Re: PROBLEM: CompactFlash mount Oops

Hi, The problem seems to be > cs: pcmcia_socket0: voltage interrogation timed out. Can you try passing the parameter setup_delay=50 to the module named "pcmcia", please? Dominik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

Re: more git updates..

Linus wrote: > the NUL-termination makes this really easy to use even in shell grumble ... > I still use the old tools I learnt to use fifteen years ago new comer ;) -- I won't rest till it's the best ... Programmer, Linux Scalability Paul

Unified changelogs for parsing by scripts

Hi Linus, Andrew, Marcelo, Greg, Chris, and folks, Since the SCM situation is changing, I thought I'd put in a word for those of us who like parsing changelogs via scripts. Hopefully the loss of BitKeeper will not involve a loss of detail in the changelogs as well. Maybe the changelogs could even

Re: bdflush/rpciod high CPU utilization, profile does not make sense

lau den 09.04.2005 Klokka 23:35 (+0200) skreiv Jakob Oestergaard: > 2.6.11.6: (dual PIII 1GHz, 2G RAM, Intel e1000) > > File Block Num Seq ReadRand Read Seq Write Rand Write > DirSize Size Thr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%) > --- -- ---

Re: bdflush/rpciod high CPU utilization, profile does not make sense

On Thu, Apr 07, 2005 at 12:17:51PM -0400, Trond Myklebust wrote: > to den 07.04.2005 Klokka 17:38 (+0200) skreiv Jakob Oestergaard: > > > I tweaked the VM a bit, put the following in /etc/sysctl.conf: > > vm.dirty_writeback_centisecs=100 > > vm.dirty_expire_centisecs=200 > > > > The defaults

Re: more git updates..

On Sat, 9 Apr 2005, Linus Torvalds wrote: > > I suspect that I have to change the file format. Maybe make the "tree" > object a two-level thing, and have a "directory" object. > > Then a "tree" object would point to a "directory" object, which would in > turn point to the individual files

Re: more git updates..

On Sat, 9 Apr 2005, Petr Baudis wrote: > > > Also, I wrote the "diff-tree" thing I talked about: > ..snip.. > > Hmm, I wonder, is this better done in C instead of a simple shell > script, like my gitdiff.sh? With 17,000 files in the kernel, and most commits just changing a small number of

Re: memory_barrier

Bart> Hi, Is there any reason why __memory_barrier() is still Bart> referenced in the kernel source? Bart> grep -r memory_barrier gave the following back, which at Bart> first seems to suggest barrier() is defined using some Bart> phantom __memory_barrier(), quite deceiving...

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

> > It's impossible to treat patents consistently. On Sat, Apr 09, 2005 at 04:38:15PM +0200, Adrian Bunk wrote: > Even RedHat with a stronger financial background than Debian considered > the MP3 patents being serious enough to remove MP3 support. It's silly to treat financial risk as being a

Re: patch to fix bashism

On Fri, Apr 08, 2005 at 11:11:38PM +0159, Han Boetes wrote: > Hi, > > This patch fixes a three bashisms in > scripts/gen_initramfs_list.sh; > > I'm not sure of the intention of the second change (local > name=...). So it's very well possible that: > > + local name="${location%/$srcdir}" >

Re: more git updates..

Hello, Dear diary, on Sat, Apr 09, 2005 at 09:45:52PM CEST, I got a letter where Linus Torvalds <[EMAIL PROTECTED]> told me that... > The good news is, the data structures/indexes haven't changed, but many of > the tools to interface with them have new (and improved!) semantics: > > In

Re: more git updates..

On Sat, 9 Apr 2005, Linus Torvalds wrote: > > To actually change the working directory, you'd first get the index file > setup, and then you do a "checkout-cache -a" to update the files in your > working directory with the files from the sha1 database. Btw, this will not overwrite any old

more git updates..

Sorry guys, several of you have sent me small fixes and scripts to "git", but I've been busy on breaking/changing the core infrastructure, so I didn't get around to looking at the scripts yet. The good news is, the data structures/indexes haven't changed, but many of the tools to interface

[2.6 patch] i386/x86_64 early_printk.c: make a variable static

This patch makes a needlessly global variable static. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- linux-2.6.12-rc2-mm2-full/arch/x86_64/kernel/early_printk.c.old 2005-04-09 20:51:23.0 +0200 +++ linux-2.6.12-rc2-mm2-full/arch/x86_64/kernel/early_printk.c 2005-04-09

[2.6 patch] crypto/api.c: make crypto_alg_lookup static

This patch makes a needlessly global function static. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- crypto/api.c |9 - crypto/internal.h |9 - 2 files changed, 8 insertions(+), 10 deletions(-) --- linux-2.6.12-rc2-mm2-full/crypto/internal.h.old 2005-04-09

Re: Kernel SCM saga..

On Sat, 2005-04-09 at 19:40 +0200, Roman Zippel wrote: > On Sat, 9 Apr 2005, Eric D. Mudama wrote: > > > For example bk does something like this: > > > > > > A1 -> A2 -> A3 -> BM > > > \-> B1 -> B2 --^ > > > > > > and instead of creating the merge changeset, one could merge

Re: Kernel SCM saga..

On 2005-04-09, at 17:42, Paul Jackson wrote: Marcin wrote: But what will impress you are either the price tag the DB comes with or the hardware it runs on :-) The payroll for the staffing to care and feed for these babies is often impressive as well. Please don't forget the bill from the electric

Re: [RFC,PATCH 3/4] Change synchronize_kernel to _rcu and _sched

On Sat, 9 Apr 2005, Francois Romieu wrote: > Manfred Spraul <[EMAIL PROTECTED]> : > > [Jeff added to cc list - it's a network driver question] > [...] > > I haven't read the whole driver, but what about > > spin_unlock_wait(>xmit_lock); > > ? > > The race here is a dev->close() against

memory_barrier

Hi, Is there any reason why __memory_barrier() is still referenced in the kernel source? grep -r memory_barrier gave the following back, which at first seems to suggest barrier() is defined using some phantom __memory_barrier(), quite deceiving... include/linux/compiler-intel.h:#define

Re: [PATCH 0/5] autoparam

On 21/03/05 00:06 +0100, Magnus Damm wrote: > Here are a set of patches that makes it possible to autogenerate kernel > command > line documentation from the source code. The approach is rather > straightforward > - the parameter name, the type and the description are stored in a section >

[PATCH] Re: Kernel SCM saga..

Dear diary, on Sat, Apr 09, 2005 at 09:08:59AM CEST, I got a letter where "Randy.Dunlap" <[EMAIL PROTECTED]> told me that... > On Sat, 9 Apr 2005 04:53:57 +0200 Petr Baudis wrote: ..snip.. > | FWIW, I made few small fixes (to prevent some trivial usage errors to > | cause cache corruption) and

[2.6 patch] let SOUND_AD1889 depend on PCI

Compiling SOUND_AD1889 with PCI=n results in the following compile error: <-- snip --> ... LD .tmp_vmlinux1 sound/built-in.o(.text+0x24f0c): In function `ad1889_remove': : undefined reference to `pci_release_region' make: *** [.tmp_vmlinux1] Error 1 <-- snip --> This patch adds

[2.6 patch] drivers/input/joystick/spaceorb.c: fix an array overflow

This patch fixes an array overflow found by the Coverity checker. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- This patch was already sent on: - 27 Mar 2005 --- linux-2.6.12-rc1-mm1-full/drivers/input/joystick/spaceorb.c.old 2005-03-23 02:12:33.0 +0100 +++

[2.6 patch] sound/oss/sonicvibes.c: fix an array overflow

This patch fixes an array overflow found by the Coverity checker. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- This patch was already sent on: - 27 Mar 2005 --- linux-2.6.12-rc1-mm1-full/sound/oss/sonicvibes.c.old2005-03-23 01:53:13.0 +0100 +++

[2.6 patch] drivers/serial/jsm/: make 2 functions static

- Forwarded message from Adrian Bunk <[EMAIL PROTECTED]> - Date: Sat, 2 Apr 2005 01:38:51 +0200 From: Adrian Bunk <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: linux-kernel@vger.kernel.org Subject: [2.6 patch drivers/serial/jsm/: make 2 functions static This patch

[2.6 patch] drivers/pnp/pnpacpi/rsparser.c: fix an array overflow

This patch fixes an array overflow found by the Coverity checker. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- This patch was already sent on: - 27 Mar 2005 --- linux-2.6.12-rc1-mm1-full/drivers/pnp/pnpacpi/rsparser.c.old 2005-03-23 02:58:31.0 +0100 +++

[2.6 patch] drivers/video/radeonfb.c: fix an array overflow

This patch fixes an array overflow found by the Coverity checker. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- This patch was already sent on: - 27 Mar 2005 --- linux-2.6.12-rc1-mm1-full/drivers/video/radeonfb.c.old 2005-03-23 01:50:14.0 +0100 +++

[-mm patch] net/ieee80211/ieee80211_tx.c: swapped memset arguments

Fix swapped memset() arguments in net/ieee80211/ieee80211_tx.c found by Maciej Soltysiak. Patch by Jesper Juhl. Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- This patch was sent by Jesper Juhl on: - 3 Apr 2005 ---

[2.6 patch] drivers/pnp/pnpbios/rsparser.c: fix an array overflow

This patch fixes an array overflow found by the Coverity checker. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- This patch was already sent on: - 27 Mar 2005 --- linux-2.6.12-rc1-mm1-full/drivers/pnp/pnpbios/rsparser.c.old 2005-03-23 03:04:17.0 +0100 +++

reboot problem in 2.6.x kernels, where 2.4.x kernels work well

Hi all, as I reported before (see here: http://www.uwsg.iu.edu/hypermail/linux/kernel/0503.3/0975.html or here: http://lkml.org/lkml/2005/3/28/38 ) -- there is a reboot problem under 2.6.x kernels with VIA EPIA MS boards. Now I have found that kernels 2.4.x seem to work well under different

Re: Kernel SCM saga..

Hi, On Sat, 9 Apr 2005, Eric D. Mudama wrote: > > For example bk does something like this: > > > > A1 -> A2 -> A3 -> BM > > \-> B1 -> B2 --^ > > > > and instead of creating the merge changeset, one could merge them like > > this: > > > > A1 -> A2 -> A3 -> B1 -> B2 >

Re: Kernel SCM saga..

> (b) while I depend on the fact that if the SHA of an object matches, the > objects are the same, I generally try to avoid the reverse > dependency. It might be a valid point that you want to leave the door open to using a different (than SHA1) digest. (So this means you going to

[2.6 patch] remove BK documentation

Whatever the new SCM will be, there's no longer a reason to document the obsolete BK usage. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- Documentation/00-INDEX |2 Documentation/BK-usage/00-INDEX| 51 --- Documentation/BK-usage/bk-kernel-howto.txt

Re: Kernel SCM saga..

Linus wrote: > In "git", you usually care about > the old contents too. True - in your case, you probably want the old contents so might as well dig them out as soon as it becomes convenient to have them. I was objecting to your claim that you _had_ to dig out the old contents to determine

Re: Kernel SCM saga..

Hi, On Fri, 8 Apr 2005, Linus Torvalds wrote: > Yes. Per-file history is expensive in git, because if the way it is > indexed. Things are indexed by tree and by changeset, and there are no > per-file indexes. > > You could create per-file _caches_ (*) on top of git if you wanted to make > it

Re: Kernel SCM saga..

Linus wrote: > (you need to remember to escape '%' > too when you do that ;). No - don't have to. Not if I don't mind giving fools that embed newlines in paths second class service. In my case, if I create a file named "foo\nbar", then backup and restore it, I end up with a restored file named

Re: Kernel SCM saga..

On Apr 8, 2005 4:52 PM, Roman Zippel <[EMAIL PROTECTED]> wrote: > The problem is you pay a price for this. There must be a reason developers > were adding another GB of memory just to run BK. > Preserving the complete merge history does indeed make repeated merges > simpler, but it builds up

2.6.12-rc2: Promise SATA150 TX4 failures

Hi all, just tried 2.6.12-rc2 and I still have the same errors from my SATA disks as with 2.6.11. The setup is a bit complex. The relevant parts (I think) are: Adaptec AHA-2940UW SCSI-controller, attached are: 1 harddisk /dev/sda 1 DDS3 streamer /dev/st0 Promise SATA150 TX4 controller,

PROPOSAL !

Dear Friend, I am Mr LEE CHEN,managinig director of China National Arts & Crafts Import./Export. Corp. we are a group of business men who deal on Art and Craft and export into the Canada/America and Europe. We are searching for representatives who can help us establish a medium of getting to our

Re: Kernel SCM saga..

Hi, On Fri, 8 Apr 2005, Linus Torvalds wrote: > Also, I suspect that BKCVS actually bothers to get more details out of a > BK tree than I cared about. People have pestered Larry about it, so BKCVS > exports a lot of the nitty-gritty (per-file comments etc) that just > doesn't actually _matter_,

Re: [PATCH] radeonfb: (#2) Implement proper workarounds for PLL accesses

Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes: > Can you redo the counting of the workarounds with the patch ? Switching from X to console: radeon_write_pll_regs: INPLL radeon_write_pll_regs: INPLL radeon_write_mode: OUTPLL radeonfb_engine_reset: INPLL radeonfb_engine_reset: OUTPLL

Re: Kernel SCM saga..

On Sat, 9 Apr 2005, Paul Jackson wrote: > > > in order to avoid having to worry about special characters > > they are NUL-terminated) > > Would this be a possible alternative - newline terminated (convert any > newlines embedded in filenames to the 3 chars '%0A', and leave it as an > exercise

Re: Kernel SCM saga..

On Thu, Apr 07, 2005 at 12:30:18PM +0200, Matthias Andree wrote: > On Thu, 07 Apr 2005, Sergei Organov wrote: > > darcs? > > Close. Some things: > > 1. It's rather slow and quite CPU consuming and certainly I/O consuming >at times - I keep, to try it out,

Re: Kernel SCM saga..

Linus wrote: > If you want to have spaces > and newlines in your pathname, go wild. So long as there is only one pathname in a record, you don't need nul-terminators to be allow spaces in the name. The rest of the record is well known, so the pathname is just whatever is left after chomping off

Re: Kernel SCM saga..

On Sat, 9 Apr 2005, Paul Jackson wrote: > > I must be missing something here ... > > If the stat shows a possible change, then you shouldn't have to open the > original version to determine if it really changed - just compute the > SHA1 of the new file, and see if that changed from the

Re: Kernel SCM saga..

> in order to avoid having to worry about special characters > they are NUL-terminated) Would this be a possible alternative - newline terminated (convert any newlines embedded in filenames to the 3 chars '%0A', and leave it as an exercise to the reader to de-convert them.) Line formatted ASCII

Re: Kernel SCM saga..

Marcin wrote: > But what will impress you are either the price tag the > DB comes with or > the hardware it runs on :-) The payroll for the staffing to care and feed for these babies is often impressive as well. -- I won't rest till it's the best ...

Re: Kernel SCM saga..

Linus wrote: > then git will open have exactly _one_ > file (no searching, no messing around), which contains absolutely nothing > except for the compressed (and SHA1-signed) old contents of the file. It > obviously _has_ to do that, because in order to know whether you've > changed it, it

Re: Kernel SCM saga..

Linus wrote: > you need to reuse the same inode/dev numbers > (again - I didn't worry about portability, and filesystems where those > aren't stable are a "don't do that then") On filesystems that don't have a stable inode number, I use the md5sum of the full (relative to mount point) pathname

2.6.12-rc2 oops PREEMPT DEBUG_PAGEALLOC sysenter_past_esp+0x3/0x75

I got around to booting 2.6.12-rc2 here at home last night, and got several (12) oops. Here is a typical one. They all have the same trace, but occured on differing processes. [18008.409586] <1>Unable to handle kernel paging request at virtual address c2166000 [24538.187178] printing eip:

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

On Fri, Apr 08, 2005 at 08:31:22PM -0400, Raul Miller wrote: > On Fri, Apr 08, 2005 at 07:34:00PM +0200, Adrian Bunk wrote: > > If Debian was at least consistent. > > > > Why has Debian a much more liberal interpretation of MP3 patent issues > > than RedHat? > > It's impossible to treat patents

  1   2   3   4   >