From [EMAIL PROTECTED] Mon Apr 16 08:35:09 2001
Andries.Brouwer writes:
> What one wants is to remap access to sector 0 to sector 1,
> and leave all other sectors alone. Thus, if someone asks
> for sectors 0 1 2 3 4, she should get sectors 1 1 2 3 4.
No, because then you
> The block device uses 1K blocksize, and will prevent userspace from
> seeing the odd-block at the end of the disk, if the disk is odd-size.
>
> IA-64 architecture defines a new partitioning scheme where there is a
> backup of the partition table header in the last sector of the disk. While
>
From [EMAIL PROTECTED] Wed Feb 14 00:37:25 2001
> Look at the addpart utility in the util-linux package.
> It will allow you to add a partition disjoint from
> previously existing partitions.
> And since a partition can start on an odd sector,
> this should allow you to al
> My patch has nothing to do with partitioning.
Yes, you already said that, and I understand you very well.
My suggestion, and I have not checked the code to make sure,
but off-hand it seems to me that it should work,
is to use a partition.
> Disk with 1001 blocks. Hardware 512-byte sector size.
Recently I got some more detailed information on Japanese keyboards
and their scancodes. Maybe there are Japanese readers here who
can look at
http://www.win.tue.nl/~aeb/linux/kbd/scancodes-3.html#ss3.3
and correct what is wrong?
Andries
-
To unsubscribe from this list: send the line "uns
From [EMAIL PROTECTED] Sat Feb 17 22:45:36 2001
I'm sending this to you with the hope that lines like this (in ipcs.c)
can be modified to report proper values:
printf ("%-10o%-12ld%-12ld\n",
ipcp->mode & 0777,
/*
* gli
From: Jon Forsberg <[EMAIL PROTECTED]>
I have two ext2 CD-ROMs. One of them I can mount the normal way,
the other I can't. Both are ok according to debugfs and e2fsck
and if I do
'mount -t ext2 -o loop /dev/cdrom /cdrom'
instead, both work.
The one that doesn't wo
> A value of hardsect_size[] means: this is the smallest size
> the hardware can work with. It is therefore a serious mistake
> just to come with "a good guess". This value is used only
You are defeating the entire purpose of having a hardware sector
size independently from t
From: Jens Axboe <[EMAIL PROTECTED]>
On Sat, Feb 17 2001, John Fremlin wrote:
> Specifically, this part:
>
> @@ -2324,11 +2309,17 @@
> sense.ascq == 0x04)
> return CDS_DISC_OK;
>
> +
> + /*
>
> You are defeating the entire purpose of having a hardware sector
> size independently from the software block size. And 2kB is a
> valid guess, apart from the drives that do 512 byte transfers too
> 2kB is really the smallest transfer we can do.
>
> : And
For a beginner I recently wrote a tiny demonstration
of what the kernel does, given a trivial user program.
Now that it served its purpose it would be a pity to
throw it out again, maybe it can be useful to someone else.
See
http://www.win.tue.nl/~aeb/linux/vfs/trail-1.html
Andries
-
To
Now that people are discussing the right hash function to use,
and the amount of space taken by filenames in various schemes,
I wondered how these things are on a random machine.
Here some statistics.
Andries
--
Statistics on a filesys
>> idea of using crc32 as the default hash function
> I once liked those things, too - but I've learned better since.
> A universal class of hashing functions is a class with the property that
> given any input, the average performance of all the functions is good.
> For example, h(k) = (a * k +
Just looking at R5 I knew it wasn't going to do well in this application
because it's similar to a number of hash functions I tried with the same
idea in mind: to place similar names together in the same leaf block.
That turned out to be not very important compared to achieving a
From [EMAIL PROTECTED] Fri Feb 23 04:43:23 2001
> Now that you provide source for r5 and dx_hack_hash, let me feed my
> collections to them.
> r5: catastrophic
> dx_hack_hash: not bad, but the linear hash is better.
I never expected dx_hack_hash to be particularly good at
> BTW, we probably want to add mount --move - atomically moving
> a subtree from one place to another. Code is there, we just need to
> decide on API. Andries?
Since we already have "mount --bind olddir newdir" this is not
an unreasonable extension of the mount(8) syntax.
And since the kernel i
From [EMAIL PROTECTED] Mon Feb 26 12:10:59 2001
Andries, others,
Thanks for hacking through the code of fs/partitions/ibm.c.
Your patch does not work at all because you are relying on the
data in the part component of the hd structure, which does not
hold the geometry data
> your arguments appear correct to me
> I include the patch to be applied from my point of view
Good. Had no time today to look at the details, but at first sight
this is a big improvement. May want to nitpick a little some other time.
Andries
-
To unsubscribe from this list: send the line "unsu
>> kbd-1.05 comes with sun12x22.psfu, which essentially is the kernel font
>> together with a unimap.
> Note, that I also have a SuSE12x22 font, which is based on the Sun font,
> some charcaters slightly changed and added lots of 8859-1 symbols.
> Isn't it included in kbd-1.04 and later, Andries?
>> For 2.5 we could perhaps think about a new swapfile layout
> The format seems to be just fine.
No, the present definition is terrible.
Read the mkswap source. A forest of #ifdefs,
and still sometimes user assistance is required
because mkswap cannot always figure out what the "pagesize" is.
From: Felix von Leitner <[EMAIL PROTECTED]>
If user !root says chown("/usr",-1,-1), he gets EPERM. Why?
Because the standard says:
The chown( ) function shall fail if:
[EPERM] The effective user ID does not match the owner of the file, or ..
Andries
-
To unsubscribe from this li
> And what does POSIX say about "#!/bin/sh\r" ?
Nothing at all. The #! construction is not part of any standard
right now. The implementation is messy - different operating systems
do vaguely similar things, but all details differ.
Linux can do whatever it wants.
Of course it helps portability if
> On Thu, 4 Jan 2001, Igmar Palsenberg wrote:
>
>> kernel 2.2.18 hates my Maxtor drive :
>> hda: Maxtor 96147H6, 32253MB w/2048kB Cache, CHS=65531/16/63, (U)DMA
>>
>> Actual (correct) parameters : CHS=119112/16/63
No. 2.2.* handles large drives since 2.2.14.
This looks more like you used the jump
> I need to look at fdisk, because it is doing things wrong.
I don't think so, unless you have a really old version.
> Linux sees the correct size, but fdisk still sees 32 GB.
> Probably a recompile / upgrade.
Yes, upgrade in case your version is older than 2.10i.
Andries
-
To unsubscribe from
> It's not that simple.. The maxtor comes clipped,. but Linux can't kill the
> clip. So it sticks with 32 MB
> ibmsetmax.c does a software clip, but that bugs a bit. Sometimes even
> Linux doesn't see 61 GB, but only 32, sometimes the full capacity.
Please don't talk vague useless garbage.
There
> Neither hwclock nor the /dev/rtc driver takes the following comment from
> set_rtc_mmss() in arch/i386/kernel/time.c into account.
> As a result, using hwclock --systohc or --adjust always leaves the
> Hardware Clock 500 ms ahead of the System Clock
By pure coincidence [EMAIL PROTECTED] sent me
> I don't have a problem with the rtc driver delaying 500ms
I still haven't looked at things, but two points:
(i) is the behaviour constant on all architectures?
(ii) instead of waiting, isn't it much easier to redefine
what it means to access rtc?
(If you read a certain value then on average you
> 2.2.18 sometimes sees 61 GB, sometimes 32 GB.
> I don't call that hard to understand.
The same kernel has varying behaviour?
Maybe not hard to understand, but rather surprising.
You are the first to report nondeterministic behaviour.
-
To unsubscribe from this list: send the line "unsubscribe l
> why `rmdir .` is been deprecated in 2.4.x?
> `rmdir .` makes perfect sense, the cwd dentry remains pinned
You think that it fails with EBUSY. That would be allowed but not required:
[EBUSY]: The directory to be removed is currently in use by
the system or some process and the impleme
> Calling pathconf with a symlink is not defined.
The Austin draft requires pathconf to follow symlinks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
From: Andrea Arcangeli <[EMAIL PROTECTED]>
> But in fact it fails with EINVAL, and
>
> [EINVAL]: The path argument contains a last component that is dot.
I can't confirm. The specs I'm checking are here:
http://www.opengroup.org/onlinepubs/007908799/xsh/rmdir.html
> I trust your specs said so, however I'm not sure which are the specs
> we should follow for Linux.
> At least for LFS 2.2.x fixage I always followed the SuSv2 specs
We are Linux, and free to do whatever we want.
However, following POSIX makes a large body of software available.
It would be ver
>> dd: advancing past 1 blocks in output file `/dev/fd0': Permission denied
> dd bug. It tries to ftruncate() the output file and gets all upset when
> kernel refuses to truncate a block device (surprise, surprise).
Yes. But EPERM means that something is wrong with privileges.
One would expect E
From: Igmar Palsenberg <[EMAIL PROTECTED]>
> > 2.2.18 sometimes sees 61 GB, sometimes 32 GB.
> > I don't call that hard to understand.
>
> The same kernel has varying behaviour?
> Maybe not hard to understand, but rather surprising.
> You are the first to report nonde
> what's the maximum swap size
See mkswap(8), making sure you have a non-ancient page
(one that mentions Linux 2.1.117).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
> The "none" bit puzzles me the most.
It is a common misconfiguration. Given a line
device dir type options garbage
in /etc/fstab, some umount versions will complain "device busy"
when the umount fails. Thus, it is better to use
proc/proc proc
devpts /dev/pts devpts
instea
> The signature on man-pages-1.34.tar.gz is bad:
Hmm, thought I had corrected that already.
Is it correct now?
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
From: Chris Wedgwood <[EMAIL PROTECTED]>
On Thu, Jan 11, 2001 at 09:34:08PM -0500, Michael Rothwell wrote:
The man pages for open, read and write say that if a file is opened
using the O_NONBLOCK flag, then read() and write() will always return
immediately and not
> the patch locates partitions inside the plan9
> i can't find anyone with plan9 to test,
I'll have a look.
A week ago you sent almost the same patch.
Was there a reason to change __u32 into unsigned long?
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
From: Ingo Molnar <[EMAIL PROTECTED]>
On Tue, 16 Jan 2001, Felix von Leitner wrote:
> I don't know how Linux does it, but returning the first free file
> descriptor can be implemented as O(1) operation.
to put it more accurately: the requirement is to be able to open(), use
Matti Aarnio writes:
> And the partitions are PHYSICAL partition numbers,
> not some logical ones.
That is very interesting. Can you explain to me what
physical partition numbers are?
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [
From: Anton Altaparmakov <[EMAIL PROTECTED]>
Subject: Getting the number of 512-byte sectors?
My question is how to get the _real_ number of sectors of a partition from
within a file system. I.e. we are starting only with the knowledge of the
struct super_block for the parti
> does partitioning slow things down?
No.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
On Mon, Nov 13, 2000 at 03:47:27PM -0800, LA Walsh wrote:
> Some further information in response to a private email, I did hdparm -ti
> under both
> 2216 and 2217 -- they are identical -- this may be something weird
> w/extended partitions...
What nonsense. There is nothing special with extended
On Mon, Nov 13, 2000 at 05:07:22PM -0700, Steven Cole wrote:
> +EISA support
> +CONFIG_EISA
> + The Extended Industry Standard Architecture (EISA) bus was
> + developed as an open alternative to the IBM MicroChannel bus.
> +
> + The EISA bus provided some of the features of the IBM MicroChanne
On Tue, Nov 14, 2000 at 03:23:05PM -0500, Jeff Garzik wrote:
> Andries Brouwer wrote:
> > However, CONFIG_EISA is almost completely superfluous, is not
> > required at compile time, can easily be tested at run time,
> > in other words adding such an option is a very stupid t
I have been using (a heavily patched) 2.4.0test9 since it was released
and have not seen any problems that I can recall. Booted (vanilla)
2.4.0test11pre5 a moment ago, but after
insmod ipchains.o
rsh foo
ping bar
the machine was completely dead immediately -
no ping/consol
On Wed, Nov 15, 2000 at 08:23:44PM +0100, Harald Koenig wrote:
> both 2.2.x and 2.4.x kernels can't read `real sky' CDs from the
> Space Telescope Science Institute containing lotsof directories (~100)
> which each contain lots of small files (~700 files/dir).
> only ~10 directories with ~10 fil
> Anybody else willing to finish this one off?
If noone else does, I suppose I can.
(> .. gets ENOENT ..
and that is not because it only is a partial image?)
Andries
PS - Yesterday I complained that 2.4.0test9 was fine
but 2.4.0test11pre5 dies as soon as it has to forward a ping.
The effect i
On Thu, Nov 16, 2000 at 06:53:30AM -0500, Alexander Viro wrote:
> > I didn't know about notrunc. Yet another GNU invention?
>
> Maybe, but I doubt it. Anyway, it made its way into 4.4BSD, it's present
> in Solaris, it's in SuS and AFAIK in POSIX.
Yes (for 1003.2-1992).
It is not in 4.3BSD.
-
To
> both 2.2.x and 2.4.x kernels can't read `real sky' CDs
Yes. 2.0.38 is OK. I just made a patch that seems to work.
Harald, could you try
ftp.xx.kernel.org/.../people/aeb/linux-2.4.0test9-isofs-patch
and report?
Linus, Alan - I made patches for 2.2 and 2.4 but want to
polish and check t
On Fri, Nov 17, 2000 at 09:30:13AM +0100, Kai Germaschewski wrote:
> One question comes to my mind: Are patches supposed to be applied with
> patch -p0 or patch -p1?
Suppose the kernel tree is in /kernpath, starting with /kernpath/linux.
Linus' patches can be applied by (cd /kernpath; patch -p0
On Thu, Nov 16, 2000 at 03:02:31AM -0500, Alexander Viro wrote:
: On Thu, 16 Nov 2000, Mikael Pettersson wrote:
:
:: dd implements the seek=NNN option by calling ftruncate() before
:: starting the write. This is where 2.4.0-test10 breaks, since
:: ftruncate on a block device now provokes an EACCE
> memory leak
Aha. Must be a missing kfree().
Does this help?
--- namei.c~Fri Nov 17 00:48:37 2000
+++ namei.c Fri Nov 17 21:59:49 2000
@@ -197,6 +197,8 @@
bh = NULL;
break;
}
+ if (cpnt)
+
On Wed, Nov 15, 2000 at 06:16:00AM -0500, Paul Gortmaker wrote:
> > What use is knowing that a machine has EISA slots? As far as I can see
> > the only use is to ask for the EISA ID of the card.
> > Should we? I collected 1200 .cfg files and estimate that this is
> > less than 10% of what exists
Linus:
> How about this version (full patch against test10 - it includes a
> slightly corrected version of my earlier dir.c patch)?
> It's entirely untested, but it looks good and compiles. Ship it!
There are three files that have to be changed.
You changed dir.c yesterday, and namei.c today
bu
> Some clues here
> ... escd.html ... escd.rtf
Thanks! I already had the former (but it refers to the EISA
spec for most details) will look for the latter.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read
>> I take it you'll also do the third part?
> Are you talking about isofs_lookup_grandparent()?
No, about isofs_read_inode.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/l
On Sun, Nov 19, 2000 at 01:53:00AM +0100, bert hubert wrote:
: On Sat, Nov 18, 2000 at 03:15:28PM -0800, Dan Hollis wrote:
:
::: In that case, the wording of the manpage needs to be changed, as it
::: implies that 'either or both' of the filedescriptors can be sockets.
::
:: Its quite clea
On Sun, Nov 19, 2000 at 04:30:34AM +0900, Taisuke Yamada wrote:
> Earlier this month, I had sent in a patch to 2.2.18pre17 (with
> IDE-patch from http://www.linux-ide.org/ applied) to add support
> for IDE disk larger than 32GB, even if the disk required "clipping"
> to reduce apparent disk size
From [EMAIL PROTECTED] Mon Nov 20 12:29:59 2000
Andries,
Don't you mean
(drive->id->cfs_enable_1 & 0x0400)word85
and not
(drive->id->command_set_1 & 0x0400)word82
Because when bit 10 of word 85 is not set then clip or HPArea is not enabled.
I saw no
William K. Josephson <[EMAIL PROTECTED]>
wrote on Sun, 8 Oct 2000:
> While writing some user-space code recently, I ran across two bugs
> in the Rock Ridge support code. First, a bogus return value and
> second links on the cd of the form foo->/bar are returned
> as foo->//bar. This should fix
A few days ago, and again half an hour ago, X stopped working.
Both times this happened in a period of heavy and continuous
IDE disk access (copying a 12 GB tree from one disk to another,
and doing a diff between two 5 GB trees on different disks).
No mouse movement, no reaction to Ctrl-Alt-Backs
Here the second patch in the isofs series.
inode.c:isofs_read_super() dereferences the variable pri
that need not be set in case of a Joliet CD, causing an Oops.
Patch below.
Andries
[While editing the diff, I left a fix for aha1542.c,
maybe you got it already. I also left something else
that a
From [EMAIL PROTECTED] Wed Nov 22 19:20:52 2000
> [EMAIL PROTECTED] a écrit :
> > I also left something else
> > that always annoyed me: valuable screen space (on a 24x80 vt)
> > is lost by these silly [< >] around addresses in an Oops.
> > They provide no information at
From [EMAIL PROTECTED] Thu Nov 23 00:17:21 2000
Well, in my experience, values of PC (or EIP is x86 speak) rarely
appear over column 50 on the screen. Therefore, removing them is
only going to save width, not height.
The EIP is not pushed out of sight horizontally, but verticall
> Thats because too many things get put on a line then.
> And because we do [] [] not [][] ?
In the good old times we had foo bar for a total of 8*(8+1) = 72
positions. Now we have [] [] which takes 8*(8+1+4) = 104
positions. If you turned this into 6 items per line instead of 8,
it would ce
After Linus' recent changes there were many complaints
about bugs in the isofs handling. Still, his code is fine.
I know about some things that still need to be done, and
already corrected two flaws yesterday or so, but people
sent me their isofs images and their problem was not caused
by anything
Yesterday night I wrote
> Note: this is not yet a confirmed compiler bug
but in the meantime there is good confirmation.
This really is a bug in gcc 2.95.2.
>From [EMAIL PROTECTED] Thu Nov 23 10:45:07 2000
> Please, could you send me ...
>From [EMAIL PROTECTED] Thu Nov 23 18:00:48 2000
> Can w
>> ... RedHat's GCC snapshot "2.96" handles this case just fine.
> Now, if you can isolate the relevant part of the diff between
> 2.95.2 and RH 2.96...
Maybe I have to be more precise in the statement "gcc 2.95.2 is buggy".
I just installed gcc 2.95.2 freshly ftp'ed from ftp.gnu.org, and
% /u
> so the reason why it did not show up in the gcc you picked up from
> ftp.gnu.org is that you have compiled it so that it defaults to -mcpu=i686
Yes, you are right.
So 2.95.2 fails for i386, i486, i586 and does not fail for i686.
Andries
-
To unsubscribe from this list: send the line "unsubscr
On Sat, Nov 25, 2000 at 03:26:15PM -0200, Rik van Riel wrote:
> The gcc-2.95.2-6cl from Conectiva 6.0 is buggy too.
Yes. Probably you have seen it by now, but the difference between
good and bad versions of gcc-2.95.2 did not lie in the applied patches,
but was the difference between compilation
On Sat, Nov 25, 2000 at 11:50:20AM +, Russell King wrote:
> Rusty Russell writes:
> > What irritates about these monkey-see-monkey-do patches is that if I
> > initialize a variable to NULL, it's because my code actually relies on
> > it; I don't want that information eliminated.
>
> What info
On Sat, Nov 25, 2000 at 06:20:56PM +0100, Arjan Filius wrote:
> Nov 25 18:16:05 sjoerd kernel: _isofs_bmap: block < 0
Understood and solved. For the whole story read linux-kernel.
To fix just this, remove the two lines
if (filp->f_pos >= inode->i_size)
return 0;
from li
On Sat, Nov 25, 2000 at 09:07:08PM +, Russell King wrote:
> Andries Brouwer writes:
> > What a strange reaction. If I write
> >
> > static int foo;
> >
> > this means that foo is a variable, local to the present compilation unit,
> > whose initia
On Sun, Nov 26, 2000 at 09:11:18AM +1100, Herbert Xu wrote:
> No information is lost.
Do I explain things so badly? Let me try again.
The difference between
static int a;
and
static int a = 0;
is the " = 0". The compiler may well generate the same code,
but I am not talking about the com
On Sat, Nov 25, 2000 at 10:27:15PM +, Tigran Aivazian wrote:
: Hello Andries,
Hi Tigran,
: ... I am quite free to _rely_ on this fact and will possibly do so.
Yes, you are. But some programmers have learned that it is a good
idea to code in a way that is informative to the programmer.
: >
On Sat, Nov 25, 2000 at 06:02:51PM -0500, Jeff Garzik wrote:
> Andries Brouwer wrote:
> > In a program source there is information for the compiler
> > and information for the future me. Removing the " = 0"
> > is like removing comments. For the compiler the inform
On Mon, Nov 27, 2000 at 12:16:41AM +0100, Stefan Frings wrote:
> [1.] One line summary of the problem:
>
> cannot ls cdroms (_isofs_bmap block >= EOF)
Yes, a well-known problem.
Delete two lines around line 118 of fs/isofs/dir.c:
- if (filp->f_pos >= inode->i_size)
- retur
On Sun, Nov 26, 2000 at 11:35:22PM -0400, Peter Cordes wrote:
> While doing some hdparm hacking, after booting with init=/bin/sh, I noticed
> that open(1) doesn't work when / is mounted read only.
Already long ago open(1) was renamed to openvt(1), so it may be that
have a very old version. See
On Mon, Nov 27, 2000 at 10:47:06PM +0100, Rogier Wolff wrote:
> Andries Brouwer wrote:
> > > access("/dev/tty2", R_OK|W_OK) = -1 EROFS (Read-only file system)
>
> > You misunderstand the function of access(). The standard says
> >
> > [EROFS]
On Mon, Nov 27, 2000 at 09:09:12PM +0100, Jörg Schütter wrote:
> after upgrading from test9 to test11, skipping test 10, I get
> the messages "_isofs_bmap: block < 0", "_isofs_bmap: block < ..."
> which also means I can't read the cd.
A FAQ. Remove the two lines
- if (filp->f_pos >= inod
On Mon, Nov 27, 2000 at 10:27:00PM +0100, Marcus Sundberg wrote:
> This reminded me of an old bug which apparently still hasn't been
> fixed (not in 2.2 at least). In init/main.c we have:
>
> extern int rd_image_start;/* starting block # of image */
> #ifdef CONFIG_BLK_DEV_INITRD
> kdev_t re
On Mon, Nov 27, 2000 at 08:27:38PM +0100, Petr Vandrovec wrote:
> could original complainer (and peoples with AMD SC*) test following
> patch? It just does nothing in case that A20 enabled bit is already
> set - such as in case when there is nobody listening on 0x92 and
> so inb returns 0xFF...
On Mon, Nov 27, 2000 at 05:40:58PM -0800, H. Peter Anvin wrote:
> > What about adding an additional
> >
> > andb$0xfe, %al
> >
> > in front of the outb?
> Already in test12-pre1.
Ach, I see I am too slow - had not even seen -pre1 and now Linus
already announces -pre2.
Anyway, I consi
On Tue, Nov 28, 2000 at 03:04:31PM +0100, Rogier Wolff wrote:
> Ok, so if you read the standard carefully you get a bogus result.
Why bogus? Things could have been otherwise, but the important
part is that all Unices do things the same way.
> Question: Was it meant this way, or did someone jus
I did again a large test comparing two identical trees.
Found again corruption, and, upon inspection, the disk
files did not differ - this is in-core corruption only.
A few days ago:
diff -r /c2/linux/linux-2.4.0-test10/linux/include/asm-sparc/ecc.h /g1/linux/li\
nux-2.4.0-test10/linux/include/a
> can you give a rough estimate on when you suspect you started seeing it?
I reported both cases. That is, I started seeing it a few days ago.
(But there is no problem during daily work. Also for example a
diff between two kernel trees never gave corruption so far.
It was only with diff between t
I just tried 2.4.0test12pre3, which has Jens' fix,
and no corruption to be seen. Will test a bit more,
but perhaps this did it.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org
Tried the same test three times with 2.4.0test11 - three times
corruption. Tried it three times with 2.4.0test12pre3 - no corruption.
Good!
On the other hand, isofs still lacks part of the required fixes.
Made a new patch relative to test12pre3.
Andries
-
diff -u --recursive --new-file
../
From [EMAIL PROTECTED] Wed Nov 29 17:52:57 2000
> Should the majority win? I.e. should we say OK, as we do now?
We should, but we don't. 2.4 does the right thing.
2.2 got the following change back in 2.2.6:
res = PTR_ERR(dentry);
if (!IS_ERR(dentry)) {
On Wed, Nov 29, 2000 at 05:24:15PM +0100, Santiago Garcia Mantinan wrote:
> I used to be able to run my 12 ethernet ports pentium based bridge without
> vga card, but with tty1, tty2, ... still working, as the kernel used to
> recognice a kind of a cga card on my machine even though there was non
> ISTR bug reports looking like that and IIRC they were never resolved.
Have you looked at the report by Daniel Phillips?
http://marc.theaimsgroup.com/?l=linux-kernel&m=95162877201890&w=2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAI
Recently I muttered a bit about the fact that
with 2.4.0test11 masquerading, the first packet
that was to be forwarded crashes the kernel. Always.
Tonight I wanted to start investigating this more closely,
but to my pleasant surprise 2.4.0test12pre3 does not have
this problem. Progress.
(I am sti
Just noticed a nonsense thread on mount/umount, entirely about
trivialities, but people are studying strace output as if
there is something here that is not well-understood.
I missed the start of this thread but just retrieved it
from a friendly archive.
Randy Dunlap wrote on 29 Nov 2000 16:47
On Mon, Dec 04, 2000 at 09:32:58AM +0530, K Ratheesh wrote:
> I am working on enabling Linux console for Local languages. As the current
> PSF format doesn't support variable width fonts , I have made a patch in
> the console driver so that it will load a user defined multi-glyph mapping
> table
Now that there was some discussion about umount,
I released a version of mount/umount that perhaps
has a slightly better behaviour. Since the change
was largish (and is untested), don't put it blindly
into your distribution.
Another change was one intended to make things behave
a bit better for Ja
On Thu, Dec 07, 2000 at 08:23:59AM -0500, Alexander Viro wrote:
>
> Oh, lovely - where the hell had the following come from?
> % man truncate
> ...
>EINVAL The pathname contains a character with the high-
> order bit set.
> ...
> Andries, would you mind removing that, er
On Thu, Dec 07, 2000 at 10:24:31AM -0500, Alexander Viro wrote:
> Al, currently walking through the /usr/share/man/man2 and swearing silently...
Swearing? At the POSIX decisions or at the man page quality?
In the latter case, additions and corrections are very welcome.
Make sure that you have 1.
On Thu, Dec 07, 2000 at 04:56:59PM +0100, Jan Niehusmann wrote:
> ll_rw_blk.c: generic_make_request() contains the following code:
>
> if (maxsector < count || maxsector - count < sector) {
> bh->b_state &= (1 << BH_Lock) | (1 << BH_Mapped);
> if (blk_size[major][MINOR(bh->b_rdev)]) {
1 - 100 of 393 matches
Mail list logo
