Re: 2.2.16 SMP: mtrr errors

[Boszormenyi Zoltan]

On Tue, 12 Dec 2000, Petr Vandrovec wrote:
> That's wrong. They must first register MTRR and then split it to
> 24+8, as they cannot register 24MB range. They can split it
> 16+16, or (16+8)+8, but at cost of 1 (or 2) additional MTRR entries -
> and there is very limited number of possible MTRRs.
> 
> Matroxfb also splits Matrox memory in 24:8, but it registers only one
> region in mtrr. Of course, in X, as mtrr registration is done by map
> videomemory, you must tell this function to not register mtrr...
> 
> Best regards,
> Petr Vandrovec
> [EMAIL PROTECTED]

NOW, I am really convinced that we need PAT support on top
of the crappy MTRR driver. :-) I already started working on it...


Regards,
Zoltan Boszormenyi

-
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] I-Opener fix (again)

[Andre Hedrick]

Basically if the setting of 

 * "hdx=flash"  : allows for more than one ata_flash disk to be
 *  registered. In most cases, only one device
 *  will be present.

fails then I will look into this but, the breaking of laptops that have
CFA devices that do not come on channels in a pair canb not happen.
If you have a vender unique setting that will follow always the way
I-Opener's are setup then that is better.

Cheers,

On Mon, 11 Dec 2000 [EMAIL PROTECTED] wrote:

> It's been a few months (and a couple of kernel releases) since I mentioned this
> before and it doesn't look like it's made it in, and I haven't seen any more
> comments on it in the list archives, so I'm bringing it up again in case it
> just got forgotten about somewhere along the line..
> 
> As I remember, Andre Hedrick had asked for clarification on my original post,
> and I sent a followup message in response, but now I can't seem to find it
> anywhere in the archives, so I don't know whether it never made it out of my
> mailer or..
> 
> In any case, attached is a patch (against 2.4.0pre11) which fixes the bug which
> causes disk detection issues on I-Opener (and possibly other unusual) hardware.
> 
> The problem is that the code assumes that a flash-disk will always be the
> primary disk on an interface, but on the I-Opener this is not always the case.
> If a traditional disk is primary, and a flashdisk is secondary, the detection
> code (wrongly) disables the primary disk that it had already previously
> detected.
> 
> I would like to see this make it into the official source as it's a very small
> change that fixes some obviously wrong behavior..
> 
> -alex
> 

Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development

-
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/

17 month late patch for Linux v2.2.x

[John Fort]

Alan, this is identical to the patch that was in patch-2.3.10 of Jul 5 1999
except a line number difference of one.

It is only needed if you build your v2.2.x kernel for the Initio 1060p LVD
SCSI controller using a later compiler
than 2.7.2.3 and then are stupid enough to ignore any compiler warnings
about 'ambiguous else, suggest using braces'.

Harbison & Steele 2nd Ed, p202, under 'Dangling Else problem' also show the
misleading indentation.

This aggravation was prompted by trying to install RedHat 7.0 and Mandrake
7.2 to my SCSI disks last week.

In linux/drivers/scsi/i60uscsi.c:
Line 768:  add  ' {' at end of line
Line 771: replace 4th Tab with '} '
Line 772: delete 5th Tab.

I tried hand entering the patch into Outhouse Exploder 5.5 and conceeded.

cu  johnf


-
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/

/dev/cpu/*/(cpuid, msr) unhappy as modules - OOPS!

[Chris Rankin]

Hi,
I have just compiled Linux 2.2.18 (UP) and Linux 2.4.0-test12 (SMP,
devfs), and in each case I compiled the msr and cpuid drivers as
modules. However, when I tried to read from the devices (using "cat"),
I got oopses from both 2.2.18 and 2.4.0-test12. Neither the msr.o nor
the cpuid.o modules were loaded beforehand, as I was testing my kmod
setup. The oopses are below:

Linux-2.4.0-test12 (2 oopses):
$ ksymoops -m /boot/System.map-2.4.0-test12 < oops1.txt 
ksymoops 2.3.4 on i686 2.4.0-test12.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.0-test12/ (default)
 -m /boot/System.map-2.4.0-test12 (specified)

Dec 13 01:17:47 twopit kernel: Unable to handle kernel paging request at virtual 
address d084a540
Dec 13 01:17:47 twopit kernel: c0133d8a
Dec 13 01:17:47 twopit kernel: *pde = 0146b063
Dec 13 01:17:47 twopit kernel: Oops: 
Dec 13 01:17:47 twopit kernel: CPU:1
Dec 13 01:17:47 twopit kernel: EIP:0010:[get_chrfops+78/368]
Dec 13 01:17:47 twopit kernel: EFLAGS: 00010282
Dec 13 01:17:47 twopit kernel: eax: 0650   ebx: d084a540   ecx: c0215280   edx: 
c0268de4
Dec 13 01:17:47 twopit kernel: esi:    edi: 0650   ebp: 00ca   esp: 
cb505ee8
Dec 13 01:17:47 twopit kernel: ds: 0018   es: 0018   ss: 0018
Dec 13 01:17:47 twopit kernel: Process cat (pid: 1681, stackpage=cb505000)
Dec 13 01:17:47 twopit kernel: Stack: cf41e140 cccfef60 ffed cb998580 c0215280 
c02158b8 cbcd7840  
Dec 13 01:17:47 twopit kernel:c013ed99 c999ca60 c013403a 00ca 0001 
cf41e140 ffed cf41e144 
Dec 13 01:17:47 twopit kernel:cb998580 c015b5d1 cb998580 cccfef60 cccfef60 
cb998580 ffe9 c14fa240 
Dec 13 01:17:47 twopit kernel: Call Trace: [path_walk+1997/2196] [chrdev_open+38/172] 
[devfs_open+277/500] [dentry_open+189/332] [filp_open+82/92] [sys_open+60/240] 
[system_call+51/56] 
Dec 13 01:17:47 twopit kernel: Code: 8b 03 85 c0 74 10 50 e8 62 8b fe ff 83 c4 04 85 
c0 74 09 8d 
Using defaults from ksymoops -t elf32-i386 -a i386

Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   8b 03 mov(%ebx),%eax
Code;  0002 Before first symbol
   2:   85 c0 test   %eax,%eax
Code;  0004 Before first symbol
   4:   74 10 je 16 <_EIP+0x16> 0016 Before first symbol
Code;  0006 Before first symbol
   6:   50push   %eax
Code;  0007 Before first symbol
   7:   e8 62 8b fe ffcall   fffe8b6e <_EIP+0xfffe8b6e> fffe8b6e 

Code;  000c Before first symbol
   c:   83 c4 04  add$0x4,%esp
Code;  000f Before first symbol
   f:   85 c0 test   %eax,%eax
Code;  0011 Before first symbol
  11:   74 09 je 1c <_EIP+0x1c> 001c Before first symbol
Code;  0013 Before first symbol
  13:   8d 00 lea(%eax),%eax

$ ksymoops -m /boot/System.map-2.4.0-test12 < oops2.txt 
ksymoops 2.3.4 on i686 2.4.0-test12.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.0-test12/ (default)
 -m /boot/System.map-2.4.0-test12 (specified)

Dec 13 01:20:02 twopit kernel: Unable to handle kernel paging request at virtual 
address d084a540
Dec 13 01:20:02 twopit kernel: c0133d8a
Dec 13 01:20:02 twopit kernel: *pde = 0146b063
Dec 13 01:20:02 twopit kernel: Oops: 
Dec 13 01:20:02 twopit kernel: CPU:0
Dec 13 01:20:02 twopit kernel: EIP:0010:[get_chrfops+78/368]
Dec 13 01:20:02 twopit kernel: EFLAGS: 00010282
Dec 13 01:20:02 twopit kernel: eax: 0650   ebx: d084a540   ecx: c0215280   edx: 
c0268de4
Dec 13 01:20:02 twopit kernel: esi:    edi: 0650   ebp: 00ca   esp: 
cb52bee8
Dec 13 01:20:02 twopit kernel: ds: 0018   es: 0018   ss: 0018
Dec 13 01:20:02 twopit kernel: Process cat (pid: 1691, stackpage=cb52b000)
Dec 13 01:20:02 twopit kernel: Stack: cf41e140 cc605bc0 ffed cb998580 c0215280 
c02158b8 cbcd7840  
Dec 13 01:20:02 twopit kernel:c013ed99 c999ca60 c013403a 00ca 0001 
cf41e140 ffed cf41e144 
Dec 13 01:20:02 twopit kernel:cb998580 c015b5d1 cb998580 cc605bc0 cc605bc0 
cb998580 ffe9 c14fa240 
Dec 13 01:20:02 twopit kernel: Call Trace: [path_walk+1997/2196] [chrdev_open+38/172] 
[devfs_open+277/500] [dentry_open+189/332] [filp_open+82/92] [sys_open+60/240] 
[system_call+51/56] 
Dec 13 01:20:02 twopit kernel: Code: 8b 03 85 c0 74 10 50 e8 62 8b fe ff 83 c4 04 85 
c0 74 09 8d 
Using defaults from ksymoops -t elf32-i386 -a i386

Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   8b 03 mov(%ebx),%eax
Code;  0002 Before first symbol
   2:   85 c0 test   %eax,%eax
Code;  0004 Before first symbol
   4:   74 10 je 16 <_EIP+0x16> 

Re: USB mass storage backport status?

[Frédéric L . W . Meunier]

On Tue, Dec 12, 2000 at 08:08:40PM -0800, Matthew Dharm wrote:
> Depending on the type of device you have and how you use it, it can either:
> (1) Work properly
> (2) Corrupt your data
> (3) Crash the driver
> (4) Crash your system

The reboot was about Iomega's Zip Drive under 2.2.18pre21:

http://slashdot.org/comments.pl?sid=00/12/11/2355217=0=1=thread=110
 
> It's allready labeled EXPERIMENTAL.  Perhaps it should be labeled
> DANGEROUS, also, but how many labels can you put on things to warn people
> off?

Hmm, where? I don't see an (EXPERIMENTAL) in
Documentation/Configure.help:

USB Mass Storage support
CONFIG_USB_STORAGE
Say Y here if you want to connect USB mass storage devices to your
computer's USB port.

This code is also available as a module ( = code which can be
inserted in and removed from the running kernel whenever you want).
The module will be called usb-storage.o. If you want to compile it
as a module, say M here and read Documentation/modules.txt.

USB Mass Storage verbose debug
CONFIG_USB_STORAGE_DEBUG
Say Y here in order to have the USB Mass Storage code generate
verbose debugging messages.

Maybe it's only enabled when you set CONFIG_EXPERIMENTAL? I don't know, because I 
enabled
it to just set CONFIG_FB.

> On Wed, Dec 13, 2000 at 01:41:54AM -0200, Frédéric L . W . Meunier wrote:
> > What's the real status of the mass storage backport to 2.2.18?
> > Some people report it can corrupt your data, another that it
> > rebooted his computer while doing a large trasnfer, and so on.
> > 
> > If it's not good, shouldn't it be removed or labeled
> > DANGEROUS? BTW, where can I see a list of what's backported
> > and working without major problems?

-- 
0@pervalidus.{net,{dyndns.}org} TelFax: 55-21-717-2399 (Niterói-RJ BR)
-
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/

wake_up and wait_event

[Sourav Ghosh]

Hi,
I have two questions:

1. Is it ok to make a "wake_up_process()" call from an interrupt
handler?

In my work, there is a kernel thread that sleeps under "sleep_on()" and
wakes up by the "wake_up_process()" by an interrupt handler.

My system is crashing and I just wanna make sure if this is not a
problem..

2. For the macros  __wait_event() and __wait_event_interruptible(), it
seems to me that they can't be called from a kernel thread as they set
the task "current" as "TASK_UNINTERRUPTIBLE" due to which it gets
removed from the scheduler runqueue. So the scheduler never chooses that
task again even if the task gets set as "TASK_RUNNING" at the end of the
macro.

Is that correct? If so, how is it possible to add the task to the
runqueue again (other than defining another new macro or function) ?

Thanks,

--
Sourav



-
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/

test12: innd bug came back?

[Anton Petrusevich]

Hi folks.

Today I saw well-known "innd bug"(truncate(tm)), and my brother said
he had seen it with -test12-pre7. I don't know about -test12-pre3,
neither I nor my brother hadn't noticed it since -test10. But we could
miss it with -test12-pre3, and I didn't try any -test11 kernels. Thus
possibly that was introduced changes between -test12-pre3 and
-test12-pre7, but I can definitly say it present in -test12-final.

Another truncate(tm)?
--
Anton
-
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: Signal 11 - the continuing saga

[Mike Galbraith]

On Wed, 13 Dec 2000, Rainer Mager wrote:

> Thanks for the info...
> 
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff V. Merkey
> > >   So, is this related to the larger signal 11 problems?
> >
> > There's a corruption bug in the page cache somewhere, and it's 100%
> > reproducable.  Finding it will be tough
> 
> Ok, granted this will be tough but is anyone even actively working on it?
> What can I do to help?

If you want, I can extract IKD.. which happens to have a trap in place
for this (because I have a 100% reproducable swap related SIGSEGV that
I'm trying to figure out). 

If you're interested, let me know and I'll extract it (quite large) and
send it along instructions on how to do the trap.

-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: USB mass storage backport status?

[Matthew Dharm]

Depending on the type of device you have and how you use it, it can either:
(1) Work properly
(2) Corrupt your data
(3) Crash the driver
(4) Crash your system

It's allready labeled EXPERIMENTAL.  Perhaps it should be labeled
DANGEROUS, also, but how many labels can you put on things to warn people
off?

Matt Dharm

On Wed, Dec 13, 2000 at 01:41:54AM -0200, Frédéric L . W . Meunier wrote:
> What's the real status of the mass storage backport to 2.2.18?
> Some people report it can corrupt your data, another that it
> rebooted his computer while doing a large trasnfer, and so on.
> 
> If it's not good, shouldn't it be removed or labeled
> DANGEROUS? BTW, where can I see a list of what's backported
> and working without major problems?
> 
> -- 
> 0@pervalidus.{net,{dyndns.}org} TelFax: 55-21-717-2399 (Niterói-RJ BR)
> -
> 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/

-- 
Matthew Dharm  Home: [EMAIL PROTECTED] 
Maintainer, Linux USB Mass Storage Driver

Umm, these aren't the droids you're looking for.
-- Bill Gates
User Friendly, 11/14/1998

 PGP signature

Re: 2.2.18pre21 oops reading /proc/apm

[Neale Banks]

On Wed, 13 Dec 2000, Alan Cox wrote:

> > (3) modifies the output of /proc/apm when power status reporting is
> > disabled - on reflection, maybe this wasn't such a smart thing to do
> > (could royally stuff anybody who is automagically parsing /proc/apm?)
> 
> Please dont - it correctly reports 'dunno' right now

OK, (yet another) diff attached, against 2.2.18.

Neale.


diff -ur -x .config linux-2.2.18-orig/Documentation/Configure.help 
linux-2.2.18/Documentation/Configure.help
--- linux-2.2.18-orig/Documentation/Configure.help  Mon Dec 11 11:49:41 2000
+++ linux-2.2.18/Documentation/Configure.help   Wed Dec 13 13:36:54 2000
@@ -10298,6 +10298,18 @@
   a work-around for a number of buggy BIOSes. Switch this option on if
   your computer crashes instead of powering off properly.
 
+Buggy battery status reporting
+CONFIG_APM_ASHES_NOTEBIOS
+  Currently disables power status reporting - for buggy BIOS which
+  (a) oopses on reading from /proc/apm and (b) does NOT have DMI.
+  (AcerNote-950 with Phoenix NoteBIOS 1994).
+  In future, this setting might invoke a bug-workaround.
+  
+  Note that if the machine has DMI then the BIOS version should be
+  automagically detectable and this workaround automated.  Send the DMI
+  strings printed at boot-time with any report if this is not happening
+  (or try patching arch/i386/kernel/dmi_scan.c).
+
 Watchdog Timer Support 
 CONFIG_WATCHDOG
   If you say Y here (and to one of the following options) and create a
diff -ur -x .config linux-2.2.18-orig/arch/i386/config.in 
linux-2.2.18/arch/i386/config.in
--- linux-2.2.18-orig/arch/i386/config.in   Mon Dec 11 11:49:41 2000
+++ linux-2.2.18/arch/i386/config.inWed Dec 13 13:36:54 2000
@@ -116,6 +116,7 @@
   bool '   RTC stores time in GMT' CONFIG_APM_RTC_IS_GMT
   bool '   Allow interrupts during APM BIOS calls' CONFIG_APM_ALLOW_INTS
   bool '   Use real mode APM BIOS call to power off' CONFIG_APM_REAL_MODE_POWER_OFF
+  bool '   Buggy power status reporting' CONFIG_APM_ASHES_NOTEBIOS
 fi
 tristate 'Toshiba Laptop support' CONFIG_TOSHIBA
 
diff -ur -x .config linux-2.2.18-orig/arch/i386/kernel/apm.c 
linux-2.2.18/arch/i386/kernel/apm.c
--- linux-2.2.18-orig/arch/i386/kernel/apm.cMon Dec 11 11:49:41 2000
+++ linux-2.2.18/arch/i386/kernel/apm.c Wed Dec 13 13:40:23 2000
@@ -130,6 +130,9 @@
  * is now the way life works). 
  * Fix thinko in suspend() (wrong return).
  *   1.13ac: Added apm_battery_horked() for Compal boards (Dell 5000e etc)
+ *   1.13ac-nb: WIP: AcerNote-950 oops on reading /proc/apm
+ * Try disabling power status reporting.
+ * Neale Banks <[EMAIL PROTECTED]>
  *
  * APM 1.1 Reference:
  *
@@ -211,6 +214,8 @@
  * P: Toshiba 1950S: battery life information only gets updated after resume
  * P: Midwest Micro Soundbook Elite DX2/66 monochrome: screen blanking
  * broken in BIOS [Reported by Garst R. Reese <[EMAIL PROTECTED]>]
+ * ?: AcerNote-950: oops on reading /proc/apm - workaround is a WIP
+ * Neale Banks <[EMAIL PROTECTED]> December 2000
  *
  * Legend: U = unusable with APM patches
  * P = partially usable with APM patches
@@ -327,6 +332,11 @@
 static int power_off_enabled = 1;
 #endif
 static int dell_crap = 0;  /*Set if we find a 5000e */
+#ifdef CONFIG_APM_ASHES_NOTEBIOS
+static int ashes_notebios = 1; /*Set by configure*/
+#else
+static int ashes_notebios = 0; /* Default to OK */
+#endif
 
 static DECLARE_WAIT_QUEUE_HEAD(apm_waitqueue);
 static DECLARE_WAIT_QUEUE_HEAD(apm_suspend_waitqueue);
@@ -658,6 +668,14 @@
u32 edx;
u32 dummy;
 
+   /* Catch cases of known buggy BIOSen */
+   if (dell_crap || ashes_notebios) {
+   *status = *bat = *life = 0x;
+   /* not sure of the _best_ code to return here.
+  For now, APM_DISABLED will have to do  */
+   return APM_DISABLED;
+   }
+
if (apm_bios_call(APM_FUNC_GET_STATUS, APM_DEVICE_ALL, 0,
, , , , ))
return (eax >> 8) & 0xff;
@@ -1272,7 +1290,7 @@
 
p = buf;
 
-   if ((smp_num_cpus == 1) && (!dell_crap) && 
+   if ((smp_num_cpus == 1) &&
!(error = apm_get_power_status(, , ))) {
ac_line_status = (bx >> 8) & 0xff;
battery_status = bx & 0xff;
@@ -1492,6 +1510,9 @@
(apm_bios_info.version & 0xff),
apm_bios_info.flags,
driver_version);
+   if (dell_crap || ashes_notebios) {
+   printk(KERN_INFO "apm: power status reporting disabled\n");
+   }
if ((apm_bios_info.flags & APM_32_BIT_SUPPORT) == 0) {
printk(KERN_INFO "apm: no 32 bit BIOS support\n");
return -ENODEV;

USB mass storage backport status?

[Frédéric L . W . Meunier]

What's the real status of the mass storage backport to 2.2.18?
Some people report it can corrupt your data, another that it
rebooted his computer while doing a large trasnfer, and so on.

If it's not good, shouldn't it be removed or labeled
DANGEROUS? BTW, where can I see a list of what's backported
and working without major problems?

-- 
0@pervalidus.{net,{dyndns.}org} TelFax: 55-21-717-2399 (Niterói-RJ BR)
-
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: Signal 11 - the continuing saga

[Linus Torvalds]

In article <[EMAIL PROTECTED]>,
Jeff V. Merkey <[EMAIL PROTECTED]> wrote:
>On Wed, Dec 13, 2000 at 09:22:55AM +0900, Rainer Mager wrote:
>>  I have a tiny bash script that launches a Java swing app. If I run my
>> script from an xterm (or gnome-terminal or whatever) then it starts up fine.
>> If, however, I try to launch it from my gnome taskbar's menu then it dies
>> with signal 11 (the Java log is available upon request). This seems to be
>> 100% consistent, since I noticed it yesterday, even across reboots.
>> Interestingly, the same behavior occurs if I try to run the program from
>> withis JBuilder 4.
>>  So, is this related to the larger signal 11 problems?
>
>There's a corruption bug in the page cache somewhere, and it's 100%
>reproducable.  Finding it will be tough

Unlikely. If the actual program data was corrupted, it would SIGSEGV
regardless of how it's executed.

I'd guess that the program has a bug, and depending on the arguments and
environment (especially the latter will be different), it shows up or
not. Things like not having a LOCALE set in either case or similar.

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: [BUG] raid5 crash with 2.4.0-test12 [Was: Linux-2.4.0-test12]

[Linus Torvalds]

On Wed, 13 Dec 2000, Neil Brown wrote:
> 
> Yes... you are right.  Alright, I can't escape it any other way so I
> guess I must admit that  it is a raid5 bug.
> 
> But how can raid5 be calling b_end_io on a buffer_head that was never
> passed to generic_make_request?
> Answer, it snoops on the buffer cache to try to do complete stripe
> writes.

Ahh, yes. It seems to just do a "get_hash_table()", and put that bh into
the queues. Bad.

> The following patch disabled that code.

If this fix makes the oops go away, then the proper fix for the problem is
not the #if 0, but do add something like

bh->b_end_io = buffer_end_io_sync;

to just before the "add_stripe_bh(sh, bh, i, WRITE);"

We've already locked the thing, so that should be ok.

I wonder about that "md_test_and_set_bit(BH_Lock ...);" thing there,
though. If the buffer we find was dirty but already locked, we won't be
using that buffer at all (because the md_test_and_set_bit() will fail),
which probably means that the RAID5 checksum won't be right. Hmm..

Why is there an dirty aliased buffer head anyway? That sounds like a
recipe for disaster - maybe we should have synched all the stripe devices
before we set up the raid? Is that a raid5 rebuild issue? What's going on
here?

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/

via82cxxx_audio - bad latency

[Paul Jakma]

hi,

i think somethings gone wrong with via82cxxx_audio. Playing anything
through it seems to cause massive latency in apps like xmms, esd,
asmixer, etc.. anything to do with playing or mixer levels suddenly
takes a minute or more to respond.

It didn't always do this, and when it started happening i assumed it
was either something bad in esd or xmms (which i tend to upgrade a
lot). However it still happens when esd is disabled. eg, i use mpg123
to play an mp3 file, and asmixer doesn't change the volume till a
minute or two after i moused it.

if i SIGSTOP mpg123, asmixer immediately becomes responsive again and
implements the pending volume change, as soon i SIGCONT mpg123,
asmixer becomes very unresponsive again.

same thing with esd, if i STOP mpg123, other apps like esd and
non-esd mixers become responsive, soon as i start playing again they
go unresponsive.

same thing with playing from esd applications, everything inlcuding
the playing app itself (eg xmms) is unresponsive, if i STOP it, the
mixers instantly become responsive, soon as i CONT the playing app
everything is "dead" again.

kernel is test12-final. AMD K7, Asus K7M board

[root@fogarty /root]# lspci -vv -s 00:04.5
00:04.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686
[Apollo Super AC97/Audio] (rev 21)
Subsystem: Asustek Computer, Inc.: Unknown device 800d
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- SERR- http://www.clubi.ie/jakma/publickey.txt
---
Fortune:
And they shall beat their swords into plowshares, for if you hit a man
with a plowshare, he's going to know he's been hit.

-
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: National Semiconductor DP83815 ethernet driver?

[root]

>From searching Google, I know some sort of driver exists. In July, Adam J.
>Richter ([EMAIL PROTECTED]) posted a 2.2.16 driver he obtained from Dave
>Gotwisner at Wyse Technologies. And Tim Hockin mentioned that he was using
>an NSC driver, but had made some minor modifications.

This one has a very murky past. Adam & I have both received the same
driver from within NatSemi, which turned out to be a rehash of the
driver originally written by Donald Becker (with his name and the GPL
license removed...). It should be noted that this wasn't "written" by
NatSemi themselves, but by a company called TeamF1.

Since then Donald's original driver (natsemi.c) has been folded into the
2.4 kernel, and I can happily report works well with 2.2 as well. It's
certainly a lot better than the dp83815.c program, which I found had
the tendency to hang the machine completely in high traffic (well, if
you count ftping from a host on the same 10Mb half duplex network as
high load ;).

john

-
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: 2.2.18pre21 oops reading /proc/apm

[Alan Cox]

> (3) modifies the output of /proc/apm when power status reporting is
> disabled - on reflection, maybe this wasn't such a smart thing to do
> (could royally stuff anybody who is automagically parsing /proc/apm?)

Please dont - it correctly reports 'dunno' right now

-
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: 2.2.16 SMP: mtrr errors

[David Wragg]

" Paul C. Nendick " <[EMAIL PROTECTED]> writes:
> Shall I submit this to Matrox as a bug then?

The "bug" is in the XFree86 core, so telling Matrox might not do a lot
of good.

The driver code just says "I want to map a framebuffer of this size at
this physical address" (or actually "with these PCI details"), and the
core code arranges the mapping, doing the MTRR stuff while it's at it.

David Wragg

-
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: National Semiconductor DP83815 ethernet driver?

[Tim Hockin]

> >From searching Google, I know some sort of driver exists. In July, Adam J.
> Richter ([EMAIL PROTECTED]) posted a 2.2.16 driver he obtained from Dave
> Gotwisner at Wyse Technologies. And Tim Hockin mentioned that he was using
> an NSC driver, but had made some minor modifications.

We're still using a heavily hacked version of the NSC driver on 2.2.x.
When we do 2.4.x, I'll examine the other driver more closely.  I can send
you my hacks on the NSC version, if you need.
-
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: Signal 11 - the continuing saga

[Rainer Mager]

Thanks for the info...

> [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff V. Merkey
> > So, is this related to the larger signal 11 problems?
>
> There's a corruption bug in the page cache somewhere, and it's 100%
> reproducable.  Finding it will be tough

Ok, granted this will be tough but is anyone even actively working on it?
What can I do to help?



> > Anyone know how to do [disable L1 and L2 caches]?
>
> Usually this is performed in the BIOS setup.  You can also disable L1
> with a sequence of instructions that write to the CR0 register on intel
> and flip a bit, but in doing this you have to execute a WBINV (write
> back invalidate) instruction to flush out the cache.  BIOS setup is
> probably simpler.  Disabling Level I will make the machine slower
> than mollasses, BTW, and if this bug is race related (they always
> are) it won't help much in running it down.

Aha, just as I suspected. My BIOS doesn't appear to support this. You seem
to be saying that doing so won't really contribute anything anyway so I will
hold off for now.



--Rainer

-
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: 2.2.18pre21 oops reading /proc/apm

[Neale Banks]

On Tue, 12 Dec 2000, Neale Banks wrote:

[...]
> New diff to follow, hopefully tomorrow.

New diff against unmolested 2.2.18pre24 (appears to apply cleanly to
2.2.18 also) is attached.

Main points:

(1) adds a configure item for buggy BIOS (i.e. that can't be automagically
detected).

(2) catches the case of booting with boot-parameter apm=debug (previously
this could cause a fatal oops during the boot)

(3) modifies the output of /proc/apm when power status reporting is
disabled - on reflection, maybe this wasn't such a smart thing to do
(could royally stuff anybody who is automagically parsing /proc/apm?)

Neale.


diff -ur -x *.ntb? -x .config linux-2.2.18pre24-orig/Documentation/Configure.help 
linux-2.2.18pre24/Documentation/Configure.help
--- linux-2.2.18pre24-orig/Documentation/Configure.help Tue Dec 12 11:39:51 2000
+++ linux-2.2.18pre24/Documentation/Configure.help  Wed Dec 13 09:34:56 2000
@@ -10295,6 +10295,18 @@
   a work-around for a number of buggy BIOSes. Switch this option on if
   your computer crashes instead of powering off properly.
 
+Buggy battery status reporting
+CONFIG_APM_ASHES_NOTEBIOS
+  Currently disables power status reporting - for buggy BIOS which
+  (a) oopses on reading from /proc/apm and (b) does NOT have DMI.
+  (AcerNote-950 with Phoenix NoteBIOS 1994).
+  In future, this setting might invoke a bug-workaround.
+  
+  Note that if the machine has DMI then the BIOS version should be
+  automagically detectable and this workaround automated.  Send the DMI
+  strings printed at boot-time with any report if this is not happening
+  (or try patching arch/i386/kernel/dmi_scan.c).
+
 Watchdog Timer Support 
 CONFIG_WATCHDOG
   If you say Y here (and to one of the following options) and create a
diff -ur -x *.ntb? -x .config linux-2.2.18pre24-orig/arch/i386/config.in 
linux-2.2.18pre24/arch/i386/config.in
--- linux-2.2.18pre24-orig/arch/i386/config.in  Tue Dec 12 11:39:54 2000
+++ linux-2.2.18pre24/arch/i386/config.in   Wed Dec 13 09:35:21 2000
@@ -116,6 +116,7 @@
   bool '   RTC stores time in GMT' CONFIG_APM_RTC_IS_GMT
   bool '   Allow interrupts during APM BIOS calls' CONFIG_APM_ALLOW_INTS
   bool '   Use real mode APM BIOS call to power off' CONFIG_APM_REAL_MODE_POWER_OFF
+  bool '   Buggy power status reporting' CONFIG_APM_ASHES_NOTEBIOS
 fi
 tristate 'Toshiba Laptop support' CONFIG_TOSHIBA
 
diff -ur -x *.ntb? -x .config linux-2.2.18pre24-orig/arch/i386/kernel/apm.c 
linux-2.2.18pre24/arch/i386/kernel/apm.c
--- linux-2.2.18pre24-orig/arch/i386/kernel/apm.c   Tue Dec 12 11:39:54 2000
+++ linux-2.2.18pre24/arch/i386/kernel/apm.cWed Dec 13 10:32:55 2000
@@ -130,6 +130,9 @@
  * is now the way life works). 
  * Fix thinko in suspend() (wrong return).
  *   1.13ac: Added apm_battery_horked() for Compal boards (Dell 5000e etc)
+ *   1.13ac-nb: WIP: AcerNote-950 oops on reading /proc/apm
+ * Try disabling power status reporting.
+ * Neale Banks <[EMAIL PROTECTED]>
  *
  * APM 1.1 Reference:
  *
@@ -211,6 +214,8 @@
  * P: Toshiba 1950S: battery life information only gets updated after resume
  * P: Midwest Micro Soundbook Elite DX2/66 monochrome: screen blanking
  * broken in BIOS [Reported by Garst R. Reese <[EMAIL PROTECTED]>]
+ * ?: AcerNote-950: oops on reading /proc/apm - workaround is a WIP
+ * Neale Banks <[EMAIL PROTECTED]> December 2000
  *
  * Legend: U = unusable with APM patches
  * P = partially usable with APM patches
@@ -327,6 +332,11 @@
 static int power_off_enabled = 1;
 #endif
 static int dell_crap = 0;  /*Set if we find a 5000e */
+#ifdef CONFIG_APM_ASHES_NOTEBIOS
+static int ashes_notebios = 1; /*Set by configure*/
+#else
+static int ashes_notebios = 0; /* Default to OK */
+#endif
 
 static DECLARE_WAIT_QUEUE_HEAD(apm_waitqueue);
 static DECLARE_WAIT_QUEUE_HEAD(apm_suspend_waitqueue);
@@ -658,6 +668,14 @@
u32 edx;
u32 dummy;
 
+   /* Catch cases of known buggy BIOSen */
+   if (dell_crap || ashes_notebios) {
+   *status = *bat = *life = 0x;
+   /* not sure of the _best_ code to return here.
+  For now, APM_DISABLED will have to do  */
+   return APM_DISABLED;
+   }
+
if (apm_bios_call(APM_FUNC_GET_STATUS, APM_DEVICE_ALL, 0,
, , , , ))
return (eax >> 8) & 0xff;
@@ -1272,7 +1290,7 @@
 
p = buf;
 
-   if ((smp_num_cpus == 1) && (!dell_crap) && 
+   if ((smp_num_cpus == 1) &&
!(error = apm_get_power_status(, , ))) {
ac_line_status = (bx >> 8) & 0xff;
battery_status = bx & 0xff;
@@ -1325,7 +1343,9 @@
  -1: Unknown
   8) min = minutes; sec = seconds */
 
-   p += sprintf(p, "%s %d.%d 0x%02x 0x%02x 

Re: Linux 2.2.18 release notes

[Mark Hahn]

> > - metrics -- L1 cacheline size is the important one: you align array
...
> Anyone can give me some pointers on how this is done runtime ? (name of
> the .c file is fine).

kernel/sched.c:aligned_data.  as mentioned elsewhere, 
the correct alignment is not necessarily L1 linesize.

-
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: All INNOMINATE linux-list feeds are now killed...

[Matti Aarnio]

On Wed, Dec 13, 2000 at 02:09:31AM +0100, Marco d'Itri wrote:
> On Dec 06, Rik van Riel <[EMAIL PROTECTED]> wrote:
>  >> We deeply regret this and apologize honestly, but also would
>  >> like to resubscribe...
>  >Could you make it a one-way list this time?
>
> If vger postmasters do not mind, next week I'm going to unidirectinally
> gate linux-kernel (and maybe other high traffic vger lists, any
> suggestions?) to a group in the linux.* hierarchy[1].

You are welcome to do that.

It is just the BI-directional gatewaying we are opposing
for well observed reasons...  (People are doing bidirectional
gateways regardless of our opposition -- "we are good, we
won't do it wrong", but when things irregardless do go wrong,
we have to do some drastic measures to cut the loops.)

> [1] http://www.linux.it/~md/linux-faq
> -- 
> ciao,
> Marco

/Matti Aarnio
-
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: Possible patch for reiserfs-3.6.22 against 2.4.0-test12

[Adam Sampson]

Steven Cole <[EMAIL PROTECTED]> writes:

> Your patch will probably let journal.c get compiled, but it might be
> dangerous to use considering what Chris said.

I've just tried it and got filesystem corruption, so no, it doesn't
work. I'll wait for someone else to provide a patch that works.

-- 

Adam Sampson
[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: Signal 11 - the continuing saga

[Jeff V. Merkey]

On Wed, Dec 13, 2000 at 09:22:55AM +0900, Rainer Mager wrote:
> Hi again,
> 
>   Ok, I just upgraded to 2.4.0test12 (although I don't think there was any
> work in 12 that directly addresses this signal 11 problem). When compiling
> the new kernel I chose to disable AGPGart and RDM as suggested by
> [EMAIL PROTECTED] I will report later if this makes any difference.
> 
>   On another, possibly related note, I'm getting some really weird behavior
> with a Java program. The only reason I mention it here is because it dies
> with our old friend Signal 11. Anyway, please bear with the description
> below.
>   I have a tiny bash script that launches a Java swing app. If I run my
> script from an xterm (or gnome-terminal or whatever) then it starts up fine.
> If, however, I try to launch it from my gnome taskbar's menu then it dies
> with signal 11 (the Java log is available upon request). This seems to be
> 100% consistent, since I noticed it yesterday, even across reboots.
> Interestingly, the same behavior occurs if I try to run the program from
> withis JBuilder 4.
>   So, is this related to the larger signal 11 problems?

There's a corruption bug in the page cache somewhere, and it's 100%
reproducable.  Finding it will be tough

> 
> 
>   What else can I do regarding these issues to help fix it? Would a core dump
> help anyone? I'd really like to contribute somehow but I need some
> direction.
> 
> 
> --Rainer
> 
> > From: CMA [mailto:[EMAIL PROTECTED]]
> > Did you already try to selectively disable L1 and L2 caches (if
> > your box has both) and see what happens?
> 
> Anyone know how to do this?

Usually this is performed in the BIOS setup.  You can also disable L1 
with a sequence of instructions that write to the CR0 register on intel
and flip a bit, but in doing this you have to execute a WBINV (write
back invalidate) instruction to flush out the cache.  BIOS setup is
probably simpler.  Disabling Level I will make the machine slower 
than mollasses, BTW, and if this bug is race related (they always 
are) it won't help much in running it down.

Jeff

> 
> -
> 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/
-
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: Possible patch for reiserfs-3.6.22 against 2.4.0-test12

[Steven Cole]

Adam Sampson wrote:
>The latest reiserfs patch on ftp.namesys.com causes compilation errors
>against test12 due to the task queue changes. Does this look correct?
[patch snipped]
> 
>It does at least compile with these changes, but I haven't yet tested
>it. Looking at run_task_queue, it would appear that the while() is now
>redundant, but could someone who knows confirm/deny this?

Chris Mason is working on this.  In an earlier exchange on reiserfs-list:

Chris Mason wrote:
>I'll try to hack out a patch while I'm waiting, but the task struct changes
>are the least of our problems.  They've changed ll_rw_block to always set
>the end_io handler to the default one.  Since the journal code relies on
>being able to use its own end_io handler, this isn't good for us.  There is
>a new func we need to use instead, so I'm migrating over.
>
>Thew new stuff should be faster, so I won't complain ;-)

Your patch will probably let journal.c get compiled, but it might be dangerous
to use considering what Chris said.

Steven
-
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: All INNOMINATE linux-list feeds are now killed...

[Marco d'Itri]

On Dec 06, Rik van Riel <[EMAIL PROTECTED]> wrote:

 >> We deeply regret this and apologize honestly, but also would
 >> like to resubscribe...
 >Could you make it a one-way list this time?
If vger postmasters do not mind, next week I'm going to unidirectinally
gate linux-kernel (and maybe other high traffic vger lists, any
suggestions?) to a group in the linux.* hierarchy[1].

[1] http://www.linux.it/~md/linux-faq
-- 
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/

scsi_unregister_device

[skinbits]

Hello all,

As part of our final year project, we are implementing a network based on
SCSI to use as a cheap fast eth link. 

This module is made of two parts:

-sn: A scsi device that talk with the scsi mid layer
-scsinet: A network device driver that talks with sn.

We made a module based on code allready made for kernel 2.1.97, ported
it to 2.4.0test10, and put it as a module. The module allready loads,
both subsystems are initialized and the kernel dosen't crash :))

The problem happens when we try to load our module without a SCSI device
driver loaded (We use Symbios 53c8xx). When that happens, we register
sn with scsi_register_device, but when we try to init scsinet, it fails
(there are no devices to talk to, so it will fail). So, before our
module is unloaded, we try to unregister the sn device using
scsi_unregister_device. All is allright, the module get's out, but, the
usage count of the scsi_mod.o dosen't decrement. So it stays blocked in
the kernel and we can't unload it...

the relevant code is something like:

static int __init init_sc(void) 
{
int ret;

sn_template.module=THIS_MODULE;
if ((ret=scsi_register_module(MODULE_SCSI_DEV,_template))!=0)
return ret;

if ((ret=register_netdev(_template)!=0) 
{
scsi_unregister_module(MODULE_SCSI_DEV,_template);
sn_template.dev_max=0;
return ret;
}

return 0;
}

sn_template is the template for the scsi device, scsinet_template is the
template for a ehternet driver.

Anyone knows what we are doing wrong?

Pedro Semeano   
-
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: National Semiconductor DP83815 ethernet driver?

[Jeff Garzik]

Torrey Hoffman wrote:
> 
> I am wondering about the current status of a driver for the NS83815 ethernet
> chip.
> 
> >From searching Google, I know some sort of driver exists. In July, Adam J.
> Richter ([EMAIL PROTECTED]) posted a 2.2.16 driver he obtained from Dave
> Gotwisner at Wyse Technologies. And Tim Hockin mentioned that he was using
> an NSC driver, but had made some minor modifications.

Use drivers/net/natsemi.c...  it's in 2.4.x-test.

-- 
Jeff Garzik |
Building 1024   | These are not the J's you're lookin' for.
MandrakeSoft| It's an old Jedi mind trick.
-
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/

Possible patch for reiserfs-3.6.22 against 2.4.0-test12

[Adam Sampson]

Hiya.

The latest reiserfs patch on ftp.namesys.com causes compilation errors
against test12 due to the task queue changes. Does this look correct?

--- fs/reiserfs/journal.c.orig  Wed Dec 13 00:13:00 2000
+++ fs/reiserfs/journal.c   Wed Dec 13 00:40:52 2000
@@ -1762,7 +1762,7 @@
   ct->p_s_sb = p_s_sb ;
   ct->jindex = jindex ;
   ct->task_done = NULL ;
-  ct->task.next = NULL ;
+  INIT_LIST_HEAD(>task.list);
   ct->task.sync = 0 ;
   ct->task.routine = (void *)(void *)reiserfs_journal_commit_task_func ; 
   ct->self = ct ;
@@ -1813,7 +1813,7 @@
   lock_kernel() ;
   while(1) {
 
-while(reiserfs_commit_thread_tq) {
+while(TQ_ACTIVE(reiserfs_commit_thread_tq)) {
   run_task_queue(_commit_thread_tq) ;
 }
 
It does at least compile with these changes, but I haven't yet tested
it. Looking at run_task_queue, it would appear that the while() is now
redundant, but could someone who knows confirm/deny this?

-- 

Adam Sampson
[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: 2.2.18-25 DELL Laptop Video Problems

[Jeff V. Merkey]

On Wed, Dec 13, 2000 at 01:34:46AM +0100, Dominik Kubla wrote:
> On Mon, Dec 11, 2000 at 11:11:41AM -0700, Jeff V. Merkey wrote:
> ...
> > Then this is the vga=271 stuff?
> > 
> > Jeff 
> 
> No, that's just selecting the VGA resolution. I am referring to the
> video parameter:
> 
>   video=:[,,...]
> 
> Look at linux/Dokumentation/fb/modedb.txt.
> 
> Yours,
>   Dominik Kubla

Thanks!  I will.   I did have VESA FB enabled, BTW and I still see the 
problem.

:-)

Jeff


> -- 
> Drug misuse is not  a disease, it is a decision, like  the decision to step
> out in  front of a  moving car. You  would call that  not a disease  but an
> error of judgment.  --Philip K. Dick. Author's Note, A SCANNER DARKLY, 1977
-
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/

National Semiconductor DP83815 ethernet driver?

[Torrey Hoffman]

I am wondering about the current status of a driver for the NS83815 ethernet
chip.

>From searching Google, I know some sort of driver exists. In July, Adam J.
Richter ([EMAIL PROTECTED]) posted a 2.2.16 driver he obtained from Dave
Gotwisner at Wyse Technologies. And Tim Hockin mentioned that he was using
an NSC driver, but had made some minor modifications.

The only source I've seen is the one Mr. Richter posted.
(http://web.gnu.walfield.org/mail-archive/linux-kernel/2000-July/4234.html).

How well does this driver work?  From Mr. Richter's email I gather that Alan
Cox gave some feedback and suggested improvements.  This makes me worried
about using the "unimproved" version of the driver.

If anyone has improved code for the 2.2.x series I would greatly appreciate
it.

2.2.17 and 18 didn't include the driver. I also gather that Mr. Richter is
(or was) concentrating on a port to the 2.4 series, how is that coming
along? 

For what it's worth, the chip seems to have detailed documentation at
http://www.national.com/pf/DP/DP83815.html.

Thanks for any help.  

Torrey Hoffman
[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: 2.2.18 vs Inspiron

[James Simmons]

> There was some discusion lately re: Dell Inspiron FB probs. The bad news
> is the ATI Mach64 display support is still broken but just selecting
> VESA VGA graphics console is working fine. 
> 
> The patient is a Dell Inspiron I7500 1050x1450 display, vga = 794.

Ah the infamous Rage Mobility chipset. Three versions of the same chipset
but each is very different.

-
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: Signal 11 - the continuing saga

[Rainer Mager]

Hi again,

Ok, I just upgraded to 2.4.0test12 (although I don't think there was any
work in 12 that directly addresses this signal 11 problem). When compiling
the new kernel I chose to disable AGPGart and RDM as suggested by
[EMAIL PROTECTED] I will report later if this makes any difference.

On another, possibly related note, I'm getting some really weird behavior
with a Java program. The only reason I mention it here is because it dies
with our old friend Signal 11. Anyway, please bear with the description
below.
I have a tiny bash script that launches a Java swing app. If I run my
script from an xterm (or gnome-terminal or whatever) then it starts up fine.
If, however, I try to launch it from my gnome taskbar's menu then it dies
with signal 11 (the Java log is available upon request). This seems to be
100% consistent, since I noticed it yesterday, even across reboots.
Interestingly, the same behavior occurs if I try to run the program from
withis JBuilder 4.
So, is this related to the larger signal 11 problems?


What else can I do regarding these issues to help fix it? Would a core dump
help anyone? I'd really like to contribute somehow but I need some
direction.


--Rainer

> From: CMA [mailto:[EMAIL PROTECTED]]
> Did you already try to selectively disable L1 and L2 caches (if
> your box has both) and see what happens?

Anyone know how to do this?

-
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: [BUG] raid5 crash with 2.4.0-test12 [Was: Linux-2.4.0-test12]

[Neil Brown]

On Tuesday December 12, [EMAIL PROTECTED] wrote:
> 
> 
> On Wed, 13 Dec 2000, Neil Brown wrote:
> >
> > Could you add this test to the top of md_make_request as well, because
> > requests to raid5 don't go through generic_make_request.
> 
> Sure they do. Everything that calls ll_rw_block() or submit_bh() will go
> through generic_make_request.
> 
> Neil, you're probably thinking about __make_request(), which only triggers
> for "normal" devices.

Yes... you are right.  Alright, I can't escape it any other way so I
guess I must admit that  it is a raid5 bug.

But how can raid5 be calling b_end_io on a buffer_head that was never
passed to generic_make_request?
Answer, it snoops on the buffer cache to try to do complete stripe
writes.
The following patch disabled that code.

NeilBrown

--- drivers/md/raid5.c  2000/12/13 00:13:54 1.1
+++ drivers/md/raid5.c  2000/12/13 00:14:07
@@ -1009,6 +1009,7 @@
struct buffer_head *bh;
int method1 = INT_MAX, method2 = INT_MAX;
 
+#if 0
/*
 * Attempt to add entries :-)
 */
@@ -1039,6 +1040,7 @@
atomic_dec(>b_count);
}
}
+#endif
PRINTK("handle_stripe() -- begin writing, stripe %lu\n", sh->sector);
/*
 * Writing, need to update parity buffer.
 
-
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.18 release notes

[Igmar Palsenberg]

> - metrics -- L1 cacheline size is the important one: you align array
>   elements to this size when you want a per-cpu array, so that multiple
>   CPUs do not share a cacheline for accessing their "own" structure.
>   Proper alignment avoids "cacheline ping-pong", as it's called,
>   whenever two CPUs need to access "their" element of the same array at
>   the same time.

Anyone can give me some pointers on how this is done runtime ? (name of
the .c file is fine).

I'm still looking at the basic stuff, but haven't bumped into this one
yet...




Igmar

-
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: Dropping chars on 16550

[Igmar Palsenberg]

> > Use handshaking
> 
> Heh...do what I did.  Go on eBay and pick up a Hayes ESP card.

Hmm.. High speed comm is fine here, as long is I use handshaking. If I
don't, I'll loose chars.

> I have a fairly weak system by todays standards, and I found that
> even with a 16550 serial port, I'd get tcp/ip errors in my logs
> (and lots of 'em).

Mine used to be a 200MMX until last week :)

> --
> Mark Orr
> [EMAIL PROTECTED]


Igmar

-
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.18 vs Inspiron

[Bob Lorenzini]

There was some discusion lately re: Dell Inspiron FB probs. The bad news
is the ATI Mach64 display support is still broken but just selecting
VESA VGA graphics console is working fine. 

The patient is a Dell Inspiron I7500 1050x1450 display, vga = 794.

Bob

-
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: Build failure in 2.2.18

[Keith Owens]

On Tue, 12 Dec 2000 09:39:31 -0500, 
root <[EMAIL PROTECTED]> wrote:
>I've just patched and reconfigured to 2.2.18 (from 2.2.17 on an
>i686-linux-gnu[2.2]).  make bzImage fails with:
>ld:/usr/src/linux/arch/i386/vmlinux.lds:73: parse error
>  /* Stabs debugging sections.  */
>  .
>   stab 0 : { *(.stab) }
>  .stabstr 0 : { *(.stabstr) }

arch/i386/vmlinux.lds is generated from arch/i386/vmlinux.lds.S, using
$(CPP).  It looks like your version of cpp is doing something very
strange to the text, it has split '.stab 0 : { *(.stab) }' over two
lines.  I do not see this with egcs 2.91.66, what does gcc -v report?

Try removing arch/i386/vmlinux.lds and running make bzImage again, that
will create a fresh copy of vmlinux.lds.

-
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: [BUG] raid5 crash with 2.4.0-test12 [Was: Linux-2.4.0-test12]

[Linus Torvalds]

On Wed, 13 Dec 2000, Neil Brown wrote:
>
> Could you add this test to the top of md_make_request as well, because
> requests to raid5 don't go through generic_make_request.

Sure they do. Everything that calls ll_rw_block() or submit_bh() will go
through generic_make_request.

Neil, you're probably thinking about __make_request(), which only triggers
for "normal" devices.

The fact that the buffer doesn't go through generic_make_request() implies
that it is some buffer that is completely internal to the raid5
processing. I don't see anything like that, though.

Jasper, sorry about even asking this, but where did you add the check for
b_end_io? Maybe you put it in __make_request() by mistake?

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/

PATCH: ALSxxx soundcard documentation update

[Jonathan Woithe]

Hi Linus

Here is a minor update to Documentation/sound/ALS which covers the PnP
issues with a little more clarity than is currently done.  It is for the
2.4.testXXX series and made against the ALS file from test10.

Regards
  jonathan

--- linux-2.4.test10-orig/Documentation/sound/ALS   Wed Apr 12 11:43:15 2000
+++ linux-2.4.test10/Documentation/sound/ALSTue Nov 21 09:07:04 2000
@@ -9,25 +9,42 @@
 as part of the Sound Blaster 16 driver (adding only 800 bytes to the
 SB16 driver).
 
-To use an ALS sound card under Linux, enable the following options in the
-sound configuration section of the kernel config:
+To use an ALS sound card under Linux, enable the following options as
+modules in the sound configuration section of the kernel config:
   - 100% Sound Blaster compatibles (SB16/32/64, ESS, Jazz16) support
   - FM synthesizer (YM3812/OPL-3) support 
+  - standalone MPU401 support may be required for some cards; for the
+ALS-007, when using isapnptools, it is required
 Since the ALS-007/100/200 are PnP cards, ISAPnP support should probably be
-compiled in.
+compiled in.  If kernel level PnP support is not included, isapnptools will
+be required to configure the card before the sound modules are loaded.
 
-Alternatively, if you decide not to use kernel level ISAPnP, you can use the
-user mode isapnptools to wake up the sound card, as in 2.2.X. Set the "I/O 
-base for SB", "Sound Blaster IRQ" and "Sound Blaster DMA" (8 bit -
-either 0, 1 or 3) to the values used in your particular installation (they
-should match the values used to configure the card using isapnp).  The
-ALS-007 does NOT implement 16 bit DMA, so the "Sound Blaster 16 bit DMA"
-should be set to -1.  If you wish to use the external MPU-401 interface on
-the card, "MPU401 I/O base of SB16" and "SB MPU401 IRQ" should be set to
-the appropriate values for your installation.  (Note that the ALS-007
-requires a separate IRQ for the MPU-401, so don't specify -1 here).  (Note
-that the base port of the internal FM synth is fixed at 0x388 on the ALS007; 
-in any case the FM synth location cannot be set in the kernel configuration).
+When using kernel level ISAPnP, the kernel should correctly identify and
+configure all resources required by the card when the "sb" module is
+inserted.  Note that the ALS-007 does not have a 16 bit DMA channel and that
+the MPU401 interface on this card uses a different interrupt to the audio
+section.  This should all be correctly configured by the kernel; if problems
+with the MPU401 interface surface, try using the standalone MPU401 module,
+passing "0" as the "sb" module's "mpu_io" module parameter to prevent the
+soundblaster driver attempting to register the MPU401 itself.  The onboard
+synth device can be accessed using the "opl3" module.
+
+If isapnptools is used to wake up the sound card (as in 2.2.x), the settings
+of the card's resources should be passed to the kernel modules ("sb", "opl3"
+and "mpu401") using the module parameters.  When configuring an ALS-007, be
+sure to specify different IRQs for the audio and MPU401 sections - this card
+requires they be different.  For "sb", "io", "irq" and "dma" should be set
+to the same values used to configure the audio section of the card with
+isapnp.  "dma16" should be explicitly set to "-1" for an ALS-007 since this
+card does not have a 16 bit dma channel; if not specified the kernel will
+default to using channel 5 anyway which will cause audio not to work. 
+"mpu_io" should be set to 0.  The "io" parameter of the "opl3" module should
+also agree with the setting used by isapnp.  To get the MPU401 interface
+working on an ALS-007 card, the "mpu401" module will be required since this
+card uses separate IRQs for the audio and MPU401 sections and there is no
+parameter available to pass a different IRQ to the "sb" driver (whose
+inbuilt MPU401 driver would otherwise be fine).  Insert the mpu401 module
+passing appropriate values using the "io" and "irq" parameters.
 
 The resulting sound driver will provide the following capabilities:
   - 8 and 16 bit audio playback
@@ -45,3 +62,5 @@
 
 Modified 2000-02-26 by Dave Forrest, [EMAIL PROTECTED] to add ALS100/ALS200
 Modified 2000-04-10 by Paul Laufer, [EMAIL PROTECTED] to add ISAPnP info.
+Modified 2000-11-19 by Jonathan Woithe, [EMAIL PROTECTED]
+ - updated information for kernel 2.4.x.


-- 
* Jonathan Woithe[EMAIL PROTECTED]*
*http://www.physics.adelaide.edu.au/~jwoithe*
***---***
** "Time is an illusion; lunchtime doubly so"  **
*  "...you wouldn't recognize a subtle plan if it painted itself purple *
*   and danced naked on a harpsicord singing 'subtle plans are here again'" *
-
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 

Re: VM problem (2.4.0-test11)

[J . A . Magallon]

On Wed, 13 Dec 2000 00:25:25 Jussi Laako wrote:
> Marc Mutz wrote:
> > 
> > Just to not miss the obvious: You know about ulimit(3)?
> 
> Yes, but it doesn't stop deadlocks caused by kernel's VM system going
> wild... I think that no matter what user process does, root should be always
> able to stop it. User process should never be able to render whole system
> unusable.
> 

That is just some issue that was discussed in this list recently. Look in the
list
for 'oom killer' subjects.
There are various patches-ways-to-do available, kernel gurus are still working
on it...
(leave always some 4% of mem for root, kill some process when mem is exhausted,
which one to kill...)

-- 
Juan Antonio Magallon Lacarta #> cd /pub
mailto:[EMAIL PROTECTED] #> more beer

Linux werewolf 2.2.18-aa1 #1 SMP Mon Dec 11 21:26:28 CET 2000 i686

-
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: Still "eth0: trigger_send() called with the transmitter busy" in 2.4.0-test12

[Gnea]

On Tue, 12 Dec 2000 18:46:42 +0100, Juan blurted forth:

> Hi!
>  
>  This error exists since 2.4.0-test10preX or so. It occurs when the
>  network interface is activated.
>  
>  I'm using RedHat 7.0 and my ethernet card is a "Kingston EtheRx KNE20
>  Plug and Play ISA Adapter". I'm unable to access the Internet because
>  the ethernet card doesn't work :-(. Besides, the card uses two
>  interrupts (?) and there are two interfaces (eth0 y eth1) when I have
>  only one (?).
>  
[snip]
>   --- Next Part --- 
>  
>  Card 1 'KTC2000:Kingston EtheRx KNE20 Plug and Play ISA Adapter' PnP version 1.0 
>Product version 1.0
>Logical device 0 'RTL8019:Unknown'
>  Supported registers 0x2
>  Compatible device PNP80d6
>  Device is active
>  Active port 0x,0x,0x,0x,0x,0x,0x,0x
>  Active IRQ 255 [0xff],255 [0xff]
>  Active DMA 255,255
>  Active memory 0x,0x,0x,0x
>  Resources 0
>Priority preferred
>Port 0x240-0x380, align 0x1f, size 0x20, 10-bit address decoding
>IRQ 3,4,5,2/9,10,11,12,15 High-Edge

try loading the rtl81*.o module(s) until it works right... you should
see a message for eth1 in dmesg about it

-- 
.oO gnea at rochester dot rr dot com Oo.
.oO url: http://garson.org/~gnea Oo.

"You can tune a filesystem, but you can't tuna fish" -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: how to capture long oops w/o having second machine

[Mohammad A. Haque]

Wouldn't you know it. I've patched my kernel with kdb and now I can't
get it to throw up.

Maybe it'll do it once this mail gets sent out like it did last time.

I'd prefer a dumper also. I went and grabbed LKCD but it didn't patch
cleanly against test12 so I decided against it.

dean gaudet wrote:
> 
> i've always been curious why none of the crash dump patches are default.
> an oops dumper alone would seem to be most useful.  (i know anything more
> would be unacceptable 'cause linus isn't into debuggers ;)
> 
> -dean
> 

-- 

=
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: VM problem (2.4.0-test11)

[Jussi Laako]

Marc Mutz wrote:
> 
> Just to not miss the obvious: You know about ulimit(3)?

Yes, but it doesn't stop deadlocks caused by kernel's VM system going
wild... I think that no matter what user process does, root should be always
able to stop it. User process should never be able to render whole system
unusable.

Hard memory limit per process doesn't stop this from happening, because it
depends overall system memory usage and allocation rate. It's completely
different if memory usage goes from 200 MB to 512 MB in 1 usec or 1 week.

 - Jussi Laako

-- 
PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B  39DD A4DE 63EB C216 1E4B
Available at PGP keyservers
-
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: how to capture long oops w/o having second machine

[dean gaudet]

i've always been curious why none of the crash dump patches are default.
an oops dumper alone would seem to be most useful.  (i know anything more
would be unacceptable 'cause linus isn't into debuggers ;)

-dean

On Tue, 12 Dec 2000, Miles Lane wrote:

>
> Try reading:
>
>   http://www.linuxhq.com/kernel/v2.3/doc/oops-tracing.txt.html
>
> It mentions:
>
>  Patch the kernel with one of the crash dump patches.  These save
>  data to a floppy disk or video rom or a swap partition.  None of
>  these are standard kernel patches so you have to find and apply
>  them yourself.  Search kernel archives for kmsgdump, lkcd and
>  oops+smram.
>
> I don't know if the "dump to floppy" patch is maintained for the
> 2.4.0 series.
>
>   Miles
>
> Mohammad A. Haque wrote:
>
> > Nope, this didn't fly. Would have been neat if it did work. Maybe it can
> > be made to work for future use?
> >
> > On Tue, 12 Dec 2000, Greg KH wrote:
> >
> >
> >> I don't know if /dev/ttyUSBX would work, but I think it would.  People
> >> have successfully run consoles through the usb-serial drivers, but I'm
> >> not sure if the oops main console requires something different (like
> >> registering itself actually as a console?)
> >>
> >> And then there's the nice problem of the fact that if the oops comes
> >> from the USB code, you will not see it come out the usb-serial driver :)
> >>
> >> Let me know if you try this, and have any success (or find that it
> >> doesn't work.)
>
>
> -
> 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/
>

-
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: [BUG] raid5 crash with 2.4.0-test12 [Was: Linux-2.4.0-test12]

[Neil Brown]

On Tuesday December 12, [EMAIL PROTECTED] wrote:
> On Tue, Dec 12, 2000 at 11:06:07AM -0800, Linus Torvalds wrote:
> >
> > To get better debug output, could you please do something for me? 
> > 
> > In fs/buffer.c, get rid of "end_buffer_io_bad" completely, and replace all
> > users of it with NULL.
> > 
> > Then, in drivers/block/ll_rw_block.c: generic_make_request(), add a test
> > like
> > 
> > if (!bh->b_end_io) BUG();
> > 
> > to the top of that function.

Could you add this test to the top of md_make_request as well, because
requests to raid5 don't go through generic_make_request.

> 
> Strange thing is that it doesn't call BUG() and the trace seems quite
> identical -- this caused me to start looking at the code in
> drivers/md/raid5.c and it seems this null pointer deref is coming from there
> - Neil, do you have some documentation on how this code should work, as
> stripe_head causes some null-pointer-derefs inside my head..

No, no doco, sorry.
I do have a new version of the code that I haven't been brave enough
to submit during a code freeze (whatever that is)... you could try
the raid5 patch under
  http://www.cse.unsw.edu.au/~neilb/patches/linux/2.4.0-test12-pre8

I expect that you will get the same result as I don't (currently)
think the bug is in RAID code, but at least I would get one more
tester for my code

NeilBrown
-
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] timer.h obsolete comments

[Pavel Rabel]

Hi Linus,

Are the old static timers gone completely?
Some comments are either obsolete or out of place.

Pavel Rabel

--- include/linux/timer.h.old   Tue Dec 12 22:07:35 2000
+++ include/linux/timer.h   Tue Dec 12 22:09:28 2000
@@ -5,13 +5,9 @@
 #include 
 
 /*
- * This is completely separate from the above, and is the
+ * Old-style "hardcoded" timers are gone, this is the
  * "new and improved" way of handling timers more dynamically.
  * Hopefully efficient and general enough for most things.
- *
- * The "hardcoded" timers above are still useful for well-
- * defined problems, but the timer-list is probably better
- * when you need multiple outstanding timers or similar.
  *
  * The "data" field is in case you want to use the same
  * timeout function for several timeouts. You can use this

-
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: VM problem (2.4.0-test11)

[Marc Mutz]

Jussi Laako wrote:
> 
> Hello,
> 
> Would it be possible to implement some VM CPUtime/bandwidth limitation?
> 


Just to not miss the obvious: You know about ulimit(3)?

man 3 ulimit
help ulimit (when in bash).

Marc

-- 
Marc Mutz <[EMAIL PROTECTED]> http://EncryptionHOWTO.sourceforge.net/
University of Bielefeld, Dep. of Mathematics / Dep. of Physics

PGP-keyID's:   0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)

-
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: pdev_enable_device no longer used ?

[David S. Miller]

   Date: Tue, 12 Dec 2000 21:28:18 +0100 (CET)
   From: Gérard Roudier <[EMAIL PROTECTED]>

   You can be as dump as you want with PCI, but not that much. :-)

Your point is well taken.

   Btw, unlike the person, that proposed it, that will be able to test
   peer-to-peer unability only, my current machine will allow to test
   peer-to-peer ability only between 2 different PCI BUSes. :-)

   For now, my intention is to encapsulate the right interface as seen from
   my brain device in macros and forget about it until a new interface will
   be provided. I will first implement it on SYM-2 and backport changes to
   sym53c8xx later. And since I need the new major driver version to be
   tested on non-Intel platforms, this will make full synergy for the
   testings. :-)

Ok, meanwhile I will try to code up the generic interface.  It will
work like this: 1) I will code up something I know each port can
implement 2) I will show it to those here and everyone can tell me if
they can make use of it at all :-)

Later,
David S. Miller
[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: [BUG] raid5 crash with 2.4.0-test12 [Was: Linux-2.4.0-test12]

[Jasper Spaans]

On Tue, Dec 12, 2000 at 11:06:07AM -0800, Linus Torvalds wrote:

> > Dec 12 14:04:50 spaans kernel: invalid operand: 
> > Dec 12 14:04:50 spaans kernel: CPU:1
> > Dec 12 14:04:50 spaans kernel: EIP:0010:[end_buffer_io_bad+85/92]
> >
> > Dec 12 14:04:50 spaans kernel: Call Trace:
> > [raid5_end_buffer_io+68/128]
> > [complete_stripe+151/272]
> > [handle_stripe+331/1092]
> > [raid5d+173/260]
> > [md_thread+299/508]
> 
> Looks like somebody didn't initialize the "b_end_io" pointer - the code
> defaults to it being "end_buffer_io_bad" (which oopses unconditionally on
> purpose exactly to find places where it wasn't initialized).
> 
> And it obviously looks like it's the raid5 code that does it.
>
> To get better debug output, could you please do something for me? 
> 
> In fs/buffer.c, get rid of "end_buffer_io_bad" completely, and replace all
> users of it with NULL.
> 
> Then, in drivers/block/ll_rw_block.c: generic_make_request(), add a test
> like
> 
>   if (!bh->b_end_io) BUG();
> 
> to the top of that function.
> 
> You'll still get a oops, but the difference is that you'll get the oops
> when the request is queued, rather than when the requst is finished, which
> will make it easier to figure out what the thing is that leads up to this.

Right, well, I applied your suggestions, and I got it to oops -- dunno how,
but it oopsed.

Unable to handle kernel NULL pointer dereference at virtual address 

*pde = 
Oops: 
CPU:0
EIP:0010:[<>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax:    ebx: 0008   ecx: c146c400   edx: 0202
esi: c154d560   edi: c154d400   ebp: c70791a0   esp: c14ade9c
ds: 0018   es: 0018   ss: 0018
Process raid5d (pid: 9, stackpage=c14ad000)
Stack: c01c916c c70791a0 0001 0008 c154d400 0002  c01c9ccf 
   c154d400 0002 0001 c154d400 c146c400 c154d400 0003 0003 
   c146c400 c01ca827 c154d400 c154d400 c146c400 00a2 c14b1ec0 c02e8c80 
Call Trace: [] [] [] [] [] 
[] [] 
   [] [] 
Code:  Bad EIP value.

>>EIP;  Before first symbol
Trace; c01c916c 
Trace; c01c9ccf 
Trace; c01ca827 
Trace; c018c070 
Trace; c018c0c9 
Trace; c018c3ed 
Trace; c01cad99 
Trace; c01d1b57 
Trace; c0109a88 

Strange thing is that it doesn't call BUG() and the trace seems quite
identical -- this caused me to start looking at the code in
drivers/md/raid5.c and it seems this null pointer deref is coming from there
- Neil, do you have some documentation on how this code should work, as
stripe_head causes some null-pointer-derefs inside my head..

It seems a stripe_head is quite similar to a block_head, but why is
raid5_end_buffer_io calling the bh_end_io function from the stripe_head, I'd
assume it should be called from ll_rw_block.c?

Regards,
-- 
Jasper Spaans  <[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/

2.4.0-test12 doesn't start under vmware

[Thomas Kotzian]

I compiled linux-2.4.0-test12 without any problems:
it does:
Lilo:
loading v240t12 .
Uncompressing Linux... Ok, booting the kernel.

then it is in an endless loop i think because vmware uses all cpu-power.
First I start in Grub, from there i start Lilo and then the kernel. - maybe
there's a problem?

Thomas

-
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] mdacon.c cleanup

[Pavel Rabel]

On Tue, 12 Dec 2000, David Woodhouse wrote:

> [EMAIL PROTECTED] said:
> > Both MODULE_PARM and __init are removed by precompiler when not
> > compiler as module, so no need for ifdefs.  2.4.0-test12pre8
> 
> -#ifdef MODULE_PARM
>  MODULE_PARM(mda_first_vc, "1-255i");
>  MODULE_PARM(mda_last_vc,  "1-255i");
> -#endif
> 
> That was #ifdef MODULE_PARM not #ifdef MODULE. Probably there for 
> compatibility with older kernels. Although I'm not sure it's even required 
> in 2.2.

MODULE_PARM is removed by precompiler, in both 2.2 and 2.4. For sure.
 
Pavel

-
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/

EMU10K1 not working under 2.2.18 (fwd)

[kees]

Hello,
I have a SMP mobo MSI 694D with (2xPIII667MHz).
Under 2.2.18 the EMU10K1 *is* recognised (var/log/boot)

<6>Creative EMU10K1 PCI Audio Driver, version 0.6, 18:26:49 Dec  6 2000
<6>emu10k1: EMU10K1 rev 8 model 0x8027 found, IO at 0xe400-0xe41f, IRQ 18

But produce no mixer device for instance. 

Booting 2.2.17 back up: all is normal. Basically I did make oldconfig with
only:
> CONFIG_MICROCODE=y
> CONFIG_X86_MSR=y
> CONFIG_X86_CPUID=m 
and a couple of usb selections as modules. 
The other odd thing is that the 2 penguins are displayed correct with 
2.2.17 buth in a weird color with 2.2.18.
Both versions are build with the same compiler (SuSE 7.0)


Kees

P.S. Why is there no '/dev/sndstat' ?


-
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: UP 2.2.18 makes kernels 3% faster than UP 2.4.0-test12

[Steven Cole]

On Tuesday 12 December 2000 13:38, Linus Torvalds wrote:
> On Tue, 12 Dec 2000, Steven Cole wrote:
> > Task: make -j3 bzImage for 2.4.0-test12-pre7 kernel tree.
>
> Actually, do it with
>
>   make -j3 'MAKE=make -j3' bzImage
>
> A single "-j3" won't do much. It will only build three directories at a
> time, and you'll never see much load. But doing it recursively means that
> you'll build three at a time all the way out to the leaf directories, and
> you should see loads up to 20+, and much more memory pressure too.
>
>   Linus

Ok, repeated the tests with make -j3 'MAKE=make -j3' bzImage

I ran xosview to monitor the load.

The load values for 2.2.18 seemed to stay higher longer than
for 2.4.0-test12. I recorded the peak load observed.

For comparison, with make -j3 bzImage, the peak load was much
lower, about 2.7.

Task: make -j3 'MAKE=make -j3' bzImage for 2.4.0-test12-pre7 kernel tree.
Numbers are seconds to build.
New results:

 1   2   3  ave.
143 143 143 143 Running 2.2.18 SMP
19.117.519.218.6Max load observed with xosview

142 141 141 141.3   Running 2.4.0-test12-pre7 SMP
16.216.815.216.1Max load observed with xosview

Steven
-
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/

VM problem (2.4.0-test11)

[Jussi Laako]

Hello,

Would it be possible to implement some VM CPUtime/bandwidth limitation?

We have server used by multiple developers. Problem is when someone happens
to implement memory hole to application the system goes wild swapping and
ALL other activity stops. No response to keyboard/mouse events nor any
network traffic. Only disk system running wildly. No way to stop the
memoryhog application, only way out of this situation is to hit reset-button
and hope that no important data is lost. Same thing happens when I forget to
end some large matrix operation with semicolon in Octave... (and 2.2.x
kernels at least with Octave) I'm still considering this as local DOS attack
because normal user is able to overload the system.

Rebooting system all the time is annoying.

It would be nice to be able to tell system that "this process may use max
256 MB of memory and 10% of disk IO bandwidth and 25% of network bandwidth
and network IO latency is critical and disk io is not".

Kernel is stock except Andrew Morton's lowlatency patch.

Regards,

 - Jussi Laako

-- 
PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B  39DD A4DE 63EB C216 1E4B
Available at: ldap://certserver.pgp.com, http://keys.pgp.com:11371

-
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: 2.2.16 SMP: mtrr errors

[Paul C. Nendick]

Shall I submit this to Matrox as a bug then?

/paul

Alan Cox ([EMAIL PROTECTED]) said:

> > Petr, the Matrox card splits the memory between the two video screens
> > when running in a multi-head configuration and "pretends" that it is two
> > distinct cards. Thus, a 32 mb card will register an mtrr for 24mb and
> > for 8mb seperately when in this mode.
> 
> That is a driver bug. The intel processors only support MTRR's on certain
> power boundaries/sizes. The fall through is intended. 
> 
> > to fall through, but is this correct? I've inserted a break at the end
> > of the Intel switch before and have not had problems, but I left it out
> 
> Lucky
> 
> > in the latest couple of kernels because of all the mtrr work being done,
> > waiting to see if there was resolution.
> 
> The Matrox driver needs to register a single 32Mb MTRR
> 

-- 
Paul C. Nendick
-
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: how to capture long oops w/o having second machine

[Greg KH]

On Tue, Dec 12, 2000 at 06:13:39PM +0100, Andreas Bombe wrote:
> On Tue, Dec 12, 2000 at 09:34:30AM -0500, Mohammad A. Haque wrote:
> > Someone gave me a really awesome idea about possibly using a palm pilot
> > to capture the oops. Anyone know if it will be a problem using
> > /dev/ttyUSB0 as the serial port?
> 
> The driver itself has to provide support for serial console.  If the USB
> serial driver doesn't (I don't know) it won't work.  Check the config
> options for USB serial, if it doesn't offer an option for console on USB
> serial port then you're out of luck.
> 
> Unless the USB serial driver in some strange way hooks into the standard
> serial driver, but then someone more knowledgeable should answer that
> question.

Nope, it doesn't specifically support the CONFIG_SERIAL_CONSOLE with all
of the register_console code, etc., so this will not work, sorry.

But it's something that I would gladly take a patch for :)

greg k-h

-- 
greg@(kroah|wirex).com
http://immunix.org/~greg
-
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: 2.2.16 SMP: mtrr errors

[John Cavan]

Alan Cox wrote:
> > to fall through, but is this correct? I've inserted a break at the end
> > of the Intel switch before and have not had problems, but I left it out
> 
> Lucky

Wouldn't be the first time...
-
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: PROBLEM: cdrom doesnt work anymore with 2.4

[Matthias Czapla]

On Die, Dez 12, 2000 at 04:15:44 +0100, Guest section DW wrote:
> On Tue, Dec 12, 2000 at 02:17:04PM +0100, Matthias Czapla wrote:
> 
> > I have a quite old cdrom drive, called Cyberdrive 240D. With linux 2.2.17
> > it worked with soemtimes odd behavior, but it worked.
> > With 2.4.0-test11 I can mount cdroms in it but if I want to access it (eg.
> > ls, cd...) I get messages like:
> > _isofs_bmap: block >= EOF (1096810496, 2048)
> > or 
> > _isofs_bmap: block < 0
> 
> Fixed in 2.4.0-test12.
> 

Thanks. Its workign now :))

-- 
schüss,
Matthias Czapla
-
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: pdev_enable_device no longer used ?

[Gérard Roudier]

On Tue, 12 Dec 2000, David S. Miller wrote:

>Date: Tue, 12 Dec 2000 20:17:21 +0100 (CET)
>From: Gérard Roudier <[EMAIL PROTECTED]>
> 
>On Mon, 11 Dec 2000, David S. Miller wrote:
> 
>> Tell me one valid use of this information first :-)
> 
>SCRIPTS. Have a look into my kind :-) response to Martin.
> 
> Ok, this I understand.
> 
>> b) If you wish to interpret the BAR values and use them from a BUS
>>perspective somehow, you still need to go through some interface
>>because you cannot assume what even the hw BAR values mean.
>>This is precisely the kind of interface I am suggesting.
> 
>The BAR values make FULL sense on the BUS.
> 
> I am saying there may be systems where it does not make any sense,
> f.e. actually used bits of BAR depend upon whether CPU, or DEVICE on
> that bus, or DEVICE on some other bus make the access.
>
> Forget all the PCI specifications, it is irrelevant here.  All your
> PCI expertiece means nothing, nor mine.  People build dumb machines
> with "PCI implementations" and we need to handle them.

Even the dumbest PCI implementation will keep with BAR relevance. Reason
is that PCI devices are using BAR values and corresponding size to make
decision about claiming or not a transaction as target.
You can be as dump as you want with PCI, but not that much. :-)

>I will wait for your .txt file that describes your idea. Your
>documentation about the new DMA mapping had been extremally useful.
>Let me thank you again for it.
> 
> It requires no .txt file :-), 

No problems, a ".text" file would also fit just fine. :-)

> it will just be formalization of
> existing bus_to_dvma_whatever hack :-) Specify PDEV (device) and
> RESNUM (which I/O or MEM resource for that device), returns either
> error or address as seen by BUS that PDEV is on.  You may offset
> this return value as desired, up to the size of that resource.
> 
> I could make a more elaborate interface (add new parameter,
> PDEV_MASTER which is device which wishes to access area described by
> PDEV+RESNUM), allowing full PCI peer-to-peer setup, as described by
> someone else in another email of this thread.  This version would have
> an error return, since there will be peer2peer situations on some
> systems which cannot be made.  But I feel this is inappropriate until
> 2.5.x, others can disagree.

I saw the proposal.

Btw, unlike the person, that proposed it, that will be able to test
peer-to-peer unability only, my current machine will allow to test
peer-to-peer ability only between 2 different PCI BUSes. :-)

For now, my intention is to encapsulate the right interface as seen from
my brain device in macros and forget about it until a new interface will
be provided. I will first implement it on SYM-2 and backport changes to
sym53c8xx later. And since I need the new major driver version to be
tested on non-Intel platforms, this will make full synergy for the
testings. :-)

Bye,
  Gérard.

-
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: ANNOUNCE: Linux Kernel ORB: kORBit

[Chris Lattner]

On Sat, 9 Dec 2000, Mohammad A. Haque wrote:

> It was just an example. Basically, you'd be able to do in with just
> about any language that has ORBit bindings.
> 
> Ben Ford wrote:
> > Why would you *ever* want to write a device driver in perl???
> 

Precisely... but also, there could be a case where perl would make
sense.  Consider an FTP filesystem.  There performance is not dictated by
the speed of the language, it's limited by bandwidth.  It could make sense
to write your almighty FTPfs like this:

1. Prototype it in Perl, get all the bugs out.
2. Rewrite in C in userspace, get all the bugs out.
3. recompile/relink in kernel space with no source modifications
4. ship product.  :)

The great thing that kORBit buys you is insulation of kernel space from
the drivers that are running... kinda like a microkernel.  I'm not going
to start a flamewar here about Linux and microkernels, but when doing
initial development work for a driver, the test/crash/reboot/fsck cycle is
a real pain (okay, maybe journalling helps a little, but you get the
idea).  What we're offering goes more like this:

1. Boot kernel
2. Install corbafs module for example
3. Start test filesystem in user space
4. mount test user space filesystem
5. test it, oh crap, it segfaulted.
6. CorbaFS gets exceptions trying to communicate to server, which it
relays to the kernel as -errno conditions.
7. You safely unmount corbafs
8. fix your bug
9. goto step #2.

Which is arguably nicer.  :)

The whole idea is that a bastard driver shouldn't take your kernel down if
you know it to be unreliable... if you trust the driver, then by all
means, don't use kORBit.  Also, kORBit is useful when you don't WANT
something in the kernel... and I won't bring up the whole user level
filesystem debate again... :)

-Chris

http://www.nondot.org/~sabre/os/
http://korbit.sourceforge.net/

> -- 
> 
> =
> 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: 2.2.16 SMP: mtrr errors

[Alan Cox]

> Petr, the Matrox card splits the memory between the two video screens
> when running in a multi-head configuration and "pretends" that it is two
> distinct cards. Thus, a 32 mb card will register an mtrr for 24mb and
> for 8mb seperately when in this mode.

That is a driver bug. The intel processors only support MTRR's on certain
power boundaries/sizes. The fall through is intended. 

> to fall through, but is this correct? I've inserted a break at the end
> of the Intel switch before and have not had problems, but I left it out

Lucky

> in the latest couple of kernels because of all the mtrr work being done,
> waiting to see if there was resolution.

The Matrox driver needs to register a single 32Mb MTRR

-
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: 2.2.18 vanilla on SMP, latency WORKAROUND

[Mario Vanoni]

Mario Vanoni wrote:
> 
> Same latencies as 2.2.16 and 2.2.17 vanilla,
> over 75 seconds to wait on an other screen!
> And top(1) on a serial VT510 freezes.
> 
> Machine loaded with 2 setiathome and
> Doug Ledford's memtest.
> 
> ASUS P2B-DS Dual PIII550 1024MB memory,
> only SCSI devices (no IDE!).
> 
> Andrea Arcangeli's ..17pre6aa2, ..18pre17aa1
> and ..18pre21aa2 reduced the latency <2 secs.
> 
> Regards
> Mario Vanoni
> 
> PS If necessary, cc, not in lkml!

Patched with Andrea's 2.2.18aa1, with more loads,
latency always minor 1-2 seconds.
Impossible to reproduce 75 seconds!

Mario
-
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: 2.2.16 SMP: mtrr errors

[Petr Vandrovec]

On 12 Dec 00 at 16:07, John Cavan wrote:
> Petr Vandrovec wrote:
> > > kernel: mtrr: base(0xd400) is not aligned on a size(0x180) boundary
> > > last message repeated 2 times
> > 
> > For some strange reason X thinks that you have 24MB of memory on the G450.
> > You can either create 32MB write-combining region at 0xd400, or
> > teach X that your device occupies 32MB and not 24 (you should do it anyway,
> > region size can be only power of two)...
> 
> Petr, the Matrox card splits the memory between the two video screens
> when running in a multi-head configuration and "pretends" that it is two
> distinct cards. Thus, a 32 mb card will register an mtrr for 24mb and
> for 8mb seperately when in this mode.

That's wrong. They must first register MTRR and then split it to
24+8, as they cannot register 24MB range. They can split it
16+16, or (16+8)+8, but at cost of 1 (or 2) additional MTRR entries -
and there is very limited number of possible MTRRs.

Matroxfb also splits Matrox memory in 24:8, but it registers only one
region in mtrr. Of course, in X, as mtrr registration is done by map
videomemory, you must tell this function to not register mtrr...

Best regards,
Petr Vandrovec
[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: Big IDE HD unclipping and IBM drive

[Dr. Kelsey Hudson]

Yeah, get yourself one of those nifty add-in IDE controllers that CAN see
drives greater than 32GB. S'What I did and it works fine.

On Fri, 8 Dec 2000, Matan Ziv-Av wrote:

> 
> Hi,
> 
> 
> I have an IBM drive, DTLA-307075 (75GB), and a bios that hangs with
> large disks. I use a jumper to clip it to 32GB size, so the bios can
> boot into linux. The problem is that WIN_READ_NATIVE_MAX returns 32GB,
> and not the true size, and even trying to set the correct size with
> WIN_SET_MAX fails. Is there a way to use this combination (Bios, HD,
> Linux)?
> 
> 
> 

-- 
 Kelsey Hudson   [EMAIL PROTECTED] 
 Software Engineer
 Compendium Technologies, Inc   (619) 725-0771
--- 

-
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: 2.2.16 SMP: mtrr errors

[John Cavan]

Petr Vandrovec wrote:
> > kernel: mtrr: base(0xd400) is not aligned on a size(0x180) boundary
> > last message repeated 2 times
> 
> For some strange reason X thinks that you have 24MB of memory on the G450.
> You can either create 32MB write-combining region at 0xd400, or
> teach X that your device occupies 32MB and not 24 (you should do it anyway,
> region size can be only power of two)...

Petr, the Matrox card splits the memory between the two video screens
when running in a multi-head configuration and "pretends" that it is two
distinct cards. Thus, a 32 mb card will register an mtrr for 24mb and
for 8mb seperately when in this mode.

At line 1190 in arch/i386/kernel/mtrr.c the switch on Intel falls
through hitting the error message for Centaur. I know the comment says
to fall through, but is this correct? I've inserted a break at the end
of the Intel switch before and have not had problems, but I left it out
in the latest couple of kernels because of all the mtrr work being done,
waiting to see if there was resolution.

John
-
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: how to capture long oops w/o having second machine

[Miles Lane]

Try reading:

http://www.linuxhq.com/kernel/v2.3/doc/oops-tracing.txt.html

It mentions:

 Patch the kernel with one of the crash dump patches.  These save
 data to a floppy disk or video rom or a swap partition.  None of
 these are standard kernel patches so you have to find and apply
 them yourself.  Search kernel archives for kmsgdump, lkcd and
 oops+smram.

I don't know if the "dump to floppy" patch is maintained for the
2.4.0 series.

Miles

Mohammad A. Haque wrote:

> Nope, this didn't fly. Would have been neat if it did work. Maybe it can
> be made to work for future use?
> 
> On Tue, 12 Dec 2000, Greg KH wrote:
> 
> 
>> I don't know if /dev/ttyUSBX would work, but I think it would.  People
>> have successfully run consoles through the usb-serial drivers, but I'm
>> not sure if the oops main console requires something different (like
>> registering itself actually as a console?)
>> 
>> And then there's the nice problem of the fact that if the oops comes
>> from the USB code, you will not see it come out the usb-serial driver :)
>> 
>> Let me know if you try this, and have any success (or find that it
>> doesn't work.)


-
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: linux-2.4.0-test12pre8/include/linux/module.h breaks sysklogd compilation

[Frank van Maarseveen]

On Mon, Dec 11, 2000 at 07:53:05PM -0600, Peter Samuelson wrote:
> 
> [Mohammad A. Haque]
> > Wasn't there discussion that user space apps shouldn't include kernel
> > headers?
> 
> Oh, it's been discussed, many times.  Here is my executive summary of
> why nobody needs to use kernel headers in userspace programs, *EVER*:
Oh, sounds reasonable. But:

Do the maintainers of strace, lm_sensors, the wacom input device in XFree
know this? (just to name a few)

The unanswered question remains:

$ cat `find linux/include/{linux,asm}/. -type f` |grep  '^#ifdef __KERNEL__'|wc
246 5144537

why is this?

Either: strip it or maintain it.

-- 
Frank
-
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.18: Patch to SysRq code

[Riley Williams]

Hi Alan.

The enclosed patch deals with two problems relating to the Magic SysRq
function, as follows:

 1. One of my pet peeves with SysRq as implemented is the apparently
random order theoptions as listed in the SysRq help list. This
patch sorts that list into case-insensitive alphabetical order.

 2. According to the above-mentioned help list, the log level can be
set in the range 0 to 8. The code additionally allows log level
9 to be set, so this was added to the list.

Best wishes from Riley.


diff -urN linux-2.2.18.old/drivers/char/sysrq.c linux-2.2.18/drivers/char/sysrq.c
--- linux-2.2.18.old/drivers/char/sysrq.c   Thu May  4 01:16:39 2000
+++ linux-2.2.18/drivers/char/sysrq.c   Tue Dec 12 13:23:23 2000
@@ -134,16 +134,18 @@
orig_log_level = 8;
break;
default:/* Unknown: help */
-   if (kbd)
-   printk("unRaw ");
+   printk("Boot kIll killalL loglevel0-9 ");
+   if (sysrq_power_off)
+   printk("Off ");
 #ifdef CONFIG_VT
if (tty)
printk("saK ");
 #endif
-   printk("Boot ");
-   if (sysrq_power_off)
-   printk("Off ");
-   printk("Sync Unmount showPc showTasks showMem loglevel0-8 tErm kIll 
killalL\n");
+   printk("showMem showPc showTasks Sync tErm Unmount ");
+   if (kbd)
+   printk("unRaw ");
+   printk("\n");
+
/* Don't use 'A' as it's handled specially on the Sparc */
}
 

2.2.18: Configuration documentation

[Riley Williams]

Hi Alan.

I've just done a comparison of the configuration variables listed in
the config.in files against those listed in the Configure.help file.
I have enclosed the bash script I wrote to perform this analysis, and
would like to submit it for inclusion with the kernel as the file...

./scripts/listvars

The results indicate three types of problems with these variables:

 1. 452 variables occur in the config.in files, but are never defined
in Configure.help at all. I can think of the following reasons for
this occurring:

 a. This will include variables from `choice` lines that do not
need to be defined as they will never be asked for. Remember
that only the first variable in any `choice` list is asked
for by the help systems.

 b. This will include variables that should be documented, but
are not. This needs to be corrected.

 2. 50 variables occur in Configure.help but are never referenced in any
of the config.in files. I can think of two reasons for this:

 a. The option is now obsolete, in which case the accompanying help
text should also be deleted.

 b. The option is spelt differently (a typo) in the config.in files
to how it is spelt in the Configure.help file, in which case
the spelling needs to be standardised. The following may be
cases where this has happenned:

config.in version   Configure.help version
~   ~~
CONFIG_ADVANCED CONFIG_ADVANCED_CPU
CONFIG_OLD_BELKIN_DONGLECONFIG_OLD_BELKING_DONGLE
CONFIG_SOUND_VMIDI  CONFIG_SOUND_MIDI
~   ~~

There could easily be others, and equally well, the above may
not be equivalent pairs.

 3. There are four variables that are documented twice each in the
Config.help file, two of which never occur in the config.in files.
These are as follows:

Config  Help  Variable
~~    
   1  2   CONFIG_ADFS_FS
 <**> 2   CONFIG_ATOMWIDE_SERIAL
 <**> 2   CONFIG_DUALSP_SERIAL
   1  2   CONFIG_RADIO_CADET
~~    

I have presumed that the duplicate descriptions need to be merged,
and have attached a patch to do so.

The results produced from this analysis are shown below, with the items
marked with '<**>' being the ones that appear to be missing in each
case. They are sorted into ASCII order, and are grouped by the first 9
characters of the variable name.

Config  Help  Variable
~~    
   1  1   CONFIG_060_WRITETHROUGH

   1<**>  CONFIG_1GB

   1<**>  CONFIG_2GB

   1<**>  CONFIG_3215
   1<**>  CONFIG_3215_CONSOLE

   1<**>  CONFIG_3C515

   1  1   CONFIG_60XX_WDT

   3  1   CONFIG_6PACK

   1  1   CONFIG_6xx

   1  1   CONFIG_82C710_MOUSE

   1<**>  CONFIG_8xx

   2  1   CONFIG_A2065
   1  1   CONFIG_A2091_SCSI

   1  1   CONFIG_A3000_SCSI

   1<**>  CONFIG_A4000T_SCSI
   1<**>  CONFIG_A4091_SCSI

   1<**>  CONFIG_ABSTRACT_CONSOLE

   1  1   CONFIG_AC3200
   1  1   CONFIG_ACENIC
   1  1   CONFIG_ACER_PICA_61
   1  1   CONFIG_ACI_MIXER
   1  1   CONFIG_ACQUIRE_WDT
   1  1   CONFIG_ACSI_MULTI_LUN
   1  1   CONFIG_ACTISYS_DONGLE

   1<**>  CONFIG_AD1816_BASE
   1<**>  CONFIG_AD1816_CLOCK
   1<**>  CONFIG_AD1816_DMA
   1<**>  CONFIG_AD1816_DMA2
   1<**>  CONFIG_AD1816_IRQ
   2  1   CONFIG_ADBMOUSE
   2<**>  CONFIG_ADDIN_FOOTBRIDGE
   1  2   CONFIG_ADFS_FS
   1<**>  CONFIG_ADVANCED
 <**> 1   CONFIG_ADVANCED_CPU

   1  1   CONFIG_AEDSP16
   4  1   CONFIG_AEDSP16_BASE
   1  1   CONFIG_AEDSP16_MPU401
   1  1   CONFIG_AEDSP16_MPU_IRQ
   1  1   CONFIG_AEDSP16_MSS
   1  1   CONFIG_AEDSP16_MSS_DMA
   1  1   CONFIG_AEDSP16_MSS_IRQ
   1  1   CONFIG_AEDSP16_SBPRO
   1  1   CONFIG_AEDSP16_SB_DMA
   1  1   CONFIG_AEDSP16_SB_IRQ

   1  1   CONFIG_AFFS_FS

   1  1   CONFIG_AGP
   1  1   CONFIG_AGP_ALI
   1  1   CONFIG_AGP_AMD
   1  1   CONFIG_AGP_I810
   1  1   CONFIG_AGP_INTEL
   1  1   CONFIG_AGP_SIS
   1  1   CONFIG_AGP_VIA

   2  1   CONFIG_AIC7XXX_CMDS_PER_DEVICE
   2  1   CONFIG_AIC7XXX_PROC_STATS
   2  1   CONFIG_AIC7XXX_RESET_DELAY
   2  1   CONFIG_AIC7XXX_TCQ_ON_BY_DEFAULT

   1  1   CONFIG_ALGOR_P4032
   1  1   CONFIG_ALIGNMENT_TRAP
   1<**>  CONFIG_ALL_PPC
   1<**>  CONFIG_ALPHA_ALCOR
   3<**>  CONFIG_ALPHA_APECS
   2<**>  CONFIG_ALPHA_AVANTI
   1<**>  CONFIG_ALPHA_BOOK1
   1<**>  CONFIG_ALPHA_CABRIOLET
   3<**>  CONFIG_ALPHA_CIA
   1<**>  CONFIG_ALPHA_DP264
   1<**>  CONFIG_ALPHA_EB164
   2<**>  CONFIG_ALPHA_EB64P
   1<**>  CONFIG_ALPHA_EB66
   1<**>  

Re: 2.2.16 SMP: mtrr errors

[Petr Vandrovec]

On 11 Dec 00 at 14:00,  Paul C. Nendick wrote:

> -Matrox g450 32MB RAM dual-heal AGP video card w/ hand compiled X driver
>  from matrox

Make sure you do not use either matroxfb or XFree's driver... Same chip
ID, but different ramdac :-(
 
> and immediately after starting X:
> 
> kernel: mtrr: base(0xd400) is not aligned on a size(0x180) boundary
> last message repeated 2 times

For some strange reason X thinks that you have 24MB of memory on the G450.
You can either create 32MB write-combining region at 0xd400, or
teach X that your device occupies 32MB and not 24 (you should do it anyway,
region size can be only power of two)...

> and finally:
> 
> %cat /proc/mtrr 
> reg00: base=0x (   0MB), size= 256MB: write-back, count=1
> reg01: base=0xd000 (3328MB), size=  64MB: write-combining, count=1
> reg02: base=0xd580 (3416MB), size=   8MB: write-combining, count=1
+ reg03: base=0xd400 (MB), size=  32MB: write-combining, count=1

Petr Vandrovec
[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: UP 2.2.18 makes kernels 3% faster than UP 2.4.0-test12

[Linus Torvalds]

On Tue, 12 Dec 2000, Steven Cole wrote:
> 
> Task: make -j3 bzImage for 2.4.0-test12-pre7 kernel tree.

Actually, do it with

make -j3 'MAKE=make -j3' bzImage

A single "-j3" won't do much. It will only build three directories at a
time, and you'll never see much load. But doing it recursively means that
you'll build three at a time all the way out to the leaf directories, and
you should see loads up to 20+, and much more memory pressure too.

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: how to capture long oops w/o having second machine

[Mohammad A. Haque]

Nope, this didn't fly. Would have been neat if it did work. Maybe it can
be made to work for future use?

On Tue, 12 Dec 2000, Greg KH wrote:

> I don't know if /dev/ttyUSBX would work, but I think it would.  People
> have successfully run consoles through the usb-serial drivers, but I'm
> not sure if the oops main console requires something different (like
> registering itself actually as a console?)
>
> And then there's the nice problem of the fact that if the oops comes
> from the USB code, you will not see it come out the usb-serial driver :)
>
> Let me know if you try this, and have any success (or find that it
> doesn't work.)

-- 

=
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: pdev_enable_device no longer used ?

[David S. Miller]

   Date: Tue, 12 Dec 2000 20:17:21 +0100 (CET)
   From: Gérard Roudier <[EMAIL PROTECTED]>

   On Mon, 11 Dec 2000, David S. Miller wrote:

   > Tell me one valid use of this information first :-)

   SCRIPTS. Have a look into my kind :-) response to Martin.

Ok, this I understand.

   > b) If you wish to interpret the BAR values and use them from a BUS
   >perspective somehow, you still need to go through some interface
   >because you cannot assume what even the hw BAR values mean.
   >This is precisely the kind of interface I am suggesting.

   The BAR values make FULL sense on the BUS.

I am saying there may be systems where it does not make any sense,
f.e. actually used bits of BAR depend upon whether CPU, or DEVICE on
that bus, or DEVICE on some other bus make the access.

Forget all the PCI specifications, it is irrelevant here.  All your
PCI expertiece means nothing, nor mine.  People build dumb machines
with "PCI implementations" and we need to handle them.

   I will wait for your .txt file that describes your idea. Your
   documentation about the new DMA mapping had been extremally useful.
   Let me thank you again for it.

It requires no .txt file :-), it will just be formalization of
existing bus_to_dvma_whatever hack :-) Specify PDEV (device) and
RESNUM (which I/O or MEM resource for that device), returns either
error or address as seen by BUS that PDEV is on.  You may offset
this return value as desired, up to the size of that resource.

I could make a more elaborate interface (add new parameter,
PDEV_MASTER which is device which wishes to access area described by
PDEV+RESNUM), allowing full PCI peer-to-peer setup, as described by
someone else in another email of this thread.  This version would have
an error return, since there will be peer2peer situations on some
systems which cannot be made.  But I feel this is inappropriate until
2.5.x, others can disagree.

Later,
David S. Miller
[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: [PATCH] mdacon.c cleanup

[David Woodhouse]

[EMAIL PROTECTED] said:
> Both MODULE_PARM and __init are removed by precompiler when not
> compiler as module, so no need for ifdefs.  2.4.0-test12pre8

-#ifdef MODULE_PARM
 MODULE_PARM(mda_first_vc, "1-255i");
 MODULE_PARM(mda_last_vc,  "1-255i");
-#endif

That was #ifdef MODULE_PARM not #ifdef MODULE. Probably there for 
compatibility with older kernels. Although I'm not sure it's even required 
in 2.2.

And you seem to have forgotten to Cc the maintainer.  

--
dwmw2


-
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: 2.2.16 SMP: mtrr errors

[Paul C. Nendick]

See my answers inline below.  /paul

Mark Hahn ([EMAIL PROTECTED]) said:

> > kernel: mtrr: base(0xd400) is not aligned on a size(0x180) boundary
> 
> X is trying to set an mtrr for the framebuffer.  the odd thing
> is that its trying to set a 24M mtrr, which is pretty strange.
> what does /proc/pci look like for the G450?
> 

% cat /proc/pci
PCI devices found:
  Bus  0, device   0, function  0:
Host bridge: VIA Technologies Unknown device (rev 196).
  Vendor id=1106. Device id=691.
  Medium devsel.  Master Capable.  No bursts.  
  Prefetchable 32 bit memory at 0xd000 [0xd008].
  Bus  0, device   1, function  0:
PCI bridge: VIA Technologies VT 82C598 Apollo MVP3 AGP (rev 0).
  Medium devsel.  Master Capable.  No bursts.  Min Gnt=12.
  Bus  0, device   7, function  0:
ISA bridge: VIA Technologies VT 82C596 Apollo Pro (rev 35).
  Medium devsel.  Master Capable.  No bursts.  
  Bus  0, device   7, function  1:
IDE interface: VIA Technologies VT 82C586 Apollo IDE (rev 16).
  Medium devsel.  Fast back-to-back capable.  Master Capable.  Latency=32.  
  I/O at 0xe000 [0xe001].
  Bus  0, device   7, function  2:
USB Controller: VIA Technologies VT 82C586 Apollo USB (rev 17).
  Medium devsel.  IRQ 9.  Master Capable.  Latency=32.  
  I/O at 0xe400 [0xe401].
  Bus  0, device   7, function  3:
Host bridge: VIA Technologies Unknown device (rev 48).
  Vendor id=1106. Device id=3050.
  Medium devsel.  Fast back-to-back capable.  
  Bus  0, device  17, function  0:
Multimedia audio controller: Ensoniq AudioPCI (rev 0).
  Slow devsel.  IRQ 9.  Master Capable.  Latency=32.  Min Gnt=12.Max Lat=128.
  I/O at 0xe800 [0xe801].
  Bus  0, device  18, function  0:
Ethernet controller: Intel 82557 (rev 8).
  Medium devsel.  Fast back-to-back capable.  IRQ 11.  Master Capable.  
Latency=32.  Min Gnt=8.Max Lat=56.
  Non-prefetchable 32 bit memory at 0xda10 [0xda10].
  I/O at 0xec00 [0xec01].
  Non-prefetchable 32 bit memory at 0xda00 [0xda00].
  Bus  1, device   0, function  0:
VGA compatible controller: Matrox Unknown device (rev 130).
  Vendor id=102b. Device id=525.
  Medium devsel.  Fast back-to-back capable.  IRQ 10.  Master Capable.  
Latency=64.  Min Gnt=16.Max Lat=32.
  Prefetchable 32 bit memory at 0xd400 [0xd408].
  Non-prefetchable 32 bit memory at 0xd600 [0xd600].
  Non-prefetchable 32 bit memory at 0xd700 [0xd700].



> also, how do you like the G450?

My first impressions of the g450 are spectacular.  I know it's not supposed
to be as fast as the dual Nvidia offerings, but I don't play games and Matrox
has always been tops when it comes to text appearance.  It's fast as can be
driving two monitors at 1600x1200 and not too expensive to boot.  I like it.


> > I would like to know what, if anything, is wrong and what I can do about it.
> 
> worst case is that X doesn't get to set the mtrr it wants.
> this may have some performance effect, but no functionality effect.

That's good enough for me!


> regards, mark hahn.
> 
-
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: 2.2.16 SMP: mtrr errors

[John Cavan]

> kernel: mtrr: base(0xd400) is not aligned on a size(0x180) boundary
> last message repeated 2 times
> 
> and finally:
> 
> %cat /proc/mtrr
> reg00: base=0x (   0MB), size= 256MB: write-back, count=1
> reg01: base=0xd000 (3328MB), size=  64MB: write-combining, count=1
> reg02: base=0xd580 (3416MB), size=   8MB: write-combining, count=1

I'm seeing the same thing with the Matrox G400.

John
-
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: UP 2.2.18 makes kernels 3% faster than UP 2.4.0-test12

[Steven Cole]

On Tuesday 12 December 2000 11:40, Linus Torvalds wrote:
> On Tue, 12 Dec 2000, Steven Cole wrote:
> > Executive summary: SMP 2.4.0 is 2% faster than SMP 2.2.18.
>
> > I ran X and KDE 2.0 during the tests to provide a greater though
> > reproducable load on the tested kernel.
>
> You might want to do the same in 32-64MB of RAM. And actually move your
> mouse around a bit to keep KDE/X from just being paged out, at which point
> it turns un-interesting again. I don't know how to do that repeatably,
> though, but one thing I occasionally do is to read my email (which is not
> very CPU-intensive, but it does keep the desktop active and also gives me
> a feel for interactive behaviour).
>

Keeping the memory the same, I repeated the kernel builds
while moving the mouse in a similar way, and switching the
desktop 3 times, same desktops for each test. Yes, I know,
this doesn't test much more, since nothing was swapped out.

These results are even closer. The differences are so slight,
that they are not statistically significant. Hmmm, maybe no
news is good news in this case.

Perhaps if anything is interesting from this test,
it is the negative result: No significant performance
difference for this particular CPU-intensive task on only
two processors.  

I'm sure it would be fun to try this test on a GS320 32-CPU Wildfire.  
I believe a 24-CPU Sun E1 built a 2.4.0-test7 kernel in about 20 seconds.
Fun, but maybe not too meaningful. Sigh.

Task: make -j3 bzImage for 2.4.0-test12-pre7 kernel tree.
Numbers are seconds to build.

New results (with fiddling with the desktop):

 1   2   3  ave.
143 142 142 142.3   Running 2.2.18 SMP
141 141 142 141.3   Running 2.4.0-test12-pre7 SMP

Steven

-
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: pdev_enable_device no longer used ?

[Gérard Roudier]

On Mon, 11 Dec 2000, David S. Miller wrote:

>Date: Mon, 11 Dec 2000 23:07:01 +0100 (CET)
>From: Gérard Roudier <[EMAIL PROTECTED]>
> 
>So, if you want to fix this insane PCI interface:
> 
>1) Provide the _actual_ BARs values in the pci dev structure, otherwise 
>   drivers that need them will have to deal with ugly hackery or access 
>   explicitely the PCI configuration space.
> 
> Tell me one valid use of this information first :-)

SCRIPTS. Have a look into my kind :-) response to Martin.

By the way, the genuine physical addresses, alias pcidev cookies, as seen
from the CPU have exactly NO USE at all, except as input for ioremap().
Drivers can throw them away after that. So, given correct design they
should not even have to deal with them.

> a) If you want to use it to arrive at addresses MEM I/O operations
>you need to go through something akin to ioremap() first anyways.

ioremap() is the historical successor of vremap(). Without vremap(), it
may well never have existed.

> b) If you wish to interpret the BAR values and use them from a BUS
>perspective somehow, you still need to go through some interface
>because you cannot assume what even the hw BAR values mean.
>This is precisely the kind of interface I am suggesting.

The BAR values make FULL sense on the BUS.

>Consider even just that top few bits of BAR values on some system
>have some special meaning, and must be masked out before used from
>PCI device side transactions.  Perhaps these bits are interpreted
>somehow at the host bridge when CPU accesses to device MEM or I/O
>space are made.  I argue not that this is compliant behavior, I
>argue only that it is something idiots designing hardware will in
>fact do.  We have seen worse things occur.  Now, subsequently, if
>we start using raw BARs in drivers these systems (however important
>or not important) will become difficult to impossible to support.
>Here the blacklists will end up in your driver, which is where I
>think both of us will agree they should not be :-)

Read my reply to Martin on that point. 

>2) Provide an interface that accepts the PCI dev and the BAR offset as
>   input and that return somes cookie for read*/write* interface.
> GiveMeSomeCookieForMmIo(pcidev, bar_offset).
> 
> I do not understand why ioremap() is such a bletcherous interface
> for you :-)  You take resource in PDEV, add desired offset, and pass
> it to ioremap().  What about this sequence requires you to take pain
> killers? :-)  It seems quite straightforward to me.

I can live perfectly with ioremap(). :-))

> We do not want to expose physical BARs because you as a driver have
> no way to portably interpret this information.  On the other hand
> if you tell us "Given PDEV resource X, plus offset Y, give me this
> address in BUS space" we can do that and that is the interface that
> makes sense and is implementable on all architectures.  This is what
> I am proposing for adding asm/pci.h
> 
> Having people read and intepret BARs is not implementable on all
> architecures (see discussion in (b) above).
> 
> I guess there is some fundamental reason you do not like the kernel
> trying to discourage access to physical BARs.  This makes things so
> much easier and cleaner, at least to me.
> 
> I bet we end up in standstill here and ifdef hacks remain in symbios
> drivers :-)))  We will see...

I will wait for your .txt file that describes your idea. Your
documentation about the new DMA mapping had been extremally useful.
Let me thank you again for it.

Bye,
  Gérard.

-
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: [BUG] raid5 crash with 2.4.0-test12 [Was: Linux-2.4.0-test12]

[Jasper Spaans]

On Wed, Dec 13, 2000 at 06:56:22AM +1100, Neil Brown wrote:

> Guilt by association :-)
> 
> What this bit of code (complete_stripe/raid5_end_buffer_io) is doing
> is observing that it as completed some I/O request that was made of
> the raid5 device and is calling the b_end_io on the buffer_head that
> is was passed.  So it is not one of raid5's buffers that has the bad
> b_end_io, but someone else's buffer that raid5 was asked to service.
> 
> You say "things with a mysql-db on a raid5-device".  Can I interpret
> this to mean that mysql was talking driectly to /dev/md0, or is there
> some filesystem in-between?
> Either way, I expect Linus' suggestion will provide the answer.

Will try to reproduce this, with Linus' suggestion; btw, this mysql-db is
running on ext2, nothing exotic.

Regards,
-- 
  Q_.Jasper Spaans  -o)
 `~\ Conditional Access/DVB-C/OpenTV/Unix-adviseur/\\
Mr /\_\_v
Zap Een ongezellig dure consultant nodig? Mail [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/

2.2.16 SMP: mtrr errors

[Paul C. Nendick]

Please cc: any responses to my email address <[EMAIL PROTECTED]>

My setup
-A standard install of RedHat 7.0 with the 2.2.16smp w/ hand compiled X
 4.0.1 to support xinerama
-Tyan tiger 133 s1834 motherboard (VIA Apollo Pro133A Chipset)
-256mb PC133 RAM
-Two 800 Mhz PIII eb Slot-1 CPU's
-Matrox g450 32MB RAM dual-heal AGP video card w/ hand compiled X driver
 from matrox

My problem
from /var/log/message at startup:

mtrr: v1.35a (19990819) Richard Gooch ([EMAIL PROTECTED])

CPU0: Intel Pentium III (Coppermine) stepping 03

CPU1: Intel Pentium III (Coppermine) stepping 03
Total of 2 processors activated (3194.88 BogoMIPS).

checking TSC synchronization across CPUs: passed.
mtrr: your CPUs had inconsistent variable MTRR settings
mtrr: probably your BIOS does not setup all CPUs

and immediately after starting X:

kernel: mtrr: base(0xd400) is not aligned on a size(0x180) boundary
last message repeated 2 times

and finally:

%cat /proc/mtrr 
reg00: base=0x (   0MB), size= 256MB: write-back, count=1
reg01: base=0xd000 (3328MB), size=  64MB: write-combining, count=1
reg02: base=0xd580 (3416MB), size=   8MB: write-combining, count=1

I would like to know what, if anything, is wrong and what I can do about it.

Cheers!

/paul

-
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: pdev_enable_device no longer used ?

[Gérard Roudier]

On Tue, 12 Dec 2000, Martin Mares wrote:

> Hello!
> 
> > It is the bar cookies in pci dev structure that are insane, in my opinion.
> > 
> > If a driver needs BARs values, it needs actual BARs values and not some
> > stinking cookies. What a driver can do with BAR cookies other than using
> > them as band-aid for dubiously designed kernel interface.
> 
> If a driver wants to know the BAR values, it can pick them up in the configuration
> space itself. The problem is that these values mean absolutely nothing outside

The return value makes FULL sense on the BUS on which _real_ PCI
transactions will happen for old SYMBIOS devices and will hint recent ones
about using internal cycles instead (that are PCI 2.2 compliants) for
accessing the on chip-RAM.

As seen from the BUS and thus from the PCI device, all the opaque
inventions of O/Ses are just irrelevant sci-fi.

By the way, the hack that used bus_dvma_to_mem() from the BAR cookies is
not from me, but from David S. Miller. This will be fixed as you suggest.

> the bus the device resides on. There exist zillions of translating bridges
> and no driver except for the driver for the particular bridge should ever
> assume anything about them.

You seem to know well PCI but, in my opinion, you still have to learn much
about it and about what reality is.

You should repeat hundred times:

"It is not Gérard neither the sym driver that wants to know about
 BARs"

But,

"They are these damned PCI specifications that based everything on 
 actual BUS address comparators and the NCR/SYMBIOS ingenieers 
 that based memory related SCRIPTS instructions on actual adresses
 as seen from the BUS, and btw, as suggested by the specifications."


> The values in pci_dev->resource[] are not some random cookies, they are
> genuine physical addresses as seen by the CPU and as accepted by ioremap().

These cookies are confusing a lot and useless given a correct design of
related kernel interfaces. There is plenty of room in the pcidev structure
for private informations that would have avoided these stupid cookies.

In fact, these cookies are still there for historical reasons when
MMIO-capable PCI device driver(s) had to use vremap() on actual BAR
addresses. This only worked on Intel.

  Gérard.

-
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: Bad behavior of recv on already closed sockets.

[kuznet]

Hello!

> > It would be better to understand the issue f.e. trying to restore
> > the history of this descriptor.
> 
> How to do this? I mean what should I do to provide you with more information?

I do not know exactly. It depends on curcumstances, frequency 
of the stalls and... your luck. 8)

Usually in such cases I ask to start from gathering single huge
binary tcpdump (tcpdump -i lo -b ip -w big.dump port 3994)
until the problem happens. Then you cut of it the problematic session
with tcpdump again (tcpdump -n -vvv -r big.dump port 2994 and port 5432).
Then we will have at least picture at network side.

If after this we will not understand what happened then tracing
at application level. It is more complicated and depends mostly
on particular application. strace is too promiscuous as rule
and does not work well with intensively forking applications.

Alexey
-
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-usb-devel] PROBLEM: USB (MS Intellimouse specifically) does not work with SMP Linux 2.2.18.

[Stephen J. Gowdy]

Hi,
Have you tried setting MPS to 1.1 in your bios (instead of 1.4)?
This seems to be needed for 2.2.x kernels but not 2.4.x.

regards,

Stephen.

--
 /--+-=-=-=-=-+-\
|Stephen J. Gowdy   |A4000/040| Mail Stop 50A-2160, LBL, |
|http://www.ph.ed.ac.uk/~gowdy/ | 1GB   HD| 1 Cyclotron Rd, Berkeley,|
|   |20MB  RAM| CA 94720, USA|
|InterNet: [EMAIL PROTECTED]   |3.4xCDROM| Tel: +1 510 495 2796 |
 \--+-=-=-=-=-+-/

-
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: [BUG] raid5 crash with 2.4.0-test12 [Was: Linux-2.4.0-test12]

[Linus Torvalds]

On Tue, 12 Dec 2000, Jasper Spaans wrote:

> On Mon, Dec 11, 2000 at 06:52:55PM -0800, Linus Torvalds wrote:
> > 
> > Ok, there it is. Noticeable changes from pre8 are mainly (a) new tq list
> > compile fixes and (b) the NetApp snapshot thing.
> 
> >  - final:
> > - Neil Brown: raid and md cleanups
> 
> Hmm, while doing some not-so-heavy things with a mysql-db on a raid5-device
> this kernel Oopsed on me; ksymoops output [which went through klogd,
> shouldn't matter that much, klogd was using the right System.map]:
> 
> Dec 12 14:04:50 spaans kernel: invalid operand: 
> Dec 12 14:04:50 spaans kernel: CPU:1
> Dec 12 14:04:50 spaans kernel: EIP:0010:[end_buffer_io_bad+85/92]
>
> Dec 12 14:04:50 spaans kernel: Call Trace:
>   [raid5_end_buffer_io+68/128]
>   [complete_stripe+151/272]
>   [handle_stripe+331/1092]
>   [raid5d+173/260]
>   [md_thread+299/508]

Looks like somebody didn't initialize the "b_end_io" pointer - the code
defaults to it being "end_buffer_io_bad" (which oopses unconditionally on
purpose exactly to find places where it wasn't initialized).

And it obviously looks like it's the raid5 code that does it.

It _looks_ like the raid5 code does a "generic_make_request()" without
setting b_end_io anywhere, but I don't know the raid5 code well enough.

To get better debug output, could you please do something for me? 

In fs/buffer.c, get rid of "end_buffer_io_bad" completely, and replace all
users of it with NULL.

Then, in drivers/block/ll_rw_block.c: generic_make_request(), add a test
like

if (!bh->b_end_io) BUG();

to the top of that function.

You'll still get a oops, but the difference is that you'll get the oops
when the request is queued, rather than when the requst is finished, which
will make it easier to figure out what the thing is that leads up to this.

In the meantime I'm sure Neil can figure out where in the raid5 code we
don't initialize the buffer head properly even without that, but it's
worth doing the above anyway.

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/

NFSv3 Bugreport

[Dennis Johannßen]

NFSv3-Kernel-Server:
Debian potato linux-2.2.16  
mount-2.10f

NFSv3-Kernel-Client(-Support)  
Debian woodylinux-2.4.0-test10
mount-2.10q


There is a Bootwarning message, when the /etc/init.d/mountnfs.sh script   
performs the command 'mount -a -t nfs':

<-- Error Message -->

call_verify: server accept status: 2
call_verify: server accept status: 2
call_verify: server accept status: 2
RPC: garbage, exit EIO
nfs_get_root: getattr error = 5

<-- End of Error mesasge -->

This message is shown for each NFS-Share I want to mount.

-
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: 2.4.0-test12 not liking high disk i/o

[Niels Kristian Bech Jensen]

On Tue, 12 Dec 2000, Mohammad A. Haque wrote:

> i440BX is consistent with mine as is running the drive at UDMA33.
>
> > It happened when I decided to copy old 18GB IDE disk to new 40GB IDE one
> > (both UDMA33, one (18GB src) as primary master, one (40GB dst) as
> > secondary master; i440BX).
>
My system is an old 486DX4-100MHz (AMD processor), SiS 85C496 chipset,
and no UDMA33.

-- 
Niels Kristian Bech Jensen -- [EMAIL PROTECTED] -- http://www.image.dk/~nkbj/

--->>  Stop software piracy --- use free software!  <<---

-
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: UP 2.2.18 makes kernels 3% faster than UP 2.4.0-test12

[Linus Torvalds]

On Tue, 12 Dec 2000, Steven Cole wrote:
> 
> Executive summary: SMP 2.4.0 is 2% faster than SMP 2.2.18.

Note that kernel compilation really isn't a very relevant benchmark,
because percentage differences in this range can be basically just noise:
things like driver version differences that show up, but impact different
machines different ways (maybe one driver is better for certain machines,
and worse on others. Things like that).

The setup you descibe is just too CPU-intensive, with little potential for
truly interesting differences.

> I ran X and KDE 2.0 during the tests to provide a greater though
> reproducable load on the tested kernel.  

You might want to do the same in 32-64MB of RAM. And actually move your
mouse around a bit to keep KDE/X from just being paged out, at which point
it turns un-interesting again. I don't know how to do that repeatably,
though, but one thing I occasionally do is to read my email (which is not
very CPU-intensive, but it does keep the desktop active and also gives me
a feel for interactive behaviour).

At that point the numbers are probably going to show more difference (and
the variation is probably going to be much bigger).

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/

[OOPS] 2.4.0-test12 with heavy file manipulation

[Olivier Cahagne]

(please CC me when replying as I follow this list on the Web)

[1.] One line summary of the problem:
2.4.0-test12 non-fatal oops while copying files or doing shell file name 
completion.

[2.] Full description of the problem/report:
With 2.4.0-test12, I got a non reproducible oops after having compiled 
XFree 4.0.2 from CVS and copying files and doing shell file name completion.
Even after oopsing, I could ssh on this machine and still type 'ls' or 
things like this but completion would oops one more time, then, with the 
time, 'uptime' would oops too, and ssh wouldn't work anymore.
Ctrl-Alt-Del on the console would oops again and again so I was forced 
to power off the machine manually (ext2 wasn't corrupt when I rebooted, 
a simple fsck and the machine actually runs fine).

I suspect it deals with ext2 filesystem manipulation as this kernel 
oopsed after compiling XFree 4.0.2 and Mesa 3.4, copying various 
TrueType fonts in a directory on the same ext2 filesystem.

I've been testing every 2.4.0 kernel since test1 and all of them ran 
successfully on this machine.

[3.] Keywords (i.e., modules, networking, kernel):
ext2, filesystem

[4.] Kernel version (from /proc/version):
Linux version 2.4.0-test12 (root@pc2) (gcc version egcs-2.91.66 
19990314/Linux (egcs-1.1.2 release)) #1 mar déc 12 16:13:44 GMT-5 2000

[5.] Output of Oops.. message (if applicable) with symbolic information
  resolved (see Documentation/oops-tracing.txt)

ksymoops 2.3.5 on i586 2.4.0-test12.  Options used
  -V (default)
  -k /proc/ksyms (default)
  -l /proc/modules (default)
  -o /lib/modules/2.4.0-test12/ (default)
  -m /boot/System.map-2.4.0-test12 (specified)

Dec 12 21:11:20 pc2 kernel: Unable to handle kernel paging request at 
virtual address 30c0cc80
Dec 12 21:11:20 pc2 kernel: c0141dc7
Dec 12 21:11:20 pc2 kernel: *pde = 
Dec 12 21:11:20 pc2 kernel: Oops: 
Dec 12 21:11:20 pc2 kernel: CPU:0
Dec 12 21:11:20 pc2 kernel: EIP:0010:[find_inode+27/84]
Dec 12 21:11:20 pc2 kernel: EFLAGS: 00010217
Dec 12 21:11:20 pc2 kernel: eax: c7fe   ebx: 30c0cc60   ecx: 
001a   edx: 0001c4e2
Dec 12 21:11:20 pc2 kernel: esi: 30c0cc60   edi:    ebp: 
c7fecf88   esp: c60adeb8
Dec 12 21:11:20 pc2 kernel: ds: 0018   es: 0018   ss: 0018
Dec 12 21:11:20 pc2 kernel: Process zsh (pid: 374, stackpage=c60ad000)
Dec 12 21:11:20 pc2 kernel: Stack: 0001c4e2  0001c4e2 c7f8fe00 
c0142198 c7f8fe00 0001c4e2 c7fecf88
Dec 12 21:11:20 pc2 kernel:  0001c4e2 c7c632e0 
c71ae900 c71ae95c c7fecf88 c015054b
Dec 12 21:11:20 pc2 kernel:c7f8fe00 0001c4e2   
fff4 c7c632e0 c71ae900 c4b342b0
Dec 12 21:11:20 pc2 kernel: Call Trace: [iget4+76/220] 
[ext2_lookup+91/136] [real_lookup+82/192] [path_walk+1459/2076] 
[getname+92/160]
[__user_walk+60/88] [sys_stat64+22/112]
Dec 12 21:11:20 pc2 kernel: Code: 39 53 20 75 24 8b 54 24 14 39 93 8c 00 
00 00 75 18 85 ff 74
Using defaults from ksymoops -t elf32-i386 -a i386

Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
0:   39 53 20  cmp%edx,0x20(%ebx)
Code;  0003 Before first symbol
3:   75 24 jne29 <_EIP+0x29> 0029 Before 
first symbol
Code;  0005 Before first symbol
5:   8b 54 24 14   mov0x14(%esp,1),%edx
Code;  0009 Before first symbol
9:   39 93 8c 00 00 00 cmp%edx,0x8c(%ebx)
Code;  000f Before first symbol
f:   75 18 jne29 <_EIP+0x29> 0029 Before 
first symbol
Code;  0011 Before first symbol
   11:   85 ff test   %edi,%edi
Code;  0013 Before first symbol
   13:   74 00 je 15 <_EIP+0x15> 0015 Before 
first symbol

Dec 12 21:13:57 pc2 kernel: Unable to handle kernel NULL pointer 
dereference at virtual address 0018
Dec 12 21:13:57 pc2 kernel: c01329b6
Dec 12 21:13:57 pc2 kernel: *pde = 
Dec 12 21:13:57 pc2 kernel: Oops: 
Dec 12 21:13:57 pc2 kernel: CPU:0
Dec 12 21:13:57 pc2 kernel: EIP:0010:[try_to_free_buffers+54/368]
Dec 12 21:13:57 pc2 kernel: EFLAGS: 00010207
Dec 12 21:13:57 pc2 kernel: eax:    ebx:    ecx: 
c1124b08   edx: 
Dec 12 21:13:57 pc2 kernel: esi:    edi: c609e660   ebp: 
   esp: c1237f90
Dec 12 21:13:57 pc2 kernel: ds: 0018   es: 0018   ss: 0018
Dec 12 21:13:57 pc2 kernel: Process bdflush (pid: 5, stackpage=c1237000)
Dec 12 21:13:57 pc2 kernel: Stack: c10d4fe0 c10d4fc4 c021a3f8  
c609e660  c012a14f c10d4fc4
Dec 12 21:13:57 pc2 kernel: c1236000 c0282c7c  
0008e000 0021  
Dec 12 21:13:57 pc2 kernel:3b48  c0132e3f 0003 
 00010f00 c7ff3f8c c7ff3fd8
Dec 12 21:13:57 pc2 kernel: Call Trace: [page_launder+795/2056] 
[bdflush+127/260] [kernel_thread+35/48]
Dec 12 21:13:57 pc2 kernel: Code: 8b 50 18 8b 40 10 83 e2 46 8b 76 28 09 

Re: UP 2.2.18 makes kernels 3% faster than UP 2.4.0-test12

[Steven Cole]

On Monday 11 December 2000 11:46, Alan Cox wrote:
>
> Its an interesting demo that 2.4 has some performance problems since 2.2
> is slower than 2.0 although nowdays not much.

Results for SMP 2.2.18 vs SMP 2.4.0-test12 are in.
I repeated my earlier tests on a much faster dual P-III machine.

Executive summary: SMP 2.4.0 is 2% faster than SMP 2.2.18.

Although I made the following changes in the test procedure, these
tests for 2.2.18 and 2.4.0-test12 were held under identical conditions.

I used make -j3 bzImage for these tests on this SMP machine.
The test machine is a dual P-III (733 Mhz), 256MB, IDE.

I ran X and KDE 2.0 during the tests to provide a greater though
reproducable load on the tested kernel.  

The 2.2.18 kernel used was the final 2.2.18.

The 2.4.0-test12 is still 2.4.0-test12-pre7 since test12(final)
does not yet build with reiserfs. Team Reiser is working on this.

Here are the numbers I got.  Again, three runs each were done.
Task: make -j3 bzImage for 2.4.0-test12-pre7 kernel tree.
Numbers are seconds to build.

 1   2   3  ave.
143 143 143 143 Running 2.2.18 SMP
140 140 140 140 Running 2.4.0-test12-pre7 SMP

The numbers are very repeatable, as you can see.

This time, 2.4.0-test12 wins by 2%.  Recounts can be performed
by anyone, anytime.

Steven
-
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: how to capture long oops w/o having second machine

[Andreas Bombe]

On Tue, Dec 12, 2000 at 09:34:30AM -0500, Mohammad A. Haque wrote:
> Someone gave me a really awesome idea about possibly using a palm pilot
> to capture the oops. Anyone know if it will be a problem using
> /dev/ttyUSB0 as the serial port?

The driver itself has to provide support for serial console.  If the USB
serial driver doesn't (I don't know) it won't work.  Check the config
options for USB serial, if it doesn't offer an option for console on USB
serial port then you're out of luck.

Unless the USB serial driver in some strange way hooks into the standard
serial driver, but then someone more knowledgeable should answer that
question.

-- 
 Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/
-
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: 2.4.0-test12 not liking high disk i/o

[Mohammad A. Haque]

i440BX is consistent with mine as is running the drive at UDMA33.

> It happened when I decided to copy old 18GB IDE disk to new 40GB IDE one
> (both UDMA33, one (18GB src) as primary master, one (40GB dst) as
> secondary master; i440BX).

-- 

=
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: [linux-usb-devel] PROBLEM: USB (MS Intellimouse specifically) does not work with SMP Linux 2.2.18.

[Pete Toscano]

what mobo/chipset are you using?  i and a bunch of other people have
been having very similar problems with this and the 2.4.0-test kernels.
we all use the tyan tiger 133 mobo with the apollo pro 133a chipset.  i
believe that the 2.2.18 usb support has been pulled from the 2.4.0-test
source, so i'm not surprised to be seeing this.

on the linux-usb list, i was talking with johannes erdfel and doing some
checks for him.  he thinks that it's a pci irq problem as the usb
controller (uhci and usb-uhci) don't get any interrupts on smp-enabled
kernels when apic is enabled.  i've written martin mares about this (but
to the email address listed on his web page -- not [EMAIL PROTECTED], yet -- so
it probably got dropped into /dev/null) and i'm eager to hear his
opinion on matters.  i'll bet that now that the problem has moved into
the 2.2 line, we'll be seeing more noise about it.

laramie, try disabling apic at the lilo prompt (add "noapic" after your
kernel image's name) and see if that helps.  

pete

On Tue, 12 Dec 2000, Greg KH wrote:

> On Tue, Dec 12, 2000 at 02:07:59PM -, Laramie Leavitt wrote:
> > [1.] One line summary of the problem:
> > USB (MS Intellimouse specifically) does not work with SMP kernel 2.2.18.
> > 
> > [2.] Full description of the problem/report:
> > When trying to install a Microsoft Intellimouse Explorer (USB)
> > to a SMP kernel, I get the following error multiple times:
> > 
> > usb.c: USB device not accepting new address (error=-110)
> 
> What's your BIOS setting for MSR?
> 
> And how about the contents of /proc/interrupts?
> 
> This is a case of when the usb code isn't getting the hardware interrupt
> delivered properly.
> 
> thanks,
> 
> greg k-h

-- 
Pete Toscanop:[EMAIL PROTECTED] w:[EMAIL PROTECTED]
GPG fingerprint: D8F5 A087 9A4C 56BB 8F78  B29C 1FF0 1BA7 9008 2736

 PGP signature

A workload to detect fs corruption?

[Lorenzo Allegrucci]

http://www.eecs.harvard.edu/~keith/usenix96/aging.tar.gz

It's a good and 100% reproducible workload, I think.
BTW, does test12 solve the fs corruption once and for all?

--
Lorenzo
-
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.4.0-test12 won't boot in my Pentium 100Mhz,32MB RAM, SIS motherboard computer

[Juan]

It hangs after "Booting the kernel.ok"

Bye!!!
-- 
D. Juan Piernas Cánovas
Departamento de Ingeniería y Tecnología de Computadores
Facultad de Informática. Universidad de Murcia
Campus de Espinardo - 30080 Murcia (SPAIN)
Tel.: +34968367657Fax: +34968364151
email: [EMAIL PROTECTED]
PGP public key:
http://pgp.rediris.es:11371/pks/lookup?search=piernas%40ditec.um.es=index
-
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] local APIC and NMI watchdog on UP P6 systems

[Mikael Pettersson]

An updated version of the UP-APIC patch for Intel P6 processors
is now available at:

http://www.csd.uu.se/~mikpe/linux/upapic/

The current version is intended for 2.4.0-test12 final.

This version is based on Ingo Molnar's upapic-2.4.0-test9-F8 patch,
with add-on patches from Maciej W. Rozycki and myself. I'm
intending to maintain it until it gets into 2.4 or 2.5.

I've used it since test10-pre and believe it to be safe for
general use, but more testers are welcome.

For those unfamiliar with the patch:
- It enables the local APIC found in most P6 family processors,
  even on UP systems which often keep it disabled.
- The NMI watchdog now works on UP systems too. This is interesting
  primarily for kernel hackers wishing to debug lockups.
- A properly enabled local APIC is a prerequisite for interrupt-
  driven use of the performance-monitoring counters.

/Mikael
-
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/

Still "eth0: trigger_send() called with the transmitter busy" in 2.4.0-test12

[Juan]

Hi!

This error exists since 2.4.0-test10preX or so. It occurs when the
network interface is activated.

I'm using RedHat 7.0 and my ethernet card is a "Kingston EtheRx KNE20
Plug and Play ISA Adapter". I'm unable to access the Internet because
the ethernet card doesn't work :-(. Besides, the card uses two
interrupts (?) and there are two interfaces (eth0 y eth1) when I have
only one (?).

Besides, mouse stops working and hangs the computer if the network
interface is deactivated and I rerun the gpm program. Maybe, my hardware
is buggy but it works fine with 2.2.18.

Bye!
-- 
D. Juan Piernas Cánovas
Departamento de Ingeniería y Tecnología de Computadores
Facultad de Informática. Universidad de Murcia
Campus de Espinardo - 30080 Murcia (SPAIN)
Tel.: +34968367657Fax: +34968364151
email: [EMAIL PROTECTED]
PGP public key:
http://pgp.rediris.es:11371/pks/lookup?search=piernas%40ditec.um.es=index

   CPU0   
  0:  11683  XT-PIC  timer
  1:258  XT-PIC  keyboard
  2:  0  XT-PIC  cascade
  5:  1  XT-PIC  NE2000
 10:  0  XT-PIC  es1371
 12:  0  XT-PIC  NE2000
 14:   3047  XT-PIC  ide0
 15:  6  XT-PIC  ide1
NMI:  0 
LOC:  0 
ERR:  0



-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0213-0213 : isapnp read
0240-025f : eth1
02f8-02ff : serial(auto)
0300-031f : eth0
0376-0376 : ide1
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(auto)
0a79-0a79 : isapnp write
0cf8-0cff : PCI conf1
e000-e00f : VIA Technologies, Inc. Bus Master IDE
  e000-e007 : ide0
  e008-e00f : ide1
e800-e83f : Ensoniq ES1371 [AudioPCI-97]
  e800-e83f : es1371



Card 1 'KTC2000:Kingston EtheRx KNE20 Plug and Play ISA Adapter' PnP version 1.0 
Product version 1.0
  Logical device 0 'RTL8019:Unknown'
Supported registers 0x2
Compatible device PNP80d6
Device is active
Active port 0x,0x,0x,0x,0x,0x,0x,0x
Active IRQ 255 [0xff],255 [0xff]
Active DMA 255,255
Active memory 0x,0x,0x,0x
Resources 0
  Priority preferred
  Port 0x240-0x380, align 0x1f, size 0x20, 10-bit address decoding
  IRQ 3,4,5,2/9,10,11,12,15 High-Edge

Re: 2.4.0-test12 not liking high disk i/o

[Pete Toscano]

well, i hate to be piling on here, but i just encountered this (i think
it's this) this morning.  i was printing a 145+m file (to /dev/lp0) from
an ide drive and it locked up.  just before the lockup, i noticed it was
very sluggish, as if it were under very heavy load (which is really
wasn't).  this is on an smp-enabled machine (noapic at lilo prompt
because of the usb/pirq(?) problem).  i'm using 2.4.0-test12 on a tyan
tiger 133 (via apollo 133a chipset) mobo.  the machine has 512m memory
and another 512m in swap (didn't notice much swap activity, but i could
have missed it).  there were no messages in the logs.

if there's any info i can provide or tests i can run, just let me know.

pete

On Tue, 12 Dec 2000, Petr Vandrovec wrote:

> On 12 Dec 00 at 17:43, Niels Kristian Bech Jensen wrote:
> > On Tue, 12 Dec 2000, Mohammad A. Haque wrote:
> > 
> > > Any one else experiencing problems when they do lots of disk activity
> > > in test12?
> > >
> > Yes, I've had some complete freezes (nothing working at all) in
> > test12-pre8 and test12. They can be triggered by e.g. Netscape.
> > test12-pre7 seems to be stable.

-- 
Pete Toscanop:[EMAIL PROTECTED] w:[EMAIL PROTECTED]
GPG fingerprint: D8F5 A087 9A4C 56BB 8F78  B29C 1FF0 1BA7 9008 2736

 PGP signature

Re: [linux-usb-devel] PROBLEM: USB (MS Intellimouse specifically) does not work with SMP Linux 2.2.18.

[Johannes Erdfelt]

On Tue, Dec 12, 2000, Laramie Leavitt <[EMAIL PROTECTED]> wrote:
> [1.] One line summary of the problem:
> USB (MS Intellimouse specifically) does not work with SMP kernel 2.2.18.
> 
> [2.] Full description of the problem/report:
> When trying to install a Microsoft Intellimouse Explorer (USB)
> to a SMP kernel, I get the following error multiple times:
> 
> usb.c: USB device not accepting new address (error=-110)
> 
> If USB is compiled in, then it happens several times during the
> boot sequence.
> 
> Everything works fine on a single-processor kernel.  I have tried
> installing all of USB as modules, and I have tried compiling it
> into the kernel with no change.
> 
> System is a MSI 694D-Pro AR motherboard (Via 694X chipset)
> Dual 500 Mhz Celeron processors, 500 Mhz (Not overclocked)
> Microsoft Intellimouse explorer.
> 
> I suspect that it is an issue where locking is required,
> but none currently exists, either in mousedev, usb, or
> uhci.  (Great logic--those are the main modules that should
> be in use.) I suspect that the problem can be duplicated
> on my system under Linux 2.4.0-test11, but, alas, I cannot
> get linux 2.4 to boot right now.
> 
> I don't see the hid module in the status output like I do on
> the uni-processor kernel.  Maybe those structures need locks.

Unlikely. Many people use that particular mouse with your particular HCD
in SMP every day. Like myself. In fact I am right now, using 2.2.18.

What is more likely the cause is an IRQ routing problem.

Can you check /proc/interrupts and see if the interrupt count is going
up?

Also, can you check your BIOS and see if it is configured for MPS 1.4?
If so, change it to MPS 1.1.

JE

-
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: 2.4.0-test12 not liking high disk i/o

[ferret]

Can you tell us what controller chipset you have (output of lspci should
be fine) and if your hard drive has DMA or uDMA enabled?

There have been a few other reports of oopsen and fs corruption during
periods of high interrupt activity. Mine seems to occur whenever I
saturate my local network with traffic to/from the machine, but it is fine
if I turn DMA off (using hdparm -d0 /dev/hda)


On Tue, 12 Dec 2000, Mohammad A. Haque wrote:

> Hey guys,
> 
> Any one else experiencing problems when they do lots of disk activity
> in test12?
> 
> I was able to grab the tail end of an oops. Probably not too usefull.
> 
> Code: 89 42 04 89 10 b8 01 00 00 00 07 43 04 00 00 00 00 c7 03 00
> Aiee, killing interrupt handler
> Kernel panic: Attempted to kill the idle task!
> In interrupt handler - not syncing.
> 
> If I Alt+SysRq+s I get more oops (only tails again) and if I do it
> enough times it hits a BUG and reboots immediately.
> -- 
> 
> =
> 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/
> 

-
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/