* [ALSA - driver 0002008]: No Sound with snd-hda-intel driver Asus P5VDC-MX
From: bugtrack @ 2006-04-07 22:32 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2008>
======================================================================
Reported By: mborsick
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 2008
Category: PCI - hda-intel
Reproducibility: always
Severity: major
Priority: normal
Status: assigned
Distribution: Redhat/Fedora
Kernel Version: 2.6.16-1.2080 and with Xen
======================================================================
Date Submitted: 04-07-2006 00:43 CEST
Last Modified: 04-08-2006 00:32 CEST
======================================================================
Summary: No Sound with snd-hda-intel driver Asus P5VDC-MX
Description:
Kernel is up-to-date Xen kernel.
Initial install did not recognize the sound on an ASUS P5VDC-MX
motherboard.
Motherboard has southbridge VIA VT8251. CODEC is Realtek ACL653 AC'97 6
channel
Audio. Tried the updated drivers in 002404, but was unsuccessful. Also
tried
drivers on VIA site and Realltek site. The last couple of tries show no
errors
in compiling, make, etc. However, as I am just above novice in
understanding
everything about Linux, this has thrown me for a loop.
======================================================================
----------------------------------------------------------------------
rlrevell - 04-08-06 00:29
----------------------------------------------------------------------
What happens with "aplay file.wav"?
----------------------------------------------------------------------
buboleck - 04-08-06 00:32
----------------------------------------------------------------------
Plays just "Side" stops and after 2-3 sec this:
buboleck ~ # aplay /usr/share/sounds/alsa/Side_Left.wav
Playing WAVE '/usr/share/sounds/alsa/Side_Left.wav' : Signed 16 bit Little
Endian, Rate 48000 Hz, Mono
aplay: pcm_write:1222: write error: Input/output error
Issue History
Date Modified Username Field Change
======================================================================
04-07-06 00:43 mborsick New Issue
04-07-06 00:43 mborsick Distribution => Redhat/Fedora
04-07-06 00:43 mborsick Kernel Version => 2.6.16-1.2080 and
with Xen
04-07-06 01:07 rlrevell Note Added: 0009129
04-07-06 02:13 mborsick Note Added: 0009130
04-07-06 02:35 rlrevell Note Added: 0009131
04-07-06 06:38 mborsick Note Added: 0009135
04-07-06 22:45 buboleck Note Added: 0009156
04-07-06 22:47 buboleck Note Edited: 0009156
04-07-06 22:49 buboleck Note Edited: 0009156
04-07-06 23:06 rlrevell Note Added: 0009157
04-07-06 23:16 buboleck Issue Monitored: buboleck
04-07-06 23:26 buboleck Note Added: 0009158
04-07-06 23:32 rlrevell Note Added: 0009159
04-07-06 23:39 buboleck Note Added: 0009160
04-07-06 23:40 buboleck Note Edited: 0009160
04-07-06 23:43 buboleck Note Edited: 0009160
04-07-06 23:46 buboleck Note Edited: 0009160
04-07-06 23:47 rlrevell Note Added: 0009161
04-07-06 23:52 buboleck Note Added: 0009162
04-08-06 00:02 rlrevell Note Added: 0009163
04-08-06 00:16 buboleck Note Added: 0009164
04-08-06 00:19 buboleck Note Added: 0009165
04-08-06 00:29 rlrevell Note Added: 0009166
04-08-06 00:32 buboleck Note Added: 0009167
======================================================================
-------------------------------------------------------
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
* [U-Boot-Users] PATCH: CPC0_PCI initialization
From: Tolunay Orkun @ 2006-04-07 22:36 UTC (permalink / raw)
To: u-boot
This was discussed in the list a while ago but a patch was not submitted
AFAIK. I've come up with a patch that does not break any existing boards and
naming of the macro is in line with other U-Boot macros for similar settings.
Re: http://sf.net/mailarchive/message.php?msg_id=14093274
Re: http://sf.net/mailarchive/message.php?msg_id=14095552
I am currently involved with bring-up of an 405EP based board. For our
board we do actually need CPC0_PCI[SPE] set to "1" to configure
PerWE*/PCI_INT* as PerWE* so write cycles to our flash could be take place
(even for just CFI detection)
CHANGELOG:
* (ppc405ep) Add support for board configuration of CPC0_PCI register
This is needed to be able to configure PerWE*/PCI_INT* pin as PerWE*
Sign-off-by: Tolunay Orkun <listmember@orkun.us>
diff --git a/cpu/ppc4xx/start.S b/cpu/ppc4xx/start.S
index 948de43..316285a 100644
--- a/cpu/ppc4xx/start.S
+++ b/cpu/ppc4xx/start.S
@@ -1526,7 +1526,8 @@ ppc405ep_init:
mtdcr ebccfgd,r3
#endif
- addi r3,0,CPC0_PCI_HOST_CFG_EN
+#ifndef CFG_CPC0_PCI
+ li r3,CPC0_PCI_HOST_CFG_EN
#ifdef CONFIG_BUBINGA
/*
!-----------------------------------------------------------------------
@@ -1541,6 +1542,9 @@ ppc405ep_init:
beq ..pci_cfg_set /* if not set, then bypass reg write*/
#endif
ori r3,r3,CPC0_PCI_ARBIT_EN
+#else
+ li r3,CFG_CPC0_PCI
+#endif
..pci_cfg_set:
mtdcr CPC0_PCI, r3 /* Enable internal arbiter*/
^ permalink raw reply related
* Re: RT task scheduling
From: Darren Hart @ 2006-04-07 22:37 UTC (permalink / raw)
To: Bill Huey
Cc: Ingo Molnar, linux-kernel, Thomas Gleixner, Stultz, John,
Peter Williams, Siddha, Suresh B, Nick Piggin
In-Reply-To: <20060407210633.GA15971@gnuppy.monkey.org>
On Friday 07 April 2006 14:06, Bill Huey wrote:
> On Fri, Apr 07, 2006 at 07:56:20AM -0700, Darren Hart wrote:
> > The rt-overload mechanism is distinct from load balancing. RT overload
> > attempts to make sure the NR_CPUS highest priority runnable tasks are
> > running on each of the available CPUs. This isn't load balancing, this
> > is "system wide strict realtime priority scheduling" (SWSRPS). This
> > scheduling should take place even if there are 1000 non RT tasks on CPU 0
> > and none on all the others. The load balancer would be responsible for
> > distributing those 1000 non rt tasks to all the CPUs.
>
> I'm quite aware of what you're saying as well as a much of the contents of
> the -rt patch. Please don't assume that I'm not aware of this. The -rt
> patch doesn't do SWSRPS, but it could with more expensive checking. I'm not
> saying anything against it. In fact, I'm clearly for it if you read the
> other posts. Please read my other posts.
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:
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)
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.
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).
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?
>
> > > RT applications tend to want explicit control over the scheduling of
> > > the system with as little interference from the kernel as possible. The
> > > general purpose policies (RT rebalancing) of the Linux kernel can
> > > impede RT apps from getting at CPU time more directly.
> >
> > I don't feel that SWSRPS in anyway interferes with realtime applications.
> > If an application does not explicitly set a cpu affinity, then the
> > kernel should assume the task can run on any CPU and should make SWSRPS
> > decisions accordingly. In fact, in my experience, applications expect
> > this type of scheduling - and don't consider it an interference.
>
> It will with the IPI forcing the rescheduling. I've seen up to 20 usec hits
> for the IPI on p3 hardware. Some RT might like tighter guarantees. That
> extends the maxium deterministic latency by the time that it does IPI an
> along with the response.
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.).
>
> > Actually the SWSRPS is what makes the scheduling deterministic. That
> > determinism comes at a cost, but without it it doesn't exist at all on an
> > SMP machine. So saying it "adds to the maximum deterministic response
> > time" doesn't really make any sense.
>
> Above comments...
>
> > It's my impression (RT folks please pipe up if it's wrong) that if you
> > don't care about priority scheduling (i.e. it's OK for a lower priority
> > task to run while one with a higher priority sits waiting on another
> > queue), then you don't use SCHED_FIFO. So I don't think case 2 is really
> > valid.
>
> 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.
>
> Do you understand this ? The -rt patch has yet to be target for a doing
> strict RT work and your suggestion/patches might be one step closer to that
> goal.
I think I've addressed that above...
> 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.
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?
> I'm not ok with Ingo creating a new scheduling class to get around that
> aggressive rebalancing policy preserving the current SCHED_FIFO behavior in
> the main line. It's a hack IMO and I'll bet you that nobody cared about
> that behavior in the first place.
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?
> 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?
>
> > You've made a lot of references to binding tasks to CPUs (or forbidding
> > them, which is essentially a bind to non-forbidden CPUs). While
> > application developers can certainly take this approach, the linux kernel
> > should schedule realtime tasks globally according to priority in the
> > generic case.
>
> 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?
Has this cleared some things up? If not, let me know what else needs
clarification.
Thanks,
--
Darren Hart
IBM Linux Technology Center
Realtime Linux Team
^ permalink raw reply
* [U-Boot-Users] Re: [DNX#2006040842000022] PATCH: CPC0_PCI initialization
From: DENX Support System @ 2006-04-07 22:40 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040842000022] was created:
<snip>
> This was discussed in the list a while ago but a patch was not submitted
>
> AFAIK. I've come up with a patch that does not break any existing boards
> and
> naming of the macro is in line with other U-Boot macros for similar
> settings.
>
> Re: http://sf.net/mailarchive/message.php?msg_id=14093274
> Re: http://sf.net/mailarchive/message.php?msg_id=14095552
>
> I am currently involved with bring-up of an 405EP based board. For our
> board we do actually need CPC0_PCI[SPE] set to "1" to configure
> PerWE*/PCI_INT* as PerWE* so write cycles to our flash could be take
> place
> (even for just CFI detection)
>
> CHANGELOG:
>
> * (ppc405ep) Add support for board configuration of CPC0_PCI register
> This is needed to be able to configure PerWE*/PCI_INT* pin as PerWE*
>
> Sign-off-by: Tolunay Orkun <listmember@orkun.us>
>
> diff --git a/cpu/ppc4xx/start.S b/cpu/ppc4xx/start.S
> index 948de43..316285a 100644
> --- a/cpu/ppc4xx/start.S
> +++ b/cpu/ppc4xx/start.S
> @@ -1526,7 +1526,8 @@ ppc405ep_init:
> mtdcr ebccfgd,r3
> #endif
>
> - addi r3,0,CPC0_PCI_HOST_CFG_EN
> +#ifndef CFG_CPC0_PCI
> + li r3,CPC0_PCI_HOST_CFG_EN
> #ifdef CONFIG_BUBINGA
> /*
> !-----------------------------------------------------------------------
> @@ -1541,6 +1542,9 @@ ppc405ep_init:
> beq ..pci_cfg_set /* if not set, then bypass reg write*/
> #endif
> ori r3,r3,CPC0_PCI_ARBIT_EN
> +#else
> + li r3,CFG_CPC0_PCI
> +#endif
> ..pci_cfg_set:
> mtdcr CPC0_PCI, r3 /* Enable internal arbiter*/
</snip>
Your U-Boot support team
^ permalink raw reply
* [U-Boot-Users] Re: [DNX#2006040842000022] PATCH: CPC0_PCI init [...]
From: U-Boot patch tracking system @ 2006-04-07 22:40 UTC (permalink / raw)
To: u-boot
Dear Mr. U. Boot,
thank you for your contribution to the U-Boot project.
Your e-mail was registered at our system under the ticket
number [DNX#2006040842000022].
Your U-Boot support team
Powered by OTRS (http://otrs.org/)
^ permalink raw reply
* Re: [PATCH 1/5] generic clocksource updates
From: Thomas Gleixner @ 2006-04-07 22:40 UTC (permalink / raw)
To: Roman Zippel; +Cc: johnstul, Andrew Morton, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0604072239110.32445@scrub.home>
Roman,
On Fri, 2006-04-07 at 22:43 +0200, Roman Zippel wrote:
> > > Currently this field isn't needed and as soon we have a need for it, we
> > > can add proper capability information.
> >
> > Is there a reason, why requirements which are known from existing
> > experience must be discarded to be reintroduced later ?
>
> Then please explain these requirements.
I explained them very clear in my original post:
http://marc.theaimsgroup.com/?l=linux-kernel&m=114431804702870&w=2
> This field shouldn't have been added in first place, I guess I managed to
> confuse John when I talked about handling of continuous vs. tick based
> clocks.
I appreciate your responsibility, but the is_continous field was
introduced on my request because I did not want to rely on (rating > X)
to decide whether I can safely switch to high resolution timer mode or
not.
I really do not understand, why you claim to be the ultimate authority
to decide whats right and wrong in this area. Can you please shed some
light on my agnostic mind with some _real_ explanation why you can claim
to have the authority to decide whats needed and whats not needed ?
"Currently this field isn't needed and as soon we have a need ....".
----------------------------------------------^^^^
I guess http://en.wikipedia.org/wiki/Pluralis_Majestatis is the right
place for me until you start to explain.
> Currently no user should even care about this, it's an
> implementation detail of the clock.
Right. Even if no user cares about this right now, nevertheless
forseeing the requirements of the near future is the finer art of
engineering. Especially if there is existing experience, which shows
that it is necessary.
tglx
^ permalink raw reply
* [ALSA - driver 0002008]: No Sound with snd-hda-intel driver Asus P5VDC-MX
From: bugtrack @ 2006-04-07 22:41 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2008>
======================================================================
Reported By: mborsick
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 2008
Category: PCI - hda-intel
Reproducibility: always
Severity: major
Priority: normal
Status: assigned
Distribution: Redhat/Fedora
Kernel Version: 2.6.16-1.2080 and with Xen
======================================================================
Date Submitted: 04-07-2006 00:43 CEST
Last Modified: 04-08-2006 00:41 CEST
======================================================================
Summary: No Sound with snd-hda-intel driver Asus P5VDC-MX
Description:
Kernel is up-to-date Xen kernel.
Initial install did not recognize the sound on an ASUS P5VDC-MX
motherboard.
Motherboard has southbridge VIA VT8251. CODEC is Realtek ACL653 AC'97 6
channel
Audio. Tried the updated drivers in 002404, but was unsuccessful. Also
tried
drivers on VIA site and Realltek site. The last couple of tries show no
errors
in compiling, make, etc. However, as I am just above novice in
understanding
everything about Linux, this has thrown me for a loop.
======================================================================
----------------------------------------------------------------------
buboleck - 04-08-06 00:32
----------------------------------------------------------------------
Plays just "Side" stops and after 2-3 sec this:
buboleck ~ # aplay /usr/share/sounds/alsa/Side_Left.wav
Playing WAVE '/usr/share/sounds/alsa/Side_Left.wav' : Signed 16 bit Little
Endian, Rate 48000 Hz, Mono
aplay: pcm_write:1222: write error: Input/output error
----------------------------------------------------------------------
rlrevell - 04-08-06 00:41
----------------------------------------------------------------------
I think it's an ACPI IRQ routing bug. Please report to linux-kernel.
Issue History
Date Modified Username Field Change
======================================================================
04-07-06 00:43 mborsick New Issue
04-07-06 00:43 mborsick Distribution => Redhat/Fedora
04-07-06 00:43 mborsick Kernel Version => 2.6.16-1.2080 and
with Xen
04-07-06 01:07 rlrevell Note Added: 0009129
04-07-06 02:13 mborsick Note Added: 0009130
04-07-06 02:35 rlrevell Note Added: 0009131
04-07-06 06:38 mborsick Note Added: 0009135
04-07-06 22:45 buboleck Note Added: 0009156
04-07-06 22:47 buboleck Note Edited: 0009156
04-07-06 22:49 buboleck Note Edited: 0009156
04-07-06 23:06 rlrevell Note Added: 0009157
04-07-06 23:16 buboleck Issue Monitored: buboleck
04-07-06 23:26 buboleck Note Added: 0009158
04-07-06 23:32 rlrevell Note Added: 0009159
04-07-06 23:39 buboleck Note Added: 0009160
04-07-06 23:40 buboleck Note Edited: 0009160
04-07-06 23:43 buboleck Note Edited: 0009160
04-07-06 23:46 buboleck Note Edited: 0009160
04-07-06 23:47 rlrevell Note Added: 0009161
04-07-06 23:52 buboleck Note Added: 0009162
04-08-06 00:02 rlrevell Note Added: 0009163
04-08-06 00:16 buboleck Note Added: 0009164
04-08-06 00:19 buboleck Note Added: 0009165
04-08-06 00:29 rlrevell Note Added: 0009166
04-08-06 00:32 buboleck Note Added: 0009167
04-08-06 00:41 rlrevell Note Added: 0009168
======================================================================
-------------------------------------------------------
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
* Virtex-4 FX12 Mini-Module support
From: Aidan Williams @ 2006-04-07 22:42 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4418EA57.6060308@petalogix.com>
[-- Attachment #1: Type: text/plain, Size: 828 bytes --]
Hi All,
I'm using the UQ powerpc uclinux code on the
Memec Virtex-4 FX12 Mini-Module Development Kit.
I have attached a patch with our modifications:
- switch to set cache policy (OFF, WriteThru, WriteBack)
- switch to enable PPC405 CPU_213 errata workaround
- cosmetic update to cputable
- view ccr0 register in /proc/cpu
The patch is against:
http://www.itee.uq.edu.au/~pml/uclinux_powerpc/linuxppc-2.4-20051021.tgz
The specific modules/chips we're using have a silicon bug,
See the euphemistically named "Solution 13:"
http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=20658
The board boots and runs reliably with the caches OFF.
WriteThru and WriteBack caching cause memory corruption and
this is why we implemented the cache policy switch.
regards
aidan
____
:wq!
[-- Attachment #2: virtex-4-fx12-minimodule.txt --]
[-- Type: plain/text, Size: 23729 bytes --]
^ permalink raw reply
* [ALSA - driver 0002008]: No Sound with snd-hda-intel driver Asus P5VDC-MX
From: bugtrack @ 2006-04-07 22: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=2008>
======================================================================
Reported By: mborsick
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 2008
Category: PCI - hda-intel
Reproducibility: always
Severity: major
Priority: normal
Status: assigned
Distribution: Redhat/Fedora
Kernel Version: 2.6.16-1.2080 and with Xen
======================================================================
Date Submitted: 04-07-2006 00:43 CEST
Last Modified: 04-08-2006 00:42 CEST
======================================================================
Summary: No Sound with snd-hda-intel driver Asus P5VDC-MX
Description:
Kernel is up-to-date Xen kernel.
Initial install did not recognize the sound on an ASUS P5VDC-MX
motherboard.
Motherboard has southbridge VIA VT8251. CODEC is Realtek ACL653 AC'97 6
channel
Audio. Tried the updated drivers in 002404, but was unsuccessful. Also
tried
drivers on VIA site and Realltek site. The last couple of tries show no
errors
in compiling, make, etc. However, as I am just above novice in
understanding
everything about Linux, this has thrown me for a loop.
======================================================================
----------------------------------------------------------------------
rlrevell - 04-08-06 00:41
----------------------------------------------------------------------
I think it's an ACPI IRQ routing bug. Please report to linux-kernel.
----------------------------------------------------------------------
buboleck - 04-08-06 00:42
----------------------------------------------------------------------
ok
Issue History
Date Modified Username Field Change
======================================================================
04-07-06 00:43 mborsick New Issue
04-07-06 00:43 mborsick Distribution => Redhat/Fedora
04-07-06 00:43 mborsick Kernel Version => 2.6.16-1.2080 and
with Xen
04-07-06 01:07 rlrevell Note Added: 0009129
04-07-06 02:13 mborsick Note Added: 0009130
04-07-06 02:35 rlrevell Note Added: 0009131
04-07-06 06:38 mborsick Note Added: 0009135
04-07-06 22:45 buboleck Note Added: 0009156
04-07-06 22:47 buboleck Note Edited: 0009156
04-07-06 22:49 buboleck Note Edited: 0009156
04-07-06 23:06 rlrevell Note Added: 0009157
04-07-06 23:16 buboleck Issue Monitored: buboleck
04-07-06 23:26 buboleck Note Added: 0009158
04-07-06 23:32 rlrevell Note Added: 0009159
04-07-06 23:39 buboleck Note Added: 0009160
04-07-06 23:40 buboleck Note Edited: 0009160
04-07-06 23:43 buboleck Note Edited: 0009160
04-07-06 23:46 buboleck Note Edited: 0009160
04-07-06 23:47 rlrevell Note Added: 0009161
04-07-06 23:52 buboleck Note Added: 0009162
04-08-06 00:02 rlrevell Note Added: 0009163
04-08-06 00:16 buboleck Note Added: 0009164
04-08-06 00:19 buboleck Note Added: 0009165
04-08-06 00:29 rlrevell Note Added: 0009166
04-08-06 00:32 buboleck Note Added: 0009167
04-08-06 00:41 rlrevell Note Added: 0009168
04-08-06 00:42 buboleck Note Added: 0009169
======================================================================
-------------------------------------------------------
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: [PATCH 19/21] orinoco: reduce differences between PCI drivers, create orinoco_pci.h
From: Pavel Roskin @ 2006-04-07 22:43 UTC (permalink / raw)
To: Francois Romieu
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
orinoco-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20060407221041.GC15720-lmTtMILVy1jWQcoT9B9Ug5SCg42XY1Uw0E9HWUfgJXw@public.gmane.org>
On Sat, 2006-04-08 at 00:10 +0200, Francois Romieu wrote:
> > + spin_lock_irqsave(&priv->lock, flags);
>
> Interruptions are enabled. No need to save/restore.
Agreed. I have found a few other places where it's also true. I'll fix
it. Actually, I'm going to change the locking to accommodate some USB
devices, so changes will be more widespread.
> > + netif_device_attach(dev);
> > +
> > + priv->hw_unavailable--;
> > +
> > + if (priv->open && (! priv->hw_unavailable)) {
> > + err = __orinoco_up(dev);
>
> I wonder if it would be enough to issue hermes_set_irqmask() later
> in __orinoco_up() to release this irq disabled section.
Maybe, but I prefer not to touch this code, since it's about to undergo
a much more radical rework.
--
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
* Re: [PATCH rc1-mm] de_thread: fix deadlockable process addition
From: Andrew Morton @ 2006-04-07 22:51 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: ebiederm, linux-kernel
In-Reply-To: <20060407234653.GB11460@oleg>
Oleg Nesterov <oleg@tv-sign.ru> wrote:
>
> - if (likely(p->tasks.prev != LIST_POISON2))
> + if (likely(p->tasks.prev != LIST_POISON2)) {
argh.
c'mon guys, we can't put a dependency on list_head poisoning into generic
code.
We have one in detach_timer() but that's just debugging.
^ permalink raw reply
* Re: [PATCH rc1-mm] de_thread: fix deadlockable process addition
From: Andrew Morton @ 2006-04-07 22:56 UTC (permalink / raw)
To: oleg, ebiederm, linux-kernel
In-Reply-To: <20060407155113.37d6a3b3.akpm@osdl.org>
Andrew Morton <akpm@osdl.org> wrote:
>
> Oleg Nesterov <oleg@tv-sign.ru> wrote:
> >
> > - if (likely(p->tasks.prev != LIST_POISON2))
> > + if (likely(p->tasks.prev != LIST_POISON2)) {
>
> argh.
>
> c'mon guys, we can't put a dependency on list_head poisoning into generic
> code.
>
A suitable fix might be to add a new list_del_poison() (or
list_del_rcu_something()?) and use that everywhere.
But it should use a different poisoning pattern, so we know that the kernel
will still work correctly when someone removes the list_head debugging.
^ permalink raw reply
* Re: RT task scheduling
From: Vernon Mauery @ 2006-04-07 22:58 UTC (permalink / raw)
To: Darren Hart
Cc: Ingo Molnar, linux-kernel, Thomas Gleixner, Stultz, John,
Peter Williams, Siddha, Suresh B, Nick Piggin
In-Reply-To: <200604061535.28952.darren@dvhart.com>
On Thursday 06 April 2006 15:35, you wrote:
> On Thursday 06 April 2006 11:16, you wrote:
> > On Thursday 06 April 2006 00:37, Ingo Molnar wrote:
> > > * Darren Hart <darren@dvhart.com> wrote:
[snip]
> On a related note, I tried observing the rt stats in /proc/stats while
> running sched_football on 2.6.16-rt13. The entire log is nearly a MB so I
> placed it on my website for reference
> (http://www.dvhart.com/~dvhart/sched_football_stats.log), an excerpt
> follows:
>
> ---------------------
>
> The following is the output of sched_football run with 1 thread for offense
> and 1 thread for defense on a 4 way machine. The ball position is
> irrelevant in this case since there are more CPUs than threads (they should
> all be able to run). What is disturbing is that over the entire run, I
> never see RT tasks on every CPU. Even though there are usually 5 total
> runnnable threads, we constantly see groupings of 2 and 3 on the runqueues
> while the others have no running rt tasks.
>
> Looking back, I should have added a sleep to the loop - oops - still, I
> think the data is interesting and suggests a problem with sceduling RT
> tasks across all available CPUs. Does this seem like a valid test to
> everyone? Is there perhaps some explanation as to why this would be
> expected (when the cat process get's to read the proc information or
> something) ?
A better way to do the logging loop would be to write a program that simply
reads the contents of /proc/stat, filters for rt and writes out to your log
and run that at a high realtime priority. That way, the logging task will be
(more) sure to be capturing the data for the other 3 CPUs constantly and get
a clearer picture of what is happening. Naturally, the monitoring task would
interfere with the execution of the rest of the football game, but it should
just hog the single CPU while the rest of the game could play out on the
remaining three. And from the logs below, it seemed to only use two CPUs
part of the time anyway.
Having a constantly running logger would also avoid all the forky-execy the
bash loop has.
--Vernon
> # ./sched_football 1 60
> Starting 1 offense threads at priority 15
> Starting 1 defense threads at priority 30
> Starting referee thread
> Game On (60 seconds)!
> Game Over!
> Final ball position: 20359767
>
> # while true; do clear; cat /proc/stat | grep rt >>
> sched_football_stats.log; done
>
> sched_football_stats.log
> ------------------------------
> rt_overload_schedule: 57768
> rt_overload_wakeup: 157501
> rt_overload_pulled: 13722934
> rt_nr_running(0): 0
> rt_nr_running(1): 0
> rt_nr_running(2): 0
> rt_nr_running(3): 0
> rt_overload: 0
> rt_overload_schedule: 57769
> rt_overload_wakeup: 157514
> rt_overload_pulled: 13722937
> rt_nr_running(0): 0
> rt_nr_running(1): 2
> rt_nr_running(2): 3
> rt_nr_running(3): 0
> rt_overload: 2
> ...
> rt_overload_schedule: 57774
> rt_overload_wakeup: 157738
> rt_overload_pulled: 13722941
> rt_nr_running(0): 0
> rt_nr_running(1): 2
> rt_nr_running(2): 4
> rt_nr_running(3): 0
> rt_overload: 2
> ...
> rt_overload_schedule: 57791
> rt_overload_wakeup: 158650
> rt_overload_pulled: 13722964
> rt_nr_running(0): 0
> rt_nr_running(1): 2
> rt_nr_running(2): 0
> rt_nr_running(3): 3
> rt_overload: 2
> ...
> rt_overload_schedule: 57808
> rt_overload_wakeup: 166924
> rt_overload_pulled: 13722973
> rt_nr_running(0): 0
> rt_nr_running(1): 0
> rt_nr_running(2): 0
> rt_nr_running(3): 2
> rt_overload: 1
> rt_overload_schedule: 57808
> rt_overload_wakeup: 166927
> rt_overload_pulled: 13722973
> rt_nr_running(0): 0
> rt_nr_running(1): 0
> rt_nr_running(2): 0
> rt_nr_running(3): 0
> rt_overload: 0
>
> ---------------------
> -
> 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
* [Qemu-devel] Audio
From: malc @ 2006-04-07 23:00 UTC (permalink / raw)
To: qemu-devel
Hello,
At http://www.boblycat.org/~malc/code/patches/qemu/ you will find
latest (17h_aqemu at the time of this writing) audio patch. Changes
are as follows:
1. Cosmetics (Thanks to Mike Nordell)
2. Fix of several SB16 commands (mainly related to Sierras audblst.drv)
(Thanks to rozojc for rising this topic on users forum)
3. Workaround for FreeBSDs incorrect handling of SNDCTL_DSP_OSPACE ioctl
(Big thanks to Juergen Lock for lending me a shell on his box to debug
the issue)
--
mailto:malc@pulsesoft.com
^ permalink raw reply
* [PATCH] FIx mprotect() syscall for MIPS32 w/36-bit physical address support
From: Sergei Shtylyov @ 2006-04-07 23:09 UTC (permalink / raw)
To: linux-mips; +Cc: Clem Taylor, Jordan Crouse, Manish Lachwani
In-Reply-To: <20060202165436.GB17352@linux-mips.org>
[-- Attachment #1: Type: text/plain, Size: 248 bytes --]
Hello.
Fix mprotect() syscall for MIPS32 CPUs with 36-bit physical address
support: pte_modify() macro didn't clear the hardware page protection bits
before modifying...
WBR, Sergei
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
[-- Attachment #2: MIPS32-36bit-phys-addr-mprotect-fix.patch --]
[-- Type: text/plain, Size: 593 bytes --]
diff --git a/include/asm-mips/pgtable.h b/include/asm-mips/pgtable.h
index 702a28f..80b3605 100644
--- a/include/asm-mips/pgtable.h
+++ b/include/asm-mips/pgtable.h
@@ -335,8 +335,9 @@ static inline pgprot_t pgprot_noncached(
#if defined(CONFIG_64BIT_PHYS_ADDR) && defined(CONFIG_CPU_MIPS32_R1)
static inline pte_t pte_modify(pte_t pte, pgprot_t newprot)
{
- pte.pte_low &= _PAGE_CHG_MASK;
- pte.pte_low |= pgprot_val(newprot);
+ pte.pte_low &= _PAGE_CHG_MASK;
+ pte.pte_high &= ~0x3f;
+ pte.pte_low |= pgprot_val(newprot);
pte.pte_high |= pgprot_val(newprot) & 0x3f;
return pte;
}
^ permalink raw reply related
* Re: [PATCH 1/4] tickless idle cpu - Allow any CPU to update jiffies
From: Paul Mackerras @ 2006-04-07 23:04 UTC (permalink / raw)
To: vatsa; +Cc: sri_vatsa_v, linuxppc-dev
In-Reply-To: <20060407063044.GA22416@in.ibm.com>
Srivatsa Vaddagiri writes:
> Currently, only boot CPU calls do_timer to update jiffies. This prevents
> idle boot CPU from skipping ticks. Patch below, against 2.6.17-rc1-mm1,
> allows jiffies to be updated from any CPU.
We have to be very careful here. The code that keeps xtime and
gettimeofday in sync relies on xtime being incremented as close as
possible in time to when the timebase passes specific values. Since
we currently stagger the timer interrupts for the cpus throughout a
jiffy, having cpus other than the boot cpus calling do_timer will
break this and introduce inaccuracies. There are also implications
for the stolen time accounting on shared-processor LPAR systems.
I think we need to remove the staggering, thus having all cpus take
their timer interrupt at the same time. That way, any of them can
call do_timer. However we then have to be much more careful about
possible contention, e.g. on xtime_lock. Your patch has every cpu
taking xtime_lock for writing rather than just the boot cpu. I'd like
to see if there is some way to avoid that (while still having just one
cpu call do_timer, of course).
Regards,
Paul.
^ permalink raw reply
* [lm-sensors] nForce 430 SMBus
From: Mark Rages @ 2006-04-07 23:07 UTC (permalink / raw)
To: lm-sensors
Hi,
I've got an "Asus A8N-VM CSM nForce 430/GeForce 6150" motherboard.
I want to access the SMBus for hardware hacking purposes.
I can read the sensors through the w83627ehf SuperIO, through the
i2c-isa interface.
But I get nothing from eeprom/decode-dimms.pl ("Number of SDRAM DIMMs
detected and decoded: 0").
I'm guessing I need to get this interface working:
00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a2)
Subsystem: nVidia Corporation: Unknown device cb84
This has PCI ID 10de:0264.
I tried hacking adding this ID to the nforce2 driver, but I still
can't get anything from decode-dimms.pl.
What do I need to do?
Regards,
Mark
markrages at gmail
--
You think that it is a secret, but it never has been one.
- fortune cookie
^ permalink raw reply
* Re: [PATCH 16/21] orinoco_pci: disable device and free IRQ when suspending
From: Francois Romieu @ 2006-04-07 23:08 UTC (permalink / raw)
To: Pavel Roskin
Cc: torvalds-3NddpPZAyC0, netdev-u79uwXL29TY76Z2rM5mHXA,
orinoco-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1144447965.5618.8.camel@dv>
Pavel Roskin <proski-mXXj517/zsQ@public.gmane.org> :
> On Fri, 2006-04-07 at 23:24 +0200, Francois Romieu wrote:
> > Pavel Roskin <proski-mXXj517/zsQ@public.gmane.org> :
> > [...]
> > > diff --git a/drivers/net/wireless/orinoco_pci.c b/drivers/net/wireless/orinoco_pci.c
> > > index 5362c21..e57e92b 100644
> > > --- a/drivers/net/wireless/orinoco_pci.c
> > > +++ b/drivers/net/wireless/orinoco_pci.c
> > > @@ -304,7 +304,9 @@ static int orinoco_pci_suspend(struct pc
> > >
> > > orinoco_unlock(priv, &flags);
> > >
> > > + free_irq(pdev->irq, dev);
> > > pci_save_state(pdev);
> > > + pci_disable_device(pdev);
> > > pci_set_power_state(pdev, PCI_D3hot);
> > >
> > > return 0;
> >
> > /me stares at the thread behind http://lkml.org/lkml/2005/7/30/143
> >
> > Imho {free/request}_irq during suspend/resume deserves some
> > explanation.
>
> I followed examples from other drivers.
Yep, that's what I do too.
tg3/sky2/skge do not free_irq() in the suspend path. They disable the
device.
> The thread in question deals with the patch where pci_disable_device()
> precedes free_irq(). Besides, bridges may need special care because
> they pass interrupts from other devices.
> I also followed the kernel documentation (Documentation/power/pci.txt),
> which says that the driver should free the IRQ on suspend.
>
> If you can suggest an alternative approach, please do so. I don't see
> what I can do differently.
Disable the device and avoid free_irq/request_irq altogether ?
The documentation does not require more:
[...]
A driver uses this function to actually transition the device into a low power
state. This should include disabling I/O, IRQs, and bus-mastering, as well as
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
physically transitioning the device to a lower power state; it may also include
calls to pci_enable_wake().
-> free_irq() looks like the heavyweight option.
request_irq() can fail. The reference implementation does not care
(who does ?). Imho it hints that the driver writer should not take
the documentation _too_ literally when it suggests that "disabling
irq == free_irq".
--
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: Oprofile on sibyte 2.4.18 kernel
From: Ralf Baechle @ 2006-04-07 23:20 UTC (permalink / raw)
To: Shanthi Kiran Pendyala (skiranp); +Cc: linux-mips
In-Reply-To: <5547014632ED654F971D7E1E0C2E0C3E018DAFBB@xmb-sjc-215.amer.cisco.com>
On Fri, Apr 07, 2006 at 01:38:54PM -0700, Shanthi Kiran Pendyala (skiranp) wrote:
> Did anyone port oprofile to 2.4.x kernel on sibyte ?.
>
> Looking over the mailing list threads it looks like it has been given up
> as a lost cause.
Correct. So if at all you would have to rip oprofile from the 2.6 kernel
and bolt that code back into the old kernel which would seem doable. The
MIPS bits certainly don't rely on much 2.6 infrastructure.
> But business reasons require us to work with 2.4.18 kernel for the next
> 9-12 months and We really would like explore a port.
You at least want a newer 2.4 variant; 2.4.18 is now over 4 years old, is
from before the point where 2.4 really became stable and contains a number
of security revelant holes.
> Or are there other tools that I can use ?
Gprof, perfex 2 - not sure if the MIPS port of it was ever published though.
But nothing really that provides the same kind of information as oprofile.
Ralf
^ permalink raw reply
* Re: [PATCH] PCI Error Recovery: e100 network device driver
From: Linas Vepstas @ 2006-04-07 23:11 UTC (permalink / raw)
To: Greg KH
Cc: Jeff Garzik, netdev, linux-pci, linux-kernel, linuxppc-dev,
john.ronciak, jesse.brandeburg, jeffrey.t.kirsher
In-Reply-To: <20060406224643.GA6278@kroah.com>
On Thu, Apr 06, 2006 at 03:46:43PM -0700, Greg KH wrote:
> On Thu, Apr 06, 2006 at 05:24:00PM -0500, Linas Vepstas wrote:
> > + if(pci_enable_device(pdev)) {
>
> Add a space after "if" and before "(" please.
I guess I'm immune to learning from experience. :-/
Here's a new improved patch.
--linas
[PATCH] PCI Error Recovery: e100 network device driver
Various PCI bus errors can be signaled by newer PCI controllers. This
patch adds the PCI error recovery callbacks to the intel ethernet e100
device driver. The patch has been tested, and appears to work well.
Signed-off-by: Linas Vepstas <linas@linas.org>
Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
----
drivers/net/e100.c | 75 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 75 insertions(+)
Index: linux-2.6.17-rc1/drivers/net/e100.c
===================================================================
--- linux-2.6.17-rc1.orig/drivers/net/e100.c 2006-04-07 16:21:46.000000000 -0500
+++ linux-2.6.17-rc1/drivers/net/e100.c 2006-04-07 18:10:52.411266545 -0500
@@ -2780,6 +2780,80 @@ static void e100_shutdown(struct pci_dev
DPRINTK(PROBE,ERR, "Error enabling wake\n");
}
+/* ------------------ PCI Error Recovery infrastructure -------------- */
+/**
+ * e100_io_error_detected - called when PCI error is detected.
+ * @pdev: Pointer to PCI device
+ * @state: The current pci conneection state
+ */
+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. */
+ netdev->stop(netdev);
+
+ /* Detach; put netif into state similar to hotplug unplug. */
+ netif_poll_enable(netdev);
+ netif_device_detach(netdev);
+
+ /* Request a slot reset. */
+ return PCI_ERS_RESULT_NEED_RESET;
+}
+
+/**
+ * e100_io_slot_reset - called after the pci bus has been reset.
+ * @pdev: Pointer to PCI device
+ *
+ * Restart the card from scratch.
+ */
+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))
+ return PCI_ERS_RESULT_RECOVERED;
+ e100_hw_reset(nic);
+ e100_phy_init(nic);
+
+ return PCI_ERS_RESULT_RECOVERED;
+}
+
+/**
+ * e100_io_resume - resume normal operations
+ * @pdev: Pointer to PCI device
+ *
+ * Resume normal operations after an error recovery
+ * sequence has been completed.
+ */
+static void e100_io_resume(struct pci_dev *pdev)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct nic *nic = netdev_priv(netdev);
+
+ /* ack any pending wake events, disable PME */
+ pci_enable_wake(pdev, 0, 0);
+
+ netif_device_attach(netdev);
+ if (netif_running(netdev)) {
+ e100_open(netdev);
+ mod_timer(&nic->watchdog, jiffies);
+ }
+}
+
+static struct pci_error_handlers e100_err_handler = {
+ .error_detected = e100_io_error_detected,
+ .slot_reset = e100_io_slot_reset,
+ .resume = e100_io_resume,
+};
static struct pci_driver e100_driver = {
.name = DRV_NAME,
@@ -2791,6 +2865,7 @@ static struct pci_driver e100_driver = {
.resume = e100_resume,
#endif
.shutdown = e100_shutdown,
+ .err_handler = &e100_err_handler,
};
static int __init e100_init_module(void)
^ permalink raw reply
* Re: [PATCH] PCI Error Recovery: e100 network device driver
From: Linas Vepstas @ 2006-04-07 23:11 UTC (permalink / raw)
To: Greg KH
Cc: netdev, linux-kernel, jesse.brandeburg, linuxppc-dev,
john.ronciak, jeffrey.t.kirsher, linux-pci, Jeff Garzik
In-Reply-To: <20060406224643.GA6278@kroah.com>
On Thu, Apr 06, 2006 at 03:46:43PM -0700, Greg KH wrote:
> On Thu, Apr 06, 2006 at 05:24:00PM -0500, Linas Vepstas wrote:
> > + if(pci_enable_device(pdev)) {
>
> Add a space after "if" and before "(" please.
I guess I'm immune to learning from experience. :-/
Here's a new improved patch.
--linas
[PATCH] PCI Error Recovery: e100 network device driver
Various PCI bus errors can be signaled by newer PCI controllers. This
patch adds the PCI error recovery callbacks to the intel ethernet e100
device driver. The patch has been tested, and appears to work well.
Signed-off-by: Linas Vepstas <linas@linas.org>
Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
----
drivers/net/e100.c | 75 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 75 insertions(+)
Index: linux-2.6.17-rc1/drivers/net/e100.c
===================================================================
--- linux-2.6.17-rc1.orig/drivers/net/e100.c 2006-04-07 16:21:46.000000000 -0500
+++ linux-2.6.17-rc1/drivers/net/e100.c 2006-04-07 18:10:52.411266545 -0500
@@ -2780,6 +2780,80 @@ static void e100_shutdown(struct pci_dev
DPRINTK(PROBE,ERR, "Error enabling wake\n");
}
+/* ------------------ PCI Error Recovery infrastructure -------------- */
+/**
+ * e100_io_error_detected - called when PCI error is detected.
+ * @pdev: Pointer to PCI device
+ * @state: The current pci conneection state
+ */
+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. */
+ netdev->stop(netdev);
+
+ /* Detach; put netif into state similar to hotplug unplug. */
+ netif_poll_enable(netdev);
+ netif_device_detach(netdev);
+
+ /* Request a slot reset. */
+ return PCI_ERS_RESULT_NEED_RESET;
+}
+
+/**
+ * e100_io_slot_reset - called after the pci bus has been reset.
+ * @pdev: Pointer to PCI device
+ *
+ * Restart the card from scratch.
+ */
+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))
+ return PCI_ERS_RESULT_RECOVERED;
+ e100_hw_reset(nic);
+ e100_phy_init(nic);
+
+ return PCI_ERS_RESULT_RECOVERED;
+}
+
+/**
+ * e100_io_resume - resume normal operations
+ * @pdev: Pointer to PCI device
+ *
+ * Resume normal operations after an error recovery
+ * sequence has been completed.
+ */
+static void e100_io_resume(struct pci_dev *pdev)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct nic *nic = netdev_priv(netdev);
+
+ /* ack any pending wake events, disable PME */
+ pci_enable_wake(pdev, 0, 0);
+
+ netif_device_attach(netdev);
+ if (netif_running(netdev)) {
+ e100_open(netdev);
+ mod_timer(&nic->watchdog, jiffies);
+ }
+}
+
+static struct pci_error_handlers e100_err_handler = {
+ .error_detected = e100_io_error_detected,
+ .slot_reset = e100_io_slot_reset,
+ .resume = e100_io_resume,
+};
static struct pci_driver e100_driver = {
.name = DRV_NAME,
@@ -2791,6 +2865,7 @@ static struct pci_driver e100_driver = {
.resume = e100_resume,
#endif
.shutdown = e100_shutdown,
+ .err_handler = &e100_err_handler,
};
static int __init e100_init_module(void)
^ permalink raw reply
* [lm-sensors] hwmon/pc87360 as a platform driver
From: Jim Cromie @ 2006-04-07 23:17 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <4436BE3B.7090306@gmail.com>
Juerg Haefliger wrote:
> Jim,
>
> I had a similar problem when I converted the vt1211 to a platform
> driver. Turned out to be a bug in lm_sensors which required some I2C
> modules to function properly. Try either loading an I2C module or use
> the CVS version of lm_sensors.
>
> Check the following thread:
> http://lists.lm-sensors.org/pipermail/lm-sensors/2006-February/015358.html
>
> ...juerg
>
>
> On 4/7/06, *Jim Cromie* <jim.cromie at gmail.com
> <mailto:jim.cromie at gmail.com>> wrote:
>
> hi folks,
>
> Ive just made a rough pass thru pc87360, and have converted it
> to a non-working, but non-crashing platform_driver that does
> at least a little of what it should:
>
thanks!
but alas, error-driven cut-paste will only get me so far.
More to the point, I have code similar to yours and Jean's
data->class_dev = hwmon_device_register(&pdev->dev);
Guess I'll have to roll up my sleeves and actually figure it out.
BTW, I glanced at your patch, saw you're :
using sensor_attribute_2's,
that you're using the .nr field to switch the 'functionality'
of your combined-functionality callbacks.
thats all quite similar to what Im doing in these:
http://lists.lm-sensors.org/pipermail/lm-sensors/2006-March/015702.html
http://lists.lm-sensors.org/pipermail/lm-sensors/2006-March/015703.html
The SHOW_SET_*_* constants are just a bit off-putting at first read,
but I know what you mean, and I dont have a better idea.
maybe SHOW_SETTNG_*_* ?
or SHOW_CURR_*_*, thats confuse-able with the current reading
you can improve your printks :
s/(printk\(KERN_DEBUG)/dev_dbg\(&pdev->dev/;
s/(printk\(KERN_ERR)/dev_err\(&pdev->dev/
s/(printk\(KERN_INFO)/dev_info\(&pdev->dev/
at least where pdev has already been initd
Ill try to read thru the enire patch this weekend sometime.
thanks
jimc
^ permalink raw reply
* get_xip_page
From: Jared Hulbert @ 2006-04-07 23:23 UTC (permalink / raw)
To: linux-mm
What is the "create" parameter in the get_xip_page function used for?
If create = 1, does it actually create a sector and return a pointer
to it? Under what situation is create set to 1 while calling
get_xip_page? Is there any difference for a RO file system? Is it used
for a COW?
--
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
* domU not rebooting
From: rhce admin @ 2006-04-07 23:33 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 155 bytes --]
Is there a patch that can be applied to the current stable Xen version (
3.0.1) that will fix the bug that causes domU's to not come back from
reboots?
[-- Attachment #1.2: Type: text/html, Size: 156 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
* 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.