* [ALSA - driver 0002008]: No Sound with snd-hda-intel driver Asus P5VDC-MX
From: bugtrack @ 2006-04-07 22:02 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:02 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-07-06 23:52
----------------------------------------------------------------------
No it's not working. It plays something just once for about one sec and
stops. If I start again nothing comes out.
----------------------------------------------------------------------
rlrevell - 04-08-06 00:02
----------------------------------------------------------------------
Does the interrupt count for the soundcard increase in /proc/interrupts
when playing sound?
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
======================================================================
-------------------------------------------------------
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: [LARTC] leaky bucket on bursty multicast
From: Andy Furniss @ 2006-04-07 22:03 UTC (permalink / raw)
To: lartc
In-Reply-To: <ac81ed350602150442l2968563cm306cfea79f2c1138@mail.gmail.com>
Oivind wrote:
> On 3/1/06, Andy Furniss <andy.furniss@dsl.pipex.com> wrote:
>
>>Oivind wrote:
>>
>>>Hi all,
>>>I have an average 2mbit multicast stream that once in a while bursts
>>>high (up to 20mbit/s) in short periods (about 200ms). Could anyone
>>>please help me with directions using tc for configuing leaky bucket
>>>shaping to this stream? I have a 5mbit/s ceiling.
>>>
>>>My system is running gentoo linux 2.6.14, and I have compiled in all
>>>QoS modules.
>>
>>I suppose it depends what you want to do with the burst ie. propogate it
>>,smooth it without loss or drop packets to maintain a rate.
>
>
> I would like to smooth the bursts out at the ceiling bandwidth without
> any packet drops (unless an unacceptable lengthy burst of course).
Sorry for not replying earlier, I lost this one.
What you want should be OK with htb/tbf/hfsc ratelimiting at 5meg - just
choose a leaf queue/buffer length that can absorb the burst.
Andy.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* [ANNOUNCE] Stacked GIT 0.9
From: Catalin Marinas @ 2006-04-07 22:05 UTC (permalink / raw)
To: git
Stacked GIT 0.9 release is available from http://www.procode.org/stgit/
StGIT is a Python application providing similar functionality to Quilt
(i.e. pushing/popping patches to/from a stack) on top of GIT. These
operations are performed using GIT commands and the patches are stored
as GIT commit objects, allowing easy merging of the StGIT patches into
other repositories using standard GIT functionality.
The main features in this release:
# Faster three-way merge by using 'git-read-tree --aggressive' and
dealing with conflicts internally (gitmergeonefile.py removed)
# StGIT repositories are now 'git prune'-safe
# 'show' command for displaying a given patch
# 'uncommit' command for reversing the effects of 'commit'
# '--series' option added to the 'import' command
# '--merged' option added to the 'push' and 'pull' commands to check
for patches merged upstream
# '--undo' option added to 'refresh'
# Patch refreshing can be done for individual files only
# '--stdout' option added to 'export'
# '--mbox' option added to 'mail'
# 'smtpdelay' configuration option for delays between messages sending
# $PAGER or the 'pager' configuration option used for the 'show' and
'diff' commands
# '--force' option removed from the 'new' command
# Bug fixes
Acknowledgements (generated with 'git shortlog'):
Catalin Marinas:
Fix the clone command failure
Fix the 'status --reset' for individual files
Remove the --force option for new
Allow patch refreshing for some files only
Use the GIT-specific environment as default
Check whether the file exists in the fold command
Add prune-safety to StGIT
Allow tag objects to be passed on the command line
Add --stdout option to export
Add --mbox option to the 'mail' command
Fix the e-mail address escaping
Fix the reset command to set HEAD to a proper id
Allow stg to be loaded in pydb and not run main()
Print a shorter usage message with the --help option
Add a merged upstream test for pull and push
Add --series to import
Cache the base_dir value for subsequent calls
Pass the --aggressive flag to git-read-tree
gitmergeonefile.py should use git.get_base_dir()
Deal with merge conflicts directly
Add the --patch option to export
Add the --strip option to import
Fix the patch name stripping in import
Update the TODO file
The gitmergeonefile config section is deprecated
Add the "smtpdelay" config option
Create stgit/basedir.py for determining the .git directory
Remove the checking for the default configuration values
Add extra headers to the e-mail messages
Add the '--undo' option to 'refresh'
Add a 'show' command
Remove the basedir exception throwing
Use a pager for diff and show commands
Use 'git-*' instead of 'git *'
Release 0.9
Chuck Lever:
"stg pull" says "popping all patches" even when it doesn't
Use a separate directory for patches under each branch subdir
Add an option to "stg branch" to convert the internal format
Karl Hasselström:
[PATCH 2/2] Add 'stg uncommit' command
Use --refid option even when sending a cover mail
Change the signature start string to "-- \n"
Update .git/refs/heads/base after patch deletion
Kirill Smelkov:
[trivial] fix spelling typos
Paolo 'Blaisorblade' Giarrusso:
Stgit - gitmergeonefile.py: handle removal vs. changes
Pass --directory to git-ls-files for stg status
Pavel Roskin:
stgit: typo fixes
Make tutorial a valid asciidoc article.
stg export: check if there are any patches to export
Treat "stg --help cmd" and "stg help cmd" like "stg cmd
Improve "stg uncommit" help text.
Sam Vilain:
common: parse 'email (name)' correctly
--
Catalin
^ permalink raw reply
* patches for fsample/850
From: Brian Swetland @ 2006-04-07 22:06 UTC (permalink / raw)
To: linux-omap-open-source
[-- Attachment #1: Type: text/plain, Size: 582 bytes --]
Attached is a set of patches to start support for the omap850
and specifically the f-sample development board from TI.
Features:
- machine ID 970 as registered with the arm machine registery:
http://www.arm.linux.org.uk/developer/machines/?action=list&id=970
- initial support for the FPGA on fsample
- adjustment to the 'p2' lcd driver so that it correctly initializes
the display on fsample (which involves using the FPGA interface)
- some adjustment to clock.h/clock.c to avoid disabling the baseband
side of the world on 730/850 as a sideeffect of other clock changes
[-- Attachment #2: omap-fsample.patch --]
[-- Type: text/plain, Size: 13221 bytes --]
--- linux-omap-2.6/arch/arm/mach-omap1/Kconfig 2006-04-05 10:33:21.000000000 -0700
+++ linux-omap-fsample/arch/arm/mach-omap1/Kconfig 2006-04-06 13:15:33.000000000 -0700
@@ -63,6 +63,13 @@
Support for TI OMAP 730 Perseus2 board. Say Y here if you have such
a board.
+config MACH_OMAP_FSAMPLE
+ bool "TI F-Sample"
+ depends on ARCH_OMAP1 && ARCH_OMAP730
+ help
+ Support for TI OMAP 850 F-Sample board. Say Y here if you have such
+ a board.
+
config MACH_VOICEBLUE
bool "Voiceblue"
depends on ARCH_OMAP1 && ARCH_OMAP15XX
--- linux-omap-2.6/arch/arm/mach-omap1/Makefile 2006-04-05 10:33:21.000000000 -0700
+++ linux-omap-fsample/arch/arm/mach-omap1/Makefile 2006-04-06 13:15:34.000000000 -0700
@@ -17,6 +17,7 @@
obj-$(CONFIG_MACH_OMAP_INNOVATOR) += board-innovator.o
obj-$(CONFIG_MACH_OMAP_GENERIC) += board-generic.o
obj-$(CONFIG_MACH_OMAP_PERSEUS2) += board-perseus2.o
+obj-$(CONFIG_MACH_OMAP_FSAMPLE) += board-fsample.o
obj-$(CONFIG_MACH_OMAP_OSK) += board-osk.o
obj-$(CONFIG_MACH_OMAP_H3) += board-h3.o
obj-$(CONFIG_MACH_VOICEBLUE) += board-voiceblue.o
--- linux-omap-2.6/arch/arm/mach-omap1/clock.c 2006-02-27 12:14:41.000000000 -0800
+++ linux-omap-fsample/arch/arm/mach-omap1/clock.c 2006-03-01 14:25:18.000000000 -0800
@@ -761,7 +761,7 @@
ck_dpll1.rate / 1000000, (ck_dpll1.rate / 100000) % 10,
arm_ck.rate / 1000000, (arm_ck.rate / 100000) % 10);
-#ifdef CONFIG_MACH_OMAP_PERSEUS2
+#if defined(CONFIG_MACH_OMAP_PERSEUS2) || defined(CONFIG_MACH_OMAP_FSAMPLE)
/* Select slicer output as OMAP input clock */
omap_writew(omap_readw(OMAP730_PCC_UPLD_CTRL) & ~0x1, OMAP730_PCC_UPLD_CTRL);
#endif
--- linux-omap-2.6/arch/arm/mach-omap1/clock.h 2006-04-05 10:33:20.000000000 -0700
+++ linux-omap-fsample/arch/arm/mach-omap1/clock.h 2006-04-06 13:15:34.000000000 -0700
@@ -101,44 +101,50 @@
/*-------------------------------------------------------------------------
* Omap1 MPU rate table
*-------------------------------------------------------------------------*/
+#if defined(CONFIG_ARCH_OMAP730)
+ #define CKCTL_RESERVED_1_MASK (0x2000)
+#else
+ #define CKCTL_RESERVED_1_MASK (0x0000)
+#endif
+
static struct mpu_rate rate_table[] = {
/* MPU MHz, xtal MHz, dpll1 MHz, CKCTL, DPLL_CTL
* NOTE: Comment order here is different from bits in CKCTL value:
* armdiv, dspdiv, dspmmu, tcdiv, perdiv, lcddiv
*/
#if defined(CONFIG_OMAP_ARM_216MHZ)
- { 216000000, 12000000, 216000000, 0x050d, 0x2910 }, /* 1/1/2/2/2/8 */
+ { 216000000, 12000000, 216000000, CKCTL_RESERVED_1_MASK | 0x050d, 0x2910 }, /* 1/1/2/2/2/8 */
#endif
#if defined(CONFIG_OMAP_ARM_195MHZ)
- { 195000000, 13000000, 195000000, 0x050e, 0x2790 }, /* 1/1/2/2/4/8 */
+ { 195000000, 13000000, 195000000, CKCTL_RESERVED_1_MASK | 0x050e, 0x2790 }, /* 1/1/2/2/4/8 */
#endif
#if defined(CONFIG_OMAP_ARM_192MHZ)
- { 192000000, 19200000, 192000000, 0x050f, 0x2510 }, /* 1/1/2/2/8/8 */
- { 192000000, 12000000, 192000000, 0x050f, 0x2810 }, /* 1/1/2/2/8/8 */
- { 96000000, 12000000, 192000000, 0x055f, 0x2810 }, /* 2/2/2/2/8/8 */
- { 48000000, 12000000, 192000000, 0x0baf, 0x2810 }, /* 4/4/4/8/8/8 */
- { 24000000, 12000000, 192000000, 0x0fff, 0x2810 }, /* 8/8/8/8/8/8 */
+ { 192000000, 19200000, 192000000, CKCTL_RESERVED_1_MASK | 0x050f, 0x2510 }, /* 1/1/2/2/8/8 */
+ { 192000000, 12000000, 192000000, CKCTL_RESERVED_1_MASK | 0x050f, 0x2810 }, /* 1/1/2/2/8/8 */
+ { 96000000, 12000000, 192000000, CKCTL_RESERVED_1_MASK | 0x055f, 0x2810 }, /* 2/2/2/2/8/8 */
+ { 48000000, 12000000, 192000000, CKCTL_RESERVED_1_MASK | 0x0baf, 0x2810 }, /* 4/4/4/8/8/8 */
+ { 24000000, 12000000, 192000000, CKCTL_RESERVED_1_MASK | 0x0fff, 0x2810 }, /* 8/8/8/8/8/8 */
#endif
#if defined(CONFIG_OMAP_ARM_182MHZ)
- { 182000000, 13000000, 182000000, 0x050e, 0x2710 }, /* 1/1/2/2/4/8 */
+ { 182000000, 13000000, 182000000, CKCTL_RESERVED_1_MASK | 0x050e, 0x2710 }, /* 1/1/2/2/4/8 */
#endif
#if defined(CONFIG_OMAP_ARM_168MHZ)
- { 168000000, 12000000, 168000000, 0x010f, 0x2710 }, /* 1/1/1/2/8/8 */
+ { 168000000, 12000000, 168000000, CKCTL_RESERVED_1_MASK | 0x010f, 0x2710 }, /* 1/1/1/2/8/8 */
#endif
#if defined(CONFIG_OMAP_ARM_150MHZ)
- { 150000000, 12000000, 150000000, 0x010a, 0x2cb0 }, /* 1/1/1/2/4/4 */
+ { 150000000, 12000000, 150000000, CKCTL_RESERVED_1_MASK | 0x010a, 0x2cb0 }, /* 1/1/1/2/4/4 */
#endif
#if defined(CONFIG_OMAP_ARM_120MHZ)
- { 120000000, 12000000, 120000000, 0x010a, 0x2510 }, /* 1/1/1/2/4/4 */
+ { 120000000, 12000000, 120000000, CKCTL_RESERVED_1_MASK | 0x010a, 0x2510 }, /* 1/1/1/2/4/4 */
#endif
#if defined(CONFIG_OMAP_ARM_96MHZ)
- { 96000000, 12000000, 96000000, 0x0005, 0x2410 }, /* 1/1/1/1/2/2 */
+ { 96000000, 12000000, 96000000, CKCTL_RESERVED_1_MASK | 0x0005, 0x2410 }, /* 1/1/1/1/2/2 */
#endif
#if defined(CONFIG_OMAP_ARM_60MHZ)
- { 60000000, 12000000, 60000000, 0x0005, 0x2290 }, /* 1/1/1/1/2/2 */
+ { 60000000, 12000000, 60000000, CKCTL_RESERVED_1_MASK | 0x0005, 0x2290 }, /* 1/1/1/1/2/2 */
#endif
#if defined(CONFIG_OMAP_ARM_30MHZ)
- { 30000000, 12000000, 60000000, 0x0555, 0x2290 }, /* 2/2/2/2/2/2 */
+ { 30000000, 12000000, 60000000, CKCTL_RESERVED_1_MASK | 0x0555, 0x2290 }, /* 2/2/2/2/2/2 */
#endif
{ 0, 0, 0, 0, 0 },
};
--- linux-omap-2.6/arch/arm/mach-omap1/pm.c 2006-04-05 10:33:20.000000000 -0700
+++ linux-omap-fsample/arch/arm/mach-omap1/pm.c 2006-04-06 13:15:34.000000000 -0700
@@ -326,8 +326,10 @@
/* stop DSP */
omap_writew(omap_readw(ARM_RSTCT1) & ~(1 << DSP_EN), ARM_RSTCT1);
+#if !defined(CONFIG_ARCH_OMAP730)
/* shut down dsp_ck */
omap_writew(omap_readw(ARM_CKCTL) & ~(1 << EN_DSPCK), ARM_CKCTL);
+#endif
/* temporarily enabling api_ck to access DSP registers */
omap_writew(omap_readw(ARM_IDLECT2) | 1 << EN_APICK, ARM_IDLECT2);
--- linux-omap-2.6/arch/arm/mach-omap1/time.c 2006-02-27 12:12:47.000000000 -0800
+++ linux-omap-fsample/arch/arm/mach-omap1/time.c 2006-03-01 14:25:38.000000000 -0800
@@ -94,7 +94,7 @@
* will break. On P2, the timer count rate is 6.5 MHz after programming PTV
* with 0. This divides the 13MHz input by 2, and is undocumented.
*/
-#ifdef CONFIG_MACH_OMAP_PERSEUS2
+#if defined(CONFIG_MACH_OMAP_PERSEUS2) || defined(CONFIG_MACH_OMAP_FSAMPLE)
/* REVISIT: This ifdef construct should be replaced by a query to clock
* framework to see if timer base frequency is 12.0, 13.0 or 19.2 MHz.
*/
--- linux-omap-2.6/arch/arm/plat-omap/devices.c 2006-04-05 10:33:13.000000000 -0700
+++ linux-omap-fsample/arch/arm/plat-omap/devices.c 2006-04-06 13:15:37.000000000 -0700
@@ -105,7 +105,7 @@
omap_cfg_reg(E20_1610_KBR3);
omap_cfg_reg(E19_1610_KBR4);
omap_cfg_reg(N19_1610_KBR5);
- } else if (machine_is_omap_perseus2()) {
+ } else if (machine_is_omap_perseus2() || machine_is_omap_fsample()) {
omap_cfg_reg(E2_730_KBR0);
omap_cfg_reg(J7_730_KBR1);
omap_cfg_reg(E1_730_KBR2);
--- linux-omap-2.6/arch/arm/tools/mach-types 2006-03-01 12:11:29.000000000 -0800
+++ linux-omap-fsample/arch/arm/tools/mach-types 2006-03-01 14:34:59.000000000 -0800
@@ -969,3 +969,5 @@
fujitsu_wimaxsoc MACH_FUJITSU_WIMAXSOC FUJITSU_WIMAXSOC 956
dualpcmodem MACH_DUALPCMODEM DUALPCMODEM 957
gesbc9312 MACH_GESBC9312 GESBC9312 958
+omap_fsample MACH_OMAP_FSAMPLE OMAP_FSAMPLE 970
+
--- linux-omap-2.6/drivers/input/keyboard/omap-keypad.c 2006-04-05 10:29:47.000000000 -0700
+++ linux-omap-fsample/drivers/input/keyboard/omap-keypad.c 2006-04-06 13:16:47.000000000 -0700
@@ -376,7 +376,7 @@
input_register_device(omap_kp->input);
if (machine_is_omap_h2() || machine_is_omap_h3() ||
- machine_is_omap_perseus2()) {
+ machine_is_omap_perseus2() || machine_is_omap_fsample()) {
omap_writew(0xff, OMAP_MPUIO_BASE + OMAP_MPUIO_GPIO_DEBOUNCING);
}
/* scan current status and enable interrupt */
--- linux-omap-2.6/drivers/spi/omap_uwire.c 2006-02-27 12:14:45.000000000 -0800
+++ linux-omap-fsample/drivers/spi/omap_uwire.c 2006-03-17 15:45:43.000000000 -0800
@@ -495,7 +495,7 @@
omap_cfg_reg(N14_1610_UWIRE_CS0);
omap_cfg_reg(N15_1610_UWIRE_CS1);
}
- if (machine_is_omap_perseus2()) {
+ if (machine_is_omap_perseus2() || machine_is_omap_fsample()) {
/* configure pins: MPU_UW_nSCS1, MPU_UW_SDO, MPU_UW_SCLK */
int val = omap_readl(OMAP730_IO_CONF_9) & ~0x00EEE000;
omap_writel(val | 0x00AAA000, OMAP730_IO_CONF_9);
--- linux-omap-2.6/drivers/ssi/omap-uwire.c 2006-02-27 12:13:10.000000000 -0800
+++ linux-omap-fsample/drivers/ssi/omap-uwire.c 2006-03-17 15:45:43.000000000 -0800
@@ -212,7 +212,7 @@
omap_cfg_reg(N14_1610_UWIRE_CS0);
omap_cfg_reg(P15_1610_UWIRE_CS3);
}
- if (machine_is_omap_perseus2()) {
+ if (machine_is_omap_perseus2() || machine_is_omap_fsample()) {
/* configure pins: MPU_UW_nSCS1, MPU_UW_SDO, MPU_UW_SCLK */
int val = omap_readl(OMAP730_IO_CONF_9) & ~0x00EEE000;
omap_writel(val | 0x00AAA000, OMAP730_IO_CONF_9);
--- linux-omap-2.6/drivers/video/omap/Makefile 2006-02-27 12:14:45.000000000 -0800
+++ linux-omap-fsample/drivers/video/omap/Makefile 2006-03-02 14:38:23.000000000 -0800
@@ -22,6 +22,7 @@
objs-$(CONFIG_ARCH_OMAP15XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1510.o
objs-y$(CONFIG_MACH_OMAP_OSK) += lcd_osk.o
objs-y$(CONFIG_MACH_OMAP_PERSEUS2) += lcd_p2.o
+objs-y$(CONFIG_MACH_OMAP_FSAMPLE) += lcd_p2.o
objs-y$(CONFIG_MACH_OMAP_APOLLON) += lcd_apollon.o
objs-y$(CONFIG_FB_OMAP_LCD_LPH8923) += lcd_lph8923.o
--- linux-omap-2.6/drivers/video/omap/lcd_p2.c 2006-02-27 12:14:45.000000000 -0800
+++ linux-omap-fsample/drivers/video/omap/lcd_p2.c 2006-03-17 15:45:07.000000000 -0800
@@ -31,6 +31,8 @@
#include <asm/arch/gpio.h>
#include <asm/arch/omapfb.h>
+#include <asm/arch/hardware.h>
+
/*
* File: epson-md-tft.h
*
@@ -173,11 +175,17 @@
DBGENTER(1);
/* thwack the reset line */
+#ifdef CONFIG_MACH_OMAP_FSAMPLE
+ fsample_cpld_clear(FSAMPLE_CPLD_BIT_LCD_RESET);
+ mdelay(5);
+ fsample_cpld_set(FSAMPLE_CPLD_BIT_LCD_RESET);
+#else
omap_set_gpio_direction(19, 0);
omap_set_gpio_dataout(19, 0);
mdelay(2);
omap_set_gpio_dataout(19, 1);
-
+#endif
+
/* bits 31:28 -> 0 LCD_PXL_15 .. 12 */
value = omap_readl(OMAP730_IO_CONF_3) & 0x0FFFFFFF;
omap_writel(value, OMAP730_IO_CONF_3);
@@ -189,8 +197,6 @@
omap_writel(value, OMAP730_IO_CONF_4);
omap_uwire_configure_mode(0,16);
-
- omap_uwire_data_transfer(LCD_UWIRE_CS, LCD_DISOFF, 9, 0,NULL,1);
omap_uwire_data_transfer(LCD_UWIRE_CS, LCD_SLPIN, 9, 0,NULL,1);
omap_uwire_data_transfer(LCD_UWIRE_CS, LCD_DISNOR, 9, 0,NULL,1);
omap_uwire_data_transfer(LCD_UWIRE_CS, LCD_GSSET, 9, 0,NULL,1);
@@ -265,9 +271,13 @@
omap_uwire_data_transfer(LCD_UWIRE_CS, LCD_DISON, 9, 0,NULL,1);
/* enable backlight */
+#ifdef CONFIG_MACH_OMAP_FSAMPLE
+ fsample_cpld_set(FSAMPLE_CPLD_BIT_BACKLIGHT);
+#else
omap_set_gpio_direction(134, 0);
omap_set_gpio_dataout(134, 1);
-
+#endif
+
DBGLEAVE(1);
return 0;
}
--- linux-omap-2.6/include/asm-arm/arch-omap/board-fsample.h 1969-12-31 16:00:00.000000000 -0800
+++ linux-omap-fsample/include/asm-arm/arch-omap/board-fsample.h 2006-03-01 16:30:11.000000000 -0800
@@ -0,0 +1,51 @@
+/*
+ * linux/include/asm-arm/arch-omap/board-fsample.h
+ *
+ * Board-specific goodies for TI F-Sample.
+ *
+ * Copyright (C) 2006 Google, Inc.
+ * Author: Brian Swetland <swetland@google.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __ASM_ARCH_OMAP_FSAMPLE_H
+#define __ASM_ARCH_OMAP_FSAMPLE_H
+
+/* fsample is pretty close to p2-sample */
+#include <asm/arch/board-perseus2.h>
+
+#define fsample_cpld_read(reg) __raw_readb(reg)
+#define fsample_cpld_write(val, reg) __raw_writeb(val, reg)
+
+#define FSAMPLE_CPLD_BASE 0xE8100000
+#define FSAMPLE_CPLD_SIZE SZ_4K
+#define FSAMPLE_CPLD_START 0x05080000
+
+#define FSAMPLE_CPLD_REG_A (FSAMPLE_CPLD_BASE + 0x00)
+#define FSAMPLE_CPLD_SWITCH (FSAMPLE_CPLD_BASE + 0x02)
+#define FSAMPLE_CPLD_UART (FSAMPLE_CPLD_BASE + 0x02)
+#define FSAMPLE_CPLD_REG_B (FSAMPLE_CPLD_BASE + 0x04)
+#define FSAMPLE_CPLD_VERSION (FSAMPLE_CPLD_BASE + 0x06)
+#define FSAMPLE_CPLD_SET_CLR (FSAMPLE_CPLD_BASE + 0x06)
+
+#define FSAMPLE_CPLD_BIT_BT_RESET 0
+#define FSAMPLE_CPLD_BIT_LCD_RESET 1
+#define FSAMPLE_CPLD_BIT_CAM_PWDN 2
+#define FSAMPLE_CPLD_BIT_CHARGER_ENABLE 3
+#define FSAMPLE_CPLD_BIT_SD_MMC_EN 4
+#define FSAMPLE_CPLD_BIT_aGPS_PWREN 5
+#define FSAMPLE_CPLD_BIT_BACKLIGHT 6
+#define FSAMPLE_CPLD_BIT_aGPS_EN_RESET 7
+#define FSAMPLE_CPLD_BIT_aGPS_SLEEPx_N 8
+#define FSAMPLE_CPLD_BIT_OTG_RESET 9
+
+#define fsample_cpld_set(bit) \
+ fsample_cpld_write((((bit) & 15) << 4) | 0x0f, FSAMPLE_CPLD_SET_CLR)
+
+#define fsample_cpld_clear(bit) \
+ fsample_cpld_write(0xf0 | ((bit) & 15), FSAMPLE_CPLD_SET_CLR)
+
+#endif
--- linux-omap-2.6/include/asm-arm/arch-omap/hardware.h 2006-02-27 12:13:17.000000000 -0800
+++ linux-omap-fsample/include/asm-arm/arch-omap/hardware.h 2006-03-02 14:41:50.000000000 -0800
@@ -298,6 +298,10 @@
#include "board-perseus2.h"
#endif
+#ifdef CONFIG_MACH_OMAP_FSAMPLE
+#include "board-fsample.h"
+#endif
+
#ifdef CONFIG_MACH_OMAP_H3
#include "board-h3.h"
#endif
[-- Attachment #3: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] [conntrack] fixed duration connection
From: Eric Leblond @ 2006-04-07 22:08 UTC (permalink / raw)
To: Netfilter Development Mailinglist; +Cc: Patrick McHardy, nufw-devel
In-Reply-To: <4436E156.5010306@inl.fr>
[-- Attachment #1: Type: text/plain, Size: 717 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi again,
This is better with the patch...
All my apologies
BR,
Eric Leblond wrote:
> Hi,
>
> This patch against conntrack tool adds support for fixed connection. for
> example :
> conntrack -U -d 153.113.34.136 -s 192.168.11.32 -p tcp \\
> --orig-port-src 59119 --orig-port-dst 22 -t 10 \\
> -u ASSURED,SEEN_REPLY,FIXED_TIMEOUT
> will fix timeout of connection to 10 seconds after command.
>
> BR,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFENuLEnxA7CdMWjzIRAiKaAJ9tC+/xQ44ibVF1ioAakWn9JC7mbgCdFGiO
vZLLCcIN08G45vaNsru4TAw=
=BWXz
-----END PGP SIGNATURE-----
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: conntrack_fixed_timeout-flag.patch --]
[-- Type: text/x-patch; name="conntrack_fixed_timeout-flag.patch", Size: 830 bytes --]
Index: src/conntrack.c
===================================================================
--- src/conntrack.c (révision 6578)
+++ src/conntrack.c (copie de travail)
@@ -335,13 +335,13 @@
#define PARSE_MAX 2
static struct parse_parameter {
- char *parameter[5];
+ char *parameter[6];
size_t size;
- unsigned int value[5];
+ unsigned int value[6];
} parse_array[PARSE_MAX] = {
- { {"ASSURED", "SEEN_REPLY", "UNSET", "SRC_NAT", "DST_NAT"}, 5,
+ { {"ASSURED", "SEEN_REPLY", "UNSET", "SRC_NAT", "DST_NAT","FIXED_TIMEOUT"}, 6,
{ IPS_ASSURED, IPS_SEEN_REPLY, 0,
- IPS_SRC_NAT_DONE, IPS_DST_NAT_DONE} },
+ IPS_SRC_NAT_DONE, IPS_DST_NAT_DONE, IPS_FIXED_TIMEOUT} },
{ {"ALL", "NEW", "UPDATES", "DESTROY"}, 4,
{~0U, NF_NETLINK_CONNTRACK_NEW, NF_NETLINK_CONNTRACK_UPDATE,
NF_NETLINK_CONNTRACK_DESTROY} },
^ permalink raw reply
* Re: Diff between Linus' and linux-mips git: elf.h
From: Ralf Baechle @ 2006-04-07 22:21 UTC (permalink / raw)
To: Kevin D. Kissell; +Cc: Martin Michlmayr, linux-mips
In-Reply-To: <090d01c65a6b$623f6480$10eca8c0@grendel>
On Fri, Apr 07, 2006 at 07:47:40PM +0200, Kevin D. Kissell wrote:
> Arguably, whatever's used by binutils should be the tie-breaker.
> Googling around, I see that the EM_MIPS_RS3_LE value was
> added in the October 4, 1999 draft of the ELF spec, but inexplicably
> the alias with EM_MIPS_RS4_BE was left in place - perhaps they
> were supposed to be disambiguated by some 32-vs-64-bit flag
> somewhere. A random sampling of ELF documents on the web
> shows the vast majority calling out RS3_LE and not RS4_BE.
No way to actually resolve this one; not even binutils oldtimer
Ian Lance Taylor can remember the reasons for the change anymore.
Ralf
^ permalink raw reply
* Re: [PATCH 19/21] orinoco: reduce differences between PCI drivers, create orinoco_pci.h
From: Francois Romieu @ 2006-04-07 22:10 UTC (permalink / raw)
To: Pavel Roskin
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
orinoco-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20060407081057.16107.82106.stgit-fdEtzkpK75rby3iVrkZq2A@public.gmane.org>
Pavel Roskin <proski-mXXj517/zsQ@public.gmane.org> :
> index 0000000..b05a9a5
> --- /dev/null
> +++ b/drivers/net/wireless/orinoco_pci.h
[...]
> +static int orinoco_pci_resume(struct pci_dev *pdev)
> +{
> + struct net_device *dev = pci_get_drvdata(pdev);
> + struct orinoco_private *priv = netdev_priv(dev);
> + unsigned long flags;
> + int err;
> +
> + pci_set_power_state(pdev, 0);
> + pci_enable_device(pdev);
> + pci_restore_state(pdev);
> +
> + err = request_irq(pdev->irq, orinoco_interrupt, SA_SHIRQ,
> + dev->name, dev);
> + if (err) {
> + printk(KERN_ERR "%s: cannot re-allocate IRQ on resume\n",
> + dev->name);
> + pci_disable_device(pdev);
> + return -EBUSY;
> + }
> +
> + err = orinoco_reinit_firmware(dev);
> + if (err) {
> + printk(KERN_ERR "%s: error %d re-initializing firmware "
> + "on resume\n", dev->name, err);
> + return err;
> + }
> +
> + spin_lock_irqsave(&priv->lock, flags);
Interruptions are enabled. No need to save/restore.
> +
> + 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.
--
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: [PATCH 16/21] orinoco_pci: disable device and free IRQ when suspending
From: Pavel Roskin @ 2006-04-07 22:12 UTC (permalink / raw)
To: Francois Romieu
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
orinoco-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20060407212429.GA15720-lmTtMILVy1jWQcoT9B9Ug5SCg42XY1Uw0E9HWUfgJXw@public.gmane.org>
Hello!
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. 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.
--
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: [Bluez-users] sniff & pand
From: Alexandre Coser Monteiro @ 2006-04-07 22:13 UTC (permalink / raw)
To: bluez-users
In-Reply-To: <8350AFF45303EE44BE0AF1AB40CA43584DAC8E@scsmsx404.amr.corp.intel.com>
EUREKA, EUREKA, it is working, it is working !!!!! You are right it is just a reversed
sequence of MSB/LSB, but I didn`t find it write in any where.
Thank you for your help !
On Fri, 7 Apr 2006 14:25:25 -0700, Pering, Trevor wrote
> pand and sniff have nothing to do with each other -- they are handled at
> different levels and are so (in my understanding) relatively
> independent.
>
> Can you do a role switch with the device? That might have some effect.
>
> Numbers are LSB/MSB, so I think you have the order of your connection
> handle bytes reversed.
>
> The exact sequence that works for me is:
>
> hcitool cmd 0x02 0x0003 0x06 0x00 0x80 0x00 0x40 0x00 0x02 0x00 0x08
> 0x00
>
> Trevor
>
> -----Original Message-----
> From: bluez-users-admin@lists.sourceforge.net
> [mailto:bluez-users-admin@lists.sourceforge.net] On Behalf Of Alexandre
> Coser Monteiro
> Sent: Friday, April 07, 2006 2:13 PM
> To: bluez-users@lists.sourceforge.net
> Subject: RE: [Bluez-users] sniff & pand
>
> Thank you Trevor,
>
> You rigth, but still doesn`t work. I`ve ben tried many changes of
> values and position
> but my dongle do not enter in sniff mode. There is any objection against
> sniff mode and
> a pand connection work together ?
>
> #hcitool cmd 0x02 0x0003 0x00 0x06 0x8E 0x00 0x25 0x8D 0x04 0x62 0x04
> 0x62
> < HCI Command: ogf 0x02, ocf 0x0003, plen 10
> 00 06 8E 00 25 8D 04 62 04 62
> > HCI Event: 0x0f plen 4
> 02 01 03 08
>
> #hcitool con
> Connections:
> > ACL 00:03:C9:23:DE:B2 handle 6 state 1 lm SLAVE
> # hcidump
> HCIDump - HCI packet analyzer ver 1.11
> device: hci0 snap_len: 1028 filter: 0xffffffff
> < HCI Command: Sniff Mode (0x02|0x0003) plen 10
> > HCI Event: Command Status (0x0f) plen 4
>
> # hciconfig -a
> hci0: Type: USB
> BD Address: 00:03:C9:23:DE:9F ACL MTU: 377:10 SCO MTU: 16:0
> UP RUNNING PSCAN ISCAN
> RX bytes:124087 acl:483 sco:0 events:449 errors:0
> TX bytes:134145 acl:507 sco:0 commands:101 errors:0
> Features: 0xff 0xfd 0x05 0x00 0x00 0x00 0x00 0x00
> Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
> Link policy: SNIFF
> Link mode: SLAVE ACCEPT
> Name: 'Broadcom BCM2033'
> Class: 0x000000
> Service Classes: Unspecified
> Device Class: Miscellaneous,
> HCI Ver: 1.1 (0x1) HCI Rev: 0x2 LMP Ver: 1.1 (0x1) LMP Subver:
> 0x1007
> Manufacturer: Broadcom Corporation (15)
>
> Sds,
> Alexandre
>
> On Fri, 7 Apr 2006 13:46:06 -0700, Pering, Trevor wrote
> > how are you parsing your command line? I don' tunderstand how you get
> > the sniff attempts (0x0062) and sniff timeout (0x0062) from your
> > command. Do you mean 0x0462? I parse your max interval as 0x8E00.
> > Double-check the *number* of arguments you have... you have 11, when
> you
> > should have 10.
> >
> > Trevor
> >
> > -----Original Message-----
> > From: bluez-users-admin@lists.sourceforge.net
> > [mailto:bluez-users-admin@lists.sourceforge.net] On Behalf Of
> Alexandre
> > Coser Monteiro
> > Sent: Friday, April 07, 2006 12:26 PM
> > To: bluez-users@lists.sourceforge.net
> > Subject: Re: [Bluez-users] sniff & pand
> >
> > Thank you for your attention Steven.
> >
> > With a detailed eye in my sniff command line, I agree whith you that
> I
> > introduce wrong
> > parameters, but I still doesn`t understand why a pand connection
> doesn`t
> > accept my sniff
> > command line after my correction.
> > I`ve been introduced the sniff commando through the linux shell
> using
> > hcitool
> >
> > [root@helio script]# hcitool cmd 0x02 0x0003 0x00 0x06 0x00 0x8E 0x25
> > 0x8D 0x25 0x62
> > 0x04 0x62 0X04
> > < HCI Command: ogf 0x02, ocf 0x0003, plen 11
> > 00 06 00 8E 25 8E 24 62 04 62 04
> > > HCI Event: 0x0f plen 4
> > 02 01 03 08
> >
> > Sniff Interval = 6 seg.
> > Sniff Attempt = 0.7 seg.
> > Connection handle: 0x0006
> > Sniff Max Interval: 0x258E
> > Sniff Min Interval: 0x258D
> > Sniff Attempts: 0x0062
> > Sniff Timeout: 0x0062
> >
> > The notation for sniff command line is LSB-MSB ? How can I do sniff
> work
> > in a pand
> > connection ?
> > I work with FedoraCore-3, Linux kernel 2.6.9-1.667smp and a usb
> > bluetooth dongle BT3030
> > from BroadCom
> >
> > Sds,
> > Alexandre
> >
> > On Fri, 07 Apr 2006 16:02:06 +0100, Steven Singer wrote
> > > Alexandre Coser Monteiro wrote:
> > > > < HCI Command: ogf 0x02, ocf 0x0003, plen 9
> > > > 06 10 00 00 10 FF F7 00 07
> > > > > HCI Event: 0x0f plen 4
> > > > 12 01 03 08
> > >
> > > The Command Status event shows error code 0x12 = Invalid HCI Command
> > > Parameters.
> > >
> > > This means that the controller didn't like one of the parameters to
> > the
> > > sniff mode command.
> > >
> > > The sniff mode command you gave had the parameters:
> > >
> > > Connection handle: 0x1006
> > > Sniff Max Interval: 0x0000
> > > Sniff Min Interval: 0xff10
> > > Sniff Attempts: 0x00f7
> > > Sniff Timeout: 0x??07
> > >
> > > Notes:
> > >
> > > The connection handle is invalid. The valid range is
> 0x0000..0x0eff
> > >
> > > The maximum interval is invalid. The valid range is 0x0002..0xfffe
> > >
> > > The minimum interval is invalid. The valid range is 0x0002..max
> > > interval.
> > >
> > > The sniff attempts is highly unusual (but not actually invalid).
> > >
> > > The sniff timeout field is truncated, it should be two bytes.
> > >
> > > So, it's not surprising that the controller is rejecting it.
> > >
> > > Where is the sniff mode command being generated? How is it getting
> > > through the BlueZ APIs to generate such an invalid event? Are the
> > > normal APIs being bypassed and is a raw command being sent.
> > >
> > > - Steven
> > > --
-------------------------------------------------------
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
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply
* Re: [RFC][PATCH 1/5] uts namespaces: Implement utsname namespaces
From: Serge E. Hallyn @ 2006-04-07 22:13 UTC (permalink / raw)
To: James Morris
Cc: Serge E. Hallyn, linux-kernel, Kirill Korotaev, herbert, devel,
sam, Eric W. Biederman, xemul
In-Reply-To: <Pine.LNX.4.64.0604071645230.13532@d.namei>
Quoting James Morris (jmorris@namei.org):
> On Fri, 7 Apr 2006, Serge E. Hallyn wrote:
>
>
> > +EXPORT_SYMBOL(unshare_uts_ns);
> > +EXPORT_SYMBOL(free_uts_ns);
>
> Why not EXPORT_SYMBOL_GPL?
Actually come to think of it they don't need to be exported.
I will move the exports to the last, debugging, patch.
> What do you expect the user api to look like, a syscall?
This remains to be determined, and this patchset purposely doesn't
address it. AFAIU, the two most likely options are extending clone and
unshare, and using new syscalls. Whatever is decided for the other
namespaces, this should use.
With this patchset (minus the last patch for debugging) uts namespaces
are supported, but processes can't clone their uts namespace yet.
> Probably need to think about LSM hooks for creating and updating the
> namespaces.
True, that is something that needs to be discussed when the topic
of how to implement unsharing comes up again.
thanks,
-serge
^ permalink raw reply
* [ALSA - driver 0002008]: No Sound with snd-hda-intel driver Asus P5VDC-MX
From: bugtrack @ 2006-04-07 22:16 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:16 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:02
----------------------------------------------------------------------
Does the interrupt count for the soundcard increase in /proc/interrupts
when playing sound?
----------------------------------------------------------------------
buboleck - 04-08-06 00:16
----------------------------------------------------------------------
YES :)
BEFORE
buboleck ~ # cat /proc/interrupts
CPU0 CPU1
0: 206694 0 IO-APIC-edge timer
1: 412 0 IO-APIC-edge i8042
7: 0 0 IO-APIC-edge parport0
8: 2 0 IO-APIC-edge rtc
9: 0 0 IO-APIC-level acpi
12: 3341 0 IO-APIC-edge i8042
14: 10171 0 IO-APIC-edge ide0
15: 638 0 IO-APIC-edge ide1
16: 14053 0 IO-APIC-level fglrx
17: 0 0 IO-APIC-level cx88[0]
18: 394 0 IO-APIC-level eth0, uhci_hcd:usb4
19: 0 0 IO-APIC-level uhci_hcd:usb1
20: 3 0 IO-APIC-level uhci_hcd:usb2, ehci_hcd:usb5,
VIA8237
21: 0 0 IO-APIC-level uhci_hcd:usb3
NMI: 0 0
LOC: 206528 206629
ERR: 0
MIS: 0
AFTER sound
buboleck ~ # cat /proc/interrupts
CPU0 CPU1
0: 217168 0 IO-APIC-edge timer
1: 418 0 IO-APIC-edge i8042
7: 0 0 IO-APIC-edge parport0
8: 2 0 IO-APIC-edge rtc
9: 0 0 IO-APIC-level acpi
12: 4581 0 IO-APIC-edge i8042
14: 10842 0 IO-APIC-edge ide0
15: 668 0 IO-APIC-edge ide1
16: 14943 0 IO-APIC-level fglrx
17: 0 0 IO-APIC-level cx88[0]
18: 414 0 IO-APIC-level eth0, uhci_hcd:usb4
19: 0 0 IO-APIC-level uhci_hcd:usb1
20: 11 0 IO-APIC-level uhci_hcd:usb2, ehci_hcd:usb5,
VIA8237
21: 0 0 IO-APIC-level uhci_hcd:usb3
NMI: 0 0
LOC: 217004 217105
ERR: 0
MIS: 0
Plays for a sec stops and amarok dies. I kill amarok, start it again and
same, one sec sound and dies.
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
======================================================================
-------------------------------------------------------
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
* [Qemu-devel] [PATCH] SPARC target : Fix carry flag update in addxcc and subxcc ops
From: Even Rouault @ 2006-04-07 22:17 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 270 bytes --]
I send a patch that should fix a bug in the update of carry flag for addxcc
and subxcc instructions when the carry flag is set before the evaluation of
the instruction.
(the fix is identical to what is done in the similar instruction
op_adcl_T0_T1_cc for arm target)
[-- Attachment #2: qemu-sparc-carry-xcc-ops.patch --]
[-- Type: text/x-diff, Size: 2130 bytes --]
? patch-qemu-sparc-xcc_ops.txt
Index: op.c
===================================================================
RCS file: /sources/qemu/qemu/target-sparc/op.c,v
retrieving revision 1.18
diff -u -p -r1.18 op.c
--- op.c 30 Oct 2005 17:28:50 -0000 1.18
+++ op.c 7 Apr 2006 22:04:40 -0000
@@ -415,9 +415,9 @@ void OPPROTO op_addx_T1_T0(void)
void OPPROTO op_addx_T1_T0_cc(void)
{
target_ulong src1;
-
+ target_ulong has_carry = FLAG_SET(PSR_CARRY);
src1 = T0;
- T0 += T1 + FLAG_SET(PSR_CARRY);
+ T0 += T1 + has_carry;
env->psr = 0;
#ifdef TARGET_SPARC64
if (!(T0 & 0xffffffff))
@@ -435,7 +435,7 @@ void OPPROTO op_addx_T1_T0_cc(void)
env->xcc |= PSR_ZERO;
if ((int64_t) T0 < 0)
env->xcc |= PSR_NEG;
- if (T0 < src1)
+ if (T0 < src1 || (has_carry && T0 <= src1))
env->xcc |= PSR_CARRY;
if (((src1 ^ T1 ^ -1) & (src1 ^ T0)) & (1ULL << 63))
env->xcc |= PSR_OVF;
@@ -444,7 +444,7 @@ void OPPROTO op_addx_T1_T0_cc(void)
env->psr |= PSR_ZERO;
if ((int32_t) T0 < 0)
env->psr |= PSR_NEG;
- if (T0 < src1)
+ if (T0 < src1 || (has_carry && T0 <= src1))
env->psr |= PSR_CARRY;
if (((src1 ^ T1 ^ -1) & (src1 ^ T0)) & (1 << 31))
env->psr |= PSR_OVF;
@@ -505,9 +505,9 @@ void OPPROTO op_subx_T1_T0(void)
void OPPROTO op_subx_T1_T0_cc(void)
{
target_ulong src1;
-
+ target_ulong has_carry = FLAG_SET(PSR_CARRY);
src1 = T0;
- T0 -= T1 + FLAG_SET(PSR_CARRY);
+ T0 -= T1 + has_carry;
env->psr = 0;
#ifdef TARGET_SPARC64
if (!(T0 & 0xffffffff))
@@ -525,7 +525,7 @@ void OPPROTO op_subx_T1_T0_cc(void)
env->xcc |= PSR_ZERO;
if ((int64_t) T0 < 0)
env->xcc |= PSR_NEG;
- if (src1 < T1)
+ if (src1 < T1 || (has_carry && src1 <= T1))
env->xcc |= PSR_CARRY;
if (((src1 ^ T1) & (src1 ^ T0)) & (1ULL << 63))
env->xcc |= PSR_OVF;
@@ -534,7 +534,7 @@ void OPPROTO op_subx_T1_T0_cc(void)
env->psr |= PSR_ZERO;
if ((int32_t) T0 < 0)
env->psr |= PSR_NEG;
- if (src1 < T1)
+ if (src1 < T1 || (has_carry && src1 <= T1))
env->psr |= PSR_CARRY;
if (((src1 ^ T1) & (src1 ^ T0)) & (1 << 31))
env->psr |= PSR_OVF;
^ permalink raw reply
* Re: question about Linux 2.6 with Xilinx ML-403
From: Grant Likely @ 2006-04-07 22:18 UTC (permalink / raw)
To: yding, linuxppc-embedded list
In-Reply-To: <4436BD2B.9050306@lnxw.com>
On 4/7/06, yding <yding@lnxw.com> wrote:
> HI, Grant,
>
> I found this message :
> http://patchwork.ozlabs.org/linuxppc/patch?id=3D3841 on
> Internet.
> It looks like you created some patch files for supporting Linux 2.6 with
> Xilinx ML-403.
>
> how can download the whole kernel source tree with your patched files (vi=
a
> cvs or bitkeeper) ?
I believe they are now in Linus' mainline git tree. If not, they are
in Paul's powerpc git tree.
BTW, please CC the linuxppc-embedded mailing list when emailing me directly=
.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 399-0195
^ permalink raw reply
* [ALSA - driver 0002008]: No Sound with snd-hda-intel driver Asus P5VDC-MX
From: bugtrack @ 2006-04-07 22:19 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:19 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:16
----------------------------------------------------------------------
YES :)
BEFORE
buboleck ~ # cat /proc/interrupts
CPU0 CPU1
0: 206694 0 IO-APIC-edge timer
1: 412 0 IO-APIC-edge i8042
7: 0 0 IO-APIC-edge parport0
8: 2 0 IO-APIC-edge rtc
9: 0 0 IO-APIC-level acpi
12: 3341 0 IO-APIC-edge i8042
14: 10171 0 IO-APIC-edge ide0
15: 638 0 IO-APIC-edge ide1
16: 14053 0 IO-APIC-level fglrx
17: 0 0 IO-APIC-level cx88[0]
18: 394 0 IO-APIC-level eth0, uhci_hcd:usb4
19: 0 0 IO-APIC-level uhci_hcd:usb1
20: 3 0 IO-APIC-level uhci_hcd:usb2, ehci_hcd:usb5,
VIA8237
21: 0 0 IO-APIC-level uhci_hcd:usb3
NMI: 0 0
LOC: 206528 206629
ERR: 0
MIS: 0
AFTER sound
buboleck ~ # cat /proc/interrupts
CPU0 CPU1
0: 217168 0 IO-APIC-edge timer
1: 418 0 IO-APIC-edge i8042
7: 0 0 IO-APIC-edge parport0
8: 2 0 IO-APIC-edge rtc
9: 0 0 IO-APIC-level acpi
12: 4581 0 IO-APIC-edge i8042
14: 10842 0 IO-APIC-edge ide0
15: 668 0 IO-APIC-edge ide1
16: 14943 0 IO-APIC-level fglrx
17: 0 0 IO-APIC-level cx88[0]
18: 414 0 IO-APIC-level eth0, uhci_hcd:usb4
19: 0 0 IO-APIC-level uhci_hcd:usb1
20: 11 0 IO-APIC-level uhci_hcd:usb2, ehci_hcd:usb5,
VIA8237
21: 0 0 IO-APIC-level uhci_hcd:usb3
NMI: 0 0
LOC: 217004 217105
ERR: 0
MIS: 0
Plays for a sec stops and amarok dies. I kill amarok, start it again and
same, one sec sound and dies.
----------------------------------------------------------------------
buboleck - 04-08-06 00:19
----------------------------------------------------------------------
lspci with onboard sound enabled:
00:00.0 Host bridge: VIA Technologies, Inc. P4M800CE Host Bridge
00:00.1 Host bridge: VIA Technologies, Inc. P4M800CE Host Bridge
00:00.2 Host bridge: VIA Technologies, Inc. P4M800CE Host Bridge
00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge
00:00.4 Host bridge: VIA Technologies, Inc. P4M800CE Host Bridge
00:00.7 Host bridge: VIA Technologies, Inc. P4M800CE Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
00:0f.0 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 07)
00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 90)
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 90)
00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 90)
00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 90)
00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 90)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8251 PCI to ISA Bridge
00:11.5 Multimedia audio controller: VIA Technologies, Inc.
VT8233/A/8235/8237 AC97 Audio Controller (rev 70)
00:11.7 Host bridge: VIA Technologies, Inc. VT8251 Ultra VLINK Controller
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev
7c)
00:13.0 PCI bridge: VIA Technologies, Inc. VT8251 PCI to PCIE Bridge
00:13.1 PCI bridge: VIA Technologies, Inc. VT8251 PCI to PCI Bridge
01:00.0 VGA compatible controller: ATI Technologies Inc RV410 [Radeon X700
(PCIE)]
01:00.1 Display controller: ATI Technologies Inc RV410 [Radeon X700
(PCIE)] (Secondary)
02:00.0 PCI bridge: VIA Technologies, Inc. VT8251 PCIE Root Port
02:00.1 PCI bridge: VIA Technologies, Inc. VT8251 PCIE Root Port
05:08.0 Multimedia audio controller: Ensoniq 5880 AudioPCI (rev 02)
05:09.0 Multimedia video controller: Conexant CX23880/1/2/3 PCI Video and
Audio Decoder (rev 05
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
======================================================================
-------------------------------------------------------
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: RT task scheduling
From: Bill Huey @ 2006-04-07 22:18 UTC (permalink / raw)
To: Ingo Molnar
Cc: Darren Hart, linux-kernel, Thomas Gleixner, Stultz, John,
Peter Williams, Siddha, Suresh B, Nick Piggin, Bill Huey (hui)
In-Reply-To: <20060407112956.GA17277@elte.hu>
On Fri, Apr 07, 2006 at 01:29:56PM +0200, Ingo Molnar wrote:
> * Bill Huey <billh@gnuppy.monkey.org> wrote:
> > First thing's first, SCHED_FIFO_GLOBAL for what you want in the main
> > line is the same thing as SCHED_FIFO in -rt, right ?
>
> yes.
Ok, good, we're getting some where. IMO, SCHED_FIFO_GLOBAL doesn't add
anything to existing Linux scheduling policies for it to be really
distinct than SCHED_FIFO. I'd much see that feature collapsed into a
into SCHED_FIFO intrinsically. In fact, that's the way it should be in
a solid RTOS. Creation of run categories that are so similar doesn't
really add to the "meaning" of the system, since SCHED_FIFO was kind
of hammered in the first place, just make SCHED_FIFO do that strict
priority stuff across all processors as a default property.
Whether this belongs in the main line or not is questionable. My guess
is probably not. But I definitely think it should go into -rt and it
would be much more warmly received by folks developing on that kernel
patch to know that SCHED_FIFO has this strict behavior. It's actually
needed in that patch IMO. Following ?
bill
^ permalink raw reply
* Re: [PATCH 17/21] orinoco_pci: use pci_iomap() for resources
From: Pavel Roskin @ 2006-04-07 22:21 UTC (permalink / raw)
To: Francois Romieu
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
orinoco-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20060407213619.GB15720-lmTtMILVy1jWQcoT9B9Ug5SCg42XY1Uw0E9HWUfgJXw@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?
--
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: [LARTC] packet marking: only a ratio, not all
From: Andy Furniss @ 2006-04-07 22:23 UTC (permalink / raw)
To: lartc
pfer wrote:
> Hi all!
>
> In short:
>
> Anybody wrote a patch for DSMARK to make it capable of marking
> only a ratio (a given arg to the tc command) of the packets it gets?
> Say, 20%? Or, do I have to hack into the source? Alternatives,
> like a filter spitting packets to 2 different DSMARK based on this ratio?
>
> In long:
>
> I'm a hungarian univ student involved in a project (RMD-QoS stuff)
> which needs the following:
>
> \ This node has 3 ingress and 1 egress link, all have for ex. 10 Mbit
> \ limit to their traffic.
> \
> --- node ----- Suppose ingress traffic is: 8 + 3 +5 = 16 while the egress
> / link will be congested with 10. Because this node is a simple,
> / intradomain router, we would like to notify the downstream
> / edge node about this congestion, to tear down some of the flows
> causing it. (Congestion occured via for. ex. a net failure)
>
> What the protocol (draft) says, is that the edge will be notified of the level of the congestion, which will be calculated by this proportional data packet marking method, to avoid additional signaling.
> Say, if 16 would go on a link with 10 capacity, congested core-node will mark
> 60% of the packets it sends to the output of the link to another DSCP.
>
> I thought about DSMARK first, but that is incapable of doing this stuff.
> (or I think so :)
> Ideas?
>
> PS: I did not check the archives rigorously, so sorry if I am asking trivial things.
>
> PS2: Since I checked not to get mails from this list, please send your answer
> to forgamedev@yahoo.com.
I am not sure I get the logic of what you are trying to do for this
paticular setup, but there are examples of using policers with meters
shared across ingress links to dsmark overlimits packets in the iproute2
sources.
Andy.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: command queueing cmd_per_lun, queue_depth and tags
From: Brian King @ 2006-04-07 22:29 UTC (permalink / raw)
To: Patrick Mansfield; +Cc: linux-scsi
In-Reply-To: <20060407214954.GA4990@us.ibm.com>
Patrick Mansfield wrote:
> Currently cmd_per_lun is the default queue depth for both tagged and
> untagged queueing. That is, if the LLDD does not modify queue_depth in its
> slave_configure, queue_depth will be set to cmd_per_lun, no matter what
> the command queueing/tag support.
>
> If we don't allow queueing in the LLDD, and cmd_per_lun is supposed to be
> the default depth for untagged support, shouldn't it always be 1, and
> hence go away?
This seems to assume there are no SCSI devices which do command queuing, but do
not support queue tags. This is not the case.
> Similarily, why do some LLDD's use a cmd_per_lun of 3, or (like
> ncr53c8xx_slave_configure) set queue_depth for !tagged_supported to
> anything other than 1?
In the case of ipr, there are two scenarios. The first is for JBOD disks.
I use a default queue depth of 6 in ipr. When running untagged, with a queue depth
of > 1, the ipr adapter firmware then maintains a queue, guaranteeing only
one command will be outstanding to the device at once. This lower level
queue allows for a faster turnaround of commands and improved performance.
The second case is that of RAID arrays. These show up as logical scsi disks.
They support command queueing, but not tagged command queueing.
> I know (at least) FCP can always do simple queueing, but I don't think
> scsi core should allow multiple commands to be sent if the device does not
> have CMDQUE (or BQUE).
This will break both of the working scenarios I described above for ipr
and performance will suffer significantly. The inquiry data for ipr RAID
arrays does not set either CMDQUE or BQUE.
> Also we don't even check the BQUE in the INQUIRY result (byte 6, bit 7).
> Should this be changed? That is set tagged_supported if BQUE is set, like
> we do for CMDQUE (byte 7 bit 1). And also set simple_tags if
> tagged_supported is set.
I don't like the idea of always enabling TCQ in scsi core simply if
the device supports it. What if the HBA does not support it? To make
matters more interesting, what if the HBA does not support TCQ, but does
support untagged command queueing, similar to ipr as described above?
Additionally, ipr is currently relying on the fact that TCQ does not
get enabled by default. It lets userspace code enable it after verifying
the mode page settings of the drive for things like qerr, which the adapter
firmware has dependencies on.
Brian
> That is something like this patch to always set queue_depth to 1 by
> default, then later if BQUE or CMDQUE are set, set queue_depth to
> cmd_per_lun. Of course slave_configure can still override this, but this
> change means queue_depth is 1 if you call scsi_deactivate_tcq().
>
> Using this patch might also require changes in some LLDD's, like ipr.
>
> diff -uprN -X /home/patman/dontdiff /home/linux/views/linux-2.6.17-rc1/drivers/scsi/scsi.c linux-2.6.17-rc1/drivers/scsi/scsi.c
> --- /home/linux/views/linux-2.6.17-rc1/drivers/scsi/scsi.c 2006-04-03 11:35:58.000000000 -0700
> +++ linux-2.6.17-rc1/drivers/scsi/scsi.c 2006-04-07 10:00:15.000000000 -0700
> @@ -866,9 +866,7 @@ EXPORT_SYMBOL(scsi_finish_command);
> * Arguments: sdev - SCSI Device in question
> * tagged - Do we use tagged queueing (non-0) or do we treat
> * this device as an untagged device (0)
> - * tags - Number of tags allowed if tagged queueing enabled,
> - * or number of commands the low level driver can
> - * queue up in non-tagged mode (as per cmd_per_lun).
> + * tags - Number of tags allowed if tagged queueing enabled
> *
> * Returns: Nothing
> *
> @@ -883,6 +881,8 @@ void scsi_adjust_queue_depth(struct scsi
> {
> unsigned long flags;
>
> + if (!tagged)
> + tags = 1;
> /*
> * refuse to set tagged depth to an unworkable size
> */
> @@ -913,7 +913,6 @@ void scsi_adjust_queue_depth(struct scsi
> "disabled\n");
> case 0:
> sdev->ordered_tags = sdev->simple_tags = 0;
> - sdev->queue_depth = tags;
> break;
> }
> out:
> @@ -935,8 +934,7 @@ EXPORT_SYMBOL(scsi_adjust_queue_depth);
> *
> * Returns: 0 - No change needed
> * >0 - Adjust queue depth to this new depth
> - * -1 - Drop back to untagged operation using host->cmd_per_lun
> - * as the untagged command depth
> + * -1 - Drop back to untagged operation
> *
> * Lock Status: None held on entry
> *
> @@ -960,7 +958,7 @@ int scsi_track_queue_full(struct scsi_de
> return 0;
> if (sdev->last_queue_full_depth < 8) {
> /* Drop back to untagged */
> - scsi_adjust_queue_depth(sdev, 0, sdev->host->cmd_per_lun);
> + scsi_adjust_queue_depth(sdev, 0, 1);
> return -1;
> }
>
> diff -uprN -X /home/patman/dontdiff /home/linux/views/linux-2.6.17-rc1/drivers/scsi/scsi_scan.c linux-2.6.17-rc1/drivers/scsi/scsi_scan.c
> --- /home/linux/views/linux-2.6.17-rc1/drivers/scsi/scsi_scan.c 2006-04-03 11:35:58.000000000 -0700
> +++ linux-2.6.17-rc1/drivers/scsi/scsi_scan.c 2006-04-07 09:47:47.000000000 -0700
> @@ -256,7 +256,7 @@ static struct scsi_device *scsi_alloc_sd
> }
>
> sdev->request_queue->queuedata = sdev;
> - scsi_adjust_queue_depth(sdev, 0, sdev->host->cmd_per_lun);
> + scsi_adjust_queue_depth(sdev, 0, 1);
>
> scsi_sysfs_device_initialize(sdev);
>
> @@ -719,9 +719,12 @@ static int scsi_add_lun(struct scsi_devi
> * End sysfs code.
> */
>
> - if ((sdev->scsi_level >= SCSI_2) && (inq_result[7] & 2) &&
> - !(*bflags & BLIST_NOTQ))
> + if ((sdev->scsi_level >= SCSI_2) && ((inq_result[6] & 0x10) ||
> + (inq_result[7] & 2)) && !(*bflags & BLIST_NOTQ)) {
> sdev->tagged_supported = 1;
> + scsi_adjust_queue_depth(sdev, MSG_SIMPLE_TAG,
> + sdev->host->cmd_per_lun);
> + }
> /*
> * Some devices (Texel CD ROM drives) have handshaking problems
> * when used with the Seagate controllers. borken is initialized
>
> -- Patrick Mansfield
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Brian King
eServer Storage I/O
IBM Linux Technology Center
^ permalink raw reply
* [ALSA - driver 0002008]: No Sound with snd-hda-intel driver Asus P5VDC-MX
From: bugtrack @ 2006-04-07 22:29 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:29 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:19
----------------------------------------------------------------------
lspci with onboard sound enabled:
00:00.0 Host bridge: VIA Technologies, Inc. P4M800CE Host Bridge
00:00.1 Host bridge: VIA Technologies, Inc. P4M800CE Host Bridge
00:00.2 Host bridge: VIA Technologies, Inc. P4M800CE Host Bridge
00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge
00:00.4 Host bridge: VIA Technologies, Inc. P4M800CE Host Bridge
00:00.7 Host bridge: VIA Technologies, Inc. P4M800CE Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
00:0f.0 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 07)
00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 90)
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 90)
00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 90)
00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 90)
00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 90)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8251 PCI to ISA Bridge
00:11.5 Multimedia audio controller: VIA Technologies, Inc.
VT8233/A/8235/8237 AC97 Audio Controller (rev 70)
00:11.7 Host bridge: VIA Technologies, Inc. VT8251 Ultra VLINK Controller
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev
7c)
00:13.0 PCI bridge: VIA Technologies, Inc. VT8251 PCI to PCIE Bridge
00:13.1 PCI bridge: VIA Technologies, Inc. VT8251 PCI to PCI Bridge
01:00.0 VGA compatible controller: ATI Technologies Inc RV410 [Radeon X700
(PCIE)]
01:00.1 Display controller: ATI Technologies Inc RV410 [Radeon X700
(PCIE)] (Secondary)
02:00.0 PCI bridge: VIA Technologies, Inc. VT8251 PCIE Root Port
02:00.1 PCI bridge: VIA Technologies, Inc. VT8251 PCIE Root Port
05:08.0 Multimedia audio controller: Ensoniq 5880 AudioPCI (rev 02)
05:09.0 Multimedia video controller: Conexant CX23880/1/2/3 PCI Video and
Audio Decoder (rev 05
----------------------------------------------------------------------
rlrevell - 04-08-06 00:29
----------------------------------------------------------------------
What happens with "aplay file.wav"?
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
======================================================================
-------------------------------------------------------
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] Re: [DNX#2006040842000013] PATCH: CFG_GPIO0_OR [...]
From: U-Boot patch tracking system @ 2006-04-07 22:30 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#2006040842000013].
Your U-Boot support team
Powered by OTRS (http://otrs.org/)
^ permalink raw reply
* [U-Boot-Users] Re: [DNX#2006040842000013] PATCH: CFG_GPIO0_OR and CFG_GPIO0_ODR to setup GPI [...]
From: DENX Support System @ 2006-04-07 22:30 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040842000013] was created:
<snip>
> Re: http://sf.net/mailarchive/forum.php?thread_id=10122605&forum_id=12898
>
> CHANGELOG:
>
> * (ppc4xx) Add CFG_GPIO0_OR, CFG_GPIO0_ODR to setup GPIO completely.
> - Add configuration of Open Drain GPIO Output selection
> - Add configuration of initial value of GPIO output pins
>
> Sign-off-by: Tolunay Orkun <listmember@orkun.us>
>
> diff --git a/cpu/ppc4xx/cpu_init.c b/cpu/ppc4xx/cpu_init.c
> index 1a139d7..761fcf7 100644
> --- a/cpu/ppc4xx/cpu_init.c
> +++ b/cpu/ppc4xx/cpu_init.c
> @@ -115,6 +115,12 @@ cpu_init_f (void)
> /*
> * GPIO0 setup (select GPIO or alternate function)
> */
> +#if defined(CFG_GPIO0_OR)
> + out32(GPIO0_OR, CFG_GPIO0_OR); /* set initial state of output
> pins */
> +#endif
> +#if defined(CFG_GPIO0_ODR)
> + out32(GPIO0_ODR, CFG_GPIO0_ODR); /* open-drain select */
> +#endif
> out32(GPIO0_OSRH, CFG_GPIO0_OSRH); /* output select */
> out32(GPIO0_OSRL, CFG_GPIO0_OSRL);
> out32(GPIO0_ISR1H, CFG_GPIO0_ISR1H); /* input select */
</snip>
Your U-Boot support team
^ permalink raw reply
* Re: multipath disk size
From: Christophe Varoqui @ 2006-04-07 22:31 UTC (permalink / raw)
To: device-mapper development
In-Reply-To: <4436271F.1090509@unibas.ch>
URZ- AG a écrit :
> Hi,
>
> I'm posting my question again, i would really appreciate if someone
> could give me a hint why this happen.
>
>
> I'm trying to setup a FC Storage (Adaptec SANBloc 2Gb) using multipath
> (Kernel 2.6.15 - multipath-tool-0.4.7 on Fedora Core 5 )
> Everything seem to run right, but the disk created by multipath does not
> reflect the physical one.
> I do have a physical volume that is about 67GB big, when multipath
> creates the dm device it is at least 1GB.
> Here is the output of multipath -v3:
> ----------------------------------------------------
> dm-0: blacklisted
> dm-1: blacklisted
> dm-2: blacklisted
> dm-4: blacklisted
> dm-5: blacklisted
> fd0: blacklisted
> hdd: blacklisted
> md0: blacklisted
> ram0: blacklisted
> ram10: blacklisted
> ram11: blacklisted
> ram12: blacklisted
> ram13: blacklisted
> ram14: blacklisted
> ram15: blacklisted
> ram1: blacklisted
> ram2: blacklisted
> ram3: blacklisted
> ram4: blacklisted
> ram5: blacklisted
> ram6: blacklisted
> ram7: blacklisted
> ram8: blacklisted
> ram9: blacklisted
> sda: not found in pathvec
> sda: mask = 0x1f
> sda: bus = 1
> sda: dev_t = 8:0
> sda: size = 71553024
> sda: vendor = LSILOGIC
> sda: product = 1030 IM
> sda: rev = 1000
> sda: h:b:t:l = 0:0:1:0
> sda: serial =
> sda: path checker = readsector0 (config file default)
> sda: state = 2
> sda: getprio = /bin/true (config file default)
> sda: prio = 0
> sda: getuid = /sbin/scsi_id -g -u -s /block/%n (config file default)
> error calling out /sbin/scsi_id -g -u -s /block/sda
> sdb: not found in pathvec
> sdb: mask = 0x1f
> sdb: bus = 1
> sdb: dev_t = 8:16
> sdb: size = 142114816
> sdb: vendor = EUROLOGC
> sdb: product = FC2502
> sdb: rev = 7902
> sdb: h:b:t:l = 2:0:0:0
> sdb: tgt_node_name = 0x20000080e512dc77
> sdb: serial = 0000dc7720000080e512dc770000000000000000
> sdb: path checker = readsector0 (controler setting)
> sdb: state = 2
> sdb: getprio = /bin/true (config file default)
> sdb: prio = 0
> sdb: getuid = /sbin/scsi_id -g -u -p 0x80 -s /block/%n (controler
> setting)
> sdb: uid = SEUROLOGCFC2502_0000dc7720000080e512dc770000000000000000
> (callout)
> sdc: not found in pathvec
> sdc: mask = 0x1f
> sdc: bus = 1
> sdc: dev_t = 8:32
> sdc: size = 142114816
> sdc: vendor = EUROLOGC
> sdc: product = FC2502
> sdc: rev = 7902
> sdc: h:b:t:l = 2:0:1:0
> sdc: tgt_node_name = 0x20000080e512dc77
> sdc: serial = 0000dc7720000080e512dc770000000000000000
> sdc: path checker = readsector0 (controler setting)
> sdc: state = 2
> sdc: getprio = /bin/true (config file default)
> sdc: prio = 0
> sdc: getuid = /sbin/scsi_id -g -u -p 0x80 -s /block/%n (controler
> setting)
> sdc: uid = SEUROLOGCFC2502_0000dc7720000080e512dc770000000000000000
> (callout)
> ===== paths list =====
> uuid hcil dev
> dev_t pri
> 0:0:1:0 sda
> 8:0 0
> SEUROLOGCFC2502_0000dc7720000080e512dc770000000000000000 2:0:0:0 sdb
> 8:16 0
> SEUROLOGCFC2502_0000dc7720000080e512dc770000000000000000 2:0:1:0 sdc
> 8:32 0
> 8:16 ownership set to hdmail
> sdb: not found in pathvec
> sdb: mask = 0xc
> sdb: state = 2
> sdb: prio = 0
> 8:32 ownership set to hdmail
> sdc: not found in pathvec
> sdc: mask = 0xc
> sdc: state = 2
> sdc: prio = 0
> hdmail: pgfailback = -2 (config file default)
> hdmail: pgpolicy = failover (controler setting)
> hdmail: selector = round-robin 0 (controler setting)
> hdmail: features = 0 (internal default)
> hdmail: hwhandler = 0 (internal default)
> hdmail: rr_weight = 2 (config file default)
> hdmail: minio = 100 (config file default)
> hdmail: no_path_retry = -1 (config file default)
> hdmail: set ACT_CREATE (map does not exist)
> hdmail: set ACT_CREATE (map does not exist)
> create: hdmail (SEUROLOGCFC2502_0000dc7720000080e512dc770000000000000000)
> [size=1 GB][features=0][hwhandler=0]
> \_ round-robin 0 [prio=0][undef]
> \_ 2:0:0:0 sdb 8:16 [undef][ready]
> \_ round-robin 0 [prio=0][undef]
> \_ 2:0:1:0 sdc 8:32 [undef][ready]
> ----------------------------------------------------
> When you look at the disk size, it return the correct value but when it
> creates the dm device it does it too small.
>
> When I do create the multipath device using dmsetup it creates it with
> the right size, but as soon as I do runf multipath again it resize the
> device.
>
> Thanks a lot for your work and your help
>
Thanks for this report.
I can't reproduce this here.
I'm afraid I'll have to ask you to try and refine your report though.
Use a debugger to track [m]pp->size changes, or try adding debugging
output in the key code areas : add_map_with_path(), coalesce_paths(), ...
Regards,
cvaroqui
^ permalink raw reply
* [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
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.