Re: About Celeron processor memory barrier problem
* Linus Torvalds ([EMAIL PROTECTED]) [001224 16:27]: > One thing we _could_ potentially do is to simplify the CPU selection a > bit, and make it a two-stage process. Basically have a > > bool "Optimize for current CPU" CONFIG_CPU_CURRENT > > which most people who just want to get the best kernel would use. Less > confusion that way. Good Lord, YES! And while we're at it, how about a: "Build into kernel every module for hardware I have..." That'd make a 'make config' one line (I'll go back to dreaming) Ciao! -- Excusing bad programming is a shooting offence, no matter _what_ the circumstances. -- Linus Torvalds (linux-kernel mailing list) The Doctor What: Not that 'who' guy http://docwhat.gerf.org/ [EMAIL PROTECTED] KF6VNC - 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/
sysmips call and glibc atomic set
I'm working with a vr4181 target and started digging into the atomic
test and set stuff in the kernel and glibc. The first problem I had was
that the glibc code assumes that all mips III targets implement the mips
III ISA (funny assumption, no?) but the vr4181 doesn't include the
miltiprocessor oriented LL/SC operations for atomic test and set.
So I started looking at the glibc code (yes, I know this is the kernel
list... I'm getting there I promise) and notice the following operations:
__asm__ __volatile__
(".set mips2\n\t"
"/* Inline spinlock test & set */\n\t"
"1:\n\t"
"ll %0,%3\n\t"
".set push\n\t"
".set noreorder\n\t"
"bnez %0,2f\n\t"
" li %1,1\n\t"
".set pop\n\t"
"sc %1,%2\n\t"
"beqz %1,1b\n"
"2:\n\t"
"/* End spinlock test & set */"
: "=" (ret), "=" (temp), "=m" (*spinlock)
: "m" (*spinlock)
: "memory");
The significant code here being the 'll' and 'sc' operations which are
supposed to ensure that the operation is atomic.
QUESTION 1) Will this _ALWAYS_ work from user land? I realize the
operations are temporally close, but isn't there the possibility that an
interrupt occurs in the meantime?
Of course none of this code applies to my case anyway, since the vr4181
doesn't implement these ops. So once I hack^H^H^H^Hadjust glibc to use
the 'mips1' implementation, it uses the sysmips system call. regard :
_test_and_set (int *p, int v) __THROW
{
return sysmips (MIPS_ATOMIC_SET, (int) p, v, 0);
}
So then I looked at the kernel and find the code below. The system I'm
working with is expressedly uniprocessor and doesn't have any swap, so
it looks like the initial caveats are met, but it looks to me like there
could be some confusion if the value of *arg1 at entry looks like
-ENOSYS or something like that.
QUESTION 2) Wouldn't it be better to pass back the initial value of
*arg1 in *arg3 and return zero or negative error code?
case MIPS_ATOMIC_SET: {
/* This is broken in case of page faults and SMP ...
Risc/OS faults after maximum 20 tries with EAGAIN. */
unsigned int tmp;
p = (int *) arg1;
errno = verify_area(VERIFY_WRITE, p, sizeof(*p));
if (errno)
return errno;
errno = 0;
save_and_cli(flags);
errno |= __get_user(tmp, p);
errno |= __put_user(arg2, p);
restore_flags(flags);
if (errno)
return tmp;
return tmp; /* This is broken ... */
}
QUESTION 3) I notice that the code for this particular case of sysmips
has changed recently. The old code looked more like the 'll/sc' version
of glibc above. I would think that the 'll/sc' code would be better on
SMP systems. Is there a good reason why this reverted?
Sorry For the Long Post (tm)! Thanks In Advance! Merry Xmas!
--
Joe deBlaquiere
Red Hat, Inc.
307 Wynn Drive
Huntsville AL, 35805
-
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/
Re: Proposal: devfs names ending in %d or %u
Eric Shattow wrote: [snip] > when i insert a FAT formatted disc with a PC partition table, the partition > i want to mount is part1. when i insert a HFS formatted disc with a MAC > partition table, the partition i want to mount is part4. this is very ugly, and it has nothing to do with devfs. Those would be /dev/sda1 (adjust device name for IDE instead of SCSI, etc.) and /dev/sda4 without devfs. In this case, the problem is that different Zip disks really do have their data on different partitions. (If you use enough different disks and formatting utilities, it won't even be the same partition for all PC disks or all Mac disks, IIRC.) I don't use Zip disks much anymore, although there's a similar phenomenon with my SCSI MO drive on my desktop Mac (which I recently started using Linux on again). What would be nice is if there were a way of saying, "here's the disk, mount the Right Partition(tm) in /mnt/whatever." For all I know, maybe someone's done that already. If not, it seems to me that a userspace utility (== no extra kernel bloat) could parse the partition table and use some heuristics or something to pick the partition to mount. (I'm probably going to do other stuff instead of implementing this, but I haven't decided for sure yet.) In any case, I think the solution would be completely orthogonal to devfs... -Barry K. Nathan <[EMAIL PROTECTED]> - 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/
Re: Proposal: devfs names ending in %d or %u
On Sun, 24 Dec 2000, Adam J. Richter wrote: > I propose to change the devfs registration functions > to allow registrations of devices ending in %d or %u, in which > case it will use the first value, starting at 0, that generates a > string that already registered. So, if I have disc0, disc1, and disc2, > and I remove the device containing disc1, then disc1 will be next > disc device name to be registered, then disc3, then disc4, etc. i use devfs for my computers and i agree that the quasi-consistancy of device naming is annoying. my example is with my scsi zip ext. drive. when i insert a FAT formatted disc with a PC partition table, the partition i want to mount is part1. when i insert a HFS formatted disc with a MAC partition table, the partition i want to mount is part4. this is very ugly, having to set up two entries in fstab for the same device. instead of messing around with the naming behavior, why not add configuartion options to the devfsd daemon? they could be per-driver/host/device. maybe i just don't see how to do it with the existing system. in the meantime i am just setting up a /dev/mntsym/ directory that has symlinks "zip" "cdrom" "dvd", etc. when the appropriate modules register, as a quick hack until this is resolved. > This will make it a bit simpler to add devfs support to > the remaining drivers that do not have it, and it will make > numbering within devfs much simpler by default. Of course, drivers > that want to do their own thing the current way would not be impeded > from doing so by this change. it is my opinion that drivers should not have to be too specific about where their representitive /dev entries end up. i don't know enough about internals, but there must be a way to unify the registration of device entries. make the drivers register with the devfs system with the default informations and specifications, and let the devfs system make those dumb null entries or what ever else. it would be yet another layer of abstraction, but it might help make the devfs more flexible. sidenote: i got a new laptop with a serial port and lots of unsupported hardware. i went to work hacking away at what i could. i noticed especially with devfs, that debugging serial port like /dev/tts/0 is impossible if the serial.o driver refuses to load due to an IRQ conflict. if the driver never registers/auto_config's, the /dev/tts entries are not there to use. this is of concern, since some device names should be created regardless of whether the device is loaded or not. without the device entries for serial ports i was not able to give 'setserial' or 'stty' a proper device name for the ports. the PCI standards committee slacked off on the PCI serial spec, it is really weak for standards on devices like modems. the serial port is a (Xircom MPCI 56) Toshiba internal PCI modem 56, a real modem like i always thought would be supported by the serial driver, and yet sits unused like the winmodems i was careful to avoid. that's my dime-and-a-quarter. Eric Shattow [EMAIL PROTECTED] - 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/
Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots
On Sun, 24 Dec 2000, Andreas Franck wrote:
> Hello Mike, hello linux-kernel hackers,
>
> Mike Galbraith wrote:
>
> > Yes, hmm indeed. Try these two things.
> >
> > 1. make DECLARE_MUTEX_LOCKED(sem) in bdflush_init() static.
> > 2. compile with frame pointers. (normal case for IKD)
> >
> > My IKD tree works with either option, but not with neither. I haven't
> > figured out why yet.
>
> 1 worked for me, too - with the same effect as compiling buffer.c with
> 2.95.2, thus meaning successful boot and heavy crashing later on.
> I haven't tried to boot 2 yet, but this looks seriously fishy to me. It would
> be nice if we could make a simpler testcase to reproduce it, as it's much
> work to boot the kernel over and over again.
I wouldn't (not going to here;) spend a lot of time on it. The compiler
has problems. It won't build glibc-2.2, and chokes horribly on ipchains.
int ipt_register_table(struct ipt_table *table)
{
int ret;
struct ipt_table_info *newinfo;
static struct ipt_table_info bootstrap
= { 0, 0, { 0 }, { 0 }, { } };
^
ip_tables.c:1361: Internal compiler error in array_size_for_constructor, at
varasm.c:4456
-Mike
-
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/
Re: innd mmap bug in 2.4.0-test12
Marco d'Itri wrote: > And I have another problem: I'm experiencing random hangs using X[1] with > 2.4.0-test12. After a variable amount of time, some of the times I use X > (I mostly use console) it just freezes hard (no caps lock activity). > I'm not sure if this only happens while using X or it's just less > frequent in console. -test9 works fine and I used it since it has been > released with no ill effects. This is probably the run_task_queue bug fixed in test13pre3. Augusto - 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/
Proposal: devfs names ending in %d or %u
It seems that just about everything that uses devfs
contains some logic that attempts to construct an unused
device name with something like:
static devnum = 0;
sprintf (name, "lp%d", devnum++);
devfs_register_device(..., name,...);
Besides duplicating a lot of logic, making devfs support
more of a pain to add and uglier to look at, the numbering behvior
of these drivers can be inconsistent, especially if some devices
are being removed. For example, as I insert and remove my PCMCIA
flash card, it becomes /dev/discs/disc1, /dev/discs/disc2,
/dev/discs/disc3, etc.
I propose to change the devfs registration functions
to allow registrations of devices ending in %d or %u, in which
case it will use the first value, starting at 0, that generates a
string that already registered. So, if I have disc0, disc1, and disc2,
and I remove the device containing disc1, then disc1 will be next
disc device name to be registered, then disc3, then disc4, etc.
Just to illustrate, I have attached a patch that should
do it for device files, but I also want to do this for symlinks and
possibly directories. So, I am not suggesting that anyone should
integrate this patch yet.
This will make it a bit simpler to add devfs support to
the remaining drivers that do not have it, and it will make
numbering within devfs much simpler by default. Of course, drivers
that want to do their own thing the current way would not be impeded
from doing so by this change.
Anyhow, I thought I should post this suggestion to see if
anyone has any objections, better ideas, improvements or comments.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
--- linux-2.4.0-test13-pre4/fs/devfs/base.c Fri Nov 17 11:36:27 2000
+++ linux/fs/devfs/base.c Sun Dec 10 13:50:29 2000
@@ -1238,6 +1253,7 @@
{
int is_new;
struct devfs_entry *de;
+int numeric_suffix;
if (name == NULL)
{
@@ -1292,8 +1308,16 @@
minor = next_devnum_block & 0xff;
++next_devnum_block;
}
-de = search_for_entry (dir, name, strlen (name), TRUE, TRUE, _new,
- FALSE);
+numeric_suffix = 0;
+do {
+ char realname[strlen(name)+11]; /* max 32-bit decimal integer is 10
+ characters, plus one for
+ terminating null. */
+ sprintf(realname, name, numeric_suffix);
+ numeric_suffix++;
+de = search_for_entry (dir, realname, strlen (realname), TRUE, TRUE,
+ _new, FALSE);
+} while (!is_new && de != NULL && strcmp(name+strlen(name)-2, "%d") == 0);
if (de == NULL)
{
printk ("%s: devfs_register(): could not create entry: \"%s\"\n",
Re: About Celeron processor memory barrier problem
On Sun, Dec 24, 2000 at 02:25:54PM -0800, Linus Torvalds wrote: > > Indeed. Some of the issues end up just becoming compiler flags, which > means that anything that uses C is "tainted" by the processor choice. And > happily there isn't all that much non-C in the kernel any more. > > One thing we _could_ potentially do is to simplify the CPU selection a > bit, and make it a two-stage process. Basically have a > > bool "Optimize for current CPU" CONFIG_CPU_CURRENT > > which most people who just want to get the best kernel would use. Less > confusion that way. > > Linus Makes sense. Are you thinking along the lines of parsing /proc/cpuinfo to work out what is there, or did you have something else in mind ? Regards, Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - 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/
Re: innd mmap bug in 2.4.0-test12
On 25 Dec 2000, Zlatko Calusic wrote: > Linus Torvalds <[EMAIL PROTECTED]> writes: > > > On Sun, 24 Dec 2000, Linus Torvalds wrote: > > > > > > Marco, would you mind changing the test in reclaim_page(), somewheer > > > around line mm/vmscan.c:487 that says: > > > > Speaking of page_launder() I just stumbled upon two oopsen today on > the UP build. Maybe it could give a hint to someone, I'm not that good > at Oops decoding. > > Unable to handle kernel NULL pointer dereference at virtual address 000c > printing eip: > c012872e > *pde = > Oops: > CPU:0 > EIP:0010:[page_launder+510/2156] I suspected I'm not the only one who is getting these exact same Oopses (and the lockups that follow them) so earlier today, I've decoded the Oops I got, and found that the problem is in vmscan.c:line-605, where page->mapping is NULL and a_ops gets resolved and dereferenced at 0x000c. I leave the fix for the mm experts, I've notified Linus, I guess he's looking into it. -- Dan Aloni [EMAIL PROTECTED] - 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/
Re: innd mmap bug in 2.4.0-test12
On Dec 24, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> /* The page is dirty, or locked, move to inactive_dirty list. */
> if (page->buffers || TryLockPage(page)) {
> ...
>
>and change the test to
>
> if (page->buffers || PageDirty(page) || TryLockPage(page)) {
Done, no change.
Got some articles, restarted the server, all is good.
Got other articles, rebooted and the files now differ.
And I have another problem: I'm experiencing random hangs using X[1] with
2.4.0-test12. After a variable amount of time, some of the times I use X
(I mostly use console) it just freezes hard (no caps lock activity).
I'm not sure if this only happens while using X or it's just less
frequent in console. -test9 works fine and I used it since it has been
released with no ill effects.
My hardware:
00:00.0 Host bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3] (rev 04)
00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA [Apollo VP] (rev 41)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06)
00:07.3 Bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 10)
00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS)
01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G100 [Productiva] AGP
(rev 02)
vendor_id : AuthenticAMD
cpu family : 5
model : 8
model name : AMD-K6(tm) 3D processor
stepping: 12
cpu MHz : 267.282
cache size : 64 KB
gcc version 2.95.2 2220 (Debian GNU/Linux)
[1] Good old stable XF86_SVGA 3.x from debian potato.
--
ciao,
Marco
-
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/
Re: sparc 10 w/512 megs hangs during boot
test8 is borked too. I'll try test7 next ron --- Jan-Benedict Glaw <[EMAIL PROTECTED]> wrote: > On Sun, Dec 24, 2000 at 12:48:44PM -0800, Ron > Calderon wrote: > > I just finished compiling 2.4.0-test5 and that > worked > > fine with 512M ram. I'll start going thru the > other > > kernels. It'll take me sometime since compileing > takes > > a long time. > > I've not yet started active searching. However: > - test5 is fine > - test13-pre3 is not > > I don't know how fast your machine is, but we should > coordinate out > search... I'll try to build -test10final (with > minimal config to > only test boot) so that shouldn't take so very > long... You should > test sth around -test8... > > MfG, JBG > > -- > Fehler eingestehen, Größe zeigen: Nehmt die > Rechtschreibreform zurück!!! > /* Jan-Benedict Glaw <[EMAIL PROTECTED]> -- > +49-177-5601720 */ > keyID=0x8399E1BB fingerprint=250D 3BCF 7127 0D8C > A444 A961 1DBD 5E75 8399 E1BB > "insmod vi.o and there we go..." (Alexander > Viro on linux-kernel) > > ATTACHMENT part 2 application/pgp-signature __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ - 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/
shmat returning NULL with 0 sized segment
Hi, I'm trying to debug a weird problem with Xine - its screwing up its use of shared memory for regions I haven't sussed yet. One odd consequence is that it has apparently successfully managed to allocate a 0 byte chunk of shared memory; shmat is then called with shmaddr=0 and shmflg=0; the result of shmat is 0 Is this what shmat is supposed to do in this (admittedly odd) circumstance? The error behaviour is defined in the man page as returning -1 on error. (Linux/Alpha 2.4.0-test8) Back to trying to find out why it decided to allocate a 0 byte chunk Dave -- Have a happy GNU millennium! -- / Dr. David Alan Gilbert | Running GNU/Linux on | Happy \ \ gro.gilbert @ treblig.org | Alpha, x86, ARM and SPARC | In Hex / \ ___|___ http://www.treblig.org |/ - 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/
Re: css hang; somewhere between test12 and test13pre4ac2
Actually... I just remembered that I have my kernel patched to bring it up-to-date with udf cvs. Dave Gilbert wrote: > > Hi, > Somewhere between test12 and test13pre4ac2 (sheesh the version > numbers.) CSS on ATAPI DVD ROM drives has stopped working. > > Playing a CSS disc (using xine) causes a complete system hang (machine > doesn't ping - sysrq-b still works) on test13pre4ac2. On test12 it is > still OK. > > This is on an Alpha LX164. -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - 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/
Re: css hang; somewhere between test12 and test13pre4ac2
Works fine under test13-pre4 here on a x86 and an ATAPI Creative 2x dvd drive using xine or dxr2 player. Dave Gilbert wrote: > > Hi, > Somewhere between test12 and test13pre4ac2 (sheesh the version > numbers.) CSS on ATAPI DVD ROM drives has stopped working. > > Playing a CSS disc (using xine) causes a complete system hang (machine > doesn't ping - sysrq-b still works) on test13pre4ac2. On test12 it is > still OK. > > This is on an Alpha LX164. -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - 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/
css hang; somewhere between test12 and test13pre4ac2
Hi, Somewhere between test12 and test13pre4ac2 (sheesh the version numbers.) CSS on ATAPI DVD ROM drives has stopped working. Playing a CSS disc (using xine) causes a complete system hang (machine doesn't ping - sysrq-b still works) on test13pre4ac2. On test12 it is still OK. This is on an Alpha LX164. Dave -- Have a happy GNU millennium! -- / Dr. David Alan Gilbert | Running GNU/Linux on | Happy \ \ gro.gilbert @ treblig.org | Alpha, x86, ARM and SPARC | In Hex / \ ___|___ http://www.treblig.org |/ - 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/
Re: innd mmap bug in 2.4.0-test12
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Sun, 24 Dec 2000, Linus Torvalds wrote:
> >
> > Marco, would you mind changing the test in reclaim_page(), somewheer
> > around line mm/vmscan.c:487 that says:
>
Speaking of page_launder() I just stumbled upon two oopsen today on
the UP build. Maybe it could give a hint to someone, I'm not that good
at Oops decoding.
Merry Christmas!
Unable to handle kernel NULL pointer dereference at virtual address 000c
printing eip:
c012872e
*pde =
Oops:
CPU:0
EIP:0010:[page_launder+510/2156]
EFLAGS: 00010202
eax: ebx: c12e2ce8 ecx: c1244474 edx:
esi: c12e2d04 edi: ebp: esp: c15d1fb4
ds: 0018 es: 0018 ss: 0018
Process bdflush (pid: 6, stackpage=c15d1000)
Stack: c15d c15d023a 0008e000 0001 2933
c0131e5d 0003 00010f00 c146ff88 c146ffc4 c01073fc
c146ffc4 0078 c146ffc4
Call Trace: [bdflush+141/236] [kernel_thread+40/56]
Code: 8b 40 0c 8b 00 85 c0 0f 84 ba 04 00 00 83 7c 24 10 00 75 73
Unable to handle kernel NULL pointer dereference at virtual address 000c
printing eip:
c012872e
*pde =
Oops:
CPU:0
EIP:0010:[page_launder+510/2156]
EFLAGS: 00010202
eax: ebx: c1260eec ecx: c15d5fe0 edx: c02917f0
esi: c1260f08 edi: ebp: esp: c15d5f9c
ds: 0018 es: 0018 ss: 0018
Process kswapd (pid: 4, stackpage=c15d5000)
Stack: 00010f00 0004 0004 2938
c01290fc 0004 00010f00 c01f77f7 c15d4239 0008e000
c01291c6 0004 c146ffb8 c01073fc 0078
Call Trace: [do_try_to_free_pages+52/128] [tvecs+8683/64084] [kswapd+126/288]
[kernel_thread+40/56]
Code: 8b 40 0c 8b 00 85 c0 0f 84 ba 04 00 00 83 7c 24 10 00 75 73
--
Zlatko
-
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/
Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots
Hello Mike, hello linux-kernel hackers, Mike Galbraith wrote: > Yes, hmm indeed. Try these two things. > > 1. make DECLARE_MUTEX_LOCKED(sem) in bdflush_init() static. > 2. compile with frame pointers. (normal case for IKD) > > My IKD tree works with either option, but not with neither. I haven't > figured out why yet. 1 worked for me, too - with the same effect as compiling buffer.c with 2.95.2, thus meaning successful boot and heavy crashing later on. I haven't tried to boot 2 yet, but this looks seriously fishy to me. It would be nice if we could make a simpler testcase to reproduce it, as it's much work to boot the kernel over and over again. I have now printed out the buffer.c:bdflush_init assembly for all four cases, 2.95.2, 2.97 without patch, 2.97 with static DECLARE... and 2.97 with frame pointer, and will try to figure out what's going wrong - it would still be nice to know if its a gcc problem or if some kernel assumption about GCC behaviour triggered this bug, which seems equally likely, as kernel_thread and the mutex/semaphore stuff involve some nontrivial (at least for beginners like me...) hand-made assembly code. A nice evening and still merry christmas to the people westward of Europe :-) Andreas -- ->>>--- Andreas Franck <<<- ---<<< [EMAIL PROTECTED] --->>>--- ->>> Keep smiling! <<<- - 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/
Re: About Celeron processor memory barrier problem
On Sun, 24 Dec 2000, Tim Wright wrote: > > > > Which is all fine, but maybe the kernel really ought to detect that > > problem and complain at boot time? > > > > Or does that happen already? > > There was a similar thread to this recently. The issue is that if you > choose the wrong processor type, you may not even be able to complain. Indeed. Some of the issues end up just becoming compiler flags, which means that anything that uses C is "tainted" by the processor choice. And happily there isn't all that much non-C in the kernel any more. One thing we _could_ potentially do is to simplify the CPU selection a bit, and make it a two-stage process. Basically have a bool "Optimize for current CPU" CONFIG_CPU_CURRENT which most people who just want to get the best kernel would use. Less confusion that way. Linus - 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/
Re: innd mmap bug in 2.4.0-test12
On Sun, 24 Dec 2000, Daniel Phillips wrote: > > It looks like PG_dirty is now being used only for swap_cache pages, and > not for buffer cache and page cache pages, is that correct? No. PG_dirty is used for all memory mapped pages - be they anonymous or not. These days the buffer dirty bits are only used by "write()", because write() can obviously dirty smaller areas than one page. Linus - 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/
Re: [patch] support for FDC37N769 IRDA chip
G !
For Christmas, I'd like to get a new mailer which doesn't eat my patches :-)
here it is again, after cut'n'paste. Please apply by hand or "patch -l".
Cheers,
Willy
--- linux-2.2.18/drivers/net/irda/smc-ircc.cSat Jun 24 14:57:49 2000
+++ linux/drivers/net/irda/smc-ircc.c Sun Dec 24 21:30:17 2000
@@ -98,6 +98,7 @@
static smc_chip_t chips[] =
{
{ "FDC37C669", 0x55, 0x55, 0x0d, 0x04, ircc_probe_69 },
+ { "FDC37N769", 0x55, 0x55, 0x0d, 0x28, ircc_probe_69 },
{ "FDC37N869", 0x55, 0x00, 0x0d, 0x29, ircc_probe_69 },
{ "FDC37N958", 0x55, 0x55, 0x20, 0x09, ircc_probe_58 },
{ NULL }
-
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/
[patch] support for FDC37N769 IRDA chip
Hello Dag, I discovered that my notebook supported FIR, but I didn't know the chip (and it was not documented). So I disassembled it completely and found an SMC FDC37N769 inside. It's now correctly detected with the following trivial patch against kernel 2.2.18 (the same entry should be added to findchip). Merry Christmas to you and all the folks on LKML, Willy irda-fdc37n769-2.2.18.diff
Re: sparc 10 w/512 megs hangs during boot
On Sun, Dec 24, 2000 at 12:48:44PM -0800, Ron Calderon wrote: > I just finished compiling 2.4.0-test5 and that worked > fine with 512M ram. I'll start going thru the other > kernels. It'll take me sometime since compileing takes > a long time. I've not yet started active searching. However: - test5 is fine - test13-pre3 is not I don't know how fast your machine is, but we should coordinate out search... I'll try to build -test10final (with minimal config to only test boot) so that shouldn't take so very long... You should test sth around -test8... MfG, JBG -- Fehler eingestehen, Größe zeigen: Nehmt die Rechtschreibreform zurück!!! /* Jan-Benedict Glaw <[EMAIL PROTECTED]> -- +49-177-5601720 */ keyID=0x8399E1BB fingerprint=250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB "insmod vi.o and there we go..." (Alexander Viro on linux-kernel) PGP signature
Re: About Celeron processor memory barrier problem
On Sun, Dec 24, 2000 at 11:36:00AM +0200, Kai Henningsen wrote: > [EMAIL PROTECTED] (Linus Torvalds) wrote on 23.12.00 in ><[EMAIL PROTECTED]>: > > > On Thu, 23 Dec 1999, michael chen wrote: > > > I found that when I compiled the 2.4 kernel with the option > > > of Pentium III or Pentium 4 on a Celeron's PC, it could cause the > > > system hang at very beginning boot stage, and I found the problem > > > is cause by the fact that Intel Celeron doesn't have a real memory > > > barrier,but when you choose the Pentium III option, the kernel > > > assume the processor has a real memory barrier. > > > Here is a patch to fix it: > > > > No. > > > > The fix is to not lie to the configurator. > > > > A Celeron isn't a PIII, and you shouldn't tell the configure that it is. > > > > The whole point of being able to choose the CPU to optimize for is that we > > can optimize things at compile-time. > > Which is all fine, but maybe the kernel really ought to detect that > problem and complain at boot time? > > Or does that happen already? > There was a similar thread to this recently. The issue is that if you choose the wrong processor type, you may not even be able to complain. This is a user issue. All the distributions of which I am aware boot happily on any x86 machine, because they build the kernel for the lowest common denominator. Some detect the CPU type and install an appropriate kernel subsequently. So... the only way you can get into this mess is if you build a kernel yourself and choose the wrong options. There are many ways of producing a non-bootable kernel. The expectation is that if you want to go off and build your own kernel, you need to know what you're doing :-) Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - 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/
Re: sparc 10 w/512 megs hangs during boot
I just finished compiling 2.4.0-test5 and that worked fine with 512M ram. I'll start going thru the other kernels. It'll take me sometime since compileing takes a long time. ron --- Jan-Benedict Glaw <[EMAIL PROTECTED]> wrote: > On Sat, Dec 23, 2000 at 11:57:21PM -0800, Ron > Calderon wrote: > > My sparc 10 seems to hang with any 2.4.0-test12+ > > kernel > > ...but 2.4.0-test11-X kernels are fine? Well, good > info;) > > > if I add mem=128M it boots fine, but anything > above > > 128M wont boot it just hangs. Is there something > I've > > missed? here is screen output. > > I see this as well (SS10 dual with 128MB RAM). > However, if > slightly older kernel are okay, then it's quite easy > to look > through the patches. Which is your > last-known-to-be-good kernel? > > > Uncompressing image... > > PROMLIB: obio_ranges 5 > > bootmem_init: Scan sp_banks, > > init_bootmem(spfn[1c9],bpfn[1c9],mlpfn[c000]) > > free_bootmem: base[0] size[c00] > > reserve_bootmem: base[0] size[1c9000] > > reserve_bootmem: base[1c9000] size[1800] > > > > then it just hangs here > > I additionally get "Unexpected Level 15 Interrupt" > und "Program > terminated" ;-) > > MfG, JBG > > -- > Fehler eingestehen, Größe zeigen: Nehmt die > Rechtschreibreform zurück!!! > /* Jan-Benedict Glaw <[EMAIL PROTECTED]> -- > +49-177-5601720 */ > keyID=0x8399E1BB fingerprint=250D 3BCF 7127 0D8C > A444 A961 1DBD 5E75 8399 E1BB > "insmod vi.o and there we go..." (Alexander > Viro on linux-kernel) > > ATTACHMENT part 2 application/pgp-signature __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ - 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/
[mwelmor@kre8tive.org: Masquerade hangups]
OK. I went back to 2.2.18 (released) and things work better. Since it appears the debug flags don't work in the 8139too module, how can I turn on some debug flags in the 2.4.0-test13-pre4 driver so I can see where this thing is hanging? -mwe - Forwarded message from Mike Elmore <[EMAIL PROTECTED]> - Date: Sun, 24 Dec 2000 09:02:12 -0600 From: Mike Elmore <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Masquerade hangups User-Agent: Mutt/1.2.5i Precedence: bulk X-Mailing-List: [EMAIL PROTECTED] Hello, I have a Tyan S1854 Trinity 400 mb machine with a PCI rtl8139 card connected to my local net and a ISA 3c509 card connected to my dsl link. Masquerade is set up. I seem to get pretty good performance from internet->masq box and from masq box->internal lan, but when a internal box tries to get to the net through the masquerade, connection seem to time out. I'll get a pretty good initial burst, then connections stall. I'm using test13-pre4. I saw some iptables stuff on the list a week or so ago, was this fixed in pre4 or is this my problem? I can provide any information needed. -mwe [EMAIL PROTECTED] - 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/ - End forwarded message - -- Mike Elmore [EMAIL PROTECTED] "Never confuse activity with accomplishment." -unknown - 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/
Re: innd mmap bug in 2.4.0-test12
Linus Torvalds wrote:
> Hmm.. I wonder if such a dirty page might have been moved to the
> "inactive_clean" list some way? It shouldn't really be there, as the page
> had users, but if it gets on that list we'd not have tested the dirty bit.
>
> Marco, would you mind changing the test in reclaim_page(), somewheer
> around line mm/vmscan.c:487 that says:
>
> /* The page is dirty, or locked, move to inactive_dirty list. */
> if (page->buffers || TryLockPage(page)) {
> ...
>
> and change the test to
>
> if (page->buffers || PageDirty(page) || TryLockPage(page)) {
>
> instead? Ie ad the test for "PageDirty(page)"
Good point. Up until recently the page dirty bit wasn't actually being
set anywhere and page->buffers was acting as kind of a surrogate dirty
bit - page_launder would call try_to_free_buffers which would find the
dirty buffers and fail out, but start io first
It looks like PG_dirty is now being used only for swap_cache pages, and
not for buffer cache and page cache pages, is that correct?
--
Daniel
-
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/
Re: innd mmap bug in 2.4.0-test12
> > Get back there in front of the computer NOW. Christmas can wait. > > Linus "the Grinch" Torvalds Hoo - Hoo - Hoo, you've been very naughty Linus. Asking people to work on Christmas evening. My god Linus, that's so naughty that I add it to my list... As soon as I'm finished with Futurama, ... I'll get you! Merry X-Mas Santa Claus :)) - 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/
Re: FEATURE (was Re: PROBLEM: multiple mount of devices possible2.4.0-test1 - 2.4.0-test13-pre4
Tigran Aivazian wrote: > > it is not a problem, it is a feature. (and a useful one!) > yes, mount devices several times it would be a nice feature, but do something like: /etc/fstab: /dev/hdd1 /mydrive ext2 ro,noauto,user 1 1 as user: mount /mydrive as root: mount /dev/hda2 /mydrive as user: mount /mydrive as root: mount /dev/hda2 /mydrive as user: mount /mydrive result /proc/mounts: /dev/hdd1 /mydrive ext2 ro,noexec,nosuid,nodev 0 0 /dev/hda2 /mydrive vfat rw 0 0 /dev/hdd1 /mydrive ext2 ro,noexec,nosuid,nodev 0 0 /dev/hda2 /mydrive vfat rw 0 0 /dev/hdd1 /mydrive ext2 ro,noexec,nosuid,nodev 0 0 u dont have control about the mountpoints Here a BIG PROBLEM: as user: mount /mydrive as root: mount /dev/hdd1 /test as root: mount /dev/hdd1 /mnt result /proc/mounts: /dev/hdd1 /mydrive ext2 ro,noexec,nosuid,nodev 0 0 /dev/hdd1 /test ext2 ro,noexec,nosuid,nodev 0 0 /dev/hdd1 /mnt ext2 ro,noexec,nosuid,nodev 0 0 but do like mount -o remount /mnt -w result /proc/mounts: /dev/hdd1 /mydrive ext2 rw 0 0 /dev/hdd1 /test ext2 rw 0 0 /dev/hdd1 /mnt ext2 rw 0 0 ALL mountpoints now READ-WRITE-able! u lost noexec... and dont have more "security" for users... same as sym-links ... no new feature... Reinhard. > 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 umount in /proc/mounts is still the real information, > >in /etc/mtab all corresponding mountpoints are deleted. - 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/
Re: innd mmap bug in 2.4.0-test12
On Sun, 24 Dec 2000, Linus Torvalds wrote: > > Marco, would you mind changing the test in reclaim_page(), somewheer > around line mm/vmscan.c:487 that says: Yeah, yeah, it's 7PM Christmas Eve over there, and you're in the middle of your Christmas dinner. You might feel that it's unreasonable of me to ask you to test out my latest crazy idea. How selfish of you. Get back there in front of the computer NOW. Christmas can wait. Linus "the Grinch" Torvalds - 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/
Re: innd mmap bug in 2.4.0-test12
On Sun, 24 Dec 2000, Marco d'Itri wrote:
> On Dec 24, Alexander Viro <[EMAIL PROTECTED]> wrote:
>
> >> I put "cp active active.ok" in the rc file before shutting down the
> >> daemon and at the next boot the files are different, every time.
> >
> >Could you send me both files? BTW, which filesystem it is?
> I use ext2. The files are not corrupted, they just are not updated.
> Another data point: at least in some cases, if I stop and start inn
> without rebooting the files are the same.
Ok, looks like we just drop the page cache page without writing it out in
some cases. Possibly/probably because we have dropped the dirty bit on the
floor.
Look slike this is a completely different case from the previous
corruptions, it looks more like a VM issue than a FS thing..
Hmm.. munmap() (and exit()) go through "zap_page_range()", which go
through "free_pte()", which definitely copies the dirty bit to the page
structure.
Hmm.. I wonder if such a dirty page might have been moved to the
"inactive_clean" list some way? It shouldn't really be there, as the page
had users, but if it gets on that list we'd not have tested the dirty bit.
Marco, would you mind changing the test in reclaim_page(), somewheer
around line mm/vmscan.c:487 that says:
/* The page is dirty, or locked, move to inactive_dirty list. */
if (page->buffers || TryLockPage(page)) {
...
and change the test to
if (page->buffers || PageDirty(page) || TryLockPage(page)) {
instead? Ie ad the test for "PageDirty(page)" (and order _is_ important:
the TryLockPage() thing must come last, because it has side effects).
(You might add a "printk()" too that triggers when the new condition
happens, just to see if it does indeed happen).
If the page is on the inactive_clean() list, we'll have to find where it
is put there, because it really shouldn't have been there.
Uhhuh. Actually, reading "page_launder()", the buffer clearign case looks
suspiciously like i doesn't check for page accessed or dirty bits. That's
probably it. Maybe there are other cases. Anyway, I'd love to hear if the
above one-liner fixes the corruption for you..
Thanks,
Linus
-
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/
Re: test13-pre4 ip defrag oops
Hello!
> eax: 20202037 ebx: d3a406c0 ecx: cf683024 edx: c734a2a0
Ough... found eventually. skb->dev turns out to be not initialized. 8)8)
This patchlet surely fixes the bug. (plus writes are ordered)
Alexey
--- ../vger3-001222/linux/net/core/skbuff.c Fri Dec 22 19:37:54 2000
+++ linux/net/core/skbuff.c Sun Dec 24 20:24:20 2000
@@ -227,15 +227,20 @@
{
struct sk_buff *skb = p;
- skb->destructor = NULL;
- skb->pkt_type = PACKET_HOST;/* Default type */
- skb->prev = skb->next = NULL;
+ skb->next = NULL;
+ skb->prev = NULL;
skb->list = NULL;
skb->sk = NULL;
skb->stamp.tv_sec=0;/* No idea about time */
+ skb->dev = NULL;
+ skb->dst = NULL;
+ memset(skb->cb, 0, sizeof(skb->cb));
+ skb->pkt_type = PACKET_HOST;/* Default type */
skb->ip_summed = 0;
+ skb->priority = 0;
skb->security = 0; /* By default packets are insecure */
- skb->dst = NULL;
+ skb->destructor = NULL;
+
#ifdef CONFIG_NETFILTER
skb->nfmark = skb->nfcache = 0;
skb->nfct = NULL;
@@ -246,8 +251,6 @@
#ifdef CONFIG_NET_SCHED
skb->tc_index = 0;
#endif
- memset(skb->cb, 0, sizeof(skb->cb));
- skb->priority = 0;
}
-
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/
Re: About Celeron processor memory barrier problem
Hi!
> diff -Nur linux/include/asm-i386/system.h linux.new/include/asm-i386/system.h
> --- linux/include/asm-i386/system.h Mon Dec 11 19:26:39 2000
> +++ linux.new/include/asm-i386/system.h Sat Dec 23 16:06:01 2000
> @@ -274,7 +274,14 @@
> #ifndef CONFIG_X86_XMM
> #define mb() __asm__ __volatile__ ("lock; addl $0,0(%%esp)": : :"memory")
> #else
> -#define mb() __asm__ __volatile__ ("sfence": : :"memory")
> +#define mb() do { \
> + if ( cpu_has_xmm ) { \
~~
Cost of test may well be bigger than gain by using sfence...
Pavel
--
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED]
-
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/
Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots
On Sat, 23 Dec 2000, Andreas Franck wrote: > Hi Mike, hello linux-kernel audience, > > > I had the same, with the last few snapshots I tried, but 20001218 seems > > to work ok. > > dmesg|head -1 > > Linux version 2.4.0-test13ikd (root@el-kaboom) (gcc version gcc-2.97 > > 20001218 (experimental)) #18 Sat Dec 23 17:43:29 CET 2000 > > Hmm, would have been nice, but it crashes here with 20001222, nevertheless. > For which CPU do you have your kernel configured? It might be a CPU specific > issue, I'll try to compile for Pentium I and 486, now, and report my results. Yes, hmm indeed. Try these two things. 1. make DECLARE_MUTEX_LOCKED(sem) in bdflush_init() static. 2. compile with frame pointers. (normal case for IKD) My IKD tree works with either option, but not with neither. I haven't figured out why yet. -Mike - 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/
Re: innd mmap bug in 2.4.0-test12
On Dec 24, Alexander Viro <[EMAIL PROTECTED]> wrote: >> I put "cp active active.ok" in the rc file before shutting down the >> daemon and at the next boot the files are different, every time. > >Could you send me both files? BTW, which filesystem it is? I use ext2. The files are not corrupted, they just are not updated. Another data point: at least in some cases, if I stop and start inn without rebooting the files are the same. --- active.ok Sun Dec 24 09:58:00 2000 +++ active Sun Dec 24 08:33:34 2000 @@ -1,5 +1,5 @@ control 004793 004794 y -control.cancel 022865 021934 n +control.cancel 022864 021934 n junk 001806 001807 y fido.ita.ridere 014779 014777 y fido.ita.dewdney 004073 004074 y @@ -10,19 +10,19 @@ fido.ita.sf 004777 004778 y comp.os.linux.announce 010782 010779 m fido.ita.tex 000248 000249 y -it.news.annunci 004909 004787 m +it.news.annunci 004905 004787 m it.news.gestione 007878 007399 y fido.ita.tv 011944 011944 y it.test 000796 000797 y -it.news.gruppi 048004 047898 y +it.news.gruppi 047994 047898 y it.comp.sicurezza.varie 030696 030353 y it.comp.sicurezza.unix 002721 002722 y -it.faq 001154 001091 m +it.faq 001150 001091 m [...] -- ciao, Marco - 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/
Masquerade hangups
Hello, I have a Tyan S1854 Trinity 400 mb machine with a PCI rtl8139 card connected to my local net and a ISA 3c509 card connected to my dsl link. Masquerade is set up. I seem to get pretty good performance from internet->masq box and from masq box->internal lan, but when a internal box tries to get to the net through the masquerade, connection seem to time out. I'll get a pretty good initial burst, then connections stall. I'm using test13-pre4. I saw some iptables stuff on the list a week or so ago, was this fixed in pre4 or is this my problem? I can provide any information needed. -mwe [EMAIL PROTECTED] - 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/
Re: Linux 2.2.19pre2
On Sun, Dec 24, 2000 at 11:23:33AM +1100, Andrew Morton wrote: > ack. This patch against 2.2.19pre3 should fix all races. (note that wait->flags doesn't need to be initialized in the critical section in test1X too) ftp://ftp.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.19pre3/wake-one-3 Comments? Andrea - 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/
Re: IDE woes:linux and BIOS won't agree on C/H/S detection
I sent out a longish response a few minutes ago which explained the my problem was solved somehow! One thing I missed explaining in my original post is the AMI BIOS on the GA-7IXE4 motherboard has a very spartan set of options. For the geometry translation of ATA disk, only On/Off choice was available and according to help message On means LBA and Off is non-LBA (normail?). I let LBA on during my trials and errors. AWARD BIOS would have shown none/auto/large/lba, etc. for the same choice. Well, AMI BIOS seems to be pretty minor these days. I have seen it lately on my current motherboard as well as onthe low-price end machines from small vendors, inside VMware's virtual PC environment(!), but nowhere else. There could be some rough edges still around due to smaller user base. I am glad I have been using SCSI disk. If it had not been for my 2.4.0-test12 on a scsi disk I moved from my old PC, I would not have been able to use linux successfully with Win98 partition on this motherboard for a couple of weeks. I guess my motherboard is somewhat exceptional case where BIOSreports a geometry that didn't match the geometry used by popular OSes. Again thank you everybody for helpful tips. - 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/
Re: IDE woes:linux and BIOS won't agree on C/H/S detection
Guest section DW wrote: > On Sat, Dec 23, 2000 at 12:11:41AM +0900, Ishikawa wrote: > > > I have to think more deeply then what the best measure would be. > > I suppose you can get all systems involved to agree on 255 heads > if you select LBA in the BIOS. > > Andries Hi, I think I misunderstood one thing before all the tips came in. I somehow assumed that the Win98 would use the disk geometry that AMI BIOS reported during boot for the hard disk. I was wrong. Win98 seems to have its own idea of picking up convenient CHS just as linux might do. (And incidentally, this CHS seems to agree between w98 and linux!) Or AMI BIOS is lying to me during the boot and pass a different info to the OS when inquired afterward as suggested by someone. Anyway, when the geometry mismatch was reported in linux fdisk after trying to install win98 and found that linux picked up CHS geometry different from that of BIOS's, I thought this was the problem. But as Andries pointed out Win98 seemed to use the same geometry information as linux used before I made it to use the BIOS geometry by means of boot command line parameter. This means two to one favor against BIOS's idea of CHS! The two OSs used 255 heads geometry. So what I did was this. (In the end, I didn't have to remove SCSI disk to check if the linux or BIOS gets confused with the SCSI disk geometry info.) Firstly, from linux, I did the following in order to try my another attempt to wipe out the partition information for sure. dd if=/dev/zero of=/dev/hda bs=16kb count=1 Please note the much larger bs than I originally used. Also note the generic hda device rather than the /dev/hdaZ (Z=1 or whatever). I probably should have made count much bigger, but I ran the command in this mannter. And it seemed to do the trick anyway. [This obviously wiped out the partition information completely. Good.] Then I rebooted the computer (reboot from linux). During the boot, I entered the BIOS setup mode. I manually set the BIOS geometry for the disk from AUTO to USER and set 2940/255/63, which was used by Linux and seemingly win98 too. Next, I booted the PC using win98 installation floppy and found that it reported "no partition exists" warning! Good. Wiping out of the partition info confirmed. (As a matter of fact, previously when I experimented with dd, etc., the partition information somehow persisted. At this stage in my previous attempt, I could run Win98 format command and it simplay answered all the data on c drive would disappear, and I was forced to wonder WHERE format picked up the idea of the C driver partition. Obviously, my dd command was not clearing large enough area or I was mistyping the command parameter(?)) As a next step, although I was advised to stay away from disk manager tools, which I believe is a good advice in general, I used Seagate Disk Manager DM.exe for partition/formating purpose ONLY (I think). If you compare the speed of formating of this tool agains MS's, this tool wins hands down. It is BLAZINGLY fast. (Actually I found that Western Digital's similar tool also runs very fast. Maybe the same origin.) Anyway, using DM.exe, I ended up again with 10 FAT16 partitions on the disk, one of which is the primary partition, and the rest are logical partions in the extended partition. Now it is time to learn whether both the win98 (or more to the point the DM.exe) , and linux used the same geometry now recorded in the BIOS explicitly. So I rebooted Linux using loadlin floppy WITHOUT specifiying hda=ccc,hhh.sss. : previously I had hda=39694/16/63, which was the natural CHS picked up on AWARD BIOS motherboards for this disk somehow. (Without hda parameter, it used the 2940/255/63 after I began playing with old Debian GNU/Linux CD as explained in my previous post.). After booting linux, I checked the print out of the fdisk: the following is the output. As you can see below, no boundary mismatch information reported anymore. Perfect. - Command (m for help): p Disk /dev/hda: 255 heads, 63 sectors, 2490 cylinders Units = cylinders of 16065 * 512 bytes Device BootStart EndBlocks Id System /dev/hda1 * 1 249 2616 FAT16 /dev/hda2 250 2490 18000832+ f Win95 Ext'd (LBA) /dev/hda5 250 498 2616 FAT16 /dev/hda6 499 747 2616 FAT16 /dev/hda7 748 996 2616 FAT16 /dev/hda8 997 1245 2616 FAT16 /dev/hda9 1246 1494 2616 FAT16 /dev/hda10 1495 1743 2616 FAT16 /dev/hda11 1744 1992 2616 FAT16 /dev/hda12 1993 2241 2616 FAT16 /dev/hda13 2242 2490 2616 FAT16 So I think in my case the command with a large bs worked: dd if=/dev/zero of=/dev/hda bs=16kb count=1 Under this partitioning
Re: Linux 2.2.19pre2
On Sun, Dec 24, 2000 at 04:17:10PM +1100, Andrew Morton wrote:
> I was talking about a different scenario:
>
> add_wait_queue_exclusive(>wait_for_request, );
> for (;;) {
> __set_current_state(TASK_UNINTERRUPTIBLE);
> /* WINDOW */
> spin_lock_irq(_request_lock);
> rq = get_request(q, rw);
> spin_unlock_irq(_request_lock);
> if (rq)
> break;
> generic_unplug_device(q);
> schedule();
> }
> remove_wait_queue(>wait_for_request, );
>
> Suppose there are two tasks sleeping in the schedule().
>
> A wakeup comes. One task wakes. It loops aound and reaches
> the window. At this point in time, another wakeup gets sent
> to the waitqueue. It gets directed to the task which just
> woke up![..]
Ok, this is a very minor window compared to the current one, but yes, that
could happen too in test4.
> I assume this is because this waitqueue gets lots of wakeups sent to it.
It only gets the strictly necessary number of wakeups.
> Linus suggested at one point that we clear the waitqueue's
> WQ_FLAG_EXCLUSIVE bit when we wake it up, [..]
.. and then set it after checking if a new request is available, just
before schedule(). That would avoid the above race (and the one
I mentioned in previous email) but it doesn't address the lost wakeups
for example when setting USE_RW_WAIT_QUEUE_SPINLOCK to 1.
Considering wakeups only the ones that moves the task to the runqueue will get
rid of the races all together and it looks right conceptually so I prefer it.
Andrea
-
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/
Kernel-Patch
Hello to everybody This is a kernel patch against linux-2.4.0-test12. It includes only a few small code changes to make my Compiler (GCC 2.97) not complaining so much. Cheers Marcel patch
Re: TCP keepalive seems to send to only one port
On Sun, Dec 24, 2000 at 10:14:55AM +0100, Andi Kleen wrote: > On Sat, Dec 23, 2000 at 09:31:56PM -0200, Cesar Eduardo Barros wrote: > > > > I've been doing some experiments with the keepalive code in 2.4.0-test10 here > > (I want to avoid the 2.2.x NAT I'm using (for which I don't have root) from > > timing out my connections). To test it, I reduced both tcp_keepalive_time and > > tcp_keepalive_intvl to 1. Using ethereal, I saw that the keepalives were sent > > as expected, but only for one of the two idle TCP connections I had to a given > > host (I was testing with two remote hosts, each with two idle TCP connections, > > one in port 5500 and the other in port 5501). I only saw activity on 5500, yet > > netstat told me both were still active. > > I just tried it and it works fine here with 2.4.0-test13-pre > > You should be aware that the sysctls are only picked up after a timer timeout > or when a socket is newly created. When the sockets are already active it > takes a timeout for them to take effect. The default timeout is 2 hours. > I noticed that, so I exited the program and reloaded it after each change. I still don't know why it worked only with the first socket here (both sockets are opened by the same program). Maybe something changed in the networking code since test10? -- Cesar Eduardo Barros [EMAIL PROTECTED] [EMAIL PROTECTED] - 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/
Re: recommended gcc compiler version
[EMAIL PROTECTED] (Anuradha Ratnaweera) wrote on 22.12.00 in <[EMAIL PROTECTED]>: > On Fri, 22 Dec 2000, Alan Cox wrote: > > > For i386 > > > > 2.2.18 > > gcc 2.7.2 or egcs-1.1.2 > > Just a remainder for debian users. There is a debian package gcc272 which > is said to be the "GNU C compiler's C part", for "backword compatibility > purposes". I recompiled my kernel after an > > apt-get install gcc272 > > and after setting > > HOSTGCC = gcc272 > > in kernel source tree Makerile. I recently compiled 2.2.18 and noticed that make-kpkg (from kernel-package - don't compile kernels on Debian without it!) did that automatically. Incidentally, I really like the Flavours patch. MfG Kai - 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/
Re: innd mmap bug in 2.4.0-test12
"Marco d'Itri" ([EMAIL PROTECTED]) wrote: > I can confirm the bug which loses updates to the inn active file when > it's unmapped is present again in 2.4.0-test12. It is also still in 2.4.0-test13-pre4 in case someone thought they had fixed it. -- Jeff Lightfoot --jeffml at pobox.com -- http://thefoots.com/ "I see the light at the end of the tunnel now ... someone please tell me it's not a train" -- Cracker - 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/
Re: About Celeron processor memory barrier problem
[EMAIL PROTECTED] (Linus Torvalds) wrote on 23.12.00 in <[EMAIL PROTECTED]>: > On Thu, 23 Dec 1999, michael chen wrote: > > I found that when I compiled the 2.4 kernel with the option > > of Pentium III or Pentium 4 on a Celeron's PC, it could cause the > > system hang at very beginning boot stage, and I found the problem > > is cause by the fact that Intel Celeron doesn't have a real memory > > barrier,but when you choose the Pentium III option, the kernel > > assume the processor has a real memory barrier. > > Here is a patch to fix it: > > No. > > The fix is to not lie to the configurator. > > A Celeron isn't a PIII, and you shouldn't tell the configure that it is. > > The whole point of being able to choose the CPU to optimize for is that we > can optimize things at compile-time. Which is all fine, but maybe the kernel really ought to detect that problem and complain at boot time? Or does that happen already? MfG Kai - 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/
Re: About Celeron processor memory barrier problem
On Sun, Dec 24, 2000 at 10:45:14AM +0100, Jeffrey Rose wrote: > I also have a Celeron 600 in my Compaq 5000, but even with the output > below, I am not sure this is what Linus is talking about! I believe > Linus is trying to say, "We HAVE configurations set for that specific > architecture, so please USE them." However, I suppose you are saying you > will get better performance from selecting PIII due to this output? Let > me know ... The confusion is because Intel reused the name Celeron for a completely different CPU. The original Celeron was based on a PII core, the new Celeron is based on a PIII core. Both Celerons have the same features as the CPU they are based on, but with less cache memory. Selecting PIII for the new PIII based Celeron will indeed give you slightly better performance. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - 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/
Re: Q: natsemi.c spinlocks
Andrew Morton wrote:
>
> start_tx()
> {
Yes, I overlooked start_tx.
Hmm. start_tx also assumes that the cpu commits writes in order, I'm
sure the driver is unreliable on RISC cpus.
Perhaps the driver should use pci_alloc_consistent and pci_map_single?
--
Manfred
-
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/
Re: sparc 10 w/512 megs hangs during boot
On Sat, Dec 23, 2000 at 11:57:21PM -0800, Ron Calderon wrote: > My sparc 10 seems to hang with any 2.4.0-test12+ > kernel ...but 2.4.0-test11-X kernels are fine? Well, good info;) > if I add mem=128M it boots fine, but anything above > 128M wont boot it just hangs. Is there something I've > missed? here is screen output. I see this as well (SS10 dual with 128MB RAM). However, if slightly older kernel are okay, then it's quite easy to look through the patches. Which is your last-known-to-be-good kernel? > Uncompressing image... > PROMLIB: obio_ranges 5 > bootmem_init: Scan sp_banks, > init_bootmem(spfn[1c9],bpfn[1c9],mlpfn[c000]) > free_bootmem: base[0] size[c00] > reserve_bootmem: base[0] size[1c9000] > reserve_bootmem: base[1c9000] size[1800] > > then it just hangs here I additionally get "Unexpected Level 15 Interrupt" und "Program terminated" ;-) MfG, JBG -- Fehler eingestehen, Größe zeigen: Nehmt die Rechtschreibreform zurück!!! /* Jan-Benedict Glaw <[EMAIL PROTECTED]> -- +49-177-5601720 */ keyID=0x8399E1BB fingerprint=250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB "insmod vi.o and there we go..." (Alexander Viro on linux-kernel) PGP signature
2.2.19pre3 clock timer config lost ?
never seen this before. I run 2.2.19pre3 on a BP6. No OC, no vmware. just the kernel wilt lm-sensors stuff patched in. I found that the kernel was somewhat sluggish now and then, and this morning, this popped up in the logs : Dec 24 02:05:05 grobbebol kernel: probable hardware bug: clock timer configuration lost - probably a VIA686a. Dec 24 02:05:05 grobbebol kernel: probable hardware bug: restoring chip configuration. which is weird I guess. -- Grobbebol's Home | Don't give in to spammers. -o) http://www.xs4all.nl/~bengel | Use your real e-mail address /\ Linux 2.2.16 SMP 2x466MHz / 256 MB |on Usenet. _\_v - 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/
Re: About Celeron processor memory barrier problem
Erik Mouw wrote: > > On Sat, Dec 23, 2000 at 09:21:51AM -0800, Linus Torvalds wrote: > > A Celeron isn't a PIII, and you shouldn't tell the configure that it is. > > Well, some Celerons are. My laptop has a Celeron with a Coppermine > core, so it is PIII based. Here is the output from /proc/cpuinfo: > > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 8 > model name : Celeron (Coppermine) > stepping: 1 > cpu MHz : 501.140 > cache size : 128 KB > fdiv_bug: no > hlt_bug : no > f00f_bug: no > coma_bug: no > fpu : yes > fpu_exception : yes > cpuid level : 2 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 >mmx fxsr sse > bogomips: 999.42 I also have a Celeron 600 in my Compaq 5000, but even with the output below, I am not sure this is what Linus is talking about! I believe Linus is trying to say, "We HAVE configurations set for that specific architecture, so please USE them." However, I suppose you are saying you will get better performance from selecting PIII due to this output? Let me know ... jrose$ cat /proc/info processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Celeron (Coppermine) stepping: 3 cpu MHz : 598.064 cache size : 128 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1192.76 Cheers, Jeff -- <[EMAIL PROTECTED]> KEYSERVER=wwwkeys.de.pgp.net SEARCH STRING=Jeffrey Rose KEYID=6AD04244 - 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/
Re: TCP keepalive seems to send to only one port
On Sat, Dec 23, 2000 at 09:31:56PM -0200, Cesar Eduardo Barros wrote: > > I've been doing some experiments with the keepalive code in 2.4.0-test10 here > (I want to avoid the 2.2.x NAT I'm using (for which I don't have root) from > timing out my connections). To test it, I reduced both tcp_keepalive_time and > tcp_keepalive_intvl to 1. Using ethereal, I saw that the keepalives were sent > as expected, but only for one of the two idle TCP connections I had to a given > host (I was testing with two remote hosts, each with two idle TCP connections, > one in port 5500 and the other in port 5501). I only saw activity on 5500, yet > netstat told me both were still active. I just tried it and it works fine here with 2.4.0-test13-pre You should be aware that the sysctls are only picked up after a timer timeout or when a socket is newly created. When the sockets are already active it takes a timeout for them to take effect. The default timeout is 2 hours. -Andi - 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/
Re: bigphysarea support in 2.2.19 and 2.4.0 kernels
Eric W. Biederman writes: > If you are doing a real time task you don't want to very close > to your performance envelope. If you are hitting the performance > envelope any small hiccup will cause you to miss your deadline, > and close to your performance envelope hiccups are virtually certain. > > Pushing the machine just 5% slower should get everything going > with multiple pages, and you wouldn't be pushing the performance > envelope so your machine can compensate for the occasional hiccup. > >> The data stream is fat and relentless. > > So you add another node if your current nodes can't handle the load > without using giant physical areas of memory. Attempt to redesign > the operating system. Much more cost effective. Nodes can be wicked expensive. :-) Pushing the performance envelope is important when you want to sell lots of systems. Radar is a similar computational task, with the added need to reduce space and weight requirements. It's not OK to be 5% more expensive, bulky, and heavy. Also the Airplane Principal: more nodes means more big failures. - 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/
innd mmap bug in 2.4.0-test12
I can confirm the bug which loses updates to the inn active file when
it's unmapped is present again in 2.4.0-test12.
I put "cp active active.ok" in the rc file before shutting down the
daemon and at the next boot the files are different, every time.
Alexander Viro posted this test case:
#include
main(argc,argv)
int argc;
char **argv;
{
int fd;
char c=0;
truncate(argv[1], 10);
fd = open(argv[1], 1);
lseek(fd, 16384, 0);
write(fd, , 1);
close(fd);
}
but I tried it and it gives the correct result (a 16384 bytes long file
with only the first few bytes non-zeroed).
Linux wonderland 2.4.0-test12 #15 Thu Dec 21 16:40:16 CET 2000 i586 unknown
--
ciao,
Marco
-
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/
Re: bigphysarea support in 2.2.19 and 2.4.0 kernels
Jes Sorensen writes: > Albert D Cahalan <[EMAIL PROTECTED]> writes: [about using huge physical allocations for number crunching] >> 2. Programming a DMA controller with multiple addresses isn't >> as fast as programming it with one. > > LOL > > Consider that allocating the larger block of memory is going > to take a lot longer than it will take for the DMA engine to > read the scatter/gather table entries and fetch a new address > word now and then. Say it takes a whole minute to allocate the memory. It wouldn't of course, because you'd allocate memory at boot, but anyway... Then the app runs, using that memory, for a multi-hour surgery. The allocation happens once; the inter-node DMA transfers occur dozens or hundreds of times per second. - 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/
Re: bigphysarea support in 2.2.19 and 2.4.0 kernels
Jes Sorensen writes: Albert D Cahalan [EMAIL PROTECTED] writes: [about using huge physical allocations for number crunching] 2. Programming a DMA controller with multiple addresses isn't as fast as programming it with one. LOL Consider that allocating the larger block of memory is going to take a lot longer than it will take for the DMA engine to read the scatter/gather table entries and fetch a new address word now and then. Say it takes a whole minute to allocate the memory. It wouldn't of course, because you'd allocate memory at boot, but anyway... Then the app runs, using that memory, for a multi-hour surgery. The allocation happens once; the inter-node DMA transfers occur dozens or hundreds of times per second. - 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/
innd mmap bug in 2.4.0-test12
I can confirm the bug which loses updates to the inn active file when
it's unmapped is present again in 2.4.0-test12.
I put "cp active active.ok" in the rc file before shutting down the
daemon and at the next boot the files are different, every time.
Alexander Viro posted this test case:
#include unistd.h
main(argc,argv)
int argc;
char **argv;
{
int fd;
char c=0;
truncate(argv[1], 10);
fd = open(argv[1], 1);
lseek(fd, 16384, 0);
write(fd, c, 1);
close(fd);
}
but I tried it and it gives the correct result (a 16384 bytes long file
with only the first few bytes non-zeroed).
Linux wonderland 2.4.0-test12 #15 Thu Dec 21 16:40:16 CET 2000 i586 unknown
--
ciao,
Marco
-
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/
Re: bigphysarea support in 2.2.19 and 2.4.0 kernels
Eric W. Biederman writes: If you are doing a real time task you don't want to very close to your performance envelope. If you are hitting the performance envelope any small hiccup will cause you to miss your deadline, and close to your performance envelope hiccups are virtually certain. Pushing the machine just 5% slower should get everything going with multiple pages, and you wouldn't be pushing the performance envelope so your machine can compensate for the occasional hiccup. The data stream is fat and relentless. So you add another node if your current nodes can't handle the load without using giant physical areas of memory. Attempt to redesign the operating system. Much more cost effective. Nodes can be wicked expensive. :-) Pushing the performance envelope is important when you want to sell lots of systems. Radar is a similar computational task, with the added need to reduce space and weight requirements. It's not OK to be 5% more expensive, bulky, and heavy. Also the Airplane Principal: more nodes means more big failures. - 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/
Re: TCP keepalive seems to send to only one port
On Sat, Dec 23, 2000 at 09:31:56PM -0200, Cesar Eduardo Barros wrote: I've been doing some experiments with the keepalive code in 2.4.0-test10 here (I want to avoid the 2.2.x NAT I'm using (for which I don't have root) from timing out my connections). To test it, I reduced both tcp_keepalive_time and tcp_keepalive_intvl to 1. Using ethereal, I saw that the keepalives were sent as expected, but only for one of the two idle TCP connections I had to a given host (I was testing with two remote hosts, each with two idle TCP connections, one in port 5500 and the other in port 5501). I only saw activity on 5500, yet netstat told me both were still active. I just tried it and it works fine here with 2.4.0-test13-pre You should be aware that the sysctls are only picked up after a timer timeout or when a socket is newly created. When the sockets are already active it takes a timeout for them to take effect. The default timeout is 2 hours. -Andi - 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/
Re: About Celeron processor memory barrier problem
Erik Mouw wrote: On Sat, Dec 23, 2000 at 09:21:51AM -0800, Linus Torvalds wrote: A Celeron isn't a PIII, and you shouldn't tell the configure that it is. Well, some Celerons are. My laptop has a Celeron with a Coppermine core, so it is PIII based. Here is the output from /proc/cpuinfo: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Celeron (Coppermine) stepping: 1 cpu MHz : 501.140 cache size : 128 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 999.42 I also have a Celeron 600 in my Compaq 5000, but even with the output below, I am not sure this is what Linus is talking about! I believe Linus is trying to say, "We HAVE configurations set for that specific architecture, so please USE them." However, I suppose you are saying you will get better performance from selecting PIII due to this output? Let me know ... jrose$ cat /proc/info processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Celeron (Coppermine) stepping: 3 cpu MHz : 598.064 cache size : 128 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1192.76 Cheers, Jeff -- [EMAIL PROTECTED] KEYSERVER=wwwkeys.de.pgp.net SEARCH STRING=Jeffrey Rose KEYID=6AD04244 - 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/
2.2.19pre3 clock timer config lost ?
never seen this before. I run 2.2.19pre3 on a BP6. No OC, no vmware. just the kernel wilt lm-sensors stuff patched in. I found that the kernel was somewhat sluggish now and then, and this morning, this popped up in the logs : Dec 24 02:05:05 grobbebol kernel: probable hardware bug: clock timer configuration lost - probably a VIA686a. Dec 24 02:05:05 grobbebol kernel: probable hardware bug: restoring chip configuration. which is weird I guess. -- Grobbebol's Home | Don't give in to spammers. -o) http://www.xs4all.nl/~bengel | Use your real e-mail address /\ Linux 2.2.16 SMP 2x466MHz / 256 MB |on Usenet. _\_v - 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/
Re: sparc 10 w/512 megs hangs during boot
On Sat, Dec 23, 2000 at 11:57:21PM -0800, Ron Calderon wrote: My sparc 10 seems to hang with any 2.4.0-test12+ kernel ...but 2.4.0-test11-X kernels are fine? Well, good info;) if I add mem=128M it boots fine, but anything above 128M wont boot it just hangs. Is there something I've missed? here is screen output. I see this as well (SS10 dual with 128MB RAM). However, if slightly older kernel are okay, then it's quite easy to look through the patches. Which is your last-known-to-be-good kernel? Uncompressing image... PROMLIB: obio_ranges 5 bootmem_init: Scan sp_banks, init_bootmem(spfn[1c9],bpfn[1c9],mlpfn[c000]) free_bootmem: base[0] size[c00] reserve_bootmem: base[0] size[1c9000] reserve_bootmem: base[1c9000] size[1800] then it just hangs here I additionally get "Unexpected Level 15 Interrupt" und "Program terminated" ;-) MfG, JBG -- Fehler eingestehen, Größe zeigen: Nehmt die Rechtschreibreform zurück!!! /* Jan-Benedict Glaw [EMAIL PROTECTED] -- +49-177-5601720 */ keyID=0x8399E1BB fingerprint=250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB "insmod vi.o and there we go..." (Alexander Viro on linux-kernel) PGP signature
Re: Q: natsemi.c spinlocks
Andrew Morton wrote:
start_tx()
{
Yes, I overlooked start_tx.
Hmm. start_tx also assumes that the cpu commits writes in order, I'm
sure the driver is unreliable on RISC cpus.
Perhaps the driver should use pci_alloc_consistent and pci_map_single?
--
Manfred
-
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/
Re: About Celeron processor memory barrier problem
On Sun, Dec 24, 2000 at 10:45:14AM +0100, Jeffrey Rose wrote: I also have a Celeron 600 in my Compaq 5000, but even with the output below, I am not sure this is what Linus is talking about! I believe Linus is trying to say, "We HAVE configurations set for that specific architecture, so please USE them." However, I suppose you are saying you will get better performance from selecting PIII due to this output? Let me know ... The confusion is because Intel reused the name Celeron for a completely different CPU. The original Celeron was based on a PII core, the new Celeron is based on a PIII core. Both Celerons have the same features as the CPU they are based on, but with less cache memory. Selecting PIII for the new PIII based Celeron will indeed give you slightly better performance. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - 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/
Re: About Celeron processor memory barrier problem
[EMAIL PROTECTED] (Linus Torvalds) wrote on 23.12.00 in [EMAIL PROTECTED]: On Thu, 23 Dec 1999, michael chen wrote: I found that when I compiled the 2.4 kernel with the option of Pentium III or Pentium 4 on a Celeron's PC, it could cause the system hang at very beginning boot stage, and I found the problem is cause by the fact that Intel Celeron doesn't have a real memory barrier,but when you choose the Pentium III option, the kernel assume the processor has a real memory barrier. Here is a patch to fix it: No. The fix is to not lie to the configurator. A Celeron isn't a PIII, and you shouldn't tell the configure that it is. The whole point of being able to choose the CPU to optimize for is that we can optimize things at compile-time. Which is all fine, but maybe the kernel really ought to detect that problem and complain at boot time? Or does that happen already? MfG Kai - 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/
Re: innd mmap bug in 2.4.0-test12
"Marco d'Itri" ([EMAIL PROTECTED]) wrote: I can confirm the bug which loses updates to the inn active file when it's unmapped is present again in 2.4.0-test12. It is also still in 2.4.0-test13-pre4 in case someone thought they had fixed it. -- Jeff Lightfoot --jeffml at pobox.com -- http://thefoots.com/ "I see the light at the end of the tunnel now ... someone please tell me it's not a train" -- Cracker - 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/
Re: recommended gcc compiler version
[EMAIL PROTECTED] (Anuradha Ratnaweera) wrote on 22.12.00 in [EMAIL PROTECTED]: On Fri, 22 Dec 2000, Alan Cox wrote: For i386 2.2.18 gcc 2.7.2 or egcs-1.1.2 Just a remainder for debian users. There is a debian package gcc272 which is said to be the "GNU C compiler's C part", for "backword compatibility purposes". I recompiled my kernel after an apt-get install gcc272 and after setting HOSTGCC = gcc272 in kernel source tree Makerile. I recently compiled 2.2.18 and noticed that make-kpkg (from kernel-package - don't compile kernels on Debian without it!) did that automatically. Incidentally, I really like the Flavours patch. MfG Kai - 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/
Re: TCP keepalive seems to send to only one port
On Sun, Dec 24, 2000 at 10:14:55AM +0100, Andi Kleen wrote: On Sat, Dec 23, 2000 at 09:31:56PM -0200, Cesar Eduardo Barros wrote: I've been doing some experiments with the keepalive code in 2.4.0-test10 here (I want to avoid the 2.2.x NAT I'm using (for which I don't have root) from timing out my connections). To test it, I reduced both tcp_keepalive_time and tcp_keepalive_intvl to 1. Using ethereal, I saw that the keepalives were sent as expected, but only for one of the two idle TCP connections I had to a given host (I was testing with two remote hosts, each with two idle TCP connections, one in port 5500 and the other in port 5501). I only saw activity on 5500, yet netstat told me both were still active. I just tried it and it works fine here with 2.4.0-test13-pre You should be aware that the sysctls are only picked up after a timer timeout or when a socket is newly created. When the sockets are already active it takes a timeout for them to take effect. The default timeout is 2 hours. I noticed that, so I exited the program and reloaded it after each change. I still don't know why it worked only with the first socket here (both sockets are opened by the same program). Maybe something changed in the networking code since test10? -- Cesar Eduardo Barros [EMAIL PROTECTED] [EMAIL PROTECTED] - 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/
Kernel-Patch
Hello to everybody This is a kernel patch against linux-2.4.0-test12. It includes only a few small code changes to make my Compiler (GCC 2.97) not complaining so much. Cheers Marcel patch
Re: IDE woes:linux and BIOS won't agree on C/H/S detection
Guest section DW wrote: On Sat, Dec 23, 2000 at 12:11:41AM +0900, Ishikawa wrote: I have to think more deeply then what the best measure would be. I suppose you can get all systems involved to agree on 255 heads if you select LBA in the BIOS. Andries Hi, I think I misunderstood one thing before all the tips came in. I somehow assumed that the Win98 would use the disk geometry that AMI BIOS reported during boot for the hard disk. I was wrong. Win98 seems to have its own idea of picking up convenient CHS just as linux might do. (And incidentally, this CHS seems to agree between w98 and linux!) Or AMI BIOS is lying to me during the boot and pass a different info to the OS when inquired afterward as suggested by someone. Anyway, when the geometry mismatch was reported in linux fdisk after trying to install win98 and found that linux picked up CHS geometry different from that of BIOS's, I thought this was the problem. But as Andries pointed out Win98 seemed to use the same geometry information as linux used before I made it to use the BIOS geometry by means of boot command line parameter. This means two to one favor against BIOS's idea of CHS! The two OSs used 255 heads geometry. So what I did was this. (In the end, I didn't have to remove SCSI disk to check if the linux or BIOS gets confused with the SCSI disk geometry info.) Firstly, from linux, I did the following in order to try my another attempt to wipe out the partition information for sure. dd if=/dev/zero of=/dev/hda bs=16kb count=1 Please note the much larger bs than I originally used. Also note the generic hda device rather than the /dev/hdaZ (Z=1 or whatever). I probably should have made count much bigger, but I ran the command in this mannter. And it seemed to do the trick anyway. [This obviously wiped out the partition information completely. Good.] Then I rebooted the computer (reboot from linux). During the boot, I entered the BIOS setup mode. I manually set the BIOS geometry for the disk from AUTO to USER and set 2940/255/63, which was used by Linux and seemingly win98 too. Next, I booted the PC using win98 installation floppy and found that it reported "no partition exists" warning! Good. Wiping out of the partition info confirmed. (As a matter of fact, previously when I experimented with dd, etc., the partition information somehow persisted. At this stage in my previous attempt, I could run Win98 format command and it simplay answered all the data on c drive would disappear, and I was forced to wonder WHERE format picked up the idea of the C driver partition. Obviously, my dd command was not clearing large enough area or I was mistyping the command parameter(?)) As a next step, although I was advised to stay away from disk manager tools, which I believe is a good advice in general, I used Seagate Disk Manager DM.exe for partition/formating purpose ONLY (I think). If you compare the speed of formating of this tool agains MS's, this tool wins hands down. It is BLAZINGLY fast. (Actually I found that Western Digital's similar tool also runs very fast. Maybe the same origin.) Anyway, using DM.exe, I ended up again with 10 FAT16 partitions on the disk, one of which is the primary partition, and the rest are logical partions in the extended partition. Now it is time to learn whether both the win98 (or more to the point the DM.exe) , and linux used the same geometry now recorded in the BIOS explicitly. So I rebooted Linux using loadlin floppy WITHOUT specifiying hda=ccc,hhh.sss. : previously I had hda=39694/16/63, which was the natural CHS picked up on AWARD BIOS motherboards for this disk somehow. (Without hda parameter, it used the 2940/255/63 after I began playing with old Debian GNU/Linux CD as explained in my previous post.). After booting linux, I checked the print out of the fdisk: the following is the output. As you can see below, no boundary mismatch information reported anymore. Perfect. - Command (m for help): p Disk /dev/hda: 255 heads, 63 sectors, 2490 cylinders Units = cylinders of 16065 * 512 bytes Device BootStart EndBlocks Id System /dev/hda1 * 1 249 2616 FAT16 /dev/hda2 250 2490 18000832+ f Win95 Ext'd (LBA) /dev/hda5 250 498 2616 FAT16 /dev/hda6 499 747 2616 FAT16 /dev/hda7 748 996 2616 FAT16 /dev/hda8 997 1245 2616 FAT16 /dev/hda9 1246 1494 2616 FAT16 /dev/hda10 1495 1743 2616 FAT16 /dev/hda11 1744 1992 2616 FAT16 /dev/hda12 1993 2241 2616 FAT16 /dev/hda13 2242 2490 2616 FAT16 So I think in my case the command with a large bs worked: dd if=/dev/zero of=/dev/hda bs=16kb count=1 Under this partitioning scheme, I
Re: IDE woes:linux and BIOS won't agree on C/H/S detection
I sent out a longish response a few minutes ago which explained the my problem was solved somehow! One thing I missed explaining in my original post is the AMI BIOS on the GA-7IXE4 motherboard has a very spartan set of options. For the geometry translation of ATA disk, only On/Off choice was available and according to help message On means LBA and Off is non-LBA (normail?). I let LBA on during my trials and errors. AWARD BIOS would have shown none/auto/large/lba, etc. for the same choice. Well, AMI BIOS seems to be pretty minor these days. I have seen it lately on my current motherboard as well as onthe low-price end machines from small vendors, inside VMware's virtual PC environment(!), but nowhere else. There could be some rough edges still around due to smaller user base. I am glad I have been using SCSI disk. If it had not been for my 2.4.0-test12 on a scsi disk I moved from my old PC, I would not have been able to use linux successfully with Win98 partition on this motherboard for a couple of weeks. I guess my motherboard is somewhat exceptional case where BIOSreports a geometry that didn't match the geometry used by popular OSes. Again thank you everybody for helpful tips. - 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/
Re: Linux 2.2.19pre2
On Sun, Dec 24, 2000 at 11:23:33AM +1100, Andrew Morton wrote: ack. This patch against 2.2.19pre3 should fix all races. (note that wait-flags doesn't need to be initialized in the critical section in test1X too) ftp://ftp.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.19pre3/wake-one-3 Comments? Andrea - 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/
Masquerade hangups
Hello, I have a Tyan S1854 Trinity 400 mb machine with a PCI rtl8139 card connected to my local net and a ISA 3c509 card connected to my dsl link. Masquerade is set up. I seem to get pretty good performance from internet-masq box and from masq box-internal lan, but when a internal box tries to get to the net through the masquerade, connection seem to time out. I'll get a pretty good initial burst, then connections stall. I'm using test13-pre4. I saw some iptables stuff on the list a week or so ago, was this fixed in pre4 or is this my problem? I can provide any information needed. -mwe [EMAIL PROTECTED] - 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/
Re: innd mmap bug in 2.4.0-test12
On Dec 24, Alexander Viro [EMAIL PROTECTED] wrote: I put "cp active active.ok" in the rc file before shutting down the daemon and at the next boot the files are different, every time. Could you send me both files? BTW, which filesystem it is? I use ext2. The files are not corrupted, they just are not updated. Another data point: at least in some cases, if I stop and start inn without rebooting the files are the same. --- active.ok Sun Dec 24 09:58:00 2000 +++ active Sun Dec 24 08:33:34 2000 @@ -1,5 +1,5 @@ control 004793 004794 y -control.cancel 022865 021934 n +control.cancel 022864 021934 n junk 001806 001807 y fido.ita.ridere 014779 014777 y fido.ita.dewdney 004073 004074 y @@ -10,19 +10,19 @@ fido.ita.sf 004777 004778 y comp.os.linux.announce 010782 010779 m fido.ita.tex 000248 000249 y -it.news.annunci 004909 004787 m +it.news.annunci 004905 004787 m it.news.gestione 007878 007399 y fido.ita.tv 011944 011944 y it.test 000796 000797 y -it.news.gruppi 048004 047898 y +it.news.gruppi 047994 047898 y it.comp.sicurezza.varie 030696 030353 y it.comp.sicurezza.unix 002721 002722 y -it.faq 001154 001091 m +it.faq 001150 001091 m [...] -- ciao, Marco - 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/
Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots
On Sat, 23 Dec 2000, Andreas Franck wrote: Hi Mike, hello linux-kernel audience, I had the same, with the last few snapshots I tried, but 20001218 seems to work ok. dmesg|head -1 Linux version 2.4.0-test13ikd (root@el-kaboom) (gcc version gcc-2.97 20001218 (experimental)) #18 Sat Dec 23 17:43:29 CET 2000 Hmm, would have been nice, but it crashes here with 20001222, nevertheless. For which CPU do you have your kernel configured? It might be a CPU specific issue, I'll try to compile for Pentium I and 486, now, and report my results. Yes, hmm indeed. Try these two things. 1. make DECLARE_MUTEX_LOCKED(sem) in bdflush_init() static. 2. compile with frame pointers. (normal case for IKD) My IKD tree works with either option, but not with neither. I haven't figured out why yet. -Mike - 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/
Re: About Celeron processor memory barrier problem
Hi!
diff -Nur linux/include/asm-i386/system.h linux.new/include/asm-i386/system.h
--- linux/include/asm-i386/system.h Mon Dec 11 19:26:39 2000
+++ linux.new/include/asm-i386/system.h Sat Dec 23 16:06:01 2000
@@ -274,7 +274,14 @@
#ifndef CONFIG_X86_XMM
#define mb() __asm__ __volatile__ ("lock; addl $0,0(%%esp)": : :"memory")
#else
-#define mb() __asm__ __volatile__ ("sfence": : :"memory")
+#define mb() do { \
+ if ( cpu_has_xmm ) { \
~~
Cost of test may well be bigger than gain by using sfence...
Pavel
--
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED]
-
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/
Re: test13-pre4 ip defrag oops
Hello!
eax: 20202037 ebx: d3a406c0 ecx: cf683024 edx: c734a2a0
Ough... found eventually. skb-dev turns out to be not initialized. 8)8)
This patchlet surely fixes the bug. (plus writes are ordered)
Alexey
--- ../vger3-001222/linux/net/core/skbuff.c Fri Dec 22 19:37:54 2000
+++ linux/net/core/skbuff.c Sun Dec 24 20:24:20 2000
@@ -227,15 +227,20 @@
{
struct sk_buff *skb = p;
- skb-destructor = NULL;
- skb-pkt_type = PACKET_HOST;/* Default type */
- skb-prev = skb-next = NULL;
+ skb-next = NULL;
+ skb-prev = NULL;
skb-list = NULL;
skb-sk = NULL;
skb-stamp.tv_sec=0;/* No idea about time */
+ skb-dev = NULL;
+ skb-dst = NULL;
+ memset(skb-cb, 0, sizeof(skb-cb));
+ skb-pkt_type = PACKET_HOST;/* Default type */
skb-ip_summed = 0;
+ skb-priority = 0;
skb-security = 0; /* By default packets are insecure */
- skb-dst = NULL;
+ skb-destructor = NULL;
+
#ifdef CONFIG_NETFILTER
skb-nfmark = skb-nfcache = 0;
skb-nfct = NULL;
@@ -246,8 +251,6 @@
#ifdef CONFIG_NET_SCHED
skb-tc_index = 0;
#endif
- memset(skb-cb, 0, sizeof(skb-cb));
- skb-priority = 0;
}
-
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/
Re: innd mmap bug in 2.4.0-test12
On Sun, 24 Dec 2000, Marco d'Itri wrote:
On Dec 24, Alexander Viro [EMAIL PROTECTED] wrote:
I put "cp active active.ok" in the rc file before shutting down the
daemon and at the next boot the files are different, every time.
Could you send me both files? BTW, which filesystem it is?
I use ext2. The files are not corrupted, they just are not updated.
Another data point: at least in some cases, if I stop and start inn
without rebooting the files are the same.
Ok, looks like we just drop the page cache page without writing it out in
some cases. Possibly/probably because we have dropped the dirty bit on the
floor.
Look slike this is a completely different case from the previous
corruptions, it looks more like a VM issue than a FS thing..
Hmm.. munmap() (and exit()) go through "zap_page_range()", which go
through "free_pte()", which definitely copies the dirty bit to the page
structure.
Hmm.. I wonder if such a dirty page might have been moved to the
"inactive_clean" list some way? It shouldn't really be there, as the page
had users, but if it gets on that list we'd not have tested the dirty bit.
Marco, would you mind changing the test in reclaim_page(), somewheer
around line mm/vmscan.c:487 that says:
/* The page is dirty, or locked, move to inactive_dirty list. */
if (page-buffers || TryLockPage(page)) {
...
and change the test to
if (page-buffers || PageDirty(page) || TryLockPage(page)) {
instead? Ie ad the test for "PageDirty(page)" (and order _is_ important:
the TryLockPage() thing must come last, because it has side effects).
(You might add a "printk()" too that triggers when the new condition
happens, just to see if it does indeed happen).
If the page is on the inactive_clean() list, we'll have to find where it
is put there, because it really shouldn't have been there.
Uhhuh. Actually, reading "page_launder()", the buffer clearign case looks
suspiciously like i doesn't check for page accessed or dirty bits. That's
probably it. Maybe there are other cases. Anyway, I'd love to hear if the
above one-liner fixes the corruption for you..
Thanks,
Linus
-
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/
Re: innd mmap bug in 2.4.0-test12
On Sun, 24 Dec 2000, Linus Torvalds wrote: Marco, would you mind changing the test in reclaim_page(), somewheer around line mm/vmscan.c:487 that says: Yeah, yeah, it's 7PM Christmas Eve over there, and you're in the middle of your Christmas dinner. You might feel that it's unreasonable of me to ask you to test out my latest crazy idea. How selfish of you. Get back there in front of the computer NOW. Christmas can wait. Linus "the Grinch" Torvalds - 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/
Re: FEATURE (was Re: PROBLEM: multiple mount of devices possible2.4.0-test1 - 2.4.0-test13-pre4
Tigran Aivazian wrote: it is not a problem, it is a feature. (and a useful one!) yes, mount devices several times it would be a nice feature, but do something like: /etc/fstab: /dev/hdd1 /mydrive ext2 ro,noauto,user 1 1 as user: mount /mydrive as root: mount /dev/hda2 /mydrive as user: mount /mydrive as root: mount /dev/hda2 /mydrive as user: mount /mydrive result /proc/mounts: /dev/hdd1 /mydrive ext2 ro,noexec,nosuid,nodev 0 0 /dev/hda2 /mydrive vfat rw 0 0 /dev/hdd1 /mydrive ext2 ro,noexec,nosuid,nodev 0 0 /dev/hda2 /mydrive vfat rw 0 0 /dev/hdd1 /mydrive ext2 ro,noexec,nosuid,nodev 0 0 u dont have control about the mountpoints Here a BIG PROBLEM: as user: mount /mydrive as root: mount /dev/hdd1 /test as root: mount /dev/hdd1 /mnt result /proc/mounts: /dev/hdd1 /mydrive ext2 ro,noexec,nosuid,nodev 0 0 /dev/hdd1 /test ext2 ro,noexec,nosuid,nodev 0 0 /dev/hdd1 /mnt ext2 ro,noexec,nosuid,nodev 0 0 but do like mount -o remount /mnt -w result /proc/mounts: /dev/hdd1 /mydrive ext2 rw 0 0 /dev/hdd1 /test ext2 rw 0 0 /dev/hdd1 /mnt ext2 rw 0 0 ALL mountpoints now READ-WRITE-able! u lost noexec... and dont have more "security" for users... same as sym-links ... no new feature... Reinhard. 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 umount in /proc/mounts is still the real information, in /etc/mtab all corresponding mountpoints are deleted. - 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/
Re: innd mmap bug in 2.4.0-test12
Get back there in front of the computer NOW. Christmas can wait. Linus "the Grinch" Torvalds Hoo - Hoo - Hoo, you've been very naughty Linus. Asking people to work on Christmas evening. My god Linus, that's so naughty that I add it to my list... As soon as I'm finished with Futurama, ... I'll get you! Merry X-Mas Santa Claus :)) - 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/
Re: innd mmap bug in 2.4.0-test12
Linus Torvalds wrote:
Hmm.. I wonder if such a dirty page might have been moved to the
"inactive_clean" list some way? It shouldn't really be there, as the page
had users, but if it gets on that list we'd not have tested the dirty bit.
Marco, would you mind changing the test in reclaim_page(), somewheer
around line mm/vmscan.c:487 that says:
/* The page is dirty, or locked, move to inactive_dirty list. */
if (page-buffers || TryLockPage(page)) {
...
and change the test to
if (page-buffers || PageDirty(page) || TryLockPage(page)) {
instead? Ie ad the test for "PageDirty(page)"
Good point. Up until recently the page dirty bit wasn't actually being
set anywhere and page-buffers was acting as kind of a surrogate dirty
bit - page_launder would call try_to_free_buffers which would find the
dirty buffers and fail out, but start io first
It looks like PG_dirty is now being used only for swap_cache pages, and
not for buffer cache and page cache pages, is that correct?
--
Daniel
-
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/
[mwelmor@kre8tive.org: Masquerade hangups]
OK. I went back to 2.2.18 (released) and things work better. Since it appears the debug flags don't work in the 8139too module, how can I turn on some debug flags in the 2.4.0-test13-pre4 driver so I can see where this thing is hanging? -mwe - Forwarded message from Mike Elmore [EMAIL PROTECTED] - Date: Sun, 24 Dec 2000 09:02:12 -0600 From: Mike Elmore [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Masquerade hangups User-Agent: Mutt/1.2.5i Precedence: bulk X-Mailing-List: [EMAIL PROTECTED] Hello, I have a Tyan S1854 Trinity 400 mb machine with a PCI rtl8139 card connected to my local net and a ISA 3c509 card connected to my dsl link. Masquerade is set up. I seem to get pretty good performance from internet-masq box and from masq box-internal lan, but when a internal box tries to get to the net through the masquerade, connection seem to time out. I'll get a pretty good initial burst, then connections stall. I'm using test13-pre4. I saw some iptables stuff on the list a week or so ago, was this fixed in pre4 or is this my problem? I can provide any information needed. -mwe [EMAIL PROTECTED] - 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/ - End forwarded message - -- Mike Elmore [EMAIL PROTECTED] "Never confuse activity with accomplishment." -unknown - 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/
Re: sparc 10 w/512 megs hangs during boot
I just finished compiling 2.4.0-test5 and that worked fine with 512M ram. I'll start going thru the other kernels. It'll take me sometime since compileing takes a long time. ron --- Jan-Benedict Glaw [EMAIL PROTECTED] wrote: On Sat, Dec 23, 2000 at 11:57:21PM -0800, Ron Calderon wrote: My sparc 10 seems to hang with any 2.4.0-test12+ kernel ...but 2.4.0-test11-X kernels are fine? Well, good info;) if I add mem=128M it boots fine, but anything above 128M wont boot it just hangs. Is there something I've missed? here is screen output. I see this as well (SS10 dual with 128MB RAM). However, if slightly older kernel are okay, then it's quite easy to look through the patches. Which is your last-known-to-be-good kernel? Uncompressing image... PROMLIB: obio_ranges 5 bootmem_init: Scan sp_banks, init_bootmem(spfn[1c9],bpfn[1c9],mlpfn[c000]) free_bootmem: base[0] size[c00] reserve_bootmem: base[0] size[1c9000] reserve_bootmem: base[1c9000] size[1800] then it just hangs here I additionally get "Unexpected Level 15 Interrupt" und "Program terminated" ;-) MfG, JBG -- Fehler eingestehen, Größe zeigen: Nehmt die Rechtschreibreform zurück!!! /* Jan-Benedict Glaw [EMAIL PROTECTED] -- +49-177-5601720 */ keyID=0x8399E1BB fingerprint=250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB "insmod vi.o and there we go..." (Alexander Viro on linux-kernel) ATTACHMENT part 2 application/pgp-signature __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ - 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/
Re: About Celeron processor memory barrier problem
On Sun, Dec 24, 2000 at 11:36:00AM +0200, Kai Henningsen wrote: [EMAIL PROTECTED] (Linus Torvalds) wrote on 23.12.00 in [EMAIL PROTECTED]: On Thu, 23 Dec 1999, michael chen wrote: I found that when I compiled the 2.4 kernel with the option of Pentium III or Pentium 4 on a Celeron's PC, it could cause the system hang at very beginning boot stage, and I found the problem is cause by the fact that Intel Celeron doesn't have a real memory barrier,but when you choose the Pentium III option, the kernel assume the processor has a real memory barrier. Here is a patch to fix it: No. The fix is to not lie to the configurator. A Celeron isn't a PIII, and you shouldn't tell the configure that it is. The whole point of being able to choose the CPU to optimize for is that we can optimize things at compile-time. Which is all fine, but maybe the kernel really ought to detect that problem and complain at boot time? Or does that happen already? There was a similar thread to this recently. The issue is that if you choose the wrong processor type, you may not even be able to complain. This is a user issue. All the distributions of which I am aware boot happily on any x86 machine, because they build the kernel for the lowest common denominator. Some detect the CPU type and install an appropriate kernel subsequently. So... the only way you can get into this mess is if you build a kernel yourself and choose the wrong options. There are many ways of producing a non-bootable kernel. The expectation is that if you want to go off and build your own kernel, you need to know what you're doing :-) Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - 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/
Re: sparc 10 w/512 megs hangs during boot
On Sun, Dec 24, 2000 at 12:48:44PM -0800, Ron Calderon wrote: I just finished compiling 2.4.0-test5 and that worked fine with 512M ram. I'll start going thru the other kernels. It'll take me sometime since compileing takes a long time. I've not yet started active searching. However: - test5 is fine - test13-pre3 is not I don't know how fast your machine is, but we should coordinate out search... I'll try to build -test10final (with minimal config to only test boot) so that shouldn't take so very long... You should test sth around -test8... MfG, JBG -- Fehler eingestehen, Größe zeigen: Nehmt die Rechtschreibreform zurück!!! /* Jan-Benedict Glaw [EMAIL PROTECTED] -- +49-177-5601720 */ keyID=0x8399E1BB fingerprint=250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB "insmod vi.o and there we go..." (Alexander Viro on linux-kernel) PGP signature
[patch] support for FDC37N769 IRDA chip
Hello Dag, I discovered that my notebook supported FIR, but I didn't know the chip (and it was not documented). So I disassembled it completely and found an SMC FDC37N769 inside. It's now correctly detected with the following trivial patch against kernel 2.2.18 (the same entry should be added to findchip). Merry Christmas to you and all the folks on LKML, Willy irda-fdc37n769-2.2.18.diff
Re: [patch] support for FDC37N769 IRDA chip
G !
For Christmas, I'd like to get a new mailer which doesn't eat my patches :-)
here it is again, after cut'n'paste. Please apply by hand or "patch -l".
Cheers,
Willy
--- linux-2.2.18/drivers/net/irda/smc-ircc.cSat Jun 24 14:57:49 2000
+++ linux/drivers/net/irda/smc-ircc.c Sun Dec 24 21:30:17 2000
@@ -98,6 +98,7 @@
static smc_chip_t chips[] =
{
{ "FDC37C669", 0x55, 0x55, 0x0d, 0x04, ircc_probe_69 },
+ { "FDC37N769", 0x55, 0x55, 0x0d, 0x28, ircc_probe_69 },
{ "FDC37N869", 0x55, 0x00, 0x0d, 0x29, ircc_probe_69 },
{ "FDC37N958", 0x55, 0x55, 0x20, 0x09, ircc_probe_58 },
{ NULL }
-
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/
Re: About Celeron processor memory barrier problem
On Sun, 24 Dec 2000, Tim Wright wrote: Which is all fine, but maybe the kernel really ought to detect that problem and complain at boot time? Or does that happen already? There was a similar thread to this recently. The issue is that if you choose the wrong processor type, you may not even be able to complain. Indeed. Some of the issues end up just becoming compiler flags, which means that anything that uses C is "tainted" by the processor choice. And happily there isn't all that much non-C in the kernel any more. One thing we _could_ potentially do is to simplify the CPU selection a bit, and make it a two-stage process. Basically have a bool "Optimize for current CPU" CONFIG_CPU_CURRENT which most people who just want to get the best kernel would use. Less confusion that way. Linus - 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/
Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots
Hello Mike, hello linux-kernel hackers, Mike Galbraith wrote: Yes, hmm indeed. Try these two things. 1. make DECLARE_MUTEX_LOCKED(sem) in bdflush_init() static. 2. compile with frame pointers. (normal case for IKD) My IKD tree works with either option, but not with neither. I haven't figured out why yet. 1 worked for me, too - with the same effect as compiling buffer.c with 2.95.2, thus meaning successful boot and heavy crashing later on. I haven't tried to boot 2 yet, but this looks seriously fishy to me. It would be nice if we could make a simpler testcase to reproduce it, as it's much work to boot the kernel over and over again. I have now printed out the buffer.c:bdflush_init assembly for all four cases, 2.95.2, 2.97 without patch, 2.97 with static DECLARE... and 2.97 with frame pointer, and will try to figure out what's going wrong - it would still be nice to know if its a gcc problem or if some kernel assumption about GCC behaviour triggered this bug, which seems equally likely, as kernel_thread and the mutex/semaphore stuff involve some nontrivial (at least for beginners like me...) hand-made assembly code. A nice evening and still merry christmas to the people westward of Europe :-) Andreas -- Andreas Franck - --- [EMAIL PROTECTED] -- - Keep smiling! - - 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/
Re: innd mmap bug in 2.4.0-test12
Linus Torvalds [EMAIL PROTECTED] writes:
On Sun, 24 Dec 2000, Linus Torvalds wrote:
Marco, would you mind changing the test in reclaim_page(), somewheer
around line mm/vmscan.c:487 that says:
Speaking of page_launder() I just stumbled upon two oopsen today on
the UP build. Maybe it could give a hint to someone, I'm not that good
at Oops decoding.
Merry Christmas!
Unable to handle kernel NULL pointer dereference at virtual address 000c
printing eip:
c012872e
*pde =
Oops:
CPU:0
EIP:0010:[page_launder+510/2156]
EFLAGS: 00010202
eax: ebx: c12e2ce8 ecx: c1244474 edx:
esi: c12e2d04 edi: ebp: esp: c15d1fb4
ds: 0018 es: 0018 ss: 0018
Process bdflush (pid: 6, stackpage=c15d1000)
Stack: c15d c15d023a 0008e000 0001 2933
c0131e5d 0003 00010f00 c146ff88 c146ffc4 c01073fc
c146ffc4 0078 c146ffc4
Call Trace: [bdflush+141/236] [kernel_thread+40/56]
Code: 8b 40 0c 8b 00 85 c0 0f 84 ba 04 00 00 83 7c 24 10 00 75 73
Unable to handle kernel NULL pointer dereference at virtual address 000c
printing eip:
c012872e
*pde =
Oops:
CPU:0
EIP:0010:[page_launder+510/2156]
EFLAGS: 00010202
eax: ebx: c1260eec ecx: c15d5fe0 edx: c02917f0
esi: c1260f08 edi: ebp: esp: c15d5f9c
ds: 0018 es: 0018 ss: 0018
Process kswapd (pid: 4, stackpage=c15d5000)
Stack: 00010f00 0004 0004 2938
c01290fc 0004 00010f00 c01f77f7 c15d4239 0008e000
c01291c6 0004 c146ffb8 c01073fc 0078
Call Trace: [do_try_to_free_pages+52/128] [tvecs+8683/64084] [kswapd+126/288]
[kernel_thread+40/56]
Code: 8b 40 0c 8b 00 85 c0 0f 84 ba 04 00 00 83 7c 24 10 00 75 73
--
Zlatko
-
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/
css hang; somewhere between test12 and test13pre4ac2
Hi, Somewhere between test12 and test13pre4ac2 (sheesh the version numbers.) CSS on ATAPI DVD ROM drives has stopped working. Playing a CSS disc (using xine) causes a complete system hang (machine doesn't ping - sysrq-b still works) on test13pre4ac2. On test12 it is still OK. This is on an Alpha LX164. Dave -- Have a happy GNU millennium! -- / Dr. David Alan Gilbert | Running GNU/Linux on | Happy \ \ gro.gilbert @ treblig.org | Alpha, x86, ARM and SPARC | In Hex / \ ___|___ http://www.treblig.org |/ - 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/
Re: css hang; somewhere between test12 and test13pre4ac2
Works fine under test13-pre4 here on a x86 and an ATAPI Creative 2x dvd drive using xine or dxr2 player. Dave Gilbert wrote: Hi, Somewhere between test12 and test13pre4ac2 (sheesh the version numbers.) CSS on ATAPI DVD ROM drives has stopped working. Playing a CSS disc (using xine) causes a complete system hang (machine doesn't ping - sysrq-b still works) on test13pre4ac2. On test12 it is still OK. This is on an Alpha LX164. -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - 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/
Re: css hang; somewhere between test12 and test13pre4ac2
Actually... I just remembered that I have my kernel patched to bring it up-to-date with udf cvs. Dave Gilbert wrote: Hi, Somewhere between test12 and test13pre4ac2 (sheesh the version numbers.) CSS on ATAPI DVD ROM drives has stopped working. Playing a CSS disc (using xine) causes a complete system hang (machine doesn't ping - sysrq-b still works) on test13pre4ac2. On test12 it is still OK. This is on an Alpha LX164. -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - 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/
shmat returning NULL with 0 sized segment
Hi, I'm trying to debug a weird problem with Xine - its screwing up its use of shared memory for regions I haven't sussed yet. One odd consequence is that it has apparently successfully managed to allocate a 0 byte chunk of shared memory; shmat is then called with shmaddr=0 and shmflg=0; the result of shmat is 0 Is this what shmat is supposed to do in this (admittedly odd) circumstance? The error behaviour is defined in the man page as returning -1 on error. (Linux/Alpha 2.4.0-test8) Back to trying to find out why it decided to allocate a 0 byte chunk Dave -- Have a happy GNU millennium! -- / Dr. David Alan Gilbert | Running GNU/Linux on | Happy \ \ gro.gilbert @ treblig.org | Alpha, x86, ARM and SPARC | In Hex / \ ___|___ http://www.treblig.org |/ - 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/
Re: innd mmap bug in 2.4.0-test12
On Dec 24, Linus Torvalds [EMAIL PROTECTED] wrote:
/* The page is dirty, or locked, move to inactive_dirty list. */
if (page-buffers || TryLockPage(page)) {
...
and change the test to
if (page-buffers || PageDirty(page) || TryLockPage(page)) {
Done, no change.
Got some articles, restarted the server, all is good.
Got other articles, rebooted and the files now differ.
And I have another problem: I'm experiencing random hangs using X[1] with
2.4.0-test12. After a variable amount of time, some of the times I use X
(I mostly use console) it just freezes hard (no caps lock activity).
I'm not sure if this only happens while using X or it's just less
frequent in console. -test9 works fine and I used it since it has been
released with no ill effects.
My hardware:
00:00.0 Host bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3] (rev 04)
00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA [Apollo VP] (rev 41)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06)
00:07.3 Bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 10)
00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS)
01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G100 [Productiva] AGP
(rev 02)
vendor_id : AuthenticAMD
cpu family : 5
model : 8
model name : AMD-K6(tm) 3D processor
stepping: 12
cpu MHz : 267.282
cache size : 64 KB
gcc version 2.95.2 2220 (Debian GNU/Linux)
[1] Good old stable XF86_SVGA 3.x from debian potato.
--
ciao,
Marco
-
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/
Re: innd mmap bug in 2.4.0-test12
On 25 Dec 2000, Zlatko Calusic wrote: Linus Torvalds [EMAIL PROTECTED] writes: On Sun, 24 Dec 2000, Linus Torvalds wrote: Marco, would you mind changing the test in reclaim_page(), somewheer around line mm/vmscan.c:487 that says: Speaking of page_launder() I just stumbled upon two oopsen today on the UP build. Maybe it could give a hint to someone, I'm not that good at Oops decoding. Unable to handle kernel NULL pointer dereference at virtual address 000c printing eip: c012872e *pde = Oops: CPU:0 EIP:0010:[page_launder+510/2156] I suspected I'm not the only one who is getting these exact same Oopses (and the lockups that follow them) so earlier today, I've decoded the Oops I got, and found that the problem is in vmscan.c:line-605, where page-mapping is NULL and a_ops gets resolved and dereferenced at 0x000c. I leave the fix for the mm experts, I've notified Linus, I guess he's looking into it. -- Dan Aloni [EMAIL PROTECTED] - 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/
Re: About Celeron processor memory barrier problem
On Sun, Dec 24, 2000 at 02:25:54PM -0800, Linus Torvalds wrote: Indeed. Some of the issues end up just becoming compiler flags, which means that anything that uses C is "tainted" by the processor choice. And happily there isn't all that much non-C in the kernel any more. One thing we _could_ potentially do is to simplify the CPU selection a bit, and make it a two-stage process. Basically have a bool "Optimize for current CPU" CONFIG_CPU_CURRENT which most people who just want to get the best kernel would use. Less confusion that way. Linus Makes sense. Are you thinking along the lines of parsing /proc/cpuinfo to work out what is there, or did you have something else in mind ? Regards, Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - 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/
Re: innd mmap bug in 2.4.0-test12
Marco d'Itri wrote: And I have another problem: I'm experiencing random hangs using X[1] with 2.4.0-test12. After a variable amount of time, some of the times I use X (I mostly use console) it just freezes hard (no caps lock activity). I'm not sure if this only happens while using X or it's just less frequent in console. -test9 works fine and I used it since it has been released with no ill effects. This is probably the run_task_queue bug fixed in test13pre3. Augusto - 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/
Proposal: devfs names ending in %d or %u
It seems that just about everything that uses devfs
contains some logic that attempts to construct an unused
device name with something like:
static devnum = 0;
sprintf (name, "lp%d", devnum++);
devfs_register_device(..., name,...);
Besides duplicating a lot of logic, making devfs support
more of a pain to add and uglier to look at, the numbering behvior
of these drivers can be inconsistent, especially if some devices
are being removed. For example, as I insert and remove my PCMCIA
flash card, it becomes /dev/discs/disc1, /dev/discs/disc2,
/dev/discs/disc3, etc.
I propose to change the devfs registration functions
to allow registrations of devices ending in %d or %u, in which
case it will use the first value, starting at 0, that generates a
string that already registered. So, if I have disc0, disc1, and disc2,
and I remove the device containing disc1, then disc1 will be next
disc device name to be registered, then disc3, then disc4, etc.
Just to illustrate, I have attached a patch that should
do it for device files, but I also want to do this for symlinks and
possibly directories. So, I am not suggesting that anyone should
integrate this patch yet.
This will make it a bit simpler to add devfs support to
the remaining drivers that do not have it, and it will make
numbering within devfs much simpler by default. Of course, drivers
that want to do their own thing the current way would not be impeded
from doing so by this change.
Anyhow, I thought I should post this suggestion to see if
anyone has any objections, better ideas, improvements or comments.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
--- linux-2.4.0-test13-pre4/fs/devfs/base.c Fri Nov 17 11:36:27 2000
+++ linux/fs/devfs/base.c Sun Dec 10 13:50:29 2000
@@ -1238,6 +1253,7 @@
{
int is_new;
struct devfs_entry *de;
+int numeric_suffix;
if (name == NULL)
{
@@ -1292,8 +1308,16 @@
minor = next_devnum_block 0xff;
++next_devnum_block;
}
-de = search_for_entry (dir, name, strlen (name), TRUE, TRUE, is_new,
- FALSE);
+numeric_suffix = 0;
+do {
+ char realname[strlen(name)+11]; /* max 32-bit decimal integer is 10
+ characters, plus one for
+ terminating null. */
+ sprintf(realname, name, numeric_suffix);
+ numeric_suffix++;
+de = search_for_entry (dir, realname, strlen (realname), TRUE, TRUE,
+ is_new, FALSE);
+} while (!is_new de != NULL strcmp(name+strlen(name)-2, "%d") == 0);
if (de == NULL)
{
printk ("%s: devfs_register(): could not create entry: \"%s\"\n",
Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots
On Sun, 24 Dec 2000, Andreas Franck wrote:
Hello Mike, hello linux-kernel hackers,
Mike Galbraith wrote:
Yes, hmm indeed. Try these two things.
1. make DECLARE_MUTEX_LOCKED(sem) in bdflush_init() static.
2. compile with frame pointers. (normal case for IKD)
My IKD tree works with either option, but not with neither. I haven't
figured out why yet.
1 worked for me, too - with the same effect as compiling buffer.c with
2.95.2, thus meaning successful boot and heavy crashing later on.
I haven't tried to boot 2 yet, but this looks seriously fishy to me. It would
be nice if we could make a simpler testcase to reproduce it, as it's much
work to boot the kernel over and over again.
I wouldn't (not going to here;) spend a lot of time on it. The compiler
has problems. It won't build glibc-2.2, and chokes horribly on ipchains.
int ipt_register_table(struct ipt_table *table)
{
int ret;
struct ipt_table_info *newinfo;
static struct ipt_table_info bootstrap
= { 0, 0, { 0 }, { 0 }, { } };
^
ip_tables.c:1361: Internal compiler error in array_size_for_constructor, at
varasm.c:4456
-Mike
-
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/
Re: Proposal: devfs names ending in %d or %u
Eric Shattow wrote: [snip] when i insert a FAT formatted disc with a PC partition table, the partition i want to mount is part1. when i insert a HFS formatted disc with a MAC partition table, the partition i want to mount is part4. this is very ugly, and it has nothing to do with devfs. Those would be /dev/sda1 (adjust device name for IDE instead of SCSI, etc.) and /dev/sda4 without devfs. In this case, the problem is that different Zip disks really do have their data on different partitions. (If you use enough different disks and formatting utilities, it won't even be the same partition for all PC disks or all Mac disks, IIRC.) I don't use Zip disks much anymore, although there's a similar phenomenon with my SCSI MO drive on my desktop Mac (which I recently started using Linux on again). What would be nice is if there were a way of saying, "here's the disk, mount the Right Partition(tm) in /mnt/whatever." For all I know, maybe someone's done that already. If not, it seems to me that a userspace utility (== no extra kernel bloat) could parse the partition table and use some heuristics or something to pick the partition to mount. (I'm probably going to do other stuff instead of implementing this, but I haven't decided for sure yet.) In any case, I think the solution would be completely orthogonal to devfs... -Barry K. Nathan [EMAIL PROTECTED] - 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/
