On Mon, 28 Sep 2020 at 09:29, Dmitry Vyukov wrote:
> On Mon, Sep 28, 2020 at 10:23 AM Tigran Aivazian
> > No, this is not an issue. In the latest change to BFS I added the
> > following comment to the header fs/bfs/bfs.h, which explains it:
> >
> > /* In theory BF
Hello Dmitry,
On Mon, 28 Sep 2020 at 08:51, Dmitry Vyukov wrote:
> On Mon, Sep 28, 2020 at 9:48 AM syzbot
> wrote:
> > BFS-fs: bfs_fill_super(): WARNING: filesystem loop0 was created with 512
> > inodes, the real maximum is 511, mounting anyway
>
> This looks like a BFS issue. +BFS maintainers.
I see no problems for BFS.
Acked-By: Tigran Aivazian
Re-sending the patches with the "Cc: sta...@vger.kernel.org" included
in the sign-off area, as per Option 1 of the rules Greg referred me
to. I hope that now I have done everything by the rules.
On Sun, 2 Dec 2018 at 21:42, Tigran Aivazian wrote:
>
> just wanted to add: although
just wanted to add: although the subject says "4.19.6" the patches
apply perfectly to the top of "torvalds/linux" tree from github.
On Sun, 2 Dec 2018 at 21:01, Tigran Aivazian wrote:
>
> Hi Linus,
>
> I attached two incremental patches for BFS:
>
> 1. Make i
Hi Linus,
I attached two incremental patches for BFS:
1. Make inode bitmap allocation static (applies on top of 4.19.6)
2. Strengthen the superblock sanity checking code (applies on top of 1. above)
Kind regards,
Tigran
From: Tigran Aivazian
Subject: [PATCH 4.19.6 1/2] BFS updates
Make in
On Sun, 2 Dec 2018 at 20:13, Greg KH wrote:
> What is the git commit id of this patch in Linus's tree?
In linux-next the commit id is
d2e6681167c634cfc3558991b59a6f614a31d226 , but it is not in Linus'
tree (i.e. at github.com/torvalds/linux) yet. It went into Andrew
Morton's "-mm" tree and then i
tested under 4.19.6 kernel.
Kind regards,
Tigran
From: Tigran Aivazian
Subject: [PATCH 4.19.6] BFS: static inode bitmap and extra sanity checking
Strengthen validation of BFS superblock against corruption.
Make in-core inode bitmap static part of superblock info structure.
Print a warning when
On Thu, 29 Nov 2018 at 17:10, Greg KH wrote:
> Your patch has to apply on top of the existing one, so there's not an
> issue here.
> And might as well fix it now, as I can never count on a "future" patch
> getting merged.
It is already fixed, i.e. it applies cleanly against the existing
(i.e. 4.1
On Thu, 29 Nov 2018 at 16:07, Greg KH wrote:
> On Thu, Nov 29, 2018 at 03:23:00PM +0000, Tigran Aivazian wrote:
> > Yes, of course I object to it.
> I can not apply a patch to the stable trees that are not in Linus's tree
> first. So there's nothing I can do here wi
> printf().
>
> [1]
> https://syzkaller.appspot.com/bug?id=16a87c236b951351374a84c8a32f40edbc034e96
>
> Link:
> http://lkml.kernel.org/r/1525862104-3407-1-git-send-email-penguin-ker...@i-love.sakura.ne.jp
> Signed-off-by: Tetsuo Handa
> Reported-by: syzbot
> Reviewed-by: Andrew Morton
&g
On Thu, 22 Nov 2018 at 19:42, Sasha Levin wrote:
> Hm, but this one is not upstream yet? I'll wait with it until it gets
> some time to soak upstream.
It is in linux-next, so I assume it will propagate to the numbered
releases soon, see here:
https://git.kernel.org/pub/scm/linux/kernel/git/next/l
ot;Signed-off-by:" line and diffstat output. And now I've also cc'd the
linux-kernel mailing list.
Kind regards,
Tigran
From: Tigran Aivazian
Subject: bfs: extra sanity checking and static inode bitmap
Strengthen validation of BFS superblock against corruption.
Make in-core inode b
On Tue, 13 Nov 2018 at 19:40, Tigran Aivazian wrote:
>
> On Tue, 13 Nov 2018 at 08:31, Tigran Aivazian
> wrote:
> > Andrew, if you would like me to make the same patch against 4.19.1 as
> > well, please let me know.
>
> I decided to just go ahead and backport it to 4.
On Tue, 13 Nov 2018 at 08:31, Tigran Aivazian wrote:
> Andrew, if you would like me to make the same patch against 4.19.1 as
> well, please let me know.
I decided to just go ahead and backport it to 4.19.1 anyway (see
attached). Tested thoroughly under 4.19.1.
From: Tigran Aivazian
Subjec
ura.ne.jp
> Signed-off-by: Tetsuo Handa
> Reported-by: syzbot
> Reviewed-by: Andrew Morton
> Cc: Tigran Aivazian
> Cc: Matthew Wilcox
> Signed-off-by: Andrew Morton
> Signed-off-by: Linus Torvalds
> Signed-off-by: Sasha Levin
> ---
> fs/bfs/inode.c | 9 ++---
>
license free text.
>
> Signed-off-by: Borislav Petkov
> Cc: Fenghua Yu
> Cc: "H Peter Anvin"
> Cc: Shaohua Li
> Cc: Tigran Aivazian
> Cc: Tom Lendacky
> ---
> arch/x86/kernel/cpu/microcode/amd.c | 4 +---
> arch/x86/kernel/cpu/microcode/core.c | 6 +-
#syz test: git://repo/address.git branch
>> and provide the patch inline or as an attachment.
>> To mark this as a duplicate of another syzbot report, please reply with:
>> #syz dup: exact-subject-of-another-report
>> If it's a one-off invalid bug report, please reply
Looks good to me, thank you.
On 1 May 2018 at 11:01, Tetsuo Handa wrote:
>
> From 247cae4da0490c2e285e0a99e630ef963fabb6d5 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Tue, 1 May 2018 14:15:19 +0900
> Subject: [PATCH] bfs: add sanity check at bfs_fill_super().
>
> syzbot is reporting to
Hi,
If you had created the filesystem with the proper mkfs under SCO
UnixWare 7 you (probably) wouldn't encounter this issue. But since
commercial Unix-es are now part of history and the only proper way is
the Linux mkfs.bfs utility, your patch is fine.
Kind regards,
Tigran
On 5 May 2017 at 21:1
Hi Joe,
I would suggest that those addresses which bounce should certainly be
removed, but the rest should be left alone.
Kind regards,
Tigran
PS. Joe, sorry if you received this message twice --- my first attempt
to reply failed because gmail used html by default :)
On 25 August 2016 at 00:33,
On Fri, 25 Jan 2008, Dmitri Vorobiev wrote:
Heikki Orsila пишет:
+extern void dump_imap(const char *, struct super_block *);
+
Functions should not be externed, remove extern keyword.
Care to explain why?
because dump_imap() is just a BFS' internal helper (for debugging purposes
only bt
On Fri, 25 Jan 2008, Heikki Orsila wrote:
On Fri, Jan 25, 2008 at 01:32:04AM +0300, Dmitri Vorobiev wrote:
diff --git a/fs/bfs/bfs.h b/fs/bfs/bfs.h
index 090b96e..ecc74bb 100644
--- a/fs/bfs/bfs.h
+++ b/fs/bfs/bfs.h
...
+/* inode.c */
+extern void dump_imap(const char *, struct super_block *);
Ooops, I didn't look at the _name_ of the function, i.e. it being
dump_imap(), an internal helper --- of course it shouldn't be extern'd you
are right :)
On Thu, 24 Jan 2008, Tigran Aivazian wrote:
On Fri, 25 Jan 2008, Heikki Orsila wrote:
On Fri, Jan 25, 2008 at 01:32:04A
/lib/modules).
I cc'd linux-kernel as someone may wish to fix this. (see below for the
actual report).
Kind regards
Tigran
On Sun, 14 Jan 2007, Tigran Aivazian wrote:
I forgot to mention that on another machine running the same kernel version
with the same (as close as a UP machine
Hi Jean,
On Tue, 19 Dec 2006, Jean Delvare wrote:
I don't see anything in arch/i386/kernel/microcode.c depending on
CONFIG_HOTPLUG_CPU (in 2.6.20-rc1), sorry.
I run 2.6.19.1 and there both mc_cpu_notifier (which your patch modified)
and mc_cpu_callback (which uses mc_cpu_notifier) are inside
Hi Jean,
Ok, your patch is correct, although I assume you realize that it does
nothing --- both the function and the data it operates on are inside
CONFIG_HOTPLUG_CPU and checking include/linux/init.h I see that
__cpuinitdata is nothing in this case. E.g. msr_class_cpu_notifier in the
msr dri
-12-12 13:09:56.679782000 +
+++ arch/i386/kernel/microcode.c2006-12-12 13:11:14.259782000 +
@@ -1,7 +1,7 @@
/*
* Intel CPU Microcode Update Driver for Linux
*
- * Copyright (C) 2000-2004 Tigran Aivazian
+ * Copyright (C) 2000-2006 Tigran Aivazian <[EMAIL PROTEC
On Sat, 2 Dec 2006, Adrian Bunk wrote:
The only bits that should be made sure to remain valid are the
MODULE_AUTHOR, as Arjan also mentioned.
Even the "please contact the author" and the printk() should continue to
contain known bouncing addresses?
Ah, I forgot about that one, but I see Alan
On Fri, 1 Dec 2006, Jesper Juhl wrote:
In my opinion the addresses should be working ones or not present at
all (or at the very least there should be a note that the email
address is outdated).
The above argument is not valid for entries in a revision history.
Most likely (though not necessari
Hi Adrian,
I have only now had time to read your patch and reject most of it --- the
email addresses in the revision histories etc are for historical purposes
and as such are very useful. They are NOT meant to be valid except at the
moment of time when they are written. The only purpose of ema
Hi Arjan,
On Fri, 1 Dec 2006, Arjan van de Ven wrote:
On Thu, 2006-11-30 at 22:00 -0800, Hua Zhong wrote:
I am curious, what's the point?
These email addresses serve a "historical" purpose: they tell when the
contribution was made, what the author's email addresses
were at that point.
..
rds
Tigran
On Tue, 18 Jan 2005, Tigran Aivazian wrote:
On Tue, 18 Jan 2005, Tigran Aivazian wrote:
I already solved this paricular problem. And the solution is (but don't
tell me you knew it, for then why didn't you tell anyone) simply ---
compile the kernel with -g and that includes enough
On Tue, 18 Jan 2005, Tigran Aivazian wrote:
I already solved this paricular problem. And the solution is (but don't tell
me you knew it, for then why didn't you tell anyone) simply --- compile the
kernel with -g and that includes enough debug information to be able to
decode the sta
On Mon, 17 Jan 2005, H. Peter Anvin wrote:
Or does kdb not have a client at all? (If so, I have no sympathy for it.)
Peter, it was very easy for you to call my emails "rants" and "not even
funny" but the above statement is displaying complete ignorance of what
kdb actually is :) So, instead of "
Hi Andi,
On Mon, 17 Jan 2005, Andi Kleen wrote:
The ABI supported way is to read the DWARF2 unwind tables. For that
you would a dwarf2 reader. gdb does that in user space, and libgcc2
also does it for exception unwinding. IA64 has an in kernel dwarf2
reader library (and ia64 kdb uses it), although
On Mon, 17 Jan 2005, Arjan van de Ven wrote:
On Mon, 2005-01-17 at 10:26 +0100, Andi Kleen wrote:
On Sun, Jan 16, 2005 at 08:46:49AM +0100, Adrian Bunk wrote:
The only user of register_die_notifier (kernel/kprobes.c) can't be
built modular. Therefore, it's the EXPORT_SYMBOL is superfluous.
Please d
On Mon, 17 Jan 2005, Arjan van de Ven wrote:
Actually, having cc'd Linus made me think very _carefully_ about what I
say and I went and checked how the userspace does it, as I couldn't
believe that such fine piece of software as gdb would be broken as well.
And to my surprize I discovered that gdb
On Sat, 15 Jan 2005, H. Peter Anvin wrote:
It depends on the architecture ABI. This is the case for the i386
ABI, but definitely *NOT* for x86-64.
Yes, precisely. The ABI/x86_64 defines this behaviour explicitly. However,
that would mean the ABI was designed without giving thought to debugging
Hi Sathish,
The function of getname() is to allocate some (kernel-space) memory for
the userspace-passed filename and copy it from user space to kernel space.
Regards,
Tigran
On Mon, 18 Jun 2001, SATHISH.J wrote:
> Hi,
>
> Sorry if this question is too silly.
>
> I could not understand what
On 15 May 2001, Xavier Bestel wrote:
> # cd /usr/src/linux
> # make tags
No, I never use that one because it skips very useful entries like the
ones from EXPORT_SYMBOL etc. Also, it only shows the current architecture.
So, the tags target in the Makefile would only become useful when it is
stripp
On 15 May 2001, Blesson Paul wrote:
> In everyfile system, dget() function is called. But I cannot find
> where is the dget() function is written. Where is it
To find this out, you type:
# vi -t dget
and then look at the bottom line which would show
"./include/linux/dcache.h"
This
Keith,
What would be really great is to add the following item to your wishlist:
* make it possible (it is trivial but a pain to have to do it manually
every time I upgrade to your latest version!) for those extra "modules" to
be statically linked in. So that one doesn't have to keep these lines
http://sourceforge.net/projects/linux-abi/
iBCS has been ported and maintained against most of 2.3.x series for a
long time. And it is still, of course, available under 2.4.x, It is now
called ABI because old name iBCS was a misnomer (iBCS2 is an Intel
standard but the Linux implementation is far
Hi,
On Wed, 7 Mar 2001, Jauder Ho wrote:
> I am not sure what you intend this application for. If it is mission
> critical in any way shape or form, I would still recommend using something
> like Veritas (which unfortunately is not ported to Linux yet).
On Fri, 2 Mar 2001, Alan Cox wrote:
> [24940903.pdf]
> Table 14 in paticular gives the config bits
ok, thank you. Now I understand (maybe) whats' going on. Linux treated
bits 22,23,24,25 but ignored 27 which it shouldn't have. Now, coupled with
the fact that the problematic box I have
Alan,
Those formulae (both 'bus' and 'mul' calculation) are broken, I think.
If I extend 'bus' to be 4 bits instead of 2 then I can make it work on all
of my machines (or all those I tried), of course, extending the buscode[]
table appropriately.
However, the radically broken, imho, thing is th
On Thu, 1 Mar 2001, Alan Cox wrote:
> Please send me the value of your 0x2A MTRR. Because this isnt properly intel
> documented there is a certain amount of research still required.
>
ok, adding this to init_intel():
u32 lo, hi;
rdmsr(0x2A, lo, hi);
printk(KERN_ERR "lo
On Fri, 2 Mar 2001, Ingo Molnar wrote:
> > + if (c == &misc_list) {
> >
> > This should be (c != &misc_list)
>
oops, I didn't notice -- ignore the patch I sent a minute ago :)
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
On Fri, 2 Mar 2001, Tigran Aivazian wrote:
> On Thu, 1 Mar 2001, Alan Cox wrote:
> > 2.4.2-ac8
> > o Stop two people claiming the same misc dev id (Philipp Rumpf)
>
> is this what has broken misc devi registration on my machine? I have two
> misc devices -- microcode
On Thu, 1 Mar 2001, Alan Cox wrote:
> 2.4.2-ac8
> o Stop two people claiming the same misc dev id (Philipp Rumpf)
is this what has broken misc devi registration on my machine? I have two
misc devices -- microcode and psaux -- now (ac8) I get none, /proc/misc is
empty. Also, on boot gpm gene
On Thu, 1 Mar 2001, Mark Hahn wrote:
> > > > > > Well, somethig has broken in ac8, because I lost my PS/2 mouse and
> > > > > me too .
> > No luck.
>
> it seems to be the mdelay(2) added to pc_keyb.c in -ac6.
are you sure? My bet is that it is to do with misc device registration as
I lost not j
On Thu, 1 Mar 2001, José Luis Domingo López wrote:
> Linux 2.4.2-ac7 reports wrong CPU speed and model name for a Pentium III
> correctly detected on, at least, 2.2.18, 2.4.2 and 2.4.2-ac4. The
> processor is a 600 MHz one, with a 133 MHz front bus.
same here with PIII550MHz/100MHz bus. Actually,
On Thu, 1 Mar 2001, Alexander Viro wrote:
> * userland issues (what, you thought that limits on the
> command size will go away?)
the space allowed for arguments is not a userland issue, it is a kernel
limit defined by MAX_ARG_PAGES in binfmts.h, so one could tweak it if one
wanted to witho
On Thu, 1 Mar 2001, Hans Reiser wrote:
>
> This is indeed what we should do if we get no answer from the list by someone
> who has already done such work.
>
Hans,
exactly what you want to measure? I have UP, 2way-SMP and 4way-SMP
machines all of which have at least Linux+FreeBSD installed. All
Hi Linus,
Yes, I know that Stephen had fixed this bug ages ago but, nevertheless, it
is still present in 2.4.2 and I don't know about his plans for resending
the patch -- but it is a part of the set I maintain so I just wanted to
bring it to your attention. Small bug, small obvious fix -- why not
Hi,
Hmm, it's a curious driver... Here is the patch (and the final .c) to get
it to compile under 2.4.2
http://www.moses.uklinux.net/patches/aweram/
but the driver doesn't probe for the (extremely frequent!) case when the
device has been prepared by the ISA-PNP subsystem. Looking at the
infrast
On Wed, 21 Feb 2001, Giuliano Pochini wrote:
>
> Perhaps this is a faq...
> I have a dual-800 (mb asus, no AGP) with 1GB ram,
> but according to /proc/meminfo tells I only have
> 90KB. I tried "mem=1024" boot parameter without
> success. How can I get my 128MB back ?
>
when you compile you
yes, just run the famous mptable program. If the machine is SMP then it
will have a valid Intel MP 1.4 configuration tables so the program will
show meaningful output.
Regards,
Tigran
On Tue, 20 Feb 2001, Burton Windle wrote:
> Hello. Is there a way, when running a non-SMP kernel, to detect or
On Wed, 21 Feb 2001, Jeff Garzik wrote:
> On Wed, 21 Feb 2001, Tigran Aivazian wrote:
> > yes, just run the famous mptable program. If the machine is SMP then it
> > will have a valid Intel MP 1.4 configuration tables so the program will
> > show meaningful output.
>
On Wed, 21 Feb 2001, Tigran Aivazian wrote:
> yes, just run the famous mptable program.
before I am snowed under with questions about where to get this program,
here is the src and binaries that I use -- it is quite possible that there
is a newer version (I suspect Ingo Molnar might know bet
On Wed, 21 Feb 2001, Tigran Aivazian wrote:
> On Wed, 21 Feb 2001, Giuliano Pochini wrote:
>
> >
> > Perhaps this is a faq...
> > I have a dual-800 (mb asus, no AGP) with 1GB ram,
> > but according to /proc/meminfo tells I only have
> > 90KB. I tri
Hi,
free is not an interesting command. Much more interesting is the kernel
messages on boot, e.g. on my laptop it looks like this:
BIOS-provided physical RAM map:
BIOS-e820: 0009fc00 @ (usable)
BIOS-e820: 0400 @ 0009fc00 (reserved)
BIOS-e820:
On Thu, 15 Feb 2001, Samuel Flory wrote:
> What is believed to be the current status of the typical mke2fs
> crashes/hangs due to vm issues? I can reliably reproduce the issue on a
> heavily modifed VA kernel based on 2.2.18. Is there a kernel which is
> believed to be a known good kernel? (
On Tue, 13 Feb 2001, John Levon wrote:
> I had a similar set of patches a while ago. I had several more unnecessary settings.
>
> At least Matthew Dharm as usb-storage maintainer wanted to keep his in. Of more
> concern IMHO were the drivers busy waiting by failing to reset current->state
> on ea
Hi Alan,
The only case in schedule_timeout() which does not call schedule() does
set tsk->state = TASK_RUNNING explicitly before returning. Therefore, any
code which unconditionally calls schedule_timeout() (and, of course
schedule()) does not need to set TASK_RUNNING afterwards.
I have seen som
Alan's patches are installed like this:
# cd /usr/src
# tar xIf linux-2.4.1.tar.bz2
# cd linux
# patch -sp1 < ../patch-2.4.1-ac6
# chown -R root:root .
Note the "-sp1" and that you need to be _inside_ the tree. Also, you don't
need to waste another process ("cat") and create a pipe, just use she
On Tue, 13 Feb 2001, Andrew Morton wrote:
> Well, an external keyboard in a Dell Latitude works just fine here.
> Perhaps you should remove it from the docking station and test
> with an external keyboard?
yes, I can try that. In the meantime you can see for yourself -- just plug
into the docking
Hi Alan,
I am now running 2.2.19-pre9 and it is working fine. Also, just in case, I
retyped this same message in pine in xterm and on the console. No
character loss whatsoever. Also, licq stopped losing characters as well.
I will continue using 2.2.19-pre9 until the evening and report anything
s
s email about was -- I get the same
effect licq (just lost "in" before licq!) so it is not xterm-specific but
probably that is not importt anymore (just lost "an" in
"important").. (lost a . in "..." :)
Tgran (unbelievable -- it doesn't even let me spell
d, nor APM in the kernel.
Regards,
Tigran
On Tue, 13 Feb 2001, Andrew Morton wrote:
> Hi, Tigran.
>
> Internal keyboard, or external?
>
> Does it happen on the console or just in X? (How come you can't
> tell whether it's the k/b driver or the PTY driver?)
>
>
On Tue, 13 Feb 2001, Alan Cox wrote:
> > PS. This only happens on this Dell latitude CPx (notice lost shift in
> > Latitude?) H450GT.
> >
> > PPS. No, my laptop is fine -- rebootingnto 2.2.x makes it type without
> > loosing characters...
>
> 2.2 and 2.4 handle keyboard error cases quite diffe
On Tue, 13 Feb 2001, Tigran Aivazian wrote:
>
> PPS. No, my laptop is fine -- rebootingnto 2.2.x makes it type without
> loosing characters...
>
just to clarify -- it does _not_ add characters -- the "loosing" vs
"losing" thing is my own frequent typo :)
Ti
Hi,
I amtyping this without correcting -- allthe lost characters you see
(including spaces!) are exactly what the pseudo-tty driver does! This is
2.4.1 a it definitely (oh, see "nd" of the ave "and" disappeared? and
"above" turned into "ave"!) did work fine previously -- like in the days
of 2.3.9
On Mon, 12 Feb 2001, Brian Grossman wrote:
> > Yes.
>
> Thanks. Is there a preferred way of getting the equivalent info
> as free(1) did under 2.2?
btw, this is not only x86 behaviour but is also true on all other
architectures. I.e. Linux defines "shared memory" as a "integer constant
with val
Doug,
I confirm that ac7 fixed all the aic7xxx problems on my machine.
Thanks,
Tigran
-
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/
two mistakes:
a) [EMAIL PROTECTED], not veritas.com! (it was pine, not me -- default
domain etc :)
b) it was ac6 which fixed it, not ac7 (but I am running ac7)
On Thu, 8 Feb 2001, Tigran Aivazian wrote:
> Doug,
>
> I confirm that ac7 fixed all the aic7xxx problems on my machine.
&g
Alan, Doug,
If this is a known problem -- ignore. Otherwise, I will gladly assist as
much as you need.
Just tried ac5 kernel and, behold (btw, why does serial console not work
anymore, I had to copy these by hand):
(scsi0) BRKADRINT error(0x44):
Illegal Opcode in sequencer program
PCI Error
Hi,
Under 2.4.1, after a little bit of running SPEC SFS (with NFSv3) I get
these messages on the server:
vs-13042: reiserfs_read_inode2: [0 1 0x0 SD] not found
vs-13048: reiserfs_iget: bad_inode. Stat data of (0 1) not found
vs-13048: reiserfs_iget: bad_inode. Stat data of (0 1) not found
vs-130
and, while you are at it, you should (probably) also mark pin_2_irq() and
IO_APIC_get_PCI_irq_vector() functions as __init as well, for exactly the
same reason as what you noticed.
Regards,
Tigran
On Mon, 5 Feb 2001, Dunlap, Randy wrote:
> Hi,
>
> Just a question (not a patch proposal):
>
>
On Mon, 5 Feb 2001, Tigran Aivazian wrote:
> Basically, I badly needed to be able to build kernels of arbitrary size
not just "to build", but "to boot", of course :)
Also, while we are in a history lesson, I might as well add that this was
precisely the time when h
On Mon, 5 Feb 2001, Mr. James W. Laferriere wrote:
>
> Hello All , I like the warning Ladies & Gents . But when did it
> first appear ? I seem to have missed the announcement in the
> change logs . Tia , JimL
you mean when did Werner Almesberger add the check and a printf
ok, since so many people ask for it to be called "rootfstype=", I will do
so and resend the patch.
Any other comments? I think on the last round I have incorporated all the
comments (except the "rootfs" -> "rootfstype" one)...
Tigran
On Mon, 5 Feb 2001, We
5 13:54:08 2001
@@ -18,6 +18,7 @@
*Torbjörn Lindh ([EMAIL PROTECTED]), April 14, 1996.
* Added devfs support: Richard Gooch <[EMAIL PROTECTED]>, 13-JAN-1998
* Heavily rewritten for 'one fs - one tree' dcache architecture. AV, Mar 2000
+ * Added rootfs boot param. used b
Hi Daniel,
That is very well known (I posted about it many years ago :) but, as Ingo
(or someone else? maybe sct or Alan? actually, I think it was Andrea)
explained it is not a bug -- for that if() is only for purpose of catching
bad callers (which, in perfect world, shouldn't exist). The whole b
On Thu, 25 Jan 2001, David S. Miller wrote:
> 3) NFS client side activity
this bit interesting (to me). Do you mean Linux NFS client as present in
the Linux kernel source (nfs filesystem) or just the type of traffic
generated by arbitrary NFS client (e.g. the builtin one used by SPEC SFS
benchmar
On Wed, 24 Jan 2001, Jo l'Indien wrote:
> With a 2.4.1-pre10 kernel, I noticed that /dev/cpu/microcode
> was created as a file, and note as a node in the devfs.
> So, I made this very little patch to correct this:
>
[bogus patch deleted]
Hi Jocelyn,
No, that file is created as a regular file fo
On Tue, 23 Jan 2001, Tigran Aivazian wrote:
> So, since kdb was unable to tell me what's going on (and truss also can't
> attach to it) one will have to debug it the old-fashioned way -- manually,
> i.e. by trussing klogd from the beginning and reading it's sources...
act
On 23 Jan 2001, Chmouel Boudjnah wrote:
> Andrew Morton <[EMAIL PROTECTED]> writes:
>
> > As far as the klogd problem is concerned, see
> >
> > http://www.uwsg.iu.edu/hypermail/linux/kernel/0101.1/1053.html
> >
> > for a probable solution.
>
> it look like it fixes the problem for me, tha
On 23 Jan 2001, Chmouel Boudjnah wrote:
> Tigran Aivazian <[EMAIL PROTECTED]> writes:
>
> > Btw, this only happens on my laptop and not on the desktop. It only
> > happens _after_ some activity but I have not yet managed to narrow down
> > exactly what activity.
&
Hi,
Has anyone else seen this? The system load is 1.0 and all the cpu time is
taken by klogd but I do not have a stream of messages (or maybe I do but
they all are lost?). Also, kdb refuses to decode klogd's stack saying
"stack is not in task structure". It does show stack trace of other tasks
th
On Tue, 16 Jan 2001, Tigran Aivazian wrote:
> Fixing this requires either a new filesystem type (drifs) or
> (simpler!) redesigning dri to separate common things into a separate
> dri_core thing shared amongst them.
just for completeness -- there is the 3rd option -- one could just fix
Hi Bobo,
To fix this just link in only the support that corresponds to your
hardware. The design of dri is such that (one could paraphrase) each
driver-specific part includes its own copy of what should be
"driver-independent shared dri_core engine" (e.g. proc handling stuff).
Fixing this requir
On Thu, 4 Jan 2001, A.D.F. wrote:
> Max. RAM size:64 GB (any slowness accessing RAM over 4 GB
>with 32 bit machines ?)
realistic benchmarks (unixbench) will show about 3%-6% performance
degradation with use of PAE. Note that this i
Hi Alan,
I sent this one-liner to Linus ages ago but he didn't notice it. The bug
is obvious -- the goal of microcode_init() is to succeed at least in one
of either devfs or misc registration.
Regards,
Tigran
--- linux/arch/i386/kernel/microcode.c Mon Dec 11 21:42:08 2000
+++ work/arch/i386/ke
Dec 27 07:32:10 2000
+++ ucode-2.2/arch/i386/kernel/microcode.c Wed Dec 27 07:52:07 2000
@@ -35,6 +35,8 @@
* Pentium 4 support + backported fixes from 2.4
* 1.07 13 Dec 2000, Tigran Aivazian <[EMAIL PROTECTED]>
* More bugfixes backported from 2.4
+
it is not a problem, it is a feature. (and a useful one!)
On Sat, 23 Dec 2000 [EMAIL PROTECTED] wrote:
>
> 1. multiple mount of devices possible 2.4.0-test1 - 2.4.0-test13-pre4
>
> 2. its still possible to mount devices several times.
>IMHO it shouldnt be possible like 2.2.18
>with umo
On Sat, 23 Dec 2000, Sourav Sen wrote:
>
> In many parts of the kernel, I have seen both semaphore is taken
> (eg. down(¤t->mm->mmap_sem)) as well as kernel lock (lock_kernel())
> is also taken, why both are required? Whats the purpose of each?
>
because the semaphore is really needed (by desi
Hi Aaron,
Although I have not looked at Oops report in detail (Sabbath is now on,
can't do work!) but I am well aware of two (or more) bugs in that area and
one of them may well be the cause of your oops I assumed the
X86_FEATURE flags semantics to be the same on 2.2 as in 2.4 but then
discovered
On Thu, 21 Dec 2000 [EMAIL PROTECTED] wrote:
> Can somebody tell me why mount call just hangs? Is there anyway to take a
> dump when the call is being executed.
You don't need a dump. Just go to the source and start inserting
printk() statements all over the sys_mount/do_mount etc. and sooner or
1 - 100 of 421 matches
Mail list logo
