Re: [OT] Major Clock Drift

[Manfred Bartz]

Josh Myer <[EMAIL PROTECTED]> writes:

> I know this _really_ isn't the forum for this, but a friend of mine has
> noticed major, persistent clock drift over time. After several weeks, the
> clock is several minutes slow (always slow). Any thoughts on the
> cause? (Google didn't show up anything worthwhile in the first couple of
> pages, so i gave up).
> 
> I assume it doens't matter what the mains frequency is (since we're
> pulling from a crystal for this anyway). I think i'd heard mention of
> problems with other interrupts interrupting the timer often enough that
> the time got slowed down, but really?
> 
> It's a relatively new Athlon, not sure of the mobo model. If it is a
> hardware problem, i'll find out the model, since that would strike me as
> an errata =)

Try 

-
To unsubscribe from this list: send 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: ATAPI CDRW which doesn't work

[patrick . mourlhon]

Be happy, it was not that simple. ;-)

On Sat, 03 Feb 2001, Bob_Tracy wrote:

> [EMAIL PROTECTED] wrote:
> > mount atapi cd writer outpu
> > 
> > Line:/mnt/home/pmo# mount /dev/hdb /cdrom
> > /dev/hdb: Input/output error
> > mount: block device /dev/hdb is write-protected, mounting read-only
> > /dev/hdb: Input/output error
> > 
> > mount: you must specify the filesystem type
> > Line:/mnt/home/pmo#
> 
> I'd hate to think your problem is *really* this simple, but if you
> really typed what is quoted above, and the CD you have in the drive
> really has something valid on it, try the following instead:
> 
> mount -t iso9660 /dev/hdb /cdrom -r
> 
> You have to specify the filesystem type, as well as specify the
> "readonly" flag.  Although there are other filesystem types that
> can be found on CDROMs, it's unlikely in your case.
> 
> --Bob Tracy
> [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: ATAPI CDRW which doesn't work

[patrick . mourlhon]

You were my best hope, cause i did something similar for
a Hp 720c on parallel port, and it worked. I did excatly
what you've just said.
But the whole thing still doesn't work properly.

I finally could mount the device, then read the first root directory.
But couldn't get more... always got what you see at the end of the
error message.. I/O error, which resulted in no files appearing from
a 'ls' command.

I've got those kind of message now :

Feb  4 07:18:35 Line kernel: scsi : aborting command due to timeout : pid 0, scsi0, 
channel 0, id 0, lun 0 Read (10) 00 00 00 00 2e 00 00 01 00 
Feb  4 07:18:35 Line kernel: SCSI host 0 abort (pid 0) timed out - resetting
Feb  4 07:18:35 Line kernel: SCSI bus is being reset for host 0 channel 0.
Feb  4 07:18:35 Line kernel: hdb: ATAPI reset complete
Feb  4 07:18:35 Line kernel: scsi : aborting command due to timeout : pid 0, scsi0, 
channel 0, id 0, lun 0 Read (10) 00 00 00 00 2e 00 00 01 00 
Feb  4 07:18:35 Line kernel: SCSI host 0 abort (pid 0) timed out - resetting
Feb  4 07:18:35 Line kernel: SCSI bus is being reset for host 0 channel 0.
Feb  4 07:18:37 Line kernel: hdb: irq timeout: status=0xd0 { Busy }
Feb  4 07:18:41 Line kernel: scsi0: ERROR on channel 0, id 0, lun 0, CDB: Request 
Sense 00 00 00 40 00 
Feb  4 07:18:41 Line kernel: Info fld=0x0, Current sd0b:00: sense key Medium Error
Feb  4 07:18:41 Line kernel:  I/O error: dev 0b:00, sector 184
Feb  4 07:20:09 Line kernel: scsi : aborting command due to timeout : pid 0, scsi0, 
channel 0, id 0, lun 0 Read (10) 00 00 00 00 2e 00 00 01 00 
Feb  4 07:20:09 Line kernel: hdb: irq timeout: status=0xd0 { Busy }
Feb  4 07:20:09 Line kernel: hdb: ATAPI reset complete
Feb  4 07:20:09 Line kernel: hdb: irq timeout: status=0xd0 { Busy }
Feb  4 07:20:09 Line kernel: hdb: ATAPI reset complete
Feb  4 07:20:10 Line kernel: hdb: irq timeout: status=0xd0 { Busy }
Feb  4 07:20:10 Line kernel: scsi0 channel 0 : resetting for second half of retries.
Feb  4 07:20:10 Line kernel: SCSI bus is being reset for host 0 channel 0.
Feb  4 07:20:10 Line kernel: hdb: status timeout: status=0xd0 { Busy }
Feb  4 07:20:10 Line kernel: hdb: drive not ready for command
Feb  4 07:20:21 Line kernel: hdb: ATAPI reset complete
Feb  4 07:20:22 Line kernel: Device 0b:00 not ready.
Feb  4 07:20:22 Line kernel:  I/O error: dev 0b:00, sector 184


On Sun, 04 Feb 2001, Marko Kreen wrote:

> On Sat, Feb 03, 2001 at 11:05:44PM +0100, [EMAIL PROTECTED] wrote:
> > Hi,
> > 
> > I've never could make this CDRW ATAPI to work, if someone could
> > provide me any clue about the baby. I just said that people on the
> > kernel mailing list may care of its but. It looks like the baby didn't
> > even noticed. ;-)
> 
> Compile in options 'SCSI generic', 'SCSI cdrom and 'SCSI
> emulation support' then add 'hdb=scsi' to kernel parameters.
> 
> Now you can use it as SCSI cdrom, and cd-writers recognize it
> too.  Eg. for cdrecord you should probably put 'dev=0,0,0' to
> command line (I assume you have no other SCSI controller).
> 
> 
> -- 
> marko
-
To unsubscribe from this list: send 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: "kaweth" usb ethernet driver in 2.4?

[Michael Rothwell]

On 03 Feb 2001 14:22:02 -0600, Eric Sandeen wrote:

> The driver is included with the USB stuff for 2.2, but not in 2.4.


That's because we stopped fooling with 2.4 around the middle of the
pre-test-ac series of releases. We'll probably pick it back up around
2.4.7 or so.


> It also doesn't seem to work in 2.2.  :)  The original development of
> this driver was going on at http://drivers.rd.ilan.net/kaweth/ but there
> have been no updates for quite some time.


Well, it doesn't work you _you_ on 2.2, obviously. But it works for us
and other people. Can you provide any information to diagnose the
problem you're having?

And, truthfully, you'd be better off tossing it in the trash and buying
a better product. It's VERY lossy with packets and slow. And it's not
just our driver; it's the device itself. It sucks on Windows as well. :)

However, if you post some info about your experience with it, perhaps we
can get it working for you. But not on 2.4 for awhile.

-M

-
To unsubscribe from this list: send 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?] RAMFS

[Mike Galbraith]

On Sat, 3 Feb 2001, Mike Galbraith wrote:

> Hi,
> 
> With the patch below...

However, tmpfs appears to cover the functionality provided by ramfs.
Are there any uses for ramfs which can't be handled by tmpfs?

The only thing I could think of was "what if you don't have a
swap device up and running".  Seems it doesn't need one :))

-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: Every Make option ends in error.

[Rusty Russell]

In message <[EMAIL PROTECTED]> you write:
> Or even better, if you are going to patch, do a 'cp -rl', and your new

ITYM cp -al, and the main benifit (for me) is that diff -urN takes ~10
seconds (cold cache), rather than minutes.

Rusty.
--
Premature optmztion is rt of all evl. --DK
-
To unsubscribe from this list: send 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: Promise PDC20265, VIA KT133 and corruption

[Nathan Walp]

Petr Vandrovec wrote:
> 
> Hi Andre,
>   if you remember, last week I complained that Promise corrupts data
> when I copy them from hdh to hde. Today I did some more experiments
> (running 2.4.1-ac1) and found:
> 
> 1) Debian sid's 'cmp' prints incorrect offsets when files differ
>in more than one place if distance > cmp buffer size :-(
> 2) When I read data from hdh (UDMA2 Toshiba) sometime last four
>bytes of 4KB page (== probably last 4 bytes of read request)
>are not read at all and old contents of page is left here
>(it happens about once per 20MB read; and in about 1% of
>these last 8 bytes of page are incorrect).
>I have no idea whether promise or KT133 is at fault, but
>it for sure does not happen under Windows...
> 3) During write some corruption can happen on either hde (IBM
>DTLA-307045 running UDMA5) or hdh - it looks like that
>data are shifted on HDD, as fsck then complains about
>imagic set, dtime set while inode not deleted and so on,
>and then it cleaned inodes 178200-178300 from my hde :-(
>Fortunately they were mostly in old kernel trees,
>not in current data (except one inode, which was just
>created by dpkg)
> 4) So I compiled kernel without IDE DMA support at all and now
>everything works at PIO4 without any corruption...
> 
>   If anybody has any idea what I should try to get UDMA to
> work under Linux here...
> 
> lspci:
> 
> 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02)
> 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
> 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22)
> 00:04.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10)
> 00:04.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10)
> 00:04.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10)
> 00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
> 00:0a.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 06)
> 00:11.0 Unknown mass storage controller: Promise Technology, Inc. 20265 (rev 02)
> 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 04)
> 
> Thanks,
> Petr Vandrovec
> [EMAIL PROTECTED]


I've got a very similar setup, but i've got a SCSI hard drive as well. 
In copying a rather large file (600+ MB) from my home directory (on the
SCSI drive) to my IDE drive (on the promise controller, ata/100).  scsi
drive is ext2, the ide drive is vfat (basically to share movies and
music w/ windoze).  First try at copying, I got corruption.  Second try,
cp segfaulted.  Looked, and sure enough, had an oops sitting for me in
syslog, so here it is:

ksymoops 2.3.7 on i686 2.4.1-ac2.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.1-ac2/ (default)
 -m /boot/System.map-2.4.1-ac2 (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.

Feb  3 23:38:01 patience kernel: Unable to handle kernel paging request
at virtual address 81180b00
Feb  3 23:38:01 patience kernel: c0123a60
Feb  3 23:38:01 patience kernel: *pde = 
Feb  3 23:38:01 patience kernel: Oops: 0002
Feb  3 23:38:01 patience kernel: CPU:0
Feb  3 23:38:01 patience kernel: EIP:   
0010:[__remove_inode_page+48/96]
Feb  3 23:38:01 patience kernel: EFLAGS: 00010202
Feb  3 23:38:01 patience kernel: eax: c102b228   ebx: c1202058   ecx:
0106   edx: 81180b00
Feb  3 23:38:01 patience kernel: esi: c532a828   edi: c1202058   ebp:
1532   esp: cc8c5eac
Feb  3 23:38:01 patience kernel: ds: 0018   es: 0018   ss: 0018
Feb  3 23:38:01 patience kernel: Process cp (pid: 483,
stackpage=cc8c5000)
Feb  3 23:38:01 patience kernel: Stack: c1202074 c012a476 c1202058
c0309758 c0309930 0002  c012bc18
Feb  3 23:38:01 patience kernel:c0309758  c0309938
  c012bd80 c030992c 
Feb  3 23:38:01 patience kernel:0002 0001 
cc8c5f58 15ece000  0005 0001
Feb  3 23:38:01 patience kernel: Call Trace: [reclaim_page+790/1024]
[__alloc_pages_limit+120/176] [__alloc_pages+304/736]
[generic_file_write+724/1408] []
[default_fat_file_write+34/80]
Feb  3 23:38:01 patience kernel: Code: 89 02 8b 43 10 8b 53 34 c7 43 08
00 00 00 00 85 c0 74 03 89
Using defaults from ksymoops -t elf32-i386 -a i386

Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   89 02   

[OT] Major Clock Drift

[Josh Myer]

Hello all,

I know this _really_ isn't the forum for this, but a friend of mine has
noticed major, persistent clock drift over time. After several weeks, the
clock is several minutes slow (always slow). Any thoughts on the
cause? (Google didn't show up anything worthwhile in the first couple of
pages, so i gave up).

I assume it doens't matter what the mains frequency is (since we're
pulling from a crystal for this anyway). I think i'd heard mention of
problems with other interrupts interrupting the timer often enough that
the time got slowed down, but really?

It's a relatively new Athlon, not sure of the mobo model. If it is a
hardware problem, i'll find out the model, since that would strike me as
an errata =)

Thanks for indulging an idle hardware question
--
/jbm, but you can call me Josh. Really, you can.
  Rap-Rock is neither Modern nor Alternative.
 Not that I'm bitter.

-
To unsubscribe from this list: send 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.2-pre1

[Linus Torvalds]

Mainly a number of small details and some driver updates. The socket
datagram handling one is important, and has already been posted separately
here on linux-kernel. The VIA driver update is rather important if you
have one of the newer VIA chipsets.

Linus


-pre1:
 - XMM: don't allow illegal mxcsr values
 - ACPI: handle non-existent battery strings gracefully
 - Compaq Smart Array driver update
 - Kanoj Sarcar: serial console hardware flow control support
 - ide-cs: revert toc-valid cache checking in 2.4.1
 - Vojtech Pavlik: update via82cxxx driver to handle the vt82c686
 - raid5 graceful failure handling fix
 - ne2k-pci: enable device before asking the irq number
 - sis900 driver update
 - riva FB driver update
 - fix silly inode hashing pessimization
 - add SO_ACCEPTCONN for SuS
 - remove modinfo hack workaround, all newer modutils do it correctly
 - datagram socket shutdown fix
 - mark process as running when it takes a page-fault

-
To unsubscribe from this list: send 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: PS hanging in 2.4.1 - HAPPENING NOW!!!

[Shawn Starr]

Ok, ive added change. Im starting the applications that were running at the time of 
the hang. XMMS, gnomeicu, a few consoles etc.

Let's see what happens.

Shawn.

Shawn Starr wrote:

> Adding now.. I just applied 2.4.1-ac2 and now i'll add this code snipet to the 
>source. It might take 4 days or so for the bug to show itself. At least, unless it 
>triggers eariler (?)
>
> Restarting...
>
> Shawn.
>
> Linus Torvalds wrote:
>
> > On Sat, 3 Feb 2001, [EMAIL PROTECTED] wrote:
> > >
> > >Feb  3 17:57:08 coredump kernel: gnomeicu  S CD17 0  9338  1
>(NOTLB)9340  9332
> > >Feb  3 17:57:08 coredump kernel: Call Trace: [search_by_key+203/3232] 
>[search_for_position_by_key+170/916] [make_cpu_key+57/64] 
>[_get_block_create_0+136/1072] [_get_block_create_0+162/1072] 
>[remove_wait_queue+40/48] [__wait_on_buffer+128/140]
> > >Feb  3 17:57:08 coredump kernel:[] 
>[reiserfs_get_block+158/3408] [search_for_position_by_key+170/916] 
>[search_for_position_by_key+570/916] [make_cpu_key+57/64] [kmem_cache_alloc+75/116] 
>[get_unused_buffer_head+52/144] [create_buffers+96/444]
> > >Feb  3 17:57:08 coredump kernel:[block_read_full_page+246/552] 
>[add_to_page_cache_unique+202/212] [reiserfs_readpage+15/20] 
>[reiserfs_get_block+0/3408] [read_cluster_nonblocking+258/324] 
>[filemap_nopage+332/1032] [do_no_page+77/192] [handle_mm_fault+232/340]
> > >Feb  3 17:57:08 coredump kernel:[do_page_fault+312/1020] 
>[do_page_fault+0/1020] [start_request+388/508] [intlat_local_irq_disable+16/20] 
>[ide_do_request+685/752] [schedule+639/964] [remove_wait_queue+40/48] 
>[error_code+52/64]
> > >Feb  3 17:57:09 coredump kernel:[__generic_copy_from_user+52/60] 
>[opost_block+67/384] [handle_mm_fault+232/340] [add_wait_queue+59/68] 
>[write_chan+365/516] [tty_write+341/448] [write_chan+0/516] [sys_write+143/196]
> > >Feb  3 17:57:09 coredump kernel:[system_call+62/80]
> >
> > Ok, the above seems to be the culprit here.
> >
> > Note how the thing is in TASK_INTERRUPTIBLE (S) sleep somewhere in the
> > reiserfs code..
> >
> > Debugging this is slightly harder than I'd like, because the "call trace"
> > is really not a trace, but actually just a dump of the stack of everything
> > that looks like a kernel address. And a lot of it is crap - stuff left
> > over by previous calls that hasn't gotten overwritten and is visible
> > because some function has a large stack footprint (lots of local variables
> > that end up not being very used and let things show through).
> >
> > Anyway, what I _think_ is the cleaned-up stacktrace is
> >
> > [reiserfs_get_block+158/3408]
> > [reiserfs_readpage+15/20]
> > [read_cluster_nonblocking+258/324]
> > [filemap_nopage+332/1032]
> > [do_no_page+77/192]
> > [handle_mm_fault+232/340]
> > [do_page_fault+312/1020]
> > [error_code+52/64]
> > [__generic_copy_from_user+52/60]
> > [opost_block+67/384]
> > [handle_mm_fault+232/340]
> > [add_wait_queue+59/68]
> > [write_chan+365/516]
> > [tty_write+341/448]
> > [write_chan+0/516]
> > [sys_write+143/196]
> > [system_call+62/80]
> >
> > and what is interesting is that you got a page fault while you were
> > copying stuff in to the tty layer. Which happens with TASK_INTERRUPTIBLE
> > sleep. Now, the page fault code never clears that, so we enter reiserfs
> > still "sleeping", and reiserfs will do a
> >
> > if (need_resched(current))
> > schedule();
> >
> > which won't do what reiserfs _wants_ it to do at all. Because if
> > task->state is TASK_INTERRUPTIBLE, the above will go to sleep, not just
> > cause a nice reschedule. And we'll be sleeping with the task MM semaphore
> > held - only to wake up if somebody were to signal us or something.
> >
> > If you can re-create this hang, could you please try to add this single
> > line to the top of "handle_mm_fault()" in mm/memory.c (after the variable
> > declarations, of course):
> >
> > current->state = TASK_RUNNING;
> >
> > which just means that if we get a page fault while we're half asleep, it
> > will be safe to do a schedule() without explicitly setting the process
> > running again.
> >
> > 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/
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

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

Re: PS hanging in 2.4.1 - HAPPENING NOW!!!

[Shawn Starr]

Adding now.. I just applied 2.4.1-ac2 and now i'll add this code snipet to the source. 
It might take 4 days or so for the bug to show itself. At least, unless it triggers 
eariler (?)

Restarting...

Shawn.


Linus Torvalds wrote:

> On Sat, 3 Feb 2001, [EMAIL PROTECTED] wrote:
> >
> >Feb  3 17:57:08 coredump kernel: gnomeicu  S CD17 0  9338  1
>(NOTLB)9340  9332
> >Feb  3 17:57:08 coredump kernel: Call Trace: [search_by_key+203/3232] 
>[search_for_position_by_key+170/916] [make_cpu_key+57/64] 
>[_get_block_create_0+136/1072] [_get_block_create_0+162/1072] 
>[remove_wait_queue+40/48] [__wait_on_buffer+128/140]
> >Feb  3 17:57:08 coredump kernel:[] [reiserfs_get_block+158/3408] 
>[search_for_position_by_key+170/916] [search_for_position_by_key+570/916] 
>[make_cpu_key+57/64] [kmem_cache_alloc+75/116] [get_unused_buffer_head+52/144] 
>[create_buffers+96/444]
> >Feb  3 17:57:08 coredump kernel:[block_read_full_page+246/552] 
>[add_to_page_cache_unique+202/212] [reiserfs_readpage+15/20] 
>[reiserfs_get_block+0/3408] [read_cluster_nonblocking+258/324] 
>[filemap_nopage+332/1032] [do_no_page+77/192] [handle_mm_fault+232/340]
> >Feb  3 17:57:08 coredump kernel:[do_page_fault+312/1020] 
>[do_page_fault+0/1020] [start_request+388/508] [intlat_local_irq_disable+16/20] 
>[ide_do_request+685/752] [schedule+639/964] [remove_wait_queue+40/48] 
>[error_code+52/64]
> >Feb  3 17:57:09 coredump kernel:[__generic_copy_from_user+52/60] 
>[opost_block+67/384] [handle_mm_fault+232/340] [add_wait_queue+59/68] 
>[write_chan+365/516] [tty_write+341/448] [write_chan+0/516] [sys_write+143/196]
> >Feb  3 17:57:09 coredump kernel:[system_call+62/80]
>
> Ok, the above seems to be the culprit here.
>
> Note how the thing is in TASK_INTERRUPTIBLE (S) sleep somewhere in the
> reiserfs code..
>
> Debugging this is slightly harder than I'd like, because the "call trace"
> is really not a trace, but actually just a dump of the stack of everything
> that looks like a kernel address. And a lot of it is crap - stuff left
> over by previous calls that hasn't gotten overwritten and is visible
> because some function has a large stack footprint (lots of local variables
> that end up not being very used and let things show through).
>
> Anyway, what I _think_ is the cleaned-up stacktrace is
>
> [reiserfs_get_block+158/3408]
> [reiserfs_readpage+15/20]
> [read_cluster_nonblocking+258/324]
> [filemap_nopage+332/1032]
> [do_no_page+77/192]
> [handle_mm_fault+232/340]
> [do_page_fault+312/1020]
> [error_code+52/64]
> [__generic_copy_from_user+52/60]
> [opost_block+67/384]
> [handle_mm_fault+232/340]
> [add_wait_queue+59/68]
> [write_chan+365/516]
> [tty_write+341/448]
> [write_chan+0/516]
> [sys_write+143/196]
> [system_call+62/80]
>
> and what is interesting is that you got a page fault while you were
> copying stuff in to the tty layer. Which happens with TASK_INTERRUPTIBLE
> sleep. Now, the page fault code never clears that, so we enter reiserfs
> still "sleeping", and reiserfs will do a
>
> if (need_resched(current))
> schedule();
>
> which won't do what reiserfs _wants_ it to do at all. Because if
> task->state is TASK_INTERRUPTIBLE, the above will go to sleep, not just
> cause a nice reschedule. And we'll be sleeping with the task MM semaphore
> held - only to wake up if somebody were to signal us or something.
>
> If you can re-create this hang, could you please try to add this single
> line to the top of "handle_mm_fault()" in mm/memory.c (after the variable
> declarations, of course):
>
> current->state = TASK_RUNNING;
>
> which just means that if we get a page fault while we're half asleep, it
> will be safe to do a schedule() without explicitly setting the process
> running again.
>
> 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/

-
To unsubscribe from this list: send 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: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[John Alvord]

On Sat, 03 Feb 2001 00:57:45 -0800, David Ford <[EMAIL PROTECTED]>
wrote:

>How about a simple patch to the top level makefile that checks the gcc
>version then prints a distinct message ..'this compiler hasn't been approved
>for compiling the kernel', sleeping for one second, then continuing on.  This
>solution doesn't stop compiling and makes a visible indicator without forcing
>anything.

A while ago I worked up a nasty bit of make logic which prompted the
user for yes or no... and then did one thing or the other. You could
ask the user if he REALLY wants to continue and wait for a response.
Following is the model code...
John Alvord
=

_ECHO=@

all:  t0 t1 t2 t3 t4 t5 t6

# prompt for input, must be in a separate rule to unbuffer terminal
# output.
t0:
 $(_ECHO)echo Enter Y or N: \\c

# capture a line of terminal input, copy to a file, tell user
t1:
 $(_ECHO)echo $(shell read ans; echo ans) > ans
 $(_ECHO)echo The answer is \\c
 $(_ECHO)cat ans

# take first character of answer, upper case, store in another file
# then create two files, one for yes and one for no
# the || exit 0 is to mask the potential grep error, which
# would result in an error message even a - was used to ignore error
# and continue. The result is two files, which may be zero byte
t2:
 $(_ECHO)cat ans | cut -c 1-1 | tr 'a-z' 'A-Z' >ans1
 $(_ECHO)rm -f ansy
 $(_ECHO)rm -f ansn
 $(_ECHO)grep Y ans1 > ansy || exit 0
 $(_ECHO)grep N ans1 > ansn || exit 0

# Check for case where neither answer file is > 0 bytes
t3:
 $(_ECHO)test -s ansy || test -s ansn && exit 0; \
 echo Answer [$(shell cat ans)] is neither Y or N! && exit 1

# handle Yes case. Exit if Y answer file is 0 bytes or missing
t4:
 $(_ECHO)test ! -s ansy  && exit 0; \
 echo in YES processing

# handle No case
t5:
 $(_ECHO)test ! -s ansn  && exit 0; \
 echo in NO processing


# remove files used during processing
t6:
 $(_ECHO)rm -f ans
 $(_ECHO)rm -f ans1
 $(_ECHO)rm -f ansn
 $(_ECHO)rm -f ansy

-
To unsubscribe from this list: send 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: PS hanging in 2.4.1 - HAPPENING NOW!!!

[Linus Torvalds]

On Sat, 3 Feb 2001, [EMAIL PROTECTED] wrote:
>
>Feb  3 17:57:08 coredump kernel: gnomeicu  S CD17 0  9338  1
>(NOTLB)9340  9332
>Feb  3 17:57:08 coredump kernel: Call Trace: [search_by_key+203/3232] 
>[search_for_position_by_key+170/916] [make_cpu_key+57/64] 
>[_get_block_create_0+136/1072] [_get_block_create_0+162/1072] 
>[remove_wait_queue+40/48] [__wait_on_buffer+128/140] 
>Feb  3 17:57:08 coredump kernel:[] [reiserfs_get_block+158/3408] 
>[search_for_position_by_key+170/916] [search_for_position_by_key+570/916] 
>[make_cpu_key+57/64] [kmem_cache_alloc+75/116] [get_unused_buffer_head+52/144] 
>[create_buffers+96/444] 
>Feb  3 17:57:08 coredump kernel:[block_read_full_page+246/552] 
>[add_to_page_cache_unique+202/212] [reiserfs_readpage+15/20] 
>[reiserfs_get_block+0/3408] [read_cluster_nonblocking+258/324] 
>[filemap_nopage+332/1032] [do_no_page+77/192] [handle_mm_fault+232/340] 
>Feb  3 17:57:08 coredump kernel:[do_page_fault+312/1020] 
>[do_page_fault+0/1020] [start_request+388/508] [intlat_local_irq_disable+16/20] 
>[ide_do_request+685/752] [schedule+639/964] [remove_wait_queue+40/48] 
>[error_code+52/64] 
>Feb  3 17:57:09 coredump kernel:[__generic_copy_from_user+52/60] 
>[opost_block+67/384] [handle_mm_fault+232/340] [add_wait_queue+59/68] 
>[write_chan+365/516] [tty_write+341/448] [write_chan+0/516] [sys_write+143/196] 
>Feb  3 17:57:09 coredump kernel:[system_call+62/80] 

Ok, the above seems to be the culprit here.

Note how the thing is in TASK_INTERRUPTIBLE (S) sleep somewhere in the
reiserfs code..

Debugging this is slightly harder than I'd like, because the "call trace"
is really not a trace, but actually just a dump of the stack of everything
that looks like a kernel address. And a lot of it is crap - stuff left
over by previous calls that hasn't gotten overwritten and is visible
because some function has a large stack footprint (lots of local variables
that end up not being very used and let things show through).

Anyway, what I _think_ is the cleaned-up stacktrace is

[reiserfs_get_block+158/3408]
[reiserfs_readpage+15/20]
[read_cluster_nonblocking+258/324]
[filemap_nopage+332/1032]
[do_no_page+77/192]
[handle_mm_fault+232/340]
[do_page_fault+312/1020]
[error_code+52/64]
[__generic_copy_from_user+52/60]
[opost_block+67/384]
[handle_mm_fault+232/340]
[add_wait_queue+59/68]
[write_chan+365/516]
[tty_write+341/448]   
[write_chan+0/516]  
[sys_write+143/196]
[system_call+62/80]

and what is interesting is that you got a page fault while you were
copying stuff in to the tty layer. Which happens with TASK_INTERRUPTIBLE
sleep. Now, the page fault code never clears that, so we enter reiserfs
still "sleeping", and reiserfs will do a

if (need_resched(current))
schedule();

which won't do what reiserfs _wants_ it to do at all. Because if
task->state is TASK_INTERRUPTIBLE, the above will go to sleep, not just
cause a nice reschedule. And we'll be sleeping with the task MM semaphore
held - only to wake up if somebody were to signal us or something.

If you can re-create this hang, could you please try to add this single
line to the top of "handle_mm_fault()" in mm/memory.c (after the variable 
declarations, of course):

current->state = TASK_RUNNING;

which just means that if we get a page fault while we're half asleep, it
will be safe to do a schedule() without explicitly setting the process
running again.

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/

Promise PDC20265, VIA KT133 and corruption

[Petr Vandrovec]

Hi Andre,
  if you remember, last week I complained that Promise corrupts data
when I copy them from hdh to hde. Today I did some more experiments
(running 2.4.1-ac1) and found:

1) Debian sid's 'cmp' prints incorrect offsets when files differ
   in more than one place if distance > cmp buffer size :-(
2) When I read data from hdh (UDMA2 Toshiba) sometime last four
   bytes of 4KB page (== probably last 4 bytes of read request)
   are not read at all and old contents of page is left here
   (it happens about once per 20MB read; and in about 1% of
   these last 8 bytes of page are incorrect).
   I have no idea whether promise or KT133 is at fault, but
   it for sure does not happen under Windows...
3) During write some corruption can happen on either hde (IBM
   DTLA-307045 running UDMA5) or hdh - it looks like that
   data are shifted on HDD, as fsck then complains about
   imagic set, dtime set while inode not deleted and so on,
   and then it cleaned inodes 178200-178300 from my hde :-(
   Fortunately they were mostly in old kernel trees,
   not in current data (except one inode, which was just
   created by dpkg)
4) So I compiled kernel without IDE DMA support at all and now
   everything works at PIO4 without any corruption...

  If anybody has any idea what I should try to get UDMA to
work under Linux here...

lspci:

00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22)
00:04.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10)
00:04.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10)
00:04.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10)
00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
00:0a.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 06)
00:11.0 Unknown mass storage controller: Promise Technology, Inc. 20265 (rev 02)
01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 04)

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

Re: Fix dependencies for radio-miropcm20

[Robert Siemer]

Hi Jocelyn!

You wrote:

> I made a very little patch to avoid
> people complaining that the kernel doesn't compile
> properly when trying to use radio miropcm20 driver.
> (I've seen some of this in french newsgroups...)

> -dep_tristate '  Miro PCM20 Radio' CONFIG_RADIO_MIROPCM20 
> $CONFIG_VIDEO_DEV   
> +dep_tristate '  Miro PCM20 Radio' CONFIG_RADIO_MIROPCM20 
> $CONFIG_VIDEO_DEV $CONFIG_SOUND_ACI_MIXER   


This was already discussed some days ago. Arjan said, that the
miropcm20 question comes before the aci question, so this is
useless. - Arjan, this is not true for 'make menuconfig' and 'make
xconfig', isn't it?

Anyway, this solution looks somewhat cleaner to me...
But you can choose on your own:  (:
As the new maintainer I'm offering the patches on

http://www.uni-karlsruhe.de/~Robert.Siemer/Private/

Jocelyn, as my patches also include bugfixes and enhancements
(especially for the miroSOUND pcm20 radio), can you recommend these to
the complaining people. - I want more testers and reports for my
patches...


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

Re: [ANNOUNCE] Linux-NTFS project, first public release

[Michael B. Trausch]

On Sat, 3 Feb 2001, Matthew Fredrickson wrote:
> 
> And just as darkness covers the entire earth, a light comes from the
> clouds.  A voice says, "Behold, this is my beloved son, hear him"
> 
> And then the people didn't need Microsoft anymore.
> 
> :-)
> 

Linux is the way, the truth, and the light, soon people will see that..

===
Michael B. Trausch[EMAIL PROTECTED]
Avid Linux User since April, '96!   AIM:  ML100Smkr

  Contactable via IRC (DALNet) or AIM as ML100Smkr
===

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

Re: [ANNOUNCE] Linux-NTFS project, first public release

[Matthew Fredrickson]

On Sun, Feb 04, 2001 at 01:51:43AM +, Anton Altaparmakov wrote:
> At 02:42 04/02/2001, you wrote:
> >Hell will freeze, and the US will break off from the continental mass and
> >sink into the oceans before I think MS will ever endorse Linux
> >officially.  I could be wrong, but I doubt it.
> 
> Well there is that. But why not think positive. You never know. Miracles 
> sometimes do happen.

And just as darkness covers the entire earth, a light comes from the
clouds.  A voice says, "Behold, this is my beloved son, hear him"

And then the people didn't need Microsoft anymore.

:-)

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

Re: [ANNOUNCE] Linux-NTFS project, first public release

[Anton Altaparmakov]

At 02:42 04/02/2001, you wrote:
>Hell will freeze, and the US will break off from the continental mass and
>sink into the oceans before I think MS will ever endorse Linux
>officially.  I could be wrong, but I doubt it.

Well there is that. But why not think positive. You never know. Miracles 
sometimes do happen.

(-:

Anton


-- 
Anton Altaparmakov  (replace at with @)
Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

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

Re: [ANNOUNCE] Linux-NTFS project, first public release

[Jeff V. Merkey]

On Sun, Feb 04, 2001 at 01:43:54AM +, Anton Altaparmakov wrote:
> At 02:02 04/02/2001, Jeff V. Merkey wrote:
> >On Sun, Feb 04, 2001 at 12:37:16AM +, Anton Altaparmakov wrote:
> >I am noticeable impressed with your ability to address these issues.
> 
> (-:
> 
> >Microsoft would be much happier I am certain with a pure Linux solution
> >for this problem.  They have been incredibly tolerant in allowing
> 
> Believe me, so would I! It's a long way to go to having a fully functional 
> ntfsck Linux utility, but we will get there eventually. And of course, the 
> actual driver is under heavy development both by Yuri Per of Acronis Ltd. 
> and myself at the moment (he is probably doing more than me as he does this 
> as part of a full time job...). In fact I am sitting on a very nice patch 
> for the driver at the moment but want to do some testing before I send it 
> off to Alan as it does quite a lot of fixing including a nasty race I found 
> staring at the code yesterday and several bug fixes and clean ups (or 
> rather rewrites of some functions almost) courtesy of Yuri. So the 
> importance of ntfsfix should become smaller and smaller as time goes on 
> until eventually we won't need it all. (-:
> 
> >me to help customers with trashed drives, but I am sure you are
> >aware that they were only tolerating it since it was helping
> >customers who use both NT and Linux, and even this was quite
> >a stretch they did not have to go.   It's a statement that even in
> >those cases where tey may be helping Linux, they put their customers
> >needs first (this took some convincing on my part).
> 
> Yes, I am aware of that. I very much doubt that Microsoft would be helping 
> Linux without an extremely good reason. I guess the only way part of 
> Microsoft might start working with/on Linux would be if the DOJ would split 
> the company up in two parts OS/Servers and Office apps. If that would 
> happen the Office part would have a growing market interest in a Linux 
> port, which at the moment is out of the question as Office is probably one 
> of the last barriers to a mass user migration to Linux. - Imagine all the 
> office and home environments where Windows is used solely for the purpose 
> of using Microsoft Word/Excel. They could all switch to Linux and many 
> would probably do so if Word/Excel would exist under Linux... It would be 
> very cost effective, too. - Oh well, one can dream. (-;
> 
> >They are very angry at me right now for even doing this in the
> >first place, and I doubt the relationship will ever be back on
> >the keel it was originally, but since I work on Linux almost
> >exslusively now, I do not think it matters.
> 
> While it doesn't matter, I am sure things will improve over time.
> 
> >Good Work, A++.
> 
> Thanks! (-:
> 
> Best regards,
> 
>  Anton
> 
> > > At 01:16 04/02/2001, Jeff V. Merkey wrote:
> > > >To date, I have provided tools to 7,000+ folks who use this driver that
> > > >trash their NTFS partitions.  TRG will discontinue distribution of these
> > > >tools at this point since Anton has a Linux based version.
> > > >
> > > >Please do not email me for any more NT based repair tools for damaged
> > > >NTFS partitions trashed by Linux.  Please contact Andre and use his
> > >
> > > You probably meant Anton in the sentence above...
> > >
> > > >tools instead.  I will inform Microsoft I will no longer be providing
> > > >these tools since Anton now has something that will do the job.
> > >
> > > The NTFS disk edit utility you were providing does quite a lot more since
> > > it is interactive. And my utility doesn't do everything I would like it to
> > > do yet but it does work so I wanted to push a release out of the door 
> > ASAP.
> > > But it doesn't really matter. The NTFS disk editor is a relatively freely
> > > available utility as I found out recently, anyways. It is present on the
> > > Windows NT4 Service Pack 4 CD! It's not mentioned anywhere in the
> > > documentation but it sure is there among the service pack files. I managed
> > > to dig the out in our College computer office and it's now officially 
> > mine.
> > > That has the advantage of not binding you to the license of only using it
> > > for repairing NTFS partitions... (-:
> > >
> > > Best regards,
> > >
> > > Anton
> > >


Hell will freeze, and the US will break off from the continental mass and 
sink into the oceans before I think MS will ever endorse Linux 
officially.  I could be wrong, but I doubt it.  

:-)

Jeff 

> > >
> > > --
> > > Anton Altaparmakov  (replace at with @)
> > > Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
> > > ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
> >-
> >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >the body of a message to [EMAIL PROTECTED]
> >Please read the FAQ at http://www.tux.org/lkml/
> 
> -- 
> Anton Altaparmakov  (replace at with @)
> Linux NTFS Maintainer / WWW: http://sourcef

Re: [ANNOUNCE] Linux-NTFS project, first public release

[Anton Altaparmakov]

At 02:02 04/02/2001, Jeff V. Merkey wrote:
>On Sun, Feb 04, 2001 at 12:37:16AM +, Anton Altaparmakov wrote:
>I am noticeable impressed with your ability to address these issues.

(-:

>Microsoft would be much happier I am certain with a pure Linux solution
>for this problem.  They have been incredibly tolerant in allowing

Believe me, so would I! It's a long way to go to having a fully functional 
ntfsck Linux utility, but we will get there eventually. And of course, the 
actual driver is under heavy development both by Yuri Per of Acronis Ltd. 
and myself at the moment (he is probably doing more than me as he does this 
as part of a full time job...). In fact I am sitting on a very nice patch 
for the driver at the moment but want to do some testing before I send it 
off to Alan as it does quite a lot of fixing including a nasty race I found 
staring at the code yesterday and several bug fixes and clean ups (or 
rather rewrites of some functions almost) courtesy of Yuri. So the 
importance of ntfsfix should become smaller and smaller as time goes on 
until eventually we won't need it all. (-:

>me to help customers with trashed drives, but I am sure you are
>aware that they were only tolerating it since it was helping
>customers who use both NT and Linux, and even this was quite
>a stretch they did not have to go.   It's a statement that even in
>those cases where tey may be helping Linux, they put their customers
>needs first (this took some convincing on my part).

Yes, I am aware of that. I very much doubt that Microsoft would be helping 
Linux without an extremely good reason. I guess the only way part of 
Microsoft might start working with/on Linux would be if the DOJ would split 
the company up in two parts OS/Servers and Office apps. If that would 
happen the Office part would have a growing market interest in a Linux 
port, which at the moment is out of the question as Office is probably one 
of the last barriers to a mass user migration to Linux. - Imagine all the 
office and home environments where Windows is used solely for the purpose 
of using Microsoft Word/Excel. They could all switch to Linux and many 
would probably do so if Word/Excel would exist under Linux... It would be 
very cost effective, too. - Oh well, one can dream. (-;

>They are very angry at me right now for even doing this in the
>first place, and I doubt the relationship will ever be back on
>the keel it was originally, but since I work on Linux almost
>exslusively now, I do not think it matters.

While it doesn't matter, I am sure things will improve over time.

>Good Work, A++.

Thanks! (-:

Best regards,

 Anton

> > At 01:16 04/02/2001, Jeff V. Merkey wrote:
> > >To date, I have provided tools to 7,000+ folks who use this driver that
> > >trash their NTFS partitions.  TRG will discontinue distribution of these
> > >tools at this point since Anton has a Linux based version.
> > >
> > >Please do not email me for any more NT based repair tools for damaged
> > >NTFS partitions trashed by Linux.  Please contact Andre and use his
> >
> > You probably meant Anton in the sentence above...
> >
> > >tools instead.  I will inform Microsoft I will no longer be providing
> > >these tools since Anton now has something that will do the job.
> >
> > The NTFS disk edit utility you were providing does quite a lot more since
> > it is interactive. And my utility doesn't do everything I would like it to
> > do yet but it does work so I wanted to push a release out of the door 
> ASAP.
> > But it doesn't really matter. The NTFS disk editor is a relatively freely
> > available utility as I found out recently, anyways. It is present on the
> > Windows NT4 Service Pack 4 CD! It's not mentioned anywhere in the
> > documentation but it sure is there among the service pack files. I managed
> > to dig the out in our College computer office and it's now officially 
> mine.
> > That has the advantage of not binding you to the license of only using it
> > for repairing NTFS partitions... (-:
> >
> > Best regards,
> >
> > Anton
> >
> >
> > --
> > Anton Altaparmakov  (replace at with @)
> > Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
> > ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [EMAIL PROTECTED]
>Please read the FAQ at http://www.tux.org/lkml/

-- 
Anton Altaparmakov  (replace at with @)
Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

-
To unsubscribe from this list: send 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: PS hanging in 2.4.1 - HAPPENING NOW!!!

[Marko Kreen]

On Sat, Feb 03, 2001 at 08:06:08PM -0500, Shawn Starr wrote:
> Wasn't on shutdown though ;-)

The 'shutdown' as in 'process shutdown' ? _Not_ machine
shutdown.

> 
> I was just about to receive a message when things started to lock up slowly.
> Then everything else followed.
> 
> Marko Kreen wrote:
> 
> > On Sat, Feb 03, 2001 at 05:48:36PM -0500, Shawn Starr wrote:
> > > [root@coredump spstarr]# killall -9 gnomeicu
> > >
> > > ... waiting...
> >
> > Could you try it on 2.4.2ac2, I guess its this item:
> >
> > o   Fix datagram hang on shutdown   (Alexey
> > Kuznetsov)
> >
> > --
> > marko
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [EMAIL PROTECTED]
> > Please read the FAQ at http://www.tux.org/lkml/
> 

-- 
marko

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

Re: [ANNOUNCE] Linux-NTFS project, first public release

[Jeff V. Merkey]

On Sun, Feb 04, 2001 at 12:37:16AM +, Anton Altaparmakov wrote:


Anton,

I am noticeable impressed with your ability to address these issues.
Microsoft would be much happier I am certain with a pure Linux solution
for this problem.  They have been incredibly tolerant in allowing 
me to help customers with trashed drives, but I am sure you are 
aware that they were only tolerating it since it was helping 
customers who use both NT and Linux, and even this was quite 
a stretch they did not have to go.   It's a statement that even in 
those cases where tey may be helping Linux, they put their customers
needs first (this took some convincing on my part). 

They are very angry at me right now for even doing this in the 
first place, and I doubt the relationship will ever be back on 
the keel it was originally, but since I work on Linux almost 
exslusively now, I do not think it matters.  

Good Work, A++.

Jeff 


> At 01:16 04/02/2001, Jeff V. Merkey wrote:
> >To date, I have provided tools to 7,000+ folks who use this driver that
> >trash their NTFS partitions.  TRG will discontinue distribution of these
> >tools at this point since Anton has a Linux based version.
> >
> >Please do not email me for any more NT based repair tools for damaged
> >NTFS partitions trashed by Linux.  Please contact Andre and use his
> 
> You probably meant Anton in the sentence above...
> 
> >tools instead.  I will inform Microsoft I will no longer be providing
> >these tools since Anton now has something that will do the job.
> 
> The NTFS disk edit utility you were providing does quite a lot more since 
> it is interactive. And my utility doesn't do everything I would like it to 
> do yet but it does work so I wanted to push a release out of the door ASAP. 
> But it doesn't really matter. The NTFS disk editor is a relatively freely 
> available utility as I found out recently, anyways. It is present on the 
> Windows NT4 Service Pack 4 CD! It's not mentioned anywhere in the 
> documentation but it sure is there among the service pack files. I managed 
> to dig the out in our College computer office and it's now officially mine. 
> That has the advantage of not binding you to the license of only using it 
> for repairing NTFS partitions... (-:
> 
> Best regards,
> 
> Anton
> 
> 
> -- 
> Anton Altaparmakov  (replace at with @)
> Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
> ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
-
To unsubscribe from this list: send 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: PS hanging in 2.4.1 - HAPPENING NOW!!!

[Shawn Starr]

Wasn't on shutdown though ;-)

I was just about to receive a message when things started to lock up slowly.
Then everything else followed.

Marko Kreen wrote:

> On Sat, Feb 03, 2001 at 05:48:36PM -0500, Shawn Starr wrote:
> > [root@coredump spstarr]# killall -9 gnomeicu
> >
> > ... waiting...
>
> Could you try it on 2.4.2ac2, I guess its this item:
>
> o   Fix datagram hang on shutdown   (Alexey
> Kuznetsov)
>
> --
> marko
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

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

Re: PS hanging in 2.4.1 - HAPPENING NOW!!!

[Marko Kreen]

On Sat, Feb 03, 2001 at 05:48:36PM -0500, Shawn Starr wrote:
> [root@coredump spstarr]# killall -9 gnomeicu
> 
> ... waiting...


Could you try it on 2.4.2ac2, I guess its this item:

o   Fix datagram hang on shutdown   (Alexey
Kuznetsov)

-- 
marko

-
To unsubscribe from this list: send 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: ATAPI CDRW which doesn't work

[Marko Kreen]

On Sat, Feb 03, 2001 at 11:05:44PM +0100, [EMAIL PROTECTED] wrote:
> Hi,
> 
> I've never could make this CDRW ATAPI to work, if someone could
> provide me any clue about the baby. I just said that people on the
> kernel mailing list may care of its but. It looks like the baby didn't
> even noticed. ;-)

Compile in options 'SCSI generic', 'SCSI cdrom and 'SCSI
emulation support' then add 'hdb=scsi' to kernel parameters.

Now you can use it as SCSI cdrom, and cd-writers recognize it
too.  Eg. for cdrecord you should probably put 'dev=0,0,0' to
command line (I assume you have no other SCSI controller).


-- 
marko

-
To unsubscribe from this list: send 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: [reiserfs-list] Re: VM brokenness, possibly related to reiserfs

[David Ford]

Chris Mason wrote:

> 
> On Thursday, February 01, 2001 02:16:43 PM -0200 Rik van Riel 
><[EMAIL PROTECTED]> wrote:
> 
>> About the system hanging completely, I wonder if it goes
>> away by pressing sysrq-S (sync all disks). If it does,
>> maybe Reiserfs was blocking all the pages in the inactive
>> list from being written because one of the active pages
>> (not a replacement candidate) needed to be written out
>> first?  Or does the Reiserfs ->writepage() function handle
>> this?
> 

In answer to Rik's question, no, sysrq-S doesn't fix it.  The sound of 
the disk grind changes momentarily then it resumes.

> In most cases, the reiserfs writepage func is the same as block_write_full_page.  
>The only difference should come when a packed tail has been mmap'd.
> 
> Since JOURNAL_MAX_BATCH was at 100, the log should have only pinned 400k.  More 
>blocks could be pinned, but kreiserfsd should be in the process of flushing those.
> 
> I've been trying out a few things to send memory pressure down to reiserfs, but they 
>have mostly been based on the code to make fs/buffer.c use writepage for flushing.  I 
>should have done something simple first, I'll start on that now.
> 
> -chris


http://stuph.org/VM/ is back up, no thanks to the network solutions.  
The files listed there have all the relevant backtraces.

-d


-
To unsubscribe from this list: send 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: Better battery info/status files

[Albert D. Cahalan]

>> The units seem to vary. I suggest using fundamental SI units.
>> That would be meters, kilograms, seconds, and maybe a very
>> few others -- my memory fails me on this.
>
> There are lots of SI units, one for each physical dimension
> that can be measured.  Some of the ones that might apply here are:
>
> - Volts
> - Coulombs
> - Watts
> - Amperes
> - Seconds
> - Joules

No, these are not all fundamental.

1 Joule == 1 newton * 1 meter

The newton isn't fundamental either. It is defined in terms
of meters, seconds, and kilograms.

So if I've not mucked something up, 1 J == 1 m*kg*m/s/s.

Units get ugly when arbitrary powers of 10 get thrown in,
and worse with random odd constants. Amperes have a 2.0e-7
in the definition.

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

Re: [ANNOUNCE] Linux-NTFS project, first public release

[Anton Altaparmakov]

At 01:16 04/02/2001, Jeff V. Merkey wrote:
>To date, I have provided tools to 7,000+ folks who use this driver that
>trash their NTFS partitions.  TRG will discontinue distribution of these
>tools at this point since Anton has a Linux based version.
>
>Please do not email me for any more NT based repair tools for damaged
>NTFS partitions trashed by Linux.  Please contact Andre and use his

You probably meant Anton in the sentence above...

>tools instead.  I will inform Microsoft I will no longer be providing
>these tools since Anton now has something that will do the job.

The NTFS disk edit utility you were providing does quite a lot more since 
it is interactive. And my utility doesn't do everything I would like it to 
do yet but it does work so I wanted to push a release out of the door ASAP. 
But it doesn't really matter. The NTFS disk editor is a relatively freely 
available utility as I found out recently, anyways. It is present on the 
Windows NT4 Service Pack 4 CD! It's not mentioned anywhere in the 
documentation but it sure is there among the service pack files. I managed 
to dig the out in our College computer office and it's now officially mine. 
That has the advantage of not binding you to the license of only using it 
for repairing NTFS partitions... (-:

Best regards,

Anton


-- 
Anton Altaparmakov  (replace at with @)
Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

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

accept

[Mathieu Dube]

What does it typically mean when accept returns 0
and that the perror outputs "Interupted system call"??

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

Re: [ANNOUNCE] Linux-NTFS project, first public release

[Jeff V. Merkey]

On Sat, Feb 03, 2001 at 06:14:33PM -0600, [EMAIL PROTECTED] wrote:
> 
> Thank goodness, it's about time.  :-)


To date, I have provided tools to 7,000+ folks who use this driver that
trash their NTFS partitions.  TRG will discontinue distribution of these 
tools at this point since Anton has a Linux based version.  

Please do not email me for any more NT based repair tools for damaged
NTFS partitions trashed by Linux.  Please contact Andre and use his 
tools instead.  I will inform Microsoft I will no longer be providing 
these tools since Anton now has something that will do the job.

:-)

Jeff

> 
> On Sat, Feb 03, 2001 at 07:08:44PM +, Anton Altaparmakov wrote:
> > This is to announce the first public release of the Linux-NTFS project 
> > hosted on sourceforge. The project page, where you can download the source 
> > code tar ball or rpm as well as precompiled RPMs for RedHat Linux 7.0 (i386 
> > architecture only), is:
> >  http://sourceforge.net/projects/linux-ntfs/
> > You can also use the CVS server if you prefer...
> > Note, that you need the kernel headers installed to compile linux-ntfs 
> > source (probably you will need 2.4.x kernel headers and not 2.2.x ones but 
> > I haven't actually checked whether it works with 2.2.x or not).
> > 
> > The first release contains the all new and wonderful ntfsfix utility, which 
> > repairs some of the damage that the current Linux NTFS driver does when 
> > writing to an NTFS partition.
> > 
> > If you are doing any writing to NTFS partitions using the Linux NTFS driver 
> > this is an absolute *MUST* at the present time. It won't solve all 
> > problems, but it goes quite some way to prevent data corruption.
> > 
> > Run it after dismounting your NTFS partition in Linux but before rebooting 
> > into Windows NT/2000.
> > 
> > Note, after running the utility, when Windows boots up it will run an 
> > automatic chkdsk on the partition which will finish fixing the damage done 
> > by the Linux NTFS driver without corrupting the written data or any other 
> > data (as long as the Linux NTFS driver hasn't corrupted something beyond 
> > repair, obviously).
> > 
> > For amusement value, the first release also includes the ntfsdump_logfile 
> > utility which when used on an NTFS partition will display information about 
> > the journal ($LogFile) of that partition.
> > 
> > Finally both these utilities make use of the also included NTFS library 
> > which offer NTFS access to open source programs. It is currently under 
> > heavy development and the API is not going to remain as it is so don't use 
> > it yet for your own programs.
> > 
> > For everyone interested in NTFS on-disk structures and functionality, you 
> > will find the doc directory and especially the include directory to be of 
> > great interest as the later includes header files with all known to me NTFS 
> > structures. I still haven't gone through all the NTFS information that is 
> > available so they are considered work in progress but are fairly complete I 
> > thing. Most people will probably find that the $LogFile structures have 
> > never been published before anywhere and now we have the restart area 
> > structure definitions.
> > 
> > Any problems compiling/running the utilities, just give me a shout, or even 
> > better submit bug reports on the project page!
> > 
> > Enjoy!
> > 
> > Anton
> > 
> > 
> > -- 
> > "Intelligence is the ability to avoid doing work, yet get the work done". - 
> > Linus Torvalds
> > -- 
> > Anton Altaparmakov  (replace at with @)
> > Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
> > ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
> > 
> > -
> > To unsubscribe from this list: send 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/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[SoftwareRAID in 2.4.1] md_import_device() returned -22

[Art Boulatov]

Hi,

Could anybody please help me to resolve why this error is returned?
(md_import_device() returned -22)

I'm trying to setup software RAID0
on Asus CUR-DLS (dual channel ULTRA2 SCSI - sym53c896).

kernel is pure 2.4.1(SMP),
with devfs, sym53c8xx and raid0 support linked in.

raidtools are 19990824-0.90 from kernel.org.

Here is /etc/raidtab:
-
raiddev /dev/md/0

raid-level  0

persistent-superblock   1

chunk-size  16

nr-raid-disks   2

device  /dev/scsi/host0/bus0/target0/lun0/part1
raid-disk   0

device  /dev/scsi/host0/bus0/target1/lun0/part1
raid-disk   1

#same bus because I have only one cable right now :)

-

And here is what I got with "mkraid /dev/md/0":
-
handling MD device /dev/md/0
analyzing super-block
disk 0: /dev/scsi/host0/bus0/target0/lun0/part1, 17921008kB, raid 
superblock at 17920896kB
disk 1: /dev/scsi/host0/bus0/target1/lun0/part1, 17921008kB, raid 
superblock at 17920896kB
mkraid: aborted, see the syslog and /proc/mdstat for potential clues.
--

And syslog says:

modprobe: modprobe: Can't locate module block-major-8
kernel: md: could not lock scsi/host0/bus0/target0/lun0/part1, 
zero-size? Marking faulty.
kernel: md: error, md_import_device() returned -22
---

Is that "modprobe" line causing problem?
But I have compiled scsi driver in...

Or is that a devfs issue or am I doing anything wrong?

I would really be glad to get some pointers to the answer,
since I can't figure that out myself.

Thanks a lot,
Art.

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

Re: [ANNOUNCE] Linux-NTFS project, first public release

[Jeff V. Merkey]

On Sat, Feb 03, 2001 at 06:14:33PM -0600, [EMAIL PROTECTED] wrote:
> 
> Thank goodness, it's about time.  :-)
> 


Amen.  

Jeff

> On Sat, Feb 03, 2001 at 07:08:44PM +, Anton Altaparmakov wrote:
> > This is to announce the first public release of the Linux-NTFS project 
> > hosted on sourceforge. The project page, where you can download the source 
> > code tar ball or rpm as well as precompiled RPMs for RedHat Linux 7.0 (i386 
> > architecture only), is:
> >  http://sourceforge.net/projects/linux-ntfs/
> > You can also use the CVS server if you prefer...
> > Note, that you need the kernel headers installed to compile linux-ntfs 
> > source (probably you will need 2.4.x kernel headers and not 2.2.x ones but 
> > I haven't actually checked whether it works with 2.2.x or not).
> > 
> > The first release contains the all new and wonderful ntfsfix utility, which 
> > repairs some of the damage that the current Linux NTFS driver does when 
> > writing to an NTFS partition.
> > 
> > If you are doing any writing to NTFS partitions using the Linux NTFS driver 
> > this is an absolute *MUST* at the present time. It won't solve all 
> > problems, but it goes quite some way to prevent data corruption.
> > 
> > Run it after dismounting your NTFS partition in Linux but before rebooting 
> > into Windows NT/2000.
> > 
> > Note, after running the utility, when Windows boots up it will run an 
> > automatic chkdsk on the partition which will finish fixing the damage done 
> > by the Linux NTFS driver without corrupting the written data or any other 
> > data (as long as the Linux NTFS driver hasn't corrupted something beyond 
> > repair, obviously).
> > 
> > For amusement value, the first release also includes the ntfsdump_logfile 
> > utility which when used on an NTFS partition will display information about 
> > the journal ($LogFile) of that partition.
> > 
> > Finally both these utilities make use of the also included NTFS library 
> > which offer NTFS access to open source programs. It is currently under 
> > heavy development and the API is not going to remain as it is so don't use 
> > it yet for your own programs.
> > 
> > For everyone interested in NTFS on-disk structures and functionality, you 
> > will find the doc directory and especially the include directory to be of 
> > great interest as the later includes header files with all known to me NTFS 
> > structures. I still haven't gone through all the NTFS information that is 
> > available so they are considered work in progress but are fairly complete I 
> > thing. Most people will probably find that the $LogFile structures have 
> > never been published before anywhere and now we have the restart area 
> > structure definitions.
> > 
> > Any problems compiling/running the utilities, just give me a shout, or even 
> > better submit bug reports on the project page!
> > 
> > Enjoy!
> > 
> > Anton
> > 
> > 
> > -- 
> > "Intelligence is the ability to avoid doing work, yet get the work done". - 
> > Linus Torvalds
> > -- 
> > Anton Altaparmakov  (replace at with @)
> > Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
> > ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
> > 
> > -
> > To unsubscribe from this list: send 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/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Linux-NTFS project, first public release

[lists]

Thank goodness, it's about time.  :-)

On Sat, Feb 03, 2001 at 07:08:44PM +, Anton Altaparmakov wrote:
> This is to announce the first public release of the Linux-NTFS project 
> hosted on sourceforge. The project page, where you can download the source 
> code tar ball or rpm as well as precompiled RPMs for RedHat Linux 7.0 (i386 
> architecture only), is:
>  http://sourceforge.net/projects/linux-ntfs/
> You can also use the CVS server if you prefer...
> Note, that you need the kernel headers installed to compile linux-ntfs 
> source (probably you will need 2.4.x kernel headers and not 2.2.x ones but 
> I haven't actually checked whether it works with 2.2.x or not).
> 
> The first release contains the all new and wonderful ntfsfix utility, which 
> repairs some of the damage that the current Linux NTFS driver does when 
> writing to an NTFS partition.
> 
> If you are doing any writing to NTFS partitions using the Linux NTFS driver 
> this is an absolute *MUST* at the present time. It won't solve all 
> problems, but it goes quite some way to prevent data corruption.
> 
> Run it after dismounting your NTFS partition in Linux but before rebooting 
> into Windows NT/2000.
> 
> Note, after running the utility, when Windows boots up it will run an 
> automatic chkdsk on the partition which will finish fixing the damage done 
> by the Linux NTFS driver without corrupting the written data or any other 
> data (as long as the Linux NTFS driver hasn't corrupted something beyond 
> repair, obviously).
> 
> For amusement value, the first release also includes the ntfsdump_logfile 
> utility which when used on an NTFS partition will display information about 
> the journal ($LogFile) of that partition.
> 
> Finally both these utilities make use of the also included NTFS library 
> which offer NTFS access to open source programs. It is currently under 
> heavy development and the API is not going to remain as it is so don't use 
> it yet for your own programs.
> 
> For everyone interested in NTFS on-disk structures and functionality, you 
> will find the doc directory and especially the include directory to be of 
> great interest as the later includes header files with all known to me NTFS 
> structures. I still haven't gone through all the NTFS information that is 
> available so they are considered work in progress but are fairly complete I 
> thing. Most people will probably find that the $LogFile structures have 
> never been published before anywhere and now we have the restart area 
> structure definitions.
> 
> Any problems compiling/running the utilities, just give me a shout, or even 
> better submit bug reports on the project page!
> 
> Enjoy!
> 
> Anton
> 
> 
> -- 
> "Intelligence is the ability to avoid doing work, yet get the work done". - 
> Linus Torvalds
> -- 
> Anton Altaparmakov  (replace at with @)
> Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
> ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Better battery info/status files

[Jonathan Morton]

>The units seem to vary. I suggest using fundamental SI units.
>That would be meters, kilograms, seconds, and maybe a very
>few others -- my memory fails me on this.

There are lots of SI units, one for each physical dimension that can be
measured.  Some of the ones that might apply here are:

- Volts
- Coulombs
- Watts
- Amperes
- Seconds
- Joules

Some non-SI units that may be acceptable in this context due to common usage:

- Watt-hours (should strictly be joules for this measurement)

--
from: Jonathan "Chromatix" Morton
mail: [EMAIL PROTECTED]  (not for attachments)
big-mail: [EMAIL PROTECTED]
uni-mail: [EMAIL PROTECTED]

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-BEGIN GEEK CODE BLOCK-
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+
-END GEEK CODE BLOCK-


-
To unsubscribe from this list: send 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: Better battery info/status files

[Russell King]

Albert D. Cahalan writes:
> The units seem to vary. I suggest using fundamental SI units.
> That would be meters, kilograms, seconds, and maybe a very
> few others -- my memory fails me on this.

iirc, SI comes from France, and therefore it should be "metres"

[flames to /dev/null please] ;)

--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
 http://www.arm.linux.org.uk/personal/aboutme.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/

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Miles Lane]

Jeff Garzik wrote:
> 
> On Fri, 2 Feb 2001, Miles Lane wrote:
> > I asked David Hinds to write up an outline of the things that
> > will be needed to get PCMCIA support cleanly and completely
> > integrated into the kernel tree.
> >
> > David has expressed that he'll not be able to participate in
> > this work.  He has his hands full with his day job and his
> > role as maintainer/developer of the pcmcia-cs package.
> [...]
> > Anyone willing to sign up for some of this effort?
> 
> I'll convert all the network drivers once a design is agreed upon.

Would you write up a proposal for this design that we could work
from to come to a agreed design?  You are probably the best person
to start this process.

Thanks!
Miles
-
To unsubscribe from this list: send 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: [reiserfs-list] Re: ReiserFS Oops (2.4.1, deterministic, symlink

[Albert D. Cahalan]

Alan Cox writes:
> [Albert Cahalan]
>> David Woodhouse writes:

>>>  -a "$CC" = "gcc"
>> 
>> Not worth it; they should upgrade the local gcc too.
>> If anything, they are getting a reminder that they need.
>
> The local gcc has no bearing on the compiler. The local
> compiler might not even be gcc - eg if they are cross
> building off non Linux systems

I know, and it still doesn't matter. So we test Solaris cc.
If it happens to have the same bug as gcc 2.96, then it is
broken and ought to be replaced.

I wouldn't want "menuconfig" messed up by a broken compiler,
even if I'm cross-compiling from HP-UX to sh4 Linux.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RAID autodetect and 2.4.1

[Chris]

> Hi,
> I have a server with RAID1 partitions with linux 2.4.1 (stock,
> self-compiled) installed.  It was easy to create the RAID partitions
> but when booting, no auto-detection is successful.  The kernel says
> that autodetect is running, then done, but nothing is auto-detected.
> My devices are IDE devices (hda + hdc) and all drivers are bult-ins
> (no initrd nor modules).  After the boot, making a raidstart works
> like a charm...
> 
> Any advice?
> Help welcomed.

Sounds like you didn't set the partition type to be "FD" which is what
the raid autodetect looks for.  (Read the Software-RAID howto).  I
did the same thing yesterday. :)

-- 
Chris Bayly

Email:  [EMAIL PROTECTED] | CNS, UNIX Support
| 151 General Services Building
| University of Alberta
Web:http://www.ualberta.ca/~cbayly/ | Edmonton, Alberta 
| Canada T6G 2S7
-
To unsubscribe from this list: send 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: PS hanging in 2.4.1 - More interesting things

[Shawn Starr]

Ok, I rebooted the system, then syslogd was using 100% cpu?

it seems like perhaps reiserfs is causing this problem??



-
To unsubscribe from this list: send 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 autodetect and 2.4.1

[Jean-Eric Cuendet]

Hi,
I have a server with RAID1 partitions with linux 2.4.1 (stock,
self-compiled) installed.
It was easy to create the RAID partitions but when booting, no
auto-detection is successful.
The kernel says that autodetect is running, then done, but nothing is
auto-detected.
My devices are IDE devices (hda + hdc) and all drivers are bult-ins (no
initrd nor modules).
After the boot, making a raidstart works like a charm...
Any advice?
Help welcomed.

Thanks
-jec

PS: I'm not in the list, so CC me please.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
Jean-Eric Cuendet
Linkvest SA
Av des Baumettes 19, 1020 Renens Switzerland
Tel +41 21 632 9043  Fax +41 21 632 9090
http://www.linkvest.com  E-mail: [EMAIL PROTECTED]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 



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

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[Felix von Leitner]

Thus spake J . A . Magallon ([EMAIL PROTECTED]):
> > How about a simple patch to the top level makefile that checks the gcc
> > version then prints a distinct message ..'this compiler hasn't been approved
> > for compiling the kernel', sleeping for one second, then continuing on.  This
> > solution doesn't stop compiling and makes a visible indicator without forcing
> > anything.
> Or a config option like CONFIG_TRUSTED_COMPILER, and everyone that wants
> can bracket his code in 'if [ $TRUSTED = "y" ] ... fi', so if some driver-fs
> fails with untrusted compilers it is just not selectable.

What kind of crap is this?
It is not the kernel's job to work around RedHat bugs.
If RedHat ships a broken compiler, it is their responsibility to tell
their customers and provide a working one.

This kind of compatibility crap has caused commercial Unices to
suffocate in their own bloat.  We don't need this.  And we don't want
this.

Felix
-
To unsubscribe from this list: send 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: Better battery info/status files

[Albert D. Cahalan]

> This fixes units, and makes format tag: value. Please apply.

The units seem to vary. I suggest using fundamental SI units.
That would be meters, kilograms, seconds, and maybe a very
few others -- my memory fails me on this.

Power meter applets will be eternally buggy if you force them
to deal with units that change. In fact there is no reason to
print the units if you always use the fundamental units.

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

PS hanging 2.4.1 - Isolated

[Shawn Starr]

[root@coredump /proc]# cd 9338
[root@coredump 9338]# ls

Feb  3 17:57:08 coredump kernel: gnomeicu  S CD17 0  9338
1(NOTLB)9340  9332
Feb  3 17:57:08 coredump kernel: Call Trace: [search_by_key+203/3232]
[search_for_position_by_key+170/916] [make_cpu_key+57/64] [$
Feb  3 17:57:08 coredump kernel:[]
[reiserfs_get_block+158/3408] [search_for_position_by_key+170/916]
[search_f$
Feb  3 17:57:08 coredump kernel:[block_read_full_page+246/552]
[add_to_page_cache_unique+202/212] [reiserfs_readpage+15/2$
Feb  3 17:57:08 coredump kernel:[do_page_fault+312/1020]
[do_page_fault+0/1020] [start_request+388/508] [intlat_local_irq$
Feb  3 17:57:09 coredump kernel:[__generic_copy_from_user+52/60]
[opost_block+67/384] [handle_mm_fault+232/340] [add_wait$
Feb  3 17:57:09 coredump kernel:[system_call+62/80

whats happening here?

Shawn.

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

Re: [BUG?] ISA-PnP and 3c509 NIC won't work together

[Keith Owens]

On Sat, 03 Feb 2001 18:54:44 +0100, 
Viktor Rosenfeld <[EMAIL PROTECTED]> wrote:
>With ISA-PnP compiled in, and 3c509 support compiled as module:
># modprobe 3c509
>/lib/modules/2.4.1/kernel/drivers/net/3c509.o: invalid parameter parm_io
>/lib/modules/2.4.1/kernel/drivers/net/3c509.o: insmod
>/lib/modules/2.4.1/kernel/drivers/net/3c509.o failed
>/lib/modules/2.4.1/kernel/drivers/net/3c509.o: insmod 3c509 failed

You passed an unknown parameter io_parm to 3c509 and insmod rejected
it.  This has nothing to do with isa-pnp nor the 3c509, it is a pure
user error.  Correct modules.conf before doing anything 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: PS hanging in 2.4.1 - HAPPENING NOW!!!

[Shawn Starr]

Here's more info with the SYSQ in kern.log, This is the only info I have that
the kernel reports right now.

Shawn.

Shawn Starr wrote:

> [root@coredump spstarr]# killall -9 gnomeicu
>
> ... waiting...
>
> spstarr 67 -bashread_chan
> root68 /sbin/mingetty t read_chan
> root69 /sbin/mingetty t read_chan
> root73 inetddo_select
> root74 xfs  do_select
> spstarr 83 -bashwait4
> daemon 561 named -u daemon  rt_sigsuspend
> daemon 562 named -u daemon  do_poll
> daemon 563 named -u daemon  rt_sigsuspend
> daemon 564 named -u daemon  nanosleep
> daemon 565 named -u daemon  do_select
> root 26231 ./a.out  wait_for_connect
> spstarr   9297 /bin/sh /usr/X11 wait4
> spstarr   9300 xinit /usr/X11R6 wait4
> root  9301 X :0 do_select
> spstarr   9303 gnome-sessiondo_poll
> spstarr   9309 esd -terminate - down_interruptible
> spstarr   9311 gnome-smproxy -- do_select
> spstarr   9325 /usr/local/bin/s do_select
> spstarr   9327 panel --sm-confi do_poll
> spstarr   9329 gnome-name-servi do_poll
> spstarr   9332 tasklist_applet  do_poll
> spstarr   9334 quicklaunch_appl unix_stream_data_wait
>
> [root@coredump /root]# uptime
>   5:45pm  up 4 days,  7:04,  4 users,  load average: 3.37, 1.81, 0.92
>
> Huh??/ why is my load average gone up?!?
>
> the load average just went crazy..
>
> uname -a
> Linux coredump 2.4.1 #1 Tue Jan 30 10:21:42 EST 2001 i586 unknown
>
> Help, I forgot the small script Linus made to see the /proc values:
>
> XMMS *WAS* running at the time of this lock. Im waiting further
> instructions.
>
> Shawn.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/


Feb  3 17:55:58 coredump kernel: SysRq: unRaw saK Boot Sync Unmount showPc showTasks 
showMem loglevel0-8 tErm kIll killalL
Feb  3 17:55:59 coredump last message repeated 2 times
Feb  3 17:56:12 coredump kernel: SysRq: Show Memory
Feb  3 17:56:12 coredump kernel: Mem-info:
Feb  3 17:56:12 coredump kernel: Free pages: 968kB ( 0kB HighMem)
Feb  3 17:56:12 coredump kernel: ( Active: 5079, inactive_dirty: 146, inactive_clean: 
450, free: 242 (224 448 672) )
Feb  3 17:56:12 coredump kernel: 6*4kB 0*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 
1*512kB 0*1024kB 0*2048kB = 552kB)
Feb  3 17:56:12 coredump kernel: 18*4kB 5*8kB 3*16kB 2*32kB 1*64kB 1*128kB 0*256kB 
0*512kB 0*1024kB 0*2048kB = 416kB)
Feb  3 17:56:12 coredump kernel: = 0kB)
Feb  3 17:56:12 coredump kernel: Swap cache: add 427812, delete 426104, find 
235021/938247
Feb  3 17:56:12 coredump kernel: Free swap:37704kB
Feb  3 17:56:12 coredump kernel: 16384 pages of RAM
Feb  3 17:56:12 coredump kernel: 0 pages of HIGHMEM
Feb  3 17:56:12 coredump kernel: 1480 reserved pages
Feb  3 17:56:12 coredump kernel: 13751 pages shared
Feb  3 17:56:12 coredump kernel: 1708 pages swap cached
Feb  3 17:56:12 coredump kernel: 0 pages in page table cache
Feb  3 17:56:13 coredump kernel: Buffer memory:  604kB
Feb  3 17:56:22 coredump kernel: SysRq: Show Regs
Feb  3 17:56:22 coredump kernel: 
Feb  3 17:56:22 coredump kernel: EIP: 0010:[default_idle+47/68] CPU: 0 EFLAGS: 3246
Feb  3 17:56:22 coredump kernel: EAX:  EBX: c0478000 ECX: c0ce0260 EDX: 
c025c3e0
Feb  3 17:56:22 coredump kernel: ESI: c0107120 EDI: e000 EBP: 0008e000 DS: 0018 
ES: 0018
Feb  3 17:56:22 coredump kernel: CR0: 8005003b CR2: 4004ab80 CR3: 007ac000 CR4: 
0010
Feb  3 17:56:22 coredump kernel: Call Trace: [cpu_idle+62/84] [empty_bad_page+0/4096] 
[L6+0/2] 
Feb  3 17:57:05 coredump kernel: SysRq: Show State
Feb  3 17:57:05 coredump kernel: 
Feb  3 17:57:05 coredump kernel:  free
sibling
Feb  3 17:57:05 coredump kernel:   task PCstack   pid father child 
younger older
Feb  3 17:57:05 coredump kernel: init  S C1177F28  4648 1  0  9622  
(NOTLB)
Feb  3 17:57:05 coredump kernel: Call Trace: [schedule_timeout+118/152] 
[process_timeout+0/100] [do_select+413/476] [sys_select+842/1172] [sys_stat64+107/120] 
[system_call+62/80] 
Feb  3 17:57:05 coredump kernel: keventd   S 0001  6572 2  1
(L-TLB)   3
Feb  3 17:57:05 coredump kernel: Call Trace: [context_thread+261/424] 
[kernel_thread+40/56] 
Feb  3 17:57:05 coredump kernel: kswapdS C1165FA8  5472 3  1
(L-TLB)   4 2
Feb  3 17:57:05 coredump kernel: Call Trace: [schedule_timeout+118/152] 
[process_timeout+0/100] [interruptible_sleep_on_timeout+79/128] [kswapd+213/244] 
[kernel_thread+40/56] 
Feb  3 17:57:05 coredump kernel: kreclaimd  S 0286  5924 4  1
(L-TLB)   5 3
Feb  3 17:57:05 coredump kernel: Call Trace: [interruptible_sleep_on+74/120] 
[kreclaimd+75/160] [kernel_thread+40/56] 
Feb  3 17:57:05 coredump kernel: bdflush   S C116  5392 5 

system call sched_yield() doesn't work on Linux 2.2

[Mohit Aron]

Hi,
the system call sched_yield() doesn't seem to work on Linux 2.2. Does
anyone know of a kernel patch that fixes this ? 

Attached below is a small program that uses pthreads and demonstrates that
sched_yield() doesn't work. Basically, the program creates two threads that
alternatively try to yield CPU to each other.


- Mohit



#include 
#include 
#include 

static pthread_t thread1, thread2;


static void *thread1_func(void *arg)
{
  int i;

  for (i=0; i < 5 ;i++) {
printf("Thread1\n");
if (sched_yield()) printf("error in yielding\n");
  }
}

static void *thread2_func(void *arg)
{
  int i;

  for (i=0; i < 5 ;i++) {
printf("Thread2\n");
if (sched_yield()) printf("error in yielding\n");
  }
}


int main(int argc, char **argv)
{
  pthread_create(&thread1, NULL, thread1_func, NULL);
  pthread_create(&thread2, NULL, thread2_func, NULL);

  sleep(10);

  return 0;
}

setting cpu speed on crusoe

[Andrew Tridgell]

Junichi Morita and I have worked out how to access the crusoe
"longrun" settings on the crusoe based VAIO. This allows you to enable
power saving mode and slow the cpu down. It should help battery life a
lot.

the following will enable power saving and set the cpu to the slowest
speed:

  setpci -s 0:0.0 a8.b=11

and this will restore you to max speed:

  setpci -s 0:0.0 a8.b=0e

the bits are:

LRON bit0: long run "on" - I'm not really sure what this does
LRRV bit1-3: cpu speed
LREN bit4: seems to enable variable speed 

the info came from a dump of the AML off the box like this:

1e24:   Scope PCI0 (\_SB_.PCI0)
1e30: OpRegion LRCR (\_SB_.PCI0.LRCR)
1e36:   PCI_Config
1e37:   0xa8
1e39:   0x04
1e3b: Field
1e3e:   LRCR (1e30)
1e42:   AccessType: ByteAcc; LockRule: NoLock; UpdateRule: Preserve
1e43:   NamedField (1 bits at 0x0:0) LRON
1e48:   NamedField (3 bits at 0x0:1) LRRV
1e4d:   NamedField (1 bits at 0x0:4) LREN

the patch to acpidisasm to give the bit offsets and lengths for named
fields is available from
http://www.samba.org/ftp/unpacked/picturebook/acpi.patch





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

PS hanging in 2.4.1 - HAPPENING NOW!!!

[Shawn Starr]

[root@coredump spstarr]# killall -9 gnomeicu

... waiting...

spstarr 67 -bashread_chan
root68 /sbin/mingetty t read_chan
root69 /sbin/mingetty t read_chan
root73 inetddo_select
root74 xfs  do_select
spstarr 83 -bashwait4
daemon 561 named -u daemon  rt_sigsuspend
daemon 562 named -u daemon  do_poll
daemon 563 named -u daemon  rt_sigsuspend
daemon 564 named -u daemon  nanosleep
daemon 565 named -u daemon  do_select
root 26231 ./a.out  wait_for_connect
spstarr   9297 /bin/sh /usr/X11 wait4
spstarr   9300 xinit /usr/X11R6 wait4
root  9301 X :0 do_select
spstarr   9303 gnome-sessiondo_poll
spstarr   9309 esd -terminate - down_interruptible
spstarr   9311 gnome-smproxy -- do_select
spstarr   9325 /usr/local/bin/s do_select
spstarr   9327 panel --sm-confi do_poll
spstarr   9329 gnome-name-servi do_poll
spstarr   9332 tasklist_applet  do_poll
spstarr   9334 quicklaunch_appl unix_stream_data_wait

[root@coredump /root]# uptime
  5:45pm  up 4 days,  7:04,  4 users,  load average: 3.37, 1.81, 0.92

Huh??/ why is my load average gone up?!?

the load average just went crazy..

uname -a
Linux coredump 2.4.1 #1 Tue Jan 30 10:21:42 EST 2001 i586 unknown

Help, I forgot the small script Linus made to see the /proc values:

XMMS *WAS* running at the time of this lock. Im waiting further
instructions.

Shawn.

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

ATAPI CDRW which doesn't work

[patrick . mourlhon]

Hi,

I've never could make this CDRW ATAPI to work, if someone could
provide me any clue about the baby. I just said that people on the
kernel mailing list may care of its but. It looks like the baby didn't
even noticed. ;-)

kernel is 2.4.1, but never worked even before this release.
Never maintained speed.

Thanks in advance for any reply,

Patrick Mourlhon


mount atapi cd writer outpu

Line:/mnt/home/pmo# mount /dev/hdb /cdrom
/dev/hdb: Input/output error
mount: block device /dev/hdb is write-protected, mounting read-only
/dev/hdb: Input/output error

mount: you must specify the filesystem type
Line:/mnt/home/pmo#


/var/log/messages from start to the end of the previous mount command

Feb  3 22:08:25 Line kernel: hdb: irq timeout: status=0xd0 { Busy }
Feb  3 22:08:25 Line kernel: hdb: DMA disabled
Feb  3 22:08:55 Line kernel: hdb: ATAPI reset timed-out, status=0x90
Feb  3 22:08:55 Line kernel: hda: DMA disabled
Feb  3 22:08:55 Line kernel: ide0: reset: success
Feb  3 22:09:06 Line kernel: hdb: irq timeout: status=0x90 { Busy }
Feb  3 22:09:36 Line kernel: hdb: ATAPI reset timed-out, status=0x90
Feb  3 22:09:36 Line kernel: ide0: reset: success
Feb  3 22:09:47 Line kernel: hdb: irq timeout: status=0x90 { Busy }
Feb  3 22:09:47 Line kernel: end_request: I/O error, dev 03:40 (hdb), sector 2
Feb  3 22:09:48 Line kernel: hdb: status timeout: status=0x90 { Busy }
Feb  3 22:09:48 Line kernel: hdb: drive not ready for command
Feb  3 22:10:11 Line kernel: hdb: ATAPI reset complete
Feb  3 22:10:21 Line kernel: hdb: irq timeout: status=0xd0 { Busy }
Feb  3 22:10:51 Line kernel: hdb: ATAPI reset timed-out, status=0x90
Feb  3 22:10:51 Line kernel: ide0: reset: success
Feb  3 22:11:02 Line kernel: hdb: irq timeout: status=0x90 { Busy }
Feb  3 22:11:32 Line kernel: hdb: ATAPI reset timed-out, status=0x90
Feb  3 22:11:32 Line kernel: ide0: reset: success
Feb  3 22:11:42 Line kernel: hdb: irq timeout: status=0x90 { Busy }
Feb  3 22:11:42 Line kernel: end_request: I/O error, dev 03:40 (hdb), sector 2
Feb  3 22:11:43 Line kernel: hdb: status timeout: status=0x90 { Busy }
Feb  3 22:11:43 Line kernel: hdb: drive not ready for command
Feb  3 22:12:06 Line kernel: hdb: ATAPI reset complete
Feb  3 22:12:16 Line kernel: hdb: irq timeout: status=0xd0 { Busy }
Feb  3 22:12:46 Line kernel: hdb: ATAPI reset timed-out, status=0x90
Feb  3 22:12:46 Line kernel: ide0: reset: success
Feb  3 22:12:57 Line kernel: hdb: irq timeout: status=0x90 { Busy }
Feb  3 22:13:27 Line kernel: hdb: ATAPI reset timed-out, status=0x90
Feb  3 22:13:27 Line kernel: ide0: reset: success
Feb  3 22:13:37 Line kernel: hdb: irq timeout: status=0x90 { Busy }
Feb  3 22:13:37 Line kernel: end_request: I/O error, dev 03:40 (hdb), sector 0
Feb  3 22:13:37 Line kernel: FAT bread failed
Feb  3 22:13:38 Line kernel: hdb: status timeout: status=0x90 { Busy }
Feb  3 22:13:38 Line kernel: hdb: drive not ready for command
Feb  3 22:14:02 Line kernel: hdb: ATAPI reset complete
Feb  3 22:14:12 Line kernel: hdb: irq timeout: status=0xd0 { Busy }
Feb  3 22:14:42 Line kernel: hdb: ATAPI reset timed-out, status=0x90
Feb  3 22:14:42 Line kernel: ide0: reset: success
Feb  3 22:14:53 Line kernel: hdb: irq timeout: status=0x90 { Busy }
Feb  3 22:15:23 Line kernel: hdb: ATAPI reset timed-out, status=0x90
Feb  3 22:15:23 Line kernel: ide0: reset: success
Feb  3 22:15:33 Line kernel: hdb: irq timeout: status=0x90 { Busy }
Feb  3 22:15:33 Line kernel: end_request: I/O error, dev 03:40 (hdb), sector 0
Feb  3 22:15:33 Line kernel: FAT bread failed
Feb  3 22:15:35 Line kernel: hdb: status timeout: status=0x90 { Busy }
Feb  3 22:15:35 Line kernel: hdb: drive not ready for command
Feb  3 22:16:09 Line kernel: hdb: ATAPI reset timed-out, status=0x90
Feb  3 22:16:09 Line kernel: ide0: reset: success
Feb  3 22:16:12 Line kernel: hdb: packet command error: status=0x51 { DriveReady 
SeekComplete Error }
Feb  3 22:16:12 Line kernel: hdb: packet command error: error=0xb0
Feb  3 22:16:13 Line kernel: ATAPI device hdb:
Feb  3 22:16:13 Line kernel:   Error: Aborted command -- (Sense key=0x0b)
Feb  3 22:16:13 Line kernel:   (reserved error code) -- (asc=0x00, ascq=0x00)
Feb  3 22:16:13 Line kernel:   The failed "Prevent/Allow Medium Removal" packet 
command was:
Feb  3 22:16:13 Line kernel:   "1e 00 00 00 00 00 00 00 00 00 00 00 "


cat /proc/interrupts

   CPU0
  0: 147746  XT-PIC  timer
  1:  2  XT-PIC  keyboard
  2:  0  XT-PIC  cascade
  4:  0  XT-PIC  serial
 10:  0  XT-PIC  usb-uhci
 12:   3622  XT-PIC  PCnet/PCI II 79C970A
 14:  11727  XT-PIC  ide0
 15:127  XT-PIC  ide1
NMI:  0
LOC:  0
ERR:  0


cat /proc/ioports

-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
02f8-02ff : serial(set)
0376-0376 : ide

Re: SMP problem with 2.2.19pre8

[Shane Wegner]

On Sat, Feb 03, 2001 at 02:07:27PM -0800, Shane Wegner wrote:
> Hi,
> 
> I just built this SMP system and am getting some weird
> errors from kern.log.  The system will run smoothly but
> after about a half hour running the distributed.net RC5
> client, the following errors show up.
> 
> Feb  3 04:40:18 continuum kernel: stuck on TLB IPI wait
> (CPU#0)
> Feb  3 04:40:23 continuum last message repeated 4 times
> Feb  3 04:40:45 continuum last message repeated 4 times
> Feb  3 04:40:56 continuum kernel: stuck on TLB IPI wait
> (CPU#1)
> Feb  3 04:41:02 continuum last message repeated 2 times

I should also mention that the kernel has the following
patches applied.
00-piii-8
01-ide-2.2.18.1221.patch
02-raid-2.2.18b3


-- 
Shane Wegner: [EMAIL PROTECTED]
  http://www.cm.nu/~shane/
PGP:  1024D/FFE3035D
  A0ED DAC4 77EC D674 5487
  5B5C 4F89 9A4E FFE3 035D
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

SMP problem with 2.2.19pre8

[Shane Wegner]

Hi,

I just built this SMP system and am getting some weird
errors from kern.log.  The system will run smoothly but
after about a half hour running the distributed.net RC5
client, the following errors show up.

Feb  3 04:40:18 continuum kernel: stuck on TLB IPI wait
(CPU#0)
Feb  3 04:40:23 continuum last message repeated 4 times
Feb  3 04:40:45 continuum last message repeated 4 times
Feb  3 04:40:56 continuum kernel: stuck on TLB IPI wait
(CPU#1)
Feb  3 04:41:02 continuum last message repeated 2 times

The system doesn't actually crash but it does slow to a
crawl such that you can't really do anything with it.  It
is an Abit VP6 motherboard running 2 P-III 850 CPUs at
100MHZ bus speed.  256MB of PC133 micron ram.

If anyone knows whether this is a kernel issue or a
hardware one, I would appreciate hearing from you.

Shane


-- 
Shane Wegner: [EMAIL PROTECTED]
  http://www.cm.nu/~shane/
PGP:  1024D/FFE3035D
  A0ED DAC4 77EC D674 5487
  5B5C 4F89 9A4E FFE3 035D
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [BUG?] ISA-PnP and 3c509 NIC won't work together

[Brian Gerst]

Viktor Rosenfeld wrote:
> 
> Hi kernel hackers,
> 
> I have troubles getting both ISA-PnP and the driver for my 3c509 NIC
> working together.  
> 
> I can only get my NIC to work when I leave ISA-PnP completely out of the
> kernel.  When I have ISA-PnP activated, the card will not show up in
> /proc/isapnp (see below) nor is it listed in the table that my system
> displays prior to starting LILO.  The kernel help on the 3c509 driver
> suggests to completely deactivate PNP for the NIC, which is what I have
> done since kernel 2.0.x.  Unfortunately, I can't find info on
> re-enabling PNP on the card.
> 
> Below, I have attached the content of /proc/isapnp.  If I can do
> anything to provide more info, let me know.

Go to 3Com's site and get the setup program for the card (for DOS).  It
is configurable via eeprom for io and irq or PnP mode.

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

Re: [BUG?] ISA-PnP and 3c509 NIC won't work together

[Russell King]

Viktor Rosenfeld writes:
> With ISA-PnP compiled in, and 3c509 support compiled as module:
> # modprobe 3c509
> /lib/modules/2.4.1/kernel/drivers/net/3c509.o: invalid parameter parm_io
> /lib/modules/2.4.1/kernel/drivers/net/3c509.o: insmod
> /lib/modules/2.4.1/kernel/drivers/net/3c509.o failed
> /lib/modules/2.4.1/kernel/drivers/net/3c509.o: insmod 3c509 failed

Silly question, but shouldn't you fix this "invalid parameter parm_io"
error first?

iirc, insmod won't insert modules when you have parameters for missing
symbols.

--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
 http://www.arm.linux.org.uk/personal/aboutme.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/

Re: [patch] tmpfs for 2.4.1

[J . A . Magallon]

On 02.03 H. Peter Anvin wrote:
> Christoph Rohland wrote:
> > 
> > "H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> > 
> > > > Mm, does this mean that mounting /dev/shm is no more needed ?
> > > > One step more towards easy 2.2 <-> 2.4 switching...
> > 
> > Yes, it is no longer needed. You will need for POSIX shm, but there
> > are not a lot of program out there using it.
> > 
> 
> Do you need it for POSIX shm or not... if so, I would say you do need it
> (even if it's going to take some time until POSIX shm becomes widely
> used.)
> 

There was a post recently (that now I can't find), that said the shm
management was done with an interal fs. Was that Posix or sysv shm ?

-- 
J.A. Magallon  $> cd pub
mailto:[EMAIL PROTECTED]  $> more beer

Linux werewolf 2.4.1-ac2 #1 SMP Sat Feb 3 10:45:59 CET 2001 i686

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

Re: one of the most useless patches you'll ever see

[Guest section DW]

On Sat, Feb 03, 2001 at 05:36:06PM +0100, [EMAIL PROTECTED] wrote:

> This copies the sun 12x22 font to a 12x20 font.
> Readability on a 21" monitor remains very high @ 1600x1200, but you get
> 60 lines instead of 55.

Wouldnt it suffice to do
setfont -h20 sun12x22
?

[With a setfont from kbd-1.04.]

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: Need for more ISO8859 codepages?

[Nerijus Baliunas]

> About 18 months ago I patched fs/nls/ to include support for the
> Celtic character set, ISO8859-14. I notice that there are still gaps
> in nls, specifically in ISO8859 codepages 10 to 13.
> 
> The missing codepages are for Nordic/Icelandic (ISO8859-10), Thai
> (ISO8859-11), and Baltic Rim (ISO8859-13) languages. I'm still trying
> to determine the status of ISO8859-12 at the moment.
> 
> Two questions, really. The general one is whether anyone would find
> these codepages useful. If they would, I'm willing to provide the
> patches in due course. More specifically, can anyone tell me why
> ISO8859-10 (Icelandic etc.) is mentioned in Documentation/Configure.help
> whilst nls_iso8859-10.c is missing from the fs/nls directory?

Hello,

ISO8859-13 is used in Latvia and Lithuania, so it would be useful.
I don't think ISO8859-12 is really used, it is reserved for
Devanagari (Indian), but I think they will use unicode eventually...
So it would be nice to add support for ISO8859-10 and ISO8859-13
at least.

Regards,
Nerijus

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

Re: [BUG?] ISA-PnP and 3c509 NIC won't work together

[Viktor Rosenfeld]

Jeff Garzik wrote:
> 
> Victor,
> 
> Can you respond to your recently-sent linux-kernel e-mail, and provide
> the output of 'dmesg' after all your experiments?  'dmesg' program
> displays the kernel logging buffer, and should give us much additional
> information.

Of course, here it comes.  BTW, ISA-PnP left out and 3c509 compiled as
module won't do it either.  I get the same error message about parm_io. 
As you can see, only when I have ISA-PnP left out and 3c509 compiled-in,
the NIC is recognized.


- Kernel 2.4.1 with ISA-PnP and 3c509 compiled-in:
Linux version 2.4.1 (root@bart) (gcc version 2.95.2 2220 (Debian
GNU/Linux)) #1 Sam Feb 3 19:41:16 CET 2001
BIOS-provided physical RAM map:
 BIOS-e820: 0009fc00 @  (usable)
 BIOS-e820: 0400 @ 0009fc00 (reserved)
 BIOS-e820: 0001 @ 000f (reserved)
 BIOS-e820: 0001 @  (reserved)
 BIOS-e820: 0fef @ 0010 (usable)
 BIOS-e820: d000 @ 0fff3000 (ACPI data)
 BIOS-e820: 3000 @ 0fff (ACPI NVS)
On node 0 totalpages: 65536
zone(0): 4096 pages.
zone(1): 61440 pages.
zone(2): 0 pages.
Kernel command line: BOOT_IMAGE=linux ro root=802 mem=256M apm=on
devfs=nomount
Initializing CPU#0
Detected 333.351 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 665.19 BogoMIPS
Memory: 255788k/262144k available (858k kernel code, 5968k reserved,
350k data, 188k init, 0k highmem)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
CPU: Before vendor init, caps: 0183f9ff  , vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 128K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After vendor init, caps: 0183f9ff   
CPU: After generic, caps: 0183f9ff   
CPU: Common caps: 0183f9ff   
CPU: Intel Celeron (Mendocino) stepping 00
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
PCI: PCI BIOS revision 2.10 entry at 0xfaec0, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 1: assuming transparent
Unknown bridge resource 2: assuming transparent
PCI: Using IRQ router PIIX [8086/7110] at 00:07.0
  got res[1000:13ff] for resource 0 of S3 Inc. 86c968 [Vision
968 VRAM] rev 0
Limiting direct PCI/PCI transfers.
isapnp: Scanning for Pnp cards...
isapnp: Card 'TERRATEC SOUNDSYSTEM BASE 1'
isapnp: 1 Plug & Play card detected total
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
DMI 2.1 present.
30 structures occupying 806 bytes.
DMI table at 0x000F0800.
BIOS Vendor: Award Software International, Inc.
BIOS Version: 4.51 PG
BIOS Release: 01/25/99
Board Vendor: Gigabyte Technology Co. Ltd..
Board Name: i440BX-W977.
Board Version:  .
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.14)
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
block: queued sectors max/low 169928kB/56642kB, 512 slots per queue
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ
SERIAL_PCI ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
SCSI subsystem driver Revision: 1.00
sym53c8xx: at PCI bus 0, device 11, function 0
sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up)
sym53c8xx: 53c875E detected 
sym53c875E-0: rev 0x26 on pci bus 0 device 11 function 0 irq 11
sym53c875E-0: ID 7, Fast-20, Parity Checking
sym53c875E-0: on-chip RAM at 0xed00
sym53c875E-0: restart (scsi reset).
sym53c875E-0: Downloading SCSI SCRIPTS.
scsi0 : sym53c8xx - version 1.6b
  Vendor: PLEXTOR   Model: CD-ROM PX-32TSRev: 1.02
  Type:   CD-ROM ANSI SCSI revision: 02
  Vendor: IBM   Model: DNES-309170W  Rev: SAH0
  Type:   Direct-Access  ANSI SCSI revision: 03
sym53c875E-0-<8,0>: tagged command queue depth set to 8
Detected scsi disk sda at scsi0, channel 0, id 8, lun 0
sym53c875E-0-<8,0>: wide msgout: 1-2-3-1.
sym53c875E-0-<8,0>: wide msgin: 1-2-3-1.
sym53c875E-0-<8,0>: wide: wide=1 chg=0.
sym53c875E-0-<8,0>: wide msgout: 1-2-3-1.
sym53c875E-0-<8,0>: wide msgin: 1-2-3-1.
sym53c875E-0-<8,0>: wide: wide=1 chg=0.
sym53c875E-0-<8,0>: sync msgout: 1-3-1-c-10.
sym53c875E-0-<8,0>: sync msg in: 1-3-1-c-10.
sym53c875E-0-<8,0>: sync: per=12 scntl3=0x90 scntl4=0x0 ofs=16 fak=0
chg=0.
sym53c875E-0-<8,*>: FAST-20 WIDE SCSI 40.0 MB/s (50 ns, offset 16)
SCSI device sda: 17916240 512-byte hdwr sectors (9173 MB)
Partition check:
 /dev/scsi/host0/bus0/target8/lun0: p1 p2 p3 p4 < p5 p6 p7 p8 p9 >
Detected scsi CD-ROM sr0 at scsi0, chan

Re: Serious reproducible 2.4.x kernel hang

[kees]

Hi,

What is related in /proc w.r.t. sysrq?

Kees

-
To unsubscribe from this list: send 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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait/notify + callback chains

[Linus Torvalds]

On Thu, 1 Feb 2001, Stephen C. Tweedie wrote:
> 
> On Thu, Feb 01, 2001 at 09:33:27PM +0100, Christoph Hellwig wrote:
> 
> > I think you want the whole kio concept only for disk-like IO.  
> 
> No.  I want something good for zero-copy IO in general, but a lot of
> that concerns the problem of interacting with the user, and the basic
> center of that interaction in 99% of the interesting cases is either a
> user VM buffer or the page cache --- all of which are page-aligned.  
> 
> If you look at the sorts of models being proposed (even by Linus) for
> splice, you get
> 
>   len = prepare_read();
>   prepare_write();
>   pull_fd();
>   commit_write();
> 
> in which the read is being pulled into a known location in the page
> cache -- it's page-aligned, again.

Wrong.

Neither the read nor the write are page-aligned. I don't know where you
got that idea. It's obviously not true even in the common case: it depends
_entirely_ on what the file offsets are, and expecting the offset to be
zero is just being stupid. It's often _not_ zero. With networking it is in
fact seldom zero, because the network packets are seldom aligned either in
size or in location.

Also, there are many reasons why "page" may have different meaning. We
will eventually have a page-cache where the pagecace granularity is not
the same as the user-level visible one. User-level may do mmap at 4kB
boundaries, even if the page cache itself uses 8kB or 16kB pages.

THERE IS NO PAGE-ALIGNMENT. And anything that even _mentions_ the word
page-aligned is going into my trash-can faster than you can say "bug".

Linus

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

Re: [patch] tmpfs for 2.4.1

[H. Peter Anvin]

Christoph Rohland wrote:
> 
> "H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> 
> > > Mm, does this mean that mounting /dev/shm is no more needed ?
> > > One step more towards easy 2.2 <-> 2.4 switching...
> 
> Yes, it is no longer needed. You will need for POSIX shm, but there
> are not a lot of program out there using it.
> 

Do you need it for POSIX shm or not... if so, I would say you do need it
(even if it's going to take some time until POSIX shm becomes widely
used.)

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

Fix dependencies for radio-miropcm20

[Jocelyn Mayer]

I made a very little patch to avoid
people complaining that the kernel doesn't compile
properly when trying to use radio miropcm20 driver.
(I've seen some of this in french newsgroups...)

This driver always needs the ACI mixer,
so this feature should be enabled when we select
the miropcm driver.
For this, I think we have to change: (in 2.4.0 kernel)

--- Config.in-orig  Sat Feb  3 21:12:16 2001

 
+++ Config.in   Sat Feb  3 21:18:48 2001

 
@@ -22,7 +22,7 @@   

 
   hex 'GemTek i/o port (0x20c, 0x30c, 0x24c or 0x34c)' 
CONFIG_RADIO_GEMTEK_PORT 34c 
   
fi   

   
dep_tristate '  Maestro on board radio' CONFIG_RADIO_MAESTRO 
$CONFIG_VIDEO_DEV   
   
-dep_tristate '  Miro PCM20 Radio' CONFIG_RADIO_MIROPCM20 
$CONFIG_VIDEO_DEV   
   
+dep_tristate '  Miro PCM20 Radio' CONFIG_RADIO_MIROPCM20 
$CONFIG_VIDEO_DEV $CONFIG_SOUND_ACI_MIXER   
   
dep_tristate '  SF16FMI Radio' CONFIG_RADIO_SF16FMI $CONFIG_VIDEO_DEV

   
if [ "$CONFIG_RADIO_SF16FMI" = "y" ]; then   

   
   hex 'SF16FMI I/O port (0x284 or 0x384)' CONFIG_RADIO_SF16FMI_PORT 
284 
   

With regards.

Jocelyn Mayer
-
To unsubscribe from this list: send 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: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[J . A . Magallon]

On 02.03 David Ford wrote:
> How about a simple patch to the top level makefile that checks the gcc
> version then prints a distinct message ..'this compiler hasn't been approved
> for compiling the kernel', sleeping for one second, then continuing on.  This
> solution doesn't stop compiling and makes a visible indicator without forcing
> anything.
> 

Or a config option like CONFIG_TRUSTED_COMPILER, and everyone that wants
can bracket his code in 'if [ $TRUSTED = "y" ] ... fi', so if some driver-fs
fails with untrusted compilers it is just not selectable.

-- 
J.A. Magallon  $> cd pub
mailto:[EMAIL PROTECTED]  $> more beer

Linux werewolf 2.4.1-ac1 #2 SMP Fri Feb 2 00:19:04 CET 2001 i686

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

"kaweth" usb ethernet driver in 2.4?

[Eric Sandeen]

I'm wondering about the status of the "kaweth" Kawasaki LSI KL5KUSB100
USB to Ethernet Controller driver for 2.4.  According to
http://www.hiru.aoba.yokohama.jp/%7eura/USB/usbether.html, this chipset
is used in the 3Com USB Network Adapter, Linksys USB10T, D-Link DSB-650,
SMC 2102USB, Netgear EA101, and a few other USB ethernet adapters.

The driver is included with the USB stuff for 2.2, but not in 2.4.

It also doesn't seem to work in 2.2.  :)  The original development of
this driver was going on at http://drivers.rd.ilan.net/kaweth/ but there
have been no updates for quite some time.

Donald Becker had a driver at one point as well, and there's still a
link at http://www.scyld.com/usb/ethernet.html, but the link is broken
now, and I don't have the code.

I have one of these beasts, and I'd like to get it working - I haven't
done any USB _or_ ethernet work for Linux, so it'll be an uphill climb
fro me.  Anybody else have one, and have some time to collaborate?  :) 
I have some of the chipset documentation, too, FWIW.

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

Re: [PATCH] minor ne2k-pci irq fix

[Linus Torvalds]

On Thu, 1 Feb 2001, Jeff Garzik wrote:
> 
> > Probably I've missed this because the last time I hit such a thing was
> > when my ob800 bios mapped the cardbus memory BAR's into bogus legacy
> > 0xe area. Hence there was good reason to read and correct this before
> > trying to enable the device.
> 
> This is a PCI fixup, the driver shouldn't have to worry about this..

Actually, I'd rather see the _drivers_ do most of the fixups for their own
chips, and leave the global PCI fixups for things like

 - PCI/ISA/whatever bridges that affect drivers for _other_ chips. I hate
   having some random PCI driver having to know about the fact that it
   might be behind a bridge that needs special initialization. That kind
   of "non-local" knowledge is that the PCI fixups are there for.

 - stuff that needs to be fixed up early in order to have a working system
   and make sure that we don't have any resource clashes we can't fix up
   later on.

But if there is a BIOS/chip bug that affects only one driver, and that bug
is local to that driver only and can't affect anything else, then I'd
rather see the driver keep track of it. It's easy enough for a driver to
do any required fixup before it actually calls "pci_enable_device()". 

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: System unresponsitive when copying HD/HD

[LA Walsh]

I've noticed less responsive disk response on 2.4.0 vs. 2.2.17.  For example --
I run vmware and suspend it frequently when I'm not using it.  One of them requires
a 158Mb save file.  Before, I could suspend that one, then start another which
reads in a smaller 50M save file.  The smaller one would come up while the other
was still saving.  As of 2.4, the smaller one doesn't come up -- I can't even do
an 'ls' until the big save finishes.  

Now big image program has actually exited and I can close the window -- the disk
writes are going on from the disk cache with 'kupdate' taking some minor fraction (<1%)
of the CPU and the rest of the system being mostly idle.

If I have vmstat running, I notice blocks trickling out to the disk, 5sec averages
495,142,151,155,136,257,15,0.  Note that the maximum read rate (hdparm -t) of this
disk is in the 12-14M/s range.  I'm getting about 1-5% of that on output with the
system's disk subsystem being apparently unable to do anything else.

This is with IDE hard disk with DMA enabled.

a) is this expected performance on a large linear write?  
b) should I expect other disk operations to be denied service as long as
the write is 'flushing'?

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

[ANNOUNCE] Linux-NTFS project, first public release

[Anton Altaparmakov]

This is to announce the first public release of the Linux-NTFS project 
hosted on sourceforge. The project page, where you can download the source 
code tar ball or rpm as well as precompiled RPMs for RedHat Linux 7.0 (i386 
architecture only), is:
 http://sourceforge.net/projects/linux-ntfs/
You can also use the CVS server if you prefer...
Note, that you need the kernel headers installed to compile linux-ntfs 
source (probably you will need 2.4.x kernel headers and not 2.2.x ones but 
I haven't actually checked whether it works with 2.2.x or not).

The first release contains the all new and wonderful ntfsfix utility, which 
repairs some of the damage that the current Linux NTFS driver does when 
writing to an NTFS partition.

If you are doing any writing to NTFS partitions using the Linux NTFS driver 
this is an absolute *MUST* at the present time. It won't solve all 
problems, but it goes quite some way to prevent data corruption.

Run it after dismounting your NTFS partition in Linux but before rebooting 
into Windows NT/2000.

Note, after running the utility, when Windows boots up it will run an 
automatic chkdsk on the partition which will finish fixing the damage done 
by the Linux NTFS driver without corrupting the written data or any other 
data (as long as the Linux NTFS driver hasn't corrupted something beyond 
repair, obviously).

For amusement value, the first release also includes the ntfsdump_logfile 
utility which when used on an NTFS partition will display information about 
the journal ($LogFile) of that partition.

Finally both these utilities make use of the also included NTFS library 
which offer NTFS access to open source programs. It is currently under 
heavy development and the API is not going to remain as it is so don't use 
it yet for your own programs.

For everyone interested in NTFS on-disk structures and functionality, you 
will find the doc directory and especially the include directory to be of 
great interest as the later includes header files with all known to me NTFS 
structures. I still haven't gone through all the NTFS information that is 
available so they are considered work in progress but are fairly complete I 
thing. Most people will probably find that the $LogFile structures have 
never been published before anywhere and now we have the restart area 
structure definitions.

Any problems compiling/running the utilities, just give me a shout, or even 
better submit bug reports on the project page!

Enjoy!

Anton


-- 
"Intelligence is the ability to avoid doing work, yet get the work done". - 
Linus Torvalds
-- 
Anton Altaparmakov  (replace at with @)
Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

-
To unsubscribe from this list: send 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?] RAMFS

[Mike Galbraith]

Hi,

With the patch below, ramfs will withstand make -j20 (binutils)
even while an iozone is running, and cp /dev/zero zero.  These
fail as is.  The problem seems to be in the way writepage() is
called.. ClearPageDirty(); writepage().  That screws up ramfs's
beancounting and makes it wipe pages and do double accounting.
(df;cp /dev/zero zero;rm zero;df to see accounting woes).

Accounting only from ramfs_prepare_write() seems to be enough for
the page limit to function (whodathunkit;)

-Mike

--- linux-2.4.1.ac2/fs/ramfs/inode.c.orgSat Feb  3 10:29:54 2001
+++ linux-2.4.1.ac2/fs/ramfs/inode.cSat Feb  3 19:22:08 2001
@@ -173,11 +173,8 @@
   (inode->i_data.nrpages <= rsb->max_file_pages) ) ) {
inode->i_blocks += IBLOCKS_PER_PAGE;
rsb->free_pages--;
-   SetPageDirty(page);
-   } else {
-   ClearPageUptodate(page);
+   } else
ret = 0;
-   }

unlock_rsb(rsb);
 
@@ -259,13 +256,7 @@
  */
 static int ramfs_writepage(struct page *page)
 {
-   struct inode *inode = (struct inode *)page->mapping->host;
-
-   if (! ramfs_alloc_page(inode, page))
-   {
-   UnlockPage(page);
-   return -ENOSPC;
-   }
+   SetPageDirty(page);
UnlockPage(page);
return 0;
 }
@@ -275,9 +266,8 @@
struct inode *inode = (struct inode *)page->mapping->host;
void *addr;

-   if (! ramfs_alloc_page(inode, page)) {
+   if (! ramfs_alloc_page(inode, page))
return -ENOSPC;
-   }
 
addr = (void *) kmap(page);
if (!Page_Uptodate(page)) {
@@ -285,6 +275,7 @@
flush_dcache_page(page);
SetPageUptodate(page);
}
+   SetPageDirty(page);
return 0;
 }
 

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

Re: xirc2ps_cs driver timeouts/errors

[dilinger]

A few minutes ago, I got the following:
Feb  3 13:09:10 pea kernel: UDP: short packet: 0/58

.. and the driver hung.  I had to reinsert the card to get
networking back.  This is after 10 hours of uptime, using
the patch i sent previously against 2.4.1's xirc2ps_cs.
So the answer is, yes, it happens w/ 3.1.24's driver.  Any
suggestions?

On Fri, Feb 02, 2001 at 09:20:40PM -0800, David Hinds wrote:
> 
> On Fri, Feb 02, 2001 at 11:54:31PM -0500, [EMAIL PROTECTED] wrote:
> > 
> > Each time I get a transmit timeout, or UDP: short packet error,
> > networking on my laptop seems to go down.  Reinsertion of the
> > card temporarily fixes it, and if I leave it long enough it
> > also fixes itself.
> 
> Does the same happen with a 2.2 kernel and the 3.1.24 PCMCIA drivers?
> There is a bug fix in the 3.1.24 xirc2ps_cs driver that hasn't been
> merged into the kernel tree yet.
> 
> -- Dave

-- 
"... being a Linux user is sort of like living in a house inhabited
by a large family of carpenters and architects. Every morning when
you wake up, the house is a little different. Maybe there is a new
turret, or some walls have moved. Or perhaps someone has temporarily
removed the floor under your bed." - Unix for Dummies, 2nd Edition
-- found in the .sig of Rob Riggs, [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: vaio doesn't boot with 2.4.1-ac1, stops at PCI: Probing PCI hardware

[Linus Torvalds]

In article <[EMAIL PROTECTED]>, Ookhoi  <[EMAIL PROTECTED]> wrote:
>Hi Alan,
>
>> > Here it hangs hard. It used to boot with 2.4.0 and 2.4.1-prex  Should I
>> > try to determine which patch made the fatal change? Should I send my
>> 
>> That would be great.
>> 
>> Firstly however does 2.4.1 (Linus) boot ?
>
>It does boot. :-)  Is there something I can do now? 

The -ac patchset has the PCI bug re-introduced: in -ac the PCI probing
will basically disable the northbridge while probing for it, thus
killing the machine.. 

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: Secure Linux

[Michael H. Warfield]

On Tue, Jan 30, 2001 at 06:47:18PM +, Dale Amon wrote:
> Has anyone else signed up on the NSA's secure Linux
> discussion list? The idea of NSA backing the development
> of  a secure GPL'd linux is one I find intriguing. 

1) It is not "Secure Linux", it is "Security Enhanced Linux".
It's a proof of concept of adding type enforcement to the Linux kernel
and looks very promising.

> However I have only seen one posting. Is there anyone
> "real" involved with it?

Why not join the selinux mailing list and find out?

[EMAIL PROTECTED]

Seems to be a pretty active list.

> -- 
> --
> Use Linux: A computerDale Amon, CEO/MD
> is a terrible thing  Village Networking Ltd
> to waste.Belfast, Northern Ireland
> --
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

-- 
 Michael H. Warfield|  (770) 985-6132   |  [EMAIL PROTECTED]
  (The Mad Wizard)  |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9  |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471|  possible worlds.  A pessimist is sure of it!

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

mailing list for application

[news news]

Hi Everyone,

I am looking for a good mailing list covering
discussions/issues about "application development"
on Linux/Unix platform.

Could you give me some suggestions?

Additionally if you know any good Linux/Unix
users group in Bay area, it would be great.


Many thanks,
Mike.


_
Get your FREE download of MSN Explorer at http://explorer.msn.com

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

RE: 2.4.1 eats RAM or /proc/meminfo bug

[Ricardo Galli]

> you should give up thinking there's any real relation between 2.2
> and 2.4.  yes, they're both Linux, but their behaviors are essentially
> unrelated.
>
> >  total   used   free sharedbuffers
>cached
> > Mem:255340 232444  22896  0  16988
> 93212
> > -/+ buffers/cache: 122244 133096
> > Swap:   208804  0 208804
>
> no swap in use, so there's no problem.  except that 22MB is free/wasted.


Then, who is using those 122,244 KB of RAM than cannot be otherwise used for
buffers/cache?

Perhaps I am wrong and that number is the sum of procs memory plus
buffer/caches, but then it should have more free RAM than show in
free/meminfo. And altough cache and buffers are more or less stable, the
reported "used" memory" is still increasing.

What I understand is (no accounting for swap):

cache+buffers == active+inact_dirty+inact_clean.
userland mem == total - (kernel + cache + buffers)

but my reported numbers don't match. I am doing against the maths with the
current situation, and they still worse, buffers/cache have increased in
~4MB but free memory has decreased in ~14MB (with the same workload and
processes):

[gallir@m3d gallir]$ free
 total   used   free sharedbuffers cached
Mem:255340 246816   8524  0   4048 110736
-/+ buffers/cache: 132032 123308
Swap:   208804  0 208804

It's preferable to use all available RAM for buffers/cache, but this isn't
the case...

Sorry if I am wrong, I couldn't find more related docs about these changes.

--ricardo

-
To unsubscribe from this list: send 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: DFE-530TX with no mac address

[Jonathan Morton]

>You can always try writing all the registers with "good" values.

No good - nothing actually changes except 16 bits at 0x6C, and that doesn't
change to anything useful.

>> Is there a reset 'thing' for thses chips, that sets them back to
>> factory tests (like switching them off)?
>[snip]
>> So.How do I go about playing this game?
>
>You find the reset "thing". Maybe there is better documentation somewhere.
>Maybe your bios allows you to reset something on reboots.
>
>The pdf document has a few things that you can play with, SRST, INIT,
>STRT.

Already played with those, to no avail.

I think the PDF is talking about a different revision of the chip to ours -
I'm seeing some bits set which are marked "reserved" in the PDF, and some
reserved bits are clear.

--
from: Jonathan "Chromatix" Morton
mail: [EMAIL PROTECTED]  (not for attachments)
big-mail: [EMAIL PROTECTED]
uni-mail: [EMAIL PROTECTED]

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-BEGIN GEEK CODE BLOCK-
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+
-END GEEK CODE BLOCK-


-
To unsubscribe from this list: send 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: low memory

[Alan Cox]

> - kernel image (2.2.5-15) : 301 KB (I can`t make it smaller).
> 
> "install" program executes "mke2fs /dev/hda1" where /dev/hda1 partition
> has 500MB.
> So in the step: "Writing inode tables: 6/63" the system hang.

Known problem with older 2.2 kernels. There are some VM things involved where
it fails to make progress and hangs. Its also occasionally seen in installers
with older 2.2

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

Re: [BUG?] Unix Domain sockets in 2.4 series ?

[Alan Cox]

> I only tried that  little code remotely so  i do NOT know
> what's system reaction on console ...
> 
> Anyway socket interface goes bye bye after this...

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

low memory

[Javi Roman]

Hi:

I don´t know if this is a suitable forum where I must ask this question,
sorry.
I´m attempting develop a install proccess from a PCMCIA memory card in
a 4MB RAM pc.

My problem is the RAM memory, it`s very low for this purpose.
I have the following:

- kernel image (2.2.5-15) : 301 KB (I can`t make it smaller).
- "initrd": 1003 KB. This initrd has a "init" (19KB) program
(similar to init.c from Red Hat) and a "install" (955KB) program
which execute the next programs (this programs are in the PC card):
- sfdisk.
- mkswap (swapon).
- mke2fs ---> this program hang the system.


The situation just before mke2fs execution:

Total Used Free Shared
Buffers Cached

Mem  2740224 2600960 139264 294919 1064960 876544
Swap  17539072 0 17539072
MemTotal 2676 KB
MemFree  136  KB
MemShared 288  KB
Buffers  1040 KB
Cached  856  KB
SwapTotal17128 KB
SwapFree 17128 KB


"install" program executes "mke2fs /dev/hda1" where /dev/hda1 partition
has 500MB.
So in the step: "Writing inode tables: 6/63" the system hang.


Well, I have found a solution for my problem: 4mb-Laptops-HOWTO
Bruce Richardson says:

1. Find something that will boot in 4mb ram and which can also create
ext2 partitions.
2. Use it to create a swap partition and a small ext2 partition on the
laptop's hard disk.
3. Uncompress the installation root image and copy it onto the ext2
partition.
4. Boot the laptop from the installation boot disk, pointing it at the
ext2 partition on the hard disk.
5. The installation should go more or less as normal from here.


I have done a swap partition and small ext2 partition (mke2fs don't
hang) and I kill "install" (linuxrc)
and when the system attempt change to new root filesytem (the old
filesystem is the ramdisk) the system says:

"kernel panic: VFS : unable to mount root fs on 03:02"

I can see that 03:02 is /dev/hda2 which it's my swap partition,
"/linux/fs/super.c" attempt mount all knows
filesystem, but he dosen't try my /dev/hda1 small ext2 partiton, why?


I have booted the system without initrd and I obtain the same panic.
My small partiton has a /bin/sh program (main.c attempt this
posibility).
But I should obtain other error.

I have booted other system (with whole installation) using my pc card
whithout
initrd and root file system chages correctly.

Somebody can help me?

Sincery: Javi Roman.

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

[BUG?] Unix Domain sockets in 2.4 series ?

[Krzysztof Rusocki]

I ain't kernel developer .. just poor little user,
but i think you might want to look at this stuff below...

I only tried that  little code remotely so  i do NOT know
what's system reaction on console ...

Anyway socket interface goes bye bye after this...

I tried it on 2.4.1-XFS and 2.4.0-XFS (both remotely)
and effects were exactly the same...

#include 
#include 
#include 
#include 
int main(int argc, const char* argv[])
{
int retval;
int sockets[2];
char buf[1];
retval = socketpair(PF_UNIX, SOCK_DGRAM, 0, sockets);
if (retval != 0)
{
perror("socketpair");
exit(1);
}
shutdown(sockets[0], SHUT_RDWR);
read(sockets[0], buf, 1);
}


- Krzysztof

PS.
CC reply for me, i am not subscriber of lkml
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/

[BUG?] ISA-PnP and 3c509 NIC won't work together

[Viktor Rosenfeld]

Hi kernel hackers,

I have troubles getting both ISA-PnP and the driver for my 3c509 NIC
working together.  Here are the error messages I get:

Kernel 2.4.1 with ISA-PnP and 3c509 support compiled in, on boot time:
# /etc/init.d/networking start
SIOCSIFADDR: No such device
eth0: unknown interface: No such device
SIOCSIFNETMASK: No such device
SIOCSIFBRDADDR: No such device
eth0: unknown interface: No such device
eth0: unknown interface: No such device


With ISA-PnP compiled in, and 3c509 support compiled as module:
# modprobe 3c509
/lib/modules/2.4.1/kernel/drivers/net/3c509.o: invalid parameter parm_io
/lib/modules/2.4.1/kernel/drivers/net/3c509.o: insmod
/lib/modules/2.4.1/kernel/drivers/net/3c509.o failed
/lib/modules/2.4.1/kernel/drivers/net/3c509.o: insmod 3c509 failed


With both ISA-PnP and 3c509 compiled as modules:
# modprobe 3c509
isapnp: Scanning for Pnp cards...
isapnp: Card 'TERRATEC SOUNDSYSTEM BASE 1'
isapnp: 1 Plug & Play card detected total
/lib/modules/2.4.1/kernel/drivers/net/3c509.o: invalid parameter parm_io
/lib/modules/2.4.1/kernel/drivers/net/3c509.o: insmod
/lib/modules/2.4.1/kernel/drivers/net/3c509.o failed
/lib/modules/2.4.1/kernel/drivers/net/3c509.o: insmod 3c509
failed  
# insmod /lib/modules/2.4.1/kernel/drivers/net/3c509.o
/lib/modules/2.4.1/kernel/drivers/net/3c509.o: unresolved symbol
isapnp_find_dev_Rb2fa20db


I can only get my NIC to work when I leave ISA-PnP completely out of the
kernel.  When I have ISA-PnP activated, the card will not show up in
/proc/isapnp (see below) nor is it listed in the table that my system
displays prior to starting LILO.  The kernel help on the 3c509 driver
suggests to completely deactivate PNP for the NIC, which is what I have
done since kernel 2.0.x.  Unfortunately, I can't find info on
re-enabling PNP on the card.

Below, I have attached the content of /proc/isapnp.  If I can do
anything to provide more info, let me know.

Thanks for a great kernel,
Viktor
-- 
Viktor Rosenfeld
WWW: http://www.informatik.hu-berlin.de/~rosenfel/
Geek Code (3.1):
  GCS/SS d-@ s+: a20 C++@ UL++$ P+ L+++ E--- W++ N++ o? K? !W O? M? V?
  PS++@ PE+(-) Y+ P?(+++) t+ 5+ X- R? !tv b+ DI+ D- G e>+++ h-- r- !y+

Card 1 'TER1411:TERRATEC SOUNDSYSTEM BASE 1' PnP version 1.0 Product version 1.1
  Logical device 0 'ADS7180:Unknown'
Supported registers 0x2
Device is not active
Resources 0
  Priority preferred
  Port 0x220-0x220, align 0x1f, size 0x10, 16-bit address decoding
  Port 0x388-0x388, align 0x7, size 0x4, 16-bit address decoding
  Port 0x530-0x530, align 0x7, size 0x10, 16-bit address decoding
  IRQ 5 High-Edge
  DMA 1 8-bit byte-count type-A
  DMA 3 8-bit byte-count type-A
  Alternate resources 0:1
Priority acceptable
Port 0x220-0x240, align 0x1f, size 0x10, 16-bit address decoding
Port 0x388-0x388, align 0x7, size 0x4, 16-bit address decoding
Port 0x530-0x530, align 0xf, size 0x10, 16-bit address decoding
IRQ 5,7 High-Edge
DMA 0,1,3 8-bit byte-count type-A
DMA 0,1,3 8-bit byte-count type-A
  Alternate resources 0:2
Priority functional
Port 0x220-0x280, align 0x1f, size 0x10, 16-bit address decoding
Port 0x388-0x3b8, align 0x7, size 0x4, 16-bit address decoding
Port 0x500-0x560, align 0xf, size 0x10, 16-bit address decoding
IRQ 5,7,10 High-Edge
DMA 0,1,3 8-bit byte-count type-A
DMA 0,1,3 8-bit byte-count type-A
  Alternate resources 0:3
Priority functional
Port 0x220-0x280, align 0x1f, size 0x10, 16-bit address decoding
Port 0x388-0x3b8, align 0x7, size 0x4, 16-bit address decoding
Port 0x500-0x620, align 0xf, size 0x10, 16-bit address decoding
IRQ 5,7,10,11 High-Edge
DMA 0,1,3 8-bit byte-count type-A
DMA  8-bit byte-count type-A
  Alternate resources 0:4
Priority functional
Port 0x220-0x280, align 0x1f, size 0x10, 16-bit address decoding
Port 0x388-0x3b8, align 0x7, size 0x4, 16-bit address decoding
Port 0x500-0x620, align 0xf, size 0x10, 16-bit address decoding
IRQ 5,7,2/9,10,11,15 High-Edge
DMA 0,1,3 8-bit byte-count type-A
DMA  8-bit byte-count type-A
  Logical device 1 'ADS7181:Unknown'
Supported registers 0x2
Compatible device PNPb006
Device is not active
Resources 0
  Priority preferred
  Port 0x330-0x330, align 0xf, size 0x2, 16-bit address decoding
  IRQ 2/9 High-Edge
  Alternate resources 0:1
Priority acceptable
Port 0x300-0x330, align 0xf, size 0x2, 16-bit address decoding
IRQ 2/9 High-Edge
  Alternate resources 0:2
Priority functional
Port 0x300-0x330, align 0xf, size 0x2, 16-bit address decoding
IRQ 2/9,10,11,15 High-Edge
  Logical device 2 'ADS7182:Unknown'
Supported registers 0x2
Compatible device PNPb02f
Device is not active
Resources 0
  Priority prefer

Re: [reiserfs-list] Re: ReiserFS Oops (2.4.1, deterministic, symlink

[Alan Cox]

> David Woodhouse writes:
> 
> >  -a "$CC" = "gcc"
> 
> Not worth it; they should upgrade the local gcc too.
> If anything, they are getting a reminder that they need.

The local gcc has no bearing on the compiler. The local compiler might not 
even be gcc - eg if they are cross building off non Linux systems

-
To unsubscribe from this list: send 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] POSIX timers for 2.4.1

[Linus Torvalds]

On Sat, 3 Feb 2001, Jamie Lokier wrote:

> Robert H. de Vries wrote:
> > Hi Linus,
> > c. setitimer() can be used only once in a given process, you can have
> >up to 32 (configurable) POSIX timers at the same time in your process.
> 
> Why is there a limit?  With such a small limit, any library that wants
> to use its own private timers is going to have to agree a way to
> multiplex with other libraries, and you're back to setitimer().

There's a limit, simply because the thing is implemented as an array. Ugh.

It also doesn't handle the old itimers with the new ones, so you end up
having _both_ the three hardcoded timers _and_ the new timers. Which I
think is rather ugly.

Quite frankly, I'd much rather have the current real/prof/virt itimers
expanded to lists instead (ie _three_ lists: the behaviour of
real/prof/virt timers are very different, and trying to mix them on one
list would be horrible), with the magic timer ID value of zero being the
one that the old itimer() functions work on.

That way, CLONE_ITIMERS would also do something sane (which it doesn't do
with the current POSIX timer patch - it will clone the posix itimers but
not the old itimers).

Also note that the POSIX itimer patch with CLONE_ITIMERS seems to be
horribly buggy: it will save off "timer->it_process", but the process may
not actually EXIST any more by the time the timer is called: exiting only
decrements the usage count, which may be elevated due to clone's etc.

In short, there's not a way in hell I will apply this patch any time soon.
It has real implementation bugs that will cause oopses and
possible lockups (sending signals to non-existent tasks), and I think it
has design problems too.

Linus

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

Re: DFE-530TX with no mac address

[Urban Widmark]

On Sat, 3 Feb 2001 [EMAIL PROTECTED] wrote:

> I noticed that the mac address was stored in the registers and 
> eprom. I guess it would not be as easy as just writing the mac 
> back in the blank eprom and registers?

What my changed via-diag tries to do is to tell the chip to reload things
from the eeprom (note that the diag program doesn't actually list the
eeprom contents).

You can always try writing all the registers with "good" values.


> Is there a reset 'thing' for thses chips, that sets them back to 
> factory tests (like switching them off)?
[snip]
> So.How do I go about playing this game?

You find the reset "thing". Maybe there is better documentation somewhere.
Maybe your bios allows you to reset something on reboots.

The pdf document has a few things that you can play with, SRST, INIT, 
STRT.

/Urban

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

Odd behaviour on / filesystem and SCSI removable media

[John Cavan]

Hi,

I noticed an odd thing about my / file system:

du -hx reports 74mb used
df -h . reports 236mb used

The same behaviour does not show on other mounted filesystems... I'm not
sure which to believe...

I've seen this with 2.4.1 and 2.4.1-ac1, the filesystem is ReiserFS and
the kernel was compiled with egcs-1.1.2 (egcs-2.91.66).

Also, I've seen some interesting behaviour with an Iomega Jaz drive.
Basically, if I boot without a disk in the drive, the device is listed
as 1gb assumed so that when I insert a 2gb disk in the drive, it gets
messed up, unable to read the partition table. Same behaviour with the
Zip drive, picked up as a default 1gb (no Zip disk I'm aware of is this
large!) and can't deal with a 100 mb disk. Makes disk swapping with
removable media rather clunky since modules need to be removed and
reloaded to detect properly.

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

Re: [reiserfs-list] Re: ReiserFS Oops (2.4.1, deterministic, symlink

[Albert D. Cahalan]

David Woodhouse writes:

>  -a "$CC" = "gcc"

Not worth it; they should upgrade the local gcc too.
If anything, they are getting a reminder that they need.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] Re: ReiserFS Oops (2.4.1, deterministic, symlink

[David Woodhouse]

On Fri, 2 Feb 2001, Alan Cox wrote:

> if [ -e /bin/rpm ]; then
> X=`rpm -q gcc`
> if [ "$X" = "gcc-2.96-54" ]; then
> echo "*** GCC 2.96-54 will miscompile Reiserfs. Please update your 
>compiler"
> echo "See http://www.redhat.com/support/errata/RHBA-2000-132.html"
> exit 255
> fi
> fi

 -a "$CC" = "gcc"

-- 
dwmw2


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

Re: DFE-530TX with no mac address

[T . Stewart]

On 3 Feb 2001, at 14:02, Urban Widmark wrote:

> This is intresting. Your card reports that it is stopped while the
> other report show normal values on most things. Does this change if
> you try and send something (like a ping)? Common to both reports is
> that the transceivers don't respond.
> 
> The functioning card reports a PHY ID of 0016 f880, wonder which chip
> that is ... ?
> 
> 
> The attached patch for the via-daig program plays with a few
> registers.
> 
> Run it as 'via-diag -aaeemm -I' then do a 'ifconfig eth0 down;
> ifconfig eth0 up' and see if anything happens.
> 
> If this doesn't work you may want to play "guess the register". A fun
> game for all ages, made more fun by using obfuscated english. There is
> a datasheet here for a chip similar to the ones you have.
>  http://www.via.com.tw/pdf/productinfo/vt86c100a.pdf
Ye, sounds like a fun game ;-)

See bottom for via-diag outputs.

It looks as thought your I switchs do not fix the prob. There is still 
no Station address (00:00:00:00:00:00). The next thing I did was 
look at the working output again:-

VIA VT3065 Rhine-II chip registers at 0xd400
 0x000: 6eba5000 206c55d8 0c5a 4eff 8000 
 01264010 01264190
 0x020: 8400 0600 079ae810 01264020 8000 
0600 079ad010 01264030
 0x040:  00e08000  012641a0  
 013c013c feff
 0x060:    00061108 782d8100 
0880 0247 

EEPROM contents (Assumed from chip registers):
0x100:  00 50 ba 6e d8 55 00 00 00 00 00 00 00 00 00 00
0x110:  00 00 00 00 00 00 00 00 06 00 00 00 47 02 73 73

I noticed that the mac address was stored in the registers and 
eprom. I guess it would not be as easy as just writing the mac 
back in the blank eprom and registers?

Is there a reset 'thing' for thses chips, that sets them back to 
factory tests (like switching them off)?

So.How do I go about playing this game?

tom

freshboot of linux, no eth0 confg done, via-diag -aaeemm
via-diag.c:v2.04 7/14/2000 Donald Becker ([EMAIL PROTECTED])
 http://www.scyld.com/diag/index.html
Index #1: Found a VIA VT3065 Rhine-II adapter at 0xd400.
 Station address 00:00:00:00:00:00.
 Tx disabled, Rx disabled, half-duplex (0x0004).
  Receive  mode is 0x6c: Normal unicast and hashed multicast.
  Transmit mode is 0x21: Normal transmit, 256 byte threshold.
VIA VT3065 Rhine-II chip registers at 0xd400
 0x000:  216c 0004   
 01264000 01264120
 0x020: 0400 0600 01362010 01264010  
0600 01362810 01264020
 0x040: c000 00e0824e 07c49402 01264120  
  feff
 0x060:    0006131f 8100 
0880 0247 
 No interrupt sources are pending ().
  Access to the EEPROM has been disabled (0x80).
Direct reading or writing is not possible.
EEPROM contents (Assumed from chip registers):
0x100:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x110:  00 00 00 00 00 00 00 00 06 00 00 00 47 02 73 73
 ***WARNING***: No MII transceivers found!

ifconfig eth0 up, via-diag -aaeemm -I
via-diag.c:v2.04 7/14/2000 Donald Becker ([EMAIL PROTECTED])
 http://www.scyld.com/diag/index.html
Index #1: Found a VIA VT3065 Rhine-II adapter at 0xd400.
 Station address 00:00:00:00:00:00.
 Tx enabled, Rx enabled, half-duplex (0x081a).
  Receive  mode is 0x6c: Normal unicast and hashed multicast.
  Transmit mode is 0x20: Normal transmit, 256 byte threshold.
VIA VT3065 Rhine-II chip registers at 0xd400
 0x000:  206c 081a 4eff  
 01264000 01264100
 0x020: 0400     
  
 0x040:      
  feff
 0x060:    0e091308 8100 
0880 0247 
 No interrupt sources are pending ().
  Access to the EEPROM has been disabled (0x80).
Direct reading or writing is not possible.
EEPROM contents (Assumed from chip registers):
0x100:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x110:  00 00 00 00 00 00 00 00 09 0e 00 00 47 02 73 73
 ***WARNING***: No MII transceivers found!

ifconifig eth0 down, ifconfig eth0 up, via-diag -aaeemm
via-diag.c:v2.04 7/14/2000 Donald Becker ([EMAIL PROTECTED])
 http://www.scyld.com/diag/index.html
Index #1: Found a VIA VT3065 Rhine-II adapter at 0xd400.
 Station address 00:00:00:00:00:00.
 Tx enabled, Rx enabled, half-duplex (0x081a).
  Receive  mode is 0x6c: Normal unicast and hashed multicast.
  Transmit mode is 0x20: Normal transmit, 256 byte threshold.
VIA VT3065 Rhine-II chip registers at 0xd400
 0x000:  206c 081a 4eff  
 01264000 01264100
 0x020: 0400     
  
 0x040:      
  feff
 0x060:    00061301 8100 
0880 0247 
 No interrupt sources a

Re: ATAPI CD burner with cdrecord > 1.6.1

[Jocelyn Mayer]

> Kernel version is 2.4.1. For versions of cdrecord later than 1.6.1
> (1.8.1 through the latest 1.10 alpha verified), attempting to burn a
> CD results in a SCSI error of some kind. Here's some representative
> output from a "dummy" burn session with cdrecord-1.9: 

> As I recall, things work just fine with a real SCSI CD burner, so I
> think this behavior is limited to the ide-scsi flavor of things. If
> anyone has a clue as to what's really happening here, a fix or workaround
> would be appreciated. In the meantime, I'll continue to use the older
> software (xcdroast-0.96e with cdrecord-1.6.1). Thanks! 

Well...
Maybe I'm not a lucky guy,
but I just got the same trouble with a real SCSI burner...
This one is a Yamaha 8416,
attached to a Tekram UW controleur.
The error I got is exactly the same.
I got this since kernel version 2.4.0-test12, I think.

Jocelyn Mayer
-
To unsubscribe from this list: send 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] Zerocopy 2.4.1 rev3 patch against 2.4.1-ac2

[Ingo Molnar]

On Fri, 2 Feb 2001, David S. Miller wrote:

> Some people have asked me about making a patch against the AC patches.
> It is doable, but would be quite a bit of work for me.

i've done this for TUX anyway, so here is the 2.4.1-rev3 patch against the
2.4.1-ac2 tree:

http://people.redhat.com/mingo/davem-zerocopy-patches/zerocopy-2.4.1-ac2-A0.bz2

Ingo

-
To unsubscribe from this list: send 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: ECN: Clearing the air (fwd)

[Michael H. Warfield]

On Wed, Jan 31, 2001 at 06:02:17PM +, Alan Cox wrote:
> > No. ECN is essential to the continued stability of the Internet. Without
> > probabilistic queuing (i.e. RED) and ECN the Internet will continue to have
> > retransmit synchronization and once congested stay congested until people get
> > frustrated and give it up for a little bit.

> Arguably so. In theory a vindictive probabilistic queueing is sufficient
> (do RED but then drop -every- frame from the same route as the packet chosen
>  from the queue)

THAT actually sounds very similar to what some ATM switches are
doing when congestion results in lost cells in an IP datagram.  Some time
ago, a buddy up at Sandia National Laboratories was explaining the
problem with congestion and IP over ATM.  Once the congestion level
reachs a certain point, the probability of the ATM network dropping a
single cell out of the many cells comprising a complete IP datagram
exceeds unity.  All the transmitted cells, however, are contributing
to the congestion.  The datagram eventually gets retried and adds
even more to the congestion.  Net result is that once you pass this
congestion threshold, IP throughput completely collapses and retries
keep it there until higher layers fail.

The answer for some intelligent ATM switches is to recognize the
higher layer IP traffic and, when dropping an ATM cell in the middle of
an IP datagram, to drop ALL the cells in a datagram if any of the cells
are going to be dropped.  That way the remaining cells are not contributing
to the congestion when the entire IP datagram is going to be retransmitted
anyways.  Purists MIGHT argue that this is a layering violation, but it
would seem to be a good one.  :-/

You could call it vindictive, or maybe congestion with extreme
prejudice...  :-)

Mike
-- 
 Michael H. Warfield|  (770) 985-6132   |  [EMAIL PROTECTED]
  (The Mad Wizard)  |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9  |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471|  possible worlds.  A pessimist is sure of it!

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

one of the most useless patches you'll ever see

[thunder7]

This copies the sun 12x22 font to a 12x20 font.
Readability on a 21" monitor remains very high @ 1600x1200, but you get
60 lines instead of 55.

On request, a 2.2.x version is also available.

Jurriaan
-- 
For who are we to question her
Who stands among the stones
Big Country - The Seer
GNU/Linux 2.2.19pre8 SMP 2x1402 bogomips load av: 0.02 0.10 0.16

 font_sun12x20-2.4.x.diff.gz

Re: digiboard support in linux

[Martin Laberge]

Kenneth Yeung wrote:

> Hello Martin
>
> Thanks for the info, I'm having a little trouble getting the ports
> configured.  On my system, it looks like half the ports are on irq 2 and
> the other half are on irq 5.  and looks like they have been configured the
> right way?  But i can't seem to get them to run getty so that I can test
> the connection.
>
> Thanks!
> -Ken
>
> On Tue, 30 Jan 2001, Martin Laberge wrote:
>
> > Kenneth Yeung wrote:
> >
> > > Hello all
> > >
> > > Can anyone tell me where I can find infomation on digiboard support in
> > > linux specifically the PC/X model?
> > >
> > > THanks
> > > -Ken
> > >
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > the body of a message to [EMAIL PROTECTED]
> > > Please read the FAQ at http://www.tux.org/lkml/
> >
> > yes i used it often in my installations and no problem with that
> > since 2.0.x
> >
> > 2.2.x works good too
> >
> > never tried with linux 2.4.x
> >
> >
> > driver is supported by digiboard itself   and by linux
> >
> > you have the choice of 2 drivers for these boards
> >
> > i used for my part the PC/8e  PC/16e and PC/32e   In ISA versions
> > and never had any problems... (except figuring out how to install for the
> > first time)
> > but it is very simple if you know how to read install instructions
> >
> >
> > Martin Laberge
> > [EMAIL PROTECTED]
> >
> >
> >

could you send me the configuration logs and system boot messages about the
digiboard...

for my part i used agetty on these ports and the board use only one interrupt
(exept if you have many boards...
in that case one interrupt by board ... )

did you executed the DigiLoad command in your boot scripts like instructed in
documentations...
did you put the board drivers (?.bin) in the right places...

they have to be loaded for the board to work...

Martin Laberge
[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: DFE-530TX with no mac address

[Urban Widmark]

On Sat, 3 Feb 2001, Jonathan Morton wrote:

> Do you want me to try this again, after first setting the card into
> non-working condition?

Yes, the idea was to start from non-working, test -I and then ifconfig 
down/up. Getting the working card to work is a much simpler problem :)

/Urban

-
To unsubscribe from this list: send 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: DFE-530TX with no mac address

[Jonathan Morton]

>The attached patch for the via-daig program plays with a few registers.
>
>Run it as 'via-diag -aaeemm -I' then do a 'ifconfig eth0 down; ifconfig
>eth0 up' and see if anything happens.

OK, after a little trouble applying the patch, here's what I found:

Starting with the card in working condition, I tried "via-diag -aaeemm -I"
and there was no change in functionality.  Running the ifconfig toggle also
had no overall effect.  Then I tried "via-diag -aaeemm -i" (running a
pinger in another  console) and noted that the pinger stopped working when
the command was run.  However, running "via-diag -aaeemm -I" did not change
that situation.  The ifconfig toggle did correctly restart operation.

Examining the system log after the above showed that at some point during
the sequence the kernel emitted a series of "transmit timed out" log-entry
pairs as shown in my last mail.  Also, I noticed that while running -i the
receive status was listed as "unicast/hashed multicast" and while running
-I the receive status was "unknown/invalid".

Do you want me to try this again, after first setting the card into
non-working condition?

--
from: Jonathan "Chromatix" Morton
mail: [EMAIL PROTECTED]  (not for attachments)
big-mail: [EMAIL PROTECTED]
uni-mail: [EMAIL PROTECTED]

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-BEGIN GEEK CODE BLOCK-
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+
-END GEEK CODE BLOCK-


-
To unsubscribe from this list: send 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] tmpfs for 2.4.1

[Christoph Rohland]

"J . A . Magallon" <[EMAIL PROTECTED]> writes:

> I did not get the chance to deal too much with it, but apart from moving
> functionality from userspace (ipcs) to kernel (ls), what were/could be the
> benefits of /dev/shm ?. Can you create a shared memory segment by simply
> creating a file there, or it is just a picture of what is in kernelspace?.

The most appealing thing to me was rm -f /dev/shm/.IPC* :-) So I
should make a patch to ipcrm to allow multiple segments (and
wildcards?).

You could not create SYSV shm segments with open, but you could delete
them with rm and list the with ls.

> First time I saw that I thought: what could happen if /dev/shm is shared
> in a cluster ? or, lets suppose that /dev/shm is a logical volume made by
> addition of some nfs mounted volumes, one of each node, so one piece of
> the shm fs is local and other remote...kinda DSM/NUMA...?

No, this was never possible. It was only a fs interface to local
kernel objects (and still is).

> (just too much marijuana late at night...)

Oh, you are allowed to dream ;-)

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/

[test patch] reliable apic lockup with one enable/disable_irq()

[Manfred]

I found a sequence that reliably locks up my 82093AA ioapic with just
one disable/enable_irq.
I've attached a patch for the tulip driver. (tested with a pnic card)

* focus cpu must be enabled.
* Gerard's mask sequence: disable_irq() only sets IRQ_DISABLED,
mask_and_ack masks the ioapic entry if an interrupt is send to a
disabled handler.
* tulip_open:

disable_irq()

force the irq line active (enable both TPLnkPass and TPLnkFail, one of
them is always active)

enable_irq()

#insmod tulip
#ifup eth1

and now the interrupt is delivered as edge triggered, but the IRR bit is
set --> irq line stuck.

Could someone test the patch with newer boards (i840, via apollo pro,
perhaps i815 if the bios builds the MP table)

I also tried changing the trigger mode bit in
{,un}mask_level_IO_APIC_irq(), but that doesn't prevent the hang.

The patch is against 2.4.1
--
Manfred

// $Header$
// Kernel Version:
//  VERSION = 2
//  PATCHLEVEL = 4
//  SUBLEVEL = 1
//  EXTRAVERSION =
--- 2.4/drivers/net/tulip/tulip_core.c  Sat Feb  3 14:02:54 2001
+++ build-2.4/drivers/net/tulip/tulip_core.cSat Feb  3 14:04:58 2001
@@ -421,6 +421,24 @@
 
tulip_up (dev);
 
+   disable_irq(dev->irq);
+   set_current_state(TASK_UNINTERRUPTIBLE);
+   schedule_timeout(10);
+
+{
+   long ioaddr = dev->base_addr;
+   long csr7 = inl(ioaddr + CSR7);
+   outl(NormalIntr|AbnormalIntr|TPLnkPass|TPLnkFail, ioaddr + CSR7);
+   set_current_state(TASK_UNINTERRUPTIBLE);
+   schedule_timeout(10);
+   enable_irq(dev->irq);
+
+   set_current_state(TASK_UNINTERRUPTIBLE);
+   schedule_timeout(10);
+   outl(csr7, ioaddr + CSR7);
+
+}
+
netif_start_queue (dev);
 
return 0;
--- 2.4/arch/i386/kernel/io_apic.c  Sat Feb  3 14:02:24 2001
+++ build-2.4/arch/i386/kernel/io_apic.cSat Feb  3 14:54:14 2001
@@ -693,7 +693,7 @@
printk(KERN_WARNING "  to [EMAIL PROTECTED]\n");
 }
 
-void __init print_IO_APIC(void)
+void print_IO_APIC(void)
 {
int apic, i;
struct IO_APIC_reg_00 reg_00;
@@ -1189,14 +1189,22 @@
 
 #define shutdown_level_ioapic_irq  mask_IO_APIC_irq
 #define enable_level_ioapic_irqunmask_IO_APIC_irq
-#define disable_level_ioapic_irq   mask_IO_APIC_irq
+static void disable_level_ioapic_irq(unsigned int i)
+{
+   /* delayed. */
+}
 
 static void end_level_ioapic_irq (unsigned int i)
 {
ack_APIC_irq();
 }
 
-static void mask_and_ack_level_ioapic_irq (unsigned int i) { /* nothing */ }
+static void mask_and_ack_level_ioapic_irq (unsigned int i)
+{
+   if (irq_desc[i].status & IRQ_DISABLED) {
+   mask_IO_APIC_irq(i);
+   }
+}
 
 static void set_ioapic_affinity (unsigned int irq, unsigned long mask)
 {
--- 2.4/arch/i386/kernel/apic.c Sat Feb  3 14:02:24 2001
+++ build-2.4/arch/i386/kernel/apic.c   Sat Feb  3 14:42:47 2001
@@ -270,7 +270,7 @@
 *   PCI Ne2000 networking cards and PII/PIII processors, dual
 *   BX chipset. ]
 */
-#if 0
+#if 1
/* Enable focus processor (bit==0) */
value &= ~(1<<9);
 #else
--- 2.4/drivers/char/sysrq.cMon Dec  4 02:48:19 2000
+++ build-2.4/drivers/char/sysrq.c  Sat Feb  3 14:33:51 2001
@@ -137,6 +137,10 @@
send_sig_all(SIGKILL, 1);
orig_log_level = 8;
break;
+   case 'q':
+   print_all_local_APICs();
+   print_IO_APIC();
+   break;
default:/* Unknown: help */
if (kbd)
printk("unRaw ");

Re: [PATCH] POSIX timers for 2.4.1

[Jamie Lokier]

Robert H. de Vries wrote:
> Hi Linus,
> c. setitimer() can be used only once in a given process, you can have
>up to 32 (configurable) POSIX timers at the same time in your process.

Why is there a limit?  With such a small limit, any library that wants
to use its own private timers is going to have to agree a way to
multiplex with other libraries, and you're back to setitimer().

-- Jamie
-
To unsubscribe from this list: send 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: RAMDISK larger than 778000 KB halts system

[Ole Tange]

[1.] One line summary of the problem:
 Running badblocks on a ramdisk larger than 778000 KB halts system

[2.] Full description of the problem/report:
 I have setup a ramdisk of 1 GB. When I run badblocks on the 
 RAMdisk, it halts the total system when reaching app. 778000 KB

 I have tried splitting the badblock-test on several ramdisks. And
 it seems the problem appears if the sum of the accessed RAMdisks is
 778000.

 It seems this does not provoke swapping out normal processes as swap
 is entirely unused.

[3.] Keywords (i.e., modules, networking, kernel):
 RAMDISK largemem

[4.] Kernel version (from /proc/version):
 Linux version 2.4.1 ([EMAIL PROTECTED]) (gcc version 2.96 2731
 (Linux-Mandrake 7.3)) #9 Sat Feb 3 14:23:39 CET 2001

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

[6.] A small shell script or example program which triggers the
 problem (if possible)
 badblocks -w -v -s /dev/ram 80

 or

 badblocks -w -v -s /dev/ram 50
 badblocks -w -v -s /dev/ram2 10
 badblocks -w -v -s /dev/ram3 10
 badblocks -w -v -s /dev/ram4 10

[7.] Environment

[7.1.] Software (add the output of the ver_linux script here)
-- Versions installed: (if some fields are empty or look
-- unusual then possibly you have very old versions)
Linux tigger.tange.dk 2.4.1 #9 Sat Feb 3 14:23:39 CET 2001 i686 unknown
Kernel modules 2.3.19
Gnu C  2.96
Gnu Make   3.79.1
Binutils   2.10.0.24
Linux C Library2.1.95
Dynamic linker ldd (GNU libc) 2.1.95
Procps 2.0.7
Mount  2.10o
Net-tools  1.57
Console-tools  0.2.3
Sh-utils   2.0
Modules Loaded
[7.2.] Processor information (from /proc/cpuinfo):
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 2
model name  : AMD Athlon(tm) Processor
stepping: 1
cpu MHz : 650.045
cache size  : 512 KB
fdiv_bug: no
hlt_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 pae mce cx8 sep mtrr pge mca cmov
pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips: 1294.33

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


[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0278-027a : parport1
02e8-02ef : serial(auto)
02f8-02ff : serial(auto)
0376-0376 : ide1
0378-037a : parport0
037b-037f : parport0
03c0-03df : vga+
03e8-03ef : serial(auto)
03f6-03f6 : ide0
03f8-03ff : serial(auto)
0cf8-0cff : PCI conf1
4000-40ff : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
5000-500f : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
6000-607f : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
d000-d00f : VIA Technologies, Inc. Bus Master IDE
  d000-d007 : ide0
  d008-d00f : ide1
d400-d41f : VIA Technologies, Inc. UHCI USB
  d400-d41f : usb-uhci
d800-d81f : VIA Technologies, Inc. UHCI USB (#2)
  d800-d81f : usb-uhci
dc00-dc1f : Creative Labs SB Live! EMU1
  dc00-dc1f : EMU10K1
e000-e007 : Creative Labs SB Live!
e400-e4ff : Symbios Logic Inc. (formerly NCR) 53c875
  e400-e47f : sym53c8xx
e800-e87f : Digital Equipment Corporation DECchip 21142/43
  e800-e87f : eth0

-0009fbff : System RAM
0009fc00-0009 : reserved
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000c8000-000c9fff : Extension ROM
000f-000f : System ROM
0010-3ffe : System RAM
  0010-002389ed : Kernel code
  002389ee-002ade9b : Kernel data
3fff-3fff2fff : ACPI Non-volatile Storage
3fff3000-3fff : ACPI Tables
d000-d3ff : VIA Technologies, Inc. VT8371 [KX133]
d400-d7ff : PCI Bus #01
  d400-d4003fff : Matrox Graphics, Inc. MGA G200 AGP
  d500-d57f : Matrox Graphics, Inc. MGA G200 AGP
d800-d8ff : PCI Bus #01
  d800-d8ff : Matrox Graphics, Inc. MGA G200 AGP
da00-da000fff : Symbios Logic Inc. (formerly NCR) 53c875
da001000-da0010ff : Symbios Logic Inc. (formerly NCR) 53c875
da002000-da00207f : Digital Equipment Corporation DECchip 21142/43
  da002000-da00207f : eth0
- : reserved

[7.5.] PCI information ('lspci -vvv' as root)
00:00.0 Host bridge: VIA Technologies, Inc. VT8371 [KX133] (rev 02)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- 

00:01.0 PCI bridge: VIA Technologies, Inc. VT8371 [PCI-PCI Bridge] (prog-if 00 [Normal 
decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle-

Re: bidirectional named pipe?

[Jamie Lokier]

Alan Cox wrote:
> > /dev/spx".  I experiemented with socket-based pipes under Linux, but I
> > couldn't gain access to them by open()ing the name.  Is there help?  I
> 
> AF_UNIX sockets are bidirectional but like all sockets use bind() and
> connect().

And that's because sockets don't behave like bidirectional fifos.
Each connection to a socket is a distinct stream.

-- Jamie
-
To unsubscribe from this list: send 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] tmpfs for 2.4.1

[Christoph Rohland]

"H. Peter Anvin" <[EMAIL PROTECTED]> writes:

> > Mm, does this mean that mounting /dev/shm is no more needed ?
> > One step more towards easy 2.2 <-> 2.4 switching...

Yes, it is no longer needed. You will need for POSIX shm, but there
are not a lot of program out there using it.

> In some ways it's kind of sad.  I found the /dev/shm interface to be
> rather appealing :)

I totally agree :(

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/

IDE PROBLEM 2.4.0 and 2.4.1

[Lourenco]

hi!

i am getting an error every time i try to copy a big
file from my cdrom to one of my harddrives...

my hardware: P2 333 128 MB Ram
 ONLY IDE
 BOARD BX

i had run dmesg.

here it goes:

(...)
pty: 256 Unix98 ptys configured
block: queued sectors max/low 83821kB/27940kB, 256
slots per queue
RAMDISK driver initialized: 16 RAM disks of 4096K size
1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes;
override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xf000-0xf007, BIOS settings:
hda:pio, hdb:pio
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings:
hdc:pio, hdd:pio
hda: FUJITSU MPE3170AT, ATA DISK drive
hdb: QUANTUM FIREBALL EX3.2A, ATA DISK drive
hdc: TOSHIBA CD-ROM XM-6402B, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 33360580 sectors (17081 MB) w/512KiB Cache,
CHS=2076/255/63
hdb: 6306048 sectors (3229 MB) w/418KiB Cache,
CHS=782/128/63, UDMA(33)
hdc: ATAPI 32X CD-ROM drive, 256kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
Partition check:
 hda: hda1 hda2 < hda5 > hda3 hda4
 hdb: hdb1 hdb2 < hdb5 >
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Loading I2O Core - (c) Copyright 1999 Red Hat Software
I2O configuration manager v 0.04.
  (C) Copyright 1999 Red Hat Software
Serial driver version 5.02 (2000-08-09) with
MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
PPP generic driver version 2.4.1
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory:
96M
agpgart: Detected Intel 440BX chipset
agpgart: AGP aperture is 64M @ 0xe000
es1371: version v0.27 time 10:54:26 Feb  3 2001
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
uhci.c: USB UHCI at I/O 0xe000, IRQ 9
uhci.c: detected 2 ports
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
mice: PS/2 mouse device common for all mice
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 8192 bind
8192)
Linux IP multicast router 0.06 plus PIM-SM
IP-Config: No network devices available.
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Linux IPX 0.43 for NET4.0
IPX Portions Copyright (c) 1995 Caldera, Inc.
IPX Portions Copyright (c) 2000 Conectiva, Inc.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 232k freed
Adding Swap: 128516k swap-space (priority -1)
Soundblaster audio driver Copyright (C) by Hannu
Savolainen 1993-1996
sb: ESS ES1868 Plug and Play AudioDrive detected
sb: ISAPnP reports 'ESS ES1868 Plug and Play
AudioDrive' at i/o 0x220, irq 5, dma 1, 3
SB 3.01 detected OK (220)
ESS chip ES1868 detected
 at 0x220 irq 5
dma 1,3
sb: ESS ES1868 Plug and Play AudioDrive detected
sb: Failed to initialize ESS ES1868 Plug and Play
AudioDrive
sb: 1 Soundblaster PnP card(s) found.
YM3812 and OPL-3 driver Copyright (C) by Hannu
Savolainen, Rob Hooft 1993-1996
 at 0x388
0x378: FIFO is 16 bytes
0x378: writeIntrThreshold is 16
0x378: readIntrThreshold is 16
0x378: PWord is 8 bits
0x378: Interrupts are ISA-Pulses
0x378: ECP port cfgA=0x10 cfgB=0x48
0x378: ECP settings irq=7 dma=
parport0: PC-style at 0x378 (0x778)
[PCSPP,TRISTATE,COMPAT,EPP,ECP]
parport0: irq 7 detected
parport0: cpp_mux: aa55f00f52ad51(07)
parport0: Found 1 daisy-chained devices
lp0: using parport0 (polling).
lp0: console ready
VFS: Disk change detected on device ide1(22,0)
ISO 9660 Extensions: Microsoft Joliet Level 3
ISOFS: changing to secondary root
VFS: Disk change detected on device ide1(22,0)
ISO 9660 Extensions: Microsoft Joliet Level 3
ISOFS: changing to secondary root
isofs_read_level3_size: More than 100 file sections
?!?, aborting...
isofs_read_level3_size: inode=45152 ino=53408
isofs_read_level3_size: More than 100 file sections
?!?, aborting...
isofs_read_level3_size: inode=45232 ino=53488
hdc: command error: status=0x51 { DriveReady
SeekComplete Error }
hdc: command error: error=0x51
end_request: I/O error, dev 16:00 (hdc), sector 18356
hdc: command error: status=0x51 { DriveReady
SeekComplete Error }
hdc: command error: error=0x51
end_request: I/O error, dev 16:00 (hdc), sector 18360
hdc: command error: status=0x51 { DriveReady
SeekComplete Error }
hdc: command error: error=0x51
end_request: I/O error, dev 16:00 (hdc), sector 18364
hdc: command error: status=0x51 { DriveReady
SeekComplete Error }
hdc: command error: error=0x51
end_request: I/O error, dev 16:00 (hdc), sector 18368
hdc: command error: status=0x51 { DriveReady
SeekComplete Error }
hdc: command error: error=0x51
end_request: I/O error, dev 16:00 (hdc), sector 18372
hdc: command error: status=0x51 { DriveReady
SeekComplete E

2.4.1 eats RAM or /proc/meminfo bug

[Ricardo Galli]

I noticed in my server that the memory consumption with 2.4.1 it much higher
than 2.2.18 and it gets worse over time.

Free was reporting up to 140MB of RAM with no user/X session (50-60MB with
2.2.18, same software). I've upgraded to procps 2.0.7, but the problem
persists. After few minutes of rebooting the server, the memory usage was
40-50MB, but after 24 hours the used memory grew to 120MB. I though it could
be Apache or Postgres servers, so I've stopped them but the memory decreased
just few megabytes.

I did then another check, I summed the RSS of all processes (which should
give more than free) and it is reporting _less_ that free.

Find the figures and sys info below. Please note that the used memory it's
about 120MB, with 2.2.x it never passed 60MB with the same conf.

[root@m3d /root]# uname -a
Linux m3d.uib.es 2.4.1 #2 Thu Feb 1 12:22:17 MET 2001 i686 unknown

[root@m3d /root]# free -V
procps version 2.0.7

[root@m3d /root]# free
 total   used   free sharedbuffers cached
Mem:255340 232444  22896  0  16988  93212
-/+ buffers/cache: 122244 133096
Swap:   208804  0 208804

[root@m3d /root]# cat /proc/meminfo
total:used:free:  shared: buffers:  cached:
Mem:  261468160 238030848 234373120 17395712 95453184
Swap: 2138152960 213815296
MemTotal:   255340 kB
MemFree: 22888 kB
MemShared:   0 kB
Buffers: 16988 kB
Cached:  93216 kB
Active:  15424 kB
Inact_dirty: 92172 kB
Inact_clean:  2608 kB
Inact_target:   60 kB
HighTotal:   0 kB
HighFree:0 kB
LowTotal:   255340 kB
LowFree: 22888 kB
SwapTotal:  208804 kB
SwapFree:   208804 kB

[root@m3d /proc]# modprobe -l
/lib/modules/2.4.1/kernel/drivers/net/dummy.o
/lib/modules/2.4.1/kernel/drivers/net/eepro100.o
/lib/modules/2.4.1/kernel/drivers/parport/parport.o
/lib/modules/2.4.1/kernel/drivers/parport/parport_pc.o
/lib/modules/2.4.1/kernel/drivers/sound/ac97_codec.o
/lib/modules/2.4.1/kernel/drivers/sound/ad1848.o
/lib/modules/2.4.1/kernel/drivers/sound/es1370.o
/lib/modules/2.4.1/kernel/drivers/sound/es1371.o
/lib/modules/2.4.1/kernel/drivers/sound/esssolo1.o
/lib/modules/2.4.1/kernel/drivers/sound/maestro.o
/lib/modules/2.4.1/kernel/drivers/sound/mpu401.o
/lib/modules/2.4.1/kernel/drivers/sound/sound.o
/lib/modules/2.4.1/kernel/drivers/sound/soundcore.o
/lib/modules/2.4.1/kernel/drivers/sound/sscape.o
/lib/modules/2.4.1/kernel/fs/msdos/msdos.o
/lib/modules/2.4.1/kernel/fs/vfat/vfat.o


[root@m3d /root]#  ps axlh |  awk '{i+=$7; j+=$8}; END{ print i, j }'
254592 99748

Note in the last command that the total RSS is lower thet the used memory
reported by free/meminfo. The machine is a plain PIII with IDE disks adn
3Com905 etherboard.

Just tell me if you need for info or reports.

Regards.

--ricardo
http://m3d.uib.es/~gallir/


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