* Re: 2.6.16-ck3
From: Con Kolivas @ 2006-04-02 8:51 UTC (permalink / raw)
To: Nick Piggin; +Cc: ck list, linux list, Andrew Morton
In-Reply-To: <442F5721.2040906@yahoo.com.au>
On Sunday 02 April 2006 14:46, Nick Piggin wrote:
> The swap prefetching here, and the one in -mm AFAIKS still do not follow
> the lowmem reserve ratio correctly. This might explain why prefetching
> appears to help some people after updatedb swaps stuff out to make room
> for pagecache -- it may actually be dipping into lower zones when it
> shouldn't.
Curious. I was under the impression lowmem reserve only did anything if you
manually set it, and the users reporting on swap prefetch behaviour are not
the sort of users likely to do so. I'm happy to fix whatever the lowmem
reserve bug is but I doubt this bug is making swap prefetch behave better for
ordinary users. Well, whatever the case is I'll have another look at lowmem
reserve of course.
Cheers,
Con
^ permalink raw reply
* [RFC] install_session_keyring
From: Suzanne Wood @ 2006-04-02 8:50 UTC (permalink / raw)
To: dhowells; +Cc: linux-kernel, paulmck
Hello,
In a study of the control flow graph dumps to check that
an rcu_assign_pointer() with a given argument type has
preceded a call to rcu_dereference(), I've come across
install_session_keyring() of security/keys/process_keys.c.
We note that although no rcu_read_lock() is in place
locally or in the function's kernel callers, siglock
likely addresses that. While the rcu_dereference() would
indicate a desire for 'old' to persist, synchronize_rcu()
is called prior to key_put(old) which "disposes of
reference to a key." The order of events with a use of
the copy of the pointer following synchronize_rcu() is
what I question.
Thanks.
Suzanne
/******************************************************/
/*
* install a session keyring, discarding the old one
* - if a keyring is not supplied, an empty one is invented
*/
static int install_session_keyring(struct task_struct *tsk,
struct key *keyring)
{
unsigned long flags;
struct key *old;
char buf[20];
int ret;
/* create an empty session keyring */
if (!keyring) {
sprintf(buf, "_ses.%u", tsk->tgid);
keyring = keyring_alloc(buf, tsk->uid, tsk->gid, 1, NULL);
if (IS_ERR(keyring)) {
ret = PTR_ERR(keyring);
goto error;
}
}
else {
atomic_inc(&keyring->usage);
}
/* install the keyring */
spin_lock_irqsave(&tsk->sighand->siglock, flags);
old = rcu_dereference(tsk->signal->session_keyring);
rcu_assign_pointer(tsk->signal->session_keyring, keyring);
spin_unlock_irqrestore(&tsk->sighand->siglock, flags);
ret = 0;
/* we're using RCU on the pointer */
synchronize_rcu();
key_put(old);
error:
return ret;
} /* end install_session_keyring() */
^ permalink raw reply
* [ALSA - driver 0001987]: Upmix Feature Request
From: bugtrack @ 2006-04-02 8:42 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1987>
======================================================================
Reported By: the-me
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 1987
Category: CORE - control
Reproducibility: always
Severity: feature
Priority: normal
Status: feedback
Distribution: Debian
Kernel Version: 2.6.16.1
======================================================================
Date Submitted: 03-31-2006 20:38 CEST
Last Modified: 04-02-2006 10:42 CEST
======================================================================
Summary: Upmix Feature Request
Description:
Hi,
I, and many users more, want a feature at the alsamixer, called Upmix.
I've got an Terratec Aureon 5.1 Fun and I tried many things, but it's not
able, that I can hear an mp3 with upmixed 5.1 sound. Here is my actual
.asoundrc:
pcm.ch51upmix {
type route
slave.pcm surround51
slave.channels 6
ttable.0.0 1
ttable.1.1 1
ttable.0.2 1
ttable.1.3 1
ttable.0.4 0.5
ttable.1.4 0.5
ttable.0.5 0.5
ttable.1.5 0.5
}
pcm.!default
{
type plug
slave.pcm ch51upmix
}
pcm.lowpass {
type ladspa
path "/usr/lib/ladspa"
plugins [ {
label lpf
input {
controls [ 50 ]
}
} ]
}
With this .asoundrc, all speakers work, but my subwoofer doesn't play only
low frequen...
Can you please add such a feature?
Greetz, Patrick
======================================================================
----------------------------------------------------------------------
the-me - 04-01-06 10:39
----------------------------------------------------------------------
Thanks, but there is one problem. I need a lowpass filter for my
subwoofer.
Like here but only on my subwoofer channel =>
http://alsa.opensrc.org/SurroundSound ( ~ in the middle of the document ).
----------------------------------------------------------------------
Raymond - 04-02-06 10:42
----------------------------------------------------------------------
According to
http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html#pcm_plugins_ladpsa
The input and output format is always SND_PCM_FORMAT_FLOAT
Issue History
Date Modified Username Field Change
======================================================================
03-31-06 20:38 the-me New Issue
03-31-06 20:38 the-me Distribution => Debian
03-31-06 20:38 the-me Kernel Version => 2.6.16.1
03-31-06 20:40 the-me Note Added: 0009048
03-31-06 21:02 rlrevell Status new => closed
03-31-06 21:02 rlrevell Note Added: 0009049
03-31-06 21:15 the-me Status closed => feedback
03-31-06 21:15 the-me Resolution open => reopened
03-31-06 21:15 the-me Note Added: 0009050
04-01-06 01:03 Raymond Note Added: 0009052
04-01-06 10:39 the-me Note Added: 0009053
04-02-06 10:42 Raymond Note Added: 0009059
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: 2.6.16-ck3
From: Nick Piggin @ 2006-04-02 4:46 UTC (permalink / raw)
To: Con Kolivas; +Cc: ck list, linux list, Andrew Morton
In-Reply-To: <200604021401.13331.kernel@kolivas.org>
Con Kolivas wrote:
> These are patches designed to improve system responsiveness and interactivity.
> It is configurable to any workload but the default ck patch is aimed at the
> desktop and cks is available with more emphasis on serverspace.
>
> THESE INCLUDE THE PATCHES FROM 2.6.16.1 SO START WITH 2.6.16 AS YOUR BASE
>
> Apply to 2.6.16
> http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.16/2.6.16-ck3/patch-2.6.16-ck3.bz2
>
The swap prefetching here, and the one in -mm AFAIKS still do not follow
the lowmem reserve ratio correctly. This might explain why prefetching
appears to help some people after updatedb swaps stuff out to make room
for pagecache -- it may actually be dipping into lower zones when it
shouldn't.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply
* Re: Re: [PATCH] ia64 build fixes
From: Ian Campbell @ 2006-04-02 8:37 UTC (permalink / raw)
To: Keir Fraser; +Cc: xen-devel, Alex Williamson, xen-ia64-devel
In-Reply-To: <cbc762bbf18d3861589570c651a7213e@cl.cam.ac.uk>
On Sun, 2006-04-02 at 09:20 +0100, Keir Fraser wrote:
> On 1 Apr 2006, at 22:46, Alex Williamson wrote:
>
> > Here's a patch that enables HYPERVISOR_sched_op() and
> > HYPERVISOR_sched_opt_compat() for ia64. We currently have no users of
> > this call, but there's no harm in enabling it (tested by adding a
> > HYPERVISOR_yield() call to default_idle()). I did notice a problem
> > with
> > the compat interface though, nothing defines __XEN_INTERFACE_VERSION__
> > for the build of xen. We're therefore stuck on interface version
> > 0x00000000 where __HYPERVISOR_sched_op_compat == __HYPERVISOR_sched_op.
>
> Well, it doesn't actually matter right now since Xen itself does not
> use the __HYPERVISOR_foo numbers. But yes, I can see this might bite us
> later so we ought to define it.
I was using them in some debugging code the other day and it bit me :-(
Christian suggested changing xen-compat.h to use the maximum version
when compiling Xen. e.g.
#ifndef __XEN_INTERFACE_VERSION__
#ifdef __XEN__
#define __XEN_INTERFACE_VERSION__ 0xffffffff
#else
#define __XEN_INTERFACE_VERSION__ 0x00000000
#endif
#endif
Ian.
^ permalink raw reply
* Re: Re: [PATCH] ia64 build fixes
From: Keir Fraser @ 2006-04-02 8:31 UTC (permalink / raw)
To: Keir Fraser; +Cc: xen-devel, Alex Williamson, xen-ia64-devel
In-Reply-To: <cbc762bbf18d3861589570c651a7213e@cl.cam.ac.uk>
On 2 Apr 2006, at 09:20, Keir Fraser wrote:
>> Here's a patch that enables HYPERVISOR_sched_op() and
>> HYPERVISOR_sched_opt_compat() for ia64. We currently have no users of
>> this call, but there's no harm in enabling it (tested by adding a
>> HYPERVISOR_yield() call to default_idle()). I did notice a problem
>> with
>> the compat interface though, nothing defines __XEN_INTERFACE_VERSION__
>> for the build of xen. We're therefore stuck on interface version
>> 0x00000000 where __HYPERVISOR_sched_op_compat ==
>> __HYPERVISOR_sched_op.
>
> Well, it doesn't actually matter right now since Xen itself does not
> use the __HYPERVISOR_foo numbers. But yes, I can see this might bite
> us later so we ought to define it.
Ah, I'm forgetting you have a hypercall switch statement. I'll add the
version number.
With regard to your patch, actually I was thinking more about the vmx
hypercall interface which already supports sched_op_compat --- should
that one have sched_op added too, in vmx_hypercall.c?
-- Keir
^ permalink raw reply
* Re: [patch] make evtchn_upcall_pending arch-specific type
From: Keir Fraser @ 2006-04-02 8:27 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: xen-devel, Hollis Blanchard, xen-ppc-devel
In-Reply-To: <493993A5-D07B-4F95-883C-00B89B2D831C@watson.ibm.com>
On 1 Apr 2006, at 20:45, Jimi Xenidis wrote:
>>> unsigned long evtchn_upcall_bits;
>>
>> We'd have to group more than just the mask and pending flags into
>> that long on x86 as otherwise we change the size of a public
>> structure.
>
> No size change, those two elements are padded to a long to accommodate
> the size and alignment of evtchn_pending_sel; so the size remains the
> same.
Well that is true. I'd still like to see how big the patch would be to
hide accesses of the pending flag behind a macro, and how clean that
would end up being.
There maybe also be the issue of non-atomic updates of the mask flag,
but that mostly only happens in xenlinux. IA64 and x86 can update
distinct bytes separately and atomically, but I'm not sure if powerpc
guarantees writes are atomic at byte granularity? That flag gets
touched quite a lot when running xenlinux, so we wouldn't want to make
the accesses anything other than ordinary writes on x86 and ia64.
That's one of the benefits for us of currently defining the mask flag
in a separate uint8_t.
-- Keir
^ permalink raw reply
* Re: PCI-DMA: Out of IOMMU space on x86-64 (Athlon64x2), with solution
From: Joerg Bashir @ 2006-04-02 8:24 UTC (permalink / raw)
To: Muli Ben-Yehuda; +Cc: Robert Hancock, linux-kernel, ak, jgarzik
In-Reply-To: <20060402080035.GA7856@granada.merseine.nu>
Muli Ben-Yehuda wrote:
> On Sat, Apr 01, 2006 at 11:51:26PM -0800, Joerg Bashir wrote:
>
>
>>I saw a lot of patches come through by Muli but am not sure they address
>>this issue, do they?
>
>
> No, I'm afraid not - our patches are to support a different
> IOMMU, and it looks like this problem is gart specific. I'll go dig
> through the archive, but is there consensus on how to solve this bug
> and it's just a question of doing the work, or is the root cause
> unknown?
I'm unsure. Here is an earlier message from this thread with info and a
glimmer of hope.
------------------------------------
Andi Kleen wrote:
> On Friday 03 March 2006 22:27, Allen Martin wrote:
>
>
>> nForce4 has 64 bit (40 bit AMD64) DMA in the SATA controller. We gave
>> the docs to Jeff Garzik under NDA. He posted some non functional driver
>> code to linux-ide earlier this week that has the 64 bit registers and
>> structures although it doesn't make use of them. Someone could pick
>> this up if they wanted to work on it though.
>
>
>
> Thanks for the correction. Sounds nice - hopefully we'll get a driver
soon.
> I guess it's in good hands with Jeff for now.
I'll happen but not soon. Motivation is low at NV and here as well,
since newer NV is AHCI. The code in question, "NV ADMA", is essentially
legacy at this point -- though I certainly acknowledge the large current
installed base. Just being honest about the current state of things...
Jeff
>
> Cheers,
> Muli
^ permalink raw reply
* Re: [PATCH] ia64 build fixes
From: Keir Fraser @ 2006-04-02 8:20 UTC (permalink / raw)
To: Alex Williamson; +Cc: xen-devel, xen-ia64-devel
In-Reply-To: <1143928012.18506.56.camel@localhost>
On 1 Apr 2006, at 22:46, Alex Williamson wrote:
> Here's a patch that enables HYPERVISOR_sched_op() and
> HYPERVISOR_sched_opt_compat() for ia64. We currently have no users of
> this call, but there's no harm in enabling it (tested by adding a
> HYPERVISOR_yield() call to default_idle()). I did notice a problem
> with
> the compat interface though, nothing defines __XEN_INTERFACE_VERSION__
> for the build of xen. We're therefore stuck on interface version
> 0x00000000 where __HYPERVISOR_sched_op_compat == __HYPERVISOR_sched_op.
Well, it doesn't actually matter right now since Xen itself does not
use the __HYPERVISOR_foo numbers. But yes, I can see this might bite us
later so we ought to define it.
-- Keir
^ permalink raw reply
* [PATCH 00/49] V4L/DVB updates
From: mchehab @ 2006-04-02 8:16 UTC (permalink / raw)
To: linux-kernel, torvalds; +Cc: linux-dvb-maintainer, video4linux-list, akpm
Linus,
Please pull these from master branch at:
kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git
It contains the following stuff:
- Add support for I2C_HW_B_CX2341X board adapter
- Minor layout changes to make it consistent
- Implement routing command for saa7115.c
- Implement new routing commands in saa7127.c
- Remove VIDIOC_S_AUDIO from tvaudio: no longer used.
- Added the new routing commands to cx25840.
- Fix compilation warning at powerpc platform
- Saa7134: select FW_LOADER
- cpia cleanups
- Bt8xx: select FW_LOADER
- Cxusb: add support for FusionHDTV USB portable remote control
- Whitespace cleanup
- Fix video-buf PCI wrappers
- Fix camera key on FusionHDTV portable remote control
- Reduce FWSEND due to certain I2C bus adapter limits
- Fix default values for tvp5150 controls
- Added PCI IDs of 2 LifeView Cards
- Corrected CVBS input for the AVERMEDIA 777 DVB-T
- Added support for the new Lifeview hybrid cardbus modules
- Kconfig: clean up media/usb menus
- et61x251: fixed Kconfig menu and Makefile build configuration
- zc0301: fixed Kconfig menu and Makefile build configuration
- sn9c102: fixed Kconfig menu and Makefile build configuration
- pwc: fixed Kconfig menu and Makefile build configuration
- usbvideo: fixed Kconfig menu and Makefile build configuration
- put v4l encoder/decoder configuration into a separate menu
- Support for a new revision of the WT220U-stick
- Kconfig: Add firmware download comments for or51211 and or51132
- Kconfig: Fix PCI ID typo in VIDEO_CX88_ALSA help text
- Add wm8739 stereo audio ADC i2c driver
- Don't set msp3400c-non-existent register
- Fix msp3400c wait time and better audio mode fallbacks
- Add new NEC uPD64031A and uPD64083 i2c drivers
- Remove trailing newlines
- Fix SAP + stereo mode at msp3400
- Move usb v4l docs into Documentation/video4linux
- Configurable dma buffer size for saa7146-based budget dvb cards
- Fix typo in comment
- New module parameter 'tv_standard' (dvb-ttpci driver)
- Fix memory leak in dvr open
- Fix budget-av CAM reset
- Kconfig: fix VP-3054 Secondary I2C Bus build configuration menu dependencies
- Keep experimental SLICED_VBI defines under an #if 0
- Fix msp3400c and bttv stereo/mono/bilingual detection/handling
- Previous change for cx2341X boards broke the remote support
- More msp3400 and bttv fixes
- Remove obsolete commands from tvp5150.c
- Make msp3400 routing defines more consistent
- cpia2: fix function prototype
Cheers,
Mauro.
V4L/DVB development is hosted at http://linuxtv.org
---
Documentation/usb/et61x251.txt | 314 ----------
Documentation/usb/ibmcam.txt | 324 ----------
Documentation/usb/ov511.txt | 289 ---------
Documentation/usb/se401.txt | 54 -
Documentation/usb/sn9c102.txt | 518 -----------------
Documentation/usb/stv680.txt | 55 -
Documentation/usb/w9968cf.txt | 461 ---------------
Documentation/usb/zc0301.txt | 254 --------
Documentation/video4linux/CARDLIST.saa7134 | 5
Documentation/video4linux/et61x251.txt | 314 ++++++++++
Documentation/video4linux/ibmcam.txt | 324 ++++++++++
Documentation/video4linux/ov511.txt | 288 +++++++++
Documentation/video4linux/se401.txt | 54 +
Documentation/video4linux/sn9c102.txt | 518 +++++++++++++++++
Documentation/video4linux/stv680.txt | 53 +
Documentation/video4linux/w9968cf.txt | 461 +++++++++++++++
Documentation/video4linux/zc0301.txt | 254 ++++++++
drivers/media/Kconfig | 22
drivers/media/dvb/bt8xx/Kconfig | 1
drivers/media/dvb/dvb-core/dmxdev.c | 12
drivers/media/dvb/dvb-core/dvb_frontend.c | 18
drivers/media/dvb/dvb-core/dvb_frontend.h | 2
drivers/media/dvb/dvb-usb/cxusb.c | 64 +-
drivers/media/dvb/dvb-usb/dtt200u.c | 47 +
drivers/media/dvb/dvb-usb/dvb-usb-ids.h | 2
drivers/media/dvb/dvb-usb/vp702x-fe.c | 5
drivers/media/dvb/frontends/Kconfig | 12
drivers/media/dvb/frontends/tda1004x.c | 12
drivers/media/dvb/ttpci/av7110.c | 8
drivers/media/dvb/ttpci/av7110_av.c | 2
drivers/media/dvb/ttpci/budget-av.c | 13
drivers/media/dvb/ttpci/budget-core.c | 78 ++
drivers/media/dvb/ttpci/budget-patch.c | 24
drivers/media/dvb/ttpci/budget.h | 13
drivers/media/video/Kconfig | 237 ++-----
drivers/media/video/Makefile | 6
drivers/media/video/bt8xx/bttv-driver.c | 170 ++---
drivers/media/video/bt8xx/bttv-vbi.c | 2
drivers/media/video/cpia.c | 13
drivers/media/video/cpia2/cpia2.h | 2
drivers/media/video/cx25840/cx25840-audio.c | 3
drivers/media/video/cx25840/cx25840-core.c | 24
drivers/media/video/cx25840/cx25840-core.h | 67 ++
drivers/media/video/cx25840/cx25840-firmware.c | 15
drivers/media/video/cx25840/cx25840-vbi.c | 9
drivers/media/video/cx25840/cx25840.h | 107 ---
drivers/media/video/cx88/Kconfig | 15
drivers/media/video/em28xx/em28xx-cards.c | 4
drivers/media/video/em28xx/em28xx-video.c | 33 -
drivers/media/video/et61x251/Kconfig | 16
drivers/media/video/ir-kbd-i2c.c | 7
drivers/media/video/msp3400-driver.c | 91 +-
drivers/media/video/msp3400-driver.h | 6
drivers/media/video/msp3400-kthreads.c | 163 ++---
drivers/media/video/pwc/Kconfig | 28
drivers/media/video/saa7115.c | 65 +-
drivers/media/video/saa7127.c | 43 -
drivers/media/video/saa7134/Kconfig | 1
drivers/media/video/saa7134/saa7134-cards.c | 66 ++
drivers/media/video/saa7134/saa7134-dvb.c | 4
drivers/media/video/saa7134/saa7134.h | 1
drivers/media/video/sn9c102/Kconfig | 13
drivers/media/video/tuner-core.c | 12
drivers/media/video/tvaudio.c | 15
drivers/media/video/tveeprom.c | 6
drivers/media/video/tvp5150.c | 140 ----
drivers/media/video/upd64031a.c | 288 +++++++++
drivers/media/video/upd64083.c | 262 ++++++++
drivers/media/video/usbvideo/Kconfig | 44 +
drivers/media/video/usbvideo/Makefile | 8
drivers/media/video/v4l2-common.c | 8
drivers/media/video/video-buf.c | 14
drivers/media/video/wm8739.c | 355 +++++++++++
drivers/media/video/zc0301/Kconfig | 13
include/linux/videodev2.h | 61 --
include/media/cx25840.h | 64 ++
include/media/msp3400.h | 60 -
include/media/saa7115.h | 37 +
include/media/saa7127.h | 41 +
include/media/upd64031a.h | 42 +
include/media/upd64083.h | 60 +
81 files changed, 4426 insertions(+), 3190 deletions(-)
^ permalink raw reply
* Re: [RFC][patch] console_flush()
From: Keir Fraser @ 2006-04-02 8:16 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: xen-devel
In-Reply-To: <DDC0713C-B9F2-4E54-AC53-B8D9882C7B81@watson.ibm.com>
On 1 Apr 2006, at 20:38, Jimi Xenidis wrote:
> Should we unsync after the panic message, then?
> -JX
That would be quite unnecessary since we reboot five seconds later. :-)
The only reason to exit synchronous mode is performance: to avoid
polling the serial status register.
-- Keir
^ permalink raw reply
* Help recreating a raid5
From: David Greaves @ 2006-04-02 8:15 UTC (permalink / raw)
To: linux-raid
Hi
I need to rebuild a 3-disk raid5.
One disk may be faulty (sda) ; one is good (sdd) and the other I think
is OK too (sdb).
The array dropped one disk (sda), then a short time later, another (sdb)
I mistakenly 'added' sdb back in which of course marked it as a spare.
This means that --assemble even with --force no longer works:
haze:~# mdadm --detail /dev/md1
/dev/md1:
Version : 00.90.03
Creation Time : Sat Jun 11 23:12:06 2005
Raid Level : raid5
Device Size : 195358336 (186.31 GiB 200.05 GB)
Raid Devices : 3
Total Devices : 2
Preferred Minor : 1
Persistence : Superblock is persistent
Update Time : Sun Apr 2 08:35:50 2006
State : clean, degraded
Active Devices : 1
Working Devices : 2
Failed Devices : 0
Spare Devices : 1
Layout : left-symmetric
Chunk Size : 64K
UUID : 8d3c8cee:ef55096d:0f219d44:189f8912
Events : 0.1285185
Number Major Minor RaidDevice State
0 8 49 0 active sync /dev/sdd1
1 0 0 - removed
2 0 0 - removed
3 8 17 - spare /dev/sdb1
A recent --detail whilst all was well gave:
/dev/md1:
Version : 00.90.03
Creation Time : Sat Jun 11 23:12:06 2005
Raid Level : raid5
Array Size : 390716672 (372.62 GiB 400.09 GB)
Device Size : 195358336 (186.31 GiB 200.05 GB)
Raid Devices : 3
Total Devices : 3
Preferred Minor : 1
Persistence : Superblock is persistent
Update Time : Fri Mar 31 09:53:07 2006
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 64K
UUID : 8d3c8cee:ef55096d:0f219d44:189f8912
Events : 0.1269558
Number Major Minor RaidDevice State
0 8 49 0 active sync /dev/sdd1
1 8 17 1 active sync /dev/sdb1
2 8 1 2 active sync /dev/sda1
and at the first failure I saw this in dmesg:
raid5: Disk failure on sda1, disabling device. Operation continuing on 2
devices
RAID5 conf printout:
--- rd:3 wd:2 fd:1
disk 0, o:1, dev:sdd1
disk 1, o:1, dev:sdb1
disk 2, o:0, dev:sda1
RAID5 conf printout:
--- rd:3 wd:2 fd:1
disk 0, o:1, dev:sdd1
disk 1, o:1, dev:sdb1
From some archive reading I understand that I can recreate the array using
mdadm --create /dev/md1 -l5 -n3 /dev/sdd1 /dev/sdb1 missing
but that I need to specify the correct order for the drives.
I've not used --assume-clean, --force or --run; should I? I assume that
since it's only got 2 of 3 then it won't need the assume-clean.
The detail and dmesg data suggests that the order in the command above
is correct.
Can anyone confirm this?
Thanks
David
--
^ permalink raw reply
* [lm-sensors] PIIX4 and fix_hstcfg
From: Jean Delvare @ 2006-04-02 8:13 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <442E9B64.50909@sh.cvut.cz>
Hi Rudolf, Tom,
> Tom Rini wrote:
> > System Information
> > Manufacturer: To be filled
> > Product Name: To be filled
> > Version: To be filled
>
> Quite clever :)
This table is totally crappy, indeed. Nothing we can do with this.
> I think just a drop plus doc note is a winner.
Agreed. Can you please work up a patch?
Thanks,
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH 10/15] libata: add dev->sata_spd_limit and helpers
From: Jeff Garzik @ 2006-04-02 8:12 UTC (permalink / raw)
To: Tejun Heo; +Cc: alan, albertcc, linux-ide
In-Reply-To: <442F222F.3010302@gmail.com>
Tejun Heo wrote:
> Jeff Garzik wrote:
>> NAK, I definitely don't want to closely associate phy and device
>> parameters, because they are fundamentally two different things.
>>
>> We program and address PHYs, so perhaps a sata_phy struct is needed.
>>
>> Port multipliers also get interesting because we need to use ATA-ish
>> commands to talk to the PM phys. Perhaps a struct ata_port_mult
>> inside ata_device is warranted, where one stores an array of sata_phy
>> structs, and other PM-specific details.
>>
>
> Hmmm... Yeah I also thought about extracting out PHY related information
> out such that PATAs share them, SATA and PM have their own maybe marked
> to indicate how they are connected. But that looked like going too far
> especially because we don't have PM support yet. So, sticking it into
> dev was sorta middle-ground.
>
> How about putting it into ata_port around ap->cbl? This fits the current
> model better and should work the same.
Sounds good to me.
Jeff
^ permalink raw reply
* [lm-sensors] nForce 410
From: Jean Delvare @ 2006-04-02 8:11 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <20060401215808.67999.qmail@web37401.mail.mud.yahoo.com>
Hi Mark, Rudolf,
(Mark, please always reply to the list rather than individual members.)
> Linux digittar 2.6.15-19-k7 #1 SMP PREEMPT Mon Mar 20 18:21:44 UTC 2006 i686 GNU/Linux
> (...)
> 0000:00:0a.1 0c05: 10de:0264 (rev a2)
> (...)
> 0000:00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a2)
OK, it's probably just a matter of adding this PCI ID to the
i2c-nforce2 driver. It would be nice if Nvidia could be somewhat
consistent in their product names...
Mark, please try the following (as root):
modprobe i2c-nforce2
echo "10de 0264" > /sys/bus/pci/drivers/nForce2_smbus/new_id
It should bring the SMBus to work. If it does, we'll add that ID to the
driver permanently.
Thanks,
--
Jean Delvare
^ permalink raw reply
* Re: PROBLEM: make menuconfig fails under 2.6.16
From: Marco Roeland @ 2006-04-02 8:10 UTC (permalink / raw)
To: Blue Fox; +Cc: linux-kernel
In-Reply-To: <BAY110-F1201ECD426A949996E3F11FFD40@phx.gbl>
On Sunday April 2nd 2006 at 08:33 uur Blue Fox wrote:
> Thank you for information.
>
> I am using Linux from Scratch. NCURSES is part of the installation process.
> /usr/lib/libncurses.so is installed on the system. After analysing the
> problem I encountered that it has to be a link to /lib/libncurses.so.5
> which is a link to libncurses.so.5.5.
>
> The link in my /usr/lib was broken. After restoring it, build is working.
Ok, these library links are normally automatically created by running
'ldconfig'. You can always rerun this by hand at any time.
Anyway this is getting highly offtopic! And remember you can always use
"make config" or "make oldconfig" (if you had an earlier .config) to get
along even without "graphical" configurators. ;-)
--
Marco Roeland
^ permalink raw reply
* Re: [PATCH 09/15] libata: implement ata_down_xfermask_limit()
From: Jeff Garzik @ 2006-04-02 8:07 UTC (permalink / raw)
To: Tejun Heo; +Cc: alan, albertcc, linux-ide
In-Reply-To: <20060402065856.GI13172@htj.dyndns.org>
Tejun Heo wrote:
> On Sun, Apr 02, 2006 at 09:55:44AM +0900, Tejun Heo wrote:
>> Jeff Garzik wrote:
>>> Tejun Heo wrote:
>>>> Implement ata_down_xfermask_limit(). This function manipulates
>>>> @dev->pio/mwdma/udma_mask such that the next lower transfer mode is
>>>> selected. This will be used by ata_bus_probe() rewrite and later by
>>>> EH speeding down.
>>>>
>>>> Signed-off-by: Tejun Heo <htejun@gmail.com>
>>> ACK, though I share Alan's concerns, even with your explanation. We'll
>>> see where this leads...
>>>
>>> Not applied because it will cause a compile warning.
>>>
>> I'll write fuller description of synchronization model in the head
>> message of new EH framework patchset. Sorry about the compile warning.
>>
>
> Jeff, the compile warning is about ata_down_xfermask_limit() being
> unused,
Correct. It just didn't get merged because I didn't merge any users.
Jeff
^ permalink raw reply
* Re: sata_sil or libata?
From: Wesley Lim @ 2006-04-02 8:05 UTC (permalink / raw)
To: David Greaves
Cc: jgarzik, linux-ide, Mark Lord, albertl, htejun, axboe, jpiszcz
In-Reply-To: <a8b98fc60604012243w2ca883e0rb6e0115de1ba1c40@mail.gmail.com>
The more I think about it, the more it sounds like a faulty hard disk.
I'll just RMA it. Sorry for the trouble.
Wesley
On 4/1/06, Wesley Lim <wesleylim@gmail.com> wrote:
> On 4/1/06, David Greaves <david@dgreaves.com> wrote:
> > I take it badblocks shows the drives as OK? (mine does)
>
> smartctl says that SMART overall-health self-assessment is passed.
>
> I've tinkered around with badblocks and the results are surprising. I
> really hope this is not a case of bad hard disk that intermittently
> decides to act up.
>
> badblocks gives the same errors as when copying files into the drive.
> *However* badblocks reports 0 bad sectors and no libata error if I
> test the exact same sectors it reported were bad *immediately after
> the previous (errored) run* (no cooldown/reboot/etc) It might have to
> do with length of SATA bus activity? I get both libata and badblocks
> errors around the 60000000 sector range after badblocks has been
> running ~1 hour into a test. if I just run badblocks over those
> reported blocks, it always shows up fine, no libata or badblocks error
> (including badblocks -w)
>
> I experience the errors only on the reading phase of badblocks, not
> the writing phase. Also, as said above, I get zero errors when I
> repeat badblocks -w over any specific "problem" areas. This cycle
> repeats itself. (if I run a full drive scan, similar errors occur. if
> I check just those "bad" blocks, they disappear)
>
> I'm going to try starting a long block scan from a different address n
> and see if the reported "bad" blocks show up around the n+60000000
> sector range.
>
> > Mark published *two* patches to provide scsi op/cmd info which you may
> > want to apply. (25/2/06 and 14/2/06)
> > (They don't quite apply cleanly - IIRC Mark has a DPRINTK macro that
> > needs changing to a printk call)
>
> I just patched my kernel. The new error messages are below.
>
> > By the way, 2.6.16 is not kicking the drives from the array for me.
> > Did you mean 2.6.15.1? (just checking)
>
> Yup, 2.6.16.1
>
>
> Here's the new dmesg (running badblocks)
>
> ata1: no sense translation for op=0x28 cmd=0x25 status: 0x51
> ata1: translated op=0x28 cmd=0x25 ATA stat/err 0x51/00 to SCSI
> SK/ASC/ASCQ 0x3/11/04
> ata1: status=0x51 { DriveReady SeekComplete Error }
> ata1: no sense translation for op=0x28 cmd=0x25 status: 0x51
> ata1: translated op=0x28 cmd=0x25 ATA stat/err 0x51/00 to SCSI
> SK/ASC/ASCQ 0x3/11/04
> ata1: status=0x51 { DriveReady SeekComplete Error }
> ata1: no sense translation for op=0x28 cmd=0x25 status: 0x51
> ata1: translated op=0x28 cmd=0x25 ATA stat/err 0x51/00 to SCSI
> SK/ASC/ASCQ 0x3/11/04
> ata1: status=0x51 { DriveReady SeekComplete Error }
> ata1: no sense translation for op=0x28 cmd=0x25 status: 0x51
> ata1: translated op=0x28 cmd=0x25 ATA stat/err 0x51/00 to SCSI
> SK/ASC/ASCQ 0x3/11/04
> ata1: status=0x51 { DriveReady SeekComplete Error }
> ata1: no sense translation for op=0x28 cmd=0x25 status: 0x51
> ata1: translated op=0x28 cmd=0x25 ATA stat/err 0x51/00 to SCSI
> SK/ASC/ASCQ 0x3/11/04
> ata1: status=0x51 { DriveReady SeekComplete Error }
> ata1: no sense translation for op=0x28 cmd=0x25 status: 0x51
> ata1: translated op=0x28 cmd=0x25 ATA stat/err 0x51/00 to SCSI
> SK/ASC/ASCQ 0x3/11/04
> ata1: status=0x51 { DriveReady SeekComplete Error }
> sd 0:0:0:0: SCSI error: return code = 0x8000002
> sda: Current: sense key: Medium Error
> Additional sense: Unrecovered read error - auto reallocate failed
> end_request: I/O error, dev sda, sector 61590952
> ata1: no sense translation for op=0x28 cmd=0x25 status: 0x51
> ata1: translated op=0x28 cmd=0x25 ATA stat/err 0x51/00 to SCSI
> SK/ASC/ASCQ 0x3/11/04
> ata1: status=0x51 { DriveReady SeekComplete Error }
> ata1: no sense translation for op=0x28 cmd=0x25 status: 0x51
> ata1: translated op=0x28 cmd=0x25 ATA stat/err 0x51/00 to SCSI
> SK/ASC/ASCQ 0x3/11/04
> ata1: status=0x51 { DriveReady SeekComplete Error }
> ata1: no sense translation for op=0x28 cmd=0x25 status: 0x51
> ata1: translated op=0x28 cmd=0x25 ATA stat/err 0x51/00 to SCSI
> SK/ASC/ASCQ 0x3/11/04
> ata1: status=0x51 { DriveReady SeekComplete Error }
> ata1: no sense translation for op=0x28 cmd=0x25 status: 0x51
> ata1: translated op=0x28 cmd=0x25 ATA stat/err 0x51/00 to SCSI
> SK/ASC/ASCQ 0x3/11/04
> ata1: status=0x51 { DriveReady SeekComplete Error }
> ata1: no sense translation for op=0x28 cmd=0x25 status: 0x51
> ata1: translated op=0x28 cmd=0x25 ATA stat/err 0x51/00 to SCSI
> SK/ASC/ASCQ 0x3/11/04
> ata1: status=0x51 { DriveReady SeekComplete Error }
> ata1: no sense translation for op=0x28 cmd=0x25 status: 0x51
> ata1: translated op=0x28 cmd=0x25 ATA stat/err 0x51/00 to SCSI
> SK/ASC/ASCQ 0x3/11/04
> ata1: status=0x51 { DriveReady SeekComplete Error }
> sd 0:0:0:0: SCSI error: return code = 0x8000002
> sda: Current: sense key: Medium Error
> Additional sense: Unrecovered read error - auto reallocate failed
> end_request: I/O error, dev sda, sector 61590960
>
^ permalink raw reply
* Re: PCI-DMA: Out of IOMMU space on x86-64 (Athlon64x2), with solution
From: Muli Ben-Yehuda @ 2006-04-02 8:00 UTC (permalink / raw)
To: Joerg Bashir; +Cc: Robert Hancock, linux-kernel, ak, jgarzik
In-Reply-To: <442F827E.8040104@archive.org>
On Sat, Apr 01, 2006 at 11:51:26PM -0800, Joerg Bashir wrote:
> I saw a lot of patches come through by Muli but am not sure they address
> this issue, do they?
No, I'm afraid not - our patches are to support a different
IOMMU, and it looks like this problem is gart specific. I'll go dig
through the archive, but is there consensus on how to solve this bug
and it's just a question of doing the work, or is the root cause
unknown?
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
^ permalink raw reply
* Re: Synchronizing Bit operations V2
From: Russell King @ 2006-04-02 7:59 UTC (permalink / raw)
To: Christoph Lameter
Cc: Luck, Tony, David Mosberger-Tang, Nick Piggin, Zoltan Menyhart,
Boehm, Hans, Grundler, Grant G, Chen, Kenneth W, akpm,
linux-kernel, linux-ia64
In-Reply-To: <Pine.LNX.4.64.0603301657470.2068@schroedinger.engr.sgi.com>
On Thu, Mar 30, 2006 at 04:58:25PM -0800, Christoph Lameter wrote:
> On Thu, 30 Mar 2006, Luck, Tony wrote:
>
> > > Also some higher level functions may want to have the mode passed to them
> > > as parameters. See f.e. include/linux/buffer_head.h. Without the
> > > parameters you will have to maintain farms of definitions for all cases.
> >
> > But if any part of the call chain from those higher level functions
> > down to these low level functions is not inline, then the compiler
> > won't be able to collapse out the "switch (mode)" ... so we'd end up
> > with a ton of extra object code.
>
> Correct. But such bitops are typically defined to be inline.
That's doesn't seem to be the point that Tony was making. To illustrate
it let's add a practical example:
static inline void clear_bit_mode(int bit, unsigned long *ptr, int mode)
{
case (mode) {
...
}
}
void foo(blah blah, int mode)
{
... complex function ...
clear_bit_mode(bit, ptr, mode);
...
}
void bar(blah blah)
{
foo(blah, MODE_BARRIER);
}
In this case, the compiler can not optimise the unnecessary code from
the clear_bit_mode because the mode argument quite definitely is not a
constant known at compile time. Only if 'foo' was a static inline
would it be known.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* Re: Synchronizing Bit operations V2
From: Russell King @ 2006-04-02 7:59 UTC (permalink / raw)
To: Christoph Lameter
Cc: Luck, Tony, David Mosberger-Tang, Nick Piggin, Zoltan Menyhart,
Boehm, Hans, Grundler, Grant G, Chen, Kenneth W, akpm,
linux-kernel, linux-ia64
In-Reply-To: <Pine.LNX.4.64.0603301657470.2068@schroedinger.engr.sgi.com>
On Thu, Mar 30, 2006 at 04:58:25PM -0800, Christoph Lameter wrote:
> On Thu, 30 Mar 2006, Luck, Tony wrote:
>
> > > Also some higher level functions may want to have the mode passed to them
> > > as parameters. See f.e. include/linux/buffer_head.h. Without the
> > > parameters you will have to maintain farms of definitions for all cases.
> >
> > But if any part of the call chain from those higher level functions
> > down to these low level functions is not inline, then the compiler
> > won't be able to collapse out the "switch (mode)" ... so we'd end up
> > with a ton of extra object code.
>
> Correct. But such bitops are typically defined to be inline.
That's doesn't seem to be the point that Tony was making. To illustrate
it let's add a practical example:
static inline void clear_bit_mode(int bit, unsigned long *ptr, int mode)
{
case (mode) {
...
}
}
void foo(blah blah, int mode)
{
... complex function ...
clear_bit_mode(bit, ptr, mode);
...
}
void bar(blah blah)
{
foo(blah, MODE_BARRIER);
}
In this case, the compiler can not optimise the unnecessary code from
the clear_bit_mode because the mode argument quite definitely is not a
constant known at compile time. Only if 'foo' was a static inline
would it be known.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* Re: Synchronizing Bit operations V2
From: Russell King @ 2006-04-02 7:54 UTC (permalink / raw)
To: Christoph Lameter
Cc: Andi Kleen, Zoltan Menyhart, Boehm, Hans, Grundler, Grant G,
Chen, Kenneth W, akpm, linux-kernel, linux-ia64
In-Reply-To: <Pine.LNX.4.64.0603310952540.6825@schroedinger.engr.sgi.com>
On Fri, Mar 31, 2006 at 09:56:23AM -0800, Christoph Lameter wrote:
> On Fri, 31 Mar 2006, Andi Kleen wrote:
>
> > > Powerpc can do similar things AFAIK. Not sure what other arches have
> > > finer grained control over barriers but it could cover a lot of special
> > > cases for other processors as well.
> >
> > Yes, but I don't think the goal of a portable atomic operations API
> > in Linux is it to cover everybody's special case in every possible
> > combination. The goal is to have an abstraction that will lead to
> > portable code. I don't think your proposal will do this.
>
> AFAIK The goal of a bitmap operations API (we are not talking about atomic
> operations here) is to make bitmap operations as efficient as possible and
> as simple as possible.
If we are not talking about atomic operations...
> We already have multiple special cases for each
> bitmap operation
>
> I.e.
>
> clear_bit()
why do you then bring up the atomic bitop operation here?
> __clear_bit()
this is the non-atomic bitop operation.
> and some people talk abouit
>
> clear_bit_lock()
> clear_bit_unlock()
Neither of these exist in the kernel.
> What I am prosing is to do one clear_bit_mode function that can take a
> parameter customizing its synchronization behavior.
>
> clear_bit_mode(bit,addr,mode)
Which means for architectures which implement bitops out of line (due
to their size) that you end up making those architectures even more
inefficient because they now have to decode the "mode" parameter which
will take several compares and branches.
The only way around that would be for such architectures to do:
#define clear_bit_mode(bit,addr,mode) clear_bit_mode_##mode(bit,addr)
and then we're back to the named function approach.
Incidentally, you say that the named function approach is not extensible.
Do you have a limit on the number of functions you can have in your
kernel? If not, I don't see where such a statement would come from -
you obviously can extend "clear_bit_atomic" and "clear_bit_nonatomic"
by adding eg, "clear_bit_barrier". And if you really want to multiplex
them through one function, you can do:
#define clear_bit_atomic(bit,addr) clear_bit_mode(bit,addr,MODE_ATOMIC)
#define clear_bit_nonatomic(bit,addr) clear_bit_mode(bit,addr,MODE_NONATOMIC)
#define clear_bit_barrier(bit,addr) clear_bit_mode(bit,addr,MODE_BARRIER)
etc.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* Re: Synchronizing Bit operations V2
From: Russell King @ 2006-04-02 7:54 UTC (permalink / raw)
To: Christoph Lameter
Cc: Andi Kleen, Zoltan Menyhart, Boehm, Hans, Grundler, Grant G,
Chen, Kenneth W, akpm, linux-kernel, linux-ia64
In-Reply-To: <Pine.LNX.4.64.0603310952540.6825@schroedinger.engr.sgi.com>
On Fri, Mar 31, 2006 at 09:56:23AM -0800, Christoph Lameter wrote:
> On Fri, 31 Mar 2006, Andi Kleen wrote:
>
> > > Powerpc can do similar things AFAIK. Not sure what other arches have
> > > finer grained control over barriers but it could cover a lot of special
> > > cases for other processors as well.
> >
> > Yes, but I don't think the goal of a portable atomic operations API
> > in Linux is it to cover everybody's special case in every possible
> > combination. The goal is to have an abstraction that will lead to
> > portable code. I don't think your proposal will do this.
>
> AFAIK The goal of a bitmap operations API (we are not talking about atomic
> operations here) is to make bitmap operations as efficient as possible and
> as simple as possible.
If we are not talking about atomic operations...
> We already have multiple special cases for each
> bitmap operation
>
> I.e.
>
> clear_bit()
why do you then bring up the atomic bitop operation here?
> __clear_bit()
this is the non-atomic bitop operation.
> and some people talk abouit
>
> clear_bit_lock()
> clear_bit_unlock()
Neither of these exist in the kernel.
> What I am prosing is to do one clear_bit_mode function that can take a
> parameter customizing its synchronization behavior.
>
> clear_bit_mode(bit,addr,mode)
Which means for architectures which implement bitops out of line (due
to their size) that you end up making those architectures even more
inefficient because they now have to decode the "mode" parameter which
will take several compares and branches.
The only way around that would be for such architectures to do:
#define clear_bit_mode(bit,addr,mode) clear_bit_mode_##mode(bit,addr)
and then we're back to the named function approach.
Incidentally, you say that the named function approach is not extensible.
Do you have a limit on the number of functions you can have in your
kernel? If not, I don't see where such a statement would come from -
you obviously can extend "clear_bit_atomic" and "clear_bit_nonatomic"
by adding eg, "clear_bit_barrier". And if you really want to multiplex
them through one function, you can do:
#define clear_bit_atomic(bit,addr) clear_bit_mode(bit,addr,MODE_ATOMIC)
#define clear_bit_nonatomic(bit,addr) clear_bit_mode(bit,addr,MODE_NONATOMIC)
#define clear_bit_barrier(bit,addr) clear_bit_mode(bit,addr,MODE_BARRIER)
etc.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* Re: PCI-DMA: Out of IOMMU space on x86-64 (Athlon64x2), with solution
From: Joerg Bashir @ 2006-04-02 7:51 UTC (permalink / raw)
To: Robert Hancock; +Cc: linux-kernel, ak, jgarzik, mulix
In-Reply-To: <440CD09A.9040005@shaw.ca>
Robert Hancock wrote:
> Michael Monnerie wrote:
>
>> On Freitag, 3. März 2006 23:23 Jeff Garzik wrote:
>>
>>> I'll happen but not soon. Motivation is low at NV and here as well,
>>> since newer NV is AHCI. The code in question, "NV ADMA", is
>>> essentially legacy at this point -- though I certainly acknowledge
>>> the large current installed base. Just being honest about the
>>> current state of things...
>>
>>
>> I'd like to raise motivation a lot because most MB sold here (central
>> Europe) are Nforce4 with Athlon64x2 at the moment. It would be nice
>> from vendors if they support OSS developers more, as it's their
>> interest to have good drivers.
>
>
> I second that.. It appears that nForce4 will continue to be a popular
> chipset even after the Socket AM2 chips are released, so the demand for
> this (and for NCQ support as well, likely) will only increase.
>
I'll third it. Just had another machine blow up it's RAID5 set because
of this bug. Tyan S2895 board, 4 500GB Hitachi SATA drives in RAID5. I
suppose I could buy a 3ware controller I suppose but that's a few
hundred dollars per machine.
These machines are running SUSE 9.3 or SUSE 10, I've tried kernel.org
kernels as well as the iommu=memaper=3 cmdline option.
Any other advice greatly appreciated.
I saw a lot of patches come through by Muli but am not sure they address
this issue, do they?
--Joerg
^ permalink raw reply
* Re: [PATCH 2.6.16-mm2 4/4] sched_domain: Allocate sched_group structures dynamically
From: Siddha, Suresh B @ 2006-04-02 7:35 UTC (permalink / raw)
To: Nick Piggin
Cc: vatsa, Andrew Morton, Ingo Molnar, suresh.b.siddha,
Dinakar Guniguntala, pj, hawkes, linux-kernel
In-Reply-To: <442F2B52.6000205@yahoo.com.au>
On Sun, Apr 02, 2006 at 11:39:30AM +1000, Nick Piggin wrote:
>
> Srivatsa Vaddagiri wrote:
> > /*
> > @@ -6113,6 +6125,10 @@ next_sg:
> > static int build_sched_domains(const cpumask_t *cpu_map)
> > {
> > int i;
> > + struct sched_group *sched_group_phys = NULL;
> > +#ifdef CONFIG_SCHED_MC
> > + struct sched_group *sched_group_core = NULL;
> > +#endif
> > #ifdef CONFIG_NUMA
> > struct sched_group **sched_group_nodes = NULL;
> > struct sched_group *sched_group_allnodes = NULL;
> > @@ -6171,6 +6187,18 @@ static int build_sched_domains(const cpu
> > cpus_and(sd->span, sd->span, *cpu_map);
> > #endif
> >
> > + if (!sched_group_phys) {
> > + sched_group_phys
> > + = kmalloc(sizeof(struct sched_group) * NR_CPUS,
> > + GFP_KERNEL);
> > + if (!sched_group_phys) {
> > + printk (KERN_WARNING "Can not alloc phys sched"
> > + "group\n");
> > + goto error;
> > + }
> > + sched_group_phys_bycpu[i] = sched_group_phys;
> > + }
>
> Doesn't the last assignment have to be outside the if statement?
>
> Hmm.. this design seems like the best way to go for now. Suresh?
Only thing I see in this is, even if there are very few cpus in the
exclusive cpuset, we end up allocating NR_CPUS groups and waste memory.
thanks,
suresh
^ 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.