* Re: [OOPS] related to swap?
From: Nick Piggin @ 2006-04-05 9:38 UTC (permalink / raw)
To: pomac; +Cc: Linux-kernel
In-Reply-To: <1144225363.7112.10.camel@localhost>
Ian Kumlien wrote:
>>Ian Kumlien wrote:
>>
>>
>>>Yes, i run a tainted kernel! either live with it or ignore this mail
>>>=)
>>
>>>starting swap lead to a deadlock within 15 mins
>>
>>>I have never had the energy to perform a full memtext86+
>>
>>It would be useful if you could perform a memtest overnight one night,
>>then run a non-patched and non-tained 2.6.16.1 kernel, and try to
>>reproduce the problems.
>
>
> As i said, i really doubt that the memory is at fault here, it has done
> several passes over the memory but not all tests. I can give it a go
> though, but i really doubt it'll find anything.
>
If it doesn't cost you much time (ie. do it overnight) it could save some
developers a lot of time.
> The kernel i run is a plain 2.6.16.1 from kernel.org (i have heard that
> you can actually compile gentoos own these days)
>
OK, good.
> Since this is my *cough* desktop, running it without that ability is
> kinda a show stopper, thats why i included the thing above.
>
But if the problem can be reproduced in 15 minutes, it shouldn't be
too hard to get a trace without nvidia loaded.
> But the thing is, my laptop runs with the same compiler, "same" nvidia
> driver and the "same" kernel ("same" as in 32 bit not 64 bit).
> Eventhough "same" in this case usually means nothing, i doubt that one
> would have a serius bug and the other wouldn't, ie it's most likley a
> bug related to 64 bits or one or more of the drivers involved.
>
> The only errors i get in dmesg atm is:
> KERNEL: assertion (!sk->sk_forward_alloc) failed at net/core/stream.c
> (283)
> KERNEL: assertion (!sk->sk_forward_alloc) failed at net/ipv4/af_inet.c
> (150)
>
> Which is related to TSO, from what i gather, but i can't turn off tso on
> forcedeth... (i suspected this to cause corruption a while back....)
>
If your network hardware or driver is flakey, try compiling a kernel
without that as well before reproducing this swap problem.
Thanks,
Nick
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply
* [lm-sensors] unable to set lm_sensors
From: Zé @ 2006-04-06 6:50 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <200603252150.53616.mmodem00@netvisao.pt>
Em Quinta, 30 de Mar?o de 2006 22:36, escreveu:
> Hi Ze,
>
> Sorry for delay, seems all other people have other stuff to do.
>
> Z? wrote:
> > I have a notebook Acer 5024 WLMi that haves a cpu Turion 64 ML-34 and i
> > have installed Mandriva 2006 x86_64.
> >
> > I have installed lm_sensors //nd run sensors-detect but i cant get it
> >
> > Sorry, no chips were detected.
> > Either your sensors are not supported, or they are
> > connected to an I2C bus adapter that we do not support.
>
> Well notebooks usually do the thermal management on their own. The CPU temp
> can be read via ACPI. USe for example acpi -V
I cant get any temperature, if u do acpi -V i get:
AC Adapter 1: on-line
> command to see the temperature. Have you any strong reason to need to have
> lm-sensors?
Yes i really need to know the temperatures
> regards
> Rudolf
kind regards,
--
Z?
Linux user #378762
MDE Developer - www.mde.djura.org
^ permalink raw reply
* Re: About doc of libnetfilter_queue
From: Eric Leblond @ 2006-04-06 6:51 UTC (permalink / raw)
To: Frank Abel Cancio Bello; +Cc: netfilter
In-Reply-To: <200604052138.57149.frankabel@tesla.cujae.edu.cu>
Frank Abel Cancio Bello wrote:
> Hi all!
>
> The question is: where I can read libnetfilter_queue documentation?
>
> I have see on Internet some references to "Brad Fisher's documentation of
> libnetfilter_queue", where are this doc?
Maybe there :
http://archives.free.net.ph/message/20060208.171235.186dce08.en.html
BR,
--
Eric Leblond
^ permalink raw reply
* Re: [Xen-changelog] Define Xen interface version for tools build.
From: Keir Fraser @ 2006-04-06 6:52 UTC (permalink / raw)
To: Muli Ben-Yehuda; +Cc: xen-devel
In-Reply-To: <20060406055438.GA16153@granada.merseine.nu>
On 6 Apr 2006, at 06:54, Muli Ben-Yehuda wrote:
>> X11_LDPATH = -L/usr/X11R6/$(LIBDIR)
>> +
>> +CFLAGS += -D__XEN_INTERFACE_VERSION__=0x00030101
>
> This is now another place you have to remember to change the version
> string. Can we stick it in its own file with nothing else and have
> other users include it?
Where would you place it such that it's guaranteed to be included
everywhere?
One option is to define as 0xFFFFFFFF and have xen-compat.h rewrite
that to __XEN_LATEST_INTERFACE_VERSION__. Then we'd never need to
update the tools version as it would always get the latest interface.
-- Keir
^ permalink raw reply
* Re: [fuse-devel] Re: [parisc-linux] [PATCH] Fixs to work on ARM and PARIC platforms.
From: Miklos Szeredi @ 2006-04-06 6:53 UTC (permalink / raw)
To: James.Bottomley; +Cc: fuse-devel, parisc-linux
In-Reply-To: <1144282046.3214.7.camel@mulgrave.il.steeleye.com>
> > > No, because if you look at the implementation, you'll see that
> > > copy_to/from_user() copy straight into the user view (i.e. via the user
> > > cache lines).
> >
> > Yes. But how will this ensure that the above problems (dirty/clean
> > cache lines in aliases) won't cause any problems?
>
> It doesn't. The object is to write into the user cache as though the
> actual user process had done it (i.e. disregarding all aliasing).
Which is also what the object of get_user_pages() + memcpy() is. The
fact that in the process some part of the cache is flushed is
irrelevant.
get_user_pages() is used as a _substitute_ for copy_*_user() if the
memory copying needs to be done from a different VM context.
> > What is the difference between
> >
> > - updating cached data through the user view
> >
> > - flushing the cache lines for the user view, then updating data
> > through the kernel view and finally flushing the cache lines for
> > the kernel view
>
> In the former, the data usually ends up in dirty user cache lines. In
> the latter the cache lines are entirely clean after the procedure.
>
> > I don't see in either case that the cache lines for any other aliases
> > are touched. Is there still some difference in behavior?
>
> Yes, in the former, only a single alias (the user view) is affected. In
> the latter, all views are accounted for.
I think we agree on what happens, but not about why it is needed to
happen.
With your fix get_user_pages() guarantees _more_ coherency than
copy_from/to_user(). This not a bug per-se, but it does require a new
interface (flush_anon_pages()) and provides "strange" cache coherency
semantics.
By strange I mean, that all views of file backed pages are flushed,
but only one view of anononymous pages. This IMO doesn't make too
much sense, but feel free to correct me if I'm wrong.
How about this?
Index: linux/mm/memory.c
===================================================================
--- linux.orig/mm/memory.c 2006-04-04 18:44:47.000000000 +0200
+++ linux/mm/memory.c 2006-04-06 08:40:26.000000000 +0200
@@ -1072,8 +1072,8 @@ int get_user_pages(struct task_struct *t
if (pages) {
pages[i] = page;
- flush_anon_page(page, start);
- flush_dcache_page(page);
+ flush_cache_page(vma, start, page_to_pfn(page));
+ flush_kernel_dcache_page(page);
}
if (vmas)
vmas[i] = vma;
The flushing semantics are cleaner, and the flush_anon_page()
interface is not needed.
Miklos
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply
* Re: Is teardown_irq still required?
From: Keir Fraser @ 2006-04-06 6:55 UTC (permalink / raw)
To: Tian, Kevin; +Cc: xen-devel
In-Reply-To: <571ACEFD467F7749BC50E0A98C17CDD8094E7A9A@pdsmsx403>
On 6 Apr 2006, at 04:14, Tian, Kevin wrote:
> Does the assumption still hold true that some static irqaction
> may be
> freed by this way? Or previous requirement already disappears today?
> Now all the virtual drivers finally fall down to request_irq which
> matches
> free_irq. Only instances to call setup_irq are native linux drivers,
> where
> free_irq is not required for those architecture specific static irq
> number.
>
> Maybe this change can be removed now?
Yes, I think we can remove it. We used to use it for timer irqs, but no
longer.
-- Keir
^ permalink raw reply
* Re: BUG: soft lockup detected on CPU#0!
From: Keir Fraser @ 2006-04-06 6:56 UTC (permalink / raw)
To: Christopher S. Aker; +Cc: xen-devel
In-Reply-To: <44340D3D.8060903@theshore.net>
On 5 Apr 2006, at 19:32, Christopher S. Aker wrote:
> pe, delayed (13 , delayined (13 , delayed (13 pendin, delayined (13 ,
> delayined (13 pe, delayined (13 pe, delayined (13 , delayed (13 pe,
> delayed (13 , delayined (13 , delayed (13 pendin, delayined (13 ,
> delayined (13 pe, delayed (13 pe, delayined (13 , delayined (13 pe,
> delayed (13 , delayined (13 p, delayed (13 pend, delayed (13 ,
> delayined (13 pe, dela
> ^-- these are flooding, but not quite as often.
>
> This leaves Xen/Xend in an unstable condition, I'm thinking the only
> way out is a reboot...
Thanks, I'll create a fix for xen-unstable which can later be
backported to 3.0.2.
-- Keir
^ permalink raw reply
* Re: deleting partition does not effect superblock?
From: Jan-Benedict Glaw @ 2006-04-06 6:58 UTC (permalink / raw)
To: Sumit Narayan; +Cc: linux-kernel, ext3-users
In-Reply-To: <1458d9610604052337p2cafa6c8j78fc6da8c5f8be1a@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1465 bytes --]
On Thu, 2006-04-06 14:37:33 +0800, Sumit Narayan <talk2sumit@gmail.com> wrote:
> Shouldn't the superblock be changed/deleted once the partition is
> deleted? I tried a reboot, but the output remained the same.
No, everything you see is "works as expected." A partition is only a
container (as well as "disks", "volume groups", "RAID arrays",
"logical volumes", "image files" etc. are.)
Whenever you destroy such a container, its contents isn't modified (or
deleted) or otherwise modified. So it's perfectly okay to delete such
a container (eg. remove start and end from the partition table) and
recreate it at some time later (by adding those values back to the
partition table.) As long as the new container starts at the same
location, a filesystem driver will be able to find the old
information. If you start a block later, it won't find it's
superblocks.
Finally, you have several choices how to defeat getting back old data.
Most probably, you'd just zero it out before deleting the partition
with something like:
# cat /dev/zero > /dev/hda3
(of course with the correct device name!)
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Thin pack generation: optimization.
From: Junio C Hamano @ 2006-04-06 6:58 UTC (permalink / raw)
To: git
In-Reply-To: <7vd5fzlnyt.fsf@assigned-by-dhcp.cox.net>
Jens Axboe noticed that recent "git push" has become very slow
since we made --thin transfer the default.
Thin pack generation to push a handful revisions that touch
relatively small number of paths out of huge tree was stupid; it
registered _everything_ from the excluded revisions. As a
result, "Counting objects" phase was unnecessarily expensive.
This changes the logic to register the blobs and trees from
excluded revisions only for paths we are actually going to send
to the other end.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
pack-objects.c | 119 +++++++++++++++++++++++++++++++++++++-------------------
1 files changed, 79 insertions(+), 40 deletions(-)
b5026f319fc873d03a02f15992b7e431b4b5ad03
diff --git a/pack-objects.c b/pack-objects.c
index 9346392..f1bd8a6 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -505,24 +505,17 @@ static unsigned name_hash(struct name_pa
* but close enough.
*/
hash = (name_hash<<DIRBITS) | (hash & ((1U<<DIRBITS )-1));
-
- if (0) { /* debug */
- n = name + strlen(name);
- if (n != name && n[-1] == '\n')
- n--;
- while (name <= --n)
- fputc(*n, stderr);
- for (p = path; p; p = p->up) {
- fputc('/', stderr);
- n = p->elem + p->len;
- while (p->elem <= --n)
- fputc(*n, stderr);
- }
- fprintf(stderr, "\t%08x\n", hash);
- }
return hash;
}
+
+static struct pbase_tree {
+ struct pbase_tree *next;
+ unsigned char sha1[20];
+ void *tree_data;
+ unsigned long tree_size;
+} *pbase_tree;
+
static int add_object_entry(const unsigned char *sha1, unsigned hash, int exclude)
{
unsigned int idx = nr_objects;
@@ -585,58 +578,99 @@ static int add_object_entry(const unsign
}
}
return status;
+}
+
+static int name_cmp_len(const char *name)
+{
+ int i;
+ for (i = 0; name[i] && name[i] != '\n' && name[i] != '/'; i++)
+ ;
+ return i;
}
-static void add_pbase_tree(struct tree_desc *tree, struct name_path *up)
+static void add_pbase_object(struct tree_desc *tree,
+ struct name_path *up,
+ const char *name,
+ int cmplen)
{
while (tree->size) {
const unsigned char *sha1;
- const char *name;
- unsigned mode, hash;
+ const char *entry_name;
+ int entry_len;
+ unsigned mode;
unsigned long size;
char type[20];
- sha1 = tree_entry_extract(tree, &name, &mode);
+ sha1 = tree_entry_extract(tree, &entry_name, &mode);
update_tree_entry(tree);
- if (!has_sha1_file(sha1))
- continue;
- if (sha1_object_info(sha1, type, &size))
- continue;
-
- hash = name_hash(up, name);
- if (!add_object_entry(sha1, hash, 1))
+ entry_len = strlen(entry_name);
+ if (entry_len != cmplen ||
+ memcmp(entry_name, name, cmplen) ||
+ !has_sha1_file(sha1) ||
+ sha1_object_info(sha1, type, &size))
continue;
-
+ if (name[cmplen] != '/') {
+ unsigned hash = name_hash(up, name);
+ add_object_entry(sha1, hash, 1);
+ return;
+ }
if (!strcmp(type, tree_type)) {
struct tree_desc sub;
void *elem;
struct name_path me;
+ /* We probably should cache these
+ * intermediate tree buffers...
+ */
elem = read_sha1_file(sha1, type, &sub.size);
sub.buf = elem;
if (sub.buf) {
+ const char *down = name+cmplen+1;
+ int downlen = name_cmp_len(down);
+
me.up = up;
- me.elem = name;
- me.len = strlen(name);
- add_pbase_tree(&sub, &me);
+ me.elem = entry_name;
+ me.len = entry_len;
+ add_pbase_object(&sub, &me, down, downlen);
free(elem);
}
}
}
}
+
+static void add_preferred_base_object(char *name)
+{
+ struct pbase_tree *it;
+ int cmplen = name_cmp_len(name);
+ for (it = pbase_tree; it; it = it->next) {
+ if (cmplen == 0) {
+ unsigned hash = name_hash(NULL, "");
+ add_object_entry(it->sha1, hash, 1);
+ }
+ else {
+ struct tree_desc tree;
+ tree.buf = it->tree_data;
+ tree.size = it->tree_size;
+ add_pbase_object(&tree, NULL, name, cmplen);
+ }
+ }
+}
+
static void add_preferred_base(unsigned char *sha1)
{
- struct tree_desc tree;
- void *elem;
+ struct pbase_tree *it;
- elem = read_object_with_reference(sha1, tree_type, &tree.size, NULL);
- tree.buf = elem;
- if (!tree.buf)
+ for (it = pbase_tree; it && memcmp(it->sha1, sha1, 20); it = it->next)
+ ;
+ if (it)
return;
- if (add_object_entry(sha1, name_hash(NULL, ""), 1))
- add_pbase_tree(&tree, NULL);
- free(elem);
+ it = xcalloc(1, sizeof(*it));
+ it->next = pbase_tree;
+ pbase_tree = it;
+ memcpy(it->sha1, sha1, 20);
+ it->tree_data = read_object_with_reference(sha1, tree_type,
+ &it->tree_size, NULL);
}
static void check_object(struct object_entry *entry)
@@ -1051,6 +1085,7 @@ int main(int argc, char **argv)
char line[PATH_MAX + 20];
int window = 10, depth = 10, pack_to_stdout = 0;
struct object_entry **list;
+ int num_preferred_base = 0;
int i;
setup_git_directory();
@@ -1116,6 +1151,7 @@ int main(int argc, char **argv)
for (;;) {
unsigned char sha1[20];
+ unsigned hash;
if (!fgets(line, sizeof(line), stdin)) {
if (feof(stdin))
@@ -1132,12 +1168,15 @@ int main(int argc, char **argv)
if (get_sha1_hex(line+1, sha1))
die("expected edge sha1, got garbage:\n %s",
line+1);
- add_preferred_base(sha1);
+ if (num_preferred_base++ < window)
+ add_preferred_base(sha1);
continue;
}
if (get_sha1_hex(line, sha1))
die("expected sha1, got garbage:\n %s", line);
- add_object_entry(sha1, name_hash(NULL, line+41), 0);
+ add_preferred_base_object(line+41);
+ hash = name_hash(NULL, line+41);
+ add_object_entry(sha1, hash, 0);
}
if (progress)
fprintf(stderr, "Done counting %d objects.\n", nr_objects);
--
1.3.0.rc2.g9cda
^ permalink raw reply related
* [ALSA - driver 0002005]: problems with make
From: bugtrack @ 2006-04-06 6:59 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2005>
======================================================================
Reported By: mramirez
Assigned To: perex
======================================================================
Project: ALSA - driver
Issue ID: 2005
Category: 0_compilation problem_!!!
Reproducibility: always
Severity: minor
Priority: normal
Status: assigned
Distribution: Fedora Core 5
Kernel Version: 2.6.15-1.2054_FC5smp
======================================================================
Date Submitted: 04-05-2006 19:59 CEST
Last Modified: 04-06-2006 08:59 CEST
======================================================================
Summary: problems with make
Description:
I've dowload the cvs version of alsa, and try install on my laptop, but the
make process exit whit a bad status.
======================================================================
----------------------------------------------------------------------
Raymond - 04-06-06 08:59
----------------------------------------------------------------------
Please install the package with full kernel sources for your distribution
or use --with-kernel=dir option to specify another directory with kernel
sources (default is /lib/modules/2.6.15-1.2054_FC5smp/source).
Issue History
Date Modified Username Field Change
======================================================================
04-05-06 19:59 mramirez New Issue
04-05-06 19:59 mramirez Distribution => Fedora Core 5
04-05-06 19:59 mramirez Kernel Version => 2.6.15-1.2054_FC5smp
04-06-06 08:59 Raymond Note Added: 0009123
======================================================================
-------------------------------------------------------
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
* [PATCH/RFC] libata-dev: make the returned err_mask more accurate
From: Albert Lee @ 2006-04-06 7:02 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Tejun Heo, IDE Linux, Doug Maxey
make the returned err_mask more accurate
Changes:
- add ac_err_drq() and ac_err_idle() to map err_mask from drv_status for data xfer and idle states.
- fix ata_hsm_move() to use the functions for err_mask mapping.
Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
---
The current err_mask returned by HSM doesn't look right.
e.g. When we found DRQ=0 when data transfer is expected, AC_ERR_HSM is returned.
However, DRQ=0 maybe caused by device error. So, during data transfer,
if we see DRQ=0 and ERR=1, returning AC_ERR_DEV should be more accurate.
e.g. In HSM_ST_LAST state, AC_ERR_OTHER is returned for BSY=0 DRQ=1 currently.
AC_ERR_HSM shoule be more accurate.
Patch against irq-pio (79fa1b677be3a985cc66b9218a4dd09818f1051b).
For your review, thanks.
--- irq-pio0/drivers/scsi/libata-core.c 2006-04-06 10:08:44.000000000 +0800
+++ irq-pio1/drivers/scsi/libata-core.c 2006-04-06 11:20:15.000000000 +0800
@@ -3906,7 +3906,7 @@ fsm_start:
/* check device status */
if (unlikely((status & (ATA_BUSY | ATA_DRQ)) != ATA_DRQ)) {
/* Wrong status. Let EH handle this */
- qc->err_mask |= AC_ERR_HSM;
+ qc->err_mask |= ac_err_drq(status);
ap->hsm_task_state = HSM_ST_ERR;
goto fsm_start;
}
@@ -3920,7 +3920,7 @@ fsm_start:
if (unlikely(status & (ATA_ERR | ATA_DF))) {
printk(KERN_WARNING "ata%d: DRQ=1 with device error, dev_stat 0x%X\n",
ap->id, status);
- qc->err_mask |= AC_ERR_DEV;
+ qc->err_mask |= AC_ERR_HSM;
ap->hsm_task_state = HSM_ST_ERR;
goto fsm_start;
}
@@ -3976,7 +3976,7 @@ fsm_start:
if (unlikely(status & (ATA_ERR | ATA_DF))) {
printk(KERN_WARNING "ata%d: DRQ=1 with device error, dev_stat 0x%X\n",
ap->id, status);
- qc->err_mask |= AC_ERR_DEV;
+ qc->err_mask |= AC_ERR_HSM;
ap->hsm_task_state = HSM_ST_ERR;
goto fsm_start;
}
@@ -3991,7 +3991,7 @@ fsm_start:
/* ATA PIO protocol */
if (unlikely((status & ATA_DRQ) == 0)) {
/* handle BSY=0, DRQ=0 as error */
- qc->err_mask |= AC_ERR_HSM;
+ qc->err_mask |= ac_err_drq(status);
ap->hsm_task_state = HSM_ST_ERR;
goto fsm_start;
}
@@ -4007,13 +4007,16 @@ fsm_start:
* transferred to the device.
*/
if (unlikely(status & (ATA_ERR | ATA_DF))) {
- /* data might be corrputed */
- qc->err_mask |= AC_ERR_DEV;
- if (!(qc->tf.flags & ATA_TFLAG_WRITE)) {
+ if (qc->tf.flags & ATA_TFLAG_WRITE)
+ qc->err_mask |= AC_ERR_HSM;
+ else {
+ /* data might be corrputed */
+ qc->err_mask |= AC_ERR_DEV;
ata_pio_sectors(qc);
ata_altstatus(ap);
status = ata_wait_idle(ap);
+ qc->err_mask |= ac_err_idle(status);
}
/* ata_pio_sectors() might change the
@@ -4041,7 +4044,7 @@ fsm_start:
case HSM_ST_LAST:
if (unlikely(!ata_ok(status))) {
- qc->err_mask |= __ac_err_mask(status);
+ qc->err_mask |= ac_err_idle(status);
ap->hsm_task_state = HSM_ST_ERR;
goto fsm_start;
}
--- irq-pio0/include/linux/libata.h 2006-04-06 10:08:48.000000000 +0800
+++ irq-pio1/include/linux/libata.h 2006-04-06 13:44:25.000000000 +0800
@@ -942,6 +942,46 @@ static inline int ata_try_flush_cache(co
ata_id_has_flush_ext(dev->id);
}
+static inline unsigned int ac_err_drq(u8 status)
+{
+ /* BSY = 1*/
+ if (status & ATA_BUSY)
+ return AC_ERR_HSM;
+
+ /* BSY = 0, DRQ = 1 */
+ if (status & ATA_DRQ)
+ return 0;
+
+ /* BSY = 0, DRQ = 0, device err */
+ if (status & (ATA_ERR | ATA_DF))
+ return AC_ERR_DEV;
+
+ /* BSY = 0, DRQ = 0, no device err
+ * when we are expecting data transfer.
+ */
+ return AC_ERR_HSM;
+}
+
+static inline unsigned int ac_err_idle(u8 status)
+{
+ /* BSY = 1 or DRQ = 1 */
+ if (status & (ATA_BUSY | ATA_DRQ))
+ return AC_ERR_HSM;
+
+ /* BSY = 0, DRQ = 0, device err */
+ if (status & (ATA_ERR | ATA_DF))
+ return AC_ERR_DEV;
+
+ /* BSY = 0, DRQ = 0, no device err. DRDY = 1 */
+ if (status & ATA_DRDY)
+ return 0;
+
+ /* thing looks good.
+ * don't know why DRDY not set.
+ */
+ return AC_ERR_OTHER
+}
+
static inline unsigned int ac_err_mask(u8 status)
{
if (status & ATA_BUSY)
^ permalink raw reply
* Re: FILE_FLAG_WRITE_THROUGH
From: Steve Graegert @ 2006-04-06 7:02 UTC (permalink / raw)
To: linux-c-programming
In-Reply-To: <17460.4298.747957.303455@cerise.gclements.plus.com>
On 4/5/06, Glynn Clements <glynn@gclements.plus.com> wrote:
>
> Steve Graegert wrote:
>
> > > > The O_DIRECT flag suggested by Steve is probably overkill. It requires
> > > > that the buffer start address, buffer size and file offset are all
> > > > multiples of the filesystem's block size, and only works on some
> > > > filesystems.
> > >
> > > Although it works for a single file, how good is fsync() in this case?
> >
> > fsync(2) does not ensure that all data has actually been written to
> > disk. The controller may indicate that all data is stable, but it
> > does so even if it is still in its internal cache. From this point of
> > view, fsync(2) is not a replacement for O_DIRECT.
>
> If the drive doesn't accurately indicate whether data has been written
> to the physical medium, that will affect everything, including
> O_DIRECT. There have been cases of drives which indicate that data has
> been written even when it's still in the cache, in order to improve
> benchmark scores.
That's what all (IDE) drives do; they simply lie about the state of
data in their internal caches. And the kernel believes them; it has
no idea of what's in the drive's cache and has no controll over it.
SCSI drives also do caching, but the SCSI layer uses tags to turn
caching on and off if necessary. This is exactly what happens with
O_DIRECT on Linux.
> I don't believe that there's any difference between O_SYNC, O_DIRECT
> or fsync() in terms of their interpretation of "written to the
> hardware"; they all send a "flush" command to the drive and block
> until the drive reports completion.
It depends heavily on the i/o subsystem and the i/o media. There is a
significant difference between IDE and SCSI drives. The latter report
data to be stable on disk only, if the blocks held in cache have found
their place on the disk.
> The advantage of O_DIRECT is that it won't displace existing blocks
> from the kernel's buffer cache, which might be useful if you're
> writing a lot of data and won't be reading it back in any time soon.
Exactly, and most SCSI (and some more advanced IDE/SATA controllers)
take that into account. They offer fairly good services for drivers
to allow OSes to handle some special i/o requests as it is the case
for O_DIRECT.
> According to:
>
> http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B99794
>
> that is more than what FILE_FLAG_WRITE_THROUGH does:
>
> The FILE_FLAG_WRITE_THROUGH flag for CreateFile() causes any
> writes made to that handle to be written directly to the file
> without being buffered. The data is cached (stored in the disk
> cache); however, it is still written directly to the file.
> This method allows a read operation on that data to satisfy
> the read request from cached data (if it's still there),
> rather than having to do a file read to get the data. The
> write call doesn't return until the data is written to the
> file. This applies to remote writes as well--the network
> redirector passes the FILE_FLAG_WRITE_THROUGH flag to the
> server so that the server knows not to satisfy the write
> request until the data is written to the file.
>
> O_DIRECT appears closer to FILE_FLAG_NO_BUFFERING:
>
> The FILE_FLAG_NO_BUFFERING takes this concept one step further
> and eliminates all read-ahead file buffering and disk caching
> as well, so that all reads are guaranteed to come from the
> file and not from any system buffer or disk cache. When using
> FILE_FLAG_NO_BUFFERING, disk reads and writes must be done on
> sector boundaries, and buffer addresses must be aligned on
> disk sector boundaries in memory.
>
> IOW, FILE_FLAG_WRITE_THROUGH corresponds to O_SYNC while
> FILE_FLAG_NO_BUFFERING corresponds to O_DIRECT.
Agree on that one. I read the OP as a request on how to do "true"
cacheless i/o.
Nevertheless, it should be noted that O_DIRECT usually downgrades
overall performance if called synchronously. There is no point in
doing so, exactly because of the above reasons.
\Steve
^ permalink raw reply
* Re: [Xenomai-help] question about the latency test running on Blackfin
From: Philippe Gerum @ 2006-04-06 7:05 UTC (permalink / raw)
To: adam li; +Cc: xenomai
In-Reply-To: <1144294706.12272.32.camel@domain.hid>
adam li wrote:
> Hi,
>
> I tried to run the "latency" test on Blackfin 533-STAMP board, in
> different modes. Here is the output of the test result:
>
> (I am using xenomai-2.1.0 with default configuration,(adding "timer
> benchmark" driver)).
>
> 1. # latency -h -t0 -T30
> HSH|--param|--samples-|--average--|---stddev--
> HSS| min| 29| 9.862| 0.581
> HSS| avg| 299964| 11.380| 2.676
> HSS| max| 29| 49.759| 5.296
>
> # cat /proc/xenomai/stat
> CPU PID MSW CSW PF STAT NAME
> 0 0 0/0 288239 0 00400080 ROOT
> 0 47 23/22 145 0 00300082 display
> 0 48 1/0 220501 0 00300084 sampling
>
>
> 2. # latency -h -t1 -T30
> HSH|--param|--samples-|--average--|---stddev--
> HSS| min| 29| 6.552| 0.686
> HSS| avg| 299985| 8.849| 1.601
> HSS| max| 29| 35.379| 6.383
>
> cat /proc/xenomai/stat
> CPU PID MSW CSW PF STAT NAME
> 0 0 0/0 436079 0 00400080 ROOT
> 0 58 6/5 42 0 00300082 display
> 0 0 0/0 57685 0 00000084 timerbench
>
>
> 3. # latency -h -t2 -T30
> == Sampling period: 100 us
> == Test mode: in-kernel timer handler
> == All results in microseconds
> warming up...
> RTT| 00:00:01 (in-kernel timer handler, 100 us period)
> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
> worst
> RTD| -5.340| -4.385| 8.064| 0| -5.340|
> 8.064
> RTD| -6.848| -4.359| 8.907| 0| -6.848|
> 8.907
> RTD| -6.443| -4.518| 23.878| 0| -6.848|
> 23.878
> RTD| -5.757| -4.240| 23.377| 0| -6.848|
> 23.878
> RTD| -6.153| -4.144| 24.107| 0| -6.848|
> 24.107
> RTD| -5.446| -4.040| 18.754| 0| -6.848|
> 24.107
> RTD| -7.697| -4.690| 20.319| 0| -7.697|
> 24.107
>
> HSH|--param|--samples-|--average--|---stddev--
> HSS| min| 29| 5.621| 0.820
> HSS| avg| 299979| 3.990| 0.774
> HSS| max| 29| 15.966| 6.248
>
>
> And my questions are:
>
> 1). Compared the output of Mode 0 (user space task) and Mode 1 (kernel
> space task), the average latency of Mode 1 is shorter. In Mode 1, the
> "timerbench" thread is running in primary mode, but what makes the
> latency in secondary mode longer?
>
Both modes 0 and 1 exhibit threads running in primary mode. The
difference is that mode 1 runs kernel based threads which are mostly
seen as co-routines, whilst mode 0 runs user-space based ones. Mode 0
involves the additional cost of dealing with full user-space context
switches.
> 2) From the output of Mode 0, the "MSW" field of "sampling" thread is
> always 1/0, does that mean the "sampling" thread will switch to primary
> mode and keep stay in primary mode throughout the test?
>
Yes.
> 3) In Mode 2 (timer handler in kernel space), the "lat min" and "lat
> avg" is negative, is this correct?
Yes, it only means that your pre-calibrated jitter compensation value is
over-pessimistic, and could be lowered. This value is substracted from
timer shot dates in order to take into account the intrinsic latency of
your board and of Xenomai-related scheduling latency. See
ksrc/include/asm-blackfin/calibration.h. You can override this value
using the "timing" configuration menu.
If it is correct, why the latency is
> much shorter than mode 1(kernel space task)?
>
Because mode 1 measures the scheduling latency, whilst mode 2 only
measures the interrupt latency.
> And finally a general question:
> 4) why there is RTDM? What is the design purpose?
It's a unifying, RTOS-agnostic, driver-class agnostic, API-agnostic
framework for building real-time device drivers. It's the cornerstone of
Xenomai's real-time device support.
If I were to write
> Realtime device drivers, shall I use RTDM?
>
Yes, definitely.
>
> Thanks,
>
> -Li Yi
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
>
--
Philippe.
^ permalink raw reply
* -- warning("vs-44", "out of memory?"); --[ addendum ]--
From: Roy Lanek @ 2006-04-06 7:07 UTC (permalink / raw)
To: reiserfs-list
Notice that I am--happily--on reiser4 since the beginning
of the 2.6.x series (of course with the same hardware
... on Reiser since the last 2.2.x by the way). And that
the freezing thing ... perhaps once every several days,
does not come as a novelty. New is that I have been able,
perhaps thanks to grsecurity, to see more near (maybe) at
the freezing, for once. The system is otherwise DECENTLY
usable really, provided one does not start to use the
GIMP, Open Office or similar.
Cheers,
/Roy Lanek
--
########################
##### . slackware ###### rajin pangkal pandai
##### +-----linux ###### diligence is the beginning of brilliance
########################
^ permalink raw reply
* Re: -- warning("vs-44", "out of memory?");
From: Vladimir V. Saveliev @ 2006-04-06 7:12 UTC (permalink / raw)
To: Roy Lanek; +Cc: reiserfs-list
In-Reply-To: <20060406064132.11477.qmail@mail.httpdnet.com>
Hello
On Thu, 2006-04-06 at 06:41 +0000, Roy Lanek wrote:
> There might be something to debug around:
>
> warning("vs-44", "out of memory?");
>
> line 2674 of /.../linux/fs/reiser4/plugin/file/file.c
>
> In fact, I just have seen a long, unterminated series of
> reiser4-out-of-memory warnings in my logs when my box
> has started to freeze ... till it has frozen completely
> several minutes later.
>
> Unfortunately I have lost all the logs (see below) ... I
> am sad for the #---- cut out --- thing that I have seen
> and can't reproduce; I had to reboot and did not want to
> write down by hand the few items that were visible trough
> the few overlapped xterms (+ elvis).
>
> Don't worry, it will happen again enough soon: if you say
> that it makes sense, I will manage to not be caught by
> surprise again, will try to save the logs immediately,
> when the system starts to freeze.
>
Yes, please so because it is very likely that "vs-44" was preceded by
another log record which showed the real crash reason.
> OK, here a bit more context:
>
> ** kernel (... uname):
>
> 2.6.16.1-grsec #3 Wed Apr 5 22:46:36 WIT 006 i586 pentium
> i386 GNU/Linux
>
> compiled without debug support for reiser4
>
> vanilla patches reiser4-for-2.6.16-1
> + grsecurity-2.1.9-2.6.16.1-200604041154
>
> ** runit-1.4.1 + socklog-2.1.0
>
> ** Slackware current, i.e., gcc 3.4.6
>
> ** a P166/32 Mb + non SCSI HDs. (It works, I swear, and
> well too!)
>
>
> Cheers,
>
> /Roy Lanek (West Sumatra)
>
> --
> ######################## tak ada gading yang tak retak
> ##### . slackware ###### there are no ivory that is not cracked
> ##### +-----linux ###### [nothing is perfect in this world]
> ########################
>
^ permalink raw reply
* Re: [PATCH/RFC] libata-dev: make the returned err_mask more accurate
From: Tejun Heo @ 2006-04-06 7:14 UTC (permalink / raw)
To: albertl; +Cc: Jeff Garzik, IDE Linux, Doug Maxey
In-Reply-To: <4434BD0C.9080302@tw.ibm.com>
Hello, Albert.
On Thu, Apr 06, 2006 at 03:02:36PM +0800, Albert Lee wrote:
[-- snip --]
> --- irq-pio0/include/linux/libata.h 2006-04-06 10:08:48.000000000 +0800
> +++ irq-pio1/include/linux/libata.h 2006-04-06 13:44:25.000000000 +0800
> @@ -942,6 +942,46 @@ static inline int ata_try_flush_cache(co
> ata_id_has_flush_ext(dev->id);
> }
>
> +static inline unsigned int ac_err_drq(u8 status)
> +{
> + /* BSY = 1*/
> + if (status & ATA_BUSY)
> + return AC_ERR_HSM;
> +
> + /* BSY = 0, DRQ = 1 */
> + if (status & ATA_DRQ)
> + return 0;
> +
> + /* BSY = 0, DRQ = 0, device err */
> + if (status & (ATA_ERR | ATA_DF))
> + return AC_ERR_DEV;
> +
> + /* BSY = 0, DRQ = 0, no device err
> + * when we are expecting data transfer.
> + */
> + return AC_ERR_HSM;
> +}
> +
> +static inline unsigned int ac_err_idle(u8 status)
> +{
> + /* BSY = 1 or DRQ = 1 */
> + if (status & (ATA_BUSY | ATA_DRQ))
> + return AC_ERR_HSM;
> +
> + /* BSY = 0, DRQ = 0, device err */
> + if (status & (ATA_ERR | ATA_DF))
> + return AC_ERR_DEV;
> +
> + /* BSY = 0, DRQ = 0, no device err. DRDY = 1 */
> + if (status & ATA_DRDY)
> + return 0;
> +
> + /* thing looks good.
> + * don't know why DRDY not set.
> + */
> + return AC_ERR_OTHER
> +}
> +
I don't think putting these two functions into libata.h as inlines is
a good idea. As currently there are no users, it would be better to
put them where they are used as static functions and export it later
as necessary.
--
tejun
^ permalink raw reply
* Somebody, please help me!
From: Buyung Permata Alam @ 2006-04-06 7:14 UTC (permalink / raw)
To: linux-msdos
Hello..
I need help, I am building RPM for dosemu-1.3.3. But I
still confuse (don't know) what I must type at %files
tag in dosemu-1.3.3.spec. Would You please help me to
complete the file.
Here is dosemu-1.3.3.spec that I wrote:
Summary: Disk Operating System (DOS) emulator
Name: dosemu
Version: 1.3.3
Release: 1
License: GPL
Group: Applications/System
Source:
http://jaist.dl.sourceforge.net/sourceforge/dosemu/dosemu-1.3.3.tgz
URL: http://www.dosemu.org
Distribution: Fedora Core 4
Vendor: SourceForge.net
%description
DOSemu stands for DOS Emulation, and allows you to run
DOS and many DOS programs and DOS games (16 bit
Applications), including many DPMI applications such
as Magic Pockets, DOOM and Windows 3.1, under Linux.
DOSemu can run with MS-DOS, Win95/98 DOS, or freedos
with minimum hardware requirement.
%prep
rm -rf $RPM_BUILD_DIR/dosemu-1.3.3
tar -zxvf $RPM_SOURCE_DIR/dosemu-1.3.3.tgz
%build
cd dosemu-1.3.3
make
%install
cd dosemu-1.3.3
make install
%files
/usr/local/bin/dosemu
(I don't what I must list here..)
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: libata machine check on Alpha
From: Albert Lee @ 2006-04-06 7:14 UTC (permalink / raw)
To: Doug Maxey
Cc: Tejun Heo, Jeff Garzik, albertl, Carlos Pardo,
Jonathan Blake Benson, linux-ide
In-Reply-To: <200604060644.k366i0O6007713@falcon30.maxeymade.com>
Doug Maxey wrote:
> On Thu, 06 Apr 2006 14:38:39 +0800, Albert Lee wrote:
>
>>Tejun Heo wrote:
>>
>>>Jeff Garzik wrote:
>>>
>>>>DMADIR is in my copy of ATA-7...
>>>>
>>>
>>>Here's the relavant part from ATA8 draft. It seems that the bridge is
>>>supposed to mangle the IDENTIFY PACKET DEVICE result. It's supposed to
>>>nuke all DMA transfer mode information reported from the original device
>>>and report supported modes from the view point of the bridge in bits
>>>10:1 (which, BTW, should be all 1's).
>>>
>>>The question is whether or not bridges implement this properly. I think
>>>we can add a printk to word 62 and ask Jonathan to test it.
>>>
>>
>>Ah, thanks for the info. The DMADIR is in my copy ATA-7, too.
>>I just checked word 50 and overlooked it. :(
>>I should have checked other part of the spec...
>>
>>Anyway, will try to make a patch based on the ATA-7 spec.
>
>
> Do we have any devices to test your patch with? Perhaps in Rochester?
>
Yes, we have some Marvell bridges in Rochester to test.
I'll also test the JMicron bridge, once the auto enable DMADIR patch is ready.
We have no SiI 3611 at hand, so, need Jonathan's help.
--
Albert
^ permalink raw reply
* Re: [uml-devel] system call accessing the host os
From: Olivier Crameri @ 2006-04-06 7:18 UTC (permalink / raw)
To: Jeff Dike; +Cc: user-mode-linux-devel
In-Reply-To: <20060406014338.GB6924@ccure.user-mode-linux.org>
>
>> Then, when I use fread to read
>> my file into this buffer, if I read a small number of bytes, it
>> works.
>> However when I try to fread the entire file (38k), fread returns 0.
>
> What's the break point between working and non-working?
It looks like it's on a page boundary. 4095 bytes is ok, 4096 is not
I'm using 2.6.15.6 with the latest 2.6.15 patch from Blaisorblade's
website.
Regards,
Olivier
-------------------------------------------------------
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
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply
* Re: [patch 1/3] mm: An enhancement of OVERCOMMIT_GUESS
From: Hideo AOKI @ 2006-04-06 7:20 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: akpm, linux-kernel, linux-mm
In-Reply-To: <20060406094533.b340f633.kamezawa.hiroyu@jp.fujitsu.com>
Hi Kamezawa-san,
Thank you for your comments.
KAMEZAWA Hiroyuki wrote:
> Hi, AOKI-san
>
> On Wed, 05 Apr 2006 19:47:27 -0400
> Hideo AOKI <haoki@redhat.com> wrote:
>
>
>>Hello Andrew,
>>
>>Could you apply my patches to your tree?
>>
>>These patches are an enhancement of OVERCOMMIT_GUESS algorithm in
>>__vm_enough_memory(). The detailed description is in attached patch.
>
> I think adding a function like this is more simple way.
> (call this istead of nr_free_pages().)
> ==
> int nr_available_memory()
> {
> unsigned long sum = 0;
> for_each_zone(zone) {
> if (zone->free_pages > zone->pages_high)
> sum += zone->free_pages - zone->pages_high;
> }
> return sum;
> }
> ==
I like your idea. But, in the function, I think we need to care
lowmem_reserve too.
Since __vm_enough_memory() doesn't know zone and cpuset information,
we have to guess proper value of lowmem_reserve in each zone
like I did in calculate_totalreserve_pages() in my patch.
Do you think that we can do this calculation every time?
If it is good enough, I'll make revised patch.
> BTW, vm_enough_memory() doesn't eat cpuset information ?
I think this is another point which we should improve.
Best regards,
Hideo Aoki
---
Hideo Aoki, Hitachi Computer Products (America) Inc.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* can anybody check that the attached patch eliminates reiser4 compilation warnings on 64bit platforms?
From: Alexander Zarochentsev @ 2006-04-06 7:20 UTC (permalink / raw)
To: reiserfs-list
[-- Attachment #1: Type: text/plain, Size: 1884 bytes --]
hello,
would you please help to check the attached patch (for 2.6.17-rc1-mm1)
because our Alpha does not want to boot now.
the warning were:
fs/reiser4/jnode.c: In function `info_jnode':
fs/reiser4/jnode.c:1923: warning: long long unsigned int format, __u64
arg (arg 2)
fs/reiser4/key.c: In function `print_key':
fs/reiser4/key.c:88: warning: long long unsigned int format, oid_t arg
(arg 3)
fs/reiser4/key.c:88: warning: long long unsigned int format, __u64 arg
(arg 5)
fs/reiser4/key.c:88: warning: long long unsigned int format, __u64 arg
(arg 6)
fs/reiser4/key.c:88: warning: long long unsigned int format, oid_t arg
(arg 7)
fs/reiser4/key.c:88: warning: long long unsigned int format, __u64 arg
(arg 8)
fs/reiser4/key.c:94: warning: long long unsigned int format, oid_t arg
(arg 3)
fs/reiser4/key.c:94: warning: long long unsigned int format, __u64 arg
(arg 5)
fs/reiser4/key.c:94: warning: long long unsigned int format, oid_t arg
(arg 6)
fs/reiser4/key.c:94: warning: long long unsigned int format, __u64 arg
(arg 7)
fs/reiser4/super_ops.c: In function `reiser4_dirty_inode':
fs/reiser4/super_ops.c:176: warning: long long unsigned int format,
oid_t arg (arg 9)
fs/reiser4/plugin/file_ops_readdir.c: In function `readdir_common':
fs/reiser4/plugin/file_ops_readdir.c:635: warning: long long unsigned
int format, oid_t arg (arg 9)
fs/reiser4/plugin/dir_plugin_common.c: In function `rem_entry':
fs/reiser4/plugin/dir_plugin_common.c:207: warning: long long unsigned
int format, oid_t arg (arg 9)
fs/reiser4/plugin/file/file.c: In function `delete_object_unix_file':
fs/reiser4/plugin/file/file.c:2986: warning: long long unsigned int
format, oid_t arg (arg 9)
fs/reiser4/plugin/space/bitmap.c: In function `bnode_check_adler32':
fs/reiser4/plugin/space/bitmap.c:506: warning: long long unsigned int
format, bmap_nr_t arg (arg 9)
Thanks in advance.
--
Alex.
[-- Attachment #2: reiser4-fix-compilation-warnings-on-alpha.diff --]
[-- Type: text/x-diff, Size: 4523 bytes --]
A fix for printk format specifications and __u64 arguments mismatch, visible
on Alpha platform.
Signed-off-by: <zam@namesys.com>
---
fs/reiser4/key.c | 16 +++++++++-------
fs/reiser4/plugin/dir_plugin_common.c | 2 +-
fs/reiser4/plugin/file/file.c | 2 +-
fs/reiser4/plugin/file_ops_readdir.c | 2 +-
fs/reiser4/plugin/space/bitmap.c | 2 +-
fs/reiser4/super_ops.c | 2 +-
6 files changed, 14 insertions(+), 12 deletions(-)
Index: linux-2.6.17-rc1-mm1/fs/reiser4/key.c
===================================================================
--- linux-2.6.17-rc1-mm1.orig/fs/reiser4/key.c
+++ linux-2.6.17-rc1-mm1/fs/reiser4/key.c
@@ -81,17 +81,19 @@ void print_key(const char *prefix /* pre
else {
if (REISER4_LARGE_KEY)
printk("%s: (%Lx:%x:%Lx:%Lx:%Lx:%Lx)", prefix,
- get_key_locality(key),
+ (unsigned long long)get_key_locality(key),
get_key_type(key),
- get_key_ordering(key),
- get_key_band(key),
- get_key_objectid(key), get_key_offset(key));
+ (unsigned long long)get_key_ordering(key),
+ (unsigned long long)get_key_band(key),
+ (unsigned long long)get_key_objectid(key),
+ (unsigned long long)get_key_offset(key));
else
printk("%s: (%Lx:%x:%Lx:%Lx:%Lx)", prefix,
- get_key_locality(key),
+ (unsigned long long)get_key_locality(key),
get_key_type(key),
- get_key_band(key),
- get_key_objectid(key), get_key_offset(key));
+ (unsigned long long)get_key_band(key),
+ (unsigned long long)get_key_objectid(key),
+ (unsigned long long)get_key_offset(key));
/*
* if this is a key of directory entry, try to decode part of
* a name stored in the key, and output it.
Index: linux-2.6.17-rc1-mm1/fs/reiser4/plugin/dir_plugin_common.c
===================================================================
--- linux-2.6.17-rc1-mm1.orig/fs/reiser4/plugin/dir_plugin_common.c
+++ linux-2.6.17-rc1-mm1/fs/reiser4/plugin/dir_plugin_common.c
@@ -206,7 +206,7 @@ rem_entry(struct inode *dir, struct dent
if (get_key_objectid(&key) != get_inode_oid(child)) {
warning("nikita-3397",
"rem_entry: %#llx != %#llx\n",
- get_key_objectid(&key),
+ (unsigned long long)get_key_objectid(&key),
(unsigned long long)get_inode_oid(child));
return RETERR(-EIO);
}
Index: linux-2.6.17-rc1-mm1/fs/reiser4/plugin/file/file.c
===================================================================
--- linux-2.6.17-rc1-mm1.orig/fs/reiser4/plugin/file/file.c
+++ linux-2.6.17-rc1-mm1/fs/reiser4/plugin/file/file.c
@@ -2971,7 +2971,7 @@ int delete_object_unix_file(struct inode
if (result)
warning("", "failed to truncate file (%llu) on removal: %d",
- get_inode_oid(inode), result);
+ (unsigned long long)get_inode_oid(inode), result);
/* remove stat data and safe link */
return delete_object_common(inode);
Index: linux-2.6.17-rc1-mm1/fs/reiser4/plugin/file_ops_readdir.c
===================================================================
--- linux-2.6.17-rc1-mm1.orig/fs/reiser4/plugin/file_ops_readdir.c
+++ linux-2.6.17-rc1-mm1/fs/reiser4/plugin/file_ops_readdir.c
@@ -633,7 +633,7 @@ int readdir_common(struct file *f /* dir
if (reiser4_grab_space(inode_file_plugin(inode)->estimate.update(inode),
BA_CAN_COMMIT) != 0)
warning("", "failed to update atime on readdir: %llu",
- get_inode_oid(inode));
+ (unsigned long long)get_inode_oid(inode));
else
file_accessed(f);
Index: linux-2.6.17-rc1-mm1/fs/reiser4/plugin/space/bitmap.c
===================================================================
--- linux-2.6.17-rc1-mm1.orig/fs/reiser4/plugin/space/bitmap.c
+++ linux-2.6.17-rc1-mm1/fs/reiser4/plugin/space/bitmap.c
@@ -505,7 +505,7 @@ bnode_check_adler32(const struct bitmap_
warning("vpf-263",
"Checksum for the bitmap block %llu is incorrect",
- bmap);
+ (unsigned long long)bmap);
return RETERR(-EIO);
}
Index: linux-2.6.17-rc1-mm1/fs/reiser4/super_ops.c
===================================================================
--- linux-2.6.17-rc1-mm1.orig/fs/reiser4/super_ops.c
+++ linux-2.6.17-rc1-mm1/fs/reiser4/super_ops.c
@@ -174,7 +174,7 @@ static void reiser4_dirty_inode(struct i
result = reiser4_update_sd(inode);
if (result)
warning("", "failed to dirty inode for %llu: %d",
- get_inode_oid(inode), result);
+ (unsigned long long)get_inode_oid(inode), result);
}
/**
^ permalink raw reply
* Re: [patch 1/3] mm: An enhancement of OVERCOMMIT_GUESS
From: Hideo AOKI @ 2006-04-06 7:20 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: akpm, linux-kernel, linux-mm
In-Reply-To: <20060406094533.b340f633.kamezawa.hiroyu@jp.fujitsu.com>
Hi Kamezawa-san,
Thank you for your comments.
KAMEZAWA Hiroyuki wrote:
> Hi, AOKI-san
>
> On Wed, 05 Apr 2006 19:47:27 -0400
> Hideo AOKI <haoki@redhat.com> wrote:
>
>
>>Hello Andrew,
>>
>>Could you apply my patches to your tree?
>>
>>These patches are an enhancement of OVERCOMMIT_GUESS algorithm in
>>__vm_enough_memory(). The detailed description is in attached patch.
>
> I think adding a function like this is more simple way.
> (call this istead of nr_free_pages().)
> ==
> int nr_available_memory()
> {
> unsigned long sum = 0;
> for_each_zone(zone) {
> if (zone->free_pages > zone->pages_high)
> sum += zone->free_pages - zone->pages_high;
> }
> return sum;
> }
> ==
I like your idea. But, in the function, I think we need to care
lowmem_reserve too.
Since __vm_enough_memory() doesn't know zone and cpuset information,
we have to guess proper value of lowmem_reserve in each zone
like I did in calculate_totalreserve_pages() in my patch.
Do you think that we can do this calculation every time?
If it is good enough, I'll make revised patch.
> BTW, vm_enough_memory() doesn't eat cpuset information ?
I think this is another point which we should improve.
Best regards,
Hideo Aoki
---
Hideo Aoki, Hitachi Computer Products (America) Inc.
^ permalink raw reply
* Re: H.323 conntrack/NAT helper update for 2.6.17-rc1
From: Harald Welte @ 2006-04-06 7:29 UTC (permalink / raw)
To: Jing Min Zhao; +Cc: netfilter-devel
In-Reply-To: <BAY109-DAV7DCCFD349A50D33911B99B3CB0@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 875 bytes --]
On Wed, Apr 05, 2006 at 11:32:35AM -0400, Jing Min Zhao wrote:
> I sent it first in plain text the day before yesterday, but it didn't show up.
> I thought it was too big to be processed, so I sent it compressed again. Now it
> seems just because it was slow. I'm sorry I didn't know this.
No problem at all. The delay was due to administrative downtime of the
mailinglist server.
I was merely recommending you to send it as plain text in the future, so
no offence taken, no harm done ;)
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: deleting partition does not effect superblock?
From: Damian Menscher @ 2006-04-06 7:31 UTC (permalink / raw)
To: Sumit Narayan; +Cc: linux-kernel, ext3-users
In-Reply-To: <1458d9610604052337p2cafa6c8j78fc6da8c5f8be1a@mail.gmail.com>
On Thu, 6 Apr 2006, Sumit Narayan wrote:
> On my system, I first created a partition with EXT3 and put some data
> on it. Later, I deleted the partition, and re-created another
> partition with the same starting block number and a higher ending
> block number. I intended to format it with another filesystem, but
> surprisingly (or maybe just to me), the superblock of the partition
> had not changed. I could still mount the new partition as the same old
> filesystem. I could see all the files which was present earlier. Doing
> 'df' showed me the older partition details (size, % used etc.).
>
> Shouldn't the superblock be changed/deleted once the partition is
> deleted? I tried a reboot, but the output remained the same.
This is the expected behavior. A filesystem is created within the
partition. If you grow the partition, the filesystem doesn't
automatically grow (use resize2fs for that). In fact, you should
probably read the resize2fs manpage, as it might give you some starting
clue of what's going on.
Damian Menscher
--
-=#| <menscher@uiuc.edu> www.uiuc.edu/~menscher/ Ofc:(650)253-2757 |#=-
-=#| The above opinions are not necessarily those of my employers. |#=-
^ permalink raw reply
* SCSI Bidirectional data transfer
From: Maze Maze @ 2006-04-06 7:34 UTC (permalink / raw)
To: linux-kernel
Hi,
I am using redhate linux (kernel 2.4.20)
SCSI supports bidirectional data transfer. However, the two variants
request_bufflen and bufflen of a scsi_cmd are set to be the same in
the scsi_init_cmd_from_req(). I am wondering if i want to send and
receive data with different lengths, how do i pass the lengths to SCSI
layer? The scsi_wait_req() accepts only one length.... Can I make use
of extended CDB? Thanks!
Maze
^ 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.