* Re: Intel sez: Synchronous Flash and XIP is the future -- thoughts?
From: Nicolas Pitre @ 2002-12-16 18:06 UTC (permalink / raw)
To: David Woodhouse; +Cc: Wolfgang Denk, Paul Nash, Linux-MTD (E-mail)
In-Reply-To: <3806.1040060329@passion.cambridge.redhat.com>
On Mon, 16 Dec 2002, David Woodhouse wrote:
>
> nico@cam.org said:
> > On ARM this has no value since the kernel takes up at most 1 or 2
> > page table entries (1MB section descriptors that is).
>
> But you could still start up quickly from flash without having to memcpy
> the entire kernel into RAM first, then once you're running copy the kernel
> text into RAM and alter the page tables so you're running from the RAM copy
> instead of the flash.
>
> This gives you the fast startup of XIP without the runtime pain of XIP. But
> it's probably overkill.
Well at that point I prefer the penalty of about half a second with storing
a compressed kernel in flash and let it decompress to RAM directly. Oh and
btw we've made the ARM kernel decompressor XIP from flash long time ago.
Nicolas
^ permalink raw reply
* Re: Notification hooks
From: Arjan van de Ven @ 2002-12-16 17:18 UTC (permalink / raw)
To: Ben Collins; +Cc: Linus Torvalds, linux-kernel, Larry McVoy
In-Reply-To: <20021216171218.GV504@hopper.phunnypharm.org>
[-- Attachment #1: Type: text/plain, Size: 560 bytes --]
On Mon, 2002-12-16 at 18:12, Ben Collins wrote:
> Linus, is there anyway I can request a hook so that anything that
> changes drivers/ieee1394/ in your repo sends me an email with the diff
> for just the files in that directory, and the changeset log? Is this
> something that bkbits can do?
>
> I'd bet lots of ppl would like similar hooks for their portions of the
> source.
well there is the bk commits list that has all individual changesets.
Add procmail and the patchutils program "grepdiff" to the recipe and I
think we have a winner.....
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [parisc-linux] Re: YA pb with PCI IDE (my merge 2.4.21-pre1)
From: Matthew Wilcox @ 2002-12-16 17:29 UTC (permalink / raw)
To: Alan Cox; +Cc: jsoe0708, parisc-linux
In-Reply-To: <1040061866.13786.74.camel@irongate.swansea.linux.org.uk>
On Mon, Dec 16, 2002 at 06:04:26PM +0000, Alan Cox wrote:
> On Mon, 2002-12-16 at 17:06, jsoe0708@tiscali.be wrote:
> > Hi Alan,
> >
> > Worried about ext3 pb, I try to merge parisc kernel 2.4.20-pa14 with 2.4.21-pre1.
> > This merge seems to works fine on a b180l+ (without pci devices).
> > But still boot twice (??) and crash on a b2k with an ide cdrom.
>
> I've sent the PCI fixup patch to linux-kernel. Depending upon how the
> PA-RISC system interfaces to the IDE controller you may also need
> platform specific fixups or to drop the chip into Native mode.
You mean the "IDE but no disks" patch:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0212.2/0105.html ?
If so, that might be relevant, but have davem's concerns about this IDE
code being broken on big-endian machines been addressed?
--
"It's not Hollywood. War is real, war is primarily not about defeat or
victory, it is about death. I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk
^ permalink raw reply
* Re: Linux v2.5.52
From: Ben Collins @ 2002-12-16 17:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Christoph Hellwig, Kernel Mailing List
In-Reply-To: <Pine.LNX.4.44.0212160920380.2799-100000@home.transmeta.com>
> If you think that "maintainer" means that nobody else can touch the tree
> and that you thus don't need to care, you're WRONG.
I never said that. What I said was that because I can't spend lots of
time tracking changes, _sometimes_ I miss them. You will see in the SVN
repo logs a lot of places where I merge in changes from your tree. It's
a fact that people make mistakes. I've already rectified this one by
adding in the patch to the linux1394 repo.
I wasn't pushing off blame, just noting that it's not possible to never
make mistakes. You make them too.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
^ permalink raw reply
* Re: 2 (minor) Alpha probs in 2.5.51
From: Richard Henderson @ 2002-12-16 17:35 UTC (permalink / raw)
To: Dr. David Alan Gilbert; +Cc: linux-kernel
In-Reply-To: <20021216124937.GE709@gallifrey>
On Mon, Dec 16, 2002 at 12:49:37PM +0000, Dr. David Alan Gilbert wrote:
> > Dunno. Could be your clock chip is going bad.
>
> Don't think so; with 2.4.19 it seems to be fine, and it returns to the
> low value after restarting a kernel from MILO even without powering the
> machine down or returning to AlphaBIOS.
On the other hand, the code hasn't changed since 2.4 either.
r~
^ permalink raw reply
* Re: slow NFS performance extracting bits from large files
From: Bruce Allan @ 2002-12-16 17:27 UTC (permalink / raw)
To: Bruce Allen; +Cc: nfs, nfs-admin
Hi Bruce (good name, btw),
It would help if you posted information about your network. Alternately,
you could read the "Optimizing NFS Performance" section of the Linux
NFS-HOWTO located at http://nfs.sourceforge.net/nfs-howto/
Regards,
---
Bruce Allan <bruce.allan@us.ibm.com>
Software Engineer, Linux Technology Center
IBM Corporation, Beaverton OR
503-578-4187 IBM Tie-line 775-4187
Bruce Allen
<ballen@gravity.phys To: nfs@lists.sourceforge.net
.uwm.edu> cc: Bruce Allen <ballen@gravity.phys.uwm.edu>
Sent by: Subject: [NFS] slow NFS performance extracting bits from large files
nfs-admin@lists.sour
ceforge.net
12/15/2002 11:02 PM
I've searched/browsed the mail archive and the online documentation but am
still a bit clueless about where to start.
I am working on a scientific data analysis application which needs to
extract a little bit of data from around 10,000 files. The files
themselves are each around 1 MB in size. The application does:
for (i=0; i<10000; i++){
open() ith file
read() 32 bytes from beginning
lseek() to somewhere in the middle of the file
read() 620 bytes from the middle of the file
close() ith file
}
If I run this with the data set on a local disk, the total run time is
around 1 sec -- very reasonable since I am transferring around 6 MB of
data.
If I run this on an NFS-mounted disk the performance is 100 times worse.
Both client and server are stock RH 7.3. Note that if I run it a second
time, when the data is presumably cached, it takes just a few seconds to
run.
Is it obvious what needs to be changed/tuned to improve this performance?
Or if not, could someone suggest a tool and a strategy for tracing down
the cause of the poor performance?
Sincerely,
Bruce Allen
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: Notification hooks
From: Christoph Hellwig @ 2002-12-16 17:34 UTC (permalink / raw)
To: Ben Collins; +Cc: Linus Torvalds, linux-kernel, Larry McVoy
In-Reply-To: <20021216171218.GV504@hopper.phunnypharm.org>
On Mon, Dec 16, 2002 at 12:12:18PM -0500, Ben Collins wrote:
> Linus, is there anyway I can request a hook so that anything that
> changes drivers/ieee1394/ in your repo sends me an email with the diff
> for just the files in that directory, and the changeset log? Is this
> something that bkbits can do?
How about subscribing to the commits list throw away every mail not
containing ieee1394 with procmail (or $MAILFILTER)?
^ permalink raw reply
* [parisc-linux] Re: YA pb with PCI IDE (my merge 2.4.21-pre1)
From: Alan Cox @ 2002-12-16 18:04 UTC (permalink / raw)
To: jsoe0708; +Cc: parisc-linux
In-Reply-To: <3DED9BF500001EC5@ocpmta8.freegates.net>
On Mon, 2002-12-16 at 17:06, jsoe0708@tiscali.be wrote:
> Hi Alan,
>
> Worried about ext3 pb, I try to merge parisc kernel 2.4.20-pa14 with 2.4.21-pre1.
> This merge seems to works fine on a b180l+ (without pci devices).
> But still boot twice (??) and crash on a b2k with an ide cdrom.
I've sent the PCI fixup patch to linux-kernel. Depending upon how the
PA-RISC system interfaces to the IDE controller you may also need
platform specific fixups or to drop the chip into Native mode.
Someone at HP can probably answer that bit
^ permalink raw reply
* Re: installing Predict on a RedHat 7.3 box , no go :^(
From: John @ 2002-12-16 17:24 UTC (permalink / raw)
To: htodd; +Cc: linux-hams
In-Reply-To: <Pine.OSX.4.50.0212152001270.8533-100000@lesleyanne.i8u.org>
On 15 Dec, Hisashi T Fujinaka wrote:
> Predict isn't all that hard to get going. I even got it going on a NetBSD
> box.
I have it running on several SuSE systems, CygWIN on Windows and on IRIX
6.5 on an ancient SGI Challenge S...
See my Predict 2.2.1 mods at:
http://voyager.mcc.ac.uk/Predict/
or
http://cumin.mcc.ac.uk/Predict/
John
--
John Heaton, G1YYH
Manchester Computing, Kilburn Building.
The University of Manchester, Oxford Road, Manchester, England, M13-9PL
pstn://+44-161-275-6011/Hello/Is.Dat-U?
fax://+44-161-275-6040/screech/warble/ssshhh/beepbeep
^ permalink raw reply
* Multithreaded coredump patch where?
From: Roberto Fichera @ 2002-12-16 17:28 UTC (permalink / raw)
To: linux-kernel
Does anyone point me where can I download a stable
multithread coredump patch for the 2.4.19/20 kernel ?
Thanks in advance,
Roberto Fichera.
______________________________________
E-mail protetta dal servizio antivirus di IsolaWeb Agency & ISP
http://wwww.isolaweb.it
^ permalink raw reply
* Re: Notification hooks
From: Arjan van de Ven @ 2002-12-16 17:28 UTC (permalink / raw)
To: Ben Collins
Cc: Larry McVoy, Arjan van de Ven, Linus Torvalds, linux-kernel,
Larry McVoy
In-Reply-To: <20021216172722.GX504@hopper.phunnypharm.org>
On Mon, Dec 16, 2002 at 12:27:22PM -0500, Ben Collins wrote:
> > bk help triggers.
>
> Well, if it affects more than just the files I am interested in, I only
> want the diff for those files, but the changeset log and files-affected
> for the whole changeset.
>
> If I want the full diff I can go to bkbits or the archive of the commit
> list.
well grepdiff and filterdiff can do that I bet...
filterdiff takes a wildcard and only lets patches through that touch files
that match this wildcard...
^ permalink raw reply
* Re: Notification hooks
From: Ben Collins @ 2002-12-16 17:27 UTC (permalink / raw)
To: Larry McVoy, Arjan van de Ven, Linus Torvalds, linux-kernel,
Larry McVoy
In-Reply-To: <20021216092129.D432@work.bitmover.com>
On Mon, Dec 16, 2002 at 09:21:29AM -0800, Larry McVoy wrote:
> On Mon, Dec 16, 2002 at 06:18:55PM +0100, Arjan van de Ven wrote:
> > On Mon, 2002-12-16 at 18:12, Ben Collins wrote:
> > > Linus, is there anyway I can request a hook so that anything that
> > > changes drivers/ieee1394/ in your repo sends me an email with the diff
> > > for just the files in that directory, and the changeset log? Is this
> > > something that bkbits can do?
> > >
> > > I'd bet lots of ppl would like similar hooks for their portions of the
> > > source.
> >
> > well there is the bk commits list that has all individual changesets.
> > Add procmail and the patchutils program "grepdiff" to the recipe and I
> > think we have a winner.....
>
> I suspect you want to look at all the files in the cset. I think what
> you want is a script which is given a list of files and sends a patch
> for each new changeset which touches any of those files. Because if
> a changeset touched drivers/ieee1394/ and include/something then you
> probably want both.
>
> bk help triggers.
Well, if it affects more than just the files I am interested in, I only
want the diff for those files, but the changeset log and files-affected
for the whole changeset.
If I want the full diff I can go to bkbits or the archive of the commit
list.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
^ permalink raw reply
* Can somebody help me with setting up a server behind a sdsl router?
From: Jason Corekin @ 2002-12-16 17:20 UTC (permalink / raw)
To: netfilter
[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]
I have a friend who is trying to setup a Netopia R7100 sdsl router. I know that this is not a netfilter specific question, but it is largely the same stuff, just a different implementation. He has a few different publicly registered static ip's and has had one of the assigned to the dsl connection and has had it configured to pass the connection then to another router that is NATing for his internal network. Now he wants to use another one of his publicly registered static ip's for his mail server, which we are trying to plug into one of the unused jacks on the built it hub on the R7100. The problem is that we can not get the R7100 to respond to more then one public address. Is there a way that we should be able to setup the R7100 such that it would route the second address through it to the mail server? How would the rest of the internet know to talk to the R7100 to get to his mail server? This sounds like just a basic routing issue but my knowledge is limited.
Thanks for any help you might offer
Jason Corekin
[-- Attachment #2: Type: text/html, Size: 1587 bytes --]
^ permalink raw reply
* Re: usbaudio won't do 24-bit or 32-bit i/o...
From: Takashi Iwai @ 2002-12-16 17:19 UTC (permalink / raw)
To: Patrick Shirkey; +Cc: alsa-devel
In-Reply-To: <3DFB0C79.7010000@boosthardware.com>
[-- Attachment #1: Type: text/plain, Size: 1052 bytes --]
At Sat, 14 Dec 2002 19:48:25 +0900,
Patrick Shirkey wrote:
>
> Takashi Iwai wrote:
>
> >
> > could you tell me the rcs version numbers of the files on
> > alsa-kernel/usb you are using (18 Nov.) ? i've checked the files via
> > cvs but i couldn't see any differences around the date.
> >
>
> I have managed to test a more upto date version since then and it is the
> same. I have no idea when this happened though as I wasn't actively
> testing the 24 bit support until recently. I have a vague memory of
> testing it much earlier in the year but I think that was only for playback.
>
> I currently cannot record from input 1 and 2 either.
hmm, it's weird. it would be nice if we can know at which point the
driver became broken...
> Working are:
>
> output 1,2,3,4
> input 3,4
>
> I also have to initialise both pcms with the small utility you made.
the attached patch will (hopefully) do the same thing as qinit in the
kernel at the initialization (applied to the latest cvs). please let
me know whether it works.
ciao,
Takashi
[-- Attachment #2: usb-qinit.dif --]
[-- Type: application/octet-stream, Size: 5522 bytes --]
Index: alsa-kernel/usb/usbaudio.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/usb/usbaudio.c,v
retrieving revision 1.29
diff -u -r1.29 usbaudio.c
--- alsa-kernel/usb/usbaudio.c 16 Dec 2002 17:15:05 -0000 1.29
+++ alsa-kernel/usb/usbaudio.c 16 Dec 2002 17:14:16 -0000
@@ -928,6 +928,70 @@
/*
+ * initialize the picth control and sample rate
+ */
+static int init_usb_pitch(struct usb_device *dev, int iface,
+ struct usb_host_interface *alts,
+ struct audioformat *fmt)
+{
+ unsigned int ep;
+ unsigned char data[1];
+ int err;
+
+ ep = get_endpoint(alts, 0)->bEndpointAddress;
+ /* if endpoint has pitch control, enable it */
+ if (fmt->attributes & EP_CS_ATTR_PITCH_CONTROL) {
+ data[0] = 1;
+ if ((err = usb_control_msg(dev, usb_sndctrlpipe(dev, 0), SET_CUR,
+ USB_TYPE_CLASS|USB_RECIP_ENDPOINT|USB_DIR_OUT,
+ PITCH_CONTROL << 8, ep, data, 1, HZ)) < 0) {
+ snd_printk(KERN_ERR "%d:%d:%d: cannot set enable PITCH\n",
+ dev->devnum, iface, ep);
+ return err;
+ }
+ }
+ return 0;
+}
+
+static int init_usb_sample_rate(struct usb_device *dev, int iface,
+ struct usb_host_interface *alts,
+ struct audioformat *fmt, int rate)
+{
+ unsigned int ep;
+ unsigned char data[3];
+ int err;
+
+ ep = get_endpoint(alts, 0)->bEndpointAddress;
+ /* if endpoint has sampling rate control, set it */
+ if (fmt->attributes & EP_CS_ATTR_SAMPLE_RATE) {
+ int crate;
+ data[0] = rate;
+ data[1] = rate >> 8;
+ data[2] = rate >> 16;
+ if ((err = usb_control_msg(dev, usb_sndctrlpipe(dev, 0), SET_CUR,
+ USB_TYPE_CLASS|USB_RECIP_ENDPOINT|USB_DIR_OUT,
+ SAMPLING_FREQ_CONTROL << 8, ep, data, 3, HZ)) < 0) {
+ snd_printk(KERN_ERR "%d:%d:%d: cannot set freq %d to ep 0x%x\n",
+ dev->devnum, iface, fmt->altsetting, rate, ep);
+ return err;
+ }
+ if ((err = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0), GET_CUR,
+ USB_TYPE_CLASS|USB_RECIP_ENDPOINT|USB_DIR_IN,
+ SAMPLING_FREQ_CONTROL << 8, ep, data, 3, HZ)) < 0) {
+ snd_printk(KERN_ERR "%d:%d:%d: cannot get freq at ep 0x%x\n",
+ dev->devnum, iface, fmt->altsetting, ep);
+ return err;
+ }
+ crate = data[0] | (data[1] << 8) | (data[2] << 16);
+ if (crate != rate) {
+ snd_printd(KERN_WARNING "current rate %d is different from the runtime rate %d\n", crate, rate);
+ // runtime->rate = crate;
+ }
+ }
+ return 0;
+}
+
+/*
* find a matching format and set up the interface
*/
static int set_format(snd_usb_substream_t *subs, snd_pcm_runtime_t *runtime)
@@ -939,7 +1003,6 @@
struct usb_interface *iface;
struct audioformat *fmt;
unsigned int ep, attr;
- unsigned char data[3];
int is_playback = subs->direction == SNDRV_PCM_STREAM_PLAYBACK;
int err;
@@ -1012,44 +1075,11 @@
subs->syncinterval = get_endpoint(alts, 1)->bRefresh;
}
- ep = get_endpoint(alts, 0)->bEndpointAddress;
- /* if endpoint has pitch control, enable it */
- if (fmt->attributes & EP_CS_ATTR_PITCH_CONTROL) {
- data[0] = 1;
- if ((err = usb_control_msg(dev, usb_sndctrlpipe(dev, 0), SET_CUR,
- USB_TYPE_CLASS|USB_RECIP_ENDPOINT|USB_DIR_OUT,
- PITCH_CONTROL << 8, ep, data, 1, HZ)) < 0) {
- snd_printk(KERN_ERR "%d:%d:%d: cannot set enable PITCH\n",
- dev->devnum, subs->interface, ep);
- return err;
- }
- }
- /* if endpoint has sampling rate control, set it */
- if (fmt->attributes & EP_CS_ATTR_SAMPLE_RATE) {
- int crate;
- data[0] = runtime->rate;
- data[1] = runtime->rate >> 8;
- data[2] = runtime->rate >> 16;
- if ((err = usb_control_msg(dev, usb_sndctrlpipe(dev, 0), SET_CUR,
- USB_TYPE_CLASS|USB_RECIP_ENDPOINT|USB_DIR_OUT,
- SAMPLING_FREQ_CONTROL << 8, ep, data, 3, HZ)) < 0) {
- snd_printk(KERN_ERR "%d:%d:%d: cannot set freq %d to ep 0x%x\n",
- dev->devnum, subs->interface, fmt->altsetting, runtime->rate, ep);
- return err;
- }
- if ((err = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0), GET_CUR,
- USB_TYPE_CLASS|USB_RECIP_ENDPOINT|USB_DIR_IN,
- SAMPLING_FREQ_CONTROL << 8, ep, data, 3, HZ)) < 0) {
- snd_printk(KERN_ERR "%d:%d:%d: cannot get freq at ep 0x%x\n",
- dev->devnum, subs->interface, fmt->altsetting, ep);
- return err;
- }
- crate = data[0] | (data[1] << 8) | (data[2] << 16);
- if (crate != runtime->rate) {
- snd_printd(KERN_WARNING "current rate %d is different from the runtime rate %d\n", crate, runtime->rate);
- // runtime->rate = crate;
- }
- }
+ if ((err = init_usb_pitch(dev, subs->interface, alts, fmt)) < 0 ||
+ (err = init_usb_sample_rate(dev, subs->interface, alts, fmt,
+ runtime->rate)) < 0)
+ return err;
+
/* always fill max packet size */
if (fmt->attributes & EP_CS_ATTR_FILL_MAX)
subs->fill_max = 1;
@@ -1829,6 +1859,10 @@
kfree(fp);
return err;
}
+ /* try to set the interface... */
+ usb_set_interface(chip->dev, iface_no, i);
+ init_usb_pitch(chip->dev, iface_no, alts, fp);
+ init_usb_sample_rate(chip->dev, iface_no, alts, fp, fp->rate_max);
}
return 0;
}
@@ -1891,9 +1925,10 @@
/* skip non-supported classes */
continue;
}
- parse_audio_endpoints(chip, buffer, buflen, j);
- usb_set_interface(dev, j, 0); /* reset the current interface */
- usb_driver_claim_interface(&usb_audio_driver, iface, (void *)-1);
+ if (! parse_audio_endpoints(chip, buffer, buflen, j)) {
+ usb_set_interface(dev, j, 0); /* reset the current interface */
+ usb_driver_claim_interface(&usb_audio_driver, iface, (void *)-1);
+ }
}
return 0;
^ permalink raw reply
* Re: Notification hooks
From: Larry McVoy @ 2002-12-16 17:25 UTC (permalink / raw)
To: Ben Collins; +Cc: Dave Jones, Linus Torvalds, linux-kernel, Larry McVoy
In-Reply-To: <20021216172330.GW504@hopper.phunnypharm.org>
> True. But if the load is too much for bkbits to handle, I'd like Linus
> to consider it just for maintainers.
bkbits can keep up, that's not the issue. The main problem is coming up
with an interface that makes sense for people. The mechanisms are all
there already in the form of triggers.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
^ permalink raw reply
* Re: Linux v2.5.52
From: Linus Torvalds @ 2002-12-16 17:26 UTC (permalink / raw)
To: Ben Collins; +Cc: Christoph Hellwig, Kernel Mailing List
In-Reply-To: <20021216151639.GQ504@hopper.phunnypharm.org>
On Mon, 16 Dec 2002, Ben Collins wrote:
>
> How about pointing out some specifics? Maybe make my job easier by
> getting me some patches directly. Trying to track two seperate source
> tree's isn't as easy as you might think.
It's a lot easier if you track them _often_ instead of just occasionally.
That's the main problem I have with other peoples CVS trees - CVS has very
little support for tracking any outside sources, and that coupled with the
fact that people don't track it in a timely manner always generates
problems.
With CVS, a simple script like
(a) get current version
(b) diff against the last version you did the merge against
(c) apply the diff to your new tree
(d) _then_ do the diff against the current version
(e) delete "last version merged", make current version that.
will work pretty easily most of the time for subsystems that don't get a
lot of input from outside the "maintainer". Especially if you do it
reasonably often (you can do the back-merge even when you're _not_ ready
to actually send me your stuff), the diff from my tree is often quite
small and thus easily mergible.
If you think that "maintainer" means that nobody else can touch the tree
and that you thus don't need to care, you're WRONG.
Alternatively, never EVER make a patch against the "current kernel
version". Only make a patch against the _last_ kernel that you merged
with, and if I cannot apply it I will tell you so. Making a patch just
between your tree and mine will _always_ end up losing fixes.
Linus
^ permalink raw reply
* Re: Notification hooks
From: Larry McVoy @ 2002-12-16 17:24 UTC (permalink / raw)
To: Dave Jones, Ben Collins, Linus Torvalds, linux-kernel,
Larry McVoy
In-Reply-To: <20021216171925.GC15256@suse.de>
On Mon, Dec 16, 2002 at 05:19:25PM +0000, Dave Jones wrote:
> On Mon, Dec 16, 2002 at 12:12:18PM -0500, Ben Collins wrote:
> > Linus, is there anyway I can request a hook so that anything that
> > changes drivers/ieee1394/ in your repo sends me an email with the diff
> > for just the files in that directory, and the changeset log? Is this
> > something that bkbits can do?
> >
> > I'd bet lots of ppl would like similar hooks for their portions of the
> > source.
>
> It'd be nice if the bkbits webpage had a "notify me" interface for files
> in Linus' repository. This way not just the maintainers, but folks
> interested in changes in that area can also see the changes.
Just for linux.bkbits.net or for the openlogging tree? To remind people,
linux.bkbits.net has Linus/Marcelo trees but openlogging.org has the
union of all trees anywhere in the world. And openlogging doesn't have
contents, it just has comments.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
^ permalink raw reply
* Re: Notification hooks
From: Greg KH @ 2002-12-16 17:22 UTC (permalink / raw)
To: Ben Collins; +Cc: Linus Torvalds, linux-kernel, Larry McVoy
In-Reply-To: <20021216171218.GV504@hopper.phunnypharm.org>
On Mon, Dec 16, 2002 at 12:12:18PM -0500, Ben Collins wrote:
> Linus, is there anyway I can request a hook so that anything that
> changes drivers/ieee1394/ in your repo sends me an email with the diff
> for just the files in that directory, and the changeset log? Is this
> something that bkbits can do?
Just subscribe to the bk-commits-head mailing list, and then have
procmail set up a filter to alert you to anything that happens to files
in any specific directories.
Or do something else with the data sent on that mailing list, or look at
the changeset files on kernel.org that are constantly being generated.
There are lots of ways to get this information without relying on hooks
in bk.
Hope this helps,
greg k-h
^ permalink raw reply
* Re: 2.5.52 and modules (lots of unresolved symbols)?
From: Alex Goddard @ 2002-12-16 12:11 UTC (permalink / raw)
To: Gregoire Favre; +Cc: linux-kernel
In-Reply-To: <20021216171703.GD13198@ulima.unil.ch>
On Mon, 16 Dec 2002, Gregoire Favre wrote:
> On Mon, Dec 16, 2002 at 11:19:00AM +0000, Alex Goddard wrote:
>
> > > I have just patched 2.5.51, and not done the make clean && make mrproper
> > > before doing a make menuconfig && make dep && make bzImage && make
> > > modules...
> > >
> > > Will that change anything to make clean/mrproper here?
> >
> > I would give 'make clean' a try.
>
> I am just doing that right now... I'll wait till completion to report
> the issue:
>
> No change, still the same messages :-(
Huh. Like I said, reinstalling the mod tools and doing a rebuild after a
make clean cleared it up for me.
Weird.
> Thank you very much and have a great day,
You too.
--
Alex Goddard
agoddard@purdue.edu
^ permalink raw reply
* Re: Notification hooks
From: Ben Collins @ 2002-12-16 17:23 UTC (permalink / raw)
To: Dave Jones, Linus Torvalds, linux-kernel, Larry McVoy
In-Reply-To: <20021216171925.GC15256@suse.de>
On Mon, Dec 16, 2002 at 05:19:25PM +0000, Dave Jones wrote:
> On Mon, Dec 16, 2002 at 12:12:18PM -0500, Ben Collins wrote:
> > Linus, is there anyway I can request a hook so that anything that
> > changes drivers/ieee1394/ in your repo sends me an email with the diff
> > for just the files in that directory, and the changeset log? Is this
> > something that bkbits can do?
> >
> > I'd bet lots of ppl would like similar hooks for their portions of the
> > source.
>
> It'd be nice if the bkbits webpage had a "notify me" interface for files
> in Linus' repository. This way not just the maintainers, but folks
> interested in changes in that area can also see the changes.
>
> As well as opening this up for more people, it'd also take the load
> of Linus having to do it.
True. But if the load is too much for bkbits to handle, I'd like Linus
to consider it just for maintainers.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
^ permalink raw reply
* Re: Notification hooks
From: Larry McVoy @ 2002-12-16 17:21 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Ben Collins, Linus Torvalds, linux-kernel, Larry McVoy
In-Reply-To: <1040059138.1438.1.camel@laptop.fenrus.com>
On Mon, Dec 16, 2002 at 06:18:55PM +0100, Arjan van de Ven wrote:
> On Mon, 2002-12-16 at 18:12, Ben Collins wrote:
> > Linus, is there anyway I can request a hook so that anything that
> > changes drivers/ieee1394/ in your repo sends me an email with the diff
> > for just the files in that directory, and the changeset log? Is this
> > something that bkbits can do?
> >
> > I'd bet lots of ppl would like similar hooks for their portions of the
> > source.
>
> well there is the bk commits list that has all individual changesets.
> Add procmail and the patchutils program "grepdiff" to the recipe and I
> think we have a winner.....
I suspect you want to look at all the files in the cset. I think what
you want is a script which is given a list of files and sends a patch
for each new changeset which touches any of those files. Because if
a changeset touched drivers/ieee1394/ and include/something then you
probably want both.
bk help triggers.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
^ permalink raw reply
* Re: Intel sez: Synchronous Flash and XIP is the future -- thoughts?
From: Wolfgang Denk @ 2002-12-16 17:43 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: David Woodhouse, Paul Nash, Linux-MTD (E-mail)
In-Reply-To: <Pine.LNX.4.44.0212161215550.25780-100000@xanadu.home>
In message <Pine.LNX.4.44.0212161215550.25780-100000@xanadu.home> you wrote:
>
> Fortunately on ARM the kernel seems to be sane with .text and .rodata
> actually being read-only.
Well, on PowerPC the .text and .rodata is read-only, too (normally) -
but only after the patching took place :-(
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
Computers are not intelligent. They only think they are.
^ permalink raw reply
* Re: Notification hooks
From: Dave Jones @ 2002-12-16 17:19 UTC (permalink / raw)
To: Ben Collins; +Cc: Linus Torvalds, linux-kernel, Larry McVoy
In-Reply-To: <20021216171218.GV504@hopper.phunnypharm.org>
On Mon, Dec 16, 2002 at 12:12:18PM -0500, Ben Collins wrote:
> Linus, is there anyway I can request a hook so that anything that
> changes drivers/ieee1394/ in your repo sends me an email with the diff
> for just the files in that directory, and the changeset log? Is this
> something that bkbits can do?
>
> I'd bet lots of ppl would like similar hooks for their portions of the
> source.
It'd be nice if the bkbits webpage had a "notify me" interface for files
in Linus' repository. This way not just the maintainers, but folks
interested in changes in that area can also see the changes.
As well as opening this up for more people, it'd also take the load
of Linus having to do it.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* [parisc-linux] YA pb with PCI IDE (my merge 2.4.21-pre1)
From: jsoe0708 @ 2002-12-16 17:06 UTC (permalink / raw)
To: Alan Cox; +Cc: parisc-linux
[-- Attachment #1: Type: text/plain, Size: 4441 bytes --]
Hi Alan,
Worried about ext3 pb, I try to merge parisc kernel 2.4.20-pa14 with 2.4.21-pre1.
This merge seems to works fine on a b180l+ (without pci devices).
But still boot twice (??) and crash on a b2k with an ide cdrom.
So with k-2.4.20-pa14 here is the ide cdrom identification:
...
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
NS87415: IDE controller on PCI bus 00 dev 70
NS87415: chipset revision 3
NS87415: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x0900-0x0907, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0x0908-0x090f, BIOS settings: hdc:pio, hdd:pio
hda: LTN485S, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 103
hda: ATAPI 48X CD-ROM drive, 120kB Cache
Uniform CD-ROM driver Revision: 3.12
...
And now with k-2.4.21-pre1-pa-alpha:
Linux version 2.4.21-pre1-pa14 (root@palx2000) (gcc version 3.0.4) #1 Mon
Dec 16 15:05:24 CET 2002
FP[0] enabled: Rev 1 Model 16
The 32-bit Kernel has started...
...
Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
NS87415: IDE controller at PCI slot 00:0e.0
NS87415: chipset revision 3
NS87415: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x0900-0x0907, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0x0908-0x090f, BIOS settings: hdc:pio, hdd:pio
Linux version 2.4.21-pre1-pa14 (root@palx2000) (gcc version 3.0.4) #1 Mon
Dec 16 15:05:24 CET 2002
FP[0] enabled: Rev 1 Model 16
The 32-bit Kernel has started...
Determining PDC firmware type: System Map.
model 00005d00 00000481 00000000 00000002 77e93910 100000f0 00000008 000000b2
...
Just have to explain that after previous 'hdc:pio, hdd:pio' it wait less
than a second then reboot and finaly crash as follow:
...
Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
NS87415: IDE controller at PCI slot 00:0e.0
NS87415: chipset revision 3
NS87415: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x0900-0x0907, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0x0908-0x090f, BIOS settings: hdc:pio, hdd:pio
Stack Dump:
1008c800: 04100800 1021e454 1008c780 00061a80
1008c7f0: 000000df 1033a010 00000000 00c80000
1008c7e0: 000000a0 000f4240 17d78400 00000003
1008c7d0: 891511dd 00022520 f0000174 f000017c
1008c7c0: 1036e468 f0400004 00000000 ffffffff
1008c7b0: 00000000 102159fc 1034a810 1034a810
Kernel addresses on the stack:
[<1021e454>] [<102159fc>] [<102141d0>] [<102141e4>]
[<101053a4>] [<10214acc>] [<10213a1c>] [<1021560c>]
[<101003d4>] [<10108c4c>] [<10108cf4>] [<10163f64>]
[<1011dbf4>] [<10164528>] [<1011df6c>] [<101647bc>]
[<101003c4>] [<1011de40>] [<10121714>]
High Priority Machine Check (HPMC): Code=1 regs=1033d080 (Addr=00000000)
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111110100001101 Not tainted
r00-03 00000000 1034a010 10110848 000000ff
r04-07 1036e468 1036e3e0 103555c0 000000ec
r08-11 0000000f 1034a810 1034a810 1034d810
r12-15 00000000 ffffffff 00000000 f0400004
r16-19 f00008c4 f000017c f0000174 fee00000
r20-23 0000000f 100b4160 10111bd0 000f4240
r24-27 00000e06 fee00e06 100b4160 1033a010
r28-31 000000df 00061a80 1008c800 10110848
sr0-3 00000000 00000000 00000000 00000000
sr4-7 00000000 00000000 00000000 00000000
IASQ: 00000000 00000000 IAOQ: 10111be0 10111be4
IIR: 0f20001c ISR: a607fffb IOR: 80200e06
CPU: 0 CR30: 1008c000 CR31: 103f0000
ORIG_R28: 00000000
Well, I can try with this dump to use Thibaut 'dump_analyser.sh' but I doubt
to obtain relevant info because of the two successive kernel launch?
May be can you advise me on a start point of investigation: it is the first
time I met this kind of two successive boot?
Thanks in advance for your attention,
Joel
PS1: I join a full log including a normal 2.4.20-pa14 boot, the abnormal
2.4.21-pr1 crash and finaly the pim info.
PS2: it is a 32bits kernel build on a 'unstable' debian distro updated this
morning with gcc-3.0.4
********************************************************************************
Controlez mieux votre consommation Internet...surfez Tiscali Complete...http://tiscali.complete.be
[-- Attachment #2: B2kBoot.doc --]
[-- Type: application/msword, Size: 28514 bytes --]
^ permalink raw reply
* Re: 2.5.52 and modules (lots of unresolved symbols)?
From: Gregoire Favre @ 2002-12-16 17:17 UTC (permalink / raw)
To: Alex Goddard; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.50L0.0212161114360.1154-100000@dust.ebiz-gw.wintek.com>
On Mon, Dec 16, 2002 at 11:19:00AM +0000, Alex Goddard wrote:
> > I have just patched 2.5.51, and not done the make clean && make mrproper
> > before doing a make menuconfig && make dep && make bzImage && make
> > modules...
> >
> > Will that change anything to make clean/mrproper here?
>
> I would give 'make clean' a try.
I am just doing that right now... I'll wait till completion to report
the issue:
No change, still the same messages :-(
Thank you very much and have a great day,
Grégoire
________________________________________________________________
http://ulima.unil.ch/greg ICQ:16624071 mailto:greg@ulima.unil.ch
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.