Re: Mail list archives down

2001-07-05 Thread Samuli Kaski

If you don't require any fancy web features the one at our department
seems pretty uptodate & functional.

http://www.cs.helsinki.fi/linux/linux-kernel/

Samuli

On 5 Jul 2001, Håvard Kvålen wrote:

> David Balazic <[EMAIL PROTECTED]> writes:
>
> > I noticed 4 out of 5 LKML web archives listed in the FAQ are down as
> > of today.
>
> I guess the FAQ needs updating.  Here is one that seems to work:
> http://www.lib.uaa.alaska.edu/linux-kernel/ >
>
> --
> Håvard Kvålen
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: Mail list archives down

2001-07-05 Thread Samuli Kaski

If you don't require any fancy web features the one at our department
seems pretty uptodate  functional.

http://www.cs.helsinki.fi/linux/linux-kernel/

Samuli

On 5 Jul 2001, Håvard Kvålen wrote:

 David Balazic [EMAIL PROTECTED] writes:

  I noticed 4 out of 5 LKML web archives listed in the FAQ are down as
  of today.

 I guess the FAQ needs updating.  Here is one that seems to work:
 URL: http://www.lib.uaa.alaska.edu/linux-kernel/ 

 --
 Håvard Kvålen
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: pci SDSL card

2001-04-14 Thread Samuli Kaski

The Xpeed X200/300. Go to http://www.xpeed.com/Products/x300/300ds.pdf

Kernel support for the cards appeared in

ftp://ftp.cs.helsinki.fi/pub/Software/Linux/Kernel/people/alan/2.2.18pre/pre-patch-2.2.18-18.gz

I guess it hasn't been ported to 2.4 yet.

Samuli

On Fri, 13 Apr 2001, Gabriel Rocha wrote:

> does anyone know of a linux supported, pci SDSL card? I see a couple that are 
>windows based, but nothing on those and linux...thanks in advance. --gabe
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: pci SDSL card

2001-04-14 Thread Samuli Kaski

The Xpeed X200/300. Go to http://www.xpeed.com/Products/x300/300ds.pdf

Kernel support for the cards appeared in

ftp://ftp.cs.helsinki.fi/pub/Software/Linux/Kernel/people/alan/2.2.18pre/pre-patch-2.2.18-18.gz

I guess it hasn't been ported to 2.4 yet.

Samuli

On Fri, 13 Apr 2001, Gabriel Rocha wrote:

 does anyone know of a linux supported, pci SDSL card? I see a couple that are 
windows based, but nothing on those and linux...thanks in advance. --gabe
 -
 To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



2.4.0 LVM

2001-01-05 Thread Samuli Kaski

LVM doesn't compile without CONFIG_LVM_PROC_FS.

Samuli

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



2.4.0 LVM

2001-01-05 Thread Samuli Kaski

LVM doesn't compile without CONFIG_LVM_PROC_FS.

Samuli

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



2.4.0-test12 unresolved symbols in ide-scsi.o

2000-12-13 Thread Samuli Kaski

I didn't change my config and things work with test11. Sorry for the
noise if I have missed some announcement about ide-scsi.

/lib/modules/2.4.0-test12/kernel/drivers/scsi/ide-scsi.o: unresolved symbol 
scsi_unregister_module
/lib/modules/2.4.0-test12/kernel/drivers/scsi/ide-scsi.o: unresolved symbol 
scsi_register
/lib/modules/2.4.0-test12/kernel/drivers/scsi/ide-scsi.o: unresolved symbol 
scsi_register_module
/lib/modules/2.4.0-test12/kernel/drivers/scsi/ide-scsi.o: insmod 
/lib/modules/2.4.0-test12/kernel/drivers/scsi/ide-scsi.o failed
/lib/modules/2.4.0-test12/kernel/drivers/scsi/ide-scsi.o: insmod ide-scsi failed

Samuli

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



2.4.0-test10 FAT oops

2000-11-24 Thread Samuli Kaski

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

Samuli

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

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



Re: 2.4.0test10pre4 lockups

2000-10-23 Thread Samuli Kaski

On Mon, 23 Oct 2000, Andi Kleen wrote:

> I've seen 3 user land lockups with test10pre4 so far on my UP K6-400, running
> it for a day.  test9 which ran before for more than a week
> was rock stable. They all happened during some IO load (e.g. a gcc compile
> or a loop mke2fs), usually with some CPU eaters running in the background.

Well, I got the opposite experience (for now). test9 caused me several
lockups during same kind of load, even CD-R burning (dual BP6, IDE). I
usually refrain from reporting lockups because of the crappy hardware
I'm using but lately I have been seeing an increasing number of
lockups.

I switched to test10pre4 this morning to see if it makes a difference.

Samuli


-
To unsubscribe from this list: send the 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.0test10pre4 lockups

2000-10-23 Thread Samuli Kaski

On Mon, 23 Oct 2000, Andi Kleen wrote:

 I've seen 3 user land lockups with test10pre4 so far on my UP K6-400, running
 it for a day.  test9 which ran before for more than a week
 was rock stable. They all happened during some IO load (e.g. a gcc compile
 or a loop mke2fs), usually with some CPU eaters running in the background.

Well, I got the opposite experience (for now). test9 caused me several
lockups during same kind of load, even CD-R burning (dual BP6, IDE). I
usually refrain from reporting lockups because of the crappy hardware
I'm using but lately I have been seeing an increasing number of
lockups.

I switched to test10pre4 this morning to see if it makes a difference.

Samuli


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



2.4.0-test8 breaks ide-scsi

2000-09-15 Thread Samuli Kaski

[ Sorry if this is already known, I have been too busy to read all lkml
mail, ignore if so ]

When ide-scsi is inserted it detects the drive(s) all over again in the
following manner

Detected scsi CD-ROM sr?? at scsi0, channel 0, id 0, lun 0 

where ?? is a looping number, my guess is from 0 to infinity (well
whatever the size is). This renders the system unusable.

Other glitches I have noticed but haven't yet had time to work on, while
booting:

request_module[scsi_hostadapter]: Root fs not mounted
request_module[scsi_hostadapter]: Root fs not mounted

However I have only the SCSI options necessary for ide-scsi, this is a
IDE-only system.

Another thing is that either the kernel or the new modutils break
RedHat's mixer-setting/sound detection scripts. (I have a es1371 based
soundcard) However once the sound modules are manually inserted & mixer
settings loaded, sound works just fine. I'm not sure but I think I saw
this already with -test7.

The kernel also breaks lmsensors but that's probably yet another
story...

Samuli

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



2.4.0-test8 breaks ide-scsi

2000-09-15 Thread Samuli Kaski

[ Sorry if this is already known, I have been too busy to read all lkml
mail, ignore if so ]

When ide-scsi is inserted it detects the drive(s) all over again in the
following manner

Detected scsi CD-ROM sr?? at scsi0, channel 0, id 0, lun 0 

where ?? is a looping number, my guess is from 0 to infinity (well
whatever the size is). This renders the system unusable.

Other glitches I have noticed but haven't yet had time to work on, while
booting:

request_module[scsi_hostadapter]: Root fs not mounted
request_module[scsi_hostadapter]: Root fs not mounted

However I have only the SCSI options necessary for ide-scsi, this is a
IDE-only system.

Another thing is that either the kernel or the new modutils break
RedHat's mixer-setting/sound detection scripts. (I have a es1371 based
soundcard) However once the sound modules are manually inserted  mixer
settings loaded, sound works just fine. I'm not sure but I think I saw
this already with -test7.

The kernel also breaks lmsensors but that's probably yet another
story...

Samuli

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



I/O statistics per process?

2000-09-12 Thread Samuli Kaski

I know about sar which can deliver what I want for disks and/or
partitions. What about if I want to know how much I/O is caused by
userspace programs?

Looking at the proc-interface in 2.2.xx the necessary bits aren't
available. The BSD process accounting doesn't provide them either, the
I/O fields are always 0 the way I read it. Looking at the task_struct, I
can't see anything related there.

Is I/O caused by userspace processes accounted somewhere? And if it
isn't is this intentional or are folks just waiting for someone to
submit a patch? Thanks.

Samuli



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



I/O statistics per process?

2000-09-12 Thread Samuli Kaski

I know about sar which can deliver what I want for disks and/or
partitions. What about if I want to know how much I/O is caused by
userspace programs?

Looking at the proc-interface in 2.2.xx the necessary bits aren't
available. The BSD process accounting doesn't provide them either, the
I/O fields are always 0 the way I read it. Looking at the task_struct, I
can't see anything related there.

Is I/O caused by userspace processes accounted somewhere? And if it
isn't is this intentional or are folks just waiting for someone to
submit a patch? Thanks.

Samuli



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