* Re: [PATCH] mm: limit lowmem_reserve
From: Nick Piggin @ 2006-04-08 0:55 UTC (permalink / raw)
To: Con Kolivas; +Cc: Andrew Morton, ck, linux list, linux-mm
In-Reply-To: <200604081015.44771.kernel@kolivas.org>
Con Kolivas wrote:
> On Friday 07 April 2006 22:40, Nick Piggin wrote:
>
>>How would zone_watermark_ok always fail though?
>
>
> Withdrew this patch a while back; ignore
>
Well, whether or not that particular patch isa good idea, it
is definitely a bug if zone_watermark_ok could ever always
fail due to lowmem reserve and we should fix it.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply
* Re: [PATCH] mm: limit lowmem_reserve
From: Nick Piggin @ 2006-04-08 0:55 UTC (permalink / raw)
To: Con Kolivas; +Cc: Andrew Morton, ck, linux list, linux-mm
In-Reply-To: <200604081015.44771.kernel@kolivas.org>
Con Kolivas wrote:
> On Friday 07 April 2006 22:40, Nick Piggin wrote:
>
>>How would zone_watermark_ok always fail though?
>
>
> Withdrew this patch a while back; ignore
>
Well, whether or not that particular patch isa good idea, it
is definitely a bug if zone_watermark_ok could ever always
fail due to lowmem reserve and we should fix it.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [ALSA - driver 0002009]: No pcm when running mythtv, sox, aplay but /dev/pcm present, oss emulation modules loaded
From: bugtrack @ 2006-04-08 0:27 UTC (permalink / raw)
To: alsa-devel
The following issue has been RESOLVED.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2009>
======================================================================
Reported By: chadady
Assigned To: rlrevell
======================================================================
Project: ALSA - driver
Issue ID: 2009
Category: CORE - pcm
Reproducibility: always
Severity: major
Priority: normal
Status: resolved
Distribution: SuSE
Kernel Version: Linux 2.6.17-rc1
Resolution: fixed
Fixed in Version:
======================================================================
Date Submitted: 04-07-2006 04:15 CEST
Last Modified: 04-08-2006 02:27 CEST
======================================================================
Summary: No pcm when running mythtv, sox, aplay but /dev/pcm
present, oss emulation modules loaded
Description:
I have a Sound Blaster PCI512, sound works great for TvTime and XINE. Have
been trying to get MythTV up and running and it has worked 'fine' up to
1.0.11rc2 (stock kernel 2.6.16.1) in that pcm delivered mono sound, left
speaker only. On 2.6.16.1 the command 'sox -w -r 44000 -t ossdsp /dev/dsp
-t ossdsp /dev/dsp' provided nice sound, both speakers. For 1.0.11rc4 the
same command gives "sox: Failed reading /dev/dsp: Unable to set the sample
size to 16", and Myth gives "NVR: AudioInit(): /dev/dsp : error setting
audio input device to 48000kHz/16bits/2channels NVR: Could not detect
audio blocksize NVR: Cannot open DSP '/dev/dsp', exiting"
======================================================================
----------------------------------------------------------------------
rlrevell - 04-07-06 04:53
----------------------------------------------------------------------
Known bug, try ALSA CVS or the patch from:
http://bugzilla.kernel.org/show_bug.cgi?id=6329
or wait for 2.6.17-rc2
----------------------------------------------------------------------
chadady - 04-08-06 02:05
----------------------------------------------------------------------
The patch worked - thanks and please close.
Issue History
Date Modified Username Field Change
======================================================================
04-07-06 04:15 chadady New Issue
04-07-06 04:15 chadady File Added: .config
04-07-06 04:15 chadady Distribution => SuSE
04-07-06 04:15 chadady Kernel Version => Linux 2.6.17-rc1
04-07-06 04:53 rlrevell Note Added: 0009134
04-08-06 02:05 chadady Note Added: 0009170
04-08-06 02:27 rlrevell Status new => resolved
04-08-06 02:27 rlrevell Resolution open => fixed
04-08-06 02:27 rlrevell Assigned To => rlrevell
======================================================================
-------------------------------------------------------
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.17-rc1-mm1 - detects buggy TSC on GEODE
From: john stultz @ 2006-04-08 0:25 UTC (permalink / raw)
To: Andrew Morton; +Cc: Jim Cromie, linux-kernel
In-Reply-To: <20060407170706.1ae11ea1.akpm@osdl.org>
On Fri, 2006-04-07 at 17:07 -0700, Andrew Morton wrote:
> Jim Cromie <jim.cromie@gmail.com> wrote:
> > as the 2 syslog extracts show;
> > 1. the new kernel is now detecting the buggy TSC on the GEODE-sc1100
> > 2. the bug is apparently correctable by passing 'idle=poll' on kernel
> > boot-line.
>
> John, does this mean that enable-tsc-for-amd-geode-gx-lx.patch is only safe
> to merge after all your time-management patches have gone in?
Hmmm. That would look to be the case from Jim's mail, although I'm not
very familiar with the hardware in question, so I could be wrong.
thanks
-john
^ permalink raw reply
* 3.0.2 kernels
From: Brian Hays @ 2006-04-08 0:21 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 227 bytes --]
I've noticed that when executing "make kernels" in the 3.0.2 tree separate
"xen0" and "xenU" are no longer created. Is this by design? Is there a way
to have both kernels built when executing make dist?
Thank you,
Brian
[-- Attachment #1.2: Type: text/html, Size: 267 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* linear writes to raid5
From: Alex Tomas @ 2006-04-08 0:17 UTC (permalink / raw)
To: linux-raid; +Cc: alex
Good day all,
is there a way to batch explicitely write requests raid5 issues?
for example, there is a raid5 built from 3 disks with chunk=64K.
one types dd if=/dev/zero of=/dev/md0 bs=128k count=1 and 128K
bio gets into the raid5. raid5 processes the request, does xor
for parity stripe, then issues 2 64KB requests down to lower level.
is it even possible to implement? if so, how complex?
I suppose we could introduce a context which holds last
non-issued bio and instead of generic_make_request() in
handle_stripe() try to merge current request to the previous
one from the context? how does this sound to you?
thanks, Alex
^ permalink raw reply
* Re: [PATCH] mm: limit lowmem_reserve
From: Con Kolivas @ 2006-04-08 0:15 UTC (permalink / raw)
To: Nick Piggin; +Cc: Andrew Morton, ck, linux list, linux-mm
In-Reply-To: <44365DC2.1010806@yahoo.com.au>
On Friday 07 April 2006 22:40, Nick Piggin wrote:
> Con Kolivas wrote:
> > On Friday 07 April 2006 16:25, Nick Piggin wrote:
> >>Con Kolivas wrote:
> >>>It is possible with a low enough lowmem_reserve ratio to make
> >>>zone_watermark_ok always fail if the lower_zone is small enough.
> >>
> >>I don't see how this would happen?
> >
> > 3GB lowmem and a reserve ratio of 180 is enough to do it.
>
> How would zone_watermark_ok always fail though?
Withdrew this patch a while back; ignore
--
-ck
^ permalink raw reply
* Re: [PATCH] mm: limit lowmem_reserve
From: Con Kolivas @ 2006-04-08 0:15 UTC (permalink / raw)
To: Nick Piggin; +Cc: Andrew Morton, ck, linux list, linux-mm
In-Reply-To: <44365DC2.1010806@yahoo.com.au>
On Friday 07 April 2006 22:40, Nick Piggin wrote:
> Con Kolivas wrote:
> > On Friday 07 April 2006 16:25, Nick Piggin wrote:
> >>Con Kolivas wrote:
> >>>It is possible with a low enough lowmem_reserve ratio to make
> >>>zone_watermark_ok always fail if the lower_zone is small enough.
> >>
> >>I don't see how this would happen?
> >
> > 3GB lowmem and a reserve ratio of 180 is enough to do it.
>
> How would zone_watermark_ok always fail though?
Withdrew this patch a while back; ignore
--
-ck
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* RE: oprofile not compiling in amd64 hg linux tree
From: Santos, Jose Renato G @ 2006-04-08 0:13 UTC (permalink / raw)
To: Hans-Christian Armingeon, xen-devel
I believe this was already fixed by Keir in the xen-unstable tree
(changeset 9576).
I believe it should be propagated to the linux-2.6-xen tree sometime
soon.
Renato
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com
>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of
>> Hans-Christian Armingeon
>> Sent: Friday, April 07, 2006 2:52 AM
>> To: xen-devel@lists.xensource.com
>> Subject: [Xen-devel] oprofile not compiling in amd64 hg linux tree
>>
>> Hi,
>>
>> when I enable oprofile profiling support (which I don't
>> need), doesn't compile on amd64.
>>
>> /usr/src/xen/linux-2.6.16-20060407.2-xen0/arch/x86_64/oprofil
>> e/Makefile:14: *** invalid syntax in conditional. Stop.
>> make: *** [arch/x86_64/oprofile] Error 2
>>
>> The last successful build was with linux hg 20060405.
>>
>> Any ideas?
>>
>> Thanks in advance,
>>
>> Johnny
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
^ permalink raw reply
* Work in our accounting department
From: Repasting G. Captivity @ 2006-04-08 16:27 UTC (permalink / raw)
To: Linux
Please read this letter attentively!
Hello, our company opens a new vacancy.
Now we have started our activity in the territory of the UK a nd we need to
employ people who will work as our representative in the territory of the UK.
Any interested person can become our manager.
Our vacancy is opened for you if you are:
- Age: from 18 till 60 years
- Located in the territory of the UK
- Have a skill to communicate and access to the Internet.
You will earn from 1000 up to 3000 pounds, working only some hours per day.
You can work part time or full time.
Any person located in the UK can become our employee.
If you are interested in our offer send the following data to our e-mail uk@ExlDisc.com
- Your full name
- Your contact e-mail
- Your phone number
^ permalink raw reply
* Archieve new horizons in your carreer
From: Visions P. Overplayed @ 2006-04-08 16:27 UTC (permalink / raw)
To: Linux
Please read this letter attentively!
Hello, our company opens a new vacancy.
Now we have started our activity in the territory of the UK a nd we need to
employ people who will work as our representative in the territory of the UK.
Any interested person can become our manager.
Our vacancy is opened for you if you are:
- Age: from 18 till 60 years
- Located in the territory of the UK
- Have a skill to communicate and access to the Internet.
You will earn from 1000 up to 3000 pounds, working only some hours per day.
You can work part time or full time.
Any person located in the UK can become our employee.
If you are interested in our offer send the following data to our e-mail uk@ExlDisc.com
- Your full name
- Your contact e-mail
- Your phone number
^ permalink raw reply
* Fw: [BUG] 2.6.17-rc1: SCSI kobject_add problems
From: Andrew Morton @ 2006-04-08 0:14 UTC (permalink / raw)
To: Andrew Vasquez; +Cc: linux-scsi, rct
Begin forwarded message:
Date: Fri, 7 Apr 2006 13:31:05 -0500 (CDT)
From: rct@gherkin.frus.com (Bob Tracy)
To: linux-kernel@vger.kernel.org
Subject: [BUG] 2.6.17-rc1: SCSI kobject_add problems
System is a DEC Alpha 433au with two SCSI disks. SCSI controller is a
QLA1040 supported by the qla1280 driver. Runs 2.6.16 fine. Tried
booting 2.6.17-rc1 and got
kobject_add failed for 0:0: with -EEXIST, don't try to register things with the same name in the same directory
and a fairly long trace output when the system attempted to add sdb.
Not surprisingly, sdb was inaccessible.
Normally (for 2.6.16 anyway), the following relationship exists:
sd 0:0:0:0 sda
sd 0:0:1:0 sdb
More information *might* be available if needed, but will have to be
transcribed by hand. My /usr partition is on sdb, so I don't get very
far with 2.6.17-rc1 on Alpha :-). The problem is probably specific to
the qla1280 or the Alpha, as I have a x86 Adaptec SCSI-based system
with multiple spindles that works fine with 2.6.17-rc1.
--
-----------------------------------------------------------------------
Bob Tracy WTO + WIPO = DMCA? http://www.anti-dmca.org
rct@frus.com
-----------------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: RT task scheduling
From: Peter Williams @ 2006-04-08 0:11 UTC (permalink / raw)
To: Ingo Molnar
Cc: Darren Hart, linux-kernel, Thomas Gleixner, Stultz, John,
Siddha, Suresh B, Nick Piggin
In-Reply-To: <20060406073753.GA18349@elte.hu>
Ingo Molnar wrote:
> * Darren Hart <darren@dvhart.com> wrote:
>
>> My last mail specifically addresses preempt-rt, but I'd like to know
>> people's thoughts regarding this issue in the mainline kernel. Please
>> see my previous post "realtime-preempt scheduling - rt_overload
>> behavior" for a testcase that produces unpredictable scheduling
>> results.
>
> the rt_overload feature i intend to push upstream-wards too, i just
> didnt separate it out of -rt yet.
>
> "RT overload scheduling" is a totally orthogonal mechanism to the SMP
> load-balancer (and this includes smpnice too) that is more or less
> equivalent to having a 'global runqueue' for real-time tasks, without
> the SMP overhead associated with that. If there is no "RT overload" [the
> common case even on Linux systems that _do_ make use of RT tasks
> occasionally], the new mechanism is totally inactive and there's no
> overhead. But once there are more RT tasks than CPUs, the scheduler will
> do "global" decisions for what RT tasks to run on which CPU.
Is this good enough? Isn't it possible with the current
try_to_wake_up() implementation (with or without smpnice) for two RT
tasks to end up on the same CPU even when there are less RT tasks than CPUs?
> To put even
> less overhead on the mainstream kernel, i plan to introduce a new
> SCHED_FIFO_GLOBAL scheduling policy to trigger this behavior. [it doesnt
> make much sense to extend SCHED_RR in that direction.]
I wouldn't have thought a new policy was necessary. Why not just do
this for all SCHED_FIFO (or even all RT) tasks?
BTW Does any body in the real world actually use SCHED_RR?
Peter
--
Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
^ permalink raw reply
* Re: [PATCH 17/21] orinoco_pci: use pci_iomap() for resources
From: Pavel Roskin @ 2006-04-08 0:07 UTC (permalink / raw)
To: Francois Romieu
Cc: jgarzik-e+AXbWqSrlAAvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
orinoco-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20060407233819.GB15667-lmTtMILVy1jWQcoT9B9Ug5SCg42XY1Uw0E9HWUfgJXw@public.gmane.org>
Quoting Francois Romieu <romieu-W8zweXLXuWQS+FvcfC7Uqw@public.gmane.org>:
> > > Is there a reason why dev->mem_{start/end} should not be removed ?
> >
> > Is there a reason why it should? Is it going to be obsolete?
>
> It is slowly obsoleting for a few years (don't laugh...). It is preferred
> to store the relevant address in the private part of the (pci) device.
>
> Moderately recent drivers do not use it at all. However it's fairly common
> in the setup code of the (legacy) isa devices.
I agree that many drivers don't use it. But it would be nice to have a document
describing what is going on. On one hand we are adding new information elements
(such as the bus in "ethtool -i"), on the other hand we are removing addresses
from the ifconfig output. Who is deciding which information is useful and
which is not?
How about netdev->irq? Is it going to be obsolete too? Then I can easily
remove orinoco_pci_setup_netdev() with very minimal adjustments.
--
Regards,
Pavel Roskin
-------------------------------------------------------
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
* [ALSA - driver 0002009]: No pcm when running mythtv, sox, aplay but /dev/pcm present, oss emulation modules loaded
From: bugtrack @ 2006-04-08 0:05 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2009>
======================================================================
Reported By: chadady
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 2009
Category: CORE - pcm
Reproducibility: always
Severity: major
Priority: normal
Status: new
Distribution: SuSE
Kernel Version: Linux 2.6.17-rc1
======================================================================
Date Submitted: 04-07-2006 04:15 CEST
Last Modified: 04-08-2006 02:05 CEST
======================================================================
Summary: No pcm when running mythtv, sox, aplay but /dev/pcm
present, oss emulation modules loaded
Description:
I have a Sound Blaster PCI512, sound works great for TvTime and XINE. Have
been trying to get MythTV up and running and it has worked 'fine' up to
1.0.11rc2 (stock kernel 2.6.16.1) in that pcm delivered mono sound, left
speaker only. On 2.6.16.1 the command 'sox -w -r 44000 -t ossdsp /dev/dsp
-t ossdsp /dev/dsp' provided nice sound, both speakers. For 1.0.11rc4 the
same command gives "sox: Failed reading /dev/dsp: Unable to set the sample
size to 16", and Myth gives "NVR: AudioInit(): /dev/dsp : error setting
audio input device to 48000kHz/16bits/2channels NVR: Could not detect
audio blocksize NVR: Cannot open DSP '/dev/dsp', exiting"
======================================================================
----------------------------------------------------------------------
rlrevell - 04-07-06 04:53
----------------------------------------------------------------------
Known bug, try ALSA CVS or the patch from:
http://bugzilla.kernel.org/show_bug.cgi?id=6329
or wait for 2.6.17-rc2
----------------------------------------------------------------------
chadady - 04-08-06 02:05
----------------------------------------------------------------------
The patch worked - thanks and please close.
Issue History
Date Modified Username Field Change
======================================================================
04-07-06 04:15 chadady New Issue
04-07-06 04:15 chadady File Added: .config
04-07-06 04:15 chadady Distribution => SuSE
04-07-06 04:15 chadady Kernel Version => Linux 2.6.17-rc1
04-07-06 04:53 rlrevell Note Added: 0009134
04-08-06 02:05 chadady Note Added: 0009170
======================================================================
-------------------------------------------------------
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.17-rc1-mm1 - detects buggy TSC on GEODE
From: Andrew Morton @ 2006-04-08 0:07 UTC (permalink / raw)
To: Jim Cromie; +Cc: linux-kernel, johnstul
In-Reply-To: <4436D275.2010402@gmail.com>
Jim Cromie <jim.cromie@gmail.com> wrote:
>
>
> FYI,
>
> as the 2 syslog extracts show;
> 1. the new kernel is now detecting the buggy TSC on the GEODE-sc1100
> 2. the bug is apparently correctable by passing 'idle=poll' on kernel
> boot-line.
>
> Heres one vendor's bug/erratta description:
> http://soekris.com/Issue0003.htm
>
>
> Apr 7 11:42:01 truck kernel: [ 19.160016] Kernel command line:
> console=ttyS0,115200n81 root=/dev/nfs
> nfsroot=192.168.42.1:/nfshost/soekris
> nfsaddrs=192.168.42.100:192.168.42.1:192.168.42.1:255.255.255.0:soekris:eth0
> panic=5 BOOT_IMAGE=vmlinuz-2.6.17-rc1-mm1-sk
> Apr 7 11:42:01 truck kernel: [ 24.314851] Time: tsc clocksource has
> been installed.
> Apr 7 11:42:01 truck kernel: [ 29.977802] TSC appears to be running
> slowly. Marking it as unstable
> Apr 7 11:42:01 truck kernel: [ 20.460000] Time: pit clocksource has
> been installed.
>
>
> Apr 7 12:35:56 truck kernel: [ 21.562573] Kernel command line:
> console=ttyS0,115200n81 root=/dev/nfs
> nfsroot=192.168.42.1:/nfshost/soekris
> nfsaddrs=192.168.42.100:192.168.42.1:192.168.42.1:255.255.255.0:soekris:eth0
> panic=5 idle=poll BOOT_IMAGE=vmlinuz-2.6.17-rc1-mm1-sk
> Apr 7 12:35:56 truck kernel: [ 21.563049] using polling idle threads.
> Apr 7 12:35:56 truck kernel: [ 28.393469] Time: tsc clocksource has
> been installed.
>
>
> Its nice to see the buggy TSC detector detect, and the work-around work.
hm.
John, does this mean that enable-tsc-for-amd-geode-gx-lx.patch is only safe
to merge after all your time-management patches have gone in?
^ permalink raw reply
* Re: [PATCH] PCI Error Recovery: e100 network device driver
From: Alexey Dobriyan @ 2006-04-08 0:03 UTC (permalink / raw)
To: Linas Vepstas
Cc: Greg KH, Jeff Garzik, netdev, linux-pci, linux-kernel,
linuxppc-dev, john.ronciak, jesse.brandeburg, jeffrey.t.kirsher
In-Reply-To: <20060407231134.GN25225@austin.ibm.com>
On Fri, Apr 07, 2006 at 06:11:34PM -0500, Linas Vepstas wrote:
> --- linux-2.6.17-rc1.orig/drivers/net/e100.c
> +++ linux-2.6.17-rc1/drivers/net/e100.c
> + * @state: The current pci conneection state
connection
> +static pci_ers_result_t e100_io_error_detected(struct pci_dev *pdev, pci_channel_state_t state)
> +{
> + struct net_device *netdev = pci_get_drvdata(pdev);
> +
> + /* Similar to calling e100_down(), but avoids adpater I/O. */
adapter
> +static pci_ers_result_t e100_io_slot_reset(struct pci_dev *pdev)
> +{
> + struct net_device *netdev = pci_get_drvdata(pdev);
> + struct nic *nic = netdev_priv(netdev);
> +
> + if (pci_enable_device(pdev)) {
> + printk(KERN_ERR "e100: Cannot re-enable PCI device after reset.\n");
> + return PCI_ERS_RESULT_DISCONNECT;
> + }
> + pci_set_master(pdev);
> +
> + /* Only one device per card can do a reset */
> + if (0 != PCI_FUNC(pdev->devfn))
Wrong order.
^ permalink raw reply
* Re: [PATCH] PCI Error Recovery: e100 network device driver
From: Alexey Dobriyan @ 2006-04-08 0:03 UTC (permalink / raw)
To: Linas Vepstas
Cc: Greg KH, linux-kernel, jesse.brandeburg, linuxppc-dev,
john.ronciak, jeffrey.t.kirsher, netdev, linux-pci, Jeff Garzik
In-Reply-To: <20060407231134.GN25225@austin.ibm.com>
On Fri, Apr 07, 2006 at 06:11:34PM -0500, Linas Vepstas wrote:
> --- linux-2.6.17-rc1.orig/drivers/net/e100.c
> +++ linux-2.6.17-rc1/drivers/net/e100.c
> + * @state: The current pci conneection state
connection
> +static pci_ers_result_t e100_io_error_detected(struct pci_dev *pdev, pci_channel_state_t state)
> +{
> + struct net_device *netdev = pci_get_drvdata(pdev);
> +
> + /* Similar to calling e100_down(), but avoids adpater I/O. */
adapter
> +static pci_ers_result_t e100_io_slot_reset(struct pci_dev *pdev)
> +{
> + struct net_device *netdev = pci_get_drvdata(pdev);
> + struct nic *nic = netdev_priv(netdev);
> +
> + if (pci_enable_device(pdev)) {
> + printk(KERN_ERR "e100: Cannot re-enable PCI device after reset.\n");
> + return PCI_ERS_RESULT_DISCONNECT;
> + }
> + pci_set_master(pdev);
> +
> + /* Only one device per card can do a reset */
> + if (0 != PCI_FUNC(pdev->devfn))
Wrong order.
^ permalink raw reply
* Re: [PATCH] Unaligned accesses in the ethernet bridge
From: Stephen Hemminger @ 2006-04-07 23:57 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Peter Chubb, linux-kernel, netdev
In-Reply-To: <20060406203708.GA7118@stusta.de>
On Thu, 6 Apr 2006 22:37:08 +0200
Adrian Bunk <bunk@stusta.de> wrote:
> On Thu, Mar 23, 2006 at 01:06:02PM +1100, Peter Chubb wrote:
> >
> > I see lots of
> > kernel unaligned access to 0xa0000001009dbb6f, ip=0xa000000100811591
> > kernel unaligned access to 0xa0000001009dbb6b, ip=0xa0000001008115c1
> > kernel unaligned access to 0xa0000001009dbb6d, ip=0xa0000001008115f1
> > messages in my logs on IA64 when using the ethernet bridge with 2.6.16.
> >
> >
> > Appended is a patch to fix them.
>
>
> I see this patch already made it into 2.6.17-rc1.
>
> It seems to be a candidate for 2.6.16.3, too?
> If yes, please submit it to stable@kernel.org.
The code that caused this was new in 2.6.17
^ permalink raw reply
* Re: [Bridge] [PATCH] fix 802.3ad multicast
From: Stephen Hemminger @ 2006-04-07 23:59 UTC (permalink / raw)
To: Vlad Drukker; +Cc: bridge
In-Reply-To: <1144340106.17145.8.camel@quant>
On Thu, 06 Apr 2006 19:15:06 +0300
Vlad Drukker <vlad@storewiz.com> wrote:
> Hi Stephen,
>
> there was a bug in bridging bonds.
> multicast packets needed for 802.3ad netif_carrier_ok() were dropped.
> attached patch works for me.
>
> Cheers,
> Vlad.
>
>
>
Making a bonding specific hack like this seems wrong. The
port could also be disabled during shutdown (for RCU removal),
and in that case we need to drop the packet.
There must be a better solution.
--
Stephen Hemminger <shemminger@osdl.org>
OSDL http://developer.osdl.org/~shemminger
^ permalink raw reply
* Re: How to know when file data has been flushed into disk?
From: Ric Wheeler @ 2006-04-07 23:54 UTC (permalink / raw)
To: Douglas McNaught; +Cc: Xin Zhao, linux-kernel, linux-fsdevel
In-Reply-To: <87slop1ix2.fsf@suzuka.mcnaught.org>
Douglas McNaught wrote:
>"Xin Zhao" <uszhaoxin@gmail.com> writes:
>
>
>
>>3. Does sys_close() have to be blocked until all data and metadata
>>are committed? If not, sys_close() may give application an illusion
>>that the file is successfully written, which can cause the application
>>to take subsequent operation. However, data flush could be failed. In
>>this case, file system seems to mislead the application. Is this true?
>>If so, any solutions?
>>
>>
>
>The fsync() call is the way to make sure written data has hit the
>disk. close() doesn't guarantee that.
>
>-Doug
>
>
>
You should also make sure, if you care about data recovery after a power
outage, that you have either disabled the write cache on your drives or
have a working write barrier. Without this, fsync will move the data
from the page cache to the disk's write cache where it is up to the
drive firmware to write it back to permanent, safe storage on the disk
platter.
ric
^ permalink raw reply
* Re: [PATCH 2/4] tickless idle cpu: Skip ticks when CPU is idle
From: Paul Mackerras @ 2006-04-07 23:40 UTC (permalink / raw)
To: vatsa; +Cc: sri_vatsa_v, linuxppc-dev
In-Reply-To: <20060407063131.GB22416@in.ibm.com>
Srivatsa Vaddagiri writes:
> diff -puN arch/powerpc/kernel/idle_power4.S~no_idle_hz arch/powerpc/kernel/idle_power4.S
> --- linux-2.6.17-rc1/arch/powerpc/kernel/idle_power4.S~no_idle_hz 2006-04-07 04:14:39.000000000 +0530
> +++ linux-2.6.17-rc1-root/arch/powerpc/kernel/idle_power4.S 2006-04-07 04:14:58.000000000 +0530
> @@ -30,6 +30,9 @@ END_FTR_SECTION_IFCLR(CPU_FTR_CAN_NAP)
> cmpwi 0,r4,0
> beqlr
>
> + mflr r4
> + bl .stop_hz_timer
> + mtlr r4
This won't work - r4 is volatile across function calls, that is,
stop_hz_timer() could change r4 and is not required to save and
restore it.
Paul.
^ permalink raw reply
* Re: [PATCH 17/21] orinoco_pci: use pci_iomap() for resources
From: Francois Romieu @ 2006-04-07 23:38 UTC (permalink / raw)
To: Pavel Roskin
Cc: jgarzik-e+AXbWqSrlAAvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
orinoco-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1144448517.5618.14.camel@dv>
Pavel Roskin <proski-mXXj517/zsQ@public.gmane.org> :
> On Fri, 2006-04-07 at 23:36 +0200, Francois Romieu wrote:
>
> > > @@ -208,8 +205,8 @@ static int orinoco_pci_init_one(struct p
> > > priv = netdev_priv(dev);
> > > card = priv->card;
> > > card->pci_ioaddr = pci_ioaddr;
> > > - dev->mem_start = pci_iorange;
> > > - dev->mem_end = pci_iorange + pci_iolen - 1;
> > > + dev->mem_start = pci_resource_start(pdev, 0);
> > > + dev->mem_end = dev->mem_start + pci_resource_len(pdev, 0) - 1;
> >
> > Is there a reason why dev->mem_{start/end} should not be removed ?
>
> Is there a reason why it should? Is it going to be obsolete?
It is slowly obsoleting for a few years (don't laugh...). It is preferred
to store the relevant address in the private part of the (pci) device.
Moderately recent drivers do not use it at all. However it's fairly common
in the setup code of the (legacy) isa devices.
--
Ueimor
-------------------------------------------------------
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: SDIO Drivers?
From: Pierre Ossman @ 2006-04-07 18:07 UTC (permalink / raw)
To: Ram, linux-kernel
In-Reply-To: <20060407144314.GB21049@flint.arm.linux.org.uk>
Russell King wrote:
>
> I think we would be forced to re-think the existing model - SDIO cards
> seem to be able to support simultaneously both block device and IO.
> Therefore, it would appear that we need the ability to register two
> drivers against the same device.
>
>
On the other hand, they both need to select cards so there is some
overlap in how they grab the bus.
Also, MMC has some kind of register support as well. But I can't say
that I've ever seen anything but MMC memory cards.
Rgds
Pierre
^ permalink raw reply
* Re: RT task scheduling
From: Bill Huey @ 2006-04-07 23:36 UTC (permalink / raw)
To: Darren Hart
Cc: Ingo Molnar, linux-kernel, Thomas Gleixner, Stultz, John,
Peter Williams, Siddha, Suresh B, Nick Piggin, Bill Huey (hui)
In-Reply-To: <200604071537.38044.dvhltc@us.ibm.com>
On Fri, Apr 07, 2006 at 03:37:37PM -0700, Darren Hart wrote:
> OK First off - let's assume we both read eachothers posts before
> commenting :-) I'll try to address some of the areas where we seem to be
> talking passed eachother, please let me know if we agree on the following:
Right, let's try that, please.
> First, when I refer to "System Wide Strict Realtime Priority
> Scheduling" (SWSRPS) I mean it in the absolute sense. There is no "nearly"
> or "almost", it is either SWSRPS or it is not. Everything else is just load
> balancing (relaxed, aggressive, whatever). Since it's my term, I get to
> define it ;-) (and if anyone can come up with a better term, please do -
> SWSRPS is admittedly really lame)
I agree with that terminology. I would have just said "strict priority
across all processors". RTOS systems don't typically have interactive
scheduling policies so that stuff is never even in consideration. In fact,
I'm completely ignoring that in my posts. It doesn't exist in my mental
landscape. I don't care about the load balancer at all, really. RT
scheduling policies are quite difference and serve apps in very different
ways like bandwidth schedulers, etc...
That's why sched-plugin is potentally so important for -rt since the
current crop of -rt scheduling policies are very basic. It's also
important because I don't want somebody's research scheduler included
into the main line either or have to deal churns that force time
consuming prohibitive forward porting of scheduler patches. Different
topic though.
> My first question to the community was where do we want to end up? RT
> scheduling on SMP is relatively new and some RT specs don't even address it
> (http://www.rtsj.org for example, see
> http://www.rtsj.org/specjavadoc/sched_overview-summary.html section
> "Semantics and Requirements Governing the Base Scheduler"). It is my belief
> (and I think you agree?) that because Realtime tasks expect deterministic
> behavior, there should be support for SWSRPS in the kernel.
Not in the main line kernel, but definitely in -rt. The main line kernel
is very far off from an RTOS and really is a place that doesn't respect
this strict priority policy. It's needed in -rt, arguably badly.
> There will be some overhead involved with the SWSRPS implementation, we want
> to minimize that. The current attempts use IPI which is higher overhead than
> would be ideal. You mentioned 20 us, less than 10us would be better (subject
> to hardware limitations of course).
Better to bypass it completely for 0 nanoseconds for some special app cases.
> CPU binding can be used by the application developer to fine tune a complex
> realtime application and avoid some of the overhead involved with SWSRPS.
> When I read your comments it sounds like you are mentioning this as a new
> feature, which as you know it isn't - so can you rephrase what you mean by
> this?
I'm saying stop using a general purpose mechanism for a situation that
isn't general purpose. The high end of RT apps will do all sorts of tricks
to get that extra performance. What I'm saying to you "KERNEL FOLKS" is to
understand the programming issues behind these RT apps. It's not hard.
I'm having trouble getting folks to understand this problem in a
comprehensive manner. It's not one magic technique, it's a series of
them working together for a particular end goal. Let me find some
papers...linuxdevices.com. The mentality for this discussion is
completely off which is why I'm getting frustrated with it.
> I'm not arguing that SWSRPS won't impose some overhead, it definitely will.
> I'd like to see better than 20us as well. My points was without it, we don't
> have determinism, and that's a "bad thing". (We don't have SWSRPS now, I
> understand that, but there is work towards it.).
Yes, I agree, but the only ready for it is the -rt patch set.
> > Yeah, this is not good. There's a serious communication disconnect here and
> > it's not going to be easily bridged. Please read what I said and think
> > about the usage scenarios that I've mentioned more carefully. The -rt patch
> > already has this kind of mechanism whether you're aware of this or not
> > (unless somethings changed since I last looked). It's not as aggressively
> > doing SWSRPS as what you're saying but it serves things nicely for now.
>
> Which mechanism are you referring to? Do you mean rt_overload? or the
> load_balancer maybe? Either way, they do not achieve SWSRPS, but I think the
> rt_overload code is close.
Yeah, rt overload or what ever Ingo calls it. It's "ok" for now. That
means it makes some decisions about distributing the RT load across
which at least allows it to run, but isn't a strictly obeying priority
across processors.
> Well, the rt_overload code doesn't kick in unless one or more run_queues has 2
> or more runnable RT tasks. So it won't be "all the time" - but certainly
> most of the time on any SMP machine running a serious RT application. And we
> agree, it will impose some overhead - but we want to minimize that. Perhaps
> some kind of a runtime switch to enable the rt_overload code would be
> appropriate?
Listen to me, "maximum deterministic latency". Do you understand what that
is ? This is what I'm talking about. RTOS folks care about "maximum deterministic
latency" times, are you ? :)
> I'd prefer not to add another scheduling policy. Although some might argue
> that a runtime switch for rt_overload is effectively the same thing... I
> might even argue that :-)
>
> > I'd much rather see that some kind of SWSRPS go into the main line kernel
> > (RT scheduling is pretty goofy already so folks probaby won't mind SWSRPS
> > replacing it)
>
> I agree, and I think Ingo does to, he mentioned wanting to push rt_overload to
> mainline. Ingo?
It really should go into -rt. It's needed there and that variant of the
kernel can deliver a time granularity that can respect a strict priority.
Please think in terms of -rt. -rt rules.
> > and let thread binding to a CPU restore any loss of latency
> > by bypassing the SWSRPS logic. Are you tracking me ? My concerns here are
> > the latency and overhead of SWSRPS and they are definitely significant.
>
> So if an application binds an RT task to a CPU it needs to be excluded from
> some of the SWSRPS logic in order to reduce overhead? It sounds nice, but
> I'm not sure it's possible unless all the tasks are bound to CPUs. Take a 4
> CPU system. Task A is bound to CPU0. 3 other RT tasks are about to become
> runnable, the SWSRPS logic will still have to account for an RT task on CPU0
> so it doesn't get bumped. What did you have in mind?
Let the RT app dudes determine that. Seperate the general case from the
specific RT app case usage. They are completely different things, don't
mix them up in your head. They have to be address differently. I'm
repeating myself, again and again and again... but I'm ok, what ever works. :)
> > For a default RT oriented kernel, yes, I agree, but that's not what's in
> > -rt and it serves the purpose for now. Looser scheduling constraints aren't
> > really effecting the current crop of RT applications and that's ok since
> > it's a bit fast than a pure SWSRPS solution. For those apps having a more
> > general, looser, case semantic doesn't effect things dramatically and might
> > even be useful.
>
> OK so you said earlier that:
>
> > The counter effect to that is that you're going to effect the general
> > case latency case with SCHED_FIFO via that rescheduling hit "all of
> > the time" with IPIs and stuff. I'm 'ok' with that. In fact, that's
> > what I want.
>
> These two paragraphs appear contradictory to me, it's unclear to me what you
> are trying to accomplish. Would you like to see SWSRPS in the mainline
> kernel or not?
No, but I like to see this in -rt definitely. Main line is just too wacked
out to really utilize this properly. Plus, anybody seriously using SCHED_FIFO
on a 2.6 kernel is going to be using -rt anyways.
> Has this cleared some things up? If not, let me know what else needs
> clarification.
Yes, but you should really work to clarify terminology. Is this better ?
bill
^ 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.