* [lm-sensors] Question on my mainboard
From: Dieter Jurzitza @ 2006-04-18 20:53 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <200603282150.16130.dieter.jurzitza@t-online.de>
Dear Rudolf,
dear listmembers,
this is what I get when performing the awk - script Rudolf kindly provided
parsing /var/log/messages in total (~300 MByte):
\058,
\059,
\05a,
\05b,
\091,
\093,
\095,
\097,
\0a0,
\0a1,
\0a2,
\0a3,
\0a4,
\0a5,
\0a8,
\0a9,
> options w83781d force_w83782d=0,0x2d force_subclients=0,0x2d,0x48,0x49
> force_w83627hf=0,0x2c force_subclients=0,0x2c,0x4a,0x4b init=0
>
> So you left the second line there??? and only loading w83627hf with
> force_subclients=0,0x2c,0x4a,0x4b ?
Yes, I left the second line there. I had had taken out the loading of the
w83627hf driver but sensors crashed anyway, so I thought it might be a good
start from where I had had come from - what may be wrong.
> I'm asking because there are more addresses access
This:
> (cat logpart | awk -FADD '{print $2}' |awk '{print $1}' | sort -u)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
gives me the list as shown above.
I left that there because the folks from Tyan told me to use exactly this line
- and the last replies from the lm_sensors list referred to that I should
unload the w83627hf driver and did not refer to the "force_subclients=XXX"
lines. After removing the w83627hf driver there was no change, so I had had
put it back in.
Thanks for your efforts - I am not the I?C - man.
Take care
Dieter
--
-----------------------------------------------------------
|
\
/\_/\ |
| ~x~ |/-----\ /
\ /- \_/
^^__ _ / _ ____ /
<??__ \- \_/ | |/ | |
|| || _| _| _| _|
if you really want to see the pictures above - use some font
with constant spacing like courier! :-)
-----------------------------------------------------------
^ permalink raw reply
* [PATCH 1/1] megaraid_{mm,mbox}: updated fix-a-bug-in-reset-handler
From: Ju, Seokmann @ 2006-04-18 20:52 UTC (permalink / raw)
To: Andrew Morton, andre, James.Bottomley
Cc: Ju, Seokmann, linux-kernel, linux-scsi
[-- Attachment #1: Type: text/plain, Size: 3120 bytes --]
Hi,
This patch has created against 2.6.17-rc1-mm3.
The patch contains changes addressing following concerns brought by
previous megaraid_mmmbox-fix-a-bug-in-reset-handler.patch.
1.Andrew Morton:
> + scb->status = -EFAULT;
What is the significance of -EFAULT here? Seems inappropriate?
2. Andrew Morton:
And if that mbox is in main memory, the duration of this spin
will vary by
a factor of many tens across all the different machines on which
this
driver must operate.
Careful use of ndelay() or udelay() would fix that.
Thank you,
Seokmann
Signed-Off By: Seokmann Ju <seokmann.ju@lsil.com>
---
diff -Naur old/drivers/scsi/megaraid/megaraid_mbox.c
new/drivers/scsi/megaraid/megaraid_mbox.c
--- old/drivers/scsi/megaraid/megaraid_mbox.c 2006-04-18
17:17:06.288025720 -0400
+++ new/drivers/scsi/megaraid/megaraid_mbox.c 2006-04-13
16:46:53.000000000 -0400
@@ -2278,6 +2278,7 @@
unsigned long flags;
uint8_t c;
int status;
+ uioc_t *kioc;
if (!adapter) return;
@@ -2320,6 +2321,9 @@
// remove from local clist
list_del_init(&scb->list);
+ kioc = (uioc_t *)scb->gp;
+ kioc->status = 0;
+
megaraid_mbox_mm_done(adapter, scb);
continue;
@@ -2636,6 +2640,7 @@
int recovery_window;
int recovering;
int i;
+ uioc_t *kioc;
adapter = SCP2ADAPTER(scp);
raid_dev = ADAP2RAIDDEV(adapter);
@@ -2662,7 +2667,10 @@
"megaraid: IOCTL packet with %d[%d:%d] being
reset\n",
scb->sno, scb->dev_channel, scb->dev_target));
- scb->status = -EFAULT;
+ scb->status = -1;
+
+ kioc = (uioc_t *)scb->gp;
+ kioc->status = -EFAULT;
megaraid_mbox_mm_done(adapter, scb);
} else {
@@ -2933,12 +2941,13 @@
wmb();
WRINDOOR(raid_dev, raid_dev->mbox_dma | 0x1);
- for (i = 0; i < 0xFFFFFF; i++) {
+ for (i = 0; i < MBOX_SYNC_WAIT_CNT; i++) {
if (mbox->numstatus != 0xFF) break;
rmb();
+ udelay(MBOX_SYNC_DELAY_200);
}
- if (i == 0xFFFFFF) {
+ if (i == MBOX_SYNC_WAIT_CNT) {
// We may need to re-calibrate the counter
con_log(CL_ANN, (KERN_CRIT
"megaraid: fast sync command timed out\n"));
@@ -3717,7 +3726,6 @@
unsigned long flags;
kioc = (uioc_t *)scb->gp;
- kioc->status = 0;
mbox64 = (mbox64_t *)(unsigned
long)kioc->cmdbuf;
mbox64->mbox32.status = scb->status;
raw_mbox = (uint8_t *)&mbox64->mbox32;
diff -Naur old/drivers/scsi/megaraid/megaraid_mbox.h
new/drivers/scsi/megaraid/megaraid_mbox.h
--- old/drivers/scsi/megaraid/megaraid_mbox.h 2006-04-18
17:17:06.289025568 -0400
+++ new/drivers/scsi/megaraid/megaraid_mbox.h 2006-04-13
16:05:30.000000000 -0400
@@ -100,6 +100,9 @@
#define MBOX_BUSY_WAIT 10 // max usec to wait for busy
mailbox
#define MBOX_RESET_WAIT 180 // wait these many
seconds in reset
#define MBOX_RESET_EXT_WAIT 120 // extended wait reset
+#define MBOX_SYNC_WAIT_CNT 0xFFFF // wait loop index for
synchronous mode
+
+#define MBOX_SYNC_DELAY_200 200 // 200 micro-seconds
/*
* maximum transfer that can happen through the firmware commands
issued
---
[-- Attachment #2: megaraid_mm_mbox_II.patch --]
[-- Type: application/octet-stream, Size: 2387 bytes --]
diff -Naur old/drivers/scsi/megaraid/megaraid_mbox.c new/drivers/scsi/megaraid/megaraid_mbox.c
--- old/drivers/scsi/megaraid/megaraid_mbox.c 2006-04-18 17:17:06.288025720 -0400
+++ new/drivers/scsi/megaraid/megaraid_mbox.c 2006-04-13 16:46:53.000000000 -0400
@@ -2278,6 +2278,7 @@
unsigned long flags;
uint8_t c;
int status;
+ uioc_t *kioc;
if (!adapter) return;
@@ -2320,6 +2321,9 @@
// remove from local clist
list_del_init(&scb->list);
+ kioc = (uioc_t *)scb->gp;
+ kioc->status = 0;
+
megaraid_mbox_mm_done(adapter, scb);
continue;
@@ -2636,6 +2640,7 @@
int recovery_window;
int recovering;
int i;
+ uioc_t *kioc;
adapter = SCP2ADAPTER(scp);
raid_dev = ADAP2RAIDDEV(adapter);
@@ -2662,7 +2667,10 @@
"megaraid: IOCTL packet with %d[%d:%d] being reset\n",
scb->sno, scb->dev_channel, scb->dev_target));
- scb->status = -EFAULT;
+ scb->status = -1;
+
+ kioc = (uioc_t *)scb->gp;
+ kioc->status = -EFAULT;
megaraid_mbox_mm_done(adapter, scb);
} else {
@@ -2933,12 +2941,13 @@
wmb();
WRINDOOR(raid_dev, raid_dev->mbox_dma | 0x1);
- for (i = 0; i < 0xFFFFFF; i++) {
+ for (i = 0; i < MBOX_SYNC_WAIT_CNT; i++) {
if (mbox->numstatus != 0xFF) break;
rmb();
+ udelay(MBOX_SYNC_DELAY_200);
}
- if (i == 0xFFFFFF) {
+ if (i == MBOX_SYNC_WAIT_CNT) {
// We may need to re-calibrate the counter
con_log(CL_ANN, (KERN_CRIT
"megaraid: fast sync command timed out\n"));
@@ -3717,7 +3726,6 @@
unsigned long flags;
kioc = (uioc_t *)scb->gp;
- kioc->status = 0;
mbox64 = (mbox64_t *)(unsigned long)kioc->cmdbuf;
mbox64->mbox32.status = scb->status;
raw_mbox = (uint8_t *)&mbox64->mbox32;
diff -Naur old/drivers/scsi/megaraid/megaraid_mbox.h new/drivers/scsi/megaraid/megaraid_mbox.h
--- old/drivers/scsi/megaraid/megaraid_mbox.h 2006-04-18 17:17:06.289025568 -0400
+++ new/drivers/scsi/megaraid/megaraid_mbox.h 2006-04-13 16:05:30.000000000 -0400
@@ -100,6 +100,9 @@
#define MBOX_BUSY_WAIT 10 // max usec to wait for busy mailbox
#define MBOX_RESET_WAIT 180 // wait these many seconds in reset
#define MBOX_RESET_EXT_WAIT 120 // extended wait reset
+#define MBOX_SYNC_WAIT_CNT 0xFFFF // wait loop index for synchronous mode
+
+#define MBOX_SYNC_DELAY_200 200 // 200 micro-seconds
/*
* maximum transfer that can happen through the firmware commands issued
^ permalink raw reply
* [PATCH 1/1] megaraid_{mm,mbox}: updated fix-a-bug-in-reset-handler
From: Ju, Seokmann @ 2006-04-18 20:52 UTC (permalink / raw)
To: Andrew Morton, andre, James.Bottomley
Cc: Ju, Seokmann, linux-kernel, linux-scsi
[-- Attachment #1: Type: text/plain, Size: 3120 bytes --]
Hi,
This patch has created against 2.6.17-rc1-mm3.
The patch contains changes addressing following concerns brought by
previous megaraid_mmmbox-fix-a-bug-in-reset-handler.patch.
1.Andrew Morton:
> + scb->status = -EFAULT;
What is the significance of -EFAULT here? Seems inappropriate?
2. Andrew Morton:
And if that mbox is in main memory, the duration of this spin
will vary by
a factor of many tens across all the different machines on which
this
driver must operate.
Careful use of ndelay() or udelay() would fix that.
Thank you,
Seokmann
Signed-Off By: Seokmann Ju <seokmann.ju@lsil.com>
---
diff -Naur old/drivers/scsi/megaraid/megaraid_mbox.c
new/drivers/scsi/megaraid/megaraid_mbox.c
--- old/drivers/scsi/megaraid/megaraid_mbox.c 2006-04-18
17:17:06.288025720 -0400
+++ new/drivers/scsi/megaraid/megaraid_mbox.c 2006-04-13
16:46:53.000000000 -0400
@@ -2278,6 +2278,7 @@
unsigned long flags;
uint8_t c;
int status;
+ uioc_t *kioc;
if (!adapter) return;
@@ -2320,6 +2321,9 @@
// remove from local clist
list_del_init(&scb->list);
+ kioc = (uioc_t *)scb->gp;
+ kioc->status = 0;
+
megaraid_mbox_mm_done(adapter, scb);
continue;
@@ -2636,6 +2640,7 @@
int recovery_window;
int recovering;
int i;
+ uioc_t *kioc;
adapter = SCP2ADAPTER(scp);
raid_dev = ADAP2RAIDDEV(adapter);
@@ -2662,7 +2667,10 @@
"megaraid: IOCTL packet with %d[%d:%d] being
reset\n",
scb->sno, scb->dev_channel, scb->dev_target));
- scb->status = -EFAULT;
+ scb->status = -1;
+
+ kioc = (uioc_t *)scb->gp;
+ kioc->status = -EFAULT;
megaraid_mbox_mm_done(adapter, scb);
} else {
@@ -2933,12 +2941,13 @@
wmb();
WRINDOOR(raid_dev, raid_dev->mbox_dma | 0x1);
- for (i = 0; i < 0xFFFFFF; i++) {
+ for (i = 0; i < MBOX_SYNC_WAIT_CNT; i++) {
if (mbox->numstatus != 0xFF) break;
rmb();
+ udelay(MBOX_SYNC_DELAY_200);
}
- if (i == 0xFFFFFF) {
+ if (i == MBOX_SYNC_WAIT_CNT) {
// We may need to re-calibrate the counter
con_log(CL_ANN, (KERN_CRIT
"megaraid: fast sync command timed out\n"));
@@ -3717,7 +3726,6 @@
unsigned long flags;
kioc = (uioc_t *)scb->gp;
- kioc->status = 0;
mbox64 = (mbox64_t *)(unsigned
long)kioc->cmdbuf;
mbox64->mbox32.status = scb->status;
raw_mbox = (uint8_t *)&mbox64->mbox32;
diff -Naur old/drivers/scsi/megaraid/megaraid_mbox.h
new/drivers/scsi/megaraid/megaraid_mbox.h
--- old/drivers/scsi/megaraid/megaraid_mbox.h 2006-04-18
17:17:06.289025568 -0400
+++ new/drivers/scsi/megaraid/megaraid_mbox.h 2006-04-13
16:05:30.000000000 -0400
@@ -100,6 +100,9 @@
#define MBOX_BUSY_WAIT 10 // max usec to wait for busy
mailbox
#define MBOX_RESET_WAIT 180 // wait these many
seconds in reset
#define MBOX_RESET_EXT_WAIT 120 // extended wait reset
+#define MBOX_SYNC_WAIT_CNT 0xFFFF // wait loop index for
synchronous mode
+
+#define MBOX_SYNC_DELAY_200 200 // 200 micro-seconds
/*
* maximum transfer that can happen through the firmware commands
issued
---
[-- Attachment #2: megaraid_mm_mbox_II.patch --]
[-- Type: application/octet-stream, Size: 2387 bytes --]
diff -Naur old/drivers/scsi/megaraid/megaraid_mbox.c new/drivers/scsi/megaraid/megaraid_mbox.c
--- old/drivers/scsi/megaraid/megaraid_mbox.c 2006-04-18 17:17:06.288025720 -0400
+++ new/drivers/scsi/megaraid/megaraid_mbox.c 2006-04-13 16:46:53.000000000 -0400
@@ -2278,6 +2278,7 @@
unsigned long flags;
uint8_t c;
int status;
+ uioc_t *kioc;
if (!adapter) return;
@@ -2320,6 +2321,9 @@
// remove from local clist
list_del_init(&scb->list);
+ kioc = (uioc_t *)scb->gp;
+ kioc->status = 0;
+
megaraid_mbox_mm_done(adapter, scb);
continue;
@@ -2636,6 +2640,7 @@
int recovery_window;
int recovering;
int i;
+ uioc_t *kioc;
adapter = SCP2ADAPTER(scp);
raid_dev = ADAP2RAIDDEV(adapter);
@@ -2662,7 +2667,10 @@
"megaraid: IOCTL packet with %d[%d:%d] being reset\n",
scb->sno, scb->dev_channel, scb->dev_target));
- scb->status = -EFAULT;
+ scb->status = -1;
+
+ kioc = (uioc_t *)scb->gp;
+ kioc->status = -EFAULT;
megaraid_mbox_mm_done(adapter, scb);
} else {
@@ -2933,12 +2941,13 @@
wmb();
WRINDOOR(raid_dev, raid_dev->mbox_dma | 0x1);
- for (i = 0; i < 0xFFFFFF; i++) {
+ for (i = 0; i < MBOX_SYNC_WAIT_CNT; i++) {
if (mbox->numstatus != 0xFF) break;
rmb();
+ udelay(MBOX_SYNC_DELAY_200);
}
- if (i == 0xFFFFFF) {
+ if (i == MBOX_SYNC_WAIT_CNT) {
// We may need to re-calibrate the counter
con_log(CL_ANN, (KERN_CRIT
"megaraid: fast sync command timed out\n"));
@@ -3717,7 +3726,6 @@
unsigned long flags;
kioc = (uioc_t *)scb->gp;
- kioc->status = 0;
mbox64 = (mbox64_t *)(unsigned long)kioc->cmdbuf;
mbox64->mbox32.status = scb->status;
raw_mbox = (uint8_t *)&mbox64->mbox32;
diff -Naur old/drivers/scsi/megaraid/megaraid_mbox.h new/drivers/scsi/megaraid/megaraid_mbox.h
--- old/drivers/scsi/megaraid/megaraid_mbox.h 2006-04-18 17:17:06.289025568 -0400
+++ new/drivers/scsi/megaraid/megaraid_mbox.h 2006-04-13 16:05:30.000000000 -0400
@@ -100,6 +100,9 @@
#define MBOX_BUSY_WAIT 10 // max usec to wait for busy mailbox
#define MBOX_RESET_WAIT 180 // wait these many seconds in reset
#define MBOX_RESET_EXT_WAIT 120 // extended wait reset
+#define MBOX_SYNC_WAIT_CNT 0xFFFF // wait loop index for synchronous mode
+
+#define MBOX_SYNC_DELAY_200 200 // 200 micro-seconds
/*
* maximum transfer that can happen through the firmware commands issued
^ permalink raw reply
* [PATCH -mm] swsusp: rework memory shrinker (rev. 2)
From: Rafael J. Wysocki @ 2006-04-18 20:48 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, pavel, kernel
In-Reply-To: <200604181355.51318.rjw@sisk.pl>
On Tuesday 18 April 2006 13:55, Rafael J. Wysocki wrote:
> On Tuesday 18 April 2006 13:47, Rafael J. Wysocki wrote:
> > On Tuesday 18 April 2006 12:13, Andrew Morton wrote:
> > > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > > >
> > > > Rework the swsusp's memory shrinker in the following way:
> > >
> > > And what was the observed effect of all this?
> >
> > Measurable effects:
> > 1) It tends to free only as much memory as required, eg. if the image_size
> > is set to 450 MB, the actual image sizes are almost always well above
> > 400 MB and they tended to be below that number without the patch
> > (~5-10% of a difference, but still :-)).
> > 2) If image_size = 0, it frees everything that can be freed without any
> > workarounds (we had to add the additional loop checking for
> > ret >= nr_pages with the additional blk_congestion_wait() to the
> > "original" shrinker to achieve this).
> >
> > A non-measurable effect is that with the patch applied the system seems to
> > be more responsive after resume, but of course this may be an illusion.
> >
> > >
> > > > + /* Force reclaiming mapped pages in the passes #3 and #4 */
> > > > + if (pass > 2) {
> > > > + sc.may_swap = 1;
> > > > + vm_swappiness = 100;
> > > > + }
> > >
> > > That's a bit klunky. Maybe we should move swappiness into scan_control.
> >
> > Alternatively we can temporarily set zone->prev_priority to 100 in
> > shrink_all_zones() if pass > 2?
>
> s/100/0/
>
> Sorry.
In the appended version of the patch swappiness has been moved into
struct scan_control as you suggested.
---
Rework the swsusp's memory shrinker in the following way:
1) Simplify balance_pgdat() by removing all of the swsusp-related code from it.
2) Make shrink_all_memory() use shrink_slab() and a new function
shrink_all_zones() which calls shrink_active_list() and shrink_inactive_list()
directly for each zone in a way that's optimized for suspend.
In shrink_all_memory() we try to free exactly as many pages as the caller
asks for, preferably in one shot, starting from easier targets. If slab caches
are huge, they are most likely to have enough pages to reclaim. The
inactive lists are next (the zones with more inactive pages go first) etc.
Each time shrink_all_memory() attempts to shrink the active and inactive lists
for each zone in 5 passes. In the first pass, only the inactive lists are
taken into consideration. In the next two passes the active lists are also
shrunk, but mapped pages are not reclaimed. In the last two passes the
active and inactive lists are shrunk and mapped pages are reclaimed as well.
The aim of this is to alter the reclaim logic to choose the best pages to keep
on resume and improve the responsiveness of the resumed system.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Con Kolivas <kernel@kolivas.org>
---
kernel/power/swsusp.c | 10 +-
mm/vmscan.c | 222 +++++++++++++++++++++++++++++++++++++-------------
2 files changed, 174 insertions(+), 58 deletions(-)
Index: linux-2.6.17-rc1-mm3/mm/vmscan.c
===================================================================
--- linux-2.6.17-rc1-mm3.orig/mm/vmscan.c 2006-04-18 20:59:43.000000000 +0200
+++ linux-2.6.17-rc1-mm3/mm/vmscan.c 2006-04-18 21:57:45.000000000 +0200
@@ -62,6 +62,8 @@ struct scan_control {
* In this context, it doesn't matter that we scan the
* whole list at once. */
int swap_cluster_max;
+
+ int swappiness;
};
#define lru_to_page(_head) (list_entry((_head)->prev, struct page, lru))
@@ -744,7 +746,7 @@ static void shrink_active_list(unsigned
* A 100% value of vm_swappiness overrides this algorithm
* altogether.
*/
- swap_tendency = mapped_ratio / 2 + distress + vm_swappiness;
+ swap_tendency = mapped_ratio / 2 + distress + sc->swappiness;
/*
* Now use this metric to decide whether to start moving mapped
@@ -960,6 +962,7 @@ unsigned long try_to_free_pages(struct z
.may_writepage = !laptop_mode,
.swap_cluster_max = SWAP_CLUSTER_MAX,
.may_swap = 1,
+ .swappiness = vm_swappiness,
};
delay_swap_prefetch();
@@ -1026,10 +1029,6 @@ out:
* For kswapd, balance_pgdat() will work across all this node's zones until
* they are all at pages_high.
*
- * If `nr_pages' is non-zero then it is the number of pages which are to be
- * reclaimed, regardless of the zone occupancies. This is a software suspend
- * special.
- *
* Returns the number of pages which were actually freed.
*
* There is special handling here for zones which are full of pinned pages.
@@ -1047,10 +1046,8 @@ out:
* the page allocator fallback scheme to ensure that aging of pages is balanced
* across the zones.
*/
-static unsigned long balance_pgdat(pg_data_t *pgdat, unsigned long nr_pages,
- int order)
+static unsigned long balance_pgdat(pg_data_t *pgdat, int order)
{
- unsigned long to_free = nr_pages;
int all_zones_ok;
int priority;
int i;
@@ -1060,7 +1057,8 @@ static unsigned long balance_pgdat(pg_da
struct scan_control sc = {
.gfp_mask = GFP_KERNEL,
.may_swap = 1,
- .swap_cluster_max = nr_pages ? nr_pages : SWAP_CLUSTER_MAX,
+ .swap_cluster_max = SWAP_CLUSTER_MAX,
+ .swappiness = vm_swappiness,
};
loop_again:
@@ -1087,31 +1085,27 @@ loop_again:
all_zones_ok = 1;
- if (nr_pages == 0) {
- /*
- * Scan in the highmem->dma direction for the highest
- * zone which needs scanning
- */
- for (i = pgdat->nr_zones - 1; i >= 0; i--) {
- struct zone *zone = pgdat->node_zones + i;
+ /*
+ * Scan in the highmem->dma direction for the highest
+ * zone which needs scanning
+ */
+ for (i = pgdat->nr_zones - 1; i >= 0; i--) {
+ struct zone *zone = pgdat->node_zones + i;
+
+ if (!populated_zone(zone))
+ continue;
- if (!populated_zone(zone))
- continue;
+ if (zone->all_unreclaimable &&
+ priority != DEF_PRIORITY)
+ continue;
- if (zone->all_unreclaimable &&
- priority != DEF_PRIORITY)
- continue;
-
- if (!zone_watermark_ok(zone, order,
- zone->pages_high, 0, 0)) {
- end_zone = i;
- goto scan;
- }
+ if (!zone_watermark_ok(zone, order, zone->pages_high,
+ 0, 0)) {
+ end_zone = i;
+ goto scan;
}
- goto out;
- } else {
- end_zone = pgdat->nr_zones - 1;
}
+ goto out;
scan:
for (i = 0; i <= end_zone; i++) {
struct zone *zone = pgdat->node_zones + i;
@@ -1138,11 +1132,9 @@ scan:
if (zone->all_unreclaimable && priority != DEF_PRIORITY)
continue;
- if (nr_pages == 0) { /* Not software suspend */
- if (!zone_watermark_ok(zone, order,
- zone->pages_high, end_zone, 0))
- all_zones_ok = 0;
- }
+ if (!zone_watermark_ok(zone, order, zone->pages_high,
+ end_zone, 0))
+ all_zones_ok = 0;
zone->temp_priority = priority;
if (zone->prev_priority > priority)
zone->prev_priority = priority;
@@ -1167,8 +1159,6 @@ scan:
total_scanned > nr_reclaimed + nr_reclaimed / 2)
sc.may_writepage = 1;
}
- if (nr_pages && to_free > nr_reclaimed)
- continue; /* swsusp: need to do more work */
if (all_zones_ok)
break; /* kswapd: all done */
/*
@@ -1184,7 +1174,7 @@ scan:
* matches the direct reclaim path behaviour in terms of impact
* on zone->*_priority.
*/
- if ((nr_reclaimed >= SWAP_CLUSTER_MAX) && !nr_pages)
+ if (nr_reclaimed >= SWAP_CLUSTER_MAX)
break;
}
out:
@@ -1266,7 +1256,7 @@ static int kswapd(void *p)
}
finish_wait(&pgdat->kswapd_wait, &wait);
- balance_pgdat(pgdat, 0, order);
+ balance_pgdat(pgdat, order);
}
return 0;
}
@@ -1295,37 +1285,156 @@ void wakeup_kswapd(struct zone *zone, in
#ifdef CONFIG_PM
/*
- * Try to free `nr_pages' of memory, system-wide. Returns the number of freed
- * pages.
+ * Helper function for shrink_all_memory(). Tries to reclaim 'nr_pages' pages
+ * from LRU lists system-wide, for given pass and priority, and returns the
+ * number of reclaimed pages
+ *
+ * For pass > 3 we also try to shrink the LRU lists that contain a few pages
+ */
+unsigned long shrink_all_zones(unsigned long nr_pages, int pass, int prio,
+ struct scan_control *sc)
+{
+ struct zone *zone;
+ unsigned long nr_to_scan, ret = 0;
+
+ for_each_zone(zone) {
+
+ if (!populated_zone(zone))
+ continue;
+
+ if (zone->all_unreclaimable && prio != DEF_PRIORITY)
+ continue;
+
+ /* For pass = 0 we don't shrink the active list */
+ if (pass > 0) {
+ zone->nr_scan_active += (zone->nr_active >> prio) + 1;
+ if (zone->nr_scan_active >= nr_pages || pass > 3) {
+ zone->nr_scan_active = 0;
+ nr_to_scan = min(nr_pages, zone->nr_active);
+ shrink_active_list(nr_to_scan, zone, sc);
+ }
+ }
+
+ zone->nr_scan_inactive += (zone->nr_inactive >> prio) + 1;
+ if (zone->nr_scan_inactive >= nr_pages || pass > 3) {
+ zone->nr_scan_inactive = 0;
+ nr_to_scan = min(nr_pages, zone->nr_inactive);
+ ret += shrink_inactive_list(nr_to_scan, zone, sc);
+ if (ret >= nr_pages)
+ return ret;
+ }
+ }
+
+ return ret;
+}
+
+/*
+ * Try to free `nr_pages' of memory, system-wide, and return the number of
+ * freed pages.
+ *
+ * Rather than trying to age LRUs the aim is to preserve the overall
+ * LRU order by reclaiming preferentially
+ * inactive > active > active referenced > active mapped
*/
unsigned long shrink_all_memory(unsigned long nr_pages)
{
- pg_data_t *pgdat;
- unsigned long nr_to_free = nr_pages;
+ unsigned long lru_pages, nr_slab;
unsigned long ret = 0;
- unsigned retry = 2;
- struct reclaim_state reclaim_state = {
- .reclaimed_slab = 0,
+ int pass;
+ struct reclaim_state reclaim_state;
+ struct zone *zone;
+ struct scan_control sc = {
+ .gfp_mask = GFP_KERNEL,
+ .may_swap = 0,
+ .swap_cluster_max = nr_pages,
+ .may_writepage = 1,
+ .swappiness = vm_swappiness,
};
delay_swap_prefetch();
current->reclaim_state = &reclaim_state;
-repeat:
- for_each_online_pgdat(pgdat) {
- unsigned long freed;
- freed = balance_pgdat(pgdat, nr_to_free, 0);
- ret += freed;
- nr_to_free -= freed;
- if ((long)nr_to_free <= 0)
+ lru_pages = 0;
+ for_each_zone(zone)
+ lru_pages += zone->nr_active + zone->nr_inactive;
+
+ nr_slab = read_page_state(nr_slab);
+ /* If slab caches are huge, it's better to hit them first */
+ while (nr_slab >= lru_pages) {
+ reclaim_state.reclaimed_slab = 0;
+ shrink_slab(nr_pages, sc.gfp_mask, lru_pages);
+ if (!reclaim_state.reclaimed_slab)
break;
+
+ ret += reclaim_state.reclaimed_slab;
+ if (ret >= nr_pages)
+ goto out;
+
+ nr_slab -= reclaim_state.reclaimed_slab;
}
- if (retry-- && ret < nr_pages) {
- blk_congestion_wait(WRITE, HZ/5);
- goto repeat;
+
+ /*
+ * We try to shrink LRUs in 5 passes:
+ * 0 = Reclaim from inactive_list only
+ * 1 = Reclaim from active list but don't reclaim mapped
+ * 2 = 2nd pass of type 1
+ * 3 = Reclaim mapped (normal reclaim)
+ * 4 = 2nd pass of type 3
+ */
+ for (pass = 0; pass < 5; pass++) {
+ int prio;
+
+ /* Needed for shrinking slab caches later on */
+ if (!lru_pages)
+ for_each_zone(zone) {
+ lru_pages += zone->nr_active;
+ lru_pages += zone->nr_inactive;
+ }
+
+ /* Force reclaiming mapped pages in the passes #3 and #4 */
+ if (pass > 2) {
+ sc.may_swap = 1;
+ sc.swappiness = 100;
+ }
+
+ for (prio = DEF_PRIORITY; prio >= 0; prio--) {
+ unsigned long nr_to_scan = nr_pages - ret;
+
+ sc.nr_mapped = read_page_state(nr_mapped);
+ sc.nr_scanned = 0;
+
+ ret += shrink_all_zones(nr_to_scan, prio, pass, &sc);
+ if (ret >= nr_pages)
+ goto out;
+
+ reclaim_state.reclaimed_slab = 0;
+ shrink_slab(sc.nr_scanned, sc.gfp_mask, lru_pages);
+ ret += reclaim_state.reclaimed_slab;
+ if (ret >= nr_pages)
+ goto out;
+
+ if (sc.nr_scanned && prio < DEF_PRIORITY - 2)
+ blk_congestion_wait(WRITE, HZ / 10);
+ }
+
+ lru_pages = 0;
}
+
+ /*
+ * If ret = 0, we could not shrink LRUs, but there may be something
+ * in slab caches
+ */
+ if (!ret)
+ do {
+ reclaim_state.reclaimed_slab = 0;
+ shrink_slab(nr_pages, sc.gfp_mask, lru_pages);
+ ret += reclaim_state.reclaimed_slab;
+ } while (ret < nr_pages && reclaim_state.reclaimed_slab > 0);
+
+out:
current->reclaim_state = NULL;
+
return ret;
}
#endif
@@ -1423,6 +1532,7 @@ static int __zone_reclaim(struct zone *z
.swap_cluster_max = max_t(unsigned long, nr_pages,
SWAP_CLUSTER_MAX),
.gfp_mask = gfp_mask,
+ .swappiness = vm_swappiness,
};
disable_swap_token();
Index: linux-2.6.17-rc1-mm3/kernel/power/swsusp.c
===================================================================
--- linux-2.6.17-rc1-mm3.orig/kernel/power/swsusp.c 2006-04-18 20:59:43.000000000 +0200
+++ linux-2.6.17-rc1-mm3/kernel/power/swsusp.c 2006-04-18 20:59:56.000000000 +0200
@@ -165,6 +165,12 @@ void free_all_swap_pages(int swap, struc
*/
#define SHRINK_BITE 10000
+static inline unsigned long __shrink_memory(long tmp)
+{
+ if (tmp > SHRINK_BITE)
+ tmp = SHRINK_BITE;
+ return shrink_all_memory(tmp);
+}
int swsusp_shrink_memory(void)
{
@@ -187,12 +193,12 @@ int swsusp_shrink_memory(void)
tmp += zone->lowmem_reserve[ZONE_NORMAL];
}
if (tmp > 0) {
- tmp = shrink_all_memory(SHRINK_BITE);
+ tmp = __shrink_memory(tmp);
if (!tmp)
return -ENOMEM;
pages += tmp;
} else if (size > image_size / PAGE_SIZE) {
- tmp = shrink_all_memory(SHRINK_BITE);
+ tmp = __shrink_memory(size - (image_size / PAGE_SIZE));
pages += tmp;
}
printk("\b%c", p[i++%4]);
^ permalink raw reply
* Re: Next problem: empty ident <joern@limerick.(none)> not allowed
From: Linus Torvalds @ 2006-04-18 20:47 UTC (permalink / raw)
To: Jörn Engel; +Cc: git
In-Reply-To: <20060418202525.GD25688@wohnheim.fh-wedel.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1426 bytes --]
On Tue, 18 Apr 2006, Jörn Engel wrote:
>
> And now I have some questions:
> 1. Why didn't the environment variables work?
They do. But they just described the _author_. Git wanted the _committer_
to be described too.
So if you had used GIT_COMMITTER_NAME/EMAIL, everything would have been
fine.
Notice that if you don't give any author information, git will assume that
the committer is the author, so if you give committer information, you
don't actually need to give author information. It "knows" that the
committer is you, and since you don't tell it otherwise, it will think
that you're the author too.
So the committer is always the "default author".
But the reverse is _not_ true: even if you tell git who the author is, it
will _not_ assume that the committer is the same one. It knows that the
committer is you, but you didn't talk about yourself, you just talked
about the author.
That non-symmetric behaviour does make a lot of sense, if you think about
it a while. The author is _not_ the "default committer".
Putting your name and email in the git config file solves the problem,
because then git knows who the committer is (and by extension, the
"default author").
> 2. Why is there a check for commit information when I pull from some
> tree?
Because you're going to create a merge commit. It wants to know who to
attribute that merge to. Why the committer is, in other words.
Linus
^ permalink raw reply
* [ALSA - driver 0002035]: Realtek 861 card not functional using included alsa drivers
From: bugtrack @ 2006-04-18 20:45 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2035>
======================================================================
Reported By: vertex
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 2035
Category: PCI - hda-intel
Reproducibility: always
Severity: major
Priority: normal
Status: assigned
Distribution: Fedora Core 5
Kernel Version: 2.6.16-1.2080_FC5smp
======================================================================
Date Submitted: 04-18-2006 20:00 CEST
Last Modified: 04-18-2006 22:45 CEST
======================================================================
Summary: Realtek 861 card not functional using included alsa
drivers
Description:
I am using the FC5 drivers to begin with. The packages are labeled version
1.0.11rc2. There are only a few options when I run alsamixer. Using the
stock drivers, I have these options:
Headphone switch
CD level
Mic level
Input Source switch(Mic/CD)
I compiled the 1.0.11rc5 drivers from source and rebooted. I now have
these channels when I run alsamixer:
Front switch
CD level
Mic level
Input Source switch(Mic/CD)
I tried compiling the 1.0.9 drivers from Realtek's website(said nothing
about the 861), but they did not build. In fact, the install script
overwrote my asound libraries requiring a package replacement to get back
to a sane state.
Please let me know if there is something more I can provide.
======================================================================
----------------------------------------------------------------------
vertex - 04-18-06 22:32
----------------------------------------------------------------------
Forgive my ignorance(and typo). I tried again using model=auto and have the
same result. I don't have 3 jacks on this machine, only two.
----------------------------------------------------------------------
rlrevell - 04-18-06 22:45
----------------------------------------------------------------------
I would not expect it to work with model=auto as that is the default. Try
the other options
Issue History
Date Modified Username Field Change
======================================================================
04-18-06 20:00 vertex New Issue
04-18-06 20:00 vertex Distribution => Fedora Core 5
04-18-06 20:00 vertex Kernel Version => 2.6.16-1.2080_FC5smp
04-18-06 20:09 rlrevell Note Added: 0009339
04-18-06 20:25 pzad Note Added: 0009340
04-18-06 20:40 vertex Note Added: 0009342
04-18-06 20:50 vertex Note Added: 0009343
04-18-06 22:25 rlrevell Note Added: 0009345
04-18-06 22:32 vertex Note Added: 0009346
04-18-06 22:45 rlrevell Note Added: 0009347
======================================================================
-------------------------------------------------------
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
* [Xenomai-core] [patch] readme.install & troubleshooting
From: Jim Cromie @ 2006-04-18 20:44 UTC (permalink / raw)
To: xenomai-core
[-- Attachment #1: Type: text/plain, Size: 1069 bytes --]
heres another try, adjusting per Rodrigo's, Gilles' feedback,
and filling in from linux Kconfig and wikipedia on ACPI.
FYI, the latter is quite informative, esp on sleep states.
The speculative content continues - I dont mind being wrong,
esp when its temporary / corrected :-)
I held back a bit on one wild conjecture,
which connects to the xeno-stats effort / discussion.
Ill start with a Q, and see where it goes:
(feel free to change subject when replying ;-)
Ive seen idle=poll boot-arg fix the Geode SC-1100's buggy TSC
by preventing it from entering C1 state (conjecture-1 ? ;).
Might this also 'fix' the latency problems caused by ACPI_PROCESSOR ?
If so, it improves flexibility by a little, allowing some latency
decisions to be made at boot time rather than compile time.
Not quite as flexible as toggling linux-scheduler-idle behavior via sysctl,
but it doesnt introduce new code either.
I'll be testing this notion on my laptop (which has an ACPI BIOS)
when time permits, but would appreciate guesses as to probability
of useful results, tips, etc.
[-- Attachment #2: patch-readme-3 --]
[-- Type: text/plain, Size: 5899 bytes --]
Index: TROUBLESHOOTING
===================================================================
--- TROUBLESHOOTING (revision 946)
+++ TROUBLESHOOTING (working copy)
@@ -6,6 +6,57 @@
GENERIC
===================================================================
+Q: Which CONFIG_* items are latency killers, and should be avoided ?
+
+A: Heres an enumeration. Several of these are discussed in greater
+detail in following sections.
+
+CONFIG_CPU_FREQ: This allows the CPU frequency to be modulated with
+workload, but many CPUs change the TSC counting frequency also, which
+makes it useless for accurate timing when the CPU clock can change.
+Also some CPUs can take several milliseconds to ramp up to full speed.
+
+APM: The APM model assigns power management control to the BIOS, and
+BIOS code is never written with RT-latency in mind. If configured,
+APM routines are invoked with SMI priority, which breaks the rule that
+adeos-ipipe must be in charge of such things. DISABLE_SMI doesnt help
+here (more later).
+
+ACPI_PROCESSOR: For systems with ACPI support in the BIOS, this ACPI
+sub-option installs an 'idle' handler that uses ACPI C2 and C3
+processor states to save power. The CPU must 'warm-up' from these
+sleep states, increasing latency in ways dependent upon both the
+BIOS's ACPI tables and code. You may be able to suppress the sleeping
+with 'idle=poll' boot-arg, test to find out
+
+Summarizing, the latencies incurred here are dependent upon CPU, BIOS,
+and motherboard; ie they're hard to predict, so we are conservative.
+Feel free to test on your platform, (xeno-test runs testsuite/latency
+in 3 modes), but keep in mind that before you rely on the numbers, you
+must test with workloads that will exercise all the hardware used for
+your RT application.
+
+______________________________________________________________________
+
+Q: How do I adequately stress-test ?
+
+A: xeno-test has a very basic workload generator, whose main virtue is
+that its nearly universally available.
+
+ dd if=/dev/zero of=/dev/null
+
+You can change the input device (-d /dev/hda1) to get real device
+activity and interrupts, and/or -w 4 to run more workload tasks. For
+more thorough testing, use -W <your-script>.
+
+If you are looking for real heavy loads, cache benchmarks tend to
+stress your system the most, http://www.cwi.nl/~manegold/Calibrator
+for example. Combine them with heavy i/o load (flood ping etc.) to
+generate device interrupts. Also consider benchmarking software, such
+as bonnie++, cpuburn, lmbench.
+
+______________________________________________________________________
+
Q: My user-space application has unexpected latencies which seem to
appear when transitioning from primary (Xenomai) to secondary (native
Linux) real-time modes. Why?
Index: README.INSTALL
===================================================================
--- README.INSTALL (revision 946)
+++ README.INSTALL (working copy)
@@ -74,12 +74,14 @@
Once the target kernel has been prepared, all Xenomai configuration
options are available from the "Real-time subsystem" toplevel menu.
-Once configured, the kernel should be built as usual.
+There are several configure options that cause large latencies; they
+should be avoided. The TROUBLESHOOTING file identifies them and
+explains the issues with their use. Once configured, the kernel
+should be built as usual.
-It might be a good idea to put all the output into a different build
-directory as to build from from linux source several targets. For each
-target add O=../build-<target> to each make invocation. See section 2.2
-for an example.
+If you want several different configs/builds at hand, you can reuse
+the same source by adding O=../build-<target> to each make
+invocation. See section 2.2 for an example.
In order to cross-compile the Linux kernel, pass an ARCH and
CROSS_COMPILE variable on make command line. See sections 2.2, 2.3 and
@@ -105,7 +107,9 @@
albeit the kernel has been compiled with CONFIG_X86_TSC disabled would
certainly lead to runtime problems if uncaught, since Xenomai and the
application would not agree on the high precision clock to use for
-their timings.
+their timings. Furthermore, most of these issues cannot be probed for
+during compilation, because the target generally has different
+features than the host, even when theyre the same arch (ex 386 vs 686)
In order to solve those potential issues, each Xenomai architecture
port defines a set of critical features which is tested for
@@ -126,8 +130,8 @@
kernel built with CONFIG_X86_TSC set, since the x86-tsc option's
binding is strong.
-1.3.2 Generic options
----------------------
+1.3.2 Generic configure options
+-------------------------------
NAME DESCRIPTION [BINDING,]DEFAULT(*)
@@ -137,15 +141,17 @@
--enable-debug Enable debug symbols (-g) disabled
--enable-smp Enable SMP support weak,disabled
-1.3.3 Arch-specific options
----------------------------
+1.3.3 Arch-specific configure options
+-------------------------------------
NAME DESCRIPTION [BINDING,]DEFAULT(*)
--enable-x86-sep Enable x86 SEP instructions strong,disabled
- for issuing syscalls
+ for issuing syscalls.
+ You will also need NPTL
--enable-x86-tsc Enable x86 TSC for timings strong,enabled
+ You must have TSC for this.
--enable-arm-arch Define version of the target strong,"4"
ARM core architecture
@@ -254,7 +260,7 @@
2.4 Building for the Blackfin
-----------------------------
-The Blackfin is a MMU-less, DSP-type architecture running
+The Blackfin is an MMU-less, DSP-type architecture running
uClinux.
$ $xenomai_root/scripts/prepare-kernel.sh --arch=blackfin \
^ permalink raw reply
* Re: [Fireflier-devel] Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks
From: Serge E. Hallyn @ 2006-04-18 20:42 UTC (permalink / raw)
To: T?r?k Edwin
Cc: fireflier-devel, Arjan van de Ven, Crispin Cowan, Karl MacMillan,
Gerrit Huizenga, Christoph Hellwig, James Morris, Serge E. Hallyn,
Stephen Smalley, casey, linux-security-module, linux-kernel
In-Reply-To: <200604182313.05604.edwin@gurde.com>
Quoting T?r?k Edwin (edwin@gurde.com):
> On Tuesday 18 April 2006 22:50, Arjan van de Ven wrote:
> >
> > I would suspect that the "filename" thing will be the biggest achilles
> > heel...
> > after all what does filename mean in a linux world with
> > * hardlinks
> > * chroot
> > * namespaces
> > * bind mounts
> > * unlink of open files
> > * fd passing over unix sockets
> > * relative pathnames
> > * multiple threads (where one can unlink+replace file while the other is
> > in the validation code)
>
> FYI fireflier v1.1.x created rules based on filenames.
> In the current version we intended to use mountpoint+inode to identify
> programs. This reduces the potential problems from your list to: fd passing.
>
> Can't AppArmor use inodes in addition to filenames to implement its rules?
> The user could still make its choice based on a "filename" (in an interactive
Doesn't help with, for instance, /etc/shadow. Run passwd once and the
inode number is obsolete.
So either you find a way to decisively use the pathname to identify it,
or you make sure that anyone who can replace it, labels it.
> - use extended attributes to label files, using selinux's setfiles. Most
> secure option IMHO
Again, xattrs alone may be insufficient if the file can be replaced.
> - store rules based on mountpoint+inode+program hash/checksum, and then get
> selinux to label files according to this. Not sure how to do this, and if it
> is worth at all
Again, you're only addressing initial labeling. But I guess you're
labeling executables so that should be fine.
-serge
^ permalink raw reply
* Re: [Bluez-users] sniff & pand
From: Steven Singer @ 2006-04-18 20:42 UTC (permalink / raw)
To: bluez-users
In-Reply-To: <20060407214713.M40337@cos.ufrj.br>
Alexandre Coser Monteiro wrote:
> 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.
Then you've not been looking very hard.
Since you're sending raw commands, bypassing BlueZ and talking directly
to the controller, perhaps you should read the HCI specification.
Bluetooth 2.0 + EDR spec, volume 3, part E, section 5.2, page 375:
* Unless noted otherwise, all parameter values are sent and received
in Little Endian format
- Steven
--
To access the latest news from CSR copy this link into a web browser: http://www.csr.com/email_sig.php
-------------------------------------------------------
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
* question (bug?) in xeno-linux code
From: Runting Shi @ 2006-04-18 20:41 UTC (permalink / raw)
To: xen-devel
Hey, in xeno-linux, arch/i386/mm/pgtable-xen.c (line 363),
why are we doing set_pgd(&pgd[USER_PTRS_PER_PGD], __pgd(1 + __pa(pmd)));
shouldn't it be set_pgd(&pgd[USER_PTRS_PER_PGD + i], __pgd(1 + __pa(pmd)))
or something?
I am just wondering why the for loop is there at all....
Thanks,
Elaine
for (i = USER_PTRS_PER_PGD; i < PTRS_PER_PGD; i++) {
pmd_t *pmd = kmem_cache_alloc(pmd_cache, GFP_KERNEL);
if (!pmd)
goto out_oom;
set_pgd(&pgd[USER_PTRS_PER_PGD], __pgd(1 + __pa(pmd)));
}
^ permalink raw reply
* Re: Next problem: empty ident <joern@limerick.(none)> not allowed
From: Jörn Engel @ 2006-04-18 20:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu08qei2o.fsf@assigned-by-dhcp.cox.net>
On Tue, 18 April 2006 13:37:19 -0700, Junio C Hamano wrote:
> Jörn Engel <joern@wohnheim.fh-wedel.de> writes:
>
> > And now I have some questions:
> > 1. Why didn't the environment variables work?
> > 2. Why is there a check for commit information when I pull from some
> > tree?
>
> Because "pull" means "fetch and merge the local modifications if
> any". When you merge (and you _did_ merge), you create a new
> commit of your own, and the commit records who committed it.
>
> You need GIT_COMMITTER_EMAIL.
Ok. I was stupid in two accounts. Thanks!
Jörn
--
Time? What's that? Time is only worth what you do with it.
-- Theo de Raadt
^ permalink raw reply
* Re: [GIT PATCH] Fixes in the -stable tree, but not in mainline
From: Andrew Morton @ 2006-04-18 20:39 UTC (permalink / raw)
To: Greg KH; +Cc: tytso, torvalds, linux-kernel
In-Reply-To: <20060418174205.GA684@suse.de>
Greg KH <gregkh@suse.de> wrote:
>
> On Tue, Apr 18, 2006 at 12:06:10PM -0400, Theodore Ts'o wrote:
> > On Mon, Apr 17, 2006 at 02:29:46PM -0700, Greg KH wrote:
> > > Here are 5 patches that are in the -stable tree, yet not currently fixed
> > > in your mainline tree. One of them is a security fix, so it probably
> > > would be a good idea to get it into there :)
> >
> > I thought one of the requirements for accepting a patch into -stable
> > was that it was already in mainline. Was this a change in policy that
> > I missed, or just an oversight when we vetted these patches?
> >
> > Not that I have anything against these patches, just curious in the
> > future if we should NACK patches proposed for -stable if we notice
> > that they aren't yet in mainline.
>
> Sometimes some of these patches don't make it into Linus's tree because
> they get lost in the shuffle (like the Kconfig one), or because they
> were security issues that hit -stable first (like another one in there).
>
> Either way, yes, the rule is that it should be in mainline, or in the
> pipe to get into mainline (as was the 5 in this patchset.) I just
> wanted to make sure they made it into there, and didn't get lost.
>
I had them queued up as well, but I'm being sluggish and Greg got there first.
^ permalink raw reply
* Re: [linux-lvm] physical volume smaller than partition?
From: Shane Hathaway @ 2006-04-18 20:39 UTC (permalink / raw)
To: LVM general discussion and development; +Cc: Dieter Stüken
In-Reply-To: <CDF11F32-D2D3-47EB-8B00-E91614CEA795@isg.si>
Martin Gombac wrote:
> Tnx. for explanation.
> I didn't think that cfdisk uses 1000 instead of 1024.
FYI: the official meaning of kilobyte is 1000 bytes.
http://en.wikipedia.org/wiki/Kilobyte
http://lwn.net/2002/0103/a/esr-kibi.php3
Interestingly, this means drive manufacturers are not misleading
consumers after all.
Shane
^ permalink raw reply
* Re: [PATCH 1/1] megaraid_{mm,mbox}: fix a bug in reset handler
From: Andrew Morton @ 2006-04-18 20:37 UTC (permalink / raw)
To: Ju, Seokmann
Cc: Seokmann.Ju, andre, James.Bottomley, linux-kernel, linux-scsi
In-Reply-To: <890BF3111FB9484E9526987D912B261901BCDA@NAMAIL3.ad.lsil.com>
"Ju, Seokmann" <Seokmann.Ju@lsil.com> wrote:
>
> I've seen the patch (megaraid_mmmbox_fix_a_bug_in_reset_handler.patch) available on 2.6.17-rc1-mm3 under "SCSI warning fix" section.
> What should I do to remove "warning" tag on the patch.
> I've attached another patch in previous email that has 'udelay()' in the loop to remove NMI concern, and waiting for confirmation on it. Will this change remove the "warning"?
>
> I'll submit the patch officially by end of today.
There are four megaraid-specific patches in -mm:
megaraid-unused-variable.patch
drivers-scsi-megaraidc-add-a-dummy-mega_create_proc_entry-for-proc_fs=y.patch
scsi-megaraid-megaraid_mmc-fix-a-null-pointer-dereference.patch
megaraid_mmmbox-fix-a-bug-in-reset-handler.patch
The final one is your latest patch.
I'll periodically send such patches to the subsystem maintainer until
something happens.
^ permalink raw reply
* Re: Next problem: empty ident <joern@limerick.(none)> not allowed
From: Junio C Hamano @ 2006-04-18 20:37 UTC (permalink / raw)
To: Jörn Engel; +Cc: git
In-Reply-To: <20060418202525.GD25688@wohnheim.fh-wedel.de>
Jörn Engel <joern@wohnheim.fh-wedel.de> writes:
> And now I have some questions:
> 1. Why didn't the environment variables work?
> 2. Why is there a check for commit information when I pull from some
> tree?
Because "pull" means "fetch and merge the local modifications if
any". When you merge (and you _did_ merge), you create a new
commit of your own, and the commit records who committed it.
You need GIT_COMMITTER_EMAIL.
^ permalink raw reply
* Re: Next problem: empty ident <joern@limerick.(none)> not allowed
From: Junio C Hamano @ 2006-04-18 20:37 UTC (permalink / raw)
To: Jörn Engel; +Cc: git
In-Reply-To: <20060418202525.GD25688@wohnheim.fh-wedel.de>
Jörn Engel <joern@wohnheim.fh-wedel.de> writes:
> And now I have some questions:
> 1. Why didn't the environment variables work?
> 2. Why is there a check for commit information when I pull from some
> tree?
Because "pull" means "fetch and merge the local modifications if
any". When you merge (and you _did_ merge), you create a new
commit of your own, and the commit records who committed it.
You need GIT_COMMITTER_EMAIL.
Now, the normal "git log" does not verbosely show committer and
author,
^ permalink raw reply
* Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks
From: Serge E. Hallyn @ 2006-04-18 20:36 UTC (permalink / raw)
To: Stephen Smalley
Cc: Serge E. Hallyn, Alan Cox, Gerrit Huizenga, Christoph Hellwig,
James Morris, casey, linux-security-module, linux-kernel,
fireflier-devel
In-Reply-To: <1145391612.16632.236.camel@moss-spartans.epoch.ncsc.mil>
Quoting Stephen Smalley (sds@tycho.nsa.gov):
> On Tue, 2006-04-18 at 14:59 -0500, Serge E. Hallyn wrote:
> > Quoting Alan Cox (alan@lxorguk.ukuu.org.uk):
> > > On Maw, 2006-04-18 at 09:50 -0700, Gerrit Huizenga wrote:
> > > > or are there places where a "less than perfect, easy to use, good enough"
> > > > security policy? I believe there is room for both based on the end
> > > > users' needs and desires. But that is just my opinion.
> > >
> > > Poor security systems lead to less security than no security because it
> > > lulls people into a false sense of security. Someone who knows their
> >
> > Not wanting to make any digs one way or another, but because the culture
> > right now refuses to admit it I must point out:
> >
> > So does "security" which is too complicated and therefore ends up
> > misconfigured (or disabled).
>
> Not sure who refuses to admit it, but there is plenty of work in
> progress to improve SELinux useability. But that doesn't require
Yes, absolutely, some very good work.
I used to think I'd want selinux protecting the TCB, but worried about
user customizations threatening the integrity of the TCB policy. But
the namespace extension (.) may even allay that fear.
-serge
^ permalink raw reply
* Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks
From: Crispin Cowan @ 2006-04-18 20:35 UTC (permalink / raw)
To: Stephen Smalley
Cc: Karl MacMillan, Gerrit Huizenga, Christoph Hellwig, James Morris,
Serge E. Hallyn, casey, linux-security-module, linux-kernel,
fireflier-devel
In-Reply-To: <1145391252.16632.231.camel@moss-spartans.epoch.ncsc.mil>
Stephen Smalley wrote:
> On Tue, 2006-04-18 at 12:31 -0700, Crispin Cowan wrote:
>
>> AppArmor (then called "SubDomain") showed how this worked in practice
>> years before the Targeted Policy came along. The Targeted Policy
>> implements an approximation to the AppArmor security model, but does it
>> with domains and types instead of path names, imposing a substantial
>> cost in ease-of-use on the user.
>>
> Just to clarify a few points:
> - It is true that both AppArmor and SELinux with targeted policy only
> (effectively) restrict a subset of processes, but SELinux with targeted
> policy provides complete mediation of all objects and operations for
> those processes, not just capabilities and files like AppArmor.
>
Agreed, with the caveat that mediating all those things comes with
expense, and AppArmor doesn't mediate them by design, because our goal
is to keep the host from being compromised by a hacked application, not
to control all information flow. Different goals produce different designs.
> - Targeted policy demonstrates that a general purpose mechanism that is
> capable of complete mediation of all processes, objects, and operations
> (SELinux) can be applied to selective control if that is your goal. The
> reverse is not true; AppArmor is limited by its design.
>
Also agreed, and also caveated that the general purpose system emulating
the simple system is much more complex than the simple system itself,
and simplicity is a critical part of secure design. In this case, the
most expensive impact on simplicity is the complexity of the policy that
users have to manage.
> - Ease of use should be addressed in the user interface, not by using a
> broken kernel mechanism. There is ongoing work to address the
> useability of SELinux in userspace; it doesn't require changing the
> kernel mechanism to rely on pathnames (which is broken).
>
Mediating by file names rather than inodes is the fundamental place
where we disagree. I am delighted with LSM, because it allows us to
disagree without having to fight about it.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering, Novell http://novell.com
^ permalink raw reply
* Re: [RFC PATCH 1/8] pcmcia: add new ID to pcnet_cs
From: Jeff Garzik @ 2006-04-18 20:35 UTC (permalink / raw)
To: Dominik Brodowski; +Cc: netdev
In-Reply-To: <20060418201522.GA32341@isilmar.linta.de>
Dominik Brodowski wrote:
> Please review these patches which I inted to push upstream for 2.6.17 soon.
> Thanks,
> Dominik
>
> Subject: [PATCH] pcmcia: add new ID to pcnet_cs
>
> This adds a new ID to pcnet_cs, as noted by Kuro Moji.
>
> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
ACK, thanks for CC'ing netdev
Jeff
^ permalink raw reply
* Re: [parisc-linux] Does it lakes some cloberred r1 in __put_kernel_asm() 64bit?
From: Carlos O'Donell @ 2006-04-18 20:35 UTC (permalink / raw)
To: Joel Soete; +Cc: Parisc List
In-Reply-To: <4442A5AB.5080604@tiscali.be>
On 4/16/06, Joel Soete <soete.joel@tiscali.be> wrote:
> Hello all,
>
> I tried to apply my 'beautify' asm template to some uaccess.h and figure =
out that
> this hunk din't mentioned that "r1" was cloberred (iirc in fixup text) wh=
ile
> the 32bit one did:
>
> mmm, doesn't seems to change anything (I just check sys_parisc32.s) but m=
ay be elsewhere?
Please put on your thinking cap.
a) What does a clobber mean from the viewpoint of an __asm?
b) Which insn clobber r1?
Research both and return with the answer.
Double marks if you solve...
c) Should any of the __put_kernel_asm's have r1 listed as a clobber?
Cheers,
Carlos.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply
* Re: [Fireflier-devel] Re: [RESEND][RFC][PATCH 2/7] implementationof LSM hooks
From: David Lang @ 2006-04-18 19:33 UTC (permalink / raw)
To: Alan Cox
Cc: Török Edwin, fireflier-devel, Arjan van de Ven,
Crispin Cowan, Karl MacMillan, Gerrit Huizenga, Christoph Hellwig,
James Morris, Serge E. Hallyn, Stephen Smalley, casey,
linux-security-module, linux-kernel
In-Reply-To: <1145392307.21723.44.camel@localhost.localdomain>
On Tue, 18 Apr 2006, Alan Cox wrote:
> Subject: Re: [Fireflier-devel] Re: [RESEND][RFC][PATCH 2/7] implementationof
> LSM hooks
>
> On Maw, 2006-04-18 at 23:13 +0300, Török Edwin wrote:
>> In the current version we intended to use mountpoint+inode to identify
>> programs. This reduces the potential problems from your list to: fd passing.
>
> Inode numbers are not constant on all file systems unless the file is
> currently open. That is a pain in the butt when you want to describe a
> file as well but it is how things work out.
could you take an approach similar to git, store the length and a hash of
the first X amount of the file (for good performance say the first block,
for best security say the entire file)? is there a hash that's cheap
enough to calculate that this is reasonable? (although it would end up
trashing the cpu cache in any case, loosing a bunch of the benifits of
DMA)
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
^ permalink raw reply
* [ALSA - driver 0002035]: Realtek 861 card not functional using included alsa drivers
From: bugtrack @ 2006-04-18 20: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=2035>
======================================================================
Reported By: vertex
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 2035
Category: PCI - hda-intel
Reproducibility: always
Severity: major
Priority: normal
Status: assigned
Distribution: Fedora Core 5
Kernel Version: 2.6.16-1.2080_FC5smp
======================================================================
Date Submitted: 04-18-2006 20:00 CEST
Last Modified: 04-18-2006 22:32 CEST
======================================================================
Summary: Realtek 861 card not functional using included alsa
drivers
Description:
I am using the FC5 drivers to begin with. The packages are labeled version
1.0.11rc2. There are only a few options when I run alsamixer. Using the
stock drivers, I have these options:
Headphone switch
CD level
Mic level
Input Source switch(Mic/CD)
I compiled the 1.0.11rc5 drivers from source and rebooted. I now have
these channels when I run alsamixer:
Front switch
CD level
Mic level
Input Source switch(Mic/CD)
I tried compiling the 1.0.9 drivers from Realtek's website(said nothing
about the 861), but they did not build. In fact, the install script
overwrote my asound libraries requiring a package replacement to get back
to a sane state.
Please let me know if there is something more I can provide.
======================================================================
----------------------------------------------------------------------
rlrevell - 04-18-06 22:25
----------------------------------------------------------------------
ACL861 is not a valid model name (neither is ALC861)
ALC861
3stack 3-jack
3stack-dig 3-jack with SPDIF I/O
6stack-dig 6-jack with SPDIF I/O
auto auto-config reading BIOS (default)
The valid models for the ALC861 codec are 3stack, 3stack-dig, 6stack-dig,
and auto
----------------------------------------------------------------------
vertex - 04-18-06 22:32
----------------------------------------------------------------------
Forgive my ignorance(and typo). I tried again using model=auto and have the
same result. I don't have 3 jacks on this machine, only two.
Issue History
Date Modified Username Field Change
======================================================================
04-18-06 20:00 vertex New Issue
04-18-06 20:00 vertex Distribution => Fedora Core 5
04-18-06 20:00 vertex Kernel Version => 2.6.16-1.2080_FC5smp
04-18-06 20:09 rlrevell Note Added: 0009339
04-18-06 20:25 pzad Note Added: 0009340
04-18-06 20:40 vertex Note Added: 0009342
04-18-06 20:50 vertex Note Added: 0009343
04-18-06 22:25 rlrevell Note Added: 0009345
04-18-06 22:32 vertex Note Added: 0009346
======================================================================
-------------------------------------------------------
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
* [lm-sensors] Question on my mainboard
From: Rudolf Marek @ 2006-04-18 20:30 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <200603282150.16130.dieter.jurzitza@t-online.de>
Dieter Jurzitza wrote:
> Dear Rudolf,
> dear listmembers,
> after building the kernel with debugging active, I flood my /var/log/messages
> file (something like 100MByte per day).
> What I get is attached. What is apparent to me is the fact that there are
> error messages every other time (I just attached several seconds) and non
> regular accesses (should happen every ten seconds) but no hang like before.
> So I have to wait a little more. If I am unlucky the delays introduced by the
> tons of printfs prevent sensors from crashing my sensor chip. But maybe some
> of you guys can understand why the errors are being reported.
> Thank you in advance,
> take care
Yep we can.
There are are errors reading addresses 0x4A and 0x4B
And 0x2C
options w83781d force_w83782d=0,0x2d force_subclients=0,0x2d,0x48,0x49
force_w83627hf=0,0x2c force_subclients=0,0x2c,0x4a,0x4b init=0
So you left the second line there??? and only loading w83627hf with
force_subclients=0,0x2c,0x4a,0x4b ?
I'm asking because there are more addresses access
(cat logpart | awk -FADD '{print $2}' |awk '{print $1}' | sort -u)
Regards
Rudolf
^ permalink raw reply
* Re: [linux-lvm] physical volume smaller than partition?
From: Martin Gombac @ 2006-04-18 20:30 UTC (permalink / raw)
To: Dieter Stüken; +Cc: LVM general discussion and development
In-Reply-To: <4445294D.6050500@conterra.de>
Tnx. for explanation.
I didn't think that cfdisk uses 1000 instead of 1024.
Regards,
Martin
On 2006.4.18, at 20:00, Dieter St�ken wrote:
> Martin Gombac wrote
>> and noticed 277.60 GB != 291.08..GB. So my question is where did
>> the rest of disk space went to?
>
> it depends on counting "kilo" as 1000 or 1024.
> This happens even twice for kb -> mb -> gb.
>
> Thus: 277.60 * 1.024 * 1.024 = 291.08
>
> Memory capacity is calculated using 1024 where as disk manufacturer
> like using 1000, as this results in bigger numbers
> (but does not result in more space :-(
>
> Dieter.
^ permalink raw reply
* Re: [PATCH 0/7] [RFC] Sizing zones and holes in an architecture independent manner V3
From: Mel Gorman @ 2006-04-18 20:27 UTC (permalink / raw)
To: Jack Steiner
Cc: davej, tony.luck, linuxppc-dev, Linux Kernel Mailing List,
bob.picco, ak, Linux Memory Management List
In-Reply-To: <20060418195644.GA30911@sgi.com>
On Tue, 18 Apr 2006, Jack Steiner wrote:
> On Tue, Apr 18, 2006 at 02:00:15PM +0100, Mel Gorman wrote:
>> This is V3 of the patchset to size zones and memory holes in an
> ...
>
>
>
> FYI, I applied the patches to a recent kernel & booted on a large
> SGI system.
Very cool, thanks for testing. I'm glad to see the assumptions related to
the size of node_map held up for a large machine.
> No problem aside from what I assume is a very large number
> of debug messages.
>
The debug messages are all in patch 7/7 and will be dropped before I try
and push this to -mm. The patch was included here in case a machine failed
to boot so I could figure out what went wrong.
>
> ------
> Linux version 2.6.17-tony (steiner@attica) (gcc version 4.1.0 (SUSE Linux)) #5 SMP PREEMPT Tue Apr 18 14:01:54 CDT 2006
> EFI v1.10 by INTEL: SALsystab=0x6002c51df0 ACPI 2.0=0x6002c51ee0
> Number of logical nodes in system = 512
> Number of memory chunks in system = 512
> SAL 2.9: SGI SN2 version 1.10
> SAL Platform features: ITC_Drift
> SAL: AP wakeup using external interrupt vector 0x12
> No logical to physical processor mapping available
> ACPI: Local APIC address c0000000fee00000
> ACPI: Error parsing MADT - no IOSAPIC entries
> register_intr: No IOSAPIC for GSI 52
> 512 CPUs available, 512 CPUs total
> MCA related initialization done
> SGI SAL version 1.10
> add_active_range(0, 25168900, 25235456): New
> add_active_range(0, 25236375, 25419776): New
> add_active_range(0, 27262976, 27516927): New
> add_active_range(0, 29360128, 29614080): New
> add_active_range(1, 92277760, 92528640): New
> ...
> add_active_range(511, 34322242024, 34322242047): New
> add_active_range(511, 34322243072, 34322243417): New
> add_active_range(511, 34322243432, 34322243460): New
> add_active_range(511, 34322243488, 34322243500): New
> Virtual mem_map starts at 0xa0007e407d270000
> free_area_init_nodes(68719476736, 68719476736, 34322243584, 34322243584)
> free_area_init_nodes(): find_min_pfn = 25168900
> Dumping sorted node map
> entry 0: 0 25168900 -> 25235456
> entry 1: 0 25236375 -> 25419776
> entry 2: 0 27262976 -> 27516927
> entry 3: 0 29360128 -> 29614080
> entry 4: 1 92277760 -> 92528640
> entry 5: 1 94371840 -> 94625792
> entry 6: 1 96468992 -> 96722944
> ...
> entry 1536: 511 34321989632 -> 34322242001
> entry 1537: 511 34322242016 -> 34322242022
> entry 1538: 511 34322242024 -> 34322242047
> entry 1539: 511 34322243072 -> 34322243417
> entry 1540: 511 34322243432 -> 34322243460
> entry 1541: 511 34322243488 -> 34322243500
> __absent_pages_in_range(0, 25168900, 68719476736) = 3687320
> __absent_pages_in_range(0, 68719476736, 68719476736) = 0
> __absent_pages_in_range(0, 68719476736, 34322243584) = 0
> __absent_pages_in_range(0, 34322243584, 34322243584) = 0
> __absent_pages_in_range(0, 25168900, 68719476736) = 3687320
> ...
> __absent_pages_in_range(511, 34322243584, 34322243584) = 0
> __absent_pages_in_range(511, 25168900, 68719476736) = 3687485
> __absent_pages_in_range(511, 68719476736, 68719476736) = 0
> __absent_pages_in_range(511, 68719476736, 34322243584) = 0
> __absent_pages_in_range(511, 34322243584, 34322243584) = 0
> Built 512 zonelists
> Kernel command line: BOOT_IMAGE=net0:jfs/tonys ro hashdist=1 dhash_entries=2097152 ihash_entries=2097152 rhash_entries=2097152 thash_entries=2097152 console=ttySG0,38400n8 kdb=on noprobe root=/dev/sda5
> PID hash table entries: 4096 (order: 12, 32768 bytes)
> Console: colour dummy device 80x25
> Memory: 4639378784k/4655642784k available (7021k code, 16279040k reserved, 4361k data, 736k init)
> (essentially the same numbers as with a kernel w/o the patches)
> McKinley Errata 9 workaround not needed; disabling it
>
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ 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.