Hi everybody,
I have several questions about ioremap:
1) I have two 16 bit sram memory devices. To force it works I had to use
ioremap with memorysize*2, because
I was able to write to the 1 and 2 byte, 5,6, 9,10, 13,14 and so on.
Please explain why my ioremap space is non-continous,
how to
This patch shuts up some more incorrect gcc warnings.
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
diff -urN linux-2.5/arch/ppc/xmon/xmon.c testpmac/arch/ppc/xmon/xmon.c
--- linux-2.5/arch/ppc/xmon/xmon.c 2004-10-21 07:17:18.0 +1000
+++ testpmac/arch/ppc/xmon/xmon.c
On Mar 31, 2005 12:29 AM, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Your "cleanup lock usage" increases the number of lock_kernel() calls
> quite a bit, which is not really a cleanup but simply bloat.
Yes, just looking at the patch, seem to indicate so. But let's take a
closer look at the original
At what point are you seeing these delays? During early boot or after
boot?
It can be SMI happening in the platform. Typically BIOS uses some SMI
polling
to handle some devices during early boot. Though 500 microseconds sounds
a
bit too high.
Thanks,
Venki
>-Original Message-
>From:
Jon Smirl <[EMAIL PROTECTED]> wrote:
>
> This will let me boot again. It is not obvious to me where the problem
> is, it may have something to do with netlink or maybe memory
> corruption?
>
> bk export -tpatch -r1.2326,1.2327 >../foo.patch
> patch -p1 -R <../foo.patch
>
> # ChangeSet
> #
This will let me boot again. It is not obvious to me where the problem
is, it may have something to do with netlink or maybe memory
corruption?
bk export -tpatch -r1.2326,1.2327 >../foo.patch
patch -p1 -R <../foo.patch
# ChangeSet
# 2005/03/31 21:14:28-08:00 [EMAIL PROTECTED]
# Merge
On Sat, Apr 02, 2005 at 09:37:07AM +1000, Neil Brown wrote:
> On Friday April 1, [EMAIL PROTECTED] wrote:
> > I had created a new raid1 array and started moving a volume group to it at
> > the
> > same time while it was reconstructing. Got this oops after several hours,
>
> The subject says 'md
Herzlichen Glückwünsch.
Sie sind einer der glücklichen Menschen denen wir folgendes Super-Angebot
unterbreiten können:
Spielen Sie mit beim Casino Royal Las Vegas und freuen Sie sich auf bis zu
500 $ Extra
beim ersten Kauf von Chips!!
Ja Sie lesen richtig - bei Ihrem ersten Chipkauf geben wir
This patch had fixed the following warning about audit_arch().
ptrace.o
arch/mips/kernel/ptrace.c:305: warning: function declaration isn't a prototype
Yoichi
Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
diff -urN -X dontdiff rc1-mm4-orig/arch/mips/kernel/ptrace.c
* Gene Heskett <[EMAIL PROTECTED]> wrote:
> Apr 1 18:05:20 coyote ieee1394.agent[6016]: ... no drivers for IEEE1394
> product 0x/0x/0x
> Apr 1 18:05:24 coyote kernel:
> Apr 1 18:05:24 coyote kernel: ==
> Apr 1 18:05:24 coyote kernel: [ BUG: lock
This patch shuts up a couple of gcc "variable may be used
uninitialized" warnings. The warnings are invalid - the code is such
that the variables are in fact initialized before being used - but gcc
isn't smart enough to see that. This patch eliminates the warnings.
Signed-off-by: Paul Mackerras
Paul Jackson wrote:
The x86_64 memset(), both in user space and the kernel, for whatever gcc
I have, and for a current kernel, uses the "repz stos" or "rep stosq"
prefixed instruction for the bulk of the copy. This combination is a
long running, interruptible Intel string instruction that loops
**
linux-kernel@vger.kernel.org
**
Canadian Business Publications is pleased
to announce the introduction of the
Canadian Business Database
a high-performance database application
containing more than 900,000 Canadian
businesses on cd-rom.
The Canadian
With Grant's help I was able to get the tulip driver to work with 64 bit
MIPS.
Again Thanx Grant. Attached is the patch I used.
diff -Naur linux-2.6.11.6/drivers/net/tulip/eeprom.c linux-2.6.11.6/drivers/net/tulip/eeprom.c
--- linux-2.6.11.6/drivers/net/tulip/eeprom.c 2005-03-25 19:28:37 -0800
Siddha, Suresh B wrote:
On Sat, Apr 02, 2005 at 01:11:20PM +1000, Nick Piggin wrote:
How important is this? Any application to real workloads? Even if
not, I agree it would be nice to improve this more. I don't know
if I really like this approach - I guess due to what it adds to
fastpaths.
Ken
The LaCie Silverscreen external hard drive / media player contains a
~4 MByte ROMFS image that has a gzipped Linux kernel, Busybox, and a
few other assorted things. However, LaCie makes no mention of using
GPLed software, nor do they offer any source code for download. Has
anyone ever noticed
Robert wrote:
> It does run visibly slower
The x86_64 memset(), both in user space and the kernel, for whatever gcc
I have, and for a current kernel, uses the "repz stos" or "rep stosq"
prefixed instruction for the bulk of the copy. This combination is a
long running, interruptible Intel string
On Sat, Apr 02, 2005 at 01:11:20PM +1000, Nick Piggin wrote:
> How important is this? Any application to real workloads? Even if
> not, I agree it would be nice to improve this more. I don't know
> if I really like this approach - I guess due to what it adds to
> fastpaths.
Ken initially observed
On Sat, Apr 02, 2005 at 04:53:30AM +0100, Matthew Wilcox wrote:
>
> So yes, please revert this patch. There is no way it can possibly
> affect anything.
Agreed. It's now reverted and is queued for Linus to pull from.
Thanks for reviewing this.
greg k-h
-
To unsubscribe from this list: send
Siddha, Suresh B wrote:
On Sat, Apr 02, 2005 at 12:07:27PM +1000, Nick Piggin wrote:
I was thinking we could fix that by running balance on fork/exec multiple
times from top to bottom level domains. I'll have to measure the cost of
doing that, because it may be worthwhile.
Agreed.
BTW, why are we
On Fri, Apr 01, 2005 at 07:31:41PM -0800, Greg KH wrote:
> I agree. However, SGI seems to have some majorly
> hardware and drivers that cause this line to release a already released
> resource. See the other part of this patch for the part where this
> resource is supposedly freed up.
That
Hi Dmitry and others,
At 06:41 a.m. 31/03/2005, Dmitry Torokhov wrote:
On Monday 28 March 2005 06:02, Russell King wrote:
> Looks like something in the input layer went bang. The code in
> serport_ldisc_write_wakeup is:
>
>0: 8b 80 a8 09 00 00 mov0x9a8(%eax),%eax
>6: 8b 40
On Sat, Apr 02, 2005 at 02:10:23AM +0100, Matthew Wilcox wrote:
> On Fri, Apr 01, 2005 at 03:47:50PM -0800, Greg KH wrote:
> > PCI: fix an oops in some pci devices on hotplug remove when their resources
> > are being freed.
> >
> > As reported by Prarit Bhargava <[EMAIL PROTECTED]>
> >
On Sat, Apr 02, 2005 at 12:07:27PM +1000, Nick Piggin wrote:
> Siddha, Suresh B wrote:
> > Appended patch removes the unnecessary scheduler domains(containing
> > only one sched group) setup during the sched-domain init.
> >
> > For example on x86_64, we always have NUMA configured in. On Intel
Haven't finished (hardly started) the arch code for this yet (and probably
broke ppc64), so it is just an RFC at this stage.
The large CC list is because it is a reasonably big change, so I hope one
or two of you smart guys can see if it looks sound before I try to tackle
the rest of the arch code
This is what I see on boot.
--
Jon Smirl
[EMAIL PROTECTED]
Linux version 2.6.12-rc1 ([EMAIL PROTECTED]) (gcc version
3.4.2 200410
17 (Red Hat 3.4.2-6.fc3)) #21 SMP Fri Apr 1 22:09:28 EST 2005
BIOS-provided physical RAM map:
BIOS-e820: -
This went to linux-arch, but didn't get much response. Dave Miller
thought it looked fine, although I guess this was probably "in
concept" rather than a detailed review.
Andrew, would you care to put it in -mm, or would you rather we get
through the current scheduler patches first? (Note that this
Siddha, Suresh B wrote:
This time Ken Chen brought up this issue -- No it has nothing to do with
industry db benchmark ;-)
Even with the above mentioned Nick's patch in -mm, I see system livelock's
if for example I have 7000 processes pinned onto one cpu (this is on the
fastest 8-way system I
On Wednesday, February 23, 2005 11:17 PM Nick Piggin wrote:
>John Hawkes explained the problem best:
> A large number of processes that are pinned to a single CPU results
> in every other CPU's load_balance() seeing this overloaded CPU as
> "busiest", yet move_tasks() never finds a task to
Kenneth wrote:
> I recommend buying the following:
ah so ... I think I'll skip running the industry db benchmark
for now, if that's all the same.
What sort of feedback are you looking for from my running this
patch?
--
I won't rest till it's the best ...
Ray Lee wrote:
On Thu, 2005-03-31 at 22:37 -0600, Robert Hancock wrote:
This is getting pretty ridiculous.. I've tried memory timings down to
the slowest possible, ran Memtest86 for 4 passes with no errors, and
it's been stable in Windows for a few months now. Still something is
blowing up in
On Apr 1, 2005 7:17 AM, K.R. Foley <[EMAIL PROTECTED]> wrote:
> I have an old Dell Precision 620 workstation with dual PIII 933's and
> 512 Mb memory. It also uses AIC-7899P U160/m SCSI controllers with one
> U160 drive (boot drive) and one slower 18 Gb. I have been running many
> different
On Friday 01 April 2005 20:45, Lee Revell wrote:
>On Fri, 2005-04-01 at 18:34 -0500, Gene Heskett wrote:
>> No one has commented about the loss of video in the
>> tvtime/pcHDTV-3000 card situation, am I on my own, basicly
>> reverting to the
>> pcHDTV-2.0.tar.gz stuff to overwrite the kernel
Linus Torvalds wrote:
On Fri, 1 Apr 2005, Chen, Kenneth W wrote:
Paul, you definitely want to check this out on your large numa box. I booted
a kernel with this patch on a 32-way numa box and it took a long time
to produce the cost matrix.
Is there anything fundamentally wrong with the
When I boot the kernel is mistaking my initrd as an initramfs. Of
course this doesn't work. This broke in the last 24hrs on the linus bk
tree. I am using an up2date Fedora Core 3. Booting older kernels still
works.
--
Jon Smirl
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line
> On Tue, Mar 29, 2005 at 11:00:30AM -0800, David Schwartz wrote:
> > Since the GPL permits their removal, removing them cannot
> > be circumventing
> > the GPL. Since the GPL is the only license and the license
> > permits you to
> > remove them, they cannot be a license enforcement mechanism.
Chen, Kenneth W wrote:
Ingo Molnar wrote on Thursday, March 31, 2005 8:52 PM
the current defaults for cache_hot_time are 10 msec for NUMA domains,
and 2.5 msec for SMP domains. Clearly too low for CPUs with 9MB cache.
Are you increasing cache_hot_time in your experiment? If that solves
most of the
Paul Jackson wrote on Friday, April 01, 2005 5:45 PM
> Kenneth wrote:
> > Paul, you definitely want to check this out on your large numa box.
>
> Interesting - thanks. I can get a kernel patched and booted on a big
> box easily enough. I don't know how to run an "industry db benchmark",
> and
Siddha, Suresh B wrote:
Appended patch removes the unnecessary scheduler domains(containing
only one sched group) setup during the sched-domain init.
For example on x86_64, we always have NUMA configured in. On Intel EM64T
systems, top most sched domain will be of NUMA and with only one
On Wed, Mar 30, 2005 at 02:29:45PM -0800, Noah Silverman wrote:
> On Wed, 30 Mar 2005, Noah Silverman wrote:
> > I'm been experiencing a weird problem
> >
> > I get endlessly repeated hangcheck errors in my syslog with no
> explanation:
> >
> > Mar 30 12:41:43 db kernel: Hangcheck: hangcheck
On Fri, 2005-04-01 at 18:34 -0500, Gene Heskett wrote:
> No one has commented about the loss of video in the tvtime/pcHDTV-3000
> card situation, am I on my own, basicly reverting to the
> pcHDTV-2.0.tar.gz stuff to overwrite the kernel stuff?
You didn't really give much of a clue as to where
Kenneth wrote:
> Paul, you definitely want to check this out on your large numa box.
Interesting - thanks. I can get a kernel patched and booted on a big
box easily enough. I don't know how to run an "industry db benchmark",
and benchmarks aren't my forte.
Should I rope in one of our guys who
On Fri, 2005-04-01 at 17:27, Andrew Morton wrote:
> Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > > --- linux-2.6.11.orig/fs/direct-io.c2005-04-01 15:33:11.0
> > -0800
> > > +++ linux-2.6.11/fs/direct-io.c 2005-03-31 16:59:15.0 -0800
> > > @@ -66,6 +66,7 @@ struct dio
This patch changes all cases where the MS_ACTIVE bit gets set. This is
done to eliminate a race condition that can occur if an inode is
allocated and then released (using iput) during the ->fill_super
functions. The race condition is between kswapd and mount.
For most filesystems this can only
Well, not actually a time warp, though it feels like one.
I'm doing some real-time bit-twiddling in a driver, using the TSC to
measure out delays on the order of hundreds of nanoseconds. Because I
want an upper limit on the delay, I disable interrupts around it.
The logic is something like:
On Fri, 2005-04-01 at 17:20, Andrew Morton wrote:
> Daniel McNeil <[EMAIL PROTECTED]> wrote:
> >
> > I updated the patch to add an i_size element to the dio structure and
> > sample i_size during i/o submission. When i/o completes the result can
> > be truncated to match the file size without
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > --- linux-2.6.11.orig/fs/direct-io.c 2005-04-01 15:33:11.0
> -0800
> > +++ linux-2.6.11/fs/direct-io.c 2005-03-31 16:59:15.0 -0800
> > @@ -66,6 +66,7 @@ struct dio {
> >struct bio *bio;/* bio under
Daniel McNeil <[EMAIL PROTECTED]> wrote:
>
> I updated the patch to add an i_size element to the dio structure and
> sample i_size during i/o submission. When i/o completes the result can
> be truncated to match the file size without using i_size_read(), thus
> the aio result now matches the
On Fri, 2005-03-25 at 06:59, Badari Pulavarty wrote:
> Andrew,
>
> When I debugged the problem, the issue seems to be only for the last
> block of the file. Filesize is not multiple of 4K blocks. (say 17K).
> So, on the disk we have a 4K block for the last block. The test is
> trying to read
On Fri, Apr 01, 2005 at 03:47:50PM -0800, Greg KH wrote:
> PCI: fix an oops in some pci devices on hotplug remove when their resources
> are being freed.
>
> As reported by Prarit Bhargava <[EMAIL PROTECTED]>
> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
>
> diff -Nru
Ingo Molnar wrote on Thursday, March 31, 2005 8:52 PM
> the current defaults for cache_hot_time are 10 msec for NUMA domains,
> and 2.5 msec for SMP domains. Clearly too low for CPUs with 9MB cache.
> Are you increasing cache_hot_time in your experiment? If that solves
> most of the problem that
ChangeSet 1.2181.16.11, 2005/03/17 14:31:08-08:00, [EMAIL PROTECTED]
[PATCH] PCI: 80 column lines
PCI 80-column lines
A couple of lines are >80 columns
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/pci/quirks.c |4 ++--
1
ChangeSet 1.2181.16.16, 2005/03/17 14:50:04-08:00, [EMAIL PROTECTED]
[PATCH] arch/i386/pci/i386.c: Use new for_each_pci_dev macro
From: Domen Puncer <[EMAIL PROTECTED]>
As requested by Christoph Hellwig I created a new macro called
for_each_pci_dev. It is a wrapper for this common use of
ChangeSet 1.2181.16.15, 2005/03/17 14:49:28-08:00, [EMAIL PROTECTED]
[PATCH] sort-out-pci_rom_address_enable-vs-ioresource_rom_enable.patch
From: Jon Smirl <[EMAIL PROTECTED]>
This sorts out the usage of PCI_ROM_ADDRESS_ENABLE vs
IORESOURCE_ROM_ENABLE. PCI_ROM_ADDRESS_ENABLE is for actually
ChangeSet 1.2181.16.7, 2005/03/17 10:30:46-08:00, [EMAIL PROTECTED]
PCI: fix an oops in some pci devices on hotplug remove when their resources are
being freed.
As reported by Prarit Bhargava <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/pci/remove.c |
ChangeSet 1.2181.16.9, 2005/03/17 13:54:33-08:00, [EMAIL PROTECTED]
[PATCH] PCI Hotplug: remove code duplication in drivers/pci/hotplug/ibmphp_pci.c
This patch removes some code duplication where if and else have the
same code at the beginning and the end of the branch.
Signed-off-by: Rolf Eike
ChangeSet 1.2181.16.8, 2005/03/17 13:50:00-08:00, [EMAIL PROTECTED]
[PATCH] PCI: trivial DBG tidy-up
Tidy-up a bunch of PCI DBG output to use pci_name() when possible,
add domain when appropriate, remove redundancy, settle on one
style (DBG vs DBGC), etc.
Signed-off-by: Bjorn Helgaas <[EMAIL
On Sat, Apr 02, 2005 at 03:46:53AM +0400, Michael Tokarev wrote:
> Matt Mackall wrote:
> >This shuts up a potential uninitialized variable warning.
>
> Potential warning or potential uninitialized use?
> The code was right before the change, and if the compiler
> generates such a warning on it,
ChangeSet 1.2181.16.10, 2005/03/17 13:54:51-08:00, [EMAIL PROTECTED]
[PATCH] PCI Hotplug: only call ibmphp_remove_resource() if argument is not NULL
If we call ibmphp_remove_resource() with a NULL argument it will write
a warning. We can avoid this here because we already look if the argument
ChangeSet 1.2181.16.19, 2005/03/28 15:09:51-08:00, [EMAIL PROTECTED]
[PATCH] PCI: Quirk for Asus M5N
One more Asus laptop which requires a PCI quirk to unhide the SMBus.
Contributed by Matthias Hensler through bugzilla (#4391).
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Signed-off-by: Greg
ChangeSet 1.2181.16.23, 2005/03/28 15:19:00-08:00, [EMAIL PROTECTED]
[PATCH] PCI: remove pci_find_device usage from pci sysfs code.
Greg KH wrote:
> On Sun, Mar 20, 2005 at 03:53:58PM +0100, Rolf Eike Beer wrote:
> > Greg KH wrote:
> > > ChangeSet 1.1998.11.23, 2005/02/25 08:26:11-08:00, [EMAIL
I woke up to a mostly-dead PE1850 this morning:
Message from [EMAIL PROTECTED] at Fri Apr 1 06:19:14 2005 ...
storage kernel: Assertion failure in log_do_checkpoint() at
fs/jbd/checkpoint.c:365: "drop_count != 0 || cleanup_ret != 0"
Message from [EMAIL PROTECTED] at Fri Apr 1 06:19:14 2005
ChangeSet 1.2181.16.3, 2005/03/16 23:56:39-08:00, [EMAIL PROTECTED]
PCI: add CONFIG_PCI_NAMES to the feature-removal-schedule.txt file
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
Documentation/feature-removal-schedule.txt |9 +
1 files changed, 9 insertions(+)
diff
Appended patch removes the unnecessary scheduler domains(containing
only one sched group) setup during the sched-domain init.
For example on x86_64, we always have NUMA configured in. On Intel EM64T
systems, top most sched domain will be of NUMA and with only one sched_group in
it.
With
Ingo Molnar wrote:
* Frank Rowand <[EMAIL PROTECTED]> wrote:
< more stuff deleted >
I'm working on the architecture support for realtime on PPC64 now. If
the lock field of struct raw_rwlock_t is a long instead of int then
/proc/meminfo shows MemFree decreasing from 485608 kB to 485352 kB.
Do
ChangeSet 1.2181.16.22, 2005/03/28 15:10:57-08:00, [EMAIL PROTECTED]
[PATCH] PCI: handle multiple video cards on the same bus
From: Jon Smirl <[EMAIL PROTECTED]>
When detecting the boot video device, allow for the case of multiple
cards on the same bus. Check each candidate to make sure that
ChangeSet 1.2181.16.26, 2005/03/28 22:29:40-08:00, [EMAIL PROTECTED]
[PATCH] PCI: create PCI_DEBUG config option to make it easier for users to
enable pci debugging
Now you don't have to dig through a file to change a #define, it's a real
config option.
Signed-off-by: Greg Kroah-Hartman
On Thu, 2005-03-31 at 14:03 -0800, Rajesh Shah wrote:
> Does this patch help?
YES! I can now power down the slot, see it gone from pci list, reenable
it, etc. Awesome. Thank you.
[EMAIL PROTECTED] ~]# lspci -s 08:00
08:00.0 Ethernet controller: Intel Corp.: Unknown device 105f (rev 03)
Andrea,
I just successfully tested the patch on my environment. It actually
resolved OOM-killer problem for my iscsid.
Important note: daemon's parent must be init.
In my test, OOM-killer killed everything around but iscsid, and iscsid
successfully finished registration of new SCSI host in the
ChangeSet 1.2181.16.14, 2005/03/17 14:32:07-08:00, [EMAIL PROTECTED]
[PATCH] pci_ids.h correction for Intel ICH7M
This patch corrects the ICH7M LPC controller DID in pci_ids.h from x27B1
to x27B9.
Signed-off-by: Jason Gaston <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL
Grecko OSCP wrote on Friday, April 01, 2005 10:22 AM
> I noticed yesterday a news article on Linux.org about more kernel
> performance testing being called for, and I decided it would be a nice
> project to try. I have 10 completely identical systems that can be
> used for this, and would like to
ChangeSet 1.2181.16.6, 2005/03/17 10:23:26-08:00, [EMAIL PROTECTED]
[PATCH] PCI: Patch for Serverworks chips in hotplug environment
From: Kimball Murray <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/ide/pci/serverworks.c |8
ChangeSet 1.2181.16.21, 2005/03/28 15:10:34-08:00, [EMAIL PROTECTED]
[PATCH] PCI: shrink drivers/pci/proc.c::pci_seq_start()
this patch shrinks pci_seq_start by using for_each_pci_dev() macro instead
of explicitely using a loop and avoiding a goto.
Signed-off-by: Rolf Eike Beer <[EMAIL
ChangeSet 1.2181.16.1, 2005/03/16 23:55:56-08:00, [EMAIL PROTECTED]
PCI: increase the size of the pci.ids strings
If we are going to waste memory, might as well do it right...
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/pci/gen-devlist.c |2 +-
include/linux/pci.h
ChangeSet 1.2181.16.2, 2005/03/16 23:56:17-08:00, [EMAIL PROTECTED]
Remove item from feature-removal-schedule.txt that was already removed from the
kernel.
my mistake...
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
Documentation/feature-removal-schedule.txt | 15 ---
ChangeSet 1.2181.16.12, 2005/03/17 14:31:26-08:00, [EMAIL PROTECTED]
[PATCH] [PATCH] remove redundant devices list
The RPA PCI Hotplug module creates and maintains a list of devices for
each slot. This is redundant, because the PCI structures already
maintain such a list. This patch changes
ChangeSet 1.2181.16.18, 2005/03/28 15:09:31-08:00, [EMAIL PROTECTED]
[PATCH] PCI Hotplug: add documentation about release pointer.
Adds "release" func pointer comments to nano-doc.
Signed-off-by: Prarit Bhargava <[EMAIL PROTECTED]>
Index: hp/drivers/pci/hotplug/pci_hotplug.h
ChangeSet 1.2181.16.5, 2005/03/17 10:11:55-08:00, [EMAIL PROTECTED]
[PATCH] PCI: Add PCI device ID for new Mellanox HCA
Add PCI device IDs for new Mellanox "Sinai" InfiniHost III Lx HCA.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
ChangeSet 1.2181.16.24, 2005/03/28 15:20:34-08:00, [EMAIL PROTECTED]
[PATCH] drivers/pci/msi.c: fix a check after use
This patch fixes a check after use found by the Coverity checker.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
ChangeSet 1.2181.16.13, 2005/03/17 14:31:48-08:00, [EMAIL PROTECTED]
[PATCH] PCI busses are structs, not integers
PCI busses are structs, not integers. Fix pcibus_to_cpumask to take
a struct. NB changing it from a macro to an inline function would
require serious include file surgery.
ChangeSet 1.2181.16.17, 2005/03/21 22:55:26-08:00, [EMAIL PROTECTED]
PCI Hotplug: enforce the rule that a hotplug slot needs a release function.
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/pci/hotplug/pci_hotplug_core.c |5 +
1 files changed, 5 insertions(+)
diff
ChangeSet 1.2181.16.20, 2005/03/28 15:10:15-08:00, [EMAIL PROTECTED]
[PATCH] drivers/pci/hotplug/cpqphp_core.c: fix a check after use
This patch fixes a check after use found by the Coverity checker.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL
ChangeSet 1.2181.16.25, 2005/03/28 22:00:24-08:00, [EMAIL PROTECTED]
PCI: clean up the dynamic id logic a little bit.
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/pci/pci-driver.c | 11 ++-
1 files changed, 2 insertions(+), 9 deletions(-)
diff -Nru
Matt Mackall wrote:
This shuts up a potential uninitialized variable warning.
Potential warning or potential uninitialized use?
The code was right before the change, and if the compiler
generates such a warning on it, it's the compiler who
should be fixed, not the code: it's obvious the variable
Hi,
Here are some PCI and PCI Hotplug patches for 2.6.11. All of these have
been in the past few -mm releases.
This includes an even bigger pci.ids update, as now we should be
completly synced up with the main sf.net database. I've also marked
this feature as "will be deleted soon" as it's a
This patch makes two needlessly global functions static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/serial/jsm/jsm.h |1 -
drivers/serial/jsm/jsm_neo.c |2 +-
drivers/serial/jsm/jsm_tty.c |4 +++-
3 files changed, 4 insertions(+), 3 deletions(-)
---
On Friday April 1, [EMAIL PROTECTED] wrote:
> I had created a new raid1 array and started moving a volume group to it at the
> same time while it was reconstructing. Got this oops after several hours,
The subject says 'md array' but the Opps seems to say 'dm raid1
array'.
Could you please
On Friday 01 April 2005 14:22, K.R. Foley wrote:
>Gene Heskett wrote:
>> On Friday 01 April 2005 13:27, K.R. Foley wrote:
>>>Gene Heskett wrote:
>>>
>>>
It was up to 43-04 by the time I got there.
This one didn't go in cleanly Ingo. From my build-src scripts
output:
I'm testing a system based on a ATI Radeon Xpress 200 motherboard.
(host bridge PCI device 1002:5950)
Something is causing the timer interrupt to be received twice as often as
desired; this makes the clock run at double normal speed.
I first noticed the problem when testing Red Hat 2.4 and 2.6
Greetings, James. :-)
On Fri, Apr 01, 2005 at 12:23:37PM -0600, James Bottomley wrote:
> On Thu, 2005-03-31 at 18:08 +0900, Tejun Heo wrote:
> > When scsi_init_io() returns BLKPREP_DEFER or BLKPREP_KILL,
> > it's supposed to free resources itself. This patch
> > consolidates defer
Linus Torvalds wrote on Tuesday, March 29, 2005 4:00 PM
> Also, it would be absolutely wonderful to see a finer granularity (which
> would likely also answer the stability question of the numbers). If you
> can do this with the daily snapshots, that would be great. If it's not
> easily
On Fri, 1 Apr 2005, Chen, Kenneth W wrote:
>
> Paul, you definitely want to check this out on your large numa box. I booted
> a kernel with this patch on a 32-way numa box and it took a long time
> to produce the cost matrix.
Is there anything fundamentally wrong with the notion of just
Roland McGrath <[EMAIL PROTECTED]> wrote:
>
> It comes up as useful in debugging to be able to see task->thread_info->flags
> along with signal information and such. There is no way currently to
> elicit these bits from the kernel via sysrq or /proc (AFAIK).
> This patch adds the field to
It comes up as useful in debugging to be able to see task->thread_info->flags
along with signal information and such. There is no way currently to
elicit these bits from the kernel via sysrq or /proc (AFAIK).
This patch adds the field to /proc/PID/status.
Thanks,
Roland
Signed-off-by: Roland
Ingo Molnar wrote on Thursday, March 31, 2005 10:46 PM
> before we get into complexities, i'd like to see whether it solves Ken's
> performance problem. The attached patch (against BK-curr, but should
> apply to vanilla 2.6.12-rc1 too) adds the autodetection feature. (For
> ia64 i've hacked in a
Hello,
some private discussion (that was continuing some kernel-summit-discuss
thread) ended in the below patch. I also liked a textual "disable"
instead of value "-17" (internally to the kernel it could be represented
the same way, but the /proc parsing would be more complicated). If you
prefer
Greetings, James.
On Fri, Apr 01, 2005 at 12:09:48PM -0600, James Bottomley wrote:
> On Fri, 2005-04-01 at 14:01 +0900, Tejun Heo wrote:
> > > Well, REQ_SPECIAL is the signal to the mid-layer that we've allocated
> > > the resources necessary to process the command, so in practice it will
> > >
On Fri, Apr 01, 2005 at 04:41:44PM +0100, Artem B. Bityuckiy wrote:
>
> Suppose we compress 1 GiB of input, and have a 70K output buffer. We
The question is what happens when you compress 1 1GiB input buffer into
a 1GiB output buffer.
> Surely I'll check. I'll even test the new implementation
On Fri, 1 Apr 2005, Steven Rostedt wrote:
On Fri, 2005-04-01 at 16:18 -0500, Steven Rostedt wrote:
On Fri, 2005-04-01 at 12:46 -0800, Matt Mackall wrote:
On Fri, Apr 01, 2005 at 12:26:41PM -0800, Andrew Morton wrote:
Matt Mackall <[EMAIL PROTECTED]> wrote:
This patch tidies up those annoying
On Fri, Apr 01, 2005 at 12:23:25PM -0800, Jim Gifford wrote:
> Grant,
>Thank you, I took your driver as a reference and added in the cobalt
> specifics to the eeprom.c file, works perfectly now.
Cool! very welcome.
Can you do me a favor and submit a diff of all the tulip changes
you have at
1 - 100 of 631 matches
Mail list logo
