2.2.18ac14 yamaha debug output removal patch.

[Rob Landley]

The new driver works fine on the box here, produces all sorts of debug
gorp to the console though.  Most of the unnecessary printk's are
commented out, these are the three I've been seeing while playing around
with mpg123 and some mp3 files...

Other than that, it worked for me...

Rob

--- linux/drivers/sound/ymfpci.cMon Oct  2 01:46:48 2000
+++ linux2/drivers/sound/ymfpci.c   Mon Oct  2 01:43:03 2000
@@ -668,10 +668,10 @@
/*
 * Normal end of DMA.
 */
-   printk("ymfpci%d: %d: done: delta %d"
-   " hwptr %d swptr %d distance %d count %d\n",
-   codec->inst, voice->number, delta,
-   dmabuf->hwptr, swptr, distance, dmabuf->count);
+// printk("ymfpci%d: %d: done: delta %d"
+// " hwptr %d swptr %d distance %d count %d\n",
+// codec->inst, voice->number, delta,
+// dmabuf->hwptr, swptr, distance, dmabuf->count);
}
played = dmabuf->count;
if (ypcm->running) {
@@ -826,8 +826,8 @@
end >>= 1;
if (w_16)
end >>= 1;
-/* P3 */ printk("ymf_pcm_init_voice: %d: Rate %d Format 0x%08x Delta 0x%x End 0x%x\n",
-  voice->number, rate, format, delta, end);
+/* P3 */ // printk("ymf_pcm_init_voice: %d: Rate %d Format 0x%08x Delta 0x%x End 
+0x%x\n",
+//  voice->number, rate, format, delta, end);
for (nbank = 0; nbank < 2; nbank++) {
bank = &voice->bank[nbank];
bank->format = format;
@@ -1710,7 +1710,7 @@
case SNDCTL_DSP_SETFRAGMENT:
get_user_ret(val, (int *)arg, -EFAULT);
/* P3: these frags are for Doom. Amasingly, it sets [2,2**11]. */
-   /* P3 */ printk("ymfpci: ioctl SNDCTL_DSP_SETFRAGMENT 0x%x\n", val);
+   /* P3 */ // printk("ymfpci: ioctl SNDCTL_DSP_SETFRAGMENT 0x%x\n", val);
 
dmabuf->ossfragshift = val & 0x;
dmabuf->ossmaxfrags = (val >> 16) & 0x;

BUG in buffer.c (2.4.0-test9-pre7); fsck problem

[H. Peter Anvin]

I got the following OOPSen running 2.4.0-test9-pre7; I hope it can be of
use for someone.

Also, this kernel has an odd problem: fsck sometimes gets stuck when
rebooting after crash.  The drive light occationally flashes (not on
solid as it usually is!) but nothing seems to happen in the end.  Booting
into a 2.2 kernel, fsck can make forward progress (usually nothing is
seriously wrong with the filesystem).

Anyway, the first and second oops are included with ksymoops; also a full
serial console transcript is included.

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

ksymoops 2.3.3 on i686 2.4.0-test9-pre7.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.0-test9-pre7/ (default)
 -m /usr/src/linux/System.map (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Error (regular_file): read_system_map stat /usr/src/linux/System.map failed
invalid operand: 
CPU:1
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: 001c   ebx: e94e3e60   ecx: c02f7408   edx: 0027
esi: f7c6deac   edi: f7c6de00   ebp:    esp: c5315eb0
ds: 0018   es: 0018   ss: 0018
Process cc1plus (pid: 6520, stackpage=c5315000)
Stack: c0291c9e c029207a 02da c01cb915 e94e3e60 0001 f7c6de00 c6d12000 
   c6d12000  c01cbc14 f7c6de00 0001 0002 0001 0001 
   0001 f7c6de00 0002  f7c6de00 0242 35ae8000 f7dc0498 
Call Trace: [] [] [] [] [] 
[] [] 
   [] [] [] 
Code: 0f 0b 83 c4 0c c3 8d 76 00 57 56 53 8b 74 24 10 8b 54 24 14 

>>EIP; c013504b<=
Trace; c0291c9e <__br_write_unlock+18e5a/41936>
Trace; c029207a <__br_write_unlock+19236/41936>
Trace; c01cb915 
Trace; c01cbc14 
Trace; c0205ed2 
Trace; c01caedc 
Trace; c0204948 
Trace; c010c566 <__global_restore_flags+92/bc>
Trace; c010c759 
Trace; c010ae7c <__read_lock_failed+114c/25d0>
Code;  c013504b 
 <_EIP>:
Code;  c013504b<=
   0:   0f 0b ud2a  <=
Code;  c013504d 
   2:   83 c4 0c  addl   $0xc,%esp
Code;  c0135050 
   5:   c3ret
Code;  c0135051 
   6:   8d 76 00  leal   0x0(%esi),%esi
Code;  c0135054 
   9:   57pushl  %edi
Code;  c0135055 
   a:   56pushl  %esi
Code;  c0135056 
   b:   53pushl  %ebx
Code;  c0135057 
   c:   8b 74 24 10   movl   0x10(%esp,1),%esi
Code;  c013505b 
  10:   8b 54 24 14   movl   0x14(%esp,1),%edx

Aiee, killing interrupt handler

1 warning and 1 error issued.  Results may not be reliable.


ksymoops 2.3.3 on i686 2.4.0-test9-pre7.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.0-test9-pre7/ (default)
 -m /usr/src/linux/System.map (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Error (regular_file): read_system_map stat /usr/src/linux/System.map failed
invalid operand: 
CPU:1
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: 001b   ebx: 0020   ecx: c02f7408   edx: 
esi:    edi: c5314000   ebp: c5315db8   esp: c5315d60
ds: 0018   es: 0018   ss: 0018
Process cc1plus (pid: 6520, stackpage=c5315000)
Stack: c028b61e c028b836 02ba c5314000 f0e25320 c5314000 c01330a0 0001 
   f48aebc0 0020 f48aece0 0020 0082 c5314000 c5314000 c011cc3a 
   c5314000 c5314000 c5314000 0001 c5314000 000b 000b c011cff8 
Call Trace: [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
Code: 0f 0b 8d 65 b4 5b 5e 5f 89 ec 5d c3 89 f6 55 89 e5 83 ec 24 

>>EIP; c0117c62<=
Trace; c028b61e <__br_write_unlock+127da/41936>
Trace; c028b836 <__br_write_unlock+129f2/41936>
Trace; c01330a0 
Trace; c011cc3a 
Trace; c011cff8 
Trace; c010b2a6 <__read_lock_failed+1576/25d0>
Trace; c010b53e <__read_lock_failed+180e/25d0>
Trace; c0283bbc <__br_write_unlock+ad78/41936>
Trace; c013504b 
Trace; c010aee4 <__read_lock_failed+11b4/25d0>
Trace; c013

Re: What is up with Redhat 7.0?

[Kristofer T. Karas]

Alan Cox wrote:

> I don't see your point except as 'never change anything'. I got bored of
> libc2 a while back. I prefer change

Reasonable coordinated change, or reckless change?

How about shipping a new distribution with a 2.3.x kernel patched in-house to
get rid of most of the oopsen?  This is not conceptually all that different
than shipping a distribution with a patched version of a not-yet-released
compiler.  You are trading innovation for stability; innovation is only useful
to people if it offers sufficient stability and permanency to get the job done.

Change that propagates smoothly through acceptable channels is no doubt a good
thing.  The Linux Kernel enjoys a high rate of change and attempts to appeal to
a wide audience; for this it has achieved excellent name recognition
world-wide.  Despite that, with the possible exception of early versions of
0.x, the kernel has always offered a stable branch that changed comparatively
little versus the development branch; this gave library and application
developers a chance to sync up, resulting in a kernel that was actually useful
to somebody other than a kernel developer.  Had Linus, instead, kept only a
development kernel that changed hourly, never stopping long enough to get the
drivers updated to the structures in the core, then the fragmentation in users
of that kernel would have had a serious negative impact on the viability and
popularity of Linux to the computing world at large.  Change that is
fragmented, leaving discontinuities, has high entropy and a general lack of
solidity.

Granted, the customized software RedHat ships that results in binary
incompatibility is a slightly different concept than degree of change.  But the
end result is similar.  A coordinated effort between RedHat and the other
distribution builders to achieve a common framework for advancement would not
hinder development; to the contrary, the common ground achieved from such a
coordinated effort would make Linux that much stronger.

Kris

-
To unsubscribe from this list: send 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: Corruption on database

[Christoph Rohland]

Hi Markus,

Markus Döhr <[EMAIL PROTECTED]> writes:

> We're currently in the process switching our SAP R/3 systems over to linux.
> Database is SAPDB (former ADABAS). The size is about 125 GB. For storing RAW
> DEVSPACES are used (2 x RAID-5, 1 x RAID-1).
> 
> We have problems with the database under high I/O load. The kernel doesn't
> report any hardware error (sync problems or the like) but the database often
> dumps with signal 11 doing a 'BAD DATA PAGE' on the RAW device what implies
> a full recover. 
> 
> Used is kernel 2.2.16-22SAPenterprise, a 'special' kernel from Redhat with
> some patches (Bigmem, semaphores, LFS etc.).
> 
> Just curious if there are any known issues with RAW devices that are bigger
> than 2 GB and their behaviour under high/very high load. Due to the fact,
> that we have this problem on two nearly identical machines I assume that
> there's no hardware problem with the controller.
> 
> The used hardware is Compaq ProLiant 5500 with 1.8 GB of RAM and 3way P-II
> 450 Xeon. 

I do not think that this is Linux kernel related. There was a bug in
the SAPDB kernel with raw devices.

I have put our support mail address on this reply. Please follow up
with them.

Greetings
Christoph
-
To unsubscribe from this list: send 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: Getting fullspeed from Speedstep processors.

[Alan Cox]

> Is it possible to run these intel 'speedstep' processors at full speed?

Its up to the SMM mode firmware to manage the processor. THe kernel changes
just make our delay loops cope with suprise cpu speed changes.


-
To unsubscribe from this list: send 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: What is up with Redhat 7.0?

[Alan Cox]

> fyi you can compile with egcs with using "gcc -V`egcs-version`" for
> mandrake when you have the egcs package installed.

If you want mandrake builds to auto detect the compiler and use that one then
can you send me a diff 

-
To unsubscribe from this list: send 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: What is up with Redhat 7.0?

[Chmouel Boudjnah]

Alan Cox <[EMAIL PROTECTED]> writes:

> If you want mandrake builds to auto detect the compiler and use that one then
> can you send me a diff 

Actually for 7.2 i change our egcs package to add a kgcc script (which
call gcc with the egcs compiler) to be compatible with your last
changes on 2.2.18, so no need mdk specific code .

(and i believe kgcc name or something else should be standardized
around the distrib).

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

test9-pre7 still truncate/ext2 corruption/system hang bugs

[Linux Now]

I've had reproduceable and repeatable problems with test9 -most of them-
that always leave my laptop stuck. Only sysrq-o seems to respond.

It seems it is related to the truncate proble that arised in test7 series.

When I'm reading my email in an xterm with pine and I expunge a mailbox,
if I'm too fast with my fingers and click several keys in advance -like
the down arrow to check for new email- the system stop working. No oops,
now working keybord, only rebooting through magic key.

I've reproduced it like 20 times, every time I boot with test9-pre7 or
less. test8 doesn't seem to have the same problem.

I'm going to compile test9-pre8, but I haven't seen any change that seems
related to this bug.

If someone needs debugging, please provide me with the proper patch or
instructions as I cannot get any oops. I'll carry on the necessary tests.

Pau

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

block_truncate_page bug?

[Ben Fennema]

I'm getting calls to end_buffer_io_bad caused by block_truncate_page.

The path that is causing it is a update page with no buffers, so
create_empty_buffers gets called. (w/ all the buffers io set to
end_buffer_io_bad). Since the page is uptodate, the buffer is set to be
update and the b_end_io is never change to end_buffer_io_sync. Then,
the buffer is marked dirty. When the end_io function is called, BUG (and
hard lockup of system).

Am I not supposed to be calling block_truncate_page on a uptodate page with
no buffers, or is it something that fell through the cracks?

Ben

-- 
Linux UDF - http://linux-udf.sourceforge.net
Latest Is - udf-0.9.2.1 (http://www.csc.calpoly.edu/~bfennema/udf.html)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

IDE patches for 2.2.17

[Mike A. Harris]

Well, I've applied the IDE patches for 2.2.17, and everything
appears to be working with my VIA board much better now.

I'm not sure it is totally optimal yet though.  My CDROM's are on
the second channel, and I don't much care about them.

Can I configure it somehow to optimize it for single channel
operation with 2 Quantum Fireballs?  Leaving the second channel
UDMAless?  I read something about tweaking FIFO, but don't have a
clue about it and don't want to risk anything.

Plus could y'all look at the data below and tell me if anything
is wrong or should be changed?  I'm a bit worried about the hdd
failure warning/error messages on /dev/hdd (my 4x Toshiba CDROM).

I'm using:  hdparm -X66 -m16c1d1k1

Also, if there is a linux-ide mailing list, where is it?  I
couldn't find one on linux-ide.org nor on www.liszt.com...

Any help appreciated.


1 root@asdf:/proc# cat ide/via
Command register = 0x7
Master Read  Cycle IRDY 1 Wait State
Master Write Cycle IRDY 1 Wait State
FIFO Output Data 1/2 Clock Advance: off
Bus Master IDE Status Register Read Retry: on
Latency timer = 32 (max. = 0)
Interrupt Steering Swap: off
--Primary IDESecondary IDE-
both channels togth:   yes yes
Prefetch Buffer :  on  on
Post Write Buffer: on  on
FIFO Conf/Chan. :  08  08
Threshold Prim. :  1/2 1/2
Read DMA FIFO flush:   on  on
End Sect. FIFO flush:  on  on
Max DRDY Pulse Width:  No limitation
Bytes Per Sector:  512 512
--drive0--drive1---drive0--drive1
DMA enabled:yes yes  yes no
Act Pls Width:  03  03   04  07
Recovery Time:  01  01   02  06
Add. Setup T.:  4T  4T   4T  4T
--UDMA-Timing-Control
Enable Meth.:0   00   0
Enable: yes yes  no  no
Transfer Mode: PIO PIO  DMA DMA
Cycle Time: 2T  2T   5T  5T


1 root@asdf:/proc# hdparm -v /dev/hd[abcd]

/dev/hda:
 multcount= 16 (on)
 I/O support  =  1 (32-bit)
 unmaskirq=  0 (off)
 using_dma=  1 (on)
 keepsettings =  1 (on)
 nowerr   =  0 (off)
 readonly =  0 (off)
 readahead=  8 (on)
 geometry = 935/255/63, sectors = 15032115, start = 0

/dev/hdb:
 multcount= 16 (on)
 I/O support  =  1 (32-bit)
 unmaskirq=  0 (off)
 using_dma=  1 (on)
 keepsettings =  1 (on)
 nowerr   =  0 (off)
 readonly =  0 (off)
 readahead=  8 (on)
 geometry = 524/255/63, sectors = 8418816, start = 0

/dev/hdc:
 HDIO_GET_MULTCOUNT failed: Input/output error
 I/O support  =  0 (default 16-bit)
 unmaskirq=  0 (off)
 using_dma=  1 (on)
 keepsettings =  0 (off)
 HDIO_GET_NOWERR failed: Input/output error
 readonly =  0 (off)
 BLKRAGET failed: Input/output error
 HDIO_GETGEO failed: Invalid argument
hdd: set_drive_speed_status: status=0x51 { DriveReady
SeekComplete Error }
hdd: set_drive_speed_status: error=0x04
hdd: ATAPI 4X CD-ROM drive, 256kB Cache

/dev/hdd:
 HDIO_GET_MULTCOUNT failed: Invalid argument
 I/O support  =  0 (default 16-bit)
 unmaskirq=  0 (off)
 using_dma=  0 (off)
 keepsettings =  0 (off)
 HDIO_GET_NOWERR failed: Invalid argument
 readonly =  1 (on)
 readahead=  8 (on)
 HDIO_GETGEO failed: Invalid argument



Uniform Multi-Platform E-IDE driver Revision: 6.30
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
VT 82C598 Apollo MVP3
 Chipset Core ATA-33
Split FIFO Configuration:  8 Primary buffers, threshold = 1/2
   8 Second. buffers, threshold = 1/2
ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:DMA,
hdb:DMA
ide0: VIA Bus-Master (U)DMA Timing Config Success
ide1: BM-DMA at 0xe008-0xe00f, BIOS settings: hdc:DMA,
hdd:pio
ide1: VIA Bus-Master (U)DMA Timing Config Success
hda: QUANTUM FIREBALL EL7.6A, ATA DISK drive
hdb: QUANTUM FIREBALL SE4.3A, ATA DISK drive
hdc: HP CD-Writer+ 7200, ATAPI CDROM drive
hdd: TOSHIBA CD-ROM XM-5302TA, ATAPI CDROM drive
hdd: set_drive_speed_status: status=0x51 { DriveReady
SeekComplete Error }
hdd: set_drive_speed_status: error=0x04
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: QUANTUM FIREBALL EL7.6A, 7339MB w/418kB Cache,
CHS=935/255/63, UDMA(33)
hdb: QUANTUM FIREBALL SE4.3A, 4110MB w/80kB Cache,
CHS=524/255/63, UDMA(33)






--
  Mike A. Harris  -  Linux advocate  -  Open source advocate
  Computer Consultant - Capslock Consulting
 Copyright 2000 all rights reserved
-

Re: Anyone working on multi-threaded core files for 2.4 ?

[James Cownie]

> Can someone explain why core dumping can't be done in userspace?
...
> There must be a good reason Unix and Linux don't do this ... but I
> haven't thought of it yet.  Anyone care to enlighten me?

The problem, I believe, is that once a process has reached the point
where it has been delivered a core dumping signal (of which there are
more than just SIGSEGV, of course), you can't rely on anything about
its internal state.

So, in particular, it could have unmapped all its writeable memory, or
have overwritten it with zeroes, or ... 

Therefore it's not at all clear that there's enough of the process
left to be able to guarantee that code inside it will be able to write
a core file.

If you really wanted to write core files from user space, the way to
do it would be to have a separate, well known to the kernel, daemon
process whose sole job was to dump the core of failing processes when
requested to do so by the kernel. FWIW I believe that this is what
HURD does.

This would be rather a micro-kernelish approach, but given that core
dumping is both rare and expensive anyway any performance hit from
doing it like this would be irrelevant.

Such an approach might be nice, (the kernel would get smaller, and
embedded folks could just leave out the code dumping daemon) but it's
a much more major change than anyone would want to do now for 2.4.

It's also hard to summon much enthusiasm to do it, since it's deep
into the "If it's not broken don't fix it" area.

-- Jim 

James Cownie<[EMAIL PROTECTED]>
Etnus, LLC. +44 117 9071438
http://www.etnus.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/

reset/reboot with test8 and above

[Norbert Preining]

Hello!

I know this may not be the right place but I tried in a lot of
different places:

Following problem: I have a nvidia card, the nvidia drivers 0.9-5
an ALi MoBo (P5A-B).

I have test7 running wonderful.

When I start X under test8 - test9-pre7 it reboots immediately.

Nothing in the logfiles, like a hard reset.

I tried the following things:
* compiled the nvidia_kernel with all the options for turning of
  agp 2x/4x, SBA, FW
* installed the ALi patches for test7/test8 from #nvidia ice-dcc

but it was always the same.

I looked into the test8-patch but didn't find any changes to agp-support.

Does anybody have an idea what can be the source of these reboots?

Please Cc: me any answer since I am not subscribed to the list, thanks a lot!

Best wishes
Norbert

-- 
ciao
norb

+---+
| Norbert Preining  http://www.logic.at/people/preining |
| University of Technology Vienna, Austria[EMAIL PROTECTED] |
| DSA: 0x09C5B094 (RSA: 0xCF1FA165) mail subject: get [DSA|RSA]-key |
+---+

 PGP signature

Re: 32-bit pid_t / security

[David Weinehall]

On Mon, Oct 02, 2000 at 04:16:44AM +0200, Andries Brouwer wrote:
> On Sun, Oct 01, 2000 at 07:51:13PM +0200, David Weinehall wrote:
> 
> > Hoping for security just by having more
> > PID's is a bit naive.
> 
> *1*
> It is strange that people do not really seem to understand
> the case for a 32-bit pid_t.
> This case is: "16 bits is not enough".
> 
> We all know that 640KB was enough, and that 1024 cylinders was enough,
> and ten or twenty years later these assumptions turned out to be very
> inconvenient. 
> 
> Today 32000 processes is enough - I rarely see more than 500.
> But there will be a moment in time when 32000 no longer is enough.
> If we have to change anyway, changing early is better than
> changing late. There always are people with unusual needs.

If you read my entire post, rather than just the part that you quoted,
you'll see that I argue FOR, not against, a larger pid_t, based on just
these grounds; I know that sooner or later, we'll need those extra
processes. Well, my 486 won't...

> *2*
> So, in the long run we want a large pid_t. What about the short run?
> For today the disadvantages are negligeable, and for people who
> like security there are definite advantages.
> 
> David, I already said the same to someone else:
> Security is not a yes/no matter. It is a matter of less or more.
> Thus, "Hoping for security" is meaningless.
> But "Hoping for more security by having more PID's" is quite
> reasonable. If I am local user on your system then I can break in
> using a wraparound. If that takes 2147483647 processes I have to
> wait longer than when that takes 32000 processes.

Again, read the entire post, not just the part you quoted. PLEASE?
Even just the quote. "[...]JUST by having more PID's[...]". The
paragraph this stands in continues with a reasoning on how much
easier it would be to assume that someone's trying to break into your
machine when's he's doing a forkbomb and trying to eat 31 bits of
PID's rather than just 15...

Please, I'm with you on this one, not against you. I want pid_t to be
increased. I'd rather see it sooner than later. What I meant was simply
that _purely_ making the move out of security reasons might not be
reasonable.


/David
  _ _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/http://www.tux.org/lkml/

Re: block_truncate_page bug?

[Alexander Viro]

On Mon, 2 Oct 2000, Ben Fennema wrote:

> I'm getting calls to end_buffer_io_bad caused by block_truncate_page.
> 
> The path that is causing it is a update page with no buffers, so
> create_empty_buffers gets called. (w/ all the buffers io set to
> end_buffer_io_bad). Since the page is uptodate, the buffer is set to be
> update and the b_end_io is never change to end_buffer_io_sync. Then,
> the buffer is marked dirty. When the end_io function is called, BUG (and
> hard lockup of system).
> 
> Am I not supposed to be calling block_truncate_page on a uptodate page with
> no buffers, or is it something that fell through the cracks?

No, that's a bug.

--- fs/buffer.cMon Oct  2 05:52:22 2000
+++ fs/buffer.cMon Oct  2 05:58:55 2000
@@ -1807,9 +1807,10 @@
if (Page_Uptodate(page))
set_bit(BH_Uptodate, &bh->b_state);

+   bh->b_end_io = end_buffer_io_sync;
+
if (!buffer_uptodate(bh)) {
err = -EIO;
-   bh->b_end_io = end_buffer_io_sync;
ll_rw_block(READ, 1, &bh);
wait_on_buffer(bh);
/* Uhhuh. Read error. Complain and punt. */

-
To unsubscribe from this list: send 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: serial driver problems?

[Matthias Andree]

On Mon, 02 Oct 2000, Ben Marsh wrote:

> I have a Banksia iTra8 8 port internal ISA modem card (UART 16654) for dial
> up access.  To get the modem card to work I was told to replace serial.c and
> SerialP.h  from 2.2.x kernel source (used 2.2.14-12) and compile a kernel.

Hum. Tytso has his serial drivers at
http://sourceforge.net/projects/serial/ and an accompanying, updated
setserial at http://sourceforge.net/projects/setserial/ (note sure if
you need these). Work for me (16750 UARTS here).

You can compile the serial driver either by copying files into the
kernel source or separately from the kernel (you only need to have the
*configured* kernel at /usr/src/linux; symlink if it's not there), but
watch out, it replaces your serial SysV init script
(/etc/rc.d/init.d/serial or /sbin/init.d/serial).

Please also make sure your kernel is 2.2.16 or .17 for security reasons.

For your convenience, if you're using 2.2.17, check out
http://home.pages.de/~mandree/kernelpatches/v2.2/v2.2.17/ - there is a
PATCHES-ma2 file and a patch-2.2.17-ma2.bz2. The first describes what
patches I have collected in the second file (quite a lot, IDE, I²C among
them). It is meant to be applied on top of a kernel.org linux 2.2.17.

> Do you need any files? I am unclear on which files to send you guys. Who is
> the maintainer of the serial code?

Try the updated serial driver from sourceforge.net first. Patching old
drivers into new kernels is usually not a good idea.

-- 
Matthias Andree
-
To unsubscribe from this list: send 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: 32-bit pid_t / security

[Alan Cox]

> If you read my entire post, rather than just the part that you quoted,
> you'll see that I argue FOR, not against, a larger pid_t, based on just
> these grounds; I know that sooner or later, we'll need those extra
> processes. Well, my 486 won't...

S/390 folks run 70,000 sessions active within the same 60 second period off
one big box. Not on Linux (yet ;)) but its worth bearing in mind.

Alan

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

Alan, are you out there?!

[David Weinehall]

I'm sorry, this is TOTALLY irrelevant to any discussions on this list,
but...

Alan, I've sent you a couple of e-mail concerning v2.0.39 lately
(sunday and friday if I'm not all wrong), did you receive them? If
not, it seems I too got caught by your filtering...


/David
  _ _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/http://www.tux.org/lkml/

Re: 32-bit pid_t / security

[Keith Owens]

On Mon, 2 Oct 2000 11:27:16 +0100 (BST), 
Alan Cox <[EMAIL PROTECTED]> wrote:
>S/390 folks run 70,000 sessions active within the same 60 second period off
>one big box. Not on Linux (yet ;)) but its worth bearing in mind.

FYI, OS/390 Unix System Services uses a halfword for the maximum number
of processes in system limits MAXPROCSYS and MAXPROCUSER.  The fields
are defined as full words but the API only uses the low half word.
Even their pid is structured as (big endian)

  Bit 0   Reserved, must be 0
  Bit 1-7 Slot reuse counter.
  Bit 8-15Reserved, currently 0.
  Bit 16-31   Process slot number.

Obviously IBM think that 64K concurrent processes is enough for anyone,
even on big iron.  Now where have I heard that before ;)?

-
To unsubscribe from this list: send 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-test9-pre8 static cleanup

[Keith Owens]

Trivial patch to remove some of the largest zero static initializers in
my compile.

Index: 0-test9-pre8.1/net/ipv6/protocol.c
--- 0-test9-pre8.1/net/ipv6/protocol.c Fri, 26 May 2000 13:10:01 +1000 kaos 
(linux-2.4/e/36_protocol.c 1.1 644)
+++ 0-test9-pre8.1(w)/net/ipv6/protocol.c Mon, 02 Oct 2000 21:40:30 +1100 kaos 
+(linux-2.4/e/36_protocol.c 1.1 644)
@@ -32,11 +32,8 @@
 #include 
 #include 
 
-struct inet6_protocol *inet6_protocol_base = NULL;
-struct inet6_protocol *inet6_protos[MAX_INET_PROTOS] = 
-{
-   NULL
-};
+struct inet6_protocol *inet6_protocol_base;
+struct inet6_protocol *inet6_protos[MAX_INET_PROTOS];
 
 void inet6_add_protocol(struct inet6_protocol *prot)
 {
Index: 0-test9-pre8.1/init/version.c
--- 0-test9-pre8.1/init/version.c Fri, 26 May 2000 13:10:01 +1000 kaos 
(linux-2.4/j/45_version.c 1.1 644)
+++ 0-test9-pre8.1(w)/init/version.c Mon, 02 Oct 2000 21:40:30 +1100 kaos 
+(linux-2.4/j/45_version.c 1.1 644)
@@ -14,7 +14,7 @@
 #define version(a) Version_ ## a
 #define version_string(a) version(a)
 
-int version_string(LINUX_VERSION_CODE) = 0;
+int version_string(LINUX_VERSION_CODE);
 
 struct new_utsname system_utsname = {
UTS_SYSNAME, UTS_NODENAME, UTS_RELEASE, UTS_VERSION,
Index: 0-test9-pre8.1/arch/i386/kernel/traps.c
--- 0-test9-pre8.1/arch/i386/kernel/traps.c Tue, 26 Sep 2000 12:13:33 +1100 kaos 
(linux-2.4/A/c/1_traps.c 1.1.2.2.1.1.2.1.2.3.1.2 644)
+++ 0-test9-pre8.1(w)/arch/i386/kernel/traps.c Mon, 02 Oct 2000 21:40:30 +1100 kaos 
+(linux-2.4/A/c/1_traps.c 1.1.2.2.1.1.2.1.2.3.1.2 644)
@@ -416,8 +416,8 @@ inline void nmi_watchdog_tick(struct pt_
 *  here too!]
 */
 
-   static unsigned int last_irq_sums [NR_CPUS] = { 0, },
-   alert_counter [NR_CPUS] = { 0, };
+   static unsigned int last_irq_sums [NR_CPUS],
+   alert_counter [NR_CPUS];
 
/*
 * Since current-> is always on the stack, and we always switch

-
To unsubscribe from this list: send 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: 32-bit pid_t / security

[Alan Cox]

> On Mon, 2 Oct 2000 11:27:16 +0100 (BST), 
> Alan Cox <[EMAIL PROTECTED]> wrote:
> >S/390 folks run 70,000 sessions active within the same 60 second period off
> >one big box. Not on Linux (yet ;)) but its worth bearing in mind.
> 
> FYI, OS/390 Unix System Services uses a halfword for the maximum number
> of processes in system limits MAXPROCSYS and MAXPROCUSER.  The fields

The 70,000+ users folk dont run OS/390 unix services either

-
To unsubscribe from this list: send 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-test9-pre8

[Jan Niehusmann]

On Mon, Oct 02, 2000 at 02:11:33AM -0400, Mohammad A. Haque wrote:
> Broke md as module. I guess this is one way to fix it.

I propose the following patch. It fixes lvm modules, too.

Jan


--- linux-2.4.0-test9-pre8/drivers/Makefile.origMon Oct  2 12:49:03 2000
+++ linux-2.4.0-test9-pre8/drivers/Makefile Mon Oct  2 12:43:18 2000
@@ -31,7 +31,8 @@
 subdir-$(CONFIG_I2O)   += i2o
 subdir-$(CONFIG_IDE)   += ide
 subdir-$(CONFIG_SCSI)  += scsi
-subdir-$(CONFIG_MD)+= md
+subdir-$(CONFIG_BLK_DEV_MD)+= md
+subdir-$(CONFIG_BLK_DEV_LVM)   += md
 subdir-$(CONFIG_IEEE1394)  += ieee1394
 subdir-$(CONFIG_PNP)   += pnp
 subdir-$(CONFIG_ISDN)  += isdn
-
To unsubscribe from this list: send 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: set_current_state() vs current->state

[Manfred]

Andrea wrote:
> In short you need set_current_state(x) when you do something that relies on the 
> ordering like: 
> 
> set_current_state(TASK_UNINTERRUPTIBLE) 
> if (event_happened_meanwhile) 
> break; 
> schedule(); 

Btw, even if the code is protected with a spinlock you must use
set_current_state, spin_unlock() is only a partial memory barrier (at
least on i386 and ia64).

   set_current_state(TASK_UNINTERRUPTIBLE) 
/* __set_current_state() can lock up */
   spin_unlock(&lock);
   if (event_happened_meanwhile) 
break; 
   schedule(); 


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

[PATCH-2.2.18] compile fix for netdevice.h

[willy tarreau]

Hi Alan,

with the ethernet frame diverter in 2.2.18,
netdevice.h
breaks compilation of user space progs because of an
include of . The following one-liner
patch fixes it.

BTW, in the 2.2.18pre14 main Makefile, the "CC = "
statement should be replaced with "CC := ". On my box,
the kwhich script was called 124 times !

-- patch to netdevice.h --
diff -urN 18wt2-1/include/linux/netdevice.h
18wt2-1bis/include/linux/netdevice.h
--- 18wt2-1/include/linux/netdevice.h   Mon Oct  2
13:41:24 2000
+++ 18wt2-1bis/include/linux/netdevice.hMon
Oct  2 13:49:24 2000
@@ -30,7 +30,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 


___
Do You Yahoo!? -- Pour dialoguer en direct avec vos amis, 
Yahoo! Messenger : http://fr.messenger.yahoo.com
 divert-include.gz

Re: [PATCH] fix for VM test9-pre7

[ehrhardt]

Hi,

On Mon, Oct 02, 2000 at 12:42:47AM -0300, Rik van Riel wrote:
> --- linux-2.4.0-test9-pre7/fs/buffer.c.orig   Sat Sep 30 18:09:18 2000
> +++ linux-2.4.0-test9-pre7/fs/buffer.cMon Oct  2 00:19:41 2000
> @@ -706,7 +706,9 @@
>  static void refill_freelist(int size)
>  {
>   if (!grow_buffers(size)) {
> - try_to_free_pages(GFP_BUFFER);
> + wakeup_bdflush(1);
> + current->policy |= SCHED_YIELD;
> + schedule();
>   }
>  }

This part looks strange! wakeup_bdflush will sleep if the parameter
is not zero, i.e. we'll schedule twice. I doubt that this the intended
behaviour?

regardsChristian

-- 
THAT'S ALL FOLKS!
-
To unsubscribe from this list: send 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: What is up with Redhat 7.0?

[Marc Lehmann]

On Sun, Oct 01, 2000 at 09:33:31PM -0400, Horst von Brand 
<[EMAIL PROTECTED]> wrote:
> > many others.
> 
> What makes Debian's package management "reasonable" where others aren't?

This *really* doesn't belong on linux-kernel.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |
-
To unsubscribe from this list: send 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: Corruption on database

[Christoph Rohland]

Christoph Rohland <[EMAIL PROTECTED]> writes:

> I do not think that this is Linux kernel related. There was a bug in
> the SAPDB kernel with raw devices.

Actually I have to correct myself :-( 

I do not know what's happening. The fixed error was _not_ about this
problem. We will investigate further here at SAP. (But still any help
from lkml is of course welcome)

Greetings
Christoph
-
To unsubscribe from this list: send 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.18] compile fix for netdevice.h

[Jeff Garzik]

On Mon, 2 Oct 2000, [iso-8859-1] willy tarreau wrote:
> diff -urN 18wt2-1/include/linux/netdevice.h
> 18wt2-1bis/include/linux/netdevice.h
> --- 18wt2-1/include/linux/netdevice.h   Mon Oct  2
> 13:41:24 2000
> +++ 18wt2-1bis/include/linux/netdevice.hMon
> Oct  2 13:49:24 2000
> @@ -30,7 +30,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  #include 
>  

Something else is wrong if this patch is necessary...  including any net
header is 

#include 


-
To unsubscribe from this list: send 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-test9-pre8

[Mohammad A. Haque]

This would make more sense wouldn't it. I guess it doesn't help to look
right before heading off to bed.

I hope the rest of you guys are getting enough sleep.

Jan Niehusmann wrote:
> 
> On Mon, Oct 02, 2000 at 02:11:33AM -0400, Mohammad A. Haque wrote:
> > Broke md as module. I guess this is one way to fix it.
> 
> I propose the following patch. It fixes lvm modules, too.
> 
> Jan
> 
> --- linux-2.4.0-test9-pre8/drivers/Makefile.origMon Oct  2 12:49:03 2000
> +++ linux-2.4.0-test9-pre8/drivers/Makefile Mon Oct  2 12:43:18 2000
> @@ -31,7 +31,8 @@
>  subdir-$(CONFIG_I2O)   += i2o
>  subdir-$(CONFIG_IDE)   += ide
>  subdir-$(CONFIG_SCSI)  += scsi
> -subdir-$(CONFIG_MD)+= md
> +subdir-$(CONFIG_BLK_DEV_MD)+= md
> +subdir-$(CONFIG_BLK_DEV_LVM)   += md
>  subdir-$(CONFIG_IEEE1394)  += ieee1394
>  subdir-$(CONFIG_PNP)   += pnp
>  subdir-$(CONFIG_ISDN)  += isdn
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

-- 

=
Mohammad A. Haque  http://www.haque.net/ 
   [EMAIL PROTECTED]

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [EMAIL PROTECTED]
=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test9-pre8

[Jan Niehusmann]

On Mon, Oct 02, 2000 at 08:32:40AM -0400, Mohammad A. Haque wrote:
> This would make more sense wouldn't it. I guess it doesn't help to look
> right before heading off to bed.

Please note that my patch still has problems: It doesn't work with 
CONFIG_BLK_DEV_MD and CONFIG_BLK_DEV_LVM both =y.

Christoph Hellwig sent me a better patch, with Cc: to Linus, so I hope this
will be fixed in test9. 

Jan

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

Apologies

[Igmar Palsenberg]

Hi,

Want to apologise to this list with regarding to the RH 7.0 thread. I was
way out off line.


Igmar

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

Re: 32-bit pid_t / security

[Andries Brouwer]

On Mon, Oct 02, 2000 at 11:47:41AM +0200, David Weinehall wrote:

> > Thus, "Hoping for security" is meaningless.
> > But "Hoping for more security by having more PID's" is quite
> > reasonable. If I am local user on your system then I can break in
> > using a wraparound. If that takes 2147483647 processes I have to
> > wait longer than when that takes 32000 processes.
> 
> Please, I'm with you on this one, not against you. I want pid_t to be
> increased. I'd rather see it sooner than later.

Good.

> What I meant was simply that _purely_ making the move out of security
> reasons might not be reasonable.

So it is only here we disagree.

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/

Re: 2.4.0-test9-pre8

[Jeff Garzik]

On Mon, 2 Oct 2000, Jan Niehusmann wrote:
> On Mon, Oct 02, 2000 at 08:32:40AM -0400, Mohammad A. Haque wrote:
> > This would make more sense wouldn't it. I guess it doesn't help to look
> > right before heading off to bed.
> 
> Please note that my patch still has problems: It doesn't work with 
> CONFIG_BLK_DEV_MD and CONFIG_BLK_DEV_LVM both =y.
> 
> Christoph Hellwig sent me a better patch, with Cc: to Linus, so I hope this
> will be fixed in test9. 

*nudge* Here's hoping that one of you guys will post the patch, since
it's quite useful and I don't see it on lkml  Otherwise it might be
Tuesday (test9-final) before everyone else gets the fix

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/

PATCH 2.4.0.9.8: support for external module building

[Jeff Garzik]

Linus,

The attached patch against 2.4.0-test9-pre8 greatly improves support
for maintaining open source modules outside the kernel.

This patch changes linux/Makefile to export all important Make settings
with each kernel build, so that external modules can then pick up that
info and build with the -exact- configuration that the kernel itself was
built with.

The patch also includes docs for the feature, and adds
include/linux/module.mak for use in external module Makefiles.

(this was authored by one of the Olaf's... Titz or Kirsch.  Damn me, I
can't remember who, to properly credit)

Jeff





diff -urN linux.vanilla/Documentation/external-modules.txt 
linux_2_3/Documentation/external-modules.txt
--- linux.vanilla/Documentation/external-modules.txtThu Jan  1 01:00:00 1970
+++ linux_2_3/Documentation/external-modules.txtMon Oct  2 12:59:51 2000
@@ -0,0 +1,34 @@
+To compile external modules, you need the include tree of a configured
+kernel (after doing at least "make dep").
+
+Set up a Makefile in the module's directory which contains at least
+these lines:
+
+  # Object files which make up the module: without exported symbols
+  M_OBJS=foo.o bar.o
+  # ...and with exported symbols
+  MX_OBJS=fred.o
+  # Target into which the M_OBJS and MX_OBJS files are linked
+  M_TARGET=squish.o
+
+  # set this to your kernel include directory. Use this variable name.
+  # make sure it ends in /include.
+  HPATH=/var/export/src/linux-2.3.99-pre3/include
+  include $(HPATH)/linux/module.mak
+
+
+Then you can do...  to do...
+
+make depupdate the ksym tables if needed,
+generate a dependencies file
+make modulescompile the objects and link them into a module
+make modules_installinstall the module into its final location
+make clean  to clean up everything
+
+The module Makefile can define other variables, such as:
+
+EXTRA_CFLAGSadditional CFLAGS for all objects
+CFLAGS_foo.oadditional CFLAGS for foo.o
+PRE_CFLAGS  additional CFLAGS for all objects, set first on
+CC command line
+INSTALL_MOD_PATHmodule installation root (default /)
diff -urN linux.vanilla/Makefile linux_2_3/Makefile
--- linux.vanilla/Makefile  Mon Oct  2 13:05:12 2000
+++ linux_2_3/Makefile  Mon Oct  2 12:59:47 2000
@@ -345,6 +345,26 @@
 $(patsubst %, _modinst_%, $(SUBDIRS)) :
$(MAKE) -C $(patsubst _modinst_%, %, $@) modules_install
 
+include/linux/module.mak: dummy
+   @echo VERSION = $(VERSION) > .ver
+   @echo PATCHLEVEL = $(PATCHLEVEL) >> .ver
+   @echo SUBLEVEL = $(SUBLEVEL) >> .ver
+   @echo EXTRAVERSION = $(EXTRAVERSION) >> .ver
+   @echo ARCH = $(ARCH) >> .ver
+   @echo CC = $(CROSS_COMPILE)gcc >> .ver
+   @echo LD = $(LD) >> .ver
+   @echo GENKSYMS = $(GENKSYMS) >> .ver
+ifdef CONFIG_SMP
+   @echo CONFIG_SMP = 1 >> .ver
+endif
+ifdef CONFIG_MODVERSIONS
+   @echo CONFIG_MODVERSIONS = 1 >> .ver
+endif
+   @(echo CFLAGS = $(CFLAGS) $(MODFLAGS) | sed 's,$(TOPDIR)/include,$$(HPATH),g') 
+>> .ver
+   @echo LINUX_COMPILER = \"`$(CC) -v 2>&1 | tail -1`\" >> .ver
+   @echo include '$$(HPATH)/linux/module.rules' >> .ver
+   @mv -f .ver $@
+
 # modules disabled
 
 else
@@ -355,13 +375,18 @@
@echo "Then build a kernel with module support enabled."
@echo
@exit 1
+
+include/linux/module.mak: dummy
+   @echo modules modules_install: > .ver
+   @$(MAKE) -n modules | sed -n "s/^e/ @e/p" >> .ver
+   @mv -f .ver $@
+
 endif
 
 clean: archclean
rm -f kernel/ksyms.lst include/linux/compile.h
-   find . -name '*.[oas]' -type f -print | grep -v lxdialog/ | xargs rm -f
-   rm -f core `find . -type f -name 'core' -print`
-   rm -f core `find . -type f -name '.*.flags' -print`
+   find . \( -name '*.[oas]' -o -name core -o -name '.*.flags' \) -type f -print 
+| \
+   grep -v lxdialog/ | xargs rm -f
rm -f vmlinux System.map
rm -f .tmp*
rm -f drivers/char/consolemap_deftbl.c drivers/video/promcon_tbl.c
@@ -376,7 +401,9 @@
$(MAKE) -C Documentation/DocBook clean
 
 mrproper: clean archmrproper
-   rm -f include/linux/autoconf.h include/linux/version.h
+   find . \( -name .depend -o -name core -o -size 0 \) -type f -print | \
+   xargs rm -f
+   rm -f include/linux/autoconf.h include/linux/version.h include/linux/module.mak
rm -f drivers/net/hamradio/soundmodem/sm_tbl_{afsk1200,afsk2666,fsk9600}.h
rm -f drivers/net/hamradio/soundmodem/sm_tbl_{hapn4800,psk4800}.h
rm -f drivers/net/hamradio/soundmodem/sm_tbl_{afsk2400_7,afsk2400_8}.h
@@ -394,8 +421,6 @@
rm -f .menuconfig.log
rm -f include/asm
rm -rf include/config
-   rm -f .depend `find . -type f -name .depend -print`
-   rm -f core `find . -type f -size 0 -print`
rm -f .hdepend scripts/mkdep scripts/sp

Re: 2.2.18pre14 msdos mounted filesystems now in uppercase?

[tenthumbs]

On Mon, 2 Oct 2000, Andries Brouwer wrote:

> [omitted]
> 
> so I suppose that if you try the "small" mount option
> you should get the old behaviour back.
>

Yes, that works. I'm impressed that even old mounts handle this
correctly.

 
> [Clearly not a bug, although I don't know whether it is
> a good idea to change the case of filenames halfway a
> sequence of stable kernels.]
> 
> Andries
> 
> 


If I try something like:

--- linux.18p14/fs/fat/inode.c  Sun Oct  1 12:20:41 2000
+++ linux.18p14/fs/fat/inode.c.new  Mon Oct  2 08:35:02 2000
@@ -216,7 +216,7 @@
opts->quiet = opts->sys_immutable = opts->dotsOK =
opts->showexec = 0;
opts->codepage = 0;
opts->utf8 = 0;
-   opts->small_letter = 0;
+   opts->small_letter = 1;
opts->iocharset = NULL;
*debug = *fat = 0;

then msdos mounts work as they used to but vfat mounts are also
affected. I suspect someone didn't consider all the possibilities.

In any event, breaking long-standing behavior (at least as far back as
1.2 kernels) seems like a bad idea.

Thanks.


-
To unsubscribe from this list: send 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: [KBUILD] PATCH 2.4.0.9.8: support for external module building

[Christoph Hellwig]

On Mon, Oct 02, 2000 at 08:06:08AM -0500, Jeff Garzik wrote:
> Linus,
> 
> The attached patch against 2.4.0-test9-pre8 greatly improves support
> for maintaining open source modules outside the kernel.
> 
> This patch changes linux/Makefile to export all important Make settings
> with each kernel build, so that external modules can then pick up that
> info and build with the -exact- configuration that the kernel itself was
> built with.
> 
> The patch also includes docs for the feature, and adds
> include/linux/module.mak for use in external module Makefiles.

Could you change module.mak to use a new-style syntax (obj-foo).
We'd like to get rid of the old *_OBJS stuff as soon as possible.
(Or let Olaf do it ;).

Christoph

-- 
Always remember that you are unique.  Just like everyone else.
-
To unsubscribe from this list: send 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-test9-pre8

[Christoph Hellwig]

On Mon, Oct 02, 2000 at 08:01:14AM -0500, Jeff Garzik wrote:
> > Christoph Hellwig sent me a better patch, with Cc: to Linus, so I hope this
> > will be fixed in test9. 
> 
> *nudge* Here's hoping that one of you guys will post the patch, since
> it's quite useful and I don't see it on lkml  Otherwise it might be
> Tuesday (test9-final) before everyone else gets the fix

Sorry, I Cc'ed vger.rutgers.edu instead of vger.kernel.org again ...

Here's the patch with a little change suggested by Jan (bool vs tristate):

(edited in-place, take care ;))

--- drivers/md/Config.in~   Mon Oct  2 13:34:11 2000
+++ drivers/md/Config.inMon Oct  2 13:35:44 2000
@@ -4,7 +4,9 @@
 mainmenu_option next_comment
 comment 'Multi-device support (RAID and LVM)'
 
-tristate 'Multiple devices driver support (RAID and LVM)' CONFIG_BLK_DEV_MD
+bool 'Multiple devices driver support (RAID and LVM)' CONFIG_MD
+
+dep_tristate ' RAID support' CONFIG_BLK_DEV_MD $CONFIG_MD
 dep_tristate '  Linear (append) mode' CONFIG_MD_LINEAR $CONFIG_BLK_DEV_MD
 dep_tristate '  RAID-0 (striping) mode' CONFIG_MD_RAID0 $CONFIG_BLK_DEV_MD
 dep_tristate '  RAID-1 (mirroring) mode' CONFIG_MD_RAID1 $CONFIG_BLK_DEV_MD
@@ -14,7 +16,7 @@
 bool '  Auto Detect support' CONFIG_AUTODETECT_RAID
 fi
 
-dep_tristate 'Logical volume manager (LVM) support' CONFIG_BLK_DEV_LVM 
$CONFIG_BLK_DEV_MD
+dep_tristate ' Logical volume manager (LVM) support' CONFIG_BLK_DEV_LVM $CONFIG_MD
 dep_mbool '   LVM information in proc filesystem' CONFIG_LVM_PROC_FS 
$CONFIG_BLK_DEV_LVM
 
 endmenu


Christoph

-- 
Always remember that you are unique.  Just like everyone else.
-
To unsubscribe from this list: send 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: [KBUILD] PATCH 2.4.0.9.8: support for external module building

[Jeff Garzik]

On Mon, 2 Oct 2000, Christoph Hellwig wrote:
> Could you change module.mak to use a new-style syntax (obj-foo).
> We'd like to get rid of the old *_OBJS stuff as soon as possible.
> (Or let Olaf do it ;).

module.mak?  That is just the file that contains the build settings.

In any case I don't think that obj-foo is useful here, since external
Makefiles aren't going to be referencing kernel CONFIG_xxx options.

Feel free to post an incremental patch which proves me wrong


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/

problems with 2.4.0-test8

[Richard Polton]

 Hi,
 
 I am using 2.4.0-test8 on an i686 laptop. I find that netscape-4.72
 keeps locking up. I am not able to kill the process at all (without
 a reboot, and SysRQ cannot do a sync on the partition it is running
 in either). I have been advised that RvR's memory patches will fix
 this but I have yet to try. (This behaviour also can be seen with
 ppp-2.4.0, which is a trifle irritating 8-)
 
 Thanks,
 Richard
-
To unsubscribe from this list: send 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-test9-pre8, usb, unresolved symbols

[f5ibh]

Hi!

While doing modprobe hid or modprobe usb-uhci, I get the following unresolved
symbols. Config is P200MMX, 64Mb SDRAM.

-- Versions installed: (if some fields are empty or look
-- unusual then possibly you have very old versions)
Linux debian-f5ibh 2.4.0-test9 #1 lun oct 2 14:44:11 CEST 2000 i586 unknown
Kernel modules 2.3.16
Gnu C  2.95.2
Binutils   2.9.5.0.41
Linux C Library2.1.3
Dynamic linker ldd: version 1.9.11
Linux C++ Library  2.9.
Procps 2.0.6
Mount  2.10o
Net-tools  2.05
Console-tools  0.2.3
Sh-utils   2.0
Modules Loaded nls_iso8859-1 ide-cd cdrom isofs parport_pc lp parport input 
autofs4 rtc serial isa-pnp unix



/lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: unresolved symbol usb_deregister
/lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: unresolved symbol usb_set_idle
/lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: unresolved symbol 
__usb_get_extra_descriptor
/lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: unresolved symbol usb_register
/lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: unresolved symbol usb_set_protocol
/lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: unresolved symbol usb_string
/lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: unresolved symbol 
usb_get_class_descriptor
/lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: unresolved symbol usb_submit_urb
/lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: unresolved symbol usb_unlink_urb
/lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: insmod 
/lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o failed
/lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: insmod hid failed
/lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: unresolved symbol 
usb_claim_bandwidth
/lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: unresolved symbol 
usb_release_bandwidth
/lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: unresolved symbol 
usb_check_bandwidth
/lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: unresolved symbol usb_alloc_bus
/lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: unresolved symbol usb_free_dev
/lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: unresolved symbol 
usb_inc_dev_use
/lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: unresolved symbol 
usb_deregister_bus
/lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: unresolved symbol 
usb_disconnect
/lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: unresolved symbol usb_connect
/lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: unresolved symbol 
usb_new_device
/lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: unresolved symbol 
usb_root_hub_string
/lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: unresolved symbol usb_alloc_dev
/lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: unresolved symbol 
usb_register_bus
/lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: unresolved symbol usb_free_bus
/lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: insmod 
/lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o failed
i/lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: insmod usb-uhci failed

-
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: Soft-Updates for Linux ?

[Daniel Phillips]

"Albert D. Cahalan" wrote:
> 
> Robert Redelmeier writes:
> > Daniel Phillips wrote in part:
> 
> >> One thing to keep in mind in all of this is: nobody is testing the
> >> reliability of their journalling or any other kind of filesystem just by
> >> running it.  To test these things you have to crash/interrupt the system
> >> *a lot*.  Otherwise, you are just fooling yourself and everybody else.
> >> How many crashes does it take to find that one little window of
> >> vulnerability that comes up every 10,000 crashes normally but suddenly
> >> starts coming up every time just because your customer uses their system
> >> a different way?  You're doing the right thing by crash-testing it, now
> >> instead of doing it 5 times do it 1,000 times.  Here's one of my
> >> favorite tests: unzip a kernel source tree and wait until the disk light
> >> goes out.  A second or so after it comes on again (kflushd) hit the
> >> reset button.
> >
> > Good idea.  I certainly believe in stressing hardware (see .sig),
> > but I'm not sure this test is rigorous enough.  The problem is
> > the reset button is only connected to the CPU and the hard disk
> > will probably continue to write out sectors from it's hw buffer.
> > OTOH, I don't like the idea of pulling the plug too often.  It's
> > very hard on the hardware.  I'd expect a mechanical disk failure
> > before 10,000 cycles.
> 
> The nice way to develop this code is with a block device that
> discards all writes after a timer goes off.

And it has to stop the filesystem processing somehow and convince the hd
to discard its write cache.

Somebody should write a crash-simulator along those lines and do some
real head-to-head comparisons amongst the various candidates for the
"most reliable filesystem" crown.  Doing a million simulated crashes
under controlled conditions might not catch every possible thing that
could go wrong but it would sure help remove the subjective opinion
element.  I think it would spur on development too because we'd have a
real yardstick to measure progress against.

The tricky part of the crash simulator would be recovering the resources
the filesystem was using and convincing the VFS to let go of the the
partition.  If you could return the system to a stable state you could
do many, many more test runs in the same time.  Maybe VMWare could help
here.

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

Re: 2.4.0-test9-pre8

[Mike Galbraith]

On Mon, 2 Oct 2000, Rik van Riel wrote:

> On Sun, 1 Oct 2000, Linus Torvalds wrote:
> 
> > Last pre-kernel - I'll do the real test9 before I fly off to
> > Germany on Tuesday.
> 
> >  - pre8:
> > - quintela: fix the synchronous wait on kmem_cache_shrink().
> >   This should fix the mmap02 lockup.
> 
> It probably doesn't. People will want to apply my patch
> (on http://www.surriel.com/patches/) to -test9-pre8 to
> see if that really makes the box solid.
> 
> Testing volunteers: it looks like you have one whole day
> to really stress-test the crap out of my patch so Linus
> can have a bit of certainty the patch he'll (maybe) apply
> really works ;)

I'm not done applying hot pokers and such, but have kicked it
in the.. lower abdomen hard enough to feel comfortable saying
'works for me'.

Noticed a couple of warnings, and missing UnlockPage() thingy
in buffer.c was forgotten.

-Mike

P.S. my address is bogus (f-word provider) but I must use it to
get mail out of this _brokedick_ domain. cc [EMAIL PROTECTED] if
replying please (provider's _old_ domain is bent, but works;).

-
To unsubscribe from this list: send 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: Soft-Updates for Linux ?

[Andi Kleen]

On Mon, Oct 02, 2000 at 03:33:54PM +0200, Daniel Phillips wrote:
> The tricky part of the crash simulator would be recovering the resources
> the filesystem was using and convincing the VFS to let go of the the
> partition.  If you could return the system to a stable state you could
> do many, many more test runs in the same time.  Maybe VMWare could help
> here.

User-Mode-Linux would probably be the better choice. You simply crash the
kernel with a few kills. 

It is also free unlike VMWare.

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

Re: problems with 2.4.0-test8

[Petko Manolov]

Richard Polton wrote:
> 
>  Hi,
> 
>  I am using 2.4.0-test8 on an i686 laptop. I find that netscape-4.72
>  keeps locking up. I am not able to kill the process at all (without
>  a reboot, and SysRQ cannot do a sync on the partition it is running
>  in either). I have been advised that RvR's memory patches will fix
>  this but I have yet to try. (This behaviour also can be seen with
>  ppp-2.4.0, which is a trifle irritating 8-)


I have the same kind of problems with 2.4.0-test8, test-9-pre[678].

I'd thought it is due to bug in my (usb pegasus) driver which i used
most of the time. But i got the same crash with eepro100 which is
considered to be fairly solid.

The bug appears when netscape tries to switch the windows or open new
one. I'm afraid the newest RvR's MM code is not so stable.


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

[Fwd: How Close if 2.4 to Final Release]

[Jeff V. Merkey]

This is probably a public issue, so I am posting to the list instead.

Jeff



Linus,

How close is 2.4 to final release.  Looks like only level II bugs left
from the postings I've been following, and few show stoppers there to
prevent release.  Customers are starting to ask, BTW (although you are a
bastard and don't care about customers, at least you said so, but I
thought I would ask).

:-)

Jeff

Re: Anyone working on multi-threaded core files for 2.4 ?

[James Cownie]

> Queueing the tcores in the mm_struct could work though. Add a prctl [1]
> that enables tcore core dumping. When tcore core dumping is enabled every
> core dump that would dump a mm_struct with reference count > 1 does not
> actually dump it, but just queues a structure (tqueue) with its registers/
> signal info/etc.  into a list in the mm_struct. When a thread dumps and 
> the mm_struct count is 1 then dump a normal core file with all the tcores 
> as thread notes. Also clean up all the cores then when freeing the mm_struct.

What is your model for the scope of this prctl ?

Should it be on a per-thread (OK, Alexander, "per process sharing the
same MM") basis, or does it apply to all members of the thread_group ?

It seems to me that it makes no sense unless
1) it applies to all members of the thread_group
   (because without this the ref count on the mm will never get to
   zero).
2) if it applies we also ensure that core dump signals get sent to all
   members of the thread_group.
   (because without this the other threads won't exit).

At the moment (test9-pre7) there seems to be no code in the kernel to
cause the core dumping signals to be fanned out. But then there seems
to be no code to cause any signals (even the negative "deliver to
thread group" ones) to be fanned out. I assume that's because it's
still work in progress.

(Yes, I know that linuxthreads does it from outside the kernel, but I
was under the impression that the aim of the thread_group was to make
it work better, and if we're going to do multi-threaded core files it
seems that distributing the core dumping signals inside the kernel
is essential).

Just to reiterate what I and, I think, some of the other folks who've
written the existing patches are trying to achieve :-

1) We want to provide multi-threaded core files for pthread programs,
   where the user _expects_ a core dump signal to terminate all of the
   threads in the process and the process itself as soon "as
   possible".

2) We don't want to affect programs which are using the full linux
   threads model. If it makes no sense to attempt to write a
   multi-threaded core dump from such a process that's fine. People who
   are using this model probably don't want such a thing anyway.

The "itch" I'm trying to scratch is the complaints we get from our
customers saying that our debugger doesn't work because it won't
provide them with any useful information from the core files they get
from their pthreaded codes when running on Linux. I don't like having
to explain that it's a kernel "feature" :-( so I'm trying to fix it
(or, at least, help other people to do do).

-- Jim 

James Cownie<[EMAIL PROTECTED]>
Etnus, LLC. +44 117 9071438
http://www.etnus.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/

hdparm -d 1 fail test9-pre8

[Mike Galbraith]

Greetings,

In order for hdparm -d 1 to work in test9-pre8, I had to reverse
this change.  (Without being able to enable dma, performance here
is muy el-stinko;-)  Is enabling dma manually now forbidden? (or
am I maybe missing something else?)

diff -urN linux-2.4.0-test9-pre7/drivers/ide/ide-pci.c 
linux-2.4.0-test9-pre8/drivers/ide/ide-pci.c
--- linux-2.4.0-test9-pre7/drivers/ide/ide-pci.cSun Jul 30 06:30:13 2000
+++ linux-2.4.0-test9-pre8/drivers/ide/ide-pci.cMon Oct  2 10:11:36 2000
@@ -538,7 +538,7 @@
 * Can we trust the reported IRQ?
 */
pciirq = dev->irq;
-   if ((dev->class & ~(0xfa)) != ((PCI_CLASS_STORAGE_IDE << 8) | 5)) {
+   if ((dev->class & ~(0xff)) != (PCI_CLASS_STORAGE_IDE << 8)) {
printk("%s: not 100%% native mode: will probe irqs later\n", d->name);
/*
 * This allows offboard ide-pci cards the enable a BIOS,

>From dmesg:
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c596b IDE UDMA66 controller on pci0:7.1
ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xe008-0xe00f, BIOS settings: hdc:DMA, hdd:pio
hda: IBM-DJNA-352030, ATA DISK drive
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
hdc: MATSHITADVD-ROM SR-8583A, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 39876480 sectors (20417 MB) w/1966KiB Cache, CHS=2482/255/63, UDMA(33)
hdc: ATAPI 32X DVD-ROM drive, 512kB Cache, DMA

please cc [EMAIL PROTECTED], as [EMAIL PROTECTED] is nothing but a
mail black-hole. (provider must be trying to trim his customer base:)

-Mike

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

Re: 2.2.18pre14 msdos mounted filesystems now in uppercase?

[Alan Cox]

> -   opts->small_letter = 0;
> +   opts->small_letter = 1;
> opts->iocharset = NULL;
> *debug = *fat = 0;
> 
> then msdos mounts work as they used to but vfat mounts are also
> affected. I suspect someone didn't consider all the possibilities.
> In any event, breaking long-standing behavior (at least as far back as
> 1.2 kernels) seems like a bad idea.

Definitely. I've already fixed the default back, and added 'big' to undo
small

-
To unsubscribe from this list: send 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: hdparm -d 1 fail test9-pre8

[Jeff Garzik]

On Mon, 2 Oct 2000, Mike Galbraith wrote:
> In order for hdparm -d 1 to work in test9-pre8, I had to reverse
> this change.  (Without being able to enable dma, performance here
> is muy el-stinko;-)  Is enabling dma manually now forbidden? (or
> am I maybe missing something else?)

If this change broke your DMA enabling, I think there are other bugs
lurking in the code...

Can you provide a "diff -u " of dmesg, output, with, and without the
change below?

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: Alan, are you out there?!

[David Weinehall]

On Mon, Oct 02, 2000 at 11:46:00AM +0100, Alan Cox wrote:
> I haven't seen them, but if the filter bounced them you'd have got an
> error back.

e92AXfi08746  554 691240 Oct  2 12:33 <[EMAIL PROTECTED]>
 (Deferred: Connection reset by
lightning.swansea.uk.linux.org.)

<[EMAIL PROTECTED]>

There were also some notes about read errors etc.


/David
  _ _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/http://www.tux.org/lkml/

Re: Anyone working on multi-threaded core files for 2.4 ?

[Andi Kleen]

On Mon, Oct 02, 2000 at 03:10:10PM +0100, James Cownie wrote:
> 
> > Queueing the tcores in the mm_struct could work though. Add a prctl [1]
> > that enables tcore core dumping. When tcore core dumping is enabled every
> > core dump that would dump a mm_struct with reference count > 1 does not
> > actually dump it, but just queues a structure (tqueue) with its registers/
> > signal info/etc.  into a list in the mm_struct. When a thread dumps and 
> > the mm_struct count is 1 then dump a normal core file with all the tcores 
> > as thread notes. Also clean up all the cores then when freeing the mm_struct.
> 
> What is your model for the scope of this prctl ?
> 
> Should it be on a per-thread (OK, Alexander, "per process sharing the
> same MM") basis, or does it apply to all members of the thread_group ?

It should be per thread and inherited to childs but cleared on exec.
(this way the original thread or the thread manager could set it in 
LinuxThreads). 

> 
> It seems to me that it makes no sense unless
> 1) it applies to all members of the thread_group
>(because without this the ref count on the mm will never get to
>zero).

In this case the tcore information would be lost. If you don't
want that don't enable the prctl.

> 2) if it applies we also ensure that core dump signals get sent to all
>members of the thread_group.
>(because without this the other threads won't exit).

With the prctl you told the kernel that you are comitted to that.


> 
> At the moment (test9-pre7) there seems to be no code in the kernel to
> cause the core dumping signals to be fanned out. But then there seems
> to be no code to cause any signals (even the negative "deliver to
> thread group" ones) to be fanned out. I assume that's because it's
> still work in progress.

I see no problem in doing it in user space. It works fine there.
There are potential applications of the Linux clone threads model where 
you don't want to kill the other threads (e.g. when you have a 
object database that does its own object paging using SIGSEGV) 



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

test9-pre8 doesn't compile Reiserfs-3.6.17

[Steven Cole]

I just tried out 2.4.0-test9-pre8, and Reiserfs-3.6.17 didn't get compiled
during the make.  Up through test9-pre7 (pre2, pre5), this has worked smoothly. 

In all cases, I apply the linux-2.4.0-test8-reiserfs-3.6.17-patch after the
test9-preX patch.

I initially configured using make xconfig, and then tried using an old .config
from prior to test9-pre8 with the same results.  And yes, I have both
CONFIG_EXPERIMENTAL=y and obviously CONFIG_REISERFS_FS=y in my .config file.

The file .hdepend has all the same references to reiserfs as the prior
test9-preX versions which worked perfectly.

Any help will be appreciated.  I've posted this to the reiserfs list as well,
but on the chance that this is a more general problem, I'm posting it here.

With kind regards,

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

makefile bash2 typo (Re: We interrupt you regularly scheduled catfight for.. Linux 2.2.18pre13)

[Clayton Weaver]

   
> []   
> Another problem in Makefile. I guess this change between pre 12 and 13
> is a typo:

>  CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
>  - else if [ -x /bin/bash ]; then echo /bin/bash; \
>  + else if [ -x /bin/bash ]; then echo /bin/bash2; \
>else echo sh; fi ; fi)
> []   
   

What is the second "fi" for?

Regards,

Clayton Weaver

(Seattle)

"Everybody's ignorant, just in different subjects."  Will Rogers



-
To unsubscribe from this list: send 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: Where to obtain the latest test kernels

[Admin Mailing Lists]

i thought they were versus 2.2.17pre20 ?

-Tony
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco   Network Administrator/Engineer
[EMAIL PROTECTED]   Intergrafix Internet Services

"Dream as if you'll live forever, live as if you'll die today"
http://www.asteroid-b612.orghttp://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.

On Sat, 30 Sep 2000, Alan Cox wrote:

> > I am interested in testing the 2.2.18pre12 kernel.  Where do I
> > find the source code.  Checking ftp.kernel.org, it only goes to 2.2.17,
> > the latest stable release.  Following several mirror sites gave only the
> > same.  
> 
> ftp://ftp.*.kernel.org/pub/linux/kernel/people/alan/...
> 
> Each patch is versus 2.2.17 so you only need the latest one
> 
> Alan
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
> 

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

RAID patches

[Anil kumar]

Hi,
 I am looking for RAID patches .Please suggest where
can I get these patches.

with regards,
  Anil

__
Do You Yahoo!?
Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free!
http://photos.yahoo.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

PROBLEM: PPPD CRASH

[Lucien Rocha]

 
[2.]
The problem is described in 5., i only got this 
problem with this new kernel. Before i upgrade i was using kernel 2.2.14cl and 
ppp runs nice, but i got problems with sound VIA-chipset(like in docs), then, i 
decided to upgrade, with this kernel(2.2.17) my sound works fine, but ppp 
crashs, i´ve tried to compile the kernel 2.2.16 and got problems with ppp 
too...
 
 
 
[4.]  Linux krypton 2.2.17 #9 Sun Oct 1 
11:24:29 BRST 2000 i586 unknown
 
[5.]
Sep 25 11:35:56 krypton kernel: Lucent Modem driver 
version 4.27.5.66 with MANY_PORTS MULTIPORT SHARE_IRQ enabledSep 25 11:35:56 
krypton kernel: ttyS14 at 0x1400 (irq = 9) is a LucentSep 25 11:36:50 
krypton PAM_pwdb[498]: (login) session opened for user root by (uid=0)Sep 25 
11:37:00 krypton kernel: CSLIP: code copyright 1989 Regents of the University of 
CaliforniaSep 25 11:37:00 krypton kernel: PPP: version 2.3.7 (demand 
dialling)Sep 25 11:37:00 krypton kernel: PPP line discipline 
registered.Sep 25 11:37:00 krypton kernel: registered device ppp0Sep 25 
11:37:00 krypton pppd[544]: pppd 2.3.11 started by root, uid 0Sep 25 
11:37:39 krypton pppd[544]: Serial connection established.Sep 25 11:37:39 
krypton pppd[544]: Using interface ppp0Sep 25 11:37:39 krypton pppd[544]: 
Connect: ppp0 <--> /dev/modemSep 25 11:37:40 krypton kernel: Unable to 
handle kernel paging request at virtual address 6000Sep 25 11:37:40 
krypton kernel: current->tss.cr3 = 010a7000, %%cr3 = 010a7000Sep 25 
11:37:40 krypton kernel: *pde = Sep 25 11:37:40 krypton kernel: 
Oops: 0002Sep 25 11:37:40 krypton kernel: CPU:    0Sep 25 
11:37:40 krypton kernel: EIP:    
0010:[fat:fat_esc2uni_Rdf8b5a1e+215633/92772019]Sep 25 11:37:40 krypton 
kernel: EFLAGS: 00010012Sep 25 11:37:40 krypton kernel: eax: 
0fff   ebx: 002d   ecx: 000b   edx: 
1000Sep 25 11:37:40 krypton kernel: esi: c1bac238   edi: 
6000   ebp: c1bac000   esp: c10abeccSep 25 11:37:40 
krypton kernel: ds: 0018   es: 0018   ss: 0018Sep 25 
11:37:40 krypton kernel: Process pppd (pid: 544, process nr: 21, 
stackpage=c10ab000)Sep 25 11:37:40 krypton kernel: Stack: 0001 c1bac000 
0286  c208ee77 c1199000  c1bac238 Sep 25 11:37:40 
krypton kernel:    002d c1bac000 
c18cd480 c1860680 c208ed94 c1bac000 c021 c2090fff Sep 25 11:37:40 
krypton kernel:    c1bac000 c1860680 
c1bac020 c1bac000 c1bac020 c18cd480 0018 c20912f3 Sep 25 11:37:40 
krypton kernel: Call Trace: [fat:fat_esc2uni_Rdf8b5a1e+500023/92487629] 
[fat:fat_esc2uni_Rdf8b5a1e+499796/92487856] 
[fat:fat_esc2uni_Rdf8b5a1e+508607/92479045] 
[fat:fat_esc2uni_Rdf8b5a1e+509363/92478289] 
[fat:fat_esc2uni_Rdf8b5a1e+497979/92489673] [tty_write+458/528] 
[fat:fat_esc2uni_Rdf8b5a1e+497736/92489916] Sep 25 11:37:40 krypton 
kernel:    [sys_write+219/256] 
[tty_write+0/528] [system_call+52/56] Sep 25 11:37:40 krypton kernel: Code: 
f3 a5 f6 c3 02 74 02 66 a5 f6 c3 01 74 01 a4 89 d8 03 45 5c Sep 25 11:37:40 
krypton kernel: Unable to handle kernel NULL pointer dereference at virtual 
address 0014Sep 25 11:37:40 krypton kernel: current->tss.cr3 = 
00101000, %%cr3 = 00101000Sep 25 11:37:40 krypton kernel: *pde = 
Sep 25 11:37:40 krypton kernel: Oops: Sep 25 11:37:40 
krypton kernel: CPU:    0Sep 25 11:37:40 krypton kernel: 
EIP:    0010:[fat:fat_esc2uni_Rdf8b5a1e+220968/92766684]Sep 
25 11:37:40 krypton kernel: EFLAGS: 00010286Sep 25 11:37:40 krypton kernel: 
eax: c1199000   ebx:    ecx: c1199000   
edx: 0012Sep 25 11:37:40 krypton kernel: esi: c1199000   edi: 
c1199100   ebp: 0001   esp: c10abdc8Sep 25 11:37:40 
krypton kernel: ds: 0018   es: 0018   ss: 0018Sep 25 
11:37:40 krypton kernel: Process pppd (pid: 544, process nr: 21, 
stackpage=c10ab000)Sep 25 11:37:40 krypton kernel: Stack: c0196ee9 c1199000 
c1199000 0220 c10aa000 0001 c1199000  Sep 25 11:37:40 
krypton kernel:    c0196f32 c1199000 
c0196fa7 c1199000  c10aa000 c10aa000 c10aa000 Sep 25 11:37:40 
krypton kernel:    c01178c5 0001 
0296 c10aa000 c14e9ac0 c10abe3c c0117af3 c10abe90 Sep 25 11:37:40 
krypton kernel: Call Trace: [do_tty_hangup+637/648] [tty_vhangup+10/16] 
[disassociate_ctty+91/212] [exit_notify+461/472] [do_exit+547/616] 
[die_if_no_fixup+0/64] [error_table+2646/9568] Sep 25 11:37:40 krypton 
kernel:    [error_table+9294/9568] 
[do_page_fault+708/944] [error_table+9294/9568] [error_code+45/52] 
[fat:fat_esc2uni_Rdf8b5a1e+215633/92772019] 
[fat:fat_esc2uni_Rdf8b5a1e+500023/92487629] 
[fat:fat_esc2uni_Rdf8b5a1e+499796/92487856] 
[fat:fat_esc2uni_Rdf8b5a1e+508607/92479045] Sep 25 11:37:40 krypton 
kernel:    
[fat:fat_esc2uni_Rdf8b5a1e+509363/92478289] 
[fat:fat_esc2uni_Rdf8b5a1e+497979/92489673] [tty_write+458/528] 
[fat:fat_esc2uni_Rdf8b5a1e+497736/92489916] [sys_write+219/256] 
[tty_write+0/528] [system_call+52/56] Sep 25 11:37:40 krypton kernel: Code: 
8b 73 14 50 e8 bb eb ff ff 53 e8 19 e3 ff ff c7 43 40 00 00 Sep 25 11:38:07 
krypton PAM_pwdb[499]: (login

Re: RAID patches

[John Levon]

On Mon, 2 Oct 2000, Anil kumar wrote:

> Hi,
>  I am looking for RAID patches .Please suggest where
> can I get these patches.
> 
> with regards,
>   Anil
> 

Try Ingo Molnar's directory, linked from http://kernelnewbies.org/patches/

if you find somewhere else, please tell me

thanks
john

-- 
"Perl does one thing, and does it well. What it does well 
 is to integrate all its features into one language."
- Larry Wall

-
To unsubscribe from this list: send 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-test9-pre8, usb, unresolved symbols

[Dunlap, Randy]

Hi,

> From: f5ibh [mailto:[EMAIL PROTECTED]]
> 
> Hi!
> 
> While doing modprobe hid or modprobe usb-uhci, I get the 
> following unresolved
> symbols. Config is P200MMX, 64Mb SDRAM.

All of the missing symbols are in usb.o (usbcore.o module or
usbdrv.o in-kernel).  Is usbcore.o loaded or do you have
/etc/modules.conf setup to load it automatically?
Did you run depmod after 'make modules_install' ?

~Randy


> -- Versions installed: (if some fields are empty or look
> -- unusual then possibly you have very old versions)
> Linux debian-f5ibh 2.4.0-test9 #1 lun oct 2 14:44:11 CEST 
> 2000 i586 unknown
> Kernel modules 2.3.16
> Gnu C  2.95.2
> Binutils   2.9.5.0.41
> Linux C Library2.1.3
> Dynamic linker ldd: version 1.9.11
> Linux C++ Library  2.9.
> Procps 2.0.6
> Mount  2.10o
> Net-tools  2.05
> Console-tools  0.2.3
> Sh-utils   2.0
> Modules Loaded nls_iso8859-1 ide-cd cdrom isofs 
> parport_pc lp parport input autofs4 rtc serial isa-pnp unix
> 
> 
> 
> /lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: unresolved 
> symbol usb_deregister
> /lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: unresolved 
> symbol usb_set_idle
> /lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: unresolved 
> symbol __usb_get_extra_descriptor
> /lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: unresolved 
> symbol usb_register
> /lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: unresolved 
> symbol usb_set_protocol
> /lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: unresolved 
> symbol usb_string
> /lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: unresolved 
> symbol usb_get_class_descriptor
> /lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: unresolved 
> symbol usb_submit_urb
> /lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: unresolved 
> symbol usb_unlink_urb
> /lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: insmod 
> /lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o failed
> /lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o: insmod hid failed
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> unresolved symbol usb_claim_bandwidth
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> unresolved symbol usb_release_bandwidth
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> unresolved symbol usb_check_bandwidth
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> unresolved symbol usb_alloc_bus
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> unresolved symbol usb_free_dev
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> unresolved symbol usb_inc_dev_use
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> unresolved symbol usb_deregister_bus
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> unresolved symbol usb_disconnect
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> unresolved symbol usb_connect
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> unresolved symbol usb_new_device
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> unresolved symbol usb_root_hub_string
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> unresolved symbol usb_alloc_dev
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> unresolved symbol usb_register_bus
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> unresolved symbol usb_free_bus
> /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> insmod /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o failed
> i/lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o: 
> insmod usb-uhci failed
> 
> -
> 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: Soft-Updates for Linux ?

[Daniel Phillips]

Andi Kleen wrote:
> 
> On Mon, Oct 02, 2000 at 03:33:54PM +0200, Daniel Phillips wrote:
> > The tricky part of the crash simulator would be recovering the resources
> > the filesystem was using and convincing the VFS to let go of the the
> > partition.  If you could return the system to a stable state you could
> > do many, many more test runs in the same time.  Maybe VMWare could help
> > here.
> 
> User-Mode-Linux would probably be the better choice. You simply crash the
> kernel with a few kills.

I think you are right.  Last time I looked UML didn't support modules
and now it does.  This looks like a really lightweight solution for 90%
of my filesystem development.  I'm starting to get a little bored with
the crash and burn, repeat as necessary approach :-)

> It is also free unlike VMWare.

Yes, that matters to me.  I would have mentioned Plex86 except it's not
quite there yet, though it's looking really good.  I'm really blown away
by what that group is doing - it's like the inside of a transmeta chip. 
They have to work around a lot of extreme braindeadness in the x86
design and they do it by analyzing and rewriting code on the fly, then
they have to make it look like they never did that, in case the code is
checksumming itself, and so on, yikes.

I think VMWare is really a good product, and it's there now.  They make
it really easy for Windows users to get free.  I support them.  If they
are smart they will open up eventually, and if they are not smart, well,
that's what natural selection is for.

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

Re: 2.4.0-test9-pre8

[David Weinehall]

On Mon, Oct 02, 2000 at 01:34:03AM -0300, Rik van Riel wrote:
> On Sun, 1 Oct 2000, Linus Torvalds wrote:
> 
> > Last pre-kernel - I'll do the real test9 before I fly off to
> > Germany on Tuesday.
> 
> >  - pre8:
> > - quintela: fix the synchronous wait on kmem_cache_shrink().
> >   This should fix the mmap02 lockup.
> 
> It probably doesn't. People will want to apply my patch
> (on http://www.surriel.com/patches/) to -test9-pre8 to
> see if that really makes the box solid.
> 
> Testing volunteers: it looks like you have one whole day
> to really stress-test the crap out of my patch so Linus
> can have a bit of certainty the patch he'll (maybe) apply
> really works ;)

Well, I did my best, and without too much trouble I managed to sink the
kernel into a grinding halt. No oops, and it still responded to SysRQ,
but nothing else.

This was with v2.4.0-test9-pre8+your patches.

Oh, and I guess this is for you to fix:

page_alloc.c: In function `__alloc_pages':
page_alloc.c:473: warning: suggest parentheses around comparison in operand of &
page_alloc.c:536: warning: int format, long int arg (arg 2)

(I HATE buildtime warnings.)


/David
  _ _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/http://www.tux.org/lkml/

Re: We interrupt you regularly scheduled catfight for.. Linux 2.2.18pre13

[Pavel Machek]

Hi!

> > Where does the idea that the kernel 'needs' a special compiler 
> > come from ?  I have been under the impression that that is just
> 
> Mostly from the sad fact that it does.
> 
> > what we were trying to get away from .  I am reminded of other
> > os's that required their propritary compiler in order to create
> > a os image .  Please let us not travel that road .  Tia ,  JimL
> 
> Patches are welcome. But keep in mind that we _are_ dependent on a
> particular compiler. gcc, that is. I would be glad to get rid of it - the
> codebase is extremely messy. However, removing gcc-isms is a huge
> work. You are welcome to do it, indeed, but so far nobody had done that.

Actually there's another compiler (codepro or how is it called), made
by SGI(?) for merced, available under gpl, and hving all gcc
extensions, including __asm__().
Pavel
-- 
The best software in life is free (not shareware)!  Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+
-
To unsubscribe from this list: send 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-test9-pre8

[David Weinehall]

Warnings on build with v2.4.0test9pre8 (with Rik van Riel's extra fixes):

parport_pc.c:2283: warning: `parport_pc_superio_info' defined but not used
sg.c: In function `exit_sg':
sg.c:1321: warning: implicit declaration of function `sg_proc_cleanup'
page_alloc.c: In function `__alloc_pages':
page_alloc.c:473: warning: suggest parentheses around comparison in operand of &
page_alloc.c:536: warning: int format, long int arg (arg 2)
buffer.c: In function `balance_dirty_state':
buffer.c:864: warning: unused variable `shortage'
reg_add_sub.c: In function `FPU_sub':
reg_add_sub.c:143: warning: `tag' might be used uninitialized in this function
reg_compare.c: In function `FPU_compare_st_data':
reg_compare.c:177: warning: `f' might be used uninitialized in this function
reg_compare.c: In function `compare_st_st':
reg_compare.c:219: warning: `f' might be used uninitialized in this function
reg_compare.c: In function `compare_u_st_st':
reg_compare.c:271: warning: `f' might be used uninitialized in this function
reg_ld_str.c: In function `FPU_store_single':
reg_ld_str.c:635: warning: `templ' might be used uninitialized in this function
reg_divide.c: In function `FPU_div':
reg_divide.c:206: warning: control reaches end of non-void function
reg_mul.c: In function `FPU_mul':
reg_mul.c:131: warning: control reaches end of non-void function
bbootsect.s: Assembler messages:
bbootsect.s:842: Warning: indirect lcall without `*'
bsetup.s: Assembler messages:
bsetup.s:1126: Warning: indirect lcall without `*'


The parport thing is because I don't use PCI, I suppose, and fixes for
the sg.c and buffer.c warnings are attached. I won't go anywhere near the
fpu emulation code however, and the assembler warnings might be due to
having too old binutils; I'm not sure.


/David Weinehall
  _ _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/

--- linux-2.4.0test9pre8rielvmpatch/drivers/scsi/sg.c.old   Mon Oct  2 17:11:11 
2000
+++ linux-2.4.0test9pre8rielvmpatch/drivers/scsi/sg.c   Mon Oct  2 17:12:18 2000
@@ -1318,7 +1318,9 @@
 static void __exit exit_sg( void)
 {
 #ifdef CONFIG_PROC_FS
+#ifdef MODULE
 sg_proc_cleanup();
+#endif  /* MODULE */
 #endif  /* CONFIG_PROC_FS */
 scsi_unregister_module(MODULE_SCSI_DEV, &sg_template);
 devfs_unregister_chrdev(SCSI_GENERIC_MAJOR, "sg");


--- linux-2.4.0test9pre8rielvmpatch/fs/buffer.c.old Mon Oct  2 17:06:09 2000
+++ linux-2.4.0test9pre8rielvmpatch/fs/buffer.c Mon Oct  2 17:06:16 2000
@@ -861,7 +861,6 @@
 int balance_dirty_state(kdev_t dev)
 {
unsigned long dirty, tot, hard_dirty_limit, soft_dirty_limit;
-   int shortage;
 
dirty = size_buffers_type[BUF_DIRTY] >> PAGE_SHIFT;
tot = nr_free_buffer_pages();

Re: makefile bash2 typo (Re: We interrupt you regularly scheduled catfight for.. Linux 2.2.18pre13)

[Tim Waugh]

On Mon, Oct 02, 2000 at 07:47:54AM -0700, Clayton Weaver wrote:

> What is the second "fi" for?

The first "if".

Tim.
*/

 PGP signature

Re: 2.4.0-test9-pre8

[Jeff Garzik]

On Mon, 2 Oct 2000, David Weinehall wrote:

> Warnings on build with v2.4.0test9pre8 (with Rik van Riel's extra fixes):
> 
> parport_pc.c:2283: warning: `parport_pc_superio_info' defined but not used

.config dependent I think.


> sg.c: In function `exit_sg':
> sg.c:1321: warning: implicit declaration of function `sg_proc_cleanup'

This is definitely wrong...


--- linux-2.4.0test9pre8rielvmpatch/drivers/scsi/sg.c.old   Mon Oct  2 
17:11:11 2000
+++ linux-2.4.0test9pre8rielvmpatch/drivers/scsi/sg.c   Mon Oct  2 17:12:18 
2000
@@ -1318,7 +1318,9 @@
 static void __exit exit_sg( void)
 {
 #ifdef CONFIG_PROC_FS
+#ifdef MODULE
 sg_proc_cleanup();
+#endif  /* MODULE */
 #endif  /* CONFIG_PROC_FS */
 scsi_unregister_module(MODULE_SCSI_DEV, &sg_template);
 devfs_unregister_chrdev(SCSI_GENERIC_MAJOR, "sg");

  [ Part 3: "Attached Text" ]



-
To unsubscribe from this list: send 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: sigtimedwait with a zero timeout

[James Antill]

Henrik Nordstrom <[EMAIL PROTECTED]> writes:

> You are not late. In fact you are the first who have responded to my
> linux-kernel messages at all.
> 
> Yes, I am well aware of sigwaitinfo.
> 
> sigwaitinfo blocks infinitely if there is no queued signals and is the
> opposite of sigtimedwait with a zero timeout.

 Yes, sorry that's what I thought you wanted to do (Ie. you new some
data was there and wanted to get it quickly).

> sigwaitinfo is implemented as sigtimedwait with a NULL timeout which is
> read as a timeout of MAX_SCHEDULE_TIMEOUT.

 Ahh I didn't know that.

> sigtimedwait with a zero timeout are meant to be used by applications
> needing to poll signal queues while doing other processing. Having
> sigtimedwait always block for at least 10 ms can have a quite negative
> impact on such applications.

 If you want to return imediatley (and there might not be data) the
answer given is usually...

 sigqueue( ... );
 sigwaitinfo( ... );

 If the above will still schedule, then Linus might be more likely to
take a patch (I'd guess that he'd look at sigtimedwait() to be like
sleep() in most other cases though). 

-- 
James Antill -- [EMAIL PROTECTED]
"If we can't keep this sort of thing out of the kernel, we might as well
pack it up and go run Solaris." -- Larry McVoy.
-
To unsubscribe from this list: send 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-test9-pre8

[David Weinehall]

On Mon, Oct 02, 2000 at 10:26:20AM -0500, Jeff Garzik wrote:
> On Mon, 2 Oct 2000, David Weinehall wrote:
> 
> > Warnings on build with v2.4.0test9pre8 (with Rik van Riel's extra fixes):
> > 
> > parport_pc.c:2283: warning: `parport_pc_superio_info' defined but not used
> 
> .config dependent I think.

Yes, as I said, I don't use PCI. That struct is only used by PCI-stuff.
Actually, most of the code in that file is.

> > sg.c: In function `exit_sg':
> > sg.c:1321: warning: implicit declaration of function `sg_proc_cleanup'
> 
> This is definitely wrong...

Uhm. Probably, I just had a brief look at it. Still, sg_proc_cleanup is
only defined when MODULE is defined, so something else is broken if this
patch is incorrect. There are quite a lot of #ifdef MODULE in that file.

> --- linux-2.4.0test9pre8rielvmpatch/drivers/scsi/sg.c.old   Mon Oct  2 
> 17:11:11 2000
> +++ linux-2.4.0test9pre8rielvmpatch/drivers/scsi/sg.c   Mon Oct  2 17:12:18 
> 2000
> @@ -1318,7 +1318,9 @@
>  static void __exit exit_sg( void)
>  {
>  #ifdef CONFIG_PROC_FS
> +#ifdef MODULE
>  sg_proc_cleanup();
> +#endif  /* MODULE */
>  #endif  /* CONFIG_PROC_FS */
>  scsi_unregister_module(MODULE_SCSI_DEV, &sg_template);
>  devfs_unregister_chrdev(SCSI_GENERIC_MAJOR, "sg");


/David
  _ _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/http://www.tux.org/lkml/

Re: hdparm -d 1 fail test9-pre8

[Ivan Kokshaysky]

On Mon, Oct 02, 2000 at 09:24:58AM -0500, Jeff Garzik wrote:
> If this change broke your DMA enabling, I think there are other bugs
> lurking in the code...
> 
This change also broke CMD646 IDE on alpha lx164.

CMD646: IDE controller on PCI bus 00 dev 58
CMD646: chipset revision 1
CMD646: chipset revision 0x01, MultiWord DMA Limited, IRQ workaround enabled
CMD646: 100% native mode on irq 21
ide0: BM-DMA at 0x9000-0x9007, BIOS settings: hda:pio, hdb:DMA
ide1: BM-DMA at 0x9008-0x900f, BIOS settings: hdc:pio, hdd:pio
hdb: ATAPI CD-ROM DRIVE 40X MAXIMUM, ATAPI CDROM drive
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ide0 at 0x1f0-0x1f7,0x3f6 on irq 21

No IDE interrupts...
With the change reverted:

CMD646: IDE controller on PCI bus 00 dev 58
CMD646: chipset revision 1
CMD646: not 100% native mode: will probe irqs later
CMD646: chipset revision 0x01, MultiWord DMA Limited, IRQ workaround enabled
ide0: BM-DMA at 0x9000-0x9007, BIOS settings: hda:pio, hdb:DMA
ide1: BM-DMA at 0x9008-0x900f, BIOS settings: hdc:pio, hdd:pio
hdb: ATAPI CD-ROM DRIVE 40X MAXIMUM, ATAPI CDROM drive
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14

IDE works again.


Ivan.
-
To unsubscribe from this list: send 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] fix for VM test9-pre7

[Rik van Riel]

On Mon, 2 Oct 2000 [EMAIL PROTECTED] wrote:
> On Mon, Oct 02, 2000 at 12:42:47AM -0300, Rik van Riel wrote:
> > --- linux-2.4.0-test9-pre7/fs/buffer.c.orig Sat Sep 30 18:09:18 2000
> > +++ linux-2.4.0-test9-pre7/fs/buffer.c  Mon Oct  2 00:19:41 2000
> > @@ -706,7 +706,9 @@
> >  static void refill_freelist(int size)
> >  {
> > if (!grow_buffers(size)) {
> > -   try_to_free_pages(GFP_BUFFER);
> > +   wakeup_bdflush(1);
> > +   current->policy |= SCHED_YIELD;
> > +   schedule();
> > }
> >  }
> 
> This part looks strange! wakeup_bdflush will sleep if the
> parameter is not zero, i.e. we'll schedule twice. I doubt that
> this the intended behaviour?

Heh...

I copied back the old code because I saw some failures in
the try_to_free_pages() in this situation.

Maybe the person who wrote this code originally can comment
on this one ?

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/   http://www.surriel.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: We interrupt you regularly scheduled catfight for.. Linux 2.2.18pre13

[Christoph Hellwig]

On Mon, Oct 02, 2000 at 05:17:46PM +0200, Pavel Machek wrote:
> Actually there's another compiler (codepro or how is it called), made
> by SGI(?) for merced, available under gpl, and hving all gcc
> extensions, including __asm__().

SGI Pro64 - it's IA64 only and uses the gcc frontends.
But I doubt that it will compily a kernel correctly ...

Christoph

-- 
Always remember that you are unique.  Just like everyone else.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Bogomip/CPU speed issues

[Alan Cox]

Ted, 
Can you add 'kernel dies with a 2GHZ or faster CPU' to the 2.4 list.
There are most of the needed fixes in 2.2 and 2.4 needs to sort them. People
are at 1.4/1.6GHz already 

Alan

-
To unsubscribe from this list: send 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: iounmap() - can't always unmap memory I've mappedt

[Timur Tabi]

** Reply to message from Alan Cox <[EMAIL PROTECTED]> on Sat, 30 Sep
2000 00:24:43 +0100 (BST)


> > Unfortunately, this mapping is a requirement for our product.  I'd hate to have
> > to create my own pte's and do it all manually.
> 
> If you are doing it at boot time as Id expect then you may need to - the SMP
> code for bootstrapping has to do pte stuff itself for the same reason

No, I'm not doing it at boot time, I'm doing it when my driver loads.  Granted,
the driver will usually by loaded once when the system boots, but it can be
loaded at any time.  I'm trying to make my driver as independent of the kernel
as possible, and I'm 99% there.

Anyway, my original question has not yet been answered: why is it that I can
ioremap() any physical page by simply setting one bit, but I cannot always
iounmap() it?  Why can't iounmap() simply undo what ioremap() did?


-- 
Timur Tabi - [EMAIL PROTECTED]
Interactive Silicon - http://www.interactivesi.com

When replying to a mailing-list message, please don't cc: me, because then I'll just 
get two copies of the same message.
-
To unsubscribe from this list: send 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.2.18] compile on Alpha - loops_per_jiffy

[willy tarreau]

Hi Alan,

2.2.18pre14 compiles and runs on Alpha with the
following patch. It only replaces loops_per_sec with
loops_per_jiffy*HZ. It works for me, although I'm not
totally sure this is quite correct.

BTW, I had to remove nvram and drm to compile. Will
see later why (unknown references to LOCK_PREFIX and
CHECK_DRIVER_INIT).

The loops_per_jiffy patch is attached.

Willy.



___
Do You Yahoo!? -- Pour dialoguer en direct avec vos amis, 
Yahoo! Messenger : http://fr.messenger.yahoo.com
 2.2.18pre14-alpha.diff.gz

Re: Alan, are you out there?!

[David Weinehall]

This should help to analyse the mail-problem, hopefully (again
I ask the rest of the kernellist to forgive me for bringing off-topic
matters to this list, but I can't seem to be able to communicate with
Alan any other way at the moment):

Running /var/spool/mqueue/q3/e92Aogi17072 (sequence 1 of 1)
<[EMAIL PROTECTED]>... Connecting to
lightning.swansea.uk.linux.org. via esmtp...
220 the-village.bc.nu ESMTP Exim 2.12 #1 Mon, 2 Oct 2000 15:32:54
+0100
>>> EHLO kleopatra.acc.umu.se
250-the-village.bc.nu Hello root at kleopatra.acc.umu.se
[130.239.18.150]
250-SIZE
250-PIPELINING
250 HELP
>>> MAIL From:<[EMAIL PROTECTED]> SIZE=602
250 <[EMAIL PROTECTED]> is syntactically correct
>>> RCPT To:<[EMAIL PROTECTED]>
250 <[EMAIL PROTECTED]> is syntactically correct
>>> DATA
354 Enter message, ending with "." on a line by itself
>>> .
421 the-village.bc.nu SMTP incoming data timeout - closing connection.
>>> QUIT
<[EMAIL PROTECTED]>... Deferred: Connection reset by
lightning.swansea.uk.linux.org.
 
 
/var/spool/mqueue/q3# l *e92Aogi17072
-rw---   1 root system   585 Oct 02 12:50 dfe92Aogi17072
-rw---   1 root system  1266 Oct 02 16:36 qfe92Aogi17072


/David
  _ _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/http://www.tux.org/lkml/

Re: iounmap() - can't always unmap memory I've mappedt

[Alan Cox]

> Anyway, my original question has not yet been answered: why is it that I can
> ioremap() any physical page by simply setting one bit, but I cannot always
> iounmap() it?  Why can't iounmap() simply undo what ioremap() did?

The fact you can doesn't mean you should. You need to be sole owner of that
page before you can fiddle with the reserved bit. You were not sole owner

-
To unsubscribe from this list: send 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.18] compile on Alpha - loops_per_jiffy

[Alan Cox]

> following patch. It only replaces loops_per_sec with
> loops_per_jiffy*HZ. It works for me, although I'm not
> totally sure this is quite correct.

loops_per_jiffy*HZ overflows at 2GHz for an int. If the alpha is using ulong
for this I guess it works fine at 64bits.

-
To unsubscribe from this list: send 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: test9-pre8 doesn't compile Reiserfs-3.6.17

[Claudius Link]

On Mon, Oct 02, 2000 at 08:32:45AM -0600, Steven Cole wrote:
> I just tried out 2.4.0-test9-pre8, and Reiserfs-3.6.17 didn't get compiled
> during the make.  Up through test9-pre7 (pre2, pre5), this has worked smoothly. 
With me that was a simple makefile problem
linux/fs/Makefile
changed quit a bit. So you have to add the line
subdir-$(CONFIG_REISERFS_FS)+= reiserfs
somewhere (for example after "subdir-$(CONFIG_JFFS_FS)  += jffs")
then it works fine.

> In all cases, I apply the linux-2.4.0-test8-reiserfs-3.6.17-patch after the
> test9-preX patch.
You should check for rejected files ('find . -name "*.rej"' in the source dir)

regards,
Claudius
-- 

Claudius Link   [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/

ntfs oops report kernel BUG at fs.c:568

[Andre Maasikas]

Hi,

Trying to play a file with mpg123 from ntfs partition got this:
(test9-pre8 and repeatable at least with mpg123, also test9-pre7 gave
similar one. I havent tried this with earlier versions)

Oct  2 17:45:28 eepc08 kernel: kernel BUG at fs.c:568!
Oct  2 17:45:28 eepc08 kernel: invalid operand: 
etc..
from ksymoops:

Warning: You did not tell me where to find symbol information.  I will
...
ac97_codec: AC97  codec, vendor id1: 0x5452, id2: 0x4123 (TriTech TR?)
invalid operand: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010292
eax: 0018   ebx: c63a04e0   ecx: c6c13460   edx: 0004
esi: c88cd990   edi: 0031fd09   ebp:    esp: c6393dd4
ds: 0018   es: 0018   ss: 0018
Process mpg123 (pid: 684, stackpage=c6393000)
Stack: c88d4445 c88d4858 0238 c013072c c63a04e0  c6356f60  
    c6b26de0  c63a057c  c6356f60 c017696c 0009 
   18fe  c01fc378  c6356f60  0200 18fe 
Call Trace: [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] [] 
Code: 0f 0b 83 c4 0c b8 ff ff ff ff c3 90 8b 44 24 08 68 90 d9 8c 

>>EIP; c88cd9a4 <[ntfs]ntfs_get_block+14/20>   <=
Trace; c88d4445 <[ntfs].rodata.start+25/1505>
Trace; c88d4858 <[ntfs].rodata.start+438/1505>
Trace; c013072c 
Trace; c017696c 
Trace; c0122bf4 
Trace; c88cd9d3 <[ntfs]ntfs_readpage+f/14>
Trace; c88cd990 <[ntfs]ntfs_get_block+0/20>
Trace; c0122d0a 
Trace; c0123f63 
Trace; c0120eed 
Trace; c0121040 
Trace; c011216f 
Trace; c0159ac2 
Trace; c011b165 
Trace; c010a67c 
Code;  c88cd9a4 <[ntfs]ntfs_get_block+14/20>
 <_EIP>:
Code;  c88cd9a4 <[ntfs]ntfs_get_block+14/20>   <=
   0:   0f 0b ud2a  <=
Code;  c88cd9a6 <[ntfs]ntfs_get_block+16/20>
   2:   83 c4 0c  add$0xc,%esp
Code;  c88cd9a9 <[ntfs]ntfs_get_block+19/20>
   5:   b8 ff ff ff ffmov$0x,%eax
Code;  c88cd9ae <[ntfs]ntfs_get_block+1e/20>
   a:   c3ret
Code;  c88cd9af <[ntfs]ntfs_get_block+1f/20>
   b:   90nop
Code;  c88cd9b0 <[ntfs]ntfs_writepage+0/14>
   c:   8b 44 24 08   mov0x8(%esp,1),%eax
Code;  c88cd9b4 <[ntfs]ntfs_writepage+4/14>
  10:   68 90 d9 8c 00push   $0x8cd990

1 warning issued.  Results may not be reliable.

modules loaded:
es1371 25876   0
ac97_codec  7748   0  [es1371]
soundcore   3620   4  [es1371]
nls_iso8859-1   2840   1  (autoclean)
ntfs   37128   1  (autoclean)
3c59x  23016   1  (autoclean)
serial 42788   0  (autoclean)

After trying this 2-3 times it usually hangs(cannot kill with ctrl-c)
and after that also ps aux,w and top will hang. sysrq will work
Machine is PIII IDE RedHat 6.2 with some packages updated
My 1st post - don't bash too hard if I got smth wrong 

Andre

-
To unsubscribe from this list: send 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: makefile bash2 typo (Re: We interrupt you regularly scheduled catfight for.. Linux 2.2.18pre13)

[Andreas Schwab]

Tim Waugh <[EMAIL PROTECTED]> writes:

|> On Mon, Oct 02, 2000 at 07:47:54AM -0700, Clayton Weaver wrote:
|> 
|> > What is the second "fi" for?
|> 
|> The first "if".

Btw, the Bourne language also has `elif':

  CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
elif [ -x /bin/bash ]; then echo /bin/bash; \
else echo sh; fi)

Andreas.

-- 
Andreas Schwab  "And now for something
SuSE Labscompletely different."
[EMAIL PROTECTED]
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

PROBLEM: 2.2.17 hangs when attempting to mount atapi cdrom Teac CD-540E

[Serge Gavrilov]

[1.] 2.2.17 hangs when attempting to mount atapi cdrom Teac CD-540E

[2.] My kernel was compiled with flags

CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y

My cdrom Teac CD-540E supports UDMA mode2.
When I try to mount /cdrom kernel hangs.
If I invoke 

hdparm -d0 /dev/hdc

and invoke "mount /cdrom" after, then everything is OK.


[3.] cdrom, dma, atapi

[4.] Kernel version (from /proc/version):

Linux version 2.2.17 (root@galileo) (gcc version 2.95.2 2220 (Debian GNU/Linux)) 
#1 Sun Sep 24 12:55:07 MSD 2000

[5.] 

[6.] 

[7.] 

[7.1.] 

Linux galileo 2.2.17 #1 Sun Sep 24 12:55:07 MSD 2000 i586 unknown
Kernel modules 2.3.11
Gnu C  2.95.2
Binutils   2.9.5.0.37
Linux C Library2.1.3
Dynamic linker ldd: version 1.9.11
Procps 2.0.6
Mount  2.10f
Net-tools  2.05
Console-tools  0.2.3
Sh-utils   2.0
Modules Loaded isofs snd-pcm1-oss lockd snd-mixer-oss sunrpc snd-card-ens1371 
snd-seq-device snd-ens1371 snd-pcm1 snd-timer snd-ac97-codec snd-mixer snd-pcm 
snd-midi snd soundcore nls_koi8-r nls_cp866 vfat fat ne2k-pci 8390

[7.2.] Processor information (from /proc/cpuinfo):
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 5
model   : 4
model name  : Pentium MMX
stepping: 3
cpu MHz : 200.456
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 mmx
bogomips: 399.77

[7.3.] Module information (from /proc/modules):

isofs  17488   1 (autoclean)
snd-pcm1-oss   13192   1 (autoclean)
lockd  30696   1 (autoclean)
snd-mixer-oss   3992   0 (autoclean)
sunrpc 52292   1 (autoclean) [lockd]
snd-card-ens13712568   1
snd-seq-device  3472   1 [snd-card-ens1371]
snd-ens1371 7536   0 [snd-card-ens1371]
snd-pcm1   16956   0 [snd-pcm1-oss snd-ens1371]
snd-timer   7964   0 [snd-pcm1]
snd-ac97-codec 2   0 [snd-ens1371]
snd-mixer  25728   0 [snd-mixer-oss snd-card-ens1371 snd-ac97-codec]
snd-pcm 9068   0 [snd-pcm1-oss snd-card-ens1371 snd-pcm1]
snd-midi   12844   0 [snd-card-ens1371 snd-ens1371]
snd34956   1 [snd-pcm1-oss snd-mixer-oss snd-card-ens1371 
snd-seq-device snd-ens1371 snd-pcm1 snd-timer snd-ac97-codec snd-mixer snd-pcm 
snd-midi]
soundcore   2596   5 [snd]
nls_koi8-r  3368   1 (autoclean)
nls_cp866   3360   2 (autoclean)
vfat9052   1 (autoclean)
fat29280   1 (autoclean) [vfat]
ne2k-pci4072   1
83906068   0 [ne2k-pci]

[7.4.] SCSI information (from /proc/scsi/scsi)

[7.5.] 


Thanks a lot!

-- 
Serge Gavrilov 
-
To unsubscribe from this list: send 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] fix for VM test9-pre7

[Christoph Rohland]

Hi Rik,

the shm swapping still kills the machine(8GB mem) the machine with
somthing like '__alloc_pages failed order 0'. 

When I do the same stresstest with mmaped file in ext2 the machine
runs fine but the processes do not do anything and vmstat/ps lock up
on these processes.

Greetings
Christoph
-
To unsubscribe from this list: send 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: test9-pre8 doesn't compile Reiserfs-3.6.17

[Steven Cole]

On 2000-10-02 Claudius Link wrote:

>With me that was a simple makefile problem
>linux/fs/Makefile
>changed quit a bit. So you have to add the line
>   subdir-$(CONFIG_REISERFS_FS)+= reiserfs
>somewhere (for example after "subdir-$(CONFIG_JFFS_FS)  += jffs")
>then it works fine.

Right, thanks.  Here is a tested little patchlet:

diff -u linux/fs/Makefile.orig linux/fs/Makefile
--- linux/fs/Makefile.orig  Mon Oct  2 10:27:34 2000
+++ linux/fs/Makefile   Mon Oct  2 09:59:03 2000
@@ -60,6 +60,7 @@
 subdir-$(CONFIG_ADFS_FS)   += adfs
 subdir-$(CONFIG_DEVPTS_FS) += devpts
 subdir-$(CONFIG_SUN_OPENPROMFS)+= openpromfs
+subdir-$(CONFIG_REISERFS_FS)   += reiserfs


 obj-$(CONFIG_BINFMT_AOUT)  += binfmt_aout.o


With kind regards,
Steven Cole
-
To unsubscribe from this list: send 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: Soft-Updates for Linux ?

[Andreas Dilger]

Albert Cahalan write:
> Robert Redelmeier writes:
> > Daniel Phillips wrote in part:
> 
> >> One thing to keep in mind in all of this is: nobody is testing the
> >> reliability of their journalling or any other kind of filesystem just by
> >> running it.  To test these things you have to crash/interrupt the system
> >> *a lot*.  Otherwise, you are just fooling yourself and everybody else.
> >> How many crashes does it take to find that one little window of
> >> vulnerability that comes up every 10,000 crashes normally but suddenly
> >> starts coming up every time just because your customer uses their system
> >> a different way?  You're doing the right thing by crash-testing it, now
> >> instead of doing it 5 times do it 1,000 times.  Here's one of my
> >> favorite tests: unzip a kernel source tree and wait until the disk light
> >> goes out.  A second or so after it comes on again (kflushd) hit the
> >> reset button.
> >
> > Good idea.  I certainly believe in stressing hardware (see .sig),
> > but I'm not sure this test is rigorous enough.  The problem is 
> > the reset button is only connected to the CPU and the hard disk
> > will probably continue to write out sectors from it's hw buffer.
> > OTOH, I don't like the idea of pulling the plug too often.  It's
> > very hard on the hardware.  I'd expect a mechanical disk failure
> > before 10,000 cycles.
> 
> The nice way to develop this code is with a block device that
> discards all writes after a timer goes off.

I made a patch to the loopback device which allows you to discard I/Os
going to disk.  You can either activate it via an ioctl from user space,
or via a function call in the kernel.

You can also make reads fail, but this was not very useful for me, because
it caused the ASSERTs in ext3 to oops.  Also the read "failures" are not
the same as the real thing, so it may not be a valid test.  They only
return a zero'd page, rather than really causing a non-up-to-date page.

I used it quite a bit when developing the orphan code for ext3, and for
testing journal integration in InterMezzo.  You can use it for testing
a loopback file, or loopback mount a block device, but as with regular
loopback devices, there is a 2GB limit.

I posted it to fsdevel a few months ago, but I have also uploaded it to:
ftp://ftp.stelias.com/pub/adilger/loopdiscard-2.2.16.patch
ftp://ftp.stelias.com/pub/adilger/loop_discard.c

The loop_discard.c program simply calls the ioctl to enable or disable
I/O on the specific loop device.  Unconfiguring the loop device also
resets the I/O status.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
To unsubscribe from this list: send 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.17 crashing like mad on me - oops included

[Brad Felmey]

Hello,

I've subscribed to the list for quite a while, and I sincerely hope this is the
correct place to report this particular problem. If not, I apologize and ask
that someone point me in the correct direction.

Since I would rather include too much information than too little, I'll include
a brief description of the hardware, the distro, and the problem, followed by a
printout of the oops.

The machine:

SMP dual PII/400
Supermicro P6DBU
256MB PC-100 in 4 sticks of 64MB ea.
Adaptec 2940UW
TNT2 Ultra 32MB AGP
(2) Intel PRO/100 PCI NICs
PCI es1370 sound
LinTV card (bttv)
300w Antec PSU
APC 500 PS backup

Mandrake 7.1, expert install, chose everything, and went with ReiserFS (love
those speedy boots). This box ran very well for weeks. The box itself is
hand-built, and has run well for a year or so under various Linux distros.

When 2.2.17 was released, I immediately went and pulled the 2.2.17 kernel, and
the 3.5.24 reiserfs patch. Patched, config'd, built. Started having terrible
lockups. Closing Netscape would do it almost every time. I removed all Netscape
from the machine. Mozilla (latest nightly) would crash it on opening up a child
window. I started having massive corruption of data streams. For instance, when
opening up *.tar.gz files, or checking RAR archives, etc. md5 would come up with
inconsistent results (!). Files corrupted (but only ones that had been
"touched"/manipulated. Samba would happily take down the machine. All of these
are hard locks, requiring manual reboots.

Rebuilt the kernel several times. Pulled fresh source, fresh patch (now at
3.5.26), reapplied, copied old .config over and did 'make oldconfig', and on
others just simply redid the config from scratch. All of these in just about
every way there is to arrange 9 books on a shelf. Chose modules, chose built-in,
on and on ad nauseum. I surely did not want to post to this list without at
least doing my homework.

I have other mission-critical boxen that I have held off of the 2.2.17 upgrade
until I'm comfortable that this is just a problem specific to this machine or my
stupidity. This is the only SMP box I have, the others are UP. The following was
taken from my /var/messages log.

I appreciate any/all feedback, because this is just quite simply driving me
crazy. Most un-Linuxish behavior. :(

>Oct  2 11:22:58 omega kernel: <3>kmem_free: Bad obj addr (objp=ccc58280, 
>name=size-32) 
>Oct  2 11:22:58 omega kernel: <1>Unable to handle kernel NULL pointer dereference at 
>virtual address  
>Oct  2 11:22:58 omega kernel: <1>current->tss.cr3 = 0f533000, %%cr3 = 0f533000 
>Oct  2 11:22:58 omega kernel: <1>*pde =  
>Oct  2 11:22:58 omega kernel: <4>Oops: 0002 
>Oct  2 11:22:58 omega kernel: <4>CPU:1 
>Oct  2 11:22:58 omega kernel: <4>EIP:0010:[kfree+410/460] 
>Oct  2 11:22:58 omega kernel: <4>EFLAGS: 00010202 
>Oct  2 11:22:58 omega kernel: <4>eax: 0039   ebx: c080   ecx: 004a   edx: 
>0002 
>Oct  2 11:22:58 omega kernel: <4>esi: ccc58280   edi: 0202   ebp:    esp: 
>ca955ecc 
>Oct  2 11:22:58 omega kernel: <4>ds: 0018   es: 0018   ss: 0018 
>Oct  2 11:22:58 omega kernel: <4>Process smbd (pid: 624, process nr: 31, 
>stackpage=ca955000) 
>Oct  2 11:22:58 omega kernel: <4>Stack:   ccd58b00 ca682860 a54eebaa 
>0011 cc29b404 ca955f68  
>Oct  2 11:22:58 omega kernel: <4>   0040 c0136071 ccc58280 ca682860 ca71001a 
> ccd58b00 ca58c8a0  
>Oct  2 11:22:58 omega kernel: <4>   fffe ca71 08124d60 b75c  
> ca8e4e40 ca955f78  
>Oct  2 11:22:58 omega kernel: <4>Call Trace: [prune_dcache+229/312] 
>[shrink_dcache_parent+23/48] [lookup_dentry+365/504] [vfs_rmdir+254/308] 
>[sys_rmdir+201/320] [common_interrupt+24/32] [system_call+52/64]  
>Oct  2 11:22:58 omega kernel: <4>   [stext+43/164]  
>Oct  2 11:22:59 omega kernel: <4>Code: c7 05 00 00 00 00 00 00 00 00 eb 1d 89 f6 83 
>c4 f8 56 68 82  

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

buffer_head.b_blocknr is unsigned long, not int

[Matt_Domsch]

Throughout linux/fs/buffer.c, the struct buffer_head member b_blocknr has
integer values put into it, while it's defined to be an unsigned long in
fs.h.  For architectures where sizeof(int) != sizeof(long), calls to bread()
could potentially do the wrong thing if the disk has more than 2^41 blocks
(2 TB or more, depending on block size).

Before hunting down all the places where b_blocknr gets an integer put in
it, and making a patch, I thought I'd ask first if there's a good reason why
it's done this way.  In a few places, values such as -1 and -1000 are put
there as dummy values, so don't hurt anything.  Are there other reasons?

Thanks,
Matt Domsch
Dell Enterprise Systems Group
Linux Development Team



-
To unsubscribe from this list: send 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: problems with 2.4.0-test8

[Rik van Riel]

On Mon, 2 Oct 2000, Petko Manolov wrote:
> Richard Polton wrote:

> >  I am using 2.4.0-test8 on an i686 laptop. I find that netscape-4.72
> >  keeps locking up. I am not able to kill the process at all (without
> >  a reboot, and SysRQ cannot do a sync on the partition it is running
> >  in either). I have been advised that RvR's memory patches will fix
> >  this but I have yet to try. (This behaviour also can be seen with
> >  ppp-2.4.0, which is a trifle irritating 8-)
> 
> I have the same kind of problems with 2.4.0-test8, test-9-pre[678].
> 
> I'd thought it is due to bug in my (usb pegasus) driver which i used
> most of the time. But i got the same crash with eepro100 which is
> considered to be fairly solid.
> 
> The bug appears when netscape tries to switch the windows or open new
> one. I'm afraid the newest RvR's MM code is not so stable.

You may want to try my latest patch ;)

I have known about these problems for about 2 weeks, but
was away at conferences so couldn't create a clean enough
patch to send to Linus ;(

http://www.surriel.com/patches/

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/   http://www.surriel.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: PROBLEM: 2.2.17 hangs when attempting to mount atapi cdrom Teac CD-540E

[Jens Axboe]

On Mon, Oct 02 2000, Serge Gavrilov wrote:
> [1.] 2.2.17 hangs when attempting to mount atapi cdrom Teac CD-540E
> 
> [2.] My kernel was compiled with flags
> 
> CONFIG_BLK_DEV_IDEPCI=y
> CONFIG_BLK_DEV_IDEDMA=y
> CONFIG_IDEDMA_AUTO=y
> 
> My cdrom Teac CD-540E supports UDMA mode2.
> When I try to mount /cdrom kernel hangs.
> If I invoke 
> 
> hdparm -d0 /dev/hdc
> 
> and invoke "mount /cdrom" after, then everything is OK.

What IDE chipset? Note that not all of them support DMA with ATAPI at
the moment. And also note that even if your CD-ROM claims to support
UDMA, it doesn't necessarily mean that it does in reality...

-- 
* 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: test9-pre7 doesn't recognize HiSax ISDN card

[Karsten Keil]

On Mon, Oct 02, 2000 at 12:08:10AM +0200, Pierfrancesco Caci wrote:
> 
> The subject tells everything:
> 
...
> 
> 28x481 23:49:14 penny kernel: fb0: MATROX VGA frame buffer device
> Oct  1 23:49:14 penny kernel: pty: 512 Unix98 ptys configured
> Oct  1 23:49:14 penny kernel: ISDN subsystem Rev: 1.111/1.93/1.135/1.77/1.21/1.5
> Oct  1 23:49:14 penny kernel: Uniform Multi-Platform E-IDE driver Revision: 6.31
> 
> Is there something that is changed and that I should know ?
> 

Nothing so far I know, seems HiSax was not selected or compiled as module.

-- 
Karsten Keil
SuSE Labs
ISDN 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: Meaning of blk_size

[Daniel Phillips]

Andries Brouwer wrote:
> On Mon, Oct 02, 2000 at 02:33:20AM +0200, Daniel Phillips wrote:
> > On Mon, 02 Oct 2000, Andries Brouwer wrote:
> 
> > > [you sounded as if you noticed a discrepancy somewhere - so I expected:
> > > foo.c uses this in line 123 but bar.c uses that in line 666.]
> >
> > No, I'm just trying to understand the meaning of the "+ 1" in ll_rw_block.c,
> > generic_make_request:
> >
> >   unsigned long maxsector = (blk_size[major][MINOR(bh->b_rdev)] << 1) + 1;
> 
> blk_size[][] gives a block count
> blk_size[][]<<1 gives a sector count
> 
> but if the device had an odd number of sectors, the sector count
> is one larger than twice the block count.
> 
> (thus, this is not the precisely correct test; the knowledge about
> the number of sectors lives in the dev->sizes array; here we only
> have a rough check)

OK, it's a discrepancy.  This is the test used in generic_make_request. 
Devices with 512 byte blocks will be able to access one sector past the
blk_size.  I wasn't expecting that and that's why I was so confused by
it.  The deep problem is the size should be expressed in units of
dev_block_size, not bogosectors.

*** pauses for a moment and wonders what a nice filesystem developer is
doing in a place like this

I have no doubt I'm beating on a horse that has been beaten on many
times in the past.  I'll suggest the obvious: there should be a device
table, dev_block_bits[MAX_BLKDEV], initialized by default to 9's.  Then
at our leisure we can change over the drivers one by one to use the real
device block size instead of bogosectors and finally kill that ugly
duck.  The new improved code will be more efficient because it will get
rid of a lot of multiply/divides by 512.  Some device size limitations
will go away.  It will certainly be easier to read.

One more question that has probably been asked a lot: why are the
various fields of a device splatted across half a dozen tables instead
of being collected together in a struct and accessed through one table?

Now I'll get out of here and go back to my filesystem.  I was checking
the wrong thing in my valid_block function anyway, I should have been
checking against the blocks count in the superblock:

#define valid_block(sb, i) \
  (i < sb->u.ext2_sb.s_blocks_per_group * sb->u.ext2_sb.s_groups_count)

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

Re: iounmap() - can't always unmap memory I've mappedt

[Timur Tabi]

** Reply to message from Alan Cox <[EMAIL PROTECTED]> on Mon, 2 Oct 2000
17:18:59 +0100 (BST)


> > Anyway, my original question has not yet been answered: why is it that I can
> > ioremap() any physical page by simply setting one bit, but I cannot always
> > iounmap() it?  Why can't iounmap() simply undo what ioremap() did?
> 
> The fact you can doesn't mean you should. You need to be sole owner of that
> page before you can fiddle with the reserved bit. You were not sole owner

Ok, is there a way around this?  After all, mapping a page I don't own doesn't
really mean anything in the kernel, because all pages, whether or not I own
them, are already mapped!  phys_to_virt works on any physical address.  What I
want to do is use iounmap_nocache() to access the memory in an uncached manner,
and that's what I do.

Would it be possible to reassign the ioremap()'d memory to some other physical
page that I _do_ own, and then call iounmap?  I have no problem doing all of
this stuff in Windows 2000, so I'm surprised that it's so difficult in Linux.



-- 
Timur Tabi - [EMAIL PROTECTED]
Interactive Silicon - http://www.interactivesi.com

When replying to a mailing-list message, please don't cc: me, because then I'll just 
get two copies of the same message.
-
To unsubscribe from this list: send 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] fix for VM test9-pre7

[Rik van Riel]

On 2 Oct 2000, Christoph Rohland wrote:

> the shm swapping still kills the machine(8GB mem) the machine
> with somthing like '__alloc_pages failed order 0'.
> 
> When I do the same stresstest with mmaped file in ext2 the
> machine runs fine but the processes do not do anything and
> vmstat/ps lock up on these processes.

This may be a highmem bounce-buffer creation deadlock. Do
your tests work if you use only 800 MB of RAM ?

Shared memory swapping on my 64 MB test machine seems to
work fine (albeit a bit slow).

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/   http://www.surriel.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/

2.4.0-test9-pre8 on SPARC build failure

[Horst von Brand]

This PCI stuff was discussed before...

pcic.c: At top level:
pcic.c:39: redefinition of `pcibios_present'
/usr/src/linux-2.4.0-test/include/linux/pci.h:562: `pcibios_present' previously 
defined here
make[1]: *** [pcic.o] Error 1
make[1]: Leaving directory `/usr/src/linux-2.4.0-test/arch/sparc/kernel'
make: *** [_dir_arch/sparc/kernel] Error 2
-- 
Dr. Horst H. von Brand   mailto:[EMAIL PROTECTED]
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

TODO list for new VM (oct 2000)

[Rik van Riel]

[MM TODO list, updated for october 2000]

---
Here is the TODO list for the new VM. The only thing
really needed for 2.4 is the OOM handler and a fix
for the highmem deadlock.

The page->mapping->flush() callback is really wanted
by the journaling filesystem folks.

The rest are mostly extra's that would be nice; these
things won't be pushed for inclusion except if it turns
out to be really trivial to implement, high performance
on the cases they're supposed to affect and their influence
is highly localised...

(sorry folks, but for 2.4 I'll be really conservative)

---> TODO list for the new VM <---

for kernel 2.4, necessary:
- out of memory handling
[integrate the OOM killer, 10 minutes work]
- fix the highmem deadlock, where the swapper cannot create
  low memory bounce buffers OR swap out low memory because
  it has consumed all resources
[old bug, already reported with 2.4.0-test6, probably before]

for kernel 2.4, really wanted:
- page->mapping->flush() callback in page_launder(),
  for easier integration with journaling filesystems
  and maybe the network filesystems
[about 30 minutes of work on the VM side]

for kernel 2.4, wanted:
- maybe rebalance the swapper a bit ... we do page aging
  now so maybe refill_inactive_scan() / shm_swap() and
  swap_out() need to be rebalanced a bit

for kernel 2.5:(maybe available as patch for 2.4 ???)
- physical->virtual reverse mapping, so we can do much
  better page aging with less CPU usage spikes
- better IO clustering for swap (and filesystem) IO
- move all the global VM variables, lists, etc. into
  the pgdat struct for better NUMA scalability
- (maybe) some QoS things, as far as they are major
  improvements with minor intrusion
- thrashing control, maybe process suspension with some
  forced swapping ?
- include Ben LaHaise's code, which moves readahead
  to the VMA level, this way we can do streaming swap
  IO, complete with drop_behind()

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/   http://www.surriel.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/

Oops at bootup with 2.4.0-test9-pre8

[really [EMAIL PROTECTED]]

--test9-pre8 blows up at boot, somewhere around the ALI5X3 init.

Here's the oops, with ksymoops decode.  Copied by hand, 
hope it's correct:

ALI5X3: IDE controller on PCI buss 00 dev 78
ALI5X3: chipset revision 193
ALI5X3: bad irq (0): will probe later

Unable to handle kernel paging request at virtual address 0010
printing eip
c0178539
*pde = 
Oops: 
CPU:0
EIP:0010:[]
EFLAGS: 00010002
eax:    ebx: 0002   ecx:    edx: c133df3f
esi: 005e   edi: cbfec400   ebp:    esp: c133def8
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 2, stackpage=c133d000)
Stack: c133df3f  c020db96  005e c133df3f cbfec400 004b
   004a cbfec400 004b c133df3f 01f0 c0258200 03f4 
   0246 4a0001f0 c020e6fe c0258200 c0214844 cbfec400 c024ccbc 8e00
Call Trace: [] [] 
Code: 8b 41 10 8b 40 30 52 56 51 8b 00 ff d0 83 c4 0c 53 0d 5b 5e


ksymoops 2.3.4 on i586 2.4.0-test9pre7.  Options used
 -v ./vmlinux (specified)
 -K (specified)
 -L (specified)
 -O (specified)
 -m ./System.map (specified)

Unable to handle kernel paging request at virtual address 0010
c0178539
*pde = 
Oops: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010002
eax:    ebx: 0002   ecx:    edx: c133df3f
esi: 005e   edi: cbfec400   ebp:    esp: c133def8
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 2, stackpage=c133d000)
Stack: c133df3f  c020db96  005e c133df3f cbfec400 004b
   004a cbfec400 004b c133df3f 01f0 c0258200 03f4 
   0246 4a0001f0 c020e6fe c0258200 c0214844 cbfec400 c024ccbc 8e00
Call Trace: [] [] 
Code: 8b 41 10 8b 40 30 52 56 51 8b 00 ff d0 83 c4 0c 53 0d 5b 5e

>>EIP; c0178397<=
Trace; c0107007 
Trace; c0108cec 
Code;  c0178397 
 <_EIP>:
Code;  c0178397<=
   0:   8b 41 10  mov0x10(%ecx),%eax   <=
Code;  c017839a 
   3:   8b 40 30  mov0x30(%eax),%eax
Code;  c017839d 
   6:   52push   %edx
Code;  c017839e 
   7:   56push   %esi
Code;  c017839f 
   8:   51push   %ecx
Code;  c01783a0 
   9:   8b 00 mov(%eax),%eax
Code;  c01783a2 
   b:   ff d0 call   *%eax
Code;  c01783a4 
   d:   83 c4 0c  add$0xc,%esp
Code;  c01783a7 
  10:   53push   %ebx
Code;  c01783a8 
  11:   0d 5b 5e 00 00or $0x5e5b,%eax



/proc/pci :

PCI devices found:
  Bus  0, device   0, function  0:
Host bridge: Acer Laboratories Inc. [ALi] M1541 (rev 4).
  Master Capable.  Latency=64.  
  Non-prefetchable 32 bit memory at 0xd800 [0xdfff].
  Bus  0, device   1, function  0:
PCI bridge: Acer Laboratories Inc. [ALi] M5243 (rev 4).
  Master Capable.  Latency=64.  Min Gnt=8.
  Bus  0, device   3, function  0:
Bridge: Acer Laboratories Inc. [ALi] M7101 PMU (rev 0).
  Bus  0, device   7, function  0:
ISA bridge: Acer Laboratories Inc. [ALi] M1533 PCI to ISA Bridge [Aladdin IV] (rev 
195).
  Bus  0, device  10, function  0:
Ethernet controller: Digital Equipment Corporation DECchip 21041 [Tulip Pass 3] 
(rev 17).
  IRQ 12.
  Master Capable.  Latency=24.  
  I/O at 0xb800 [0xb87f].
  Non-prefetchable 32 bit memory at 0xd680 [0xd680007f].
  Bus  0, device  15, function  0:
IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev 193).
  Master Capable.  Latency=32.  Min Gnt=2.Max Lat=4.
  I/O at 0xb400 [0xb40f].
  Bus  1, device   0, function  0:
VGA compatible controller: ATI Technologies Inc Rage 128 RF (rev 0).
  IRQ 11.
  Master Capable.  Latency=64.  Min Gnt=8.
  Prefetchable 32 bit memory at 0xe400 [0xe7ff].
  I/O at 0xd800 [0xd8ff].
  Non-prefetchable 32 bit memory at 0xd780 [0xd7803fff].



/proc/cpuinfo :

processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 5
model   : 9
model name  : AMD-K6(tm) 3D+ Processor
stepping: 1
cpu MHz : 449.000148
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
sep_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr mce cx8 sep mtrr pge mmx 3dnow
bogomips: 894.57


-
To unsubscribe from this list: send 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: TODO list for new VM (oct 2000)

[Linus Torvalds]

Why do you apparently ignore the fact that page-out write-back performance
is horribly crappy because it always starts out doing synchronous writes?

I pointed out previously in a private email that page_launder() must be
buggy as it stands now, you seem to have ignored that part (and the
test-program that shows 1MB/s writeout speeds due to it) completely.

The whole _point_ of the new VM was performance. Without that, the new VM
is pointless, and discussing TODO features is equally pointless.

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: TODO list for new VM (oct 2000)

[Rik van Riel]

On Mon, 2 Oct 2000, Linus Torvalds wrote:

> Why do you apparently ignore the fact that page-out write-back
> performance is horribly crappy because it always starts out
> doing synchronous writes?

Because it is fixed in the patch I mailed yesterday?

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/   http://www.surriel.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: Oops at bootup with 2.4.0-test9-pre8

[really [EMAIL PROTECTED]]

> --test9-pre8 blows up at boot, somewhere around the ALI5X3 init.
>
> Here's the oops, with ksymoops decode.  Copied by hand, 
> hope it's correct:

Darn.  Made 3 typos in transcription:

ALI5X3: IDE controller on PCI buss 00 dev 78
 ^ 
Process swapper (pid: 2, stackpage=c133d000)
  ^ should be "pid: 1"
Code: 8b 41 10 8b 40 30 52 56 51 8b 00 ff d0 83 c4 0c 53 0d 5b 5e
 ^ should be "9d"
-

Here's the corrected oops, with ksymoops decode:

=

ALI5X3: IDE controller on PCI bus 00 dev 78
ALI5X3: chipset revision 193
ALI5X3: bad irq (0): will probe later

Unable to handle kernel paging request at virtual address 0010
printing eip
c0178539
*pde = 
Oops: 
CPU:0
EIP:0010:[]
EFLAGS: 00010002
eax:    ebx: 0002   ecx:    edx: c133df3f
esi: 005e   edi: cbfec400   ebp:    esp: c133def8
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 1, stackpage=c133d000)
Stack: c133df3f  c020db96  005e c133df3f cbfec400 004b
   004a cbfec400 004b c133df3f 01f0 c0258200 03f4 
   0246 4a0001f0 c020e6fe c0258200 c0214844 cbfec400 c024ccbc 8e00
Call Trace: [] [] 
Code: 8b 41 10 8b 40 30 52 56 51 8b 00 ff d0 83 c4 0c 53 9d 5b 5e



ksymoops 2.3.4 on i586 2.4.0-test9pre7.  Options used
 -v ./vmlinux (specified)
 -K (specified)
 -L (specified)
 -O (specified)
 -m ./System.map (specified)

Unable to handle kernel paging request at virtual address 0010
c0178539
*pde = 
Oops: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010002
eax:    ebx: 0002   ecx:    edx: c133df3f
esi: 005e   edi: cbfec400   ebp:    esp: c133def8
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 1, stackpage=c133d000)
Stack: c133df3f  c020db96  005e c133df3f cbfec400 004b
   004a cbfec400 004b c133df3f 01f0 c0258200 03f4 
   0246 4a0001f0 c020e6fe c0258200 c0214844 cbfec400 c024ccbc 8e00
Call Trace: [] [] 
Code: 8b 41 10 8b 40 30 52 56 51 8b 00 ff d0 83 c4 0c 53 9d 5b 5e

>>EIP; c0178397<=
Trace; c0107007 
Trace; c0108cec 
Code;  c0178397 
 <_EIP>:
Code;  c0178397<=
   0:   8b 41 10  mov0x10(%ecx),%eax   <=
Code;  c017839a 
   3:   8b 40 30  mov0x30(%eax),%eax
Code;  c017839d 
   6:   52push   %edx
Code;  c017839e 
   7:   56push   %esi
Code;  c017839f 
   8:   51push   %ecx
Code;  c01783a0 
   9:   8b 00 mov(%eax),%eax
Code;  c01783a2 
   b:   ff d0 call   *%eax
Code;  c01783a4 
   d:   83 c4 0c  add$0xc,%esp
Code;  c01783a7 
  10:   53push   %ebx
Code;  c01783a8 
  11:   9dpopf   
Code;  c01783a9 
  12:   5bpop%ebx
Code;  c01783aa 
  13:   5epop%esi

-
To unsubscribe from this list: send 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: Meaning of blk_size

[Andries Brouwer]

On Mon, Oct 02, 2000 at 07:11:52PM +0200, Daniel Phillips wrote:

> One more question that has probably been asked a lot: why are the
> various fields of a device splatted across half a dozen tables instead
> of being collected together in a struct and accessed through one table?

Yes, this has been asked a lot.

I did this a few times. Half of the work was the introduction
of the kdev_t opaque type - the patch was around 1.3.20.
I am very glad this happened - it was a lot of work, determining
for all integers in the kernel whether they held a device value
or not. Today the kernel is seven times as large and such a change
would be next to impossible.

The other half increased in magnitude in the past five years.
It is what you suggest: have a kdev_t that is a pointer to a
struct that contains the fields that today live in these arrays.

device size is a 64-bit bytecount, so no granularity problems.

These days I have as background activity the construction
of the corresponding patch for 2.4. Maybe we can start 2.5
without these arrays and with large device numbers.

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/

Re: TODO list for new VM (oct 2000)

[Rik van Riel]

On Mon, 2 Oct 2000, Rik van Riel wrote:
> On Mon, 2 Oct 2000, Linus Torvalds wrote:
> 
> > Why do you apparently ignore the fact that page-out write-back
> > performance is horribly crappy because it always starts out
> > doing synchronous writes?
> 
> Because it is fixed in the patch I mailed yesterday?

One small warning though. Please don't apply that patch
yet because I fixed 3 more small problems today. I'll
send you an updated patch...

- the compile warnings are fixed
- in try_to_free_pages(), we forgot to set
  PF_MEMALLOC in current->flags  (oops)
- in grow_buffers(), in case we cannot get a
  buffer head, we must unlock the page

A patch against 2.4.0-test9-pre8 with these 3 changes will
be on its way once I've tested it a bit...

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/   http://www.surriel.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 2.4.0.9.8: Fix IDE...

[Jeff Garzik]

Linus,

Ug.  Why do I feel like the IDE "driver" is code layered upon code
layered upon code, through the ages, with nary a cleanup in between?

My previous patch was a fix, but (brown paper bag time) standard IDE
devices no longer called chipset init.  People either had no IDE, or
were stuck in legacy mode.  This fixes it.

The IDE layer is in serious need of a cleanup though, IMHO...

With this tested patch full functionality should be restored, without
reverting to the previously-crazy code found in test9-pre7 and before.

Jeff




Index: drivers/ide/ide-pci.c
===
RCS file: /usr/jgarzik/cvslan/linux_2_3/drivers/ide/ide-pci.c,v
retrieving revision 1.1.1.9
diff -u -r1.1.1.9 ide-pci.c
--- drivers/ide/ide-pci.c   2000/10/02 08:32:44 1.1.1.9
+++ drivers/ide/ide-pci.c   2000/10/02 18:28:10
@@ -493,6 +493,7 @@
byte tmp = 0;
ide_hwif_t *hwif, *mate = NULL;
unsigned int class_rev;
+   int pci_class_ide;
 
 #ifdef CONFIG_IDEDMA_AUTO
autodma = 1;
@@ -538,7 +539,8 @@
 * Can we trust the reported IRQ?
 */
pciirq = dev->irq;
-   if ((dev->class & ~(0xff)) != (PCI_CLASS_STORAGE_IDE << 8)) {
+   pci_class_ide = ((dev->class >> 8) == PCI_CLASS_STORAGE_IDE);
+   if (!pci_class_ide) {
printk("%s: not 100%% native mode: will probe irqs later\n", d->name);
/*
 * This allows offboard ide-pci cards the enable a BIOS,
@@ -548,11 +550,17 @@
 */
pciirq = (d->init_chipset) ? d->init_chipset(dev, d->name) : 
ide_special_settings(dev, d->name);
} else if (tried_config) {
-   printk("%s: will probe irqs later\n", d->name);
+   printk(KERN_INFO "%s: will probe irqs later\n", d->name);
pciirq = 0;
} else if (!pciirq) {
-   printk("%s: bad irq (%d): will probe later\n", d->name, pciirq);
-   pciirq = 0;
+   if (pci_class_ide) {
+   /* this is the normal path for most IDE devices */
+   if (d->init_chipset)
+   pciirq = d->init_chipset(dev, d->name);
+   else
+   printk(KERN_INFO "%s standard IDE storage device 
+detected\n", d->name);
+   } else
+   printk(KERN_WARNING "%s: bad irq (0): will probe later\n", 
+d->name);
} else {
if (d->init_chipset)
(void) d->init_chipset(dev, d->name);

-
To unsubscribe from this list: send 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: PIDs limited to 15 significant bits

[Adam Sampson]

On Sun, Oct 01, 2000 at 10:48:41PM -0400, Albert D. Cahalan wrote:
> I see you don't remember the original post. It argued in
> favor of a large PID space "because the output of ps wouldn't
> look nice otherwise"!!! (the poster wanted output sorted by
> start time without using --sort=start to ask for it)

Why not use 32-bit PIDs in the kernel, but make the number at which they
wrap a configurable option? That way, most users can keep the numbers small
for ease of management, and people who really need 100,000 processes can
have them.

-- 

Adam Sampson
[EMAIL PROTECTED]

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

Linux 2.2.18pre15

[Alan Cox]

Bug squash number three.

ARM, Alpha and x86 should be completely sorted for the loops_per_sec change. 
S/390 merge yet to be done. PPC and Sparc still won't build.

Alan

Stuff left to do for 2.2.18final
-   loops_per_jiffy for non x86, Alpha, ARM
-   Merge the S/390 stuff and make S/390 build again
-   Fix the megaraid (revert if need be)

The S/390 stuff shouldnt touch the mainstream so from hereon in its simply
a case of squashing bugs as they pop out until its ready to be 2.2.18.

2.2.18pre15
o   Default msdos behaviour to old (small) letters  (me)
| An option 'big' goes with 'small'
o   Fix define collision in cpqfc   (Arjan van de Ven)
o   Fix case where scripts/kwhich isnt executable   (me)
o   Alpha FPU divide fix(Richard Henderson)
o   Add ADMtek985 to the tulip list (J Katz)
o   Lose excess ymfpci debugging(Rob Landley)
o   Fix i2c bus id clash(Russell King)
o   Update the ARM vidc driver  (Russell King)
o   Update the ARM am79c961a driver (Russell King)
o   Fix parport_pc build with no PCI(Russell King)
o   Fix ARM memzero (Russell King)
o   Update ARM for __init and __setup   (Russell King)
o   Update ARM to loops_per_jiffy   (Russell King)
o   Remove arm ecard debug messages (Russell King)
o   Fix ARM makefiles   (Russell King)
o   Fix iph5526 driver to use mdelay(Arjan van de Ven)
o   Fix epca, dtlk, aha152x loops_per_sec bits  (Philipp Rumpf)
o   Fix smp tlb invalidate and bogomip printing (Philipp Rumpf)
o   Fix NLS warnings(Arjan van de Ven)
o   Fix wavfront conversion to loops_per_jiffies(me)
o   Fix an audio problem and a sanyo changer(Jens Axboe)
problem
o   Fix include bug with divert (me)
| Alternate fix to Willy Tarreau's
o   Fix Alpha for loops_per_jiffy   (Willy Tarreau)

2.2.18pre14
o   Reorder attributes in drm to work with gcc272   (me)
o   GNU cross compilers are foo-bar-gcc (Russell King)
o   Add extra strange pcnet32 ident (Willy Tarreau)
o   Since no vendor can get which right.. use a (Miquel van Smoorenburg)
shell script instead
| Please nobody tell me this fails in some bash version!
o   Should be using bash not bash2 (escaped debug)  (Petri Kaukasoina)
o   spin_unlock_irq wrong debug mode printk (Willy Tarreau)
o   Fix pcxx for the loops changes  (Arjan van de Ven)
o   Fix ov511/via-rhine name clash  (Arjan van de Ven)
o   Fix bridge compile with loops_per_sec change(Mitch Adair)
o   8139too driver added(Jeff Garzik)

2.2.18pre13
o   Change udelay to use loops_per tick (Philipp Rumpf)
| Otherwise we bomb out at 2GHz which isnt far enough
| away with 1.4/1.6GHz stuff due out RSN
o   Fix drivers using big delays to use mdelay  (me)
o   Fix drivers that used loops_per_sec (Philipp Rumpf, me)
o   Fix yamaha PCI sound SMP bug(Arjan van de Ven)
o   Change to preferred USB init fix(David Rees)
o   Fix rio fix (Arjan van de Ven)
o   Catch the VT but no mouse case in init/main.c   (Arjan van de Ven)
o   Fix the 'which' compiler stuff  (Horst von Brand,
 Peter Samuelson)
| Can someone verify for me this works on Slackware and
| on Caldera ?
o   Add devfs include. Devfs wont be going into 2.2 (Richard Gooch)
but this again makes it easier to do 2.2/2.4
drivers.

2.2.18pre12
o   Fix cyrix MTRR handling bug (IIZUKA Daisuke)
o   Fix ymfpci poll (me, Arjan)
o   Update radio-maestro, add Configure.help(Adam Tla/lka>
o   Fix rio/generic serial build bug(Marcelo Tossati)
o   USB build bug fix   (Arjan van de Ven)
o   Fix missing ac97_codec.c return value   (Arjan van de Ven)
o   Fix several warnings(Arjan van de Ven)
o   Made the PS/2 reconnect behaviour optional  (me)
| Its now 'psaux-reconnect' on the boot line
o   Allow for newer Hauppauge with 4 ports  (Krischan Jodies)
o   Switch sound drivers from library to object (Arjan van de Ven)
o   Kill the not working ac97 lock on the 810   (me)
o   Automatically select older compilers for kernel
builds on Debian and RH