headers
Con Kolivas | 1 May 2002 01:01

Re: Your patchset

On Wed, 1 May 2002 06:59, you wrote:
> Hi Con,

Hey MCP

> nice patchset :-) ... Is it the O(1) Scheduler Backport from 2.5 or the K3?

Thanks. It is from the 2.4.18-pre8-k3 patch

> Do you have those patches as standalone or only as a full one patchset?

No, I had to hand modify each file after each separate patch was applied so 
one patchset only.

Enjoy!

Cheers,
Con.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Permalink | Reply | 0 comments |
headers
Con Kolivas | 1 May 2002 01:01

Re: Combined low latency & performance patches for 2.4.18

On Tue, 30 Apr 2002 02:51, you wrote:
> After applying it, if you ever do a make mrproper oldconfig dep bzImage it
> fails to compile sched.c as follows

> If I don't  do an mrproper it compiles ok. Haven't tested yet.

Hmm
I used a make mrproper && make clean followed by manual configuration without 
any problems but thanks for your input. I'm not claiming to be a patch or 
kernel guru. Just offering what worked for me.

> It's the O1 sched patch. Not your fault....

Thanks thats kinda reassuring :)

Con.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Permalink | Reply | 5 comments |
headers
Alan Cox | 1 May 2002 01:40
Picon

Re: romfx XIP patch

> Flash-ROM. Because the machine doesn't have too much memory, I have fixed
> 2.2.18 kernel, so that it keeps all unwritable sections if ROM and that's
> the place where they're executed for. Thanks to that I have spared about
> 500KB of memory.

(I'd be interested in these patches too)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Permalink | Reply | 1 comment |
headers
Alan Cox | 1 May 2002 01:45
Picon

Re: SMP race condition on startup with patch

> I found a smp race condition on startup
> of the 2.4.18 kernel when I put a printk
> in schedule.

Yep. Its already fixed in my tree if I remember rightly. 

BTW - a useful tip for checking your port is to memset the __init pages
to an illegal instruction value as you reclaim them.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Permalink | Reply | 0 comments |
headers
Alan Cox | 1 May 2002 01:53
Picon

Re: Kernel 2.4.x and ASUS A7M266-D

> We are using 2.4.18 with that board and it works fine.
> Just have to choose MPS1.1 in the BIOS...

Ditto.

I had great pain with the bios, and the manual but the board itself is
really nice and I'm very happy with that part of it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Permalink | Reply | 0 comments |
headers
Woodruff, Robert J | 1 May 2002 01:37
Picon

[ANNOUNCE] InfiniBand S/W project started on SourceForge

Hi all,

	An InfiniBand S/W project has been open on sourceforge.net
http://sourceforge.net/projects/infiniband.

	The site contains early reference code for an
	             InfiniBand Transport and OS infrastructure 
	             Virtual NIC Driver
	              IP LAN emulation driver that runs over InfiniBand
	              SCSI RDMA Protocol (SRP) driver
	              VIPL

	The project  intends to develop a production ready InfiniBand S/W
stack (using the existing code as a reference)
	and solicits participation from all interested parties in industry
and the Linux community at large.  The goal of the project
	is to produce an InfiniBand S/W OS infrastructure worthy of
inclusion in standard Linux distributions. 

	Refer to the Home Page on the SourceForge project for project
descriptions, details, and a list of contacts. 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Permalink | Reply | 0 comments |
headers
Andries.Brouwer | 1 May 2002 01:41
Picon
Picon
Favicon

[WIP] Apacer SmartMedia driver

I just got myself an Apacer SM/CF combo reader, USB 07c4:a109.
The CF part is supported in the stock kernel (by datafab.c),
the SM part is not.
This evening I wrote a read-only driver; hope to add the
writing part soon.
If anyone has information (or a Linux driver) I'd like to hear.

Andries

[Another interesting point is Olympus. Do I understand
correctly that Olympus put its name in the CIS, that moreover
many SM readers refuse to write the CIS, and that an Olympus
camera will say "Card Error" when it doesn't find the string
"OLYMPUS", so that Olympus can sell SM cards at a higher price?]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Permalink | Reply | 0 comments |
headers
Lawrence Walton | 1 May 2002 02:05

Re: 2.5.10 and 2.5.11 not booting

Dave Jones [davej <at> suse.de] wrote:
<snip>
> This dump is useless to anyone, as the addresses need to be converted
> to symbol names. The EIP being the more important one, followed by the
> call trace.
> 
Here is the new and improved opps run through ksymoops, minus a _lot_ of warnings.! 

unable to handle kernel null pointer deference at address 00000016
c0198147
CPU: 0
EIP: 0010:[<c0198147>] not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010213
EAX: 00000000 EBX: c17p4ac0 ECX: c17fec00 EDX: 00000088
Warning (Oops_set_regs): garbage 'EBX: c17p4ac0 ECX: c17fec00 EDX: 00000088' at end of register line ignored
ESI: 00000004 EDI: 00000008 EBX: c17f4ac0 ESP: c16e7dcc
DS: 0018 ES:0018 SS:0018
Stack: c17f4ac0 effe8bc0 00000000 c17fec00 00000006 c019b52c c17fec00
c16e7e00 c17fed60 c17fec00 00000000 00000000 c019b651 c17fedb0
c17fec00 00000001 effe8bc0 c019ba3b c17fedb0 c17fec00 c16cefc0 effe8c0
call trace: [<c01a0935>] [<c01a6co7>] [<c01a0d1a>] [<c0193pbp>] [<c0194512>]
[<c0194512>] [<c01a6c07>] [<c01a0cfd>] [<c01a0d1a>] [<c01935b6>] [<c01936ca>]
[<c019e08d>] [<c019f18e>] [<c019dff0>] [<c019f8bd>] [<c019dff0>] [,c019dfa6>]
[<c019dff0>] [<c01a73a3>] [<c0105027>] [<c0106fb8>]
code: 81 50 16 80 e2 04 b8 04 00 00 00 84 d2 0f 45 f8 39 fe 76 56

>>EIP; c0198147 <acpi_ex_read_data_from_field+57/150>   <=====

>>EBX; c17f4ac0 <_end+1491e6c/304d63ac>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Fedyk | 1 May 2002 02:15

Inactive instead of Inact_dirty, Inact_clean & Inact_target breaks sar

Hi,

I was just trying out sar (sysstat package in debian), and I noticed that
with an -aa vm several values are blank.

inadtypg, inaclnpg, and inatarpg, represent the three values in /proc/meminfo.

It looks like the best thing to do is simply file a bug against the sar
package, but I thought it deserved mentioning here too.

Thanks,

Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Permalink | Reply | 0 comments |
headers
David Dyck | 1 May 2002 02:28

changes between 2.2.20 and 2.4.x 'broke' select() from detecting input characters in my serial /dev/ttyS0 program


I have a program that opened "/dev/ttyS0" twice,
once as O_RDONLY, and once as O_WRONLY
 (I know now that I could have opened only one channel O_RDWR)

The program used tcsetattr( ,TCSANOW, ) to modify
c_iflag, c_oflag, and c_cflag for both channels.
first for the O_RDONLY channel, and then for the O_WRONLY.

Later the program used select() on the O_RDONLY channel to
detect characters, and read() to extract them from the driver.
This used to work in 2.2.x, (2.2.20) but select() now reports no characters
available on 2.4.x (today it is 2.4.19-pre7-ac3).

If I change the order of the tcsetattr() to modify the O_RDONLY
after the O_WRONLY channel, then it works on both 2.2.x and 2.4.x.
I have a workaround (by changing the order), but this order
dependency is not documented and I wonder if it is some new
feature, or a bug.
 (I think it is a bug)

I have a 158 line program that I use to demonstrate the
bug that I could email if requested.

I am wondering what changed between 2.2.x and 2.4.x that
could have caused this change in behaviour.

It turns out also that the O_WRONLY channel had CREAD turned off,
which I would expect was appropriate for an output channel, and
in 2.2 kernels, it didn't affect the O_RDONLY channel.  If I enable
(Continue reading)

Permalink | Reply | 2 comments |

Gmane