Re: setting up pppd dial-in on linux

[J Sloan]

"Jeff V. Merkey" wrote:

> Anyone out there a whiz at setting up a pppd dialin server?  I am
> trying to put together an RPM for pppd dialin configurations
> that will support default Windows NT and Linux dial in clients
> without requiring the poor user to learn bash scripting, chat
> scripting, mgetty and inittab configuration, etc.  The steps
> in setting this up are about as easy as going on a U.N. relief
> mission to equatorial Africa, and most customers who are
> "mere mortals" would give up about an hour into it.

Red Hat's ppp client setup is about a 90 second job

> I am seeing massive problems with pppd dial-in and IP/IPX
> routing with problems that range from constant Oops, to
> the bug infested pppd daemon failing valid MD5 chap
> authentication.  The HOW-TO's and man pages provide
> wonderful commentary on all the things about pppd
> that don't work, but it's not too helpful on getting
> it to work reliably.  An NT dial-in server takes about
> 5 minutes to configure on W2K.  Linux takes about 2 days, and
> won't stay up reliably.

hmm, an awful lot of ISPs use Linux dialup servers...

I set up a linux ppp server back in 1996 - things might have
changed, but it seemed fairly straightforward at the time -

can't imagine it's gotten worse since then...

> Who out there is an expert on Linux pppd that would like
> to help put together some easy configs for standard
> dial-in scenarios?

Crunch time for me right now, finals coming right up...

I'll bet there's quite a few ISP-savvy admins who could
lend a hand though -

jjs


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

[NSOTON] Voice modem/speakerphone drivers/software?

[Mike A. Harris]

My new 56k internal modem has speakerphone jacks, etc, and voice
recording capabilities allegedly.  AOPEN 56k.  Although it works
fine (but not at 56k) for dialin, I'm wondering if I can actually
use the speakerphone and voice recording features in Linux.  The
.INF file that came with it contains stuff like:

HKR, SpeakerPhoneEnable,  1,, "at#vls=6"
HKR, SpeakerPhoneEnable,  2,, "at#cls=8"
HKR, SpeakerPhoneEnable,  3,, "at#spk=1,10,2"
HKR, SpeakerPhoneDisable,1,, "at#spk=0,16,,"
HKR, SpeakerPhoneDisable,2,, "at#vls=0"
HKR, SpeakerPhoneMute,1,, "at#vls=6"
HKR, SpeakerPhoneMute,2,, "at#spk=0,,,"
HKR, SpeakerPhoneUnMute,  1,, "at#vls=6"
HKR, SpeakerPhoneUnMute,  2,, "at#spk=1,,,"
HKR, SpeakerPhoneSetVolumeGain,  1,, "at#vls=6"
HKR, SpeakerPhoneSetVolumeGain,  2,, "at#spk=,,"

HKR, StartPlay,   1,, "at#vtx"
HKR, StopPlay,1,, "None"
HKR, StopPlay,2,, "NoResponse"
HKR, StartRecord, 1,, "at#vrx"
HKR, StopRecord,  1,, "None"
HKR, StopRecord,  2,, "NoResponse"
HKR,, TerminateRecord,,  ""
HKR,, TerminatePlay,,""
HKR,, AbortPlay,,""
HKR, LineSetPlayFormat,   1,, "at#vls=0"
HKR, LineSetRecordFormat, 1,, "None"
HKR, LineSetRecordFormat, 2,, "NoResponse"
HKR, HandsetSetRecordFormat,   1,,"at#vsr=7200"
HKR, HandsetSetRecordFormat,   2,,"at#vbs=4"
HKR, HandsetSetPlayFormat, 1,,"at#vsr=7200"
HKR, HandsetSetPlayFormat, 2,,"at#vbs=4"
HKR, OpenHandset,   1,, "at#cls=8"
HKR, OpenHandset,   2,, "at#vls=1"
HKR, CloseHandset,   1,, "at#vls=0"
HKR, CloseHandset,   2,, "at#cls=0"



I could probably script up some nasty perl to get it to work, but
does anyone know of existing software for Linux to exploit these
capabilities?  Does it need to be connected to a sound card for
actual recording, or does the DSP in the modem work?

--
  Mike A. Harris  -  Linux advocate  -  Open source advocate
  This message is copyright 2000, all rights reserved.
  Views expressed are my own, not necessarily shared by my employer.
--

Be up to date on nerd news and stuff that matters:  http://slashdot.org

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: CS4630

[David Ford]

Charles Peterman wrote:

> Thanks, I had to putz with the gain to get sound out of it without
> turning my amp to 11, but yes it works.  Do you know if anyone is
> putting in the effort to make the six channel useful?
>
> Thanks again,

Dunno about that, I use gmix for my mixer and it sounds fine, I did note that you
can't use non-powered speakers with it, the sound is awfully low.  If you use
powered speakers or pipe it out to an amp, it is perfect sounding.  That is the
only hardware issue I have.

There is also an issue with the line in, the line in level is zero unless PCM
sound is being played.  So you need to play mp3s but mute PCM in order to listen
to other inputs.

-d



begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Blue Labs Developer
x-mozilla-cpt:;14688
fn:David Ford
end:vcard

setting up pppd dial-in on linux

[Jeff V. Merkey]

Anyone out there a whiz at setting up a pppd dialin server?  I am 
trying to put together an RPM for pppd dialin configurations
that will support default Windows NT and Linux dial in clients
without requiring the poor user to learn bash scripting, chat 
scripting, mgetty and inittab configuration, etc.  The steps
in setting this up are about as easy as going on a U.N. relief
mission to equatorial Africa, and most customers who are 
"mere mortals" would give up about an hour into it.

I am seeing massive problems with pppd dial-in and IP/IPX 
routing with problems that range from constant Oops, to 
the bug infested pppd daemon failing valid MD5 chap 
authentication.  The HOW-TO's and man pages provide 
wonderful commentary on all the things about pppd 
that don't work, but it's not too helpful on getting
it to work reliably.  An NT dial-in server takes about
5 minutes to configure on W2K.  Linux takes about 2 days, and 
won't stay up reliably.  

Who out there is an expert on Linux pppd that would like
to help put together some easy configs for standard 
dial-in scenarios?

Thanks

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/

Re: Patch(?): isapnp_card_id tables for all isapnp drivers in 2.4.0-test11

[Adam J. Richter]

Keith Owens <[EMAIL PROTECTED]> wrote:
>"Adam J. Richter" <[EMAIL PROTECTED]> wrote:
>>  Note that this is not a "final" version.  I plan to go
>>through all of the changes and bracket all of these new tables
>>with #ifdef MODULE...#endif so they do not result in complaints
>>about the table being defined static and never used in cases where
>>the driver is compiled directly into the kernel.

>This is cleaner.  Append MODULE_ONLY after __initdata and remove the
>ifdef.  It increases the size of initdata in the kernel, compared to
>ifdef, but since initdata is promptly reused as scratch space it should
>not be a problem.
[patch elided]

Thanks for the patch, but I think I'll stick with the ifdefs
for now, for the following reasons.

1. I think ifdef MODULE is more understandable to the casual observer.
2. There is often some other condition that I need to combine
   with (CONFIG_PCI, CONFIG_ISAPNP, CONFIG_ISAPNP_MODULE).
3. There is often an existing ifdef in the right place that I
   can just tuck the code into.
4. I would prefer that this change not have even a file size cost
   to people who want to build minimal monolithic kernels
   for applicance applications.
5. My feeling is that just the few kilobytes of file size cost
   associated with #4 and knowing that absolutely nothing is
   added for non-module usage will psychologically make
   maintainers feel better about it and have even fewer misgivings
   about integrating it.
6. We can expect the lines bracketing these table declarations
   to be changed in the near future as the drivers are changed
   to use the new PCI and isapnp interfaces or to use the ID
   tables just to eliminate the old custom data structures that
   hold the same information.

Thanks for the patch anyhow, though.  It's a clever idea that
may be useful in other situations.

Adam J. Richter __ __   4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ /  San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l   United States of America
fax +1 408 261-6631  "Free Software For The Rest Of Us."
-
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: silly [< >] and other excess

[Albert D. Cahalan]

Russell King writes:
> Albert D. Cahalan writes:

>>> they are not only references to
>>> kernel functions, but also kernel data and read only data within
>>> the kernel text segment.
>>
>> 1. this is harmless
>> 2. this is useful (you might get a variable's name)
>
> Wrong.  Op-codes on this machine are organised such that bits 31-28
> indicate the "condition" that the instruction executes.  All 16
> combinations are meaningful.  This means that any 32-bit value can
> appear to be an instruction OR data.  It takes human intellect to
> decide which it is.  No machine can tell you that.

You haven't shown me to be wrong. How exactly is it harmful to
err on the side of doing symbol lookups that aren't required?
Maybe you'd like an example; I'll provide one below.

>> Nope. You get the unmolested oops and some symbol data.
>> If there isn't any symbol for 0x424a5149, so what? It is
>> no big deal to look up a few opcodes in the symbol table
>> by accident.
>
> But there could well be a symbol for 0xc0023004, but it also
> corresponds to the instruction:
>
>   andgt   r3, r2, r4

Yes. So what?

> "Perform a logical AND operation between r2 and r4 and place the result
>  in r3 if the condition codes indicate the `Greater Than' condition"
>
> In addition, the kernel may not be compiled to run at address 0xC...
> but at address 0x6... or maybe even 0xe...  Guess what 0xE means
> in the high nibble of the op-code?  "Always", or "Unconditional".

Again, not a problem. Here is the example:

 example crash 
kernel NULL (002c) accessed from c01a4b98
GPRs c0294041  c01a4600 000a 0200 c0258000 
OSRs  00403100 c010 0002
RAR c0105344 SP c0294080 FCR  FSR 
Stack:      
        
        
        
Trace: bad stack frame
Code: 8a739052 c00a 41310001 87052926
---

Then it gets run through a simple tool that never fails to look
up a symbol that needs to be looked up:

 example report of the above crash 
kernel NULL (002c) accessed from c01a4b98
GPRs c0294041  c01a4600 000a 0200 c0258000 
OSRs  00403100 c010 0002
RAR c0105344 SP c0294080 FCR  FSR 
Stack:      
        
        
        
Trace: bad stack frame
Code: 8a739052 c00a 41310001 87052926

Symbols:
c00a __start
c0105344 qfs_frob_directory
c01a4600 qfs_cleaner
c01a4b98 qfs_hash_file_record
---

Well, that first symbol (__start) was really "jump +10", but the
extra noise doesn't hurt anyone. You get what you need, no matter
how mangled the oops is. It can be word-wrapped, missing chunks...
The tool doesn't need to care.

Code disassembly is useful too, and again it is best to err on
the side of decoding more than is required. Remember that users
tend to mangle oops data. If the FCR register get disassembled
as a breakpoint instruction... hey, just ignore the extra noise.

When tools really try to understand an oops, they screw up.
They ignore data that should be looked up as symbols.

-
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: Can't mount SCSI CDROM in 2.4.*

[Roland Orre]

Doug Gilbert wrote:
> Roland,
> Assuming "sr" is a module and 'lsmod' doesn't
> show it as loaded then what does 'modprove sr_mod'
> report?

Thanks Doug, sometimes I'm totally blind it seems like. 
Of some reason (probably mine fault...) it seems as the flag
CONFIG_BLK_DEV_SR=y
which I've had enabled as long as I can remember of some reason was
missed when I transferred the .config file from 2.2.17 to  2.4.0

   Best regards
   Roland
-
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/

PIIX4 BX Errata for DMA errors.

[Andre Hedrick]

Anyone having DMA errors that are dmaproc: error 14, there is not a clean
workaround yet.  Also the Intel erratas state that only a bus reset will
clear the hang, but the details are loose.

Regards,

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/

Re: ext2 filesystem corruptions back from dead? 2.4.0-test11

[Andre Hedrick]

On Fri, 24 Nov 2000, Mike Ricketts wrote:

> On Fri, 24 Nov 2000, Ion Badulescu wrote:
> 
> > So I'm asking the same question, to all those who have seen unexplained
> > filesystem corruption with 2.4.0: are you using IDE drives? If the answer
> > is yes, can you check the logs and see if, at *any* point before the
> > corruption occurred, the IDE driver choked and disabled DMA for *any* of
> > your disks?
> 
> I have both IDE and SCSI drives in my machine, but have only seen
> corruption on the SCSI drives.  That doesn't mean that the problem only
> exists on the SCSI drives - they IDE ones are not frequently written to.
> I have disabled DMA myself on all my IDE drives because if I enable it,
> the IDE driver always chokes the first time they are anything like
> hammered (well, it always used to - I haven't actually tried it recently).

This is the kind of data point that is needed.
A possible storage class independent problem.
More important, what was the first kernel you began to notice this
problem.  Next, I need you to enable the DMA engine in ATA to verify that
is happening on both classes.

Cheers,

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/

Re: 2.4.0-test-11: K7 compile error: `current' missing in string macro.

[Tom Leete]

Ishikawa wrote:
> 
> 2.4.0-test-11: K7 compile error: `current' missing in string macro.
> 
> Symptom:
> 2.4.0-test11 won't compile with K7 if we choose it for CPU.
> 
> The compile error is attached at the end.
> 
> The same config except for CPU (AMD K6) works.
> The diff of config is shown immediately below.
> (I saved the old config from some early test-1x series
> compilation.)
> 
[...]
> 
> HALF-HEARTED FIX suggestion.:
> 
> I looked around and found asm/current.h had this
> #define current get_current()
> 
> 
> QUESTION: Shouldn't this code  be enabled for AMD K6-III
> (not K7), too? (It would boost the performance on this CPU if so.)
> Or does K6-III lack some instructions of 3D-Now (available
> in K7, Athlon or Duron) and so can't use these macros?
> 
> Either way, asm/current.h needs to be included
> somewhere (probably after the include statements quoted above?)

Either deselect SMP or see the patch I posted here in May. If you just keep
adding headers for stuff in_interrupt() needs, you soon hit a circular
dependency.

Tom
-
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: LKCD from SGI

[Keith Owens]

On 24 Nov 2000 16:40:50 -0700, 
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
>Peter Samuelson <[EMAIL PROTECTED]> writes:
>
>> [Matt D. Robinson]
>> > Any way we can standardize 'make install' in the kernel?  It's
>> > disturbing to have different install mechanisms per platform ...
>> > I can make the changes for a few platforms.
>> 
>> 2.5 material, already on the todo list.
>
>What is the thought on this.  There is an issue with different
>boot loaders needing rather dramatically different formats...

2.5 kernel build wish list[1] has a couple of entries for standardising
the install targets.  My thinking (and I know that some people disagree
with this) is that the standard targets of a linux compile are only

* vmlinux
* System.map
* modules in the kernel tree (not installed yet)
* any other bits and pieces that are required to compile external
  modules against this config.

The install phases are many and varied, depending on whether you are
installing on this machine, on another machine, does your boot loader
understand ELF, do you have to do the [b]zImage fiddling first, are you
doing a network boot from ROM, a network boot over tftp etc.

In current kernels the install phases are mixed in with the compile
phase which makes it difficult to handle different install targets.
2.5 will have a default make target which does the compile phase but
does nothing that is install related, i.e. default is no [b]zImage, no
modules_install etc.  There will be separate install targets for any
combination that is required and for which people can be bothered
writing the make scripts.

[1] 
ftp://ftp..kernel.org/pub/linux/kernel/projects/kbuild/makefile-wishlist-2.5-...

-
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(?): isapnp_card_id tables for all isapnp drivers in 2.4.0-test11

[Keith Owens]

On Fri, 24 Nov 2000 15:37:33 -0800, 
"Adam J. Richter" <[EMAIL PROTECTED]> wrote:
>   Note that this is not a "final" version.  I plan to go
>through all of the changes and bracket all of these new tables
>with #ifdef MODULE...#endif so they do not result in complaints
>about the table being defined static and never used in cases where
>the driver is compiled directly into the kernel.

This is cleaner.  Append MODULE_ONLY after __initdata and remove the
ifdef.  It increases the size of initdata in the kernel, compared to
ifdef, but since initdata is promptly reused as scratch space it should
not be a problem.

Index: 0-test11.1/include/linux/module.h
--- 0-test11.1/include/linux/module.h Sun, 12 Nov 2000 14:59:01 +1100 kaos 
(linux-2.4/W/33_module.h 1.1.2.1.2.1.2.1.2.1.1.3 644)
+++ 0-test11.1(w)/include/linux/module.h Sat, 25 Nov 2000 12:40:10 +1100 kaos 
+(linux-2.4/W/33_module.h 1.1.2.1.2.1.2.1.2.1.1.3 644)
@@ -261,6 +261,7 @@ extern struct module __this_module;
 #define MOD_INC_USE_COUNT  __MOD_INC_USE_COUNT(THIS_MODULE)
 #define MOD_DEC_USE_COUNT  __MOD_DEC_USE_COUNT(THIS_MODULE)
 #define MOD_IN_USE __MOD_IN_USE(THIS_MODULE)
+#define MODULE_ONLY__attribute__ ((unused))
 
 #include 
 static const char __module_kernel_version[] __attribute__((section(".modinfo"))) =
@@ -286,6 +287,7 @@ static const char __module_using_checksu
 #define MOD_INC_USE_COUNT  do { } while (0)
 #define MOD_DEC_USE_COUNT  do { } while (0)
 #define MOD_IN_USE 1
+#define MODULE_ONLY
 
 extern struct module *module_list;
 

-
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: Fasttrak100 questions...

[Andre Hedrick]

NO!

Doing so VIOLATES the terms and agreement that you obtained the BINARY
Soft-Raid Engine and the GPL terms of the kernel.

On Fri, 24 Nov 2000, James Lamanna wrote:

> So, I have a system that has 2 45GB IDE drives connected
> up to a Promise Technologies Fasttrack 100.
> Promise Techonologies currently has a driver that you can compile
> against a 2.2 kernel into a module, but it also includes one
> proprietary object file.
> During my linux installation I was able to preload the module and
> have it detect the drives fine as a scsi device, so I was able to
> install the base system onto them.
>  
> The question is, is there a way to compile this module into the kernel
> so that it will automatically detect the card? A simple linking of the
> module into the scsi library by editing the Makefile doesn't seem to do
> it. It doesn't detect the drives if I boot off of a floppy with this
> kernel on it.
> 
> Also, is it possible for Lilo to even boot this without a RAM disk
> somewhere? I guess Lilo has to know about the drive, but it can't know
> without the module...so am I screwed into using floppies with a
> RAM disk image anyways?
> 
> Thanks,
> --James Lamanna
> -
> 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/
> 

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/

2.4.0-test-11: K7 compile error: `current' missing in string macro.

[Ishikawa]

2.4.0-test-11: K7 compile error: `current' missing in string macro.

Symptom:
2.4.0-test11 won't compile with K7 if we choose it for CPU.

The compile error is attached at the end.



The same config except for CPU (AMD K6) works.
The diff of config is shown immediately below.
(I saved the old config from some early test-1x series
compilation.)


ishikawa@standard$ diff -C1 -cibw ~/config-saved /usr/src/linux/.config
*** /home/ishikawa/config-saved Fri Nov 24 13:44:30 2000
--- /usr/src/linux/.config  Sat Nov 25 09:29:17 2000
***
*** 31,34 
  # CONFIG_MPENTIUM4 is not set
! CONFIG_MK6=y
! # CONFIG_MK7 is not set
  # CONFIG_MCRUSOE is not set
--- 31,34 
  # CONFIG_MPENTIUM4 is not set
! # CONFIG_MK6 is not set
! CONFIG_MK7=y
  # CONFIG_MCRUSOE is not set
***
*** 42,46 
  CONFIG_X86_POPAD_OK=y
! CONFIG_X86_L1_CACHE_SHIFT=5
! CONFIG_X86_ALIGNMENT_16=y
  CONFIG_X86_TSC=y
  CONFIG_X86_USE_PPRO_CHECKSUM=y
--- 42,48 
  CONFIG_X86_POPAD_OK=y
! CONFIG_X86_L1_CACHE_SHIFT=6
  CONFIG_X86_TSC=y
+ CONFIG_X86_GOOD_APIC=y
+ CONFIG_X86_USE_3DNOW=y
+ CONFIG_X86_PGE=y
  CONFIG_X86_USE_PPRO_CHECKSUM=y
ishikawa@standard$

HALF-HEARTED FIX suggestion.:

I looked around and found asm/current.h had this
#define current get_current()

I thought including asm/current.h in string.h
would fix it. (And it would.)

HOWEVER, I was a little puzzled at the comment
in string.h just before the 3d-now related macros.:

#ifdef CONFIG_X86_USE_3DNOW

/* All this just for in_interrupt() ... */

#include 
#include 
#include 
#include 
#include 
#include 

/*
 *  This CPU favours 3DNow strongly (eg AMD Athlon)
 */


QUESTION: Shouldn't this code  be enabled for AMD K6-III
(not K7), too? (It would boost the performance on this CPU if so.)
Or does K6-III lack some instructions of 3D-Now (available
in K7, Athlon or Duron) and so can't use these macros?

Either way, asm/current.h needs to be included
somewhere (probably after the include statements quoted above?)

[I should not ask too much in one post, but will the kernel compiled
for AMD-K6-III work for AMD K7  Duron 750 ?
I booted the kernel compiled for K6-III on a Duron 750 PC and
it booted up to where the SCSI Symbios 58xxx driver
failed due to SCRIPT loading error or something.  Could be a motherboard

error.
I began investigating and realized the CPU mismatch, but the
new compilataion failed as noted here. But it seemed
to boot up fine up until the point, FYI.)

Observed compile error:

standard:/usr/src/linux# LC_ALL=C
standard:/usr/src/linux#
standard:/usr/src/linux#
standard:/usr/src/linux#
standard:/usr/src/linux# make bzImage
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe
-mpreferred-stack-boundary=2 -march=i686 -malign-functions=4-c -o
init/main.o init/main.c
In file included from /usr/src/linux/include/linux/irq.h:57,
 from /usr/src/linux/include/asm/hardirq.h:6,
 from /usr/src/linux/include/linux/interrupt.h:45,
 from /usr/src/linux/include/asm/string.h:296,
 from /usr/src/linux/include/linux/string.h:21,
 from /usr/src/linux/include/linux/fs.h:23,
 from /usr/src/linux/include/linux/capability.h:17,
 from /usr/src/linux/include/linux/binfmts.h:5,
 from /usr/src/linux/include/linux/sched.h:9,
 from /usr/src/linux/include/linux/mm.h:4,
 from /usr/src/linux/include/linux/slab.h:14,
 from /usr/src/linux/include/linux/malloc.h:4,
 from /usr/src/linux/include/linux/proc_fs.h:5,
 from init/main.c:15:
/usr/src/linux/include/asm/hw_irq.h: In function `x86_do_profile':
/usr/src/linux/include/asm/hw_irq.h:198: `current' undeclared (first use
in this function)
/usr/src/linux/include/asm/hw_irq.h:198: (Each undeclared identifier is
reported only once
/usr/src/linux/include/asm/hw_irq.h:198: for each function it appears
in.)
In file included from /usr/src/linux/include/asm/string.h:296,
 from /usr/src/linux/include/linux/string.h:21,
 from /usr/src/linux/include/linux/fs.h:23,
 from /usr/src/linux/include/linux/capability.h:17,
 from /usr/src/linux/include/linux/binfmts.h:5,
 from /usr/src/linux/include/linux/sched.h:9,
 from /usr/src/linux/include/linux/mm.h:4,
 from /usr/src/linux/include/linux/slab.h:14,
 from /usr/src/linux/include/linux/malloc.h:4,
 from /usr/src/linux/include/linux/proc_fs.h:5,
 from init/main.c:15:
/usr/src/linux/include/linux/interrupt.h: In function `raise_softirq':
/usr/src/linux/include/linux/interrupt.h:89: `current' undeclared (first
use in this function)
/usr/src/linux/include/linux/interrupt.h: In function
`tasklet_schedule':

Re: LKCD from SGI

[Eric W. Biederman]

Peter Samuelson <[EMAIL PROTECTED]> writes:

> [Matt D. Robinson]
> > Any way we can standardize 'make install' in the kernel?  It's
> > disturbing to have different install mechanisms per platform ...
> > I can make the changes for a few platforms.
> 
> 2.5 material, already on the todo list.

What is the thought on this.  There is an issue with different
boot loaders needing rather dramatically different formats...

Eric
-
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: Booting AMD Elan520 without BIOS

[Eric W. Biederman]

Ronald G Minnich <[EMAIL PROTECTED]> writes:

> On Fri, 24 Nov 2000, I+D wrote:
> 
> > I'm trying to boot an AMD Elan520 board without bios
> > with kernel 2.4.0-test10 configured for i486 and PCI direct access.
> > This kernel boots correctly from HD using the bios provided with the 
> > evaluation board but kernel 2.4.0-test8 and previous hang
> > after "Ok booting the kernel".
> 
> well, first I want your code for linuxbios :-)
> 
> > The last message I see is "Calibrating delay loop"
> > (I see this thaks to the Jtag debugger for Elan520 because
> > I haven't configured the VGA board yet).
> 
> you don't have clock interrupts on. If you are able to single step you'll
> probably see it in the loop spinning on jiffies. This is one of our
> regular problems with a new mainboard.

This can also easily be a misconfiguration of the local apic.
I might need to be put into virtual wire mode.

Eric

-
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] O_SYNC patch 3/3, add inode dirty buffer list support to ext2

[Eric W. Biederman]

"Jeff V. Merkey" <[EMAIL PROTECTED]> writes:

> Cool.  ORACLE is going to **SMOKE** on EXT2 with this change.



Hmm I don't see how ORACLE is going to **SMOKE**.
Last I looked ORACLE would need a query optimizer that always
would find the best possible index and much less overhead to **SMOKE**.

Last I looked table reads were 10x slower than file reads.



Eric
-
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] blindingly stupid 2.2 VM bug

[Chip Salzenberg]

According to Rik van Riel:
> Luckily my patch fixes some of the suspect areas in
> VM-global [...]

Would you say that the below patch is just the try_to_free_pages
bug fix, then?

Index: mm/vmscan.c
--- mm/vmscan.c.prev
+++ mm/vmscan.c Fri Nov 24 15:17:59 2000
@@ -401,4 +401,5 @@ int try_to_free_pages(unsigned int gfp_m
int priority;
int count = SWAP_CLUSTER_MAX;
+   int loopcount = count;
int killed = 0;
 
@@ -409,5 +410,5 @@ int try_to_free_pages(unsigned int gfp_m
 
 again:
-   priority = 5;
+   priority = 6;
do {
while (shrink_mmap(priority, gfp_mask)) {
@@ -431,5 +432,10 @@ again:
 
shrink_dcache_memory(priority, gfp_mask);
-   } while (--priority > 0);
+
+   /* Only lower priority if we didn't make progress. */
+   if (count == loopcount)
+   --priority;
+   loopcount = count;
+   } while (priority > 0);
 done:
unlock_kernel();
@@ -454,6 +460,9 @@ done:
}
 
-   /* Return success if we freed a page. */
-   return priority > 0;
+   /* Return success if we have enough free memory or we freed a page. */
+   if (nr_free_pages > freepages.low)
+   return 1;
+
+   return count < SWAP_CLUSTER_MAX;
 }
 

-- 
Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]>
   "Give me immortality, or give me death!"  // Firesign Theatre
-
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] Re: [PATCH] Latest preemptible kernel (low latency) patch available

[Roger Larsson]

Hi,

I got compilation errors due to use of START / STOP 
definitions (zlib.c, ppp?)

This little additional patch should fix it. They were not
used in any other place of the patch...

I am still compiling...

/RogerL

--- spinlock.h.preemt   Sat Nov 25 00:31:38 2000
+++ spinlock.h  Sat Nov 25 00:30:50 2000
@@ -47,21 +47,21 @@
 /*
  * Here are the basic preemption lock macros.
  */
-#define START 0
-#define STOP 1
-#define BKL pree)current)->lock_depth) != -1)
+#define PREEMPT_START 0
+#define PREEMPT_STOP 1
+#define PREEMPT_BKL pree)current)->lock_depth) != -1)
 
 #ifdef DEBUG_PREEMPT
 #define debug_lock(t) do {  \
-   if ((in_ctx_sw_off() - (BKL?1:0)) < t) \
+   if ((in_ctx_sw_off() - (PREEMPT_BKL?1:0)) 
< t) \
   SPIN_BREAKPOINT; \
  } while (0) 
 #else
 #define debug_lock(t) do {   } while (0) 
 #endif
 
-#define preempt_lock_start(c) debug_lock(START)
-#define preempt_lock_stop()   debug_lock(STOP)
+#define preempt_lock_start(c) debug_lock(PREEMPT_START)
+#define preempt_lock_stop()   debug_lock(PREEMPT_STOP)
 
 #ifdef CONFIG_PREEMPT
 #include 

-- 
Home page:
  http://www.norran.net/nra02596/
-
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/

Problems with D-link DFE550TX in 2.4.0-test10

[rob]

Hi

At boot, I get the following messages:

eth0: OEM Sundance Technology ST201 at 0xc880, 00:50:ba:14:de:30, IRQ 10.
eth0: No MII transceiver found!, ASIC status 62

it works a bit, but it freezes every so often. The card is plugged
into a 10/100 switch. When it freezes, I get the following messages:
(The link changed messages happen when I unplug the cable and put it
back in.)

Nov 24 22:44:40 linux kernel: eth0: Too much work at interrupt, status=0x0011 / 0x0401.
Nov 24 22:53:46 linux kernel: NETDEV WATCHDOG: eth0: transmit timed out
Nov 24 22:53:46 linux kernel: eth0: Transmit timed out, status c0, resetting...
Nov 24 22:53:46 linux kernel:   Rx ring c13fc940:  803c 803c 804c 803c 
804c 804a 803c 803c 803c 803c 803c 803c 803c 
803c 803c 803c 804c 803c 804c 803c 803c 803c 
803c 803c 803c 803c 804a 8042 804a 804a 803c 
804c
Nov 24 22:53:46 linux kernel:   Tx ring c13fcb40:  80018000 80018004 80018008 8001800c 
80018010 80018014 80018018 8001801c 80018020 80018024 80018028 8001802c 80018030 
80018034 80018038 8001803c
Nov 24 22:56:25 linux kernel: eth0: Link changed: Autonegotiation advertising   
partner .
Nov 24 22:56:31 linux kernel: eth0: Link changed: Autonegotiation advertising   
partner .
Nov 24 23:11:59 linux kernel: eth0: Too much work at interrupt, status=0x0011 / 0x0401.
Nov 24 23:13:36 linux kernel: NETDEV WATCHDOG: eth0: transmit timed out
Nov 24 23:13:36 linux kernel: eth0: Transmit timed out, status c0, resetting...
Nov 24 23:13:36 linux kernel:   Rx ring c13fc940:  803e 8044 8044 804a 
8044 804a 8044 803c 803c 803c 803c 803c 803c 
803c 803c 803c 803c 8044 803c 803c 803c 803c 
8044 8044 8044 803c 803c 803c 803c 803c 803e 
803e
Nov 24 23:13:36 linux kernel:   Tx ring c13fcb40:  80018000 80018004 80018008 8001800c 
80018010 80018014 80018018 8001801c 80018020 80018024 80018028 8001802c 80018030 
80018034 80018038 8001803c
Nov 24 23:13:44 linux kernel: eth0: Link changed: Autonegotiation advertising   
partner .
Nov 24 23:13:49 linux kernel: eth0: Link changed: Autonegotiation advertising   
partner .
Nov 24 23:15:33 linux kernel: eth0: Too much work at interrupt, status=0x0011 / 0x.
Nov 24 23:15:42 linux kernel: NETDEV WATCHDOG: eth0: transmit timed out
Nov 24 23:15:42 linux kernel: eth0: Transmit timed out, status c0, resetting...
Nov 24 23:15:42 linux kernel:   Rx ring c13fc940:  8062 8048 8062  
         
      803c 8062 803c 
803c 803c 803c 8062 803c 8062 8042 8046 8062 
8062
Nov 24 23:15:42 linux kernel:   Tx ring c13fcb40:  80018000 80018004 80018008 8001800c 
80018010 80018014 80018018 8001801c 80018020 80018024 80018028 8001802c 80018030 
80018034 80018038 8001803c
Nov 24 23:18:15 linux kernel: eth0: Too much work at interrupt, status=0x0011 / 0x0401.
Nov 24 23:18:24 linux kernel: NETDEV WATCHDOG: eth0: transmit timed out
Nov 24 23:18:24 linux kernel: eth0: Transmit timed out, status c0, resetting...
Nov 24 23:18:24 linux kernel:   Rx ring c13fc940:      
         
    803c 803c 8062 803c 8062 
803c 8062 803e 803c 8062 803c 8062 8040 803c 

Nov 24 23:18:24 linux kernel:   Tx ring c13fcb40:  80018000 80018004 80018008 8001800c 
80018010 80018014 80018018 8001801c 80018020 80018024 80018028 8001802c 80018030 
80018034 80018038 8001803c
Nov 24 23:23:49 linux kernel: spurious 8259A interrupt: IRQ15.
Nov 24 23:25:29 linux kernel: eth0: Too much work at interrupt, status=0x0011 / 0x0401.
Nov 24 23:25:36 linux kernel: NETDEV WATCHDOG: eth0: transmit timed out
Nov 24 23:25:36 linux kernel: eth0: Transmit timed out, status c0, resetting...
Nov 24 23:25:36 linux kernel:   Rx ring c13fc940:      
   803c 803c 803c 8062 803c 8062 
803c 803c 8062 803c      
         

Nov 24 23:25:36 linux kernel:   Tx ring c13fcb40:  80018000 80018004 80018008 8001800c 
80018010 80018014 80018018 8001801c 80018020 80018024 80018028 8001802c 80018030 
80018034 80018038 8001803c
Nov 24 23:26:10 linux kernel: eth0: Too much work at interrupt, status=0x0011 / 0x0401.
Nov 24 23:26:20 linux kernel: NETDEV WATCHDOG: eth0: transmit timed out
Nov 24 23:26:20 linux kernel: eth0: Transmit timed out, status c0, resetting...
Nov 24 

Re: Oops on 2.2.18-23 as pppd dial in server

[Jeff V. Merkey]

I always type too fast.  Yes, it's "slocate".

Jeff

"Mohammad A. Haque" wrote:
> 
> solcate? .. you sure you don't mean slocate?
> 
> "Jeff V. Merkey" wrote:
> > process solcate pid: 1109 nr: 45 stack=c17f9000
> 
> --
> 
> =
> 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/

Patch(?): isapnp_card_id tables for all isapnp drivers in 2.4.0-test11

[Adam J. Richter]

I have made added isapnp_card_id table to all isapnp drivers.
This is the isapnp equivalent of the pci MODULE_DEVICE_TABLE declarations.
They allow a user level software agent to know which modules correspond
to your hardware configuration and to load them.  One such implementation
(GPL'ed) is available from
ftp://ftp.yggdrasil.com/pub/dist/device_control/isapnpmodules/.

There previously were no isapnp_card_id tables in the kernel
drivers.  I believe this patch adds isapnp_card_id tables to all of
them, completing the coverage of Keith Owens's
/lib/modules//modules.{pci,usb,isapnp}map files.  I have
attached a patch below that covers just the files that have the
isapnp changes.  Note that it includes a couple of pci_device_id
table declarations that happened to flow into the same "diff" sections
as the isapnp_card_id declarations.  A complete set of patches
with both pci and isapnp declarations is available from

ftp://ftp.yggdrasil.com/pub/dist/device_control/kernel/pci_id_tables-2.4.0-test11.patch2.gz

Note that this is not a "final" version.  I plan to go
through all of the changes and bracket all of these new tables
with #ifdef MODULE...#endif so they do not result in complaints
about the table being defined static and never used in cases where
the driver is compiled directly into the kernel.  After 2.4.0, I
imainge most of those #ifdef MODULE conditions will go away
as the tables come to be actually used by the driver code.

Any comments are welcome.

-- 
Adam J. Richter __ __   4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ /  San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l   United States of America
fax +1 408 261-6631  "Free Software For The Rest Of Us."


--- linux-2.4.0-test11/drivers/char/serial.cMon Oct 16 12:58:51 2000
+++ linux/drivers/char/serial.c Fri Nov 24 14:07:01 2000
@@ -4682,6 +4682,287 @@
unsigned short device;
 };
 
+#define ISPNP_TBL_ENTRY(v1,v2,v3,func) { \
+   card_vendor: ISAPNP_ANY_ID, \
+   card_device: ISAPNP_ANY_ID, \
+   devs: { ISAPNP_DEVICE_ID(v1,v2,v3,func ) }, \
+}
+
+# ifdef MODULE
+static struct isapnp_card_id ixj_isa_ids[] __initdata = {
+   /* Archtek America Corp. */
+   /* Archtek SmartLink Modem 3334BT Plug & Play */
+   ISAPNP_TBL_ENTRY('A', 'A', 'C', 0x000F),
+   /* Anchor Datacomm BV */
+   /* SXPro 144 External Data Fax Modem Plug & Play */
+   ISAPNP_TBL_ENTRY('A', 'D', 'C', 0x0001),
+   /* SXPro 288 External Data Fax Modem Plug & Play */
+   ISAPNP_TBL_ENTRY('A', 'D', 'C', 0x0002),
+   /* Rockwell 56K ACF II Fax+Data+Voice Modem */
+   ISAPNP_TBL_ENTRY('A', 'K', 'Y', 0x1021),
+   /* AZT3005 PnP SOUND DEVICE */
+   ISAPNP_TBL_ENTRY('A', 'Z', 'T', 0x4001),
+   /* Best Data Products Inc. Smart One 336F PnP Modem */
+   ISAPNP_TBL_ENTRY('B', 'D', 'P', 0x3336),
+   /*  Boca Research */
+   /* Boca Complete Ofc Communicator 14.4 Data-FAX */
+   ISAPNP_TBL_ENTRY('B', 'R', 'I', 0x0A49),
+   /* Boca Research 33,600 ACF Modem */
+   ISAPNP_TBL_ENTRY('B', 'R', 'I', 0x1400),
+   /* Boca 33.6 Kbps Internal FD34FSVD */
+   ISAPNP_TBL_ENTRY('B', 'R', 'I', 0x3400),
+   /* Boca 33.6 Kbps Internal FD34FSVD */
+   ISAPNP_TBL_ENTRY('B', 'R', 'I', 0x0A49),
+   /* Best Data Products Inc. Smart One 336F PnP Modem */
+   ISAPNP_TBL_ENTRY('B', 'D', 'P', 0x3336),
+   /* Computer Peripherals Inc */
+   /* EuroViVa CommCenter-33.6 SP PnP */
+   ISAPNP_TBL_ENTRY('C', 'P', 'I', 0x4050),
+   /* Creative Labs */
+   /* Creative Labs Phone Blaster 28.8 DSVD PnP Voice */
+   ISAPNP_TBL_ENTRY('C', 'T', 'L', 0x3001),
+   /* Creative Labs Modem Blaster 28.8 DSVD PnP Voice */
+   ISAPNP_TBL_ENTRY('C', 'T', 'L', 0x3011),
+   /* Creative */
+   /* Creative Modem Blaster Flash56 DI5601-1 */
+   ISAPNP_TBL_ENTRY('D', 'M', 'B', 0x1032),
+   /* Creative Modem Blaster V.90 DI5660 */
+   ISAPNP_TBL_ENTRY('D', 'M', 'B', 0x2001),
+   /* FUJITSU */
+   /* Fujitsu 33600 PnP-I2 R Plug & Play */
+   ISAPNP_TBL_ENTRY('F', 'U', 'J', 0x0202),
+   /* Fujitsu FMV-FX431 Plug & Play */
+   ISAPNP_TBL_ENTRY('F', 'U', 'J', 0x0205),
+   /* Fujitsu 33600 PnP-I4 R Plug & Play */
+   ISAPNP_TBL_ENTRY('F', 'U', 'J', 0x0206),
+   /* Fujitsu Fax Voice 33600 PNP-I5 R Plug & Play */
+   ISAPNP_TBL_ENTRY('F', 'U', 'J', 0x0209),
+   /* Archtek America Corp. */
+   /* Archtek SmartLink Modem 3334BT Plug & Play */
+   ISAPNP_TBL_ENTRY('G', 'V', 'C', 0x000F),
+   /* Hayes */
+   /* Hayes Optima 288 V.34-V.FC + FAX + Voice Plug & Play */
+   ISAPNP_TBL_ENTRY('H', 'A', 'Y', 0x0001),
+   /* Hayes Optima 336 V.34 + FAX + Voice PnP */
+   ISAPNP_TBL_ENTRY('H', 'A', 'Y', 0x000C),
+   /* Hayes Optima 336B V.34 + FAX + Voice PnP */
+   ISAPNP_TBL_ENTRY('H', 'A', 'Y', 0x000D),
+

Re: Oops on 2.2.18-23 as pppd dial in server

[Mohammad A. Haque]

solcate? .. you sure you don't mean slocate?

"Jeff V. Merkey" wrote:
> process solcate pid: 1109 nr: 45 stack=c17f9000

-- 

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

Oops on 2.2.18-23 as pppd dial in server

[Jeff V. Merkey]

Alan,

Was able to reproduce this Oops, but it took several days.   Oops occurs
against 2.2.18-23.  I had to copy this info from the console -- the
system was hard hung after the oops and even ksymoops was locked solid.

Jeff

unable to handle kernel paing request virtual address 90C16C24
CR3-0187 pde=0

Oops: 0002
CPU:  0
EIP   0010: C0137596
EFLAGS: 00010206
eax:  90c16c20  ebx:  c16c6145  ecx:  edx: c0226e2c 
esi:  c0259200  edi:  c16c614d  ebp: c0259200 esp: c17f9ee8
ds: 18  es: 18  ss: 18
process solcate pid: 1109 nr: 45 stack=c17f9000
Call Trace:  c01377fe  c0137816  c0144bbc  c0131238  c0131434  c013151c 
c012f532 c010a2fc
-
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: Address translation

[Andreas Bombe]

On Thu, Nov 23, 2000 at 10:04:18PM +0100, Bjorn Wesen wrote:
> On Thu, 23 Nov 2000, Andreas Bombe wrote:
> > > I may be wrong on this, but I thought that copy_{to,from}_user are
> > > only necessary if the address range you are accessing might cause a
> > > fault which Linux cannot handle (ie. one which would cause the
> > > application to segfault if it accessed that memory). If it is only a
> > 
> > It is wrong.  copy_*_user handle the page faults, whether they are good
> > faults (swapped out, copy on write) or bad faults (illegal access).
> > Without these macros you get the "unable to handle kernel page fault"
> > oops message if a fault occurs.
> 
> Yes but only if it's a real fault, not if the address range actually is
> a valid VMA which needs paging, COW'ing or related OS ops. copy_*_user
> does not do the access in any different way than a "manual" access or
> memcpy does, it just adds a .fixup section that tells the do_page_fault
> handler that it should not segfault the kernel itself if the copy takes a
> big fault at any point, instead it should jump to the fixup which makes
> the copy routine return an error message.

You're right, I remembered wrong.

> > >  (1) In a "top half" thread, can I now access this memory without the
> > >  access macros (since I know the address range is valid)?
> > 
> > The address is valid, the pages probably aren't.  In fact, extending the
> > address space only creates read-only mappings to the global zeroed page
> > if I remember right.
> 
> But it does not matter that the pages aren't there physically, any kind of
> access (including an access from kernel-mode) will bring about the same
> COW/change-on-write mechanism as copy_to_user or a user-mode access would.

However these faults can let you sleep (swap-in, or swap-out to make
room for a COW page).  That's defined for the uaccess macros, but might
come very unexpected with a memcpy.  Unexpected sleeps alone can make a
crash if the surrounding code does not allow it.

It's a moot point anyway, memcpy with user space is illegal.

-- 
 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: 3c59x: Using bad IRQ 0

[Jeff Garzik]

Linus Torvalds wrote:
> 
> On Tue, 21 Nov 2000, Jeff Garzik wrote:
> >
> > A caveat to this whole scheme is that usb-uhci -already- calls
> > pci_enable_device before checking dev->irq, and yet cannot get around
> > the "assign IRQ to USB: no" setting in BIOS.  I hope that is an
> > exception rather than the rule.
> 
> Do we have a recent report of this with full PCI debug output? It might
> just be another unlisted intel irq router..

Actually, I -was- able to reproduce this problem on my SMP PIIX4 box
here.  But as of test11-final, I am no longer able to reproduce it.

Maybe some intrepid testers are willing to test 2.4.0-test11 with these
BIOS settings:
PNP OS: Yes
Assign IRQ to USB: No

It works for me... :)

Jeff


-- 
Jeff Garzik |
Building 1024   | The chief enemy of creativity is "good" sense
MandrakeSoft|  -- Picasso
-
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] removal of "static foo = 0" from drivers/ide (test11)

[J . A . Magallon]

On Thu, 23 Nov 2000 12:01:53 Rusty Russell wrote:
> 
> What irritates about these monkey-see-monkey-do patches is that if I
> initialize a variable to NULL, it's because my code actually relies on
> it; I don't want that information eliminated.
> 

What I understood from the previous answer from Tigran is that you can
avoid initializations to ZERO or NULL, because the BSS is zeroed (ie, all
variables you declare static os global in a module are zeroed) at
kernel start.

As I understand from compiler working, if you put a statement like
int a = 0;
int b = 0;
all variables that have an initial value are stored contiguous in the
data segment of the executable and an image of their initial values has
to be stored with the binary. So if a program like

int a[16384];
int main() {}

gives a binary of 13k, if you write it as

int a[16384] = {0};
int main() {}

it has to store the 64k of a, just to put a 0 in the first place and
make the exec size to 78k.

ANSI rules for C say that uninitialized vars get a 0, but you can't trust
on the ANSI behaviour of a compiler.

Obviuosly, you have to leave your initializations to 7 or -1 in place.

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

Linux 2.2.18-pre23-vm #3 SMP Wed Nov 22 22:33:53 CET 2000 i686 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: Recent ide patches and DMA

[Kafu Nagai]

440BX with PIIX4 on BP6


>On Thu, Nov 23, 2000 at 01:09:35PM -0800, Kafu Nagai wrote:
>> With recent ide patches, the ide driver seems to try to use DMA mode even for a 
>drive which dosen't support it. CONFIG_IDEDMA_PCI_AUTO is enabled but even so with 
>the stock kernel this dosen't happen. older patches didn't have this behavior either. 
>Is this change intentional ?
>> 
>> hdc: 333630 sectors (171 MB) w/32KiB Cache, CHS=1011/15/22, DMA
>> Partition check:
>>  hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 >
>>  hdc:hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
>> hdc: dma_intr: error=0x04 { DriveStatusError }
>> hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
>> hdc: dma_intr: error=0x04 { DriveStatusError }
>> hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
>> hdc: dma_intr: error=0x04 { DriveStatusError }
>> hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
>> hdc: dma_intr: error=0x04 { DriveStatusError }
>> hdc: DMA disabled
>> ide1: reset: success
>>  hdc1
>> 
>> ~ $ hdparm -i /dev/hdc
>>  
>> /dev/hdc:
>>  
>>  Model=QUANTUM ELS170A, FwRev=4.20, SerialNo=166304085456
>>  Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>5Mbs RotSpdTol>.5% }
>>  RawCHS=1011/15/22, TrkSize=11264, SectSize=512, ECCbytes=4
>>  BuffType=3(DualPortCache), BuffSize=32kB, MaxMultSect=8, MultSect=off
>>  DblWordIO=no, OldPIO=2, DMA=no
>>  CurCHS=1011/15/22, CurSects=333629, LBA=no 
>
>Which chipset are you using?
>
>-- 
>Vojtech Pavlik
>SuSE Labs



Free Web space and web based email @EASYNEWS.COM


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: changing BIOS setting

[Jeff Garzik]

Andrew Park wrote:
> Is there a way to change BIOS setting (like boot sequence)
> from the kernel space?  Any pointers would be appreciated.

Yes.  All the BIOS does is configure your hardware.  Get docs on your
hardware, and you can do anything that BIOS does.  For example, if your
parallel port is disabled in BIOS, and you have the datasheet for your
southbridge, then you can "manually" enable the parallel port by writing
certain values to certain PCI config registers.

That said, it is generally a bad idea to do this sort of thing.  Unless
you have a cluster full of machines that all have a BIOS-related
problem, or similar, you should just reboot and adjust your BIOS...

Of course, if you are really motivated, you could just flash your own
BIOS.  Check out http://www.acl.lanl.gov/linuxbios/

Regards,

Jeff


-- 
Jeff Garzik |
Building 1024   | The chief enemy of creativity is "good" sense
MandrakeSoft|  -- Picasso
-
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] 2.2.18pre21: DRM update

[Ed Tomlinson]

Alan Cox wrote:

> I'll look over it. It may be worth doing the fixing for 2.2.18, since
> 2.2.17 doesnt have DRM anyway. As posted it doesnt build against vanilla
> 2.2.18pre but I can see why so not a problem

This patch enables a G400 to use DRI using debian woody.  Without this its 
2.4 time.  (BTW 2.4.0test11-ac3 BUG()ed out at sched.c:513 when playing the 
the matrox fb stuff).

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

changing BIOS setting

[Andrew Park]

Hi,
Is there a way to change BIOS setting (like boot sequence)
from the kernel space?  Any pointers would be appreciated.
Thanks

-A.

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

Fasttrak100 questions...

[James Lamanna]

So, I have a system that has 2 45GB IDE drives connected
up to a Promise Technologies Fasttrack 100.
Promise Techonologies currently has a driver that you can compile
against a 2.2 kernel into a module, but it also includes one
proprietary object file.
During my linux installation I was able to preload the module and
have it detect the drives fine as a scsi device, so I was able to
install the base system onto them.
 
The question is, is there a way to compile this module into the kernel
so that it will automatically detect the card? A simple linking of the
module into the scsi library by editing the Makefile doesn't seem to do
it. It doesn't detect the drives if I boot off of a floppy with this
kernel on it.

Also, is it possible for Lilo to even boot this without a RAM disk
somewhere? I guess Lilo has to know about the drive, but it can't know
without the module...so am I screwed into using floppies with a
RAM disk image anyways?

Thanks,
--James Lamanna
-
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.18pre23 Oops

[f5ibh]

Hi,

I was running a packet radio (hamradio) program whose name is tnt.
(We can see it is the oops and he disapeared during the oops).
The OOps occured as I was loading the modules for a ppa ZIP parallel port ZIP
drive.

This is the raw Oos without processing it with ksymoops :
*

ppa: Version 2.05 (for Linux 2.2.x)
ppa: Found device at ID 6, Attempting to use EPP 32 bit
ppa: Communication established with ID 6 using EPP 32 bit
Warning: kfree_skb passed an skb still on a list (from c4868fc1).



Oops: 0002
CPU:0
EIP:0010:[skb_recv_datagram+359/416]
EFLAGS: 00010047
eax: c2d868e0   ebx:    ecx: 0246   edx: 
esi: 05dc   edi: c3203e84   ebp: c36d7a04   esp: c3203dcc
ds: 0018   es: 0018   ss: 0018
Process tnt (pid: 316, process nr: 28, stackpage=c3203000)
Stack: c3203e84 c3203f48 c3ffe040 c3203df0    c019de40
2000 c4876b5b c36d79c0   c3203e20 c302ed48 05dc
c3203e84 c3203f48  c019de40 c36d79c0 35323431 6731 c3247e40
Call Trace: [twist_table.690+3744/4256] [] [twist_table.690+3744/4256] 
[sock_recvmsg+65/184] [tcp_listen_poll+56/80] [sys_recvfrom+168/260] [free_pages+39/44]
[free_wait+101/116] [do_select+487/512] [do_select+440/512] [sys_select+993/1176] 
[sys_socketcall+410/540] [common_interrupt+24/32] [error_code+45/52] 
[system_call+52/56]
Code: 89 6a 04 89 55 00 c7 00 00 00 00 00 c7 40 04 00 00 00 00 c7



scsi0 : Iomega VPI0 (ppa) interface
scsi : 1 host.
Vendor: IOMEGAModel: ZIP 100
Rev: L.01
Type:   Direct-Access
ANSI SCSI revision: 02
Detected scsi removable disk sda at scsi0, channel 0, id 6, lun 0
SCSI device sda: hdwr sector= 512 bytes. Sectors= 196608 [96 MB] [0.1 GB]

And here is the oops processed bu ksymoops :



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

Oops: 0002
CPU:0
EIP:0010:[skb_recv_datagram+359/416]
EFLAGS: 00010047
eax: c2d868e0   ebx:    ecx: 0246   edx: 
esi: 05dc   edi: c3203e84   ebp: c36d7a04   esp: c3203dcc
ds: 0018   es: 0018   ss: 0018
Process tnt (pid: 316, process nr: 28, stackpage=c3203000)
Stack: c3203e84 c3203f48 c3ffe040 c3203df0    c019de40
   2000 c4876b5b c36d79c0   c3203e20 c302ed48 05dc
   c3203e84 c3203f48  c019de40 c36d79c0 35323431 6731 c3247e40
Call Trace: [twist_table.690+3744/4256] [] [twist_table.690+3744/4256] 
[sock_recvmsg+65/184] [tcp_listen_poll+56/80] [sys_recvfrom+168/260] [free_pages+39/44]
Code: 89 6a 04 89 55 00 c7 00 00 00 00 00 c7 40 04 00 00 00 00 c7
Using defaults from ksymoops -t elf32-i386 -a i386

Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   89 6a 04  mov%ebp,0x4(%edx)
Code;  0003 Before first symbol
   3:   89 55 00  mov%edx,0x0(%ebp)
Code;  0006 Before first symbol
   6:   c7 00 00 00 00 00 movl   $0x0,(%eax)
Code;  000c Before first symbol
   c:   c7 40 04 00 00 00 00  movl   $0x0,0x4(%eax)
Code;  0013 Before first symbol
  13:   c7 00 00 00 00 00 movl   $0x0,(%eax)

System is :
***

-- Versions installed: (if some fields are empty or look
-- unusual then possibly you have very old versions)
Linux debian-f5ibh 2.2.18pre23 #1 jeu nov 23 23:38:07 CET 2000 i586 unknown
Kernel modules 2.3.21
Gnu C  2.95.2
Binutils   2.9.5.0.41
Linux C Library2.1.3
Dynamic linker ldd: version 1.9.11
Procps 2.0.6
Mount  2.10o
Net-tools  2.05
Console-tools  0.2.3
Sh-utils   2.0
Modules Loaded scc sd_mod ppa scsi_mod adlib_card v_midi opl3 sb uart401
sound soundcore ide-cd cdrom isofs nls_cp437 vfat fat ppp_deflate bsd_comp ppp 
slhc af_packet ax25 parport_pc lp parport mousedev usb-uhci hid usbcore input 
autofs lockd sunrpc serial unix

-

Regards

Jean-Luc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: About IP address

[Mike A. Harris]

On Fri, 24 Nov 2000, J. Dow wrote:

>Date: Fri, 24 Nov 2000 14:15:41 -0800
>From: J. Dow <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED], [EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED]
>Content-Type: text/plain;
>charset="iso-8859-1"
>Subject: Re: About IP address
>
>From: "John Crowhurst" <[EMAIL PROTECTED]>
>
>> > For example, Class B address range is 128.1.0.0 ~ 191.254.0.0
>> >
>> > Why 128.0.0.0 and 191.255.0.0 can't use ?
>> >
>> > I can't understand it
>>
>> This is because its the network and broadcast addresses of a Class A address
>> range. Simple answer :)
>
>That is not a responsive answer, John. And since you gave it I issue you the
>challenge to declare why 128.0.0.1 through 191.255.255.254 are not legal
>address ranges.

One possibility: rfc1700

;o)


--
  Mike A. Harris  -  Linux advocate  -  Open source advocate
  This message is copyright 2000, all rights reserved.
  Views expressed are my own, not necessarily shared by my employer.
--

Looking for Linux software?   http://freshmeat.net  http://www.rpmfind.net
http://filewatcher.org  http://www.coldstorage.org  http://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: OOPS on bringing down ppp

[Marc Heckmann]

On Fri, Nov 24, 2000 at 10:55:39AM +, Mark Ellis wrote:
> Hi all, consistently getting the following when pppd is terminated. Happens
> in 2.4.0-test11, fine in 2.4.0-test9, don't know about test10. Same happens
> for pppd 2.4.0b4 and 2.4.0, both recompiled for test11. Is this related to
> the modutils incompatability (modutils 2.3.19) ? 

I get the same oops w/ 2.4.0-test11pre7, pppd-2.3.11 and pppd-2.4.0, not
quite sure if it happens on _every_ pppd termination, but it does happen
a lot. Modutils-2.3.2[01]. ksymoops below, notice that it is preceded by
a waitpid failed, don't wether it is important or not... My kernel is
compiled on a fairly stock RH-7.0 with kgcc.

system:

-- Versions installed: (if some fields are empty or look
-- unusual then possibly you have very old versions)
Linux fsck.ikr.org 2.4.0-test11 #2 Sun Nov 19 00:16:38 EST 2000 i586
unknown
Kernel modules 2.3.20
Gnu C  egcs-2.91.66
Gnu Make   3.79.1
Binutils   2.10.0.18
Linux C Library2.1.94
Dynamic linker ldd (GNU libc) 2.1.94
Procps 2.0.7
Mount  2.10m
Net-tools  1.56
Console-tools  0.3.3
Sh-utils   2.0
Modules Loaded ppp_deflate bsd_comp ppp_async ppp_generic slhc
ide-cd cdrom soundcore de4x5 raid1 BusLogic


Nov 23 16:05:13 fsck kernel: waitpid(1808) failed, -512
Nov 23 16:05:13 fsck kernel: Unable to handle kernel NULL pointer
dereference at
 virtual address 0008
Nov 23 16:05:13 fsck kernel:  printing eip:
Nov 23 16:05:13 fsck kernel: c011556e
Nov 23 16:05:13 fsck kernel: *pde = 
Nov 23 16:05:13 fsck kernel: Oops: 
Nov 23 16:05:13 fsck kernel: CPU:0
Nov 23 16:05:13 fsck kernel: EIP:0010:[exec_usermodehelper+734/944]
Nov 23 16:05:13 fsck kernel: EFLAGS: 00010246
Nov 23 16:05:13 fsck kernel: eax:    ebx: c1177b20   ecx: c1fb4fb0
edx: c1fb4fa4
Nov 23 16:05:13 fsck kernel: esi: c2694000   edi: c2694000   ebp: 
esp: c2695fb0
Nov 23 16:05:13 fsck kernel: ds: 0018   es: 0018   ss: 0018
Nov 23 16:05:13 fsck kernel: Process pppd (pid: 1808, stackpage=c2695000)
Nov 23 16:05:13 fsck kernel: Stack: 0100 c34e7d90 c34e6000 c1a640c0
c3eca9a0 c36fc160 c1177b20 c3eca9a0 
Nov 23 16:05:13 fsck kernel:c3eca9a0 c1177b20 c3eca9a0 c3eca9a0
c0115890 c0222840 c34e7e4c c34e7e38 
Nov 23 16:05:13 fsck kernel:c0108e87 c34e7dbc c34e7dbc c34e7e4c 
Nov 23 16:05:13 fsck kernel: Call Trace: [exec_helper+20/24]
[kernel_thread+35/48] 
Nov 23 16:05:13 fsck kernel: Code: 3b 68 08 7d 2a 8b 40 14 83 3c a8 00 74
15 b8 06 00 00 00 89


ksymoops:

ksymoops 2.3.5 on i586 2.2.16-22.  Options used
 -v /usr/src/linux/vmlinux (specified)
 -K (specified)
 -L (specified)
 -o /lib/modules/2.4.0-test11/ (specified)
 -m /usr/src/linux/System.map (specified)

No modules in ksyms, skipping objects
Nov 23 16:05:13 fsck kernel: Unable to handle kernel NULL pointer
dereference at virtual address 0008
Nov 23 16:05:13 fsck kernel: c011556e
Nov 23 16:05:13 fsck kernel: *pde = 
Nov 23 16:05:13 fsck kernel: Oops: 
Nov 23 16:05:13 fsck kernel: CPU:0
Nov 23 16:05:13 fsck kernel: EIP:0010:[exec_usermodehelper+734/944]
Nov 23 16:05:13 fsck kernel: EFLAGS: 00010246
Nov 23 16:05:13 fsck kernel: eax:    ebx: c1177b20   ecx: c1fb4fb0
edx: c1fb4fa4
Nov 23 16:05:13 fsck kernel: esi: c2694000   edi: c2694000   ebp: 
esp: c2695fb0
Nov 23 16:05:13 fsck kernel: ds: 0018   es: 0018   ss: 0018
Nov 23 16:05:13 fsck kernel: Process pppd (pid: 1808, stackpage=c2695000)
Nov 23 16:05:13 fsck kernel: Stack: 0100 c34e7d90 c34e6000 c1a640c0
c3eca9a0 c36fc160 c1177b20 c3eca9a0 
Nov 23 16:05:13 fsck kernel:c3eca9a0 c1177b20 c3eca9a0 c3eca9a0
c0115890 c0222840 c34e7e4c c34e7e38 
Nov 23 16:05:13 fsck kernel:c0108e87 c34e7dbc c34e7dbc c34e7e4c 
Nov 23 16:05:13 fsck kernel: Call Trace: [exec_helper+20/24]
[kernel_thread+35/48] 
Nov 23 16:05:13 fsck kernel: Code: 3b 68 08 7d 2a 8b 40 14 83 3c a8 00 74
15 b8 06 00 00 00 89
Using defaults from ksymoops -t elf32-i386 -a i386

Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   3b 68 08  cmp0x8(%eax),%ebp
Code;  0003 Before first symbol
   3:   7d 2a jge2f <_EIP+0x2f> 002f Before
first symbol
Code;  0005 Before first symbol
   5:   8b 40 14  mov0x14(%eax),%eax
Code;  0008 Before first symbol
   8:   83 3c a8 00   cmpl   $0x0,(%eax,%ebp,4)
Code;  000c Before first symbol
   c:   74 15 je 23 <_EIP+0x23> 0023 Before
first symbol
Code;  000e Before first symbol
   e:   b8 06 00 00 00mov$0x6,%eax
Code;  0013 Before first symbol
  13:   89 00 mov%eax,(%eax)

-Marc

> CONFIG_PPP and CONFIG_PPP_ASYNC are built in, CONFIG_PPP_DEFLATE and
> CONFIG_PPP_BSDCOMP as modules, but oopses whether 

Re: About IP address

[J. Dow]

From: "John Crowhurst" <[EMAIL PROTECTED]>

> > For example, Class B address range is 128.1.0.0 ~ 191.254.0.0
> > 
> > Why 128.0.0.0 and 191.255.0.0 can't use ?
> > 
> > I can't understand it
> 
> This is because its the network and broadcast addresses of a Class A address
> range. Simple answer :)

That is not a responsive answer, John. And since you gave it I issue you the
challenge to declare why 128.0.0.1 through 191.255.255.254 are not legal
address ranges.

{^_-}


-
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] removal of "static foo = 0" from drivers/ide (test11)

[Vojtech Pavlik]

On Thu, Nov 23, 2000 at 10:01:53PM +1100, Rusty Russell wrote:
> In message <[EMAIL PROTECTED]> you write:
> > > On Tue, 21 Nov 2000 22:25:01 Bartlomiej Zolnierkiewicz wrote:
> > > > 
> > > > Quick removal of unnecessary initialization to 0.
> > 
> > Quite the contrary. The patch seems correct and useful to me. What do you
> > think is wrong with it? (Linus accepted megabytes worth of the above in
> > the past...)
> 
> What irritates about these monkey-see-monkey-do patches is that if I
> initialize a variable to NULL, it's because my code actually relies on
> it; I don't want that information eliminated.

Yes, but if it generates a bigger (== worse) binary?

-- 
Vojtech Pavlik
SuSE Labs
-
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: iBCS2 and 2.4.0-11 Can we make soup yet?

[Mohammad A. Haque]

Check this thread
http://marc.theaimsgroup.com/?t=9714970441=2=1

"Jeff V. Merkey" wrote:
> 
> I noticed that iBC2 support no longer builds against 2.4.0-11.  I also
> found that 11/98 seems to be the last version of iBCS2 posted.  2.4.0-11
> does have a MISC binary loadable option, but I did not see iBCS2 in the
> tree.  Is there something more recent, or is iBCS2 something that's
> basically no longer considered critical for Linux?

-- 

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

2.4.0-test5 bug: invalid "shmid_kernel" passed to "shm_nopage_core"

[Kevin Buhr]

I've been chasing after a bug in 2.4.0-test5 that I can't quite nail
down.  I don't see anything obvious between test5 and test11 that
leads me to believe it's been fixed.

I encountered a lockup on my SMP box.  One CPU got stuck in a spinlock
via the following call trace.  There were enough args and saved
registers on the stack for me to reconstruct a few of the calls:

  valid_swaphandles(entry=c218b268, offset=c68e7e78)
  swapin_readahead(entry=c218b268)
  shm_nopage_core(shp=c218b240, idx=0, address=40014000)
  shm_nopage
  do_no_page
  handle_mm_fault
  do_page_fault
  schedule
  sys_ipc (at call to sys_shmat)

"valid_swaphandles" locked on the:

swap_device_lock(swapdev)

and it's not surprising it did.  The SWP_TYPE(entry) was swapfile
index 52 on my 2-swapfile system, so it was spinning on some random
piece of memory.

In "shm_nopage", the code

if(!(shp = shm_lock(inode->i_ino)))
BUG();

got a "shp" of 0xc218b240.  For some reason, this wasn't a valid
"shp", because in "shm_nopage_core", the

pte = SHM_ENTRY(shp,idx);  // in our case, shp->shm_dir[0][0]

returned 0xc218b268 (i.e., the value of >shm_dir, so maybe
shp->shm_dir was a pointer to itself---not possible if "shp" pointed
to a valid "struct shmid_kernel").

The SHM locking has thwarted my attempts at understanding.  Maybe
someone else can see the bug or reassure me that it's already been
fixed in test11?

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

[PATCH] asm-ppc/elf.h error (fixed patch)

[David Riley]

Oops, 
I included the wrong diff.  Perhaps I should check them better next
time.  Here's one that should work.
 elf.h.diff

asm-ppc/elf.h error

[David Riley]

In asm-ppc/elf.h,  is not included.  This breaks
compilations of anything that compiles it (e.g. binutils) because the
vector registers for Altivec aren't defined elsewhere.  Included is a
quick diff.  I didn't know which PPC maintainer to send this to, so I
posted it to the linuxppc-dev list.

Thanks,
David

--- linux/include/asm-ppc/elf.h.old Fri Nov 24 15:42:44 2000
+++ linux/include/asm-ppc/elf.h Fri Nov 24 15:43:54 2000
@@ -4,6 +4,7 @@
 /*
  * ELF register definitions..
  */
+#include 
 #include 
 
 #define ELF_NGREG  48  /* includes nip, msr, lr, etc. */
@@ -25,9 +26,11 @@
 typedef double elf_fpreg_t;
 typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG];
 
+#ifdef CONFIG_ALTIVEC
 /* Altivec registers */
 typedef __vector128 elf_vrreg_t;
 typedef elf_vrreg_t elf_vrregset_t[ELF_NVRREG];
+#endif
 
 #ifdef __KERNEL__
 

[patch] 2.2.18pre23: user access checking in pipe_read/pipe_write

[Tim Waugh]

Here is an untested patch intended to fix the following behaviour:

$ cat a.c
#include 
int main (int argc, char **arghhh)
{
  int fd[2];
  pipe (fd);
  write (fd[1], NULL, 1);
}
$ gcc -o a a.c
$ strace -ewrite ./a
write(4, NULL, 1)   = 1
$ 

Tim.
*/

--- linux-2.2.18pre23/fs/pipe.c.cfu Fri Nov 24 20:55:11 2000
+++ linux-2.2.18pre23/fs/pipe.c Fri Nov 24 21:00:11 2000
@@ -31,7 +31,7 @@
 size_t count, loff_t *ppos)
 {
struct inode * inode = filp->f_dentry->d_inode;
-   ssize_t chars = 0, size = 0, read = 0;
+   ssize_t chars = 0, size = 0, read = 0, err = 0;
 char *pipebuf;
 
 
@@ -67,11 +67,14 @@
chars = size;
read += chars;
 pipebuf = PIPE_BASE(*inode)+PIPE_START(*inode);
+   if (copy_to_user(buf, pipebuf, chars )) {
+   err = -EFAULT;
+   break;
+   }
PIPE_START(*inode) += chars;
PIPE_START(*inode) &= (PIPE_BUF-1);
PIPE_LEN(*inode) -= chars;
count -= chars;
-   copy_to_user(buf, pipebuf, chars );
buf += chars;
}
PIPE_LOCK(*inode)--;
@@ -80,9 +83,9 @@
UPDATE_ATIME(inode);
return read;
}
-   if (PIPE_WRITERS(*inode))
+   if (!err && PIPE_WRITERS(*inode))
return -EAGAIN;
-   return 0;
+   return err;
 }

 static ssize_t pipe_write(struct file * filp, const char * buf,
@@ -109,7 +112,7 @@
down(>i_sem);
return -ERESTARTSYS;
}
-   while (count>0) {
+   while (count>0 && !err) {
while ((PIPE_FREE(*inode) < free) || PIPE_LOCK(*inode)) {
if (!PIPE_READERS(*inode)) { /* no readers */
send_sig(SIGPIPE,current,0);
@@ -134,10 +137,13 @@
if (chars > free)
chars = free;
 pipebuf = PIPE_BASE(*inode)+PIPE_END(*inode);
+   if (copy_from_user(pipebuf, buf, chars )) {
+   err = -EFAULT;
+   break;
+   }
written += chars;
PIPE_LEN(*inode) += chars;
count -= chars;
-   copy_from_user(pipebuf, buf, chars );
buf += chars;
}
PIPE_LOCK(*inode)--;
-
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: Jens Axboe's blk-11 causing problems

[Jens Axboe]

On Fri, Nov 24 2000, Boszormenyi Zoltan wrote:
> Hi!
> 
> I tried 2.4.0-test11 (plain, +ac1/2) with and without
> Jens' blk-11 patch. This indeed performs (much) better
> when there is only high disk activity but cdrecord
> starts up _very_ slowly if the kernel was compiled with 
> blk-11. It does not happen if blk-11 is not applied.
> 
> I stopped cdrecord before it started writing because of
> this suspicious slowness and I did not want to create a bad CD.
> 
> Other data points:
> The CD-writer is a Yamaha-6416 (SCSI version).
> The SCSI card is a Diamond Fireport-40 (Symbios 53c875j)
> I tested both the in-kernel 1.6b and 1.7.2 versions of the
> sym53c8xx driver.
> 
> The slowdown was experienced in every case where
> the kernel contained blk-11.

You might want to send messages such as this one to me
as well, so I don't miss them :-)

The problem is due to sg assuming that scsi_do_req will
fire the request queue immediately to let the command
inject complete. This was never really the case, even
in the stock kernel. Here's a quick-and-dirty patch
against test11+blk-11 attached, untested but it should
fix the delays.

-- 
* Jens Axboe <[EMAIL PROTECTED]>
* SuSE Labs


--- /opt/kernel/linux-2.4.0-test11/drivers/scsi/sg.cTue Oct 24 22:58:20 2000
+++ drivers/scsi/sg.c   Fri Nov 24 21:57:50 2000
@@ -689,6 +689,7 @@
(void *)SRpnt->sr_buffer, hp->dxfer_len,
sg_cmd_done_bh, timeout, SG_DEFAULT_RETRIES);
 /* dxfer_len overwrites SRpnt->sr_bufflen, hence need for b_malloc_len */
+generic_unplug_device(>sr_device->request_queue);
 return 0;
 }
 

Re: More info about de USB HP 8230e and problems]

[Jens Axboe]

On Fri, Nov 24 2000, Drizzt wrote:
> I have using the next software:
> 
> a) test11 + storage checkout from linux-usb at sourceforge ( without 
>this checkout fails too).
> 
> b) cdrecord 1.10a6
> 
> If I start to burn a CD at x4 speed, I have always the next error from
> cdrecord:
> Track 01: 102 of 109 MB written (fifo 100%)./opt/schily/bin/cdrecord:
> Input/output error. write_g1: scsi sendcmd: retryable error
> CDB:  2A 00 00 00 CD 03 00 00 1F 00
> status: 0x2 (CHECK CONDITION)
> Sense Bytes: 70 00 03 00 00 00 00 12 00 00 00 00 0C 09 00 00
> Sense Key: 0x3 Medium Error, Segment 0
> Sense Code: 0x0C Qual 0x09 (write error - loss of streaming) Fru 0x0
> Sense flags: Blk 0 (not valid)
> 
> Well the size of track varies in function that have buring.
> 
> With the storage-usb debug active I have the next log:
> 
> usb-storage: Command WRITE_10 (10 bytes)
> usb-storage: 2a 00 00 00 cd 03 00 00 1f 00 ff bf
> usb-storage: Transferred out 38 of 38 bytes
> usb-storage: Transferred out 32768 of 32768 bytes
> usb-storage: Transferred out 30720 of 30720 bytes
> usb-storage: -- transport indicates command failure
> usb-storage: Issuing auto-REQUEST_SENSE
> usb-storage: Transferred out 14 of 14 bytes
> usb-storage: Waited not busy for 0 steps
> usb-storage: Transferred out 12 of 12 bytes
> usb-storage: Waited not busy for 2 steps
> usb-storage: Transferred in 18 of 18 bytes
> usb-storage: 70 00 03 00 00 00 00 12 00 00 00 00 0C 09 00 00
> usb-storage: 00 00
> usb-storage: -- Result from auto-sense is 0
> usb-storage: -- code: 0x70, key: 0x3, ASC: 0xc, ASCQ: 0x9
   

Loss of streaming. The drive emptied it's buffer before any
new data was delivered to it.

> If I burning the CD with the same software at x2 speed with these computer I
> have no problem burning the CD.

Then you should probably just stay there, it seems things can't keep up.

-- 
* Jens Axboe <[EMAIL PROTECTED]>
* SuSE Labs
-
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, test10, test11: HPT366 problem

[Nathan A. Ferch]

I have similar problems with an IBM-DTLA-305020 and the HPT-366 on a ABIT BP6.
I'm not sure what the BIOS version is, i'll check it once i return home.
Changing to udma3 seems to fix the problems. However i can always pass
partition check fine.

On Tue, Nov 21, 2000 at 01:29:51PM +, David Woodhouse wrote:
> 
> [EMAIL PROTECTED] said:
> >  When it comes to the partition detection during bootup, udma4 or
> > udma3 doesn't seem to matter. It passes approx. one out of ten times
> > either way. 
> 
> How have you made it use udma3 at bootup? Something like the patch below?
> 
> Index: drivers/ide/hpt366.c
> ===
> RCS file: /inst/cvs/linux/drivers/ide/Attic/hpt366.c,v
> retrieving revision 1.1.2.10
> diff -u -r1.1.2.10 hpt366.c
> --- drivers/ide/hpt366.c  2000/11/10 14:56:31 1.1.2.10
> +++ drivers/ide/hpt366.c  2000/11/21 13:27:32
> @@ -55,6 +55,8 @@
>  };
>  
>  const char *bad_ata66_4[] = {
> + "IBM-DTLA-307045",
> + "IBM-DTLA-307030",
>   "WDC AC310200R",
>   NULL
>  };
> 
> --
> 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/
--
nathan a ferch
[EMAIL PROTECTED]
"No!  Nobody ever built them like this!  The architect was either an authentic whacko 
or a certified genius.  The whole building is like a huge antenna for pulling in and 
concentrating psychokinetic energy." -Stantz
-
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/

iBCS2 and 2.4.0-11 Can we make soup yet?

[Jeff V. Merkey]

I noticed that iBC2 support no longer builds against 2.4.0-11.  I also
found that 11/98 seems to be the last version of iBCS2 posted.  2.4.0-11
does have a MISC binary loadable option, but I did not see iBCS2 in the
tree.  Is there something more recent, or is iBCS2 something that's
basically no longer considered critical for Linux?

Thanks

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/

Re: AIC-7xxx oops

[Jens Axboe]

On Mon, Nov 20 2000, KELEMEN Peter wrote:
> Hello.
> 
> I've been experiencing SCSI-related oopsen since 2.4.0-test6.
> Couple of minutes ago I tried with test11 final, no luck still.
> When I attempt to play an audio CD using cdplay from the cdtool
> package, I'm rewarded with the following oops and cdplay
> segfaults.

Known and fixed, not submitted to Linus yet.

http://www.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.0-test11/cd-1.bz2

-- 
* Jens Axboe <[EMAIL PROTECTED]>
* SuSE Labs
-
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] removal of "static foo = 0" from drivers/ide (test11)

[Rusty Russell]

In message <[EMAIL PROTECTED]> you write:
> > On Tue, 21 Nov 2000 22:25:01 Bartlomiej Zolnierkiewicz wrote:
> > > 
> > > Quick removal of unnecessary initialization to 0.
> 
> Quite the contrary. The patch seems correct and useful to me. What do you
> think is wrong with it? (Linus accepted megabytes worth of the above in
> the past...)

What irritates about these monkey-see-monkey-do patches is that if I
initialize a variable to NULL, it's because my code actually relies on
it; I don't want that information eliminated.

Rusty.
--
Hacking 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/

[PATCH] G450 support for matroxfb

[Petr Vandrovec]

Hi,
  if there are unhappy owners of Matrox G450, I have gift for them.
Patch below is for 2.4.0-test11, and works on my dualhead G450,
16MB, DDR. 

  Because of there are no specs for this piece of hardware, currently:
(1) BIOS have to initialize hardware. Although chip presents
itself as G400, there is at least one additional PCI configuration
register :-( Not talking about completely new RAMDAC portion,
new memory interface, and so on... Hit them with big stick.
(2) Second head does not work. No spec, no game... Maybe after I
find some spare time.
(3) DAC is limited to 500MHz. Mine goes up to 959MHz, but without
datasheet I want to be conservative. It was very hard to get
this one piece...
(4) Everything is based on my piece of hardware; if it does not work
for you, complain loudly...

BTW, XF4.0.1e is also very unhappy on this hardware.
Best regards,
Petr Vandrovec
[EMAIL PROTECTED]



diff -urdN linux/Documentation/Configure.help linux/Documentation/Configure.help
--- linux/Documentation/Configure.help  Sat Nov 18 00:43:42 2000
+++ linux/Documentation/Configure.help  Fri Nov 24 19:24:38 2000
@@ -3210,9 +3210,9 @@
 CONFIG_FB_MATROX
   Say Y here if you have a Matrox Millennium, Matrox Millennium II,
   Matrox Mystique, Matrox Mystique 220, Matrox Productiva G100, Matrox
-  Mystique G200, Matrox Millennium G200, Matrox Marvel G200 video or
-  Matrox G400 card in your box. At this time, support for the G100,
-  Mystique G200 and Marvel G200 is untested.
+  Mystique G200, Matrox Millennium G200, Matrox Marvel G200 video,
+  Matrox G400 or G450 card in your box. At this time, support for the G100
+  is untested and support for G450 is highly experimental.
 
   This driver is also available as a module ( = code which can be
   inserted and removed from the running kernel whenever you want).
@@ -3241,13 +3241,13 @@
   packed pixel and 32 bpp packed pixel. You can also use font widths
   different from 8.
 
-Matrox G100/G200/G400 support
+Matrox G100/G200/G400/G450 support
 CONFIG_FB_MATROX_G100
-  Say Y here if you have a Matrox Productiva G100, Matrox Mystique
-  G200, Matrox Marvel G200 or Matrox Millennium G200 video card. If
-  you select "Advanced lowlevel driver options", you should check 8
-  bpp packed pixel, 16 bpp packed pixel, 24 bpp packed pixel and 32
-  bpp packed pixel. You can also use font widths different from 8.
+  Say Y here if you have a Matrox G100, G200, G400 or G450 based
+  video card. If you select "Advanced lowlevel driver options", you 
+  should check 8 bpp packed pixel, 16 bpp packed pixel, 24 bpp packed 
+  pixel and 32 bpp packed pixel. You can also use font widths 
+  different from 8.
 
   If you need support for G400 secondary head, you must first say Y to
   "I2C support" and "I2C bit-banging support" in the character devices
@@ -3270,6 +3270,8 @@
   
 Matrox G400 second head support
 CONFIG_FB_MATROX_MAVEN
+  WARNING !!! This support does not work with G450 !!!
+
   Say Y or M here if you want to use a secondary head (meaning two
   monitors in parallel) on G400 or MGA-TVO add-on on G200. Secondary
   head is not compatible with accelerated XFree 3.3.x SVGA servers -
diff -urdN linux/drivers/video/Config.in linux/drivers/video/Config.in
--- linux/drivers/video/Config.in   Mon Sep 18 22:15:22 2000
+++ linux/drivers/video/Config.in   Fri Nov 24 19:16:18 2000
@@ -104,7 +104,7 @@
 if [ "$CONFIG_FB_MATROX" != "n" ]; then
bool 'Millennium I/II support' CONFIG_FB_MATROX_MILLENIUM
bool 'Mystique support' CONFIG_FB_MATROX_MYSTIQUE
-   bool 'G100/G200/G400 support' CONFIG_FB_MATROX_G100
+   bool 'G100/G200/G400/G450 support' CONFIG_FB_MATROX_G100
 if [ "$CONFIG_I2C" != "n" ]; then
   dep_tristate '  Matrox I2C support' CONFIG_FB_MATROX_I2C 
$CONFIG_FB_MATROX $CONFIG_I2C_ALGOBIT
   if [ "$CONFIG_FB_MATROX_G100" = "y" ]; then
diff -urdN linux/drivers/video/matrox/matroxfb_DAC1064.c 
linux/drivers/video/matrox/matroxfb_DAC1064.c
--- linux/drivers/video/matrox/matroxfb_DAC1064.c   Thu Aug 10 19:34:31 2000
+++ linux/drivers/video/matrox/matroxfb_DAC1064.c   Fri Nov 24 19:25:40 2000
@@ -227,15 +227,35 @@
DBG("DAC1064_calcclock")
 
fvco = PLL_calcclock(PMINFO freq, fmax, in, feed, );
-   p = (1 << p) - 1;
-   if (fvco <= 10)
-   ;
-   else if (fvco <= 14)
-   p |= 0x08;
-   else if (fvco <= 18)
-   p |= 0x10;
-   else
-   p |= 0x18;
+   
+   if (ACCESS_FBINFO(devflags.g450dac)) {
+   if (fvco <= 30) /* 276-324 */
+   ;
+   else if (fvco <= 40)/* 378-438 */
+   p |= 0x08;
+   else if (fvco <= 55)  

PROBLEM: kernel oops at bootup (2.2.17, Mandrake 7.2)

[Wouter Verheijen]

Hello,

I just bought Linux Mandrake 7.2. The problem described applies to (at
least) the kernel used to boot the installation.
It OCCURS just after the detection of the buses and harddisks:
hda: 
hdc: 
hdd: 
Unable to handle kernel NULL pointer dereference at virtual address 0014
[see attached OOPS-TRACE, not absolutely sure this kernel matches this
System.map.]

Kernel version: 2.2.17
Kernel 2.2.14, 2.0, and 2.4-pre7 are known to WORK on my machine. I am
not sure if something was BROKEN in this specific release, or because
of certain options customized by Mandrake (for the installation)?

SYSTEM DESCRIPTION:
 Intel Pentium 133
 Host bridge: VIA Technologies VT 82C585 Apollo VP1/VPX (rev 2)
 48MB RAM
 NE2000 ethernet adapter
I also tried with BIOS safe options (e.g. no power management)

I hope you can point me out where to look for the problem. If you need
more information, please contact me.

Best regards,
-- 
Wouter Verheijen
[EMAIL PROTECTED]



processor   : 0
vendor_id   : GenuineIntel
cpu family  : 5
model   : 2
model name  : Pentium 75 - 200
stepping: 6
cpu MHz : 132.875605
fdiv_bug: no
hlt_bug : no
sep_bug : no
f00f_bug: yes
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr mce cx8
bogomips: 53.04



ksymoops 0.7c on i586 2.2.14-15mdk.  Options used
 -V (specified)
 -K (specified)
 -L (specified)
 -O (specified)
 -m /boot/System.map-2.2.17-21mdk (specified)

Unable to handle kernel NULL pointer dereference at virtual address 0014
current->tss.cr3 = 00101000, %cr3 = 00101000
*pde = 
Oops: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010002
eax:    ebx: 0202 ecx: fff4   edx: fe80
esi: 0004   edi: c02404d8 ebp: c0240498   esp: e2f19ee8
ds: 0018es: 0018   ss: 0018
Process swapper (pid: 1, process nr: 1, stackpage=c2f19000)
Stack:  c0108c73 fff4 600a c016c67c fff4 004b 0008 c01eea40
   c02404d8  0039 0053 0001 08181e23 c0181e45 c02404d8
   0008 c02404d8  c0240498 0246 0021 0053cfd8 c2f152e0
Call Trace: [] [] [] [] [] 
[c017ddbf>] []
[] [] []
Code: 8b 40 14 ff d0 83 c4 04 53 9d 5b c3 8d 76 00 53 8b 5c 24 08

>>EIP; c0108c59<=
Trace; 0c0108c7 Before first symbol
Trace; c016c67c 
Trace; c0181e45 
Trace; c0181ff1 
Trace; c017d504 
Trace; 0c010600 Before first symbol
Trace; c010615e 
Trace; c01065f3 
Code;  c0108c59 
 <_EIP>:
Code;  c0108c59<=
   0:   8b 40 14  mov0x14(%eax),%eax   <=
Code;  c0108c5c 
   3:   ff d0 call   *%eax
Code;  c0108c5e 
   5:   83 c4 04  add$0x4,%esp
Code;  c0108c61 
   8:   53push   %ebx
Code;  c0108c62 
   9:   9dpopf   
Code;  c0108c63 
   a:   5bpop%ebx
Code;  c0108c64 
   b:   c3ret
Code;  c0108c65 
   c:   8d 76 00  lea0x0(%esi),%esi
Code;  c0108c68 
   f:   53push   %ebx
Code;  c0108c69 
  10:   8b 5c 24 08   mov0x8(%esp,1),%ebx

Re: Recent patch to cfi.h screws MTD CFI layer

[David Woodhouse]

On Fri, 24 Nov 2000, Russell King wrote:

> The recent patch in 2.4.0-test11 causes MTD to oops the kernel:

Fixed in my tree. That and other things will be fixed when I flush the
latest CFI code to Linus - probably quite soon.

The inter_module_ stuff has introduced link order dependencies too. I'm
working on fixing that.

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

do_initcalls bug

[Pavel Machek]

Hi!

static void __init do_initcalls(void)
{
initcall_t *call;

call = &__initcall_start;
do {
early_printk("[%lx]\n", call);
(*call)();
call++;
} while (call < &__initcall_end);
}

In case there are no initcalls to be called, it just simply
crashes. Ouch.

Pavel
-- 
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

2.4-test11 does not compile

[mkloppstech]

The following .config does not compile under 2.4-test11.
Reason is the choice of the Athlon.
If taking P-Pro/P II it compiles correctly.


#
# Automatically generated by make menuconfig: don't edit
#
CONFIG_X86=y
CONFIG_ISA=y
# CONFIG_SBUS is not set
CONFIG_UID16=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_M686FXSR is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_USE_3DNOW=y
CONFIG_X86_PGE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_TOSHIBA is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
# CONFIG_MTRR is not set
# CONFIG_SMP is not set
# CONFIG_X86_UP_IOAPIC is not set

#
# General setup
#
CONFIG_NET=y
# CONFIG_VISWS is not set
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
CONFIG_HOTPLUG=y

#
# PCMCIA/CardBus support
#
CONFIG_PCMCIA=y
CONFIG_CARDBUS=y
# CONFIG_I82365 is not set
# CONFIG_TCIC is not set
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
CONFIG_PM=y
CONFIG_ACPI=y
# CONFIG_ACPI_INTERPRETER is not set
# CONFIG_ACPI_S1_SLEEP is not set
# CONFIG_APM is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play configuration
#
CONFIG_PNP=y
CONFIG_ISAPNP=y

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_BLK_DEV_INITRD is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
# CONFIG_BLK_DEV_MD is not set
# CONFIG_MD_LINEAR is not set
# CONFIG_MD_RAID0 is not set
# CONFIG_MD_RAID1 is not set
# CONFIG_MD_RAID5 is not set
# CONFIG_BLK_DEV_LVM is not set
# CONFIG_LVM_PROC_FS is not set

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
# CONFIG_NETLINK is not set
# CONFIG_NETFILTER is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_INET_ECN is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_IPV6 is not set
# CONFIG_KHTTPD is not set
# CONFIG_ATM is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_LLC is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set
# CONFIG_PHONE_IXJ is not set

#
# ATA/IDE/MFM/RLL support
#
CONFIG_IDE=y

#
# IDE, ATA and ATAPI Block devices
#
CONFIG_BLK_DEV_IDE=y
# CONFIG_BLK_DEV_HD_IDE is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_BLK_DEV_IDEDISK=y
# CONFIG_IDEDISK_MULTI_MODE is not set
# CONFIG_BLK_DEV_IDEDISK_VENDOR is not set
# CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set
# CONFIG_BLK_DEV_IDEDISK_IBM is not set
# CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set
# CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set
# CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set
# CONFIG_BLK_DEV_IDEDISK_WD is not set
# CONFIG_BLK_DEV_COMMERIAL is not set
# CONFIG_BLK_DEV_TIVO is not set
# CONFIG_BLK_DEV_IDECS is not set
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
CONFIG_BLK_DEV_CMD640=y
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
# CONFIG_BLK_DEV_ISAPNP is not set
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_IDEDMA_PCI is not set
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_IDEDMA_PCI_AUTO is not set
# CONFIG_BLK_DEV_IDEDMA is not set
# CONFIG_IDEDMA_PCI_WIP is not set
# 

Re: [patch] O_SYNC patch 3/3, add inode dirty buffer list support to ext2

[Andrea Arcangeli]

On Thu, Nov 23, 2000 at 01:01:25PM -0700, Jeff V. Merkey wrote:
> On Thu, Nov 23, 2000 at 12:01:35PM +, Stephen C. Tweedie wrote:
> > Hi,
> > 
> > On Wed, Nov 22, 2000 at 11:54:24AM -0700, Jeff V. Merkey wrote:
> > > 
> > > I have not implemented O_SYNC in NWFS, but it looks like I need to add it 
> > > before posting the final patches.  This patch appears to force write-through 
> > > of only dirty inodes, and allow reads to continue from cache.  Is this
> > > assumption correct
> > 
> > Yes: O_SYNC is not required to force reads to be made from disk.
> > SingleUnix has an "O_RSYNC" option which does that, but O_SYNC and
> > O_DSYNC don't imply that.
> 
> Cool.  ORACLE is going to **SMOKE** on EXT2 with this change.

Note that this is nothing new, linux (say 2.2.18pre23) always used the O_SYNC
semantics Stephen implemented in the 2.4.x O_SYNC showstopper bugfix.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Recent patch to cfi.h screws MTD CFI layer

[Russell King]

The recent patch in 2.4.0-test11 causes MTD to oops the kernel:

diff -u --recursive --new-file v2.4.0-test10/linux/include/linux/mtd/cfi.h 
linux/include/linux/mtd/cfi.
h
--- v2.4.0-test10/linux/include/linux/mtd/cfi.h Tue Jul  4 10:12:34 2000
+++ linux/include/linux/mtd/cfi.h   Tue Nov  7 10:46:04 2000
@@ -92,6 +92,7 @@
int numchips;
unsigned long chipshift; /* Because they're of the same type */
struct flchip chips[0];  /* per-chip data structure for each chip */
+   const char *im_name; /* inter_module name for cmdset_setup */
 };

 #define MAX_CFI_CHIPS 8 /* Entirely arbitrary to avoid realloc() */

This is what happens to chips[].start during initialisation:

chip 0 start 0
chip 1 start 80
chip 2 start 100
chip 3 start 180
 Intel/Sharp Extended Query Table at 0x0031
chip 0 start c013b45c   <--- overwritten by write to im_name
chip 1 start 80
chip 2 start 100
chip 3 start 180
chip 0 start c013b45c
chip 1 start 80
chip 2 start 100
chip 3 start 180
number of CFI chips: 4
chip 0 start c013b45c
chip 1 start 80
chip 2 start 100
chip 3 start 180

Here is a patch that fixes the problem, and includes a warning to tell
people not to add extra fields after the "chips" element.

--- linux.orig/include/linux/mtd/cfi.h  Sat Nov 18 21:54:02 2000
+++ linux/include/linux/mtd/cfi.h   Fri Nov 24 17:57:06 2000
@@ -209,8 +209,9 @@
  must be of the same type. */
int numchips;
unsigned long chipshift; /* Because they're of the same type */
-   struct flchip chips[0];  /* per-chip data structure for each chip */
const char *im_name; /* inter_module name for cmdset_setup */
+   struct flchip chips[0];  /* per-chip data structure for each chip */
+   /* do not add extra fields after "chips" */
 };
 
 #define MAX_CFI_CHIPS 8 /* Entirely arbitrary to avoid realloc() */

   _
  |_| - ---+---+-
  |   | Russell King[EMAIL PROTECTED]  --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+ --- -+-
  /   |   THE developer of ARM Linux  |+| /|\
 /  | | | ---  |
+-+-+ -  /\\\  |
-
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: ext2 filesystem corruptions back from dead? 2.4.0-test11

[Linus Torvalds]

In article <[EMAIL PROTECTED]>,
Guest section DW  <[EMAIL PROTECTED]> wrote:
>
>(But I described the situation where the data on disk was correct
>and the date in core was not - almost certainly this is not an IDE problem.)

Ehh.. It only means that it would have been a read failure instead of a
write failure.

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: linux-2.2.18-pre19 asm/delay.h problem?

[Jeff Epler]

On Fri, Nov 24, 2000 at 11:15:50AM -0600, Oliver Xymoron wrote:
> You could still change it to
> __bug__module_is_using_a_delay_thats_too_large__please_report()..

I thought that's where we started?

Can we somehow use the GNU linker trick which permits a warning about e.g.
gets at link time?  (Is it even documented somewhere?)  Something like:

/* bad_udelay.c */
static char bad_udelay_warning[] __attribute__((__section__(".gnu.warning")))
= "warning: constant udelay too long";
bad_udelay() { BUG(); }

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/

Re: linux-2.2.18-pre19 asm/delay.h problem?

[Oliver Xymoron]

On Wed, 22 Nov 2000, Alan Cox wrote:

> > > |> > > #define __bad_udelay() panic("Udelay called with too large a constant")
> > > |> 
> > > |> Can't we change that to :
> > > |> #error "Udelay..."
> > > 
> > > No.
> > 
> > ?? I think I'm missing something here.
> 
> preprocessor stuff is done too early for this

You could still change it to
__bug__module_is_using_a_delay_thats_too_large__please_report()..

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 

-
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: Why not PCMCIA built-in and yenta/i82365 as modules

[Oliver Xymoron]

On Wed, 22 Nov 2000, Matti Aarnio wrote:

> On Tue, Nov 21, 2000 at 11:34:45PM +0100, Tobias Ringstrom wrote:
> > The subject says it all. Is there any particular (technical) reason
> > why I must have both the generic pcmcia code and the controller support
> > built-in, or build all of them as modules?
> > 
> > /Tobias
> 
> Wasn't there some strange laptop model which had PCMCIA floppy/CDROM,
> which are unavailable to bootstrap process, unless PCMCIA is supported
> at the booting kernel ?
> 
> Or was it about USB floppy at some other laptop?

Yes and yes. However, you still would need the controller specific code
built-in.

The USB floppy situation is uglier still. When I tried to put Debian on my
VAIO from floppy, I discovered that even with a USB-enabled kernel, the
floppy wasn't available in time to mount /. 

Approaches that did work, in case anyone is curious, were using loadlin
with FreeDOS (incredibly slow) to preload the second floppy via BIOS, or
using syslinux and a custom mini-kernel and initrd image crammed onto a
single floppy.

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 


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

Strange IP-Connection

["Rüegg, Peter H."]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I encounter quite a lot of strange connection on a very busy server
here.
tcpdump -S -n on the firewall in front of it reports as follows:

16:13:03.531896 eth0 > 193.8.109.35.4870 > 212.27.173.35.www: S
1693092819:1693092819(0) win 16384 
16:13:03.532069 eth0 < 212.27.173.35.www > 193.8.109.35.4870: S
2207402096:2207402096(0) ack 1693092820 win 32256  (DF)
16:13:03.598989 eth0 > 193.8.109.35.4870 > 212.27.173.35.www: .
1693092820:1693092820(0) ack 2207402097 win 16384 
16:13:03.610774 eth0 > 193.8.109.35.4870 > 212.27.173.35.www: .
1693092820:1693093320(500) ack 2207402097 win 16384

16:13:03.611024 eth0 < 212.27.173.35.www > 193.8.109.35.4870: .
2207402097:2207402097(0) ack 1693093320 win 31756  (DF)
16:13:03.611466 eth0 > 193.8.109.35.4870 > 212.27.173.35.www: P
1693093320:1693093368(48) ack 2207402097 win 16384 
16:13:03.612058 eth0 < 212.27.173.35.www > 193.8.109.35.4870: P
2207402097:2207402239(142) ack 1693093368 win 32500
 (DF)
16:13:03.612189 eth0 < 212.27.173.35.www > 193.8.109.35.4870: F
2207402239:2207402239(0) ack 1693093368 win 32500  (DF)
16:13:03.689108 eth0 > 193.8.109.35.4870 > 212.27.173.35.www: .
1693093368:1693093368(0) ack 2207402240 win 16242 
16:13:03.689305 eth0 > 193.8.109.35.4870 > 212.27.173.35.www: F
1693093368:1693093368(0) ack 2207402240 win 16384 
16:13:03.689468 eth0 < 212.27.173.35.www > 193.8.109.35.4870: .
2207402240:2207402240(0) ack 1693093369 win 32500  (DF)
16:13:05.661668 eth0 > 193.8.109.35.4870 > 212.27.173.35.www: F
1693093368:1693093368(0) ack 2207402240 win 16384 
16:13:05.661807 eth0 < 212.27.173.35.www > 193.8.109.35.4870: .
4821635:4821635(0) ack 4186827364 win 32500
16:13:05.737763 eth0 > 193.8.109.35.4870 > 212.27.173.35.www: F
1693093368:1693093368(0) ack 2207402240 win 16384 
16:13:05.737914 eth0 < 212.27.173.35.www > 193.8.109.35.4870: .
4821635:4821635(0) ack 4186827364 win 32500
16:13:05.808887 eth0 > 193.8.109.35.4870 > 212.27.173.35.www: F
1693093368:1693093368(0) ack 2207402240 win 16384 
16:13:05.809077 eth0 < 212.27.173.35.www > 193.8.109.35.4870: .
4821635:4821635(0) ack 4186827364 win 32500
16:13:05.870439 eth0 > 193.8.109.35.4870 > 212.27.173.35.www: F
1693093368:1693093368(0) ack 2207402240 win 16384 
16:13:05.870607 eth0 < 212.27.173.35.www > 193.8.109.35.4870: .
4821635:4821635(0) ack 4186827364 win 32500

followed by approximately 1000 repetitions of the last two lines.

My questions are:

   a) Why does the server acknowledge 1693093368, which is wrong, as
it
  should be one higher.
   b) After finally admitting that 1693093369 should be the correct
value
  to send it doesn't Accept the FIN.
   c) And why on earth does the server come up with a completely
different
  connection shortafter?

As said before, this is a very busy machine. The Kernel is 2.2.16
with
the Openwall patches appended. The networkcard is a eepro100, dmesg
reports
"eth0: OEM i82557/i82558 10/100 Ethernet, Board assembly 735190-002,
primary interface chip i82555 PHY #1, ROM checksum self-test passed,
eepro100.c:v1.09j-t 9/29/99 Donald Becker, $Revision: 1.20.2.10 $
2000/05/31"
etc.

The same machine sometimes complains about "Could not fetch RX buffer
(force
0)" or "force 1", so it may be a Hardware-Problem.

I have tcp_syncookies enabled, which may be part of the problem.

The problem seems to happen with quite a lot of machines out there,
of which
I have good reasons to attempt, that their IP isn't spoofed. What
connects
all of them, is that they have a pretty fast connection to us.


Does anyone have an idea, what the problem could be?

Thanks a lot - I will have a look at the source myself, as soon as
I find the time to.

Greets

Peter H. Ruegg
Systems-/Networkadministrator eProduction AG

-BEGIN PGP SIGNATURE-
Version: PGPfreeware 6.5.8 for non-commercial use 

iQA/AwUBOh6Rilcv4X0c4GKrEQLm3ACgsZa98dDQOYdtDoUaXC8oliTexGEAoITh
1EVOdXZoEoaomtANTnlp0Lkr
=MntP
-END PGP SIGNATURE-
-
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/

Problems with 2.4.0test11 and PCI bridges

[John Thorp]

I have just tried to move to the 2.4.0-test11 kernel from the kernel
supplied with Redhat 7. With the Redhat 7 kernel I can see all the PCI slots
fine. However, when I try with the 2.4.0test11 it no longer seems to be able
to find some of the PCI buses. Is there something I can do to get the kernel
to see these PCI buses?

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: deadlock on 4way machine

[Oliver Xymoron]

On Tue, 21 Nov 2000, Tigran Aivazian wrote:

> On 21 Nov 2000, Jes Sorensen wrote:
> 
> > > "Tigran" == Tigran Aivazian <[EMAIL PROTECTED]> writes:
> > 
> > Tigran> Hi, Some processes get stuck in page fault handler for ages
> > Tigran> (like for 10 minutes!). The machine still has plenty (3.5G) of
> > Tigran> free high memory but zero (2216K) of free low memory.
> > 
> > Including info on the kernel version would kinda help.
> 
> that is obtainable by fingering @finger.kernel.org (I only ever use/report
> bugs on the latest kernel).

I think only Linus can claim that. At any rate, the world isn't going to
remember your particular preference for the latest kernel, nor is it going
to go to the trouble of trying to correlate the date on your messages with
a history of patch releases. If you report a bug thought to be fixed,
it'll just be assumed to be old.

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 

-
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: gcc-2.95.2-51 is buggy

[Matthew Vanecek]

[EMAIL PROTECTED] wrote:
> 
> > so the reason why it did not show up in the gcc you picked up from
> > ftp.gnu.org is that you have compiled it so that it defaults to -mcpu=i686
> 
> Yes, you are right.
> 
> So 2.95.2 fails for i386, i486, i586 and does not fail for i686.
> 

RedHat 7.0's gcc 2.96 and kgcc do not seem to exhibit this problem:

me2v@reliant tmp $ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 2731 (Red Hat Linux 7.0)
me2v@reliant tmp $ kgcc -v
Reading specs from
/usr/lib/gcc-lib/i386-glibc21-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
me2v@reliant tmp $ gcc -O2 -o bug bug.c ; ./bug
0x0
me2v@reliant tmp $ gcc -o bug bug.c ; ./bug
0x0
me2v@reliant tmp $ kgcc -O2 -o bug bug.c ; ./bug
0x0
me2v@reliant tmp $ kgcc -o bug bug.c ; ./bug
0x0

-- 
Matthew Vanecek
perl -e 'print
$i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'

For 93 million miles, there is nothing between the sun and my shadow
except me.
I'm always getting in the way of something...
-
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-test10 FAT oops

[Samuli Kaski]

I have had at least 2 similar (maybe even identic) oopses with 2.3/2.4
kernels in the past. Either there is still something wrong with FAT or
it's my hardware. Nevertheless, here it is.

Samuli

Nov 24 18:30:37 vortex kernel: Unable to handle kernel NULL pointer dereference at 
virtual address 0010 
Nov 24 18:30:37 vortex kernel:  printing eip: 
Nov 24 18:30:37 vortex kernel: c01599b0 
Nov 24 18:30:37 vortex kernel: *pde =  
Nov 24 18:30:37 vortex kernel: Oops: 0002 
Nov 24 18:30:37 vortex kernel: CPU:1 
Nov 24 18:30:37 vortex kernel: EIP:0010:[fat_cache_add+148/176] 
Nov 24 18:30:37 vortex kernel: EFLAGS: 00010246 
Nov 24 18:30:37 vortex kernel: eax:    ebx: 00021fdb   ecx:    edx: 
c02ac878 
Nov 24 18:30:37 vortex kernel: esi: 00021da4   edi: c3eba080   ebp: 0235   esp: 
c1a67e04 
Nov 24 18:30:37 vortex kernel: ds: 0018   es: 0018   ss: 0018 
Nov 24 18:30:37 vortex kernel: Process ncftp (pid: 10416, stackpage=c1a67000) 
Nov 24 18:30:37 vortex kernel: Stack: 0235 c3eba080 c7af2a00 00021fdb 034b0235 
c015dcf6 c3eba080 0235  
Nov 24 18:30:37 vortex kernel:00021fdb  11a8 c3eba080 c0d36300 
0017bb36 0008 00021fda  
Nov 24 18:30:37 vortex kernel: c015b6e5 c3eba080 c015b654 0200 
0235 c1a67ea8 0008  
Nov 24 18:30:37 vortex kernel: Call Trace: [fat_add_cluster+438/484] 
[fat_get_block+145/232] [fat_get_block+0/232] [__block_prepare_write+245/576] 
[cont_prepare_write+371/524] [fat_get_block+0/232] [fat_prepare_write+38/44]  
Nov 24 18:30:37 vortex kernel:[fat_get_block+0/232] 
[generic_file_write+749/1060] [default_fat_file_write+34/88] [fat_file_write+45/52] 
[sys_write+142/196] [system_call+51/56] [startup_32+43/204]  
Nov 24 18:30:37 vortex kernel: Code: c7 41 10 00 00 00 00 a1 e0 c7 2a c0 89 42 10 89 
15 e0 c7 2a  
Nov 24 18:30:37 vortex kernel: Unable to handle kernel NULL pointer dereference at 
virtual address 0010 
Nov 24 18:30:37 vortex kernel:  printing eip: 
Nov 24 18:30:37 vortex kernel: c01599b0 
Nov 24 18:30:37 vortex kernel: *pde =  
Nov 24 18:30:37 vortex kernel: Oops: 0002 
Nov 24 18:30:37 vortex kernel: CPU:0 
Nov 24 18:30:37 vortex kernel: EIP:0010:[fat_cache_add+148/176] 
Nov 24 18:30:37 vortex kernel: EFLAGS: 00010246 
Nov 24 18:30:37 vortex kernel: eax:    ebx: 000d1b98   ecx:    edx: 
c02ac878 
Nov 24 18:30:37 vortex kernel: esi: 000d1900   edi: c4d66b40   ebp: 0297   esp: 
c4963dd8 
Nov 24 18:30:37 vortex kernel: ds: 0018   es: 0018   ss: 0018 
Nov 24 18:30:37 vortex kernel: Process mxaudio (pid: 10379, stackpage=c4963000) 
Nov 24 18:30:37 vortex kernel: Stack: 0297 c4d66b40 0297 c0369ba0 034b0297 
c0159ab0 c4d66b40 0297  
Nov 24 18:30:37 vortex kernel:000d1b98 c7af2a9c 0001 0297 000d1b98 
c0159b4b c4d66b40 0297  
Nov 24 18:30:37 vortex kernel:c4d66b40 14b9 c4d66b40 0008 c015948b 
c4d66b40 14b9 c015b66e  
Nov 24 18:30:37 vortex kernel: Call Trace: [fat_get_cluster+140/164] 
[default_fat_bmap+131/164] [fat_bmap+27/32] [fat_get_block+26/232] 
[fat_get_block+0/232] [block_read_full_page+308/616] [__alloc_pages_limit+124/176]  
Nov 24 18:30:37 vortex kernel:[add_to_page_cache_unique+291/308] 
[fat_readpage+15/20] [fat_get_block+0/232] [generic_file_readahead+598/832] 
[do_generic_file_read+568/1344] [generic_file_read+99/128] [file_read_actor+0/84] 
[fat_file_read+45/52]  
Nov 24 18:30:37 vortex kernel:[sys_read+146/200] [system_call+51/56]  
Nov 24 18:30:37 vortex kernel: Code: c7 41 10 00 00 00 00 a1 e0 c7 2a c0 89 42 10 89 
15 e0 c7 2a

-
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] Re: PROBLEM: kernel 2.4.0-test11-ac1 hang with usb-uhciand emu10k1

[Linus Torvalds]

On Thu, 23 Nov 2000, Michael Elkins wrote:
> 
> On Thu, Nov 23, 2000 at 03:53:27PM -0800, Linus Torvalds wrote:
> > Try changing the thing around a bit: make the above place say
> > 
> > /* disable legacy emulation */
> > pci_write_config_word (dev, USBLEGSUP, 0);
> > 
> > and then AFTER we have successfully done a request_irq() call, we 
> > can enable PCI interrupts with
> > 
> > /* Enable PIRQ */
> > pci_write_config_word (dev, USBLEGSUP, USBLEGSUP_DEFAULT);
> > 
> > Does that make it happier?
> 
> Yep! That seems to have fixed it.  Added the pci_write_config_word() after
> the request_irq() in alloc_uhci().

Johannes, can you get in touch with the right people and make sure this
gets fixed in both uhci drivers? They both look like they have the same
bug, and I'd prefer not to do it by hand as I don't have that much in the
form of USB..

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: Booting AMD Elan520 without BIOS

[Ronald G Minnich]

On Fri, 24 Nov 2000, Joan Bertran wrote:

>  I think so, because I've read somewhere the kernel needs interrupts 
> configured, but as kernel configures i8259 I don't know what is necessary,
> the IDT with interrupt service routines ?, sommething special about the chipset ?

I put the following familiar-looking code at the head of linuxbios for
mainboards that need to boot 2.2.x. It should look familiar, except of
course this is 32-bit gas-compatible code. 


#define i8259delay jmp 1f ; 1:

movb$0x11,%al   /*! initialization sequence*/
outb%al,$0x20   /*! send it to 8259A-1*/
i8259delay
outb%al,$0xA0   /*! and to 8259A-2*/
i8259delay
movb$0x20,%al   /*! start of hardware int's
(0x20)*/
outb%al,$0x21
i8259delay
movb$0x28,%al   /*! start of hardware int's 2
(0x28)*/
outb%al,$0xA1
i8259delay
movb$0x04,%al   /*! 8259-1 is master*/
outb%al,$0x21
i8259delay
movb$0x02,%al   /*! 8259-2 is slave*/
outb%al,$0xA1
i8259delay
movb$0x01,%al   /*! 8086 mode for both*/
outb%al,$0x21
i8259delay
outb%al,$0xA1
i8259delay
movb$0xFF,%al   /*! mask off all interrupts for
now*/
outb%al,$0xA1
i8259delay
movb$0xFB,%al   /*! mask all irq's but irq2
which*/
outb%al,$0x21   /*! is cascaded*/



-
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: Booting AMD Elan520 without BIOS

[Ronald G Minnich]

On Fri, 24 Nov 2000, I+D wrote:

> I'm trying to boot an AMD Elan520 board without bios
> with kernel 2.4.0-test10 configured for i486 and PCI direct access.
> This kernel boots correctly from HD using the bios provided with the 
> evaluation board but kernel 2.4.0-test8 and previous hang
> after "Ok booting the kernel".

well, first I want your code for linuxbios :-)

>   The last message I see is "Calibrating delay loop"
> (I see this thaks to the Jtag debugger for Elan520 because
> I haven't configured the VGA board yet).

you don't have clock interrupts on. If you are able to single step you'll
probably see it in the loop spinning on jiffies. This is one of our
regular problems with a new mainboard.

Also do you have serial console up? in many cases we have found that
having serial up eliminates about 50% of the things you do with a jtag
debugger.

ron

-
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: Can't mount SCSI CDROM in 2.4.*

[Roland Orre]

Douglas Gilbert <[EMAIL PROTECTED]> Fri Nov 24 wrote:
> Roland,
> What does 'cat /proc/scsi/scsi' output on your machine?
> Which SCSI adapter do you have?
> Doug Gilbert

My scsi adapter is adaptec 7880 on one machine and 7890 on
the other, i.e. driver is aic7xxx

This is what 'cat /proc/scsi/scsi' says when I've booted with 2.4.0-test11
Attached devices: 
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: IBM  Model: DNES-318350W Rev: SA30
  Type:   Direct-AccessANSI SCSI revision: 03
Host: scsi0 Channel: 00 Id: 04 Lun: 00
  Vendor: PIONEER  Model: CD-ROM DR-U06S   Rev: 1.05
  Type:   CD-ROM   ANSI SCSI revision: 02

And when I give the mount command:
bayes:~# mount -t iso9660 /dev/sr0 /cdrom
mount: /dev/sr0 has wrong major or minor number

And this is what 'cat /proc/scsi/scsi' says when I've booted with 2.2.17
Attached devices: 
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: IBM  Model: DNES-318350W Rev: SA30
  Type:   Direct-AccessANSI SCSI revision: 03
Host: scsi0 Channel: 00 Id: 04 Lun: 00
  Vendor: PIONEER  Model: CD-ROM DR-U06S   Rev: 1.05
  Type:   CD-ROM   ANSI SCSI revision: 02

And when I give the mount command then:
bayes:~# mount -t iso9660 /dev/sr0 /cdrom
mount: block device /dev/sr0 is write-protected, mounting read-only
I.e. the mounting works fine.

And this is the other machine, at the moment running 2.4.0-test7
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: IBM  Model: DRVS18V  Rev: 00E5
  Type:   Direct-AccessANSI SCSI revision: 03
Host: scsi0 Channel: 00 Id: 02 Lun: 00
  Vendor: PIONEER  Model: DVD-ROM DVD-303  Rev: 1.10
  Type:   CD-ROM   ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 05 Lun: 00
  Vendor: YAMAHA   Model: CRW6416S Rev: 1.0b
  Type:   CD-ROM   ANSI SCSI revision: 02

bayes:/home/orre# mount -t iso9660 /dev/sr0 /cdrom
mount: /dev/sr0 has wrong major or minor number

As I said in last mail, major number= 11 and minor = 0, which is
in accordance with the documentation for both 2.2. and 2.4.

So what can this be? Can somebody that are running scsi cdrom/cdwriter
under 2.4.0-test* kernel send me a .config file so I can see if there
is any significant difference, if you don't have any other idea of
what it can be?

 Best regards
 Roland Orre
-
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: Booting AMD Elan520 without BIOS

[Joan Bertran]

> -Mensaje original-
> De: Jon Burgess [mailto:[EMAIL PROTECTED]]
> Enviado el: viernes 24 de noviembre de 2000 16:40
> Para: [EMAIL PROTECTED]
> Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
> Asunto: Re: Booting AMD Elan520 without BIOS
> 
> 
> 
> I've seen this on a board with a BIOS problem. I think it is 
> caused because 
> the
> Kernel is in a loop waiting for a timer interrupt to occur. If the 
> interrupt
> never arrives it loops forever.
> 
>  Jon
> 
> 
 I think so, because I've read somewhere the kernel needs interrupts 
configured, but as kernel configures i8259 I don't know what is necessary,
the IDT with interrupt service routines ?, sommething special about the chipset ?

Joan Bertran.


-
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: gcc 2.95.2 is buggy

[Bernd Schmidt]

On Fri, 24 Nov 2000, Tom Rini wrote:

> Well, now that there is a testcase, has anyone sent this on to the relevant
> gcc lists? (The CCs I saw haven't)

Yes.  I've just sent a fix to gcc-patches.

Bernd

-
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: Booting AMD Elan520 without BIOS

[Jon Burgess]

>The last message I see is "Calibrating delay loop"
>(I see this thaks to the Jtag debugger for Elan520 because
>I haven't configured the VGA board yet).

I've seen this on a board with a BIOS problem. I think it is caused because the
Kernel is in a loop waiting for a timer interrupt to occur. If the interrupt
never arrives it loops forever.

 Jon




PLANET PROJECT will connect millions of people worldwide through the combined
technology of 3Com and the Internet. Find out more and register now at
http://www.planetproject.com


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: gcc 2.95.2 is buggy

[Tom Rini]

On Thu, Nov 23, 2000 at 11:47:04PM -0500, Alexander Viro wrote:
> 
> 
> On Thu, 23 Nov 2000, Gregory Maxwell wrote:
> 
> > On Fri, Nov 24, 2000 at 02:57:45AM +0100, [EMAIL PROTECTED] wrote:
> > > but in the meantime there is good confirmation.
> > > This really is a bug in gcc 2.95.2.
> > 
> > ... RedHat's GCC snapshot "2.96" handles this case just fine. 
> 
> Now, if you can isolate the relevant part of the diff between 2.95.2 and
> RH 2.96...

Well, now that there is a testcase, has anyone sent this on to the relevant
gcc lists? (The CCs I saw haven't)

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
-
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/

alpha: small PCI fixes (test11-ac3)

[Ivan Kokshaysky]

Just out of curiosity I tried S3 Sonic Vibes sound card, which has
only 24 address lines connected, on sx164. This revealed two bugs
in the pci code:
 - dma mask 0x00ff (24 bits) exactly fits the ISA scatter-gather
   window, but was rejected by pci_dma_supported() due to off-by-one bug.
 - this card has some non-standard set of I/O ports, and driver tries to
   allocate resource for it at the runtime.  At this time
   pcibios_update_resource() already has been vanished.

With these fixes the card started to work to the best of its ability,
i.e. screechy and noisy, so after being so helpful the poor thing went
back into the rubbish bin...

Ivan.

--- 2.4.0t11ac3/arch/alpha/kernel/pci_iommu.c   Sat Sep 23 01:07:43 2000
+++ linux/arch/alpha/kernel/pci_iommu.c Thu Nov 23 14:35:40 2000
@@ -613,10 +613,10 @@ pci_dma_supported(struct pci_dev *pdev, 
/* Check that we have a scatter-gather arena that fits.  */
hose = pdev ? pdev->sysdata : pci_isa_hose;
arena = hose->sg_isa;
-   if (arena && arena->dma_base + arena->size <= mask)
+   if (arena && arena->dma_base + arena->size - 1 <= mask)
return 1;
arena = hose->sg_pci;
-   if (arena && arena->dma_base + arena->size <= mask)
+   if (arena && arena->dma_base + arena->size - 1 <= mask)
return 1;
 
return 0;
--- 2.4.0t11ac3/arch/alpha/kernel/pci.c Thu Nov 23 13:07:02 2000
+++ linux/arch/alpha/kernel/pci.c   Thu Nov 23 15:09:59 2000
@@ -282,7 +282,7 @@ pcibios_fixup_bus(struct pci_bus *bus)
}
 }
 
-void __init
+void
 pcibios_update_resource(struct pci_dev *dev, struct resource *root,
struct resource *res, int resource)
 {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

The Birthday of the Year!!

[Davide Piana]

Hallo!
If you wanna drink a lot and eat with a lot
of fun you *MUST* go to Italy this evening
for the Birthday of the Year
the date is at 21:00!!

WE ARE WAITING FOR YOU!

Mail me for more info about the place!
-
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: How to freeze the kernel

[Douglas Gilbert]

Ulrich Windl wrote:
> 
> Hello,
> 
> this is for your interest, amusement, and for "what not to do":
> 
> I managed to freeze the kernel (2.2.16 from SuSE Linux 7.0) in a way
> that I could not even switch virtual consoles. Completely silent
> eberything...
> 
> It all started when Windows/95 ruined another CD-R while trying to
> write an image to the media. So I decided to try it with Linux, using
> the same CD writer.
> 
> I plugged the device to the so far unused SCSI channel and used the
> "add-sigle-device" method to avoid reboot, and I succeeded:
> 
> kgate kernel: scsi singledevice 0 0 4 0
> kgate kernel:   Vendor: WAITECModel: WT624 Rev: 7.0F
> kgate kernel:   Type:   CD-ROM ANSI SCSI
> revision: 0
> kgate kernel: Detected scsi CD-ROM sr1 at scsi0, channel 0, id 4, lun 0
> kgate kernel: (scsi0:0:4:0) Synchronous at 10.0 Mbyte/sec, offset 15.
> kgate kernel: sr1: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda
> tray
> 
> Then I used "cdrecord-1.8.1" to simulate writing at "speed=8". It
> worked so far, but there was a warning about possible problems with
> "simulated fixation", and actually several minutes nothing happened
> while the simulated fixation was expected to take place.

Evidently some media/cdwriters don't like "simulated
fixation" hence the comment from cdrecord. In your
case the warning seems well founded.

When cdrecord issues the SCSI command to fixate
(0x5b on my Yamaha) it sets a long timeout (480.5
seconds (8 minutes)). To find out the current
state (in the lk 2.4 series) try:

$ cat /proc/scsi/sg/debug 
dev_max(currently)=9 max_active_device=3 (origin 1)
 scsi_dma_free_sectors=512 sg_pool_secs_aval=320 def_reserved_size=32768
 >>> device=sg2 scsi2 chan=0 id=6 lun=0   em=0 sg_tablesize=255 excl=0
   FD(1): timeout=480500ms bufflen=32768 (res)sgat=0 low_dma=0
   cmd_q=0 f_packid=0 k_orphan=0 closed=0
 act: id=4054 blen=0 t_o/elap=480500/9920ms sgat=0 op=0x5b

$ cat /proc/scsi/sg/debug 
dev_max(currently)=9 max_active_device=3 (origin 1)
 scsi_dma_free_sectors=512 sg_pool_secs_aval=320 def_reserved_size=32768
 >>> device=sg2 scsi2 chan=0 id=6 lun=0   em=0 sg_tablesize=255 excl=0
   FD(1): timeout=480500ms bufflen=32768 (res)sgat=0 low_dma=0
   cmd_q=0 f_packid=0 k_orphan=0 closed=0
 act: id=4054 blen=0 t_o/elap=480500/13840ms sgat=0 op=0x5b

The last line of these 2 commands shows that SCSI command
0x5b is active with a timeout value of 480500 milliseconds.
9.92 seconds has elapsed when the first 'cat'
was executed and 13.8 seconds had elapsed when
the second one was executed. In my test case
the "dummy fixate" concluded successfully. But what if
it locked up the cdwriter, as the warning hints at?

There is no way that I know of to cancel
a command once it is "active". The timeout
will get it (usually by the brute force
technique of resetting the SCSI bus). [I
have toyed with the idea of trying to shorten
the timeout of an active command.]
 
> At some point I hit ^C, returning to the prompt. As the device did not
> seem to be ready, I thought "remove the device and reconnect", so I did
> "remove-single-device" (possibly while a command was still "busy"). The
> remove suceeded, but a second later everything had stopped!

Things _not_ to do while there is an active
SCSI command still executing:
  - remove a module that it is using
(e.g. sg, aic7xxx, scsi_mod).
In most (but not all) cases rmmod will 
report the module is busy.
  - use remove-single-device
 
> Should a device with busy commands be able to be removed? I guess no...

Correct.
 
> The last message in the syslog was:
> 
> kgate kernel: scsi : aborting command due to timeout : pid 8358,
>  scsi0, channel 0, id 4, lun 0 UNKNOWN(0x5b) 00 02 00 00 00 00 00 00 00
> 
> At that point I pressed "RESET", and interestingly the builtin BIOS of
> the Adaptec 2740 (EISA) hung while trying to detect the device.

In my experience cdwriters are not always well behaved
SCSI devices and can lockup and not respond to SCSI
bus resets. This means you need to power cycle them
to get them back into a functional mode. It is also
a good reason _not_ to have SCSI cdwriters (and scanners)
on the same SCSI bus as high speed modern SCSI disks.
Luckily they tend to use different SCSI parallel bus
types.
 
> Only after powering down both, the CD writer and the machine (a HP
> Netserver LD Pro), the BIOS detected the device again. So I guess
> something badly hung...
> 
> The driver being used was
> Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.1.31/3.2.4
> 
> After that, everything worked fine.

Thanks for the report. Hopefully everything worked ok
when you did _not_ use the "dummy" option in cdrecord.

Doug Gilbert
-
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: ext2 filesystem corruptions back from dead? 2.4.0-test11

[Mohammad A. Haque]

I get the following followingon every reboot once.

Nov 23 01:14:37 viper kernel: hdb: drive_cmd: status=0x51 { DriveReady
SeekComplete Error }
Nov 23 01:14:37 viper kernel: hdb: drive_cmd: error=0x04
Nov 23 01:14:37 viper kernel: hdb: drive_cmd: status=0x51 { DriveReady
SeekComplete Error }
Nov 23 01:14:37 viper kernel: hdb: drive_cmd: error=0x04

hdb is my DVD drive. But other than that I haven't seen any other ide
related errors.


I found these two lines nested in between alot of other messages that I
missed before.

Nov 23 00:35:11 viper kernel: EXT2-fs error (device ide0(3,3)):
ext2_free_blocks: bit already cleared for block 147021
Nov 23 00:35:11 viper kernel: EXT2-fs error (device ide0(3,3)):
ext2_free_blocks: bit already cleared for block 147021

Then I get these 

Nov 23 00:40:06 viper kernel: EXT2-fs warning (device ide0(3,3)):
ext2_unlink: Deleting nonexistent file (622295), 0
Nov 23 00:40:06 viper kernel: = 1
Nov 23 00:40:06 viper kernel: EXT2-fs error (device ide0(3,3)):
ext2_free_blocks: Freeing blocks not in datazone - block = 540028982,
count = 1
Nov 23 00:40:06 viper kernel: EXT2-fs error (device ide0(3,3)):
ext2_free_blocks: Freeing blocks not in datazone - block = 540024880,
count = 1

[mhaque@viper mhaque]$ sudo hdparm -iv /dev/hda   

/dev/hda:
 multcount= 16 (on)
 I/O support  =  3 (32-bit w/sync)
 unmaskirq=  0 (off)
 using_dma=  1 (on)
 keepsettings =  1 (on)
 nowerr   =  0 (off)
 readonly =  0 (off)
 readahead= 128 (on)
 geometry = 1650/255/63, sectors = 26520480, start = 0

 Model=IBM-DJNA-371350, FwRev=J76OA30K, SerialNo=GM0GMFE4929
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=34
 BuffType=DualPortCache, BuffSize=1966kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=26520480
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4 
 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4 

[mhaque@viper mhaque]$ sudo hdparm -iv /dev/hdb

/dev/hdb:
 HDIO_GET_MULTCOUNT failed: Invalid argument
 I/O support  =  3 (32-bit w/sync)
 unmaskirq=  0 (off)
 using_dma=  1 (on)
 keepsettings =  1 (on)
 HDIO_GET_NOWERR failed: Invalid argument
 readonly =  1 (on)
 readahead= 128 (on)
 HDIO_GETGEO failed: Invalid argument

 Model=CREATIVEDVD-ROM DVD2240E 12/24/97, FwRev=1.7A, SerialNo=
 Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
 RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
 BuffType=unknown, BuffSize=0kB, MaxMultSect=0
 (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:150}
 PIO modes: pio0 pio1 pio2 pio4 
 DMA modes: sdma0 sdma1 sdma2 sdma? mdma0 mdma1 *mdma2 

Ion Badulescu wrote:
> 
> Ok. Are there any IDE-related errors in your logs prior to getting the f/s
> corruption? They could be relevant no matter how much time passed between
> them and the first signs of corruption.
> 
> Are your drives running with UDMA transfers enabled?
> 
> Thanks,
> Ion
> 
> --
>   It is better to keep your mouth shut and be thought a fool,
> than to open it and remove all doubt.

-- 

=
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: 3c59x: Using bad IRQ 0

[Erik Mouw]

On Tue, Nov 21, 2000 at 05:26:06PM -0800, Linus Torvalds wrote:
> On Tue, 21 Nov 2000, Jeff Garzik wrote:
> > 
> > A caveat to this whole scheme is that usb-uhci -already- calls
> > pci_enable_device before checking dev->irq, and yet cannot get around
> > the "assign IRQ to USB: no" setting in BIOS.  I hope that is an
> > exception rather than the rule.
> 
> Do we have a recent report of this with full PCI debug output? It might
> just be another unlisted intel irq router..

I don't know if this is what you're looking for, but I have indeed
problems getting USB to work on my new notebook. Some info: Asus P8300,
500MHz Celeron, 128MB, Intel 440MX chipset. Here is the output from
"lspci -vvx":


00:00.0 Host bridge: Intel Corporation 82440MX I/O Controller (rev 01)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- 
00: 6f 12 20 07 1f 00 30 02 a2 00 00 03 00 40 00 00
10: 00 00 00 f8 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 32 13
30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 00 00

00:07.0 ISA bridge: Intel Corporation 82440MX PCI to ISA Bridge (rev 01)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- 
00: c1 11 48 04 03 00 90 02 01 00 80 07 00 00 00 00
10: 00 fc df fe 89 fc 00 00 01 f4 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 40 00 00 00 68 16 00 24
30: 00 00 00 00 f8 00 00 00 00 00 00 00 0b 01 fc 0e

00:0a.0 CardBus bridge: Ricoh Co Ltd RL5c475 (rev 80)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- 16bInt+ PostWrite+
16-bit legacy interface ports at 0001
00: 80 11 75 04 07 00 10 02 80 00 07 06 00 a8 02 00
10: 00 00 00 10 dc 00 00 02 00 01 01 b0 00 00 40 10
20: 00 f0 7f 10 00 00 80 10 00 f0 bf 10 00 10 00 00
30: fc 10 00 00 00 14 00 00 fc 14 00 00 ff 01 80 05
40: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


I enabled DEBUG in arch/i386/kernel/pci-i386.h, and got the following
output at boot:


Linux version 2.4.0-test11 (root@arthur) (gcc version 2.95.2 19991024 (release)) #2 
Fri Nov 24 10:28:22 CET 2000
BIOS-provided physical RAM map:
 BIOS-e820: 0009f400 @  (usable)
 BIOS-e820: 0c00 @ 0009f400 (reserved)
 BIOS-e820: 00017000 @ 000e9000 (reserved)
 BIOS-e820: 07ef @ 0010 (usable)
 BIOS-e820: fc00 @ 07ff (ACPI data)
 BIOS-e820: 0400 @ 07fffc00 (ACPI NVS)
 BIOS-e820: 00017000 @ fffe9000 (reserved)
Scan SMP from c000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f for 65536 bytes.
Scan SMP from c009f400 for 4096 bytes.
On node 0 totalpages: 32752
zone(0): 4096 pages.
zone(1): 28656 pages.
zone(2): 0 pages.
mapped APIC to e000 (01222000)
Kernel command line: BOOT_IMAGE=linux-2.4.0t11 ro root=301
Initializing CPU#0
Detected 501.146 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 999.42 BogoMIPS
Memory: 127064k/131008k available (923k kernel code, 3556k reserved, 61k data, 184k 
init, 0k highmem)
Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
CPU: Before vendor init, caps: 0383f9ff  , vendor = 0
CPU: L2 cache: 128K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After vendor init, caps: 0383f9ff   
CPU: After generic, caps: 0383f9ff   
CPU: Common caps: 0383f9ff   
CPU: Intel Celeron (Coppermine) stepping 01
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED])
mtrr: detected mtrr type: Intel
PCI: BIOS32 Service Directory structure at 0xc00f6bf0
PCI: BIOS32 Service Directory entry at 0xfd762
PCI: BIOS probe returned s=00 hw=01 ver=02.10 l=01
PCI: PCI BIOS revision 2.10 entry at 0xfd987, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: IDE base address fixup for 00:07.1
PCI: Scanning for ghost devices on bus 0
PCI: IRQ init
PCI: Interrupt Routing Table found at 0xc00fdf50
00:07 slot=00 0:00/def8 

Booting AMD Elan520 without BIOS

[I+D]

Hi,

I'm trying to boot an AMD Elan520 board without bios
with kernel 2.4.0-test10 configured for i486 and PCI direct access.
This kernel boots correctly from HD using the bios provided with the 
evaluation board but kernel 2.4.0-test8 and previous hang
after "Ok booting the kernel".
  Currently I have the SDRam configured, the PCI peripherals
initialized (with AMD code), the GDT loaded in RAM and the CPU
in 32 bit mode. The empty_zero_page is configured with the RAM
and a command line (using code from LinuxBios and kernel startup).
I decompress directly from rom to 0x10 the
kernel image and then I jump there.
The last message I see is "Calibrating delay loop"
(I see this thaks to the Jtag debugger for Elan520 because
I haven't configured the VGA board yet).

May somebody enumerate the requirements to boot the kernel
I mean the peripherals,system configuration etc.

Thankyou.

-
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: lseek patch for 2.2.18pre23

[kernel]

On Fri, 24 Nov 2000, Andrea Arcangeli wrote:

> And in LFS (that means also 2.4.x) the >> 32 doesn't make any sense in lseek
> and should be removed:

Actually, the >> 32 part was there to avoid doing the long long comparison
on x86.  Granted, that probably doesn't matter.

-ben

-
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: Recent ide patches and DMA

[Vojtech Pavlik]

On Thu, Nov 23, 2000 at 01:09:35PM -0800, Kafu Nagai wrote:
> With recent ide patches, the ide driver seems to try to use DMA mode even for a 
>drive which dosen't support it. CONFIG_IDEDMA_PCI_AUTO is enabled but even so with 
>the stock kernel this dosen't happen. older patches didn't have this behavior either. 
>Is this change intentional ?
> 
> hdc: 333630 sectors (171 MB) w/32KiB Cache, CHS=1011/15/22, DMA
> Partition check:
>  hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 >
>  hdc:hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hdc: dma_intr: error=0x04 { DriveStatusError }
> hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hdc: dma_intr: error=0x04 { DriveStatusError }
> hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hdc: dma_intr: error=0x04 { DriveStatusError }
> hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hdc: dma_intr: error=0x04 { DriveStatusError }
> hdc: DMA disabled
> ide1: reset: success
>  hdc1
> 
> ~ $ hdparm -i /dev/hdc
>  
> /dev/hdc:
>  
>  Model=QUANTUM ELS170A, FwRev=4.20, SerialNo=166304085456
>  Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>5Mbs RotSpdTol>.5% }
>  RawCHS=1011/15/22, TrkSize=11264, SectSize=512, ECCbytes=4
>  BuffType=3(DualPortCache), BuffSize=32kB, MaxMultSect=8, MultSect=off
>  DblWordIO=no, OldPIO=2, DMA=no
>  CurCHS=1011/15/22, CurSects=333629, LBA=no 

Which chipset are you using?

-- 
Vojtech Pavlik
SuSE Labs
-
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: lseek patch for 2.2.18pre23

[Andrea Arcangeli]

On Thu, Nov 23, 2000 at 10:15:24PM -0800, H . J . Lu wrote:
> 2.2.18pre23 allows lseek to negative offsets in ext2 and has no checks
> for proc. Here is a patch.

As just said your patch is wrong for vanilla 2.2.18pre23.

The right fix for that problem in 2.2.18pre23 (2.2.x vanilla doesn't include
LFS) is here:


ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.18pre22/lseek-2g-ext2-1

I also uploaded separately your right fix for /dev/mem:


ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.18pre22/lseek-2g-mem-hjl-1
 (this one is 

and this the right fix for the largefile handling in ext2:


ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.18pre22/notify-change-2g-ext2-1

All three should be applied to 2.2.18pre-latest.

And in LFS (that means also 2.4.x) the >> 32 doesn't make any sense in lseek
and should be removed:


ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.0-test11-pre6/ext2-lseek-cleanup-1

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: About IP address

[John Crowhurst]

> For example, Class B address range is 128.1.0.0 ~ 191.254.0.0
> 
> Why 128.0.0.0 and 191.255.0.0 can't use ?
> 
> I can't understand it

This is because its the network and broadcast addresses of a Class A address
range. Simple answer :)

-- 
FyreMoon
Under the moon, the dragon flies.

-
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/drivers/media/radio check_region() removal

[Alan Cox]

> attached patch removes all check_region() calls from /linux/drivers/media/r=
> adio
> drivers. Most changes  are obvious, except radio-cadet.c which needs some=
> =20
> maintainer's attention.=20

Please check the -ac tree. I've already done them
-
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: OOPS on bringing down ppp

[Alan Cox]

> Not my area, but I don't think exec_usermodehelper() should assume
> that current->files is always valid.
> 
> Al, is this correct?  If so, does daemonize() also need this test?
> If not, then how did this thread get (current->files == NULL)?

exit_files() will leave it NULL yes. You may want to borrow (inherit ;)) the
files from init_task

-
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: Cardbus bridge problems

[Tobias Ringstrom]

On Thu, 23 Nov 2000, Linus Torvalds wrote:
> That bus setup is horribly wrong, and says that the CardBus bridge no bus
> numbers, which is obviously not correct. It somehow got through the bridge
> scanning without being fixed up..
> 
> Now, the reason for why it seems to be so unhappy is apparently
> 
>   Scanning behind PCI bridge 00:08.0, config 40, pass 1
>   Scanning behind PCI bridge 00:08.1, config 40, pass 1
> 
> Note the "config 40". It basically seems to imply that the cardbus
> bridge has been set up as bus 0x40, ie 64. With no secondary bus behind
> it. Which looks completely and utterly bogus.
> 
> I bet the thing works for you if you change the magic constant 0xff in
> pci_scan_bridge() to the new magic constant 0x00. Basically, we don't
> much care what it reports for the primary bus number: but we _do_ care
> that a PCI bridge should have a secondary bus number.

Two down.  I no longer need the Windows by-pass surgery.  Thanks!

[I have attached the new dmesg and lspci output for your amusement.]

Oh, I almost forgot.  When the bus numbers were wrong, and I inserted a
Cardbus card, I could no longer user lspci, since it tried to open a
non-existing file unser /proc/bus/pci/. It did not help to eject the card,
so I guess the kernel left something in a half-initialized state.  Would
you like me to try to find out more details, or is it a non-issue, or
maybe obvious?

/Tobias



00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03)
Subsystem: Mitac: Unknown device 7233
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- 

00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03) 
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR+ FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- FastB2B+

00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset- 16bInt- PostWrite+
16-bit legacy interface ports at 0001

00:08.1 CardBus bridge: Texas Instruments PCI1225 (rev 01)
Subsystem: Mitac: Unknown device 7233
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset+ 16bInt+ PostWrite+
16-bit legacy interface ports at 0001

00:09.0 Multimedia audio controller: ESS Technology ES1978 Maestro 2E (rev 10)
Subsystem: Mitac: Unknown device 7233
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- 
Capabilities: [5c] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RT8139 (B/C) Cardbus Fast 
Ethernet Adapter (rev 10)
Subsystem: Argosy research Inc: Unknown device 0235
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- 

Linux version 2.4.0-test11 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 
19990314/Linux (egcs-1.1.2 release)) #26 Fri Nov 24 13:25:49 CET 2000
BIOS-provided physical RAM map:
 BIOS-e820: 0009fc00 @  (usable)
 BIOS-e820: 0400 @ 0009fc00 (reserved)
 BIOS-e820: 0001 @ 000f (reserved)
 BIOS-e820: 09ef @ 0010 (usable)
 BIOS-e820: ffc0 @ 09ff (ACPI data)
 BIOS-e820: 0040 @ 09c0 (ACPI NVS)
 BIOS-e820: 0004 @ fffc (reserved)
On node 0 totalpages: 40944
zone(0): 4096 pages.
zone(1): 36848 pages.
zone(2): 0 pages.
Kernel command line: auto BOOT_IMAGE=Linux ro root=303 BOOT_FILE=/boot/vmlinuz
Initializing CPU#0
Detected 497.846 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 992.87 BogoMIPS
Memory: 158400k/163776k available (1754k kernel code, 4988k reserved, 106k data, 180k 
init, 0k highmem)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
CPU: Before vendor 

Re: [bug] set_pgdir can skip mm's

[V Ganesh]

> From ganesh Fri Nov 24 18:08:15 2000

[ set_pgdir() blah blah blah ]

damn. I was looking at test9 and as usual after shooting my mouth off on l-k
I go look at test11 and find it's fixed there, at least in i386, thanks to
the vmalloc_fault: stuff in do_page_fault. but a lot of other architectures
still use the old method.

ganesh
-
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-test11: es1371 mixer problems

[Dick Streefland]

2.4.0-test11 introduced a problem with the mixer device of my SB128
soundcard (es1371 driver). When I start a mixer application like
xmixer or aumix, only a small subset of the mixer devices are available.
With 2.4.0-test10, using the same .config, all devices are available.

I've looked through the test11 patch and noticed that it contains
a lot of changes like:

  _IOC_DIR  --> _SIOC_DIR
  _IOC_READ --> _SIOC_READ
  _IOC_WRITE--> _SIOC_WRITE
  _IOC_SIZE --> _SIOC_SIZE

These changes are not yet applied to ac97.c and ac97_codec.c, but that
does not seem to be the problem, because after making these changes
(see patch below), the problem persists.

-- 
Dick Streefland  TASKING Software BV
[EMAIL PROTECTED] (@ @) http://www.tasking.com
oOO--(_)--OOo---

--- linux-2.4.0-test11/drivers/sound/ac97.c.origFri Jan  7 00:01:56 2000
+++ linux-2.4.0-test11/drivers/sound/ac97.c Thu Nov 23 00:02:31 2000
@@ -407,19 +407,19 @@
/* Read or write request. */
ret = -EINVAL;
if (_IOC_TYPE (cmd) == 'M') {
-   int dir = _IOC_DIR (cmd);
+   int dir = _SIOC_DIR (cmd);
int channel = _IOC_NR (cmd);
 
if (channel >= 0 && channel < SOUND_MIXER_NRDEVICES) {
ret = 0;
-   if (dir & _IOC_WRITE) {
+   if (dir & _SIOC_WRITE) {
int val;
if (get_user (val, (int *) arg) == 0)
ret = ac97_set_mixer (dev, channel, val);
else
ret = -EFAULT;
}
-   if (ret >= 0 && (dir & _IOC_READ)) {
+   if (ret >= 0 && (dir & _SIOC_READ)) {
if (dev->last_written_OSS_values[channel]
== AC97_REGVAL_UNKNOWN)
dev->last_written_OSS_values[channel]
--- linux-2.4.0-test11/drivers/sound/ac97_codec.c.orig  Tue Nov 21 21:41:02 2000
+++ linux-2.4.0-test11/drivers/sound/ac97_codec.c   Thu Nov 23 00:02:45 2000
@@ -405,13 +405,13 @@
return 0;
}
 
-   if (_IOC_TYPE(cmd) != 'M' || _IOC_SIZE(cmd) != sizeof(int))
+   if (_IOC_TYPE(cmd) != 'M' || _SIOC_SIZE(cmd) != sizeof(int))
return -EINVAL;
 
if (cmd == OSS_GETVERSION)
return put_user(SOUND_VERSION, (int *)arg);
 
-   if (_IOC_DIR(cmd) == _IOC_READ) {
+   if (_SIOC_DIR(cmd) == _SIOC_READ) {
switch (_IOC_NR(cmd)) {
case SOUND_MIXER_RECSRC: /* give them the current record source */
if (!codec->recmask_io) {
@@ -451,7 +451,7 @@
return put_user(val, (int *)arg);
}
 
-   if (_IOC_DIR(cmd) == (_IOC_WRITE|_IOC_READ)) {
+   if (_SIOC_DIR(cmd) == (_SIOC_WRITE|_SIOC_READ)) {
codec->modcnt++;
if (get_user(val, (int *)arg))
return -EFAULT;
-
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/

Bug in date converting functions DOS<=>UNIX in FAT, NCPFS and SMBFS drivers

[Igor Yu. Zhbanov]

Hello!

I have found a bug in drivers of file systems which use a DOS-like format
of date (16 bit: years since 1980 - 7 bits, month - 4 bits, day - 5 bits).

There are two problems:
1) It is unable to convert UNIX-like dates before 1980 to DOS-like date format.
2) VFAT for example have three kinds of dates: creation date, modification date
   and access date. Sometimes one of these dates is set to zero (which indicates
   that this date is not set). Zero is not a valid date (e.g. months are
   numbered from one, not from zero) and can't be properly converted to
   UNIX-like format of date (it was converted to date before 1980).

I have found FAT, NCPFS and SMBFS drivers subject to this problems. Patch for
fixing these bugs attached.

Also I have a question about VFAT file system. VFAT have not access time fields
in directory entries but it has access date fields. Currently information about
the time of last access is not supported for VFAT file system in LINUX. Is this
correct? Maybe access time should be truncated to days.

Thank you.

P.S. Since I'm not currently subscribed to Linux Kernel Mailing List please CC:
all replies to [EMAIL PROTECTED] if any.


diff -ur linux-2.2.17/fs/fat/misc.c linux/fs/fat/misc.c
--- linux-2.2.17/fs/fat/misc.c  Thu May  4 04:16:46 2000
+++ linux/fs/fat/misc.c Wed Nov 22 14:05:08 2000
@@ -2,6 +2,8 @@
  *  linux/fs/fat/misc.c
  *
  *  Written 1992,1993 by Werner Almesberger
+ *  22/11/2000 - Fixed fat_date_unix2dos for dates earlier than 01/01/1980
+ *  and date_dos2unix for date==0 by Igor Zhbanov([EMAIL PROTECTED])
  */
 
 #include 
@@ -288,7 +290,9 @@
 {
int month,year,secs;
 
-   month = ((date >> 5) & 15)-1;
+   /* first subtract and mask after that... Otherwise, if
+  date == 0, bad things happen */
+   month = ((date >> 5) - 1) & 15;
year = date >> 9;
secs = (time & 31)*2+60*((time >> 5) & 63)+(time >> 11)*3600+86400*
((date & 31)-1+day_n[month]+(year/4)+year*365-((year & 3) == 0 &&
@@ -310,6 +314,8 @@
unix_date -= sys_tz.tz_minuteswest*60;
if (sys_tz.tz_dsttime) unix_date += 3600;
 
+   if (unix_date < 315532800)
+   unix_date = 315532800; /* Jan 1 GMT 00:00:00 1980. But what about 
+another time zone? */
*time = (unix_date % 60)/2+(((unix_date/60) % 60) << 5)+
(((unix_date/3600) % 24) << 11);
day = unix_date/86400-3652;
diff -ur linux-2.2.17/fs/ncpfs/dir.c linux/fs/ncpfs/dir.c
--- linux-2.2.17/fs/ncpfs/dir.c Thu Jun  8 01:26:43 2000
+++ linux/fs/ncpfs/dir.cWed Nov 22 14:06:09 2000
@@ -5,6 +5,8 @@
  *  Modified for big endian by J.F. Chadima and David S. Miller
  *  Modified 1997 Peter Waltenberg, Bill Hawes, David Woodhouse for 2.1 dcache
  *  Modified 1998 Wolfram Pienkoss for NLS
+ *  22/11/2000 - Fixed ncp_date_unix2dos for dates earlier than 01/01/1980
+ *  by Igor Zhbanov([EMAIL PROTECTED])
  *
  */
 
@@ -1158,6 +1160,8 @@
int day, year, nl_day, month;
 
unix_date = utc2local(unix_date);
+   if (unix_date < 315532800)
+   unix_date = 315532800; /* Jan 1 GMT 00:00:00 1980. But what about 
+another time zone? */
*time = (unix_date % 60) / 2 + (((unix_date / 60) % 60) << 5) +
(((unix_date / 3600) % 24) << 11);
day = unix_date / 86400 - 3652;
diff -ur linux-2.2.17/fs/smbfs/ChangeLog linux/fs/smbfs/ChangeLog
--- linux-2.2.17/fs/smbfs/ChangeLog Mon Sep  4 21:39:27 2000
+++ linux/fs/smbfs/ChangeLogWed Nov 22 14:10:40 2000
@@ -1,5 +1,10 @@
 ChangeLog for smbfs.
 
+2000-11-22 Igor Zhbanov <[EMAIL PROTECTED]>
+
+   * proc.c: fixed date_unix2dos for dates earlier than 01/01/1980
+ and date_dos2unix for date==0
+
 2000-07-20 Urban Widmark <[EMAIL PROTECTED]>
 
* proc.c: fix 2 places where bad server responses could cause an Oops.
diff -ur linux-2.2.17/fs/smbfs/proc.c linux/fs/smbfs/proc.c
--- linux-2.2.17/fs/smbfs/proc.cMon Sep  4 21:39:27 2000
+++ linux/fs/smbfs/proc.c   Wed Nov 22 14:13:32 2000
@@ -169,7 +169,9 @@
int month, year;
time_t secs;
 
-   month = ((date >> 5) & 15) - 1;
+   /* first subtract and mask after that... Otherwise, if
+  date == 0, bad things happen */
+   month = ((date >> 5) - 1) & 15;
year = date >> 9;
secs = (time & 31) * 2 + 60 * ((time >> 5) & 63) + (time >> 11) * 3600 + 86400 
*
((date & 31) - 1 + day_n[month] + (year / 4) + year * 365 - ((year & 3) == 
0 &&
@@ -188,6 +190,8 @@
int day, year, nl_day, month;
 
unix_date = utc2local(server, unix_date);
+   if (unix_date < 315532800)
+   unix_date = 315532800; /* Jan 1 GMT 00:00:00 1980. But what about 
+another time zone? */
*time = (unix_date % 60) / 2 +
(((unix_date / 60) % 60) << 5) +
(((unix_date / 3600) % 24) << 11);

Re: gcc-2.95.2-51 is buggy

[Mikael Pettersson]

On Fri, 24 Nov 2000, Jakub Jelinek wrote:

>so the reason why it did not show up in the gcc you picked up from
>ftp.gnu.org is that you have compiled it so that it defaults to -mcpu=i686
>where the bug does not show up.

Indeed. I just ran some tests, and I can confirm that gcc 2.95.2 vanilla
exhibits the bug when compiled and run for i486 or i585, but not i686.

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

[PATCH] ACPI interpreter on ACPItableless systems

[Andrey Panin]

Hi all,

this patch makes ACPI poweroff possible on ACPI capable systems without 
BIOS provided ACPI tables.
I sent this patch to LKML some month ago, but didn't get an answer :(

I will be out of this list for some weeks, so happy hacking and good bye,
Andrey

-- 
Andrey Panin| Embedded systems software engineer
[EMAIL PROTECTED]| PGP key: http://www.orbita1.ru/~pazke/AndreyPanin.asc
 PGP signature

Re: e2fs performance as function of block size

[Stephen C. Tweedie]

Hi,

On Wed, Nov 22, 2000 at 11:28:12PM +0100, Michael Marxmeier wrote:
> 
> If the files get somewhat bigger (eg. > 1G) having a bigger block
> size also greatly reduces the ext2 overhead. Especially fsync() 
> used to be really bad on big file but choosing a bigger block
> size changed a lot.

2.4 fsync should be better, but still dependent on file size.  The
O_SYNC patches I posted the other day give you an fsync which is
independent of file size.

Cheers,
 Stephen
-
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-2.4.0-test11] various small fixes

[Tigran Aivazian]

Hi Linus,

This patch does:

a) cleans up the show_mem() function on various architectures wrt
page_count() macro and the 'free' variable

b) corrects the comment above paging_init() about 0-8M page tables

c) changes the name of kflushd to bdflush. All kernel data structures
around this thread are called bdflush* so kflushd is a wrong name and
bdflush is right.

d) corrects the comments in fs/file.c about __get_free_page() usage; it
should say "vmalloc or kmalloc" for these two are used for array and fd
set allocation

e) corrects the comment in asm-i386/spinlock.h about semaphore.S

f) adds a free_mm() macro to kernel/fork.c to be symmetric to allocate_mm

g) optimizes the vmlist_lock usage by dropping it in vfree() before
freeing the 'tmp' element which was unlinked from vmlist but _after_ the
pages have been freed.

(another thing I wanted to do, but was in doubt, was to force the old lock
nfsservctl request to do do_exit(0) like we do in sys_bdlflush() for old
2.2.x userspace update to self-terminate. This way current rpc.lockd would
not spew out an error but quietly (and successfully, i.e. errcode=0) die,
just like update)

diff -urN -X dontdiff linux/arch/alpha/mm/init.c work/arch/alpha/mm/init.c
--- linux/arch/alpha/mm/init.c  Mon Oct 16 23:38:41 2000
+++ work/arch/alpha/mm/init.c   Fri Nov 24 12:40:52 2000
@@ -185,7 +185,7 @@
reserved++;
else if (PageSwapCache(mem_map+i))
cached++;
-   else if (!atomic_read(_map[i].count))
+   else if (!page_count(mem_map+i))
free++;
else
shared += atomic_read(_map[i].count) - 1;
diff -urN -X dontdiff linux/arch/i386/mm/init.c work/arch/i386/mm/init.c
--- linux/arch/i386/mm/init.c   Mon Oct 23 22:42:33 2000
+++ work/arch/i386/mm/init.cFri Nov 24 12:37:56 2000
@@ -198,7 +198,7 @@
 
 void show_mem(void)
 {
-   int i,free = 0, total = 0, reserved = 0;
+   int i, total = 0, reserved = 0;
int shared = 0, cached = 0;
int highmem = 0;
 
@@ -214,9 +214,7 @@
reserved++;
else if (PageSwapCache(mem_map+i))
cached++;
-   else if (!page_count(mem_map+i))
-   free++;
-   else
+   else if (page_count(mem_map+i))
shared += page_count(mem_map+i) - 1;
}
printk("%d pages of RAM\n", total);
@@ -437,7 +435,7 @@
 }
 
 /*
- * paging_init() sets up the page tables - note that the first 4MB are
+ * paging_init() sets up the page tables - note that the first 8MB are
  * already mapped by head.S.
  *
  * This routines also unmaps the page at virtual kernel address 0, so
diff -urN -X dontdiff linux/arch/ia64/mm/init.c work/arch/ia64/mm/init.c
--- linux/arch/ia64/mm/init.c   Tue Oct 10 01:54:56 2000
+++ work/arch/ia64/mm/init.cFri Nov 24 12:38:20 2000
@@ -245,7 +245,7 @@
 void
 show_mem (void)
 {
-   int i,free = 0,total = 0,reserved = 0;
+   int i, total = 0, reserved = 0;
int shared = 0, cached = 0;
 
printk("Mem-info:\n");
@@ -258,9 +258,7 @@
reserved++;
else if (PageSwapCache(mem_map+i))
cached++;
-   else if (!page_count(mem_map + i))
-   free++;
-   else
+   else if (page_count(mem_map + i))
shared += page_count(mem_map + i) - 1;
}
printk("%d pages of RAM\n", total);
diff -urN -X dontdiff linux/arch/ppc/mm/init.c work/arch/ppc/mm/init.c
--- linux/arch/ppc/mm/init.cThu Nov  9 03:01:34 2000
+++ work/arch/ppc/mm/init.c Fri Nov 24 12:41:53 2000
@@ -293,7 +293,7 @@
reserved++;
else if (PageSwapCache(mem_map+i))
cached++;
-   else if (!atomic_read(_map[i].count))
+   else if (!page_count(mem_map+i))
free++;
else
shared += atomic_read(_map[i].count) - 1;
diff -urN -X dontdiff linux/arch/s390/mm/init.c work/arch/s390/mm/init.c
--- linux/arch/s390/mm/init.c   Mon Oct 16 20:58:51 2000
+++ work/arch/s390/mm/init.cFri Nov 24 12:42:08 2000
@@ -192,7 +192,7 @@
 
 void show_mem(void)
 {
-int i,free = 0,total = 0,reserved = 0;
+int i, total = 0, reserved = 0;
 int shared = 0, cached = 0;
 
 printk("Mem-info:\n");
@@ -205,9 +205,7 @@
 reserved++;
 else if (PageSwapCache(mem_map+i))
 cached++;
-else if (!atomic_read(_map[i].count))
-free++;
-else
+else if (page_count(mem_map+i))
 shared += atomic_read(_map[i].count) - 1;
 }
 printk("%d pages of RAM\n",total);
diff -urN -X dontdiff linux/arch/sh/mm/init.c 

Re: OOPS on bringing down ppp

[Keith Owens]

On Fri, 24 Nov 2000 10:55:39 +, 
Mark Ellis <[EMAIL PROTECTED]> wrote:
>Hi all, consistently getting the following when pppd is terminated. Happens
>in 2.4.0-test11, fine in 2.4.0-test9, don't know about test10. Same happens
>for pppd 2.4.0b4 and 2.4.0, both recompiled for test11. Is this related to
>the modutils incompatability (modutils 2.3.19) ? 

I don't think so.  I cannot reproduce this oops on 2.4.0-test11 with
modutils 2.3.21, ppp 2.4.0.  modutils 2.3.19 should be compatible with
kernel 2.4.0-test11, the incompatibility is between modutils <= 2.3.15
and kernel 2.4.0-test11.

It was difficult to find the right area of code, my compile with
egcs-2.91.66 and -march=i686 gives quite different Assembler, so take
this analysis with a pinch of salt.  Is there any chance that you are
using the wrong compiler and/or compiler options?

The oops looks to be on line 102 of kmod.c

for (i = 0; i < current->files->max_fds; i++ ) {

current->files is NULL.  That has nothing to do with modutils, rather
it points to an invalid or incomplete current context.

-
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] linux/drivers/media/radio check_region() removal

[Andrey Panin]

Hi all,

attached patch removes all check_region() calls from /linux/drivers/media/radio
drivers. Most changes  are obvious, except radio-cadet.c which needs some 
maintainer's attention. 

I hope it will be usefull.

Best regards,
Andrey

-- 
Andrey Panin| Embedded systems software engineer
[EMAIL PROTECTED]| PGP key: http://www.orbita1.ru/~pazke/AndreyPanin.asc

diff -ur -x *.flags -x media.o /mnt/disk/linux/drivers/media/radio/radio-aimslab.c 
/linux/drivers/media/radio/radio-aimslab.c
--- /mnt/disk/linux/drivers/media/radio/radio-aimslab.c Mon Nov 20 21:01:53 2000
+++ /linux/drivers/media/radio/radio-aimslab.c  Fri Nov 24 13:04:09 2000
@@ -29,7 +29,7 @@
 
 #include   /* Modules  */
 #include /* Initdata */
-#include   /* check_region, request_region */
+#include   /* request_region   */
 #include/* udelay   */
 #include /* outb, outb_p */
 #include/* copy to/from user*/
@@ -42,7 +42,7 @@
 #endif
 
 static int io = CONFIG_RADIO_RTRACK_PORT; 
-static int users = 0;
+static int users;
 static struct semaphore lock;
 
 struct rt_device
@@ -338,7 +338,7 @@
return -EINVAL;
}
 
-   if (check_region(io, 2)) 
+   if (!request_region(io, 2, "rtrack"))
{
printk(KERN_ERR "rtrack: port 0x%x already in use\n", io);
return -EBUSY;
@@ -346,10 +346,11 @@
 
rtrack_radio.priv=_unit;

-   if(video_register_device(_radio, VFL_TYPE_RADIO)==-1)
+   if (video_register_device(_radio, VFL_TYPE_RADIO) == -1) {
+   release_region(io, 2);
return -EINVAL;
+   }

-   request_region(io, 2, "rtrack");
printk(KERN_INFO "AIMSlab RadioTrack/RadioReveal card driver.\n");
 
/* Set up the I/O locking */
diff -ur -x *.flags -x media.o /mnt/disk/linux/drivers/media/radio/radio-aztech.c 
/linux/drivers/media/radio/radio-aztech.c
--- /mnt/disk/linux/drivers/media/radio/radio-aztech.c  Mon Nov 20 21:01:53 2000
+++ /linux/drivers/media/radio/radio-aztech.c   Fri Nov 24 13:04:09 2000
@@ -26,7 +26,7 @@
 
 #include   /* Modules  */
 #include /* Initdata */
-#include   /* check_region, request_region */
+#include   /* request_region   */
 #include/* udelay   */
 #include /* outb, outb_p */
 #include/* copy to/from user*/
@@ -41,7 +41,7 @@
 
 static int io = CONFIG_RADIO_AZTECH_PORT; 
 static int radio_wait_time = 1000;
-static int users = 0;
+static int users;
 static struct semaphore lock;
 
 struct az_device
@@ -289,7 +289,7 @@
return -EINVAL;
}
 
-   if (check_region(io, 2)) 
+   if (!request_region(io, 2, "aztech")) 
{
printk(KERN_ERR "aztech: port 0x%x already in use\n", io);
return -EBUSY;
@@ -298,10 +298,11 @@
init_MUTEX();
aztech_radio.priv=_unit;

-   if(video_register_device(_radio, VFL_TYPE_RADIO)==-1)
+   if (video_register_device(_radio, VFL_TYPE_RADIO) == -1) {
+   release_region(io, 2);
return -EINVAL;
+   }

-   request_region(io, 2, "aztech");
printk(KERN_INFO "Aztech radio card driver v1.00/19990224 
[EMAIL PROTECTED]\n");
/* mute card - prevents noisy bootups */
outb (0, io);
diff -ur -x *.flags -x media.o /mnt/disk/linux/drivers/media/radio/radio-cadet.c 
/linux/drivers/media/radio/radio-cadet.c
--- /mnt/disk/linux/drivers/media/radio/radio-cadet.c   Mon Nov 20 21:01:54 2000
+++ /linux/drivers/media/radio/radio-cadet.cFri Nov 24 13:17:22 2000
@@ -20,7 +20,7 @@
 
 #include   /* Modules  */
 #include /* Initdata */
-#include   /* check_region, request_region */
+#include   /* request_region   */
 #include/* udelay   */
 #include /* outb, outb_p */
 #include/* copy to/from user*/
@@ -34,15 +34,15 @@
 #define RDS_BUFFER 256
 
 static int io=CONFIG_RADIO_CADET_PORT; 
-static int users=0;
-static int curtuner=0;
-static int tunestat=0;
-static int sigstrength=0;
+static int users;
+static int curtuner;
+static int tunestat;
+static int sigstrength;
 static wait_queue_head_t tunerq,rdsq,readq;
 struct timer_list tunertimer,rdstimer,readtimer;
-static __u8 rdsin=0,rdsout=0,rdsstat=0;
+static __u8 rdsin,rdsout,rdsstat;
 static unsigned char rdsbuf[RDS_BUFFER];
-static int cadet_lock=0;
+static int cadet_lock;
 
 #ifndef MODULE
 static int cadet_probe(void);
@@ -551,9 +551,28 @@
ioctl:  cadet_ioctl,
 };
 
+#ifdef MODULE
+static int __init cadet_probe(int ioaddr)
+{
+   if 

Re: gcc-2.95.2-51 is buggy

[Andries . Brouwer]

> so the reason why it did not show up in the gcc you picked up from
> ftp.gnu.org is that you have compiled it so that it defaults to -mcpu=i686

Yes, you are right.

So 2.95.2 fails for i386, i486, i586 and does not fail for i686.

Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

About IP address

[Su Hwan Hwang]

For example, Class B address range is 128.1.0.0 ~ 191.254.0.0

Why 128.0.0.0 and 191.255.0.0 can't use ?

I can't understand it

Please answer
_
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] Generalize disk_name in fs/partitions/check.c

[Brian Kress]

This is a patch that generalizes the code in 
fs/partitions/check.c for the disk_name() function.  With
the way the code is right now, it has a big if/then/else
block that requires generic code to know specific things 
about drivers.  This patch makes it so the driver can 
supply the code to name its devices.  It does this with
three sets of changes:

1)  Add a function pointer to struct gendisk called hd_name.

2)  Make disk_name in fs/partitions/check.c use that function
pointer if its non-null.

3)  Change the following drivers to use this method. (adding the
driver specific method and removing the old code in check.c)

drivers/md/lvm.c
drivers/md/md.c
drivers/ide/ide-probe.c
drivers/scsi/sd.c
drivers/block/cpqarray.c
drivers/block/cciss.c
drivers/block/DAC960.c


This method means new drivers can name their disks the
way they want to.  It also means LVM disks are named correctly
now (they weren't before).  It also gets rid of lots of 
#ifdefs.  Could you consider applying this patch?


Brian Kress
[EMAIL PROTECTED]


- Patch
-

diff -u --recursive linux-2.4.0-test11/drivers/block/DAC960.c
linux-2.4.0-test11-ppfix/drivers/block/DAC960.c
--- linux-2.4.0-test11/drivers/block/DAC960.c   Mon Nov 20 15:17:25 2000
+++ linux-2.4.0-test11-ppfix/drivers/block/DAC960.c Thu Nov 23 14:29:37
2000
@@ -1885,6 +1885,21 @@
 }
 
 
+char *DAC960_disk_name(struct gendisk *hd, int minor, char *buf)
+
+{
+   int ctlr = hd->major - DAC960_MAJOR;
+   int disk = minor >> hd->minor_shift;
+   int part = minor & ((1 << hd->minor_shift) - 1);
+
+   if (part)
+   sprintf(buf, "%s/c%dd%dp%d", hd->major_name, ctlr, disk, part);
+   else
+   sprintf(buf, "%s/c%dd%d", hd->major_name, ctlr, disk);
+   return buf;
+}
+
+
 /*
   DAC960_RegisterBlockDevice registers the Block Device structures
   associated with Controller.
@@ -1945,6 +1960,7 @@
   Controller->GenericDiskInfo.nr_real = Controller->LogicalDriveCount;
   Controller->GenericDiskInfo.next = NULL;
   Controller->GenericDiskInfo.fops = _BlockDeviceOperations;
+  Controller->GenericDiskInfo.hd_name = DAC960_disk_name;
   /*
 Install the Generic Disk Information structure at the end of the
list.
   */
diff -u --recursive linux-2.4.0-test11/drivers/block/cciss.c
linux-2.4.0-test11-ppfix/drivers/block/cciss.c
--- linux-2.4.0-test11/drivers/block/cciss.cMon Nov 20 15:17:25 2000
+++ linux-2.4.0-test11-ppfix/drivers/block/cciss.c  Thu Nov 23 14:22:55
2000
@@ -1749,6 +1749,20 @@
kfree(size_buff);
 }  
 
+char *cciss_disk_name(struct gendisk *hd, int minor, char *buf)
+
+{
+   int ctlr = hd->major - COMPAQ_CISS_MAJOR;
+   int disk = minor >> hd->minor_shift;
+   int part = minor & ((1 << hd->minor_shift) - 1);
+
+   if (part)
+   sprintf(buf, "%s/c%dd%dp%d", hd->major_name, ctlr, disk, part);
+   else
+   sprintf(buf, "%s/c%dd%d", hd->major_name, ctlr, disk);
+   return buf;
+}
+
 /*
  *  This is it.  Find all the controllers and register them.  I really
hate
  *  stealing all these major device numbers.
@@ -1851,6 +1865,7 @@
hba[i]->gendisk.part = hba[i]->hd;
hba[i]->gendisk.sizes = hba[i]->sizes;
hba[i]->gendisk.nr_real = hba[i]->num_luns;
+   hba[i]->gendisk.hd_name = cciss_disk_name;
 
/* Get on the disk list */ 
hba[i]->gendisk.next = gendisk_head;
diff -u --recursive linux-2.4.0-test11/drivers/block/cpqarray.c
linux-2.4.0-test11-ppfix/drivers/block/cpqarray.c
--- linux-2.4.0-test11/drivers/block/cpqarray.c Mon Nov 20 15:20:29 2000
+++ linux-2.4.0-test11-ppfix/drivers/block/cpqarray.c   Thu Nov 23
14:14:03 2000
@@ -362,6 +362,20 @@
 }
 #endif /* MODULE */
 
+char *ida_disk_name(struct gendisk *hd, int minor, char *buf)
+
+{
+   int ctlr = hd->major - COMPAQ_SMART2_MAJOR;
+   int disk = minor >> hd->minor_shift;
+   int part = minor & ((1 << hd->minor_shift) - 1);
+
+   if (part)
+   sprintf(buf, "%s/c%dd%dp%d", hd->major_name, ctlr, disk, part);
+   else
+   sprintf(buf, "%s/c%dd%d", hd->major_name, ctlr, disk);
+   return buf;   
+}
+
 /*
  *  This is it.  Find all the controllers and register them.  I really
hate
  *  stealing all these major device numbers.
@@ -512,6 +526,7 @@
ida_gendisk[i].part = ida + (i*256);
ida_gendisk[i].sizes = ida_sizes + (i*256);
ida_gendisk[i].nr_real = 0; 
+   ida_gendisk[i].hd_name = ida_disk_name;

/* Get on the disk list */
ida_gendisk[i].next = gendisk_head;
diff -u --recursive linux-2.4.0-test11/drivers/ide/ide-probe.c
linux-2.4.0-test11-ppfix/drivers/ide/ide-probe.c
--- linux-2.4.0-test11/drivers/ide/ide-probe.c  Thu Aug  3 19:29:49 2000
+++ 

Kernel Oops on locking sockets via fcntl()

[Igor Yu. Zhbanov]

Hello!

One fine day accidentally I have opened an Xserver's socket placed in /tmp
with my favourite text editor "le". I have got a message from the kernel similar
to this:

Unable to handle kernel NULL pointer dereference at virtual address 0038
current->tss.cr3 = 0336f000, %cr3 = 0336f000
*pde = 0336d067
*pte = 
Oops: 
CPU:0
EIP:0010:[]
EFLAGS: 00010202
... and so on.

I couldn't leave it aside. And I started to debug the Kernel by inserting printk
(it's my favourite method of kernel debugging :). Finally I found out the place
where the "Oops" has occurred. It is in function fcntl_setlk() which is placed
in the file linux/fs/locks.c. Here is a piece of code from this function:
---
struct file *filp;
...
if (filp->f_op->lock != NULL) {  /* Oooops!!! */
error = filp->f_op->lock(filp, cmd, _lock);
if (error < 0)
goto out_putf;
}
error = posix_lock_file(filp, _lock, cmd == F_SETLKW);
---
As you may see the first "if" statement checks if "filp->f_op->lock" is equal
to "NULL". But in the case of sockets "filp->f_op" is equal to "NULL"!
The "filp->f_op" is the pointer to "file_operations" structure which contains
pointers to functions operating with this type of file.

This problem can be fixed in several ways:
1) We must check EVERYWHERE if "filp->f_op" is equal to "NULL" (inserting this
   check to fcntl_setlk() is not enough since you will get an "Oops" when you
   will try to unlock the socket).
2) We make certain the "filp->f_op" is not equal to "NULL". Thoughts about it
   is described below.
3) Both 1) and 2).
4) Something else.

By the way can we lock a sockets or a pipes or another special files? Or maybe
the function should return an error in case of special files? The answer to this
question depends on the concepts of the Linux Kernel.

It seems what there are no problems with flock() but does is actually locks the
sockets?

Now some words about "filp->f_op". In many functions deal with files and inodes
we may see peace of code like this (linux/fs/ext2/inode.c):
-
inode->i_op = NULL;
if (inode->i_ino == EXT2_ACL_IDX_INO ||
inode->i_ino == EXT2_ACL_DATA_INO)
/* Nothing to do */ ;
else if (S_ISREG(inode->i_mode))
inode->i_op = _file_inode_operations;
else if (S_ISDIR(inode->i_mode))
inode->i_op = _dir_inode_operations;
else if (S_ISLNK(inode->i_mode))
inode->i_op = _symlink_inode_operations;
else if (S_ISCHR(inode->i_mode))
inode->i_op = _inode_operations;
else if (S_ISBLK(inode->i_mode))
inode->i_op = _inode_operations;
else if (S_ISFIFO(inode->i_mode))
init_fifo(inode);
-
What about "else if (S_ISSOCK(inode->i_mode)) ..."? Since there is no "S_ISSOCK"
the "inode->i_op" is still equal to "NULL" by default. Is it normal or we just
forgot about the sockets? Since the EXT2 is not the only one file system which
can contain a sockets I have found similar code in the following files:
linux/fs/coda/cnode.c
linux/fs/isofs/inode.c
linux/fs/nfs/inode.c
linux/fs/umsdos/inode.c
linux/fs/ext2/inode.c
linux/fs/ext2/namei.c
linux/fs/minix/inode.c
linux/fs/minix/namei.c
linux/fs/sysv/inode.c
linux/fs/sysv/namei.c
linux/fs/ufs/inode.c
linux/fs/ufs/namei.c

And everywhere "S_ISSOCK()" is absent. Is it normal?

Also I have found "struct file_operations socket_file_ops" structure definition
in the file "linux/net/socket.c". Should we use this structure?

That's all. Awaiting your suggestions.

P.S. Since I'm not currently subscribed to Linux Kernel Mailing List please Cc:
all replies also to [EMAIL PROTECTED] if any.

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

[bug] set_pgdir can skip mm's

[V Ganesh]

set_pgdir() needs to modify all active mm's to include the new entry.
what it really does is 
for_each_task(p) {
if (!p->mm)
continue;
*pgd_offset(p->mm,address) = entry;
}

however, there could be a lazy-tlb thread on another cpu whose active_mm
belongs to a process which is dead and gone, and hence won't be covered by the
above code. if this thread then accesses an address covered by this entry, it
would fault.
ideally, we ought to loop through a list of all mm's rather than processes.
but since we don't have such a list, an easier solution is to use p->active_mm
rather than p->mm. this can cause multiple updates of the same pgd, but
the number of such unnecessary extra updates is bound by the number of CPUs.

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

RFC: Security fix for demand loading of filesystem and network interface modules

[Adam J. Richter]

I want to slightly change the way filesystems and network
drivers are demand loaded via request_module.

Currently, querying a nonexistant network interface named,
say, "eth0" results in a result_module call for "eth0".  I want
to change that to "if-eth0".  This will make it impossible for
users to pass things like "-C/my/bogus/modules.config", or to
cause the loading of legitimate but buggy module to crash the
system.  The changes to modutils that Keith Owens posted address the
former problem, but not the latter, which is a pretty real possibility
given that our current builds install 786 modules.  This renaming
is also useful because it will make it possible to make generic
rules for modprobe that handle names that are unrecognized but are
know to be a networking interface (for example, "if-funkylan0" might load
all relevant modules that have PCI or USB class information indicating
that they are network interfaces and which correspond to hardware that
is present).

Likewise, I want to change request_module calls that load
file system modules (in fs/supser.c and fs/fat/cvf.c) to prefix
them with "fs-".

Of course these changes will add string length checking.

Comments?  Are the "fs-" and "if-" prefixes OK?  (There
are currently no real modules that have names beginning with those
strings.)

Adam J. Richter __ __   4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ /  San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l   United States of America
fax +1 408 261-6631  "Free Software For The Rest Of Us."
-
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/