Re: linux 2.4.3 crashed my hard disk

[Andre Hedrick]

On Fri, 6 Apr 2001, Ion Badulescu wrote:

> On Fri, 6 Apr 2001, Andre Hedrick wrote:
> 
> > > You really ought to rename this parameter to pcibus. Even though it doesn't
> > > do justice to the VLB bus, the potential for user error is much smaller.
> > 
> > Until today you had a vaild point!
> > 
> > Promise Ultra100TX2 (20268 chipset).
> > 
> > This is a 66MHz clocked Ultra100 Chipset release this week.
> 
> Ok... but how does this invalidate my point? The 66MHz still applies to 
> the PCI bus, so pcibus is ok for the parameter name, no?

Because this card is designed to run in a 66MHz pcibus or standard 33MHz
pcibus, but the idebus/bridge is clocked at double pump or 1:1 depending
on the busses 64-bit/66MHz, 64-bit/33MHz, or 32-bit/33MHz

This is were it gets messyso I do not have an answer that I valid
at this point, however I do know that 66MHz clocking is about to become
standard...

Cheers,

Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035Web: www.aslab.com

-
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: linux 2.4.3 crashed my hard disk

[Ion Badulescu]

On Fri, 6 Apr 2001, Andre Hedrick wrote:

> > You really ought to rename this parameter to pcibus. Even though it doesn't
> > do justice to the VLB bus, the potential for user error is much smaller.
> 
> Until today you had a vaild point!
> 
> Promise Ultra100TX2 (20268 chipset).
> 
> This is a 66MHz clocked Ultra100 Chipset release this week.

Ok... but how does this invalidate my point? The 66MHz still applies to 
the PCI bus, so pcibus is ok for the parameter name, no?

Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.

-
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: linux 2.4.3 crashed my hard disk

[Andre Hedrick]

On Fri, 6 Apr 2001, Ion Badulescu wrote:

> On Fri, 06 Apr 2001 21:30:24 -0700, Andre Hedrick <[EMAIL PROTECTED]> wrote:
> > 
> > You killed yourself
> > 
> > You do not have a host that will do idebus=66
> 
> You really ought to rename this parameter to pcibus. Even though it doesn't
> do justice to the VLB bus, the potential for user error is much smaller.

Until today you had a vaild point!

Promise Ultra100TX2 (20268 chipset).

This is a 66MHz clocked Ultra100 Chipset release this week.


Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035Web: www.aslab.com

-
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: linux 2.4.3 crashed my hard disk

[Ion Badulescu]

On Fri, 06 Apr 2001 21:30:24 -0700, Andre Hedrick <[EMAIL PROTECTED]> wrote:
> 
> You killed yourself
> 
> You do not have a host that will do idebus=66

You really ought to rename this parameter to pcibus. Even though it doesn't
do justice to the VLB bus, the potential for user error is much smaller.

Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
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/

module problem with new kernel

[Lee Leahu]

hello everyone!

i recently installed suse 7.1 kernel 2.4.0-4GB on an IBM 600E laptop.
it runs execellent!
but i wanted to also have sound, so through make xconfig i added
the sound module, then i found out i had to enable reiserfs (that's what fs i use)
and pcmcia.
now it's complaining that it can't find the modules - suse installed the modules in
/usr/lib/modules/2.4.0-4GB and the new kernel is the plain 2.4.0 and is looking
in /usr/lib/modules/2.4.0

can i make a symling from 2.4.0 to 2.4.0-4GB or is there a twist in it?

is there a way i can tell from somewhere what all the options where used to complie 
the 
original kernel from suse where?

-- 
Lee Leahu <[EMAIL PROTECTED]>,
System Admin,
Web Developer,
RICIS Inc,
(708) 444-2690 (Work)
(708) 467-2044 (Pager)
-
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: linux 2.4.3 crashed my hard disk

[Andre Hedrick]

You killed yourself

You do not have a host that will do idebus=66
You have now dived you clock timing in half.
You should expect to have a driver time out before the device is
completed.

-- 
Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035Web: www.aslab.com
-
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/

linux-2.4.3-ac3.tfhsio2/drivers/ide/Makefile

[Andre Hedrick]

Alan,

Since this is no more than a chipset that is identical to piix.c
Why is it setup as a loadable object?

obj-$(CONFIG_BLK_DEV_IT8172)+= it8172.o

and not like below?

ide-obj-$(CONFIG_BLK_DEV_IT8172)   += it8172.o

Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035Web: www.aslab.com

-
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: kernel BUG at page_alloc.c:75! / exit.c

[TimO]

[EMAIL PROTECTED] wrote:
> 
> "Albert D. Cahalan" wrote:
> >
> > > I'm running the 2.4.3 kernel and my system always (!) crashes when I try
> > > to generate the "Linux kernel poster" from lgp.linuxcare.com.au. After
> > > working for one hour, the kernel printed this message:
> >
> > I'd guess you have a heat problem. Check for dust, a slow fan,
> > an overclocked CPU, memory chips with airflow blocked by cables,
> > motherboard chips that are too hot to touch...
> 
> none of the above, but the CPU (Athlon) temperature is at ~65 °C. Is
> this ok?
> 
> thanks,
> Felix
> 

Hmmm, my (BIOS)default is to shut down at 56 C.  Normally runs between
40 and 42 C.  This is with a 750 Mhz Athlon.  Nothing in the docs says
what is acceptable.  Maybe check out the AMD web page.

===
-- Tim
-
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: How do I compile properly after changing tcp_input.c etc?

[Bart Trojanowski]

On Fri, 6 Apr 2001, Bill Geissler wrote:

> I need to modify the tcp_input.c and tcp_output.c code
> for a thesis, and want to make sure that I don't mess
> things up when I recompile the code.
>
> What do I need to do to properly recompile the tcp
> functions with my modifications?

As long as you don't change the way the API is presented you need only to
run 'make bzImage' (or whatever you used before) from the root of a
preconfigued tree.

If you modify some functions or structures you may need to run 'make
mrproper' (cleans out all versioning info and configuration) and then run
your usual 'make '.

> Any info would be appreciated.

Cheers,
Bart.



-- 
WebSig: http://www.jukie.net/~bart/sig/


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

How do I compile properly after changing tcp_input.c etc?

[Bill Geissler]

I need to modify the tcp_input.c and tcp_output.c code
for a thesis, and want to make sure that I don't mess
things up when I recompile the code.

What do I need to do to properly recompile the tcp
functions with my modifications?

Any info would be appreciated.

Bill

__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/
-
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/

How to build modules outside the kernel tree? [Was: Proper way to release binary driver?]

[Eric W. Biederman]

Christopher Turcksin <[EMAIL PROTECTED]> writes:

> "Eric W. Biederman" wrote:
> 
> > If what you are after is a way to release a driver that is not a
> > hassle to add to an already working system, you will find a more
> > receptive ear.  I have heard some talk, that it would be a good idea
> > to figure out how to standardize how to compile a kernel driver
> > outside the kernel tree, so it could be trivial enough that anyone
> > could do it.  To date there are enough people around who don't have
> > problems compiling their own kernel that this hasn't become a major
> > issue.
> 
> Eric,
> 
> I am finding myself exactly in this situation, and I've got a feeling
> that this won't be the last time either.
> 
> I expect that every future Linux driver I get involved with will be
> released under GPL. However, I think that the majority of our customers
> will be running a distribution that does not yet support a new driver,
> and even at Linux speeds, it'll take a long enough time that customers
> cannot afford to wait for the next release that includes the driver.
> 
> So the big issue for us appears to be how we support these customers.
> 
> There is no way that we can support customers who have custom kernels,
> but since they are 'in it' enough to compile their own kernel, I guess
> they're able to apply our patch and recompile it. I actually suspect
> that there aren't that many who do this anyway.
>
> Where we find we have a problem is the number of different 'standard'
> kernels out there. We find that we need to support all releases since
> the last year or so for each distribution. And for each of those, we
> find that there are many different kernel versions (some bugfixes, some
> provide half a dozen different kernels with the CDs, aso.). And since we
> do not expect these customers to compile their own kernel, we see no
> option but to provide a precompiled binary driver. The numbers multiply
> quickly and building all of those becomes an interesting problem.
> 
> We had hoped that MODVERSIONS would allow us to provide a single (or at
> most a few) binary driver. Kernels with even minor version numbers are
> supposed to be stable (even if they are buggy) ie. not have wildly
> changing kernel interfaces.
> 
> In practice, that doesn't work. A driver compiled with 2.2.16 doesn't
> load with 2.2.16-5.0 (from RedHat 6.2) (just an example). 

It's a good example of the problems, but a bad example of problems
caused be kernel maintenance.  

RedHat does not run stock linux kernels, but instead seems to patch
the kernel to include work-around for various known bugs and
deficiencies.  What this means is that they are more willing than the
mainstream kernel developers to include changes to the kernel.  A
example that comes to mind are the md drivers that implement software
raid. 

So for solutions (That I know of):

With recent kernels with modules_install a:
 /lib/modules/`uname -r`/build
directory is created, that effectively points to the kernel source
tree the modules were built with.  With the 2.4.x currently this is a
symlink so but it should be o.k.  It needs to be checked that the
distributors are using this directory appropriately, but it looks like
a good thing to support.  Longterm this looks like a solution
to the problem, of how to get kernel headers to match a kernel.  

This should even has a chance to work with people who build their own
kernel.

With Redhat and many derivatives as a fallback there is kernel source in 
/usr/src/linux that does it's best to match the currently running
kernel.

Using either of those locations for the source to kernel headers it
should be possible to build a package that as part of it's install
process compiles appropriate drivers, at least for most of the cases.

I suspect there is enough work in this for someone to create a support
package, that included makefiles and all the rest to assist in
building a drivers on various platforms.  Any takers?

Eric.






-
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: [PATCH for 2.5] preemptible kernel

[Andi Kleen]

Hallo, 

On Fri, Apr 06, 2001 at 04:52:25PM -0700, Paul McKenney wrote:
> 1.   On a busy system, isn't it possible for a preempted task
>  to stay preempted for a -long- time, especially if there are
>  lots of real-time tasks in the mix?

The problem you're describing is probably considered too hard to solve properly (bad 
answer,
but that is how it is currently) 

Yes there is. You can also force a normal (non preemptive) kernel into complete 
livelock by 
just giving it enough network traffic to do, so that it always works in the high 
priority 
network softirq or doing the same with some other interrupt. 

Just when this happens a lot of basic things will stop working (like page cleaning, IO 
flushing etc.), so your callbacks or module unloads not running are probably the least
of your worries.  

The same problem applies to a smaller scale to real time processes; kernel services 
normally do not run real-time, so they can be starved. 

Priority inversion is not handled in Linux kernel ATM BTW, there are already situations
where a realtime task can cause a deadlock with some lower priority system thread
(I believe there is at least one case of this known with realtime ntpd on 2.4) 

> 2.   Isn't it possible to get in trouble even on a UP if a task
>  is preempted in a critical region?  For example, suppose the
>  preempting task does a synchronize_kernel()?

Ugly. I guess one way to solve it would be to readd the 2.2 scheduler taskqueue,
and just queue a scheduler callback in this case.

-Andi
-
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: [PATCH for 2.5] preemptible kernel

[Paul McKenney]

Please accept my apologies if I am missing something basic, but...

1.   On a busy system, isn't it possible for a preempted task
 to stay preempted for a -long- time, especially if there are
 lots of real-time tasks in the mix?

2.   Isn't it possible to get in trouble even on a UP if a task
 is preempted in a critical region?  For example, suppose the
 preempting task does a synchronize_kernel()?

If I understand the preemptible kernel patch, suppressing preemption
is quite cheap -- just increment preempt_count before and decrement
it after, with no locks, atomic operations, or disabling of interrupts
required.  I understand that disabling preemption for any long time
is a Bad Thing, however, Dipankar's patch is able to detect situations
where preemption has been suppressed for too long.  In addition, Rusty's
original synchronize_kernel() patch is much simpler than the two that
wait for preempted tasks to reach a voluntary context switch.

What am I missing here?

   Thanx, Paul

> > Here is an attempt at a possible version of synchronize_kernel() that
> > should work on a preemptible kernel. I haven't tested it yet.
>
> It's close, but...
>
> Those who suggest that we don't do preemtion on SMP make this much
> easier (synchronize_kernel() is a NOP on UP), and I'm starting to
> agree with them. Anyway:
>
> > if (p->state == TASK_RUNNING ||
> > (p->state == (TASK_RUNNING|TASK_PREEMPTED))) {
> > p->flags |= PF_SYNCING;
>
> Setting a running task's flags brings races, AFAICT, and checking
> p->state is NOT sufficient, consider wait_event(): you need p->has_cpu
> here I think. You could do it for TASK_PREEMPTED only, but you'd have
> to do the "unreal priority" part of synchronize_kernel() with some
> method to say "don't preempt anyone", but it will hurt latency.
> Hmmm...
>
> The only way I can see is to have a new element in "struct
> task_struct" saying "syncing now", which is protected by the runqueue
> lock. This looks like (and I prefer wait queues, they have such nice
> helpers):
>
> static DECLARE_WAIT_QUEUE_HEAD(syncing_task);
> static DECLARE_MUTEX(synchronize_kernel_mtx);
> static int sync_count = 0;
>
> schedule():
> if (!(prev->state & TASK_PREEMPTED) && prev->syncing)
> if (--sync_count == 0) wake_up(&syncing_task);
>
> synchronize_kernel():
> {
> struct list_head *tmp;
> struct task_struct *p;
>
> /* Guard against multiple calls to this function */
> down(&synchronize_kernel_mtx);
>
> /* Everyone running now or currently preempted must
>voluntarily schedule before we know we are safe. */
> spin_lock_irq(&runqueue_lock);
> list_for_each(tmp, &runqueue_head) {
> p = list_entry(tmp, struct task_struct, run_list);
> if (p->has_cpu || p->state
== (TASK_RUNNING|TASK_PREEMPTED)) {
> p->syncing = 1;
> sync_count++;
> }
> }
> spin_unlock_irq(&runqueue_lock);
>
> /* Wait for them all */
> wait_event(syncing_task, sync_count == 0);
> up(&synchronize_kernel_mtx);
> }
>
> Also untested 8),
> Rusty.

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

mkinitrd and 2.4.x annoyances

[Tony Hoffmann]

While trying to upgrade a redhat 6.2 I've come across the following
annoyance.

Changes states that you need mkinitrd 2.9 or better.  No problem. Go to
redhat
site and grab source rpm.  In my case 3.0.5 was the one available. 
Build and
install the package.  Run it. Curse. Turns out that mkinitrd relies on
mktemp
accepting the -d which under 6.2 isn't the case.  And remakeing mktemp
isn't
an option as I'm not about to upgrade to glibc 2.2 just for that.  It
was an
easy enough fix to patch mkinitrd to not rely on the -d flag but still
bloody
annoying.  I can see why they use mktemp -d as they do all the work in
the /tmp
dir so want to avoid potential races in creating the temp directories
but why
use /tmp at all?  It's possible to do everything in the current working,
No?
-
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/

[Fwd: No USB under 2.4.3 and 2.4.3-ac?]

[Sid Boyce]

-- 
Sid Boyce ... hamradio G3VBV ... Cessna/Warrior Pilot
Linux only shop.. Tel. 44-121 422 0375


This happens on a PIII/GigaByte 6BXE, Athlon 900/ABit KT7 and on a
friend's Cyrix M-II/333 with PC-Chips PC100 mobo and SIS chipset. The
PIII is a SuSE 6.4 base +, the others are SuSE 7.1 + modutils-2.4.5
and a few other bits.
During boot and "lsusb" ver 0.7 only show the on-board USB chip, it
does not see the outboard Hub or devices. lsusb on the PIII will also
show the on-board chip, on the other machines it returns blank.
We haven't yet tried USB as modules to see if it makes a difference.

# USB support
#
CONFIG_USB=y
CONFIG_USB_DEBUG=y

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_BANDWIDTH=y

#
# USB Controllers
#
CONFIG_USB_UHCI=y  CONFIG_USB_UHCI_ALT=y on Athlon)

# USB Device Class drivers
CONFIG_USB_PRINTER=y

# USB Imaging devices
CONFIG_USB_SCANNER=m

# USB Multimedia devices
CONFIG_USB_OV511=m on the Athlon

Regards

-- 
Sid Boyce ... hamradio G3VBV ... Cessna/Warrior Pilot
Linux only shop.. Tel. 44-121 422 0375

No USB under 2.4.3 and 2.4.3-ac?

[Sid Boyce]

This happens on a PIII/GigaByte 6BXE, Athlon 900/ABit KT7 and on a
friend's Cyrix M-II/333 with PC-Chips PC100 mobo and SIS chipset. The
PIII is a SuSE 6.4 base +, the others are SuSE 7.1 + modutils-2.4.5
and a few other bits.
During boot and "lsusb" ver 0.7 only show the on-board USB chip, it
does not see the outboard Hub or devices. lsusb on the PIII will also
show the on-board chip, on the other machines it returns blank.
We haven't yet tried USB as modules to see if it makes a difference.

# USB support
#
CONFIG_USB=y
CONFIG_USB_DEBUG=y

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_BANDWIDTH=y

#
# USB Controllers
#
CONFIG_USB_UHCI=y  CONFIG_USB_UHCI_ALT=y on Athlon)

# USB Device Class drivers
CONFIG_USB_PRINTER=y

# USB Imaging devices
CONFIG_USB_SCANNER=m

# USB Multimedia devices
CONFIG_USB_OV511=m on the Athlon

Regards

-- 
Sid Boyce ... hamradio G3VBV ... Cessna/Warrior Pilot
Linux only shop.. Tel. 44-121 422 0375
-
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: a quest for a better scheduler

[Nathan Straz]

On Fri, Apr 06, 2001 at 11:06:03AM -0700, Timothy D. Witham wrote:
> Timothy D. Witham wrote :
> > I propose that we work on setting up a straight forward test harness   
> > that allows developers to quickly test a kernel patch against 
> > various performance yardsticks.

The Linux Test Project would like to help out here.  At the least, we
would like to add the scripts, wrappers, and configuration files used to
create the test systems to LTP.  Making test systems available is
definitely a great step forward.  Showing people how to build similar
test systems is another step forward.  

Let us know what parts you need and we'll see what we can come up with.

> Further comments?  I will start contacting folks who have expressed
> interest.

If anyone has loose programs that they use to test the scheduler, please
submit them to the Linux Test Project.  Chances are other people will
also find them useful and add functionality.  It doesn't have to be a
formal test program or use the test libraries that we use.  We can take
care of that when we add it to the CVS tree.

While we probably aren't going to package up full applications for
testing purposes, we could definitely keep track of useful configuration
files and scripts that people find useful for testing.  

-- 
Nate Straz  [EMAIL PROTECTED]
sgi, inc   http://www.sgi.com/
Linux Test Projecthttp://oss.sgi.com/projects/ltp/
-
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: Seems to be a lot of confusion about aic7xxx in linux 2.4.3

[John Cavan]

"Jeffrey W. Baker" wrote:
> So, I conclude that the patch was created incorrectly, or that something
> changed between cutting the patch and the tarball.

Compiled fine for me without the complete tarball, just patched. Now, I
went straight to ac2 (now ac3) without building the 2.4.3 stock kernel.

Have you tried a "make mrproper" on the tree?

John
-
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: modutils / sound

[Guennadi Liakhovetski]

Sound modules don't autoload - when you start what? I noticed a strange
thing too - when I start a light window-manager, like lfwm or fvwm2 and
THEN start, say, kmix - modules do get loaded, however, if I try starting
kde with sounds configured when the modules are NOT loaded, it complains
'no sound device available', and the modules don't get loaded. However, if
I then start kmix or smth - modules do get loaded and sound is ok. Are you
observing smth similar? If your modules don't get autoloaded ever... Well,
did you check depmod -ea? What kernel version? Sorry, can't help more so
far... Looks like you are using OSS drivers. Did you ever try ALSA? I had
problems, when I tried ALSA after OSS and then switched back - are all
your /dev-ices with char-major 14 ok?

Also, I think, it happens that some modules just can't be forced to
autoload with some kernel versions...

Guennadi

On Fri, 6 Apr 2001, isaac albeniz wrote:

> 
> I just upgraded to modutils 2.4.5, and my sound modules wont autoload
> anymore. They work fine if i manually load them but that is an
> unacceptable solution.
> 
> alias char-major-14 sb
> options sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330
> options sound dmabuf=1
> 
> Those are the lines ive always used in modules.conf and have always worked
> till i upgraded.
> 
> Any suggestions? Please CC me im not on the list.
> 
> -
> 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/
> 

___

Dr. Guennadi V. Liakhovetski
Department of Applied Mathematics
University of Sheffield, U.K.
email: [EMAIL PROTECTED]


-
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: memory allocation problems

[Hugh Dickins]

On Fri, 6 Apr 2001, Wayne Whitney wrote:
> 
> As was pointed out to me in January, another solution for i386 would be to
> fix a maximum stack size and have the mmap() allocations grow downward
> from the "top" of the stack (3GB - max stack size).  I'm not sure why that
> is not currently done.

I'd be interested in the answer to that too.  Typically, the memory
layout has ELF text at the lowest address, starting at 0x08048000 -
which is a curious place to put it, until you realize that if you
place the stack below it, you can use (in a typical small program)
just one page table for stack + text + data (then another for mmaps
and shared libs from 3GB down): two page tables instead of present three.

Hugh

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

Attn: Sales Manager

[Bernard Hartken]

Attn: Sales Manager
 
If you are outsourcing or need to expand your sales force for the short term or long 
term contract, TeleXpand 
will create a tailored campaign to guarantee you and your product success.

We are an established, full service call center with a completely trained staff of 70 
plus salespeople with a 
proven track record to close sales for your product or service.

We currently market over $1 million dollars per month in closed sales for one of the 
largest companies in the 
Washington D.C. area,  scheduling approximately 300 appointments per week...again, 
these are closed sales! 

We service ALL industries who would be interested in a telemarketing campaign of any 
size! 
Our prices are very competitive. 

Let's talk... 

Bernard Hartken
General Manager
814.459.8238

Visit us at http://www.telexpand.bigstep.com
-
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: a quest for a better scheduler

[Michael Peddemors]

Missing an important one, our VPN's routinely run on 16 MG Ram, no HD or swap..
Loaded from an initrd on a floppy..

Don't we need to test on minimalistic machines as well :)

> So the server hardware configurations have evolved to look like 
> the following.
> 
>   1 way, 512 MB,   2 IDE
>   2 way,   1 GB,  10 SCSI (1 SCSI channel)
>   4 way,   4 GB,  20 SCSI (2 channels) 
>   8 way,   8 GB,  40 SCSI (4 channels) maybe Fibre Channel (FC)
>16 way,  16 GB,  80 FC   (8 channels)
> 

-- 
"Catch the Magic of Linux..."

Michael Peddemors - Senior Consultant
LinuxAdministration - Internet Services
NetworkServices - Programming - Security
WizardInternet Services http://www.wizard.ca
Linux Support Specialist - http://www.linuxmagic.com

(604)589-0037 Beautiful British Columbia, Canada

-
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: [PATCH] Core dumps for threads

[John Van Horne]

Don,

I've searched the linux-kernel mail archives about this patch, and the most
recent 
thing I can find is that it was waiting for verification.

http://www.uwsg.indiana.edu/hypermail/linux/kernel/0102.3/0553.html

Is there anything more recent?  Has it been accepted?

Also, if I apply this patch to the kernel I am running (2.4.2), will I need
to patch gdb to be able
to read core dumps made by threads?  Or should I ask the gdb maintainers
this question?

Please include my mail address in your response, as I do not subscribe to
linux-kernel.

Thanks,
-John



John Van Horne  voice: 650-628-4148
Software Tools Engineer fax:  650-637-2411
CoSine Communications, Inc. cell: 650-346-0401
  email:
[EMAIL PROTECTED]




-
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: st corruption with 2.4.3-pre4

[Gérard Roudier]

On Fri, 6 Apr 2001, Gérard Roudier wrote:

> Here is a patch that removes the offending PPC PCI hacky area from the
> driver (sym53c8xx_defs.h):
> 
> --- sym53c8xx_defs.h  Fri Apr  6 16:23:48 2001
> +++ sym53c8xx_defs.h.orig Sun Mar  4 13:54:11 2001
> @@ -175,6 +175,9 @@
>  #define  SCSI_NCR_IOMAPPED
>  #elif defined(__alpha__)
>  #define  SCSI_NCR_IOMAPPED
> +#elif defined(__powerpc__)
> +#define  SCSI_NCR_IOMAPPED
> +#define SCSI_NCR_PCI_MEM_NOT_SUPPORTED
>  #elif defined(__sparc__)
>  #undef SCSI_NCR_IOMAPPED
>  #endif
>  Cut Here --

The patch is obviously reversed. You just have to remove the 3 lines that
apply to powerpc using you preferred editor.
Btw, using the one you dislike the most will also fit. :-)

  Gérard.

-
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: st corruption with 2.4.3-pre4

[Gérard Roudier]

On Thu, 5 Apr 2001, Geert Uytterhoeven wrote:

> 
> BTW, my 2.4.3-pre8 kernel just said
> 
> | sym53c875-0:0: ERROR (81:0) (3-21-0) (10/9d) @ (script 8a8:0b00).

Illegal instruction detected.

> | sym53c875-0: script cmd = 1100
> | sym53c875-0: regdump: da 10 80 9d 47 10 00 0d 00 03 80 21 80 01 09 09 00 30 4e 00 
>08 ff ff ff.
> | sym53c875-0-<0,*>: FAST-20 WIDE SCSI 40.0 MB/s (50.0 ns, offset 16)
> 
> during the boot process, and continued without problems. What does this mean?

Looks extremally serious to me.

The SCRIPTS processor should be fetching CHMOV DSA relative when DATA_IN
instructions. This corresponds to opcode 0x1100.

However, it seems to have fetched instruction 0x0b00 which is a 
MOVE ABSOLUTE WHEN STATUS PHASE.

In (3-21-0) we can see that the chip is expecting STATUS PHASE (3), but
the target is driving DATA IN phase (21 - the 1 indicates DATA IN phase).

In other word, the SCRIPTS processor seems to have fetched a bogus
instruction. The signaled 'illegal instruction detected' may be due to the 
count of bytes to transfer to be zero.

> Gr{oetje,eeting}s,

  Gérard.

-
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: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

[Maciej W. Rozycki]

On Fri, 6 Apr 2001, Andrea Arcangeli wrote:

> ev6 works the way you described AFIK (to flush the write buffer you can use

 Thanks for the clarification -- you made me calm down.

> wmb(), note that wmb() semantics doesn't require the cpu to really "flush" but
> just to keep writes oredered across other mb or wmb, but it's basically the
> same from a software point of you and flushing the write buffer synchronously
> obviously provides that semantics).  I didn't followed very closely the

 Of course -- you only want to do mb (and not wmb) if you need to meet
hw's specific timing or you want to perform a read from a volatile
register of a peripheral device. 

> previous part of the thread so I'm not sure what is the issue.

 Someone complained of Alpha not having Intel-style MTRRs to set write
combining for fb memory...

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--+
+e-mail: [EMAIL PROTECTED], PGP key available+

-
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: memory allocation problems

[Mark Hahn]

> > note, though, that you *CAN* actually malloc a lot more than 1G: you
> > just have to avoid causing mmaps that chop your VM at
> > TASK_UNMAPPED_BASE:
> 
> Neat trick.  I didn't realize that you could avoid allocating the mmap()
> buffers for stdin and stdout.

noone ever said you had to use stdio.  or even use libc, for that matter!

> As was pointed out to me in January, another solution for i386 would be to
> fix a maximum stack size and have the mmap() allocations grow downward
> from the "top" of the stack (3GB - max stack size).  I'm not sure why that
> is not currently done.

problems get fixed when there's some pain involved: people bumping 
into a limit, or painfully bad code, etc.  not enough people are 
feeling any pain about the current design.

this (and the "move TASK_UNMAPPED_BASE" workaround) have been known
for years; I think someone even coded up a "grow vmareas down" patch
the last time we all discussed this.

> I once wrote a tiny patch to do this, and ran it successfully for a couple
> days, but knowing so little about the kernel I probably did it in a
> completely wrong, inefficient way.  For example, some of the vma
> structures are sorted in increasing address order, and so perhaps to do
> this properly one should change them to decreasing address order.

oh, I guess you did the patch ;)
seriously, resubmit it when 2.5 opens up.  the fact is that we currently
have two things that grow up, and one that grows down.  so obviously,
one up-grower must have an arbitrary limit.  switching vma's to down-growing
is a good solution, since it's actually *good* to limit stack growth.  
I wonder whether fortraners still put all their data on the stack;
they wouldn't be happy ;)

a simple workaround would be to turn TASK_UNMAPPED_AREA into a variable,
either system-wide or thread-specific (like ia64 already has!).  that's 
compatible with the improved vmas-down approach, too.

regards, mark hahn.

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

Special packet inspecting bridging

[Mircea Ciocan]

Hi all,

I'd like to start a project involving a packet inspecting
Ethernet
bridge/firewall/traffic shaper that is protocol independent ( I mean no
ties to high level protocols like TCP/IP or IPX for ex.).
What I want to do is get raw Ethernet packets from one
interface, pipe
it trough an user level program and then inject it in the other one, and
viceversa, of course ;).
Please advise me of the means of doing this with minimum
overhead
possible, or if someone started a similar project please let me know.

Thank you,

Mircea C.
-
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: memory allocation problems

[Wayne Whitney]

On Fri, 6 Apr 2001, Mark Hahn wrote:

> note, though, that you *CAN* actually malloc a lot more than 1G: you
> just have to avoid causing mmaps that chop your VM at
> TASK_UNMAPPED_BASE:

Neat trick.  I didn't realize that you could avoid allocating the mmap()
buffers for stdin and stdout.

As was pointed out to me in January, another solution for i386 would be to
fix a maximum stack size and have the mmap() allocations grow downward
from the "top" of the stack (3GB - max stack size).  I'm not sure why that
is not currently done.

I once wrote a tiny patch to do this, and ran it successfully for a couple
days, but knowing so little about the kernel I probably did it in a
completely wrong, inefficient way.  For example, some of the vma
structures are sorted in increasing address order, and so perhaps to do
this properly one should change them to decreasing address order.

Cheers,
Wayne


-
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: [CHECKER] __init functions called by non-__init

[David S. Miller]

Rusty Russell writes:
 > It's incredibly poor taste, though, and if we ever implement __init
 > dropping for modules (Keith?),

Jakub Jelinek implemented this about 2 years ago, right before
we hit 2.2.x, Linus thought it was too late at the time so
we dropped that work from our trees.

It was really good at finding __init bugs though...

Later,
David S. Miller
[EMAIL PROTECTED]
-
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: [CHECKER] __init functions called by non-__init

[Rusty Russell]

In message <[EMAIL PROTECTED]> you write:
> where if you look in the code, the flagged routine generic_NCR53C400A_setup 
> does indeed not have __init:
>   void generic_NCR53C400A_setup (char *str, int *ints) {
>   internal_setup (BOARD_NCR53C400A, str, ints);
>   }

As long as, of course, making that function an __init would not make
it a class 2 error.

> void __init uninit_aedsp16(void)
> 
> static void __exit cleanup_aedsp16(void) {
> uninit_aedsp16();
> }

Ick.  Currently, this will work, since if it's not a module, __exit
function never get included or called.  If it is a module, __init does
nothing.

It's incredibly poor taste, though, and if we ever implement __init
dropping for modules (Keith?), it'll break horribly of course.  Thus
it's a bug to call __init functions from __exit functions, but not a
very exciting one.

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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.3 tcp window id causes problems talking to windows clients

[David S. Miller]

Kevin Stone writes:
 > Is there any plan to include the zerocopy patches into the stock kernel? 
 >   The win2k dial-up/window id problem is really a showstopper but hasn't 
 > generated much traffic on lkml or the digests. 

I submitted the patch to Linus, it will likely go into 2.4.4
but if not I'll submit the ID patch seperately.

Later,
David S. Miller
[EMAIL PROTECTED]
-
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: memory allocation problems

[Mark Hahn]

> can get at most 2GB.  Newer glibc's allow you to tune the definition
> of "small" via an environment variable.

eventually, perhaps libc will be smart enough to create 
more arenas in mmaped space once sbrk fails.  note, though,
that you *CAN* actually malloc a lot more than 1G: you just
have to avoid causing mmaps that chop your VM at TASK_UNMAPPED_BASE:

#include 
#include 
#include 

void printnumber(unsigned n) {
char number[20];
int i;
for (i=sizeof(number)-1; i>=0 && n; i--) {
number[i] = '0' + (n % 10);
n /= 10;
}
i++;
write(1,number+i, sizeof(number)-i);
}
int main() {
unsigned total = 0;
const unsigned size = 32*1024;

while (malloc(size)) {
total += size;
printnumber(total>>20);
write(1,"\n",1);
}
return 0;
}

compile -static, of course; printnumber is to avoid stdio, which seems
to use mmap for a small scratch buffer.  I allocated 2942 MB on my 128M 
machine(had to add a swapfile temporarily, since so many tiny mallocs 
do touch nontrivial numbers of pages for arena bookkeeping.)

-
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.3 tcp window id causes problems talking to windows clients

[Kevin Stone]

 From linux/include/net/ip.h (2.4.3):

static inline void ip_select_ident(struct iphdr *iph, struct dst_entry *dst)
{
   if (iph->frag_off&__constant_htons(IP_DF))
   iph->id = 0;
   else
   __ip_select_ident(iph, dst);
}

This sets the id on the packet to zero if don't fragment is set.  
Windows however is broken and under certain cirumstances (I think this 
was identified on the list several weeks ago as dialup+compressed 
headers), windows doesn't ack the packets  The result for the client 
is terrible-- it's like there's no connectivity at all-- web  pages 
never load.. etc.

This problem is fixed in the ac series, but didn't make it into Linus's 
2.4.3.  We're running 2.4.2ac11 right now across the board, and it seems 
to be working quite well (except for the lack of swap reclamation-- I 
appreciate the reasoning, but it makes upgrading older machines very 
difficult.)  However, I would rather, for maintenance and sanity 
reasons, run a stock kernel on production machines.  There are also a 
lot of differences between the ac and stock series-- binfmt_misc as 
filesystem vs. proc, ram filesystem (ex: tmpfs on ac), etc. which we 
use.  (We use binfmt_misc+suexec to run php on webservers.)

Is there any plan to include the zerocopy patches into the stock kernel? 
  The win2k dial-up/window id problem is really a showstopper but hasn't 
generated much traffic on lkml or the digests. 


Thanks!
Kevin

-
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: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

[Andrea Arcangeli]

On Fri, Apr 06, 2001 at 07:27:24PM +0200, Maciej W. Rozycki wrote:
> [..] You normally have
> non-cached locations buffered (since you don't always need peripheral
> device accesses to be posted immediately) and can force a writeback with a
> memory barrier. [..]

ev6 works the way you described AFIK (to flush the write buffer you can use
wmb(), note that wmb() semantics doesn't require the cpu to really "flush" but
just to keep writes oredered across other mb or wmb, but it's basically the
same from a software point of you and flushing the write buffer synchronously
obviously provides that semantics).  I didn't followed very closely the
previous part of the thread so I'm not sure what is the issue.

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

modutils / sound

[isaac albeniz]

I just upgraded to modutils 2.4.5, and my sound modules wont autoload
anymore. They work fine if i manually load them but that is an
unacceptable solution.

alias char-major-14 sb
options sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330
options sound dmabuf=1

Those are the lines ive always used in modules.conf and have always worked
till i upgraded.

Any suggestions? Please CC me im not on the list.

-
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: a quest for a better scheduler

[Timothy D. Witham]

Timothy D. Witham wrote :
[...]
> I propose that we work on setting up a straight forward test harness   
> that allows developers to quickly test a kernel patch against 
> various performance yardsticks.

[...
(proposed large server testbeds)
...]


  OK, so I have received some feedback on my proposal to provide a 
reference set of machines so that any kernel modifications could be 
checked across a range of machines and a range of tests.  It was 
pointed out that there are lots of smaller servers out there and 
they should be part of any test plan.  There was also some concern 
that a 4 way server didn't add any value in a test lineup. But I 
have to think that with the number of 4 ways out there they should 
be included.

  One additional piece of feedback was that any comprehensive 
characterization plan should include desktops, tablet devices and 
older machines and the performance tests that address those 
configurations usage models and I agree that it is something that 
needs to be done. But as for providing hardware for that effort the
OSDL is not the group to do that.  Hopefully somebody with an 
interest in these configurations will step forward to do that 
portion of the job.

So the server hardware configurations have evolved to look like 
the following.

1 way, 512 MB,   2 IDE
2 way,   1 GB,  10 SCSI (1 SCSI channel)
4 way,   4 GB,  20 SCSI (2 channels) 
8 way,   8 GB,  40 SCSI (4 channels) maybe Fibre Channel (FC)
   16 way,  16 GB,  80 FC   (8 channels)

The types of server applications that I have heard people express concern are:

   Web infrastructure: 
Apache(SPECWEB99???)
TUX   (SPECWEB99???)
Jabber(have their own)

   Corporate infrastructure: 
NFS   (SPECSFS2.0???)
raw TCP/IP performance
Samba (Have their own)
email (SPECMAIL2001???)

   Database performance: 
 Raw storage I/O performance  (various)
 OLTP workload(something like TPC-C???)
 OLAP workload

   General usage: 
compile speed (usually measured by kernel compile)

  
Further comments?  I will start contacting folks who have expressed
interest.
-- 
Timothy D. Witham - Lab Director - [EMAIL PROTECTED]
Open Source Development Lab Inc - A non-profit corporation
15275 SW Koll Parkway - Suite H - Beaverton OR, 97006
(503)-626-2455 x11 (office)(503)-702-2871 (cell)
(503)-626-2455 (fax)

-
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: 2 times faster rawio and several fixes (2.4.3aa3)

[Andrea Arcangeli]

On Fri, Apr 06, 2001 at 07:36:21PM +0200, Andrea Arcangeli wrote:
> 2/4Mbytes naturally aligned area). so probably I will take the vmalloc way

As expected vmalloc additional 2 tlbs aren't visible in the numbers (that
are mostly dominated by I/O anyways), I think it's the best solution to avoid
the order 2 multipage:

alpha:/home/andrea # time ./rawio-bench 
Opening /dev/raw1
Allocating 50MB of memory
Reading from /dev/raw1
Writing data to /dev/raw1

real0m5.241s
user0m0.002s
sys 0m1.119s
alpha:/home/andrea # time ./rawio-bench 
Opening /dev/raw1
Allocating 50MB of memory
Reading from /dev/raw1
Writing data to /dev/raw1

real0m5.176s
user0m0.003s
sys 0m1.128s
alpha:/home/andrea # time ./rawio-bench 
Opening /dev/raw1
Allocating 50MB of memory
Reading from /dev/raw1
Writing data to /dev/raw1

real0m5.196s
user0m0.002s
sys 0m1.132s
alpha:/home/andrea # time ./rawio-bench 
Opening /dev/raw1
Allocating 50MB of memory
Reading from /dev/raw1
Writing data to /dev/raw1

real0m5.477s
user0m0.004s
sys 0m1.146s
alpha:/home/andrea # time ./rawio-bench 
Opening /dev/raw1
Allocating 50MB of memory
Reading from /dev/raw1
Writing data to /dev/raw1

real0m5.217s
user0m0.004s
sys 0m1.149s
alpha:/home/andrea # 

Tomorrow maybe I will try to speed it up furhter using the desing described in
the first email.

The s/kmem_cache_alloc/vmalloc/ change is here for now and it is rock solid
for me (regression testing is still happy):


ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.3/rawio-2

I think it's ok for inclusion.

Andrea
-
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: syslog insmod please!

[Andrew Daviel]

On Fri, 6 Apr 2001, various people (Ion, David, James) wrote:
>Recent versions of modutils .. log to .. /var/log/ksymoops
>kmod only works when the user calles for the service ..
>consider unix.o

I'm still using 2.2 kernel where unix.o isn't a module and
/var/log/ksymoops doesn't exist, so I suppose that my original suggestion
would work there, no ?

In the usual game of catchup I guess that if RedHat issued a patch to
insmod for RH6 then indeed insmod would be included in r+ootkits.
Currently lr+k4,5 etc. can be detected by tripwire or my rkdet since they
change ls, ps & netstat, but k+nark can't. I haven't seen it in a r+ootkit
yet but it's only a matter of time.

I presume /var/log/ksymoops is local only (unless you take steps to copy
it remotely) ?

rkdet works on the basis of "I don't care how you got in, but
you mess with /bin/ps and I'll panic the firewall". (of course, if
an intruder finds it running under an identifiable name they can kill it)
I'd like to extend this to LKM based cloaking schemes.
I'd looked at LIDS in the past but don't want to patch the kernel.
Besides, I'm not sure whether LIDS module locking allows lkm to run
to load "good" modules like iso9660 on demand.
Loading modules is OK; I can use an unpredictable name to hide it from
scripts & kids.

Again, is there any way to detect a module such as k+nark if someone has
edited it out of the module list (by moving the "next" pointer) ?


("r*kit" mungled to foil search engines - maybe)
-- 
Andrew Daviel, TRIUMF, Canada
[EMAIL PROTECTED]

-
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: gcc oopses with 2.4.3

[Kurt Garloff]

On Fri, Apr 06, 2001 at 06:33:03PM +0200, Norbert Preining wrote:
> On Fre, 06 Apr 2001, Chris Mason wrote:
> > sigbus from gcc usually points to the ram, have you run a tester?
> 
> But sig 4 is sigill (whatever this may be) and 1ig11 sigsegv, so
> no sigbus!?

Illegal Instruction. Your CPU was reading some machine insn from memory it
never heard about. => exception 6 => signal 4 (SIGILL)

If your main memory is not faulty, it's your cache or your CPU. Or your
compiler.

Regards,
-- 
Kurt Garloff  <[EMAIL PROTECTED]>  Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG   SCSI, Security

 PGP signature

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

[Maciej W. Rozycki]

On 6 Apr 2001, Eric W. Biederman wrote:

> I recall on the ev6 all memory accesses to locations with bit 40 set 
> are always to IO space are never cached and are never write buffered.

 If that is the case then EV6 is seriously flawed.  You normally have
non-cached locations buffered (since you don't always need peripheral
device accesses to be posted immediately) and can force a writeback with a
memory barrier.  I don't have my 21264 handbook handy, so I can't check
EV6 details at the moment, especially why it is different.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--+
+e-mail: [EMAIL PROTECTED], PGP key available+

-
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: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

[Maciej W. Rozycki]

On Fri, 6 Apr 2001, Ivan Kokshaysky wrote:

> >  Memory barriers are a separate issue.  On the alpha the
> > natural way to implement it would be in the page table fill code.
> > Memory barriers are o.k. but the really don't help the case when what
> > you want to do is read the latest value out of a pci register.  
> 
> You don't need memory barrier for that. "Write memory barriers" are
> used to ensure correct write order, and "memory barriers" are used
> to ensure that all pending reads/writes will complete before next read
> or write.

 You do.  PCI-space registers are volatile and they may change depending
on what was written (or read) previously.  A memory barrier before a PCI
read will ensure you get a value that is relevant to previous code
actions.  Without a barrier you may get pretty anything, depending on
which of previous writes managed to complete before. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--+
+e-mail: [EMAIL PROTECTED], PGP key available+

-
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: st corruption with 2.4.3-pre4

[Gérard Roudier]

On Fri, 6 Apr 2001, Stefano Coluccini wrote:

> > I'm still waiting for other reports of st/sym53c8xx on PPC under
> > 2.4.x. BTW,
> > does it work on other big-endian platforms, like sparc?
> 
> I don't know if it is the same problem, but ...
> I have a Motorola MVME5100 (PowerPC 750 based CPU) with a mezzanine PCI
> based on the sym53c875 chip. I'm using the 2_5 kernel from fmslabs and the
> first time I have downloaded the kernel all works fine, while in a
> successive update the sym53c8xx driver was changed and my board don't work
> anymore. The driver hangs on downloading the SCSI scripts.
> I'm not a SCSI driver expert, so I've solved the problem installing the old
> version of the driver.
> Tom Rini says to me that it happened when he have merged some updates from
> the 2_4 tree, so I think my problem is related to the latest updates to the
> driver.
> I hope this helps you.
> Bye.
> Stefano.

IMO, it might well be the Linux/PPC PCI interface that doesn't return
expected values.

1) The [sym|ncr]53c8xx need to know about BAR addresses as physical
   address values as seen from the BUS. These values are used by the 
   SCSI SCRIPTS and _NOT_ by the CPU.

2) The pcidev structure returns cookies instead, that commonly are
   BARs physical addresses as seen from CPU.

The recent change in the Symbios driver about point (1) is that the
driver now reads the BARs using the pci_read_config*() interface. If these
functions donnot return the actual BAR values usable from the BUS for some
obscure reasons, this may explain your problem.

The cookies contained in the pcidev structure are completely useless for
the driver and probably for any driver. They just have to be used to remap
memory BARs to CPU virtual addresses. Then the driver forgets about them.

There are still some PPC PCI specific hacks in the sym53c8xx driver and it
has been reported to me that they can be removed. If the PPC PCI interface
is correct, then they should be removed without problems, IMO.

Here is a patch that removes the offending PPC PCI hacky area from the
driver (sym53c8xx_defs.h):

--- sym53c8xx_defs.hFri Apr  6 16:23:48 2001
+++ sym53c8xx_defs.h.orig   Sun Mar  4 13:54:11 2001
@@ -175,6 +175,9 @@
 #defineSCSI_NCR_IOMAPPED
 #elif defined(__alpha__)
 #defineSCSI_NCR_IOMAPPED
+#elif defined(__powerpc__)
+#defineSCSI_NCR_IOMAPPED
+#define SCSI_NCR_PCI_MEM_NOT_SUPPORTED
 #elif defined(__sparc__)
 #undef SCSI_NCR_IOMAPPED
 #endif
 Cut Here --

Regards,
  Gérard.

-
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: ethernet phy link state info

[Jeff Garzik]

Johan Adolfsson wrote:
> I don't have an answer but a related question:
> Is there any "standard ioctl" to force an interface
> to a certain link state, eg. auto, 10Mbs, 100Mbps,
> half/full duplex etc.?

/sbin/mii-tool should do this on most network cards.

-- 
Jeff Garzik   | Sam: "Mind if I drive?"
Building 1024 | Max: "Not if you don't mind me clawing at the dash
MandrakeSoft  |   and shrieking like a cheerleader."
-
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: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

[Maciej W. Rozycki]

On 5 Apr 2001, Eric W. Biederman wrote:

> The point is on the Alpha all ram is always cached, and i/o space is
> completely uncached.  You cannot do write-combing for video card

 You don't want to cache fb memory, do you?  All you want is write
combining and you achieve it with memory barriers.  You write to fb memory
space whatever you need to and write buffers actually deliver data to fb
memory whenever the bus is idle or they get filled up.  When you finally
decide you wrote all data and you want ensure it actually reaches the fb
memory before you perform an operation (say you send a command to fb's
support circuitry) you issue a write memory barrier.  Or a memory barrier,
if you want ensure the data reaches the fb memory ASAP.

 In other words, you have write-combining by default and request
write-through explicitly.

> memory.  Memory barriers are a separate issue.  On the alpha the
> natural way to implement it would be in the page table fill code.

 Please forgive me -- I can't see how this is related to write combining.

> Memory barriers are o.k. but the really don't help the case when what
> you want to do is read the latest value out of a pci register.  

 They do -- you issue an mb and you are sure all pending writes reached
the involved PCI hw. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--+
+e-mail: [EMAIL PROTECTED], PGP key available+

-
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: ethernet phy link state info

[Jeff Garzik]

Bernhard Bender wrote:
> where do I find information about the current link state of the ethernet PHY
> (e.g. 100mbit/s full duplex) ?
> Something like /proc/sys/net/* ?

/sbin/mii-tool

-- 
Jeff Garzik   | Sam: "Mind if I drive?"
Building 1024 | Max: "Not if you don't mind me clawing at the dash
MandrakeSoft  |   and shrieking like a cheerleader."
-
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/

[PATCH] 2.4.3-ac3 update Documentation/Changes URLs for e2fsprogs

[Steven Cole]

Greetings all,

It appears that the URLs listed in Documentation/Changes for e2fsprogs
are stale.  This patch, against 2.4.3-ac3, provides accurate URLs.

Steven

--- linux/Documentation/Changes.origFri Apr  6 11:13:10 2001
+++ linux/Documentation/Changes Fri Apr  6 11:15:00 2001
@@ -31,7 +31,7 @@
 Eine deutsche Version dieser Datei finden Sie unter
 .
 
-Last updated: January 11, 2001
+Last updated: April 6, 2001
 
 Chris Ricker ([EMAIL PROTECTED] or [EMAIL PROTECTED]).
 
@@ -311,8 +311,8 @@
 
 E2fsprogs
 -
-o  
-o  
+o  
+o  
 
 Reiserfsprogs
 -
-
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: 2 times faster rawio and several fixes (2.4.3aa3)

[Andrea Arcangeli]

On Fri, Apr 06, 2001 at 07:02:32PM +0200, Andi Kleen wrote:
> On Fri, Apr 06, 2001 at 07:07:01PM +0200, Andrea Arcangeli wrote:
> > However we can probably stay with the 512k atomic I/O otherwise the iobuf
> > structure will grow again of an order of 2. With 512k of atomic I/O the kiovec
> > structure is just 8756 in size (infact probably I should allocate some of the
> > structures dynamically instead of statics inside the kiobuf.. as it is now
> > with my patch it's not very reliable as it needs an allocation of order 2).
> 
> 8756bytes wastes most of an order 2 allocation. Wouldn't it make more sense to 
> round it up to 16k to use the four pages fully ?  (if the increased atomic

I prefer to get rid of the order 2 allocation to avoid having to deal with
fragmentation. The patch introduces arrays takes 1 page each (on x86 and alpha)
if the atomic IO is 512k so I can allocate them with a separate kmalloc.

OTOH on x86-64 we have PAGE_SIZE 4k and 8byte words so maybe I should use
vmalloc instead? Performance of vmalloc is not an issue because those
allocations doesn't happen anymore in any fast path, only worry in using
vmalloc are the additional global 3 tlb entries (but OTOH also with kmalloc
there's the chance the code will use a few more global tlb entries if the
memory returned for all the kiovec structures doesn't all fit in the same
2/4Mbytes naturally aligned area). so probably I will take the vmalloc way
that is more generic and it shouldn't hurt perormance (I will measure that
to be sure though).

Andrea
-
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: 2 times faster rawio and several fixes (2.4.3aa3)

[Andi Kleen]

On Fri, Apr 06, 2001 at 07:07:01PM +0200, Andrea Arcangeli wrote:
> However we can probably stay with the 512k atomic I/O otherwise the iobuf
> structure will grow again of an order of 2. With 512k of atomic I/O the kiovec
> structure is just 8756 in size (infact probably I should allocate some of the
> structures dynamically instead of statics inside the kiobuf.. as it is now
> with my patch it's not very reliable as it needs an allocation of order 2).

8756bytes wastes most of an order 2 allocation. Wouldn't it make more sense to 
round it up to 16k to use the four pages fully ?  (if the increased atomic
size doesn't have other bad effects -- i guess it's no problem anymore to 
lock down that much memory?) 

-Andi

-
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: memory allocation problems

[Wayne Whitney]

In mailing-lists.linux-kernel, you wrote:

>  Essentially, the problem can be summarized to be that on a machine
>  with ample ram (2G, 4G, etc), I am unable to malloc a gig if I ask 
>  for the memory in small ( <= 128k) chunks. 

Take a look at this message by Szabolcs Szakacsits:

http://marc.theaimsgroup.com/?l=linux-kernel&m=97898653909227&w=2

There are other messages that may be of interest to you in that
thread, although they are spread out in a large thread.

Briefly, malloc in glibc will use brk() for "small" chunks and mmap()
for "large" chunks.  On a usual i386 linux kernel, the 4GB address
space is set up so that brk() can get at most 870MB or so and mmap()
can get at most 2GB.  Newer glibc's allow you to tune the definition
of "small" via an environment variable.

Cheers,
Wayne
-
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: 2 times faster rawio and several fixes (2.4.3aa3)

[Andrea Arcangeli]

On Fri, Apr 06, 2001 at 06:34:40PM +0200, Andrea Arcangeli wrote:
> 2.4.3aa3 with rawio-1:
> 
> root@alpha:/home/andrea > time ./rawio-bench 
> Opening /dev/raw1
> Allocating 50MB of memory
> Reading from /dev/raw1
> Writing data to /dev/raw1
> 
> real0m5.208s
> user0m0.001s
> sys 0m1.162s
> root@alpha:/home/andrea > time ./rawio-bench 
> Opening /dev/raw1
> Allocating 50MB of memory
> Reading from /dev/raw1
> Writing data to /dev/raw1
> 
> real0m5.233s
> user0m0.002s
> sys 0m1.184s
> root@alpha:/home/andrea > time ./rawio-bench 
> Opening /dev/raw1
> Allocating 50MB of memory
> Reading from /dev/raw1
> Writing data to /dev/raw1
> 
> real0m5.378s
> user0m0.002s
> sys 0m1.213s
> root@alpha:/home/andrea > time ./rawio-bench 
> Opening /dev/raw1
> Allocating 50MB of memory
> Reading from /dev/raw1
> Writing data to /dev/raw1
> 
> real0m5.258s
> user0m0.001s
> sys 0m1.183s
> root@alpha:/home/andrea > 

with this patch:

--- 2.4.3aa/include/linux/iobuf.h   Fri Apr  6 16:33:12 2001
+++ /misc/andrea-alpha/2.4.3aa/include/linux/iobuf.hFri Apr  6 18:31:23 2001
@@ -24,7 +24,7 @@
  * entire iovec.
  */
 
-#define KIO_MAX_ATOMIC_IO  512 /* in kb */
+#define KIO_MAX_ATOMIC_IO  1024 /* in kb */
 #define KIO_STATIC_PAGES   (KIO_MAX_ATOMIC_IO / (PAGE_SIZE >> 10) + 1)
 #define KIO_MAX_SECTORS(KIO_MAX_ATOMIC_IO * 2)
 

applied on top of 2.4.3aa3 I get even better results:

alpha:/home/andrea # time ./rawio-bench 
Opening /dev/raw1
Allocating 50MB of memory
Reading from /dev/raw1
Writing data to /dev/raw1

real0m4.898s
user0m0.003s
sys 0m1.138s
alpha:/home/andrea # time ./rawio-bench 
Opening /dev/raw1
Allocating 50MB of memory
Reading from /dev/raw1
Writing data to /dev/raw1

real0m4.935s
user0m0.002s
sys 0m1.159s
alpha:/home/andrea # time ./rawio-bench 
Opening /dev/raw1
Allocating 50MB of memory
Reading from /dev/raw1
Writing data to /dev/raw1

real0m4.925s
user0m0.003s
sys 0m1.162s
alpha:/home/andrea # time ./rawio-bench 
Opening /dev/raw1
Allocating 50MB of memory
Reading from /dev/raw1
Writing data to /dev/raw1

real0m4.941s
user0m0.004s
sys 0m1.166s
alpha:/home/andrea # 

this is most probably beacuse I'm striping on two scsi disks and this way we can send
512k requests to each disk.

NOTE: also userspace reads and writes have to be >=512kbytes in granularity or
you'll generate small requests because rawio in always synchronous. And using
decent sized write/reads is good idea anyways to reduce the enter/exit kernel
overhead.

However we can probably stay with the 512k atomic I/O otherwise the iobuf
structure will grow again of an order of 2. With 512k of atomic I/O the kiovec
structure is just 8756 in size (infact probably I should allocate some of the
structures dynamically instead of statics inside the kiobuf.. as it is now
with my patch it's not very reliable as it needs an allocation of order 2).

BTW, some more description on the testcase: it first read 50mbytes physically
contigous and then it lseek to zero and writes 50mbytes. Disk throughput in
mean is 100mbyte/5sec = 20mbyte/sec.

It uses anonymous memory as in-core backend. It looks perfect testcase to me
and they're the faster disks I have here around.

Here the proggy:

/* 2001 Andrea Arcangeli <[EMAIL PROTECTED]> */

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

#define MB (1024*1024)
#define BUFSIZE (50*MB)

main()
{
int fd, size, ret;
int filemap;
char * buf, * end, * tmp;

printf("Opening /dev/raw1\n");
fd = open("/dev/raw1", O_RDWR);
if (fd < 0)
perror("open /dev/raw1"), exit(1);

#if 1
printf("Allocating %dMB of memory\n", BUFSIZE/MB);
buf = (char *) malloc(BUFSIZE);
if (buf < 0)
perror("malloc"), exit(1);
end = (char *) ((unsigned long) (buf + BUFSIZE) & PAGE_MASK);
buf = (char *) ((unsigned long)(buf + ~PAGE_MASK) & PAGE_MASK);
#else
printf("Mapping %dMB of memory\n", BUFSIZE/MB);
filemap = open("deleteme", O_RDWR|O_TRUNC|O_CREAT, 0644);
if (filemap < 0)
perror("open"), exit(1);
{
int i;
char buf[4096];
for (i = 0; i < BUFSIZE; i += 4096)
write(filemap, &buf, 4096);
}
ftruncate(filemap, BUFSIZE);
buf = mmap(0, BUFSIZE, PROT_READ|PROT_WRITE, MAP_SHARED, filemap, 0);
if ((long) buf < 0)
perror("mmap"), exit(1);
if ((unsigned long) buf & ~PAGE_MASK)
perror("mmap misaligned"), exit(1);
end = buf + BUFSIZE;
#endif
size = end - buf;

printf("Reading from /dev/raw1\n");
ret = read(fd, buf, size);
if (ret < 0)
perror("read /dev/raw1"), exit(1);
if (ret != size)
fprintf(stderr, "read only %d of %d bytes\n", 

Re: gcc oopses with 2.4.3

[Richard B. Johnson]

On Fri, 6 Apr 2001, Norbert Preining wrote:

> On Fre, 06 Apr 2001, Chris Mason wrote:
> > sigbus from gcc usually points to the ram, have you run a tester?
> 
> But sig 4 is sigill (whatever this may be) and 1ig11 sigsegv, so
> no sigbus!?
> 
> BTW: The last lines of a kernel compile:
> 
> gcc -D__KERNEL__ -I/usr/src/linux-2.4.3-ac3/include -Wall -Wstrict-prototypes -O2 
>-fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 
>-march=k6-c -o tcp_output.o tcp_output.c
> gcc: Internal compiler error: program cc1 got fatal signal 11
> make[3]: *** [tcp_output.o] Error 1
> make[3]: Leaving directory `/usr/src/linux-2.4.3-ac3/net/ipv4'
> make[2]: *** [first_rule] Error 2
> make[2]: Leaving directory `/usr/src/linux-2.4.3-ac3/net/ipv4'
> make[1]: *** [_subdir_ipv4] Error 2
> make[1]: Leaving directory `/usr/src/linux-2.4.3-ac3/net'
> make: *** [_dir_net] Error 2
> 
> Best wishes
> 
> Norbert

SIGSEGV, still looks like a bad RAM simptom. Think linked-list, bad
pointer.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


-
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: gcc oopses with 2.4.3

[Norbert Preining]

On Fre, 06 Apr 2001, Chris Mason wrote:
> sigbus from gcc usually points to the ram, have you run a tester?

But sig 4 is sigill (whatever this may be) and 1ig11 sigsegv, so
no sigbus!?

BTW: The last lines of a kernel compile:

gcc -D__KERNEL__ -I/usr/src/linux-2.4.3-ac3/include -Wall -Wstrict-prototypes -O2 
-fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=k6 
   -c -o tcp_output.o tcp_output.c
gcc: Internal compiler error: program cc1 got fatal signal 11
make[3]: *** [tcp_output.o] Error 1
make[3]: Leaving directory `/usr/src/linux-2.4.3-ac3/net/ipv4'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux-2.4.3-ac3/net/ipv4'
make[1]: *** [_subdir_ipv4] Error 2
make[1]: Leaving directory `/usr/src/linux-2.4.3-ac3/net'
make: *** [_dir_net] Error 2

Best wishes

Norbert


-- 
ciao
norb

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

NLS: koi8-u support

[Volodymyr M . Lisivka]

Please add support of KOI-8 Ukrainian (AKA koi8-u) encoding into kernel,
because
ukrainian users can't read files with ukrainian names from NTFS and SMB
disks without it.

Patch for 2.4.x kernels (2.4.0-test10 - 2.4.3):
==cut from here
diff -urN linux-vanilla/Documentation/Configure.help
linux/Documentation/Configure.help
--- linux-vanilla/Documentation/Configure.help  Thu Jan  4 23:00:55
2001
+++ linux/Documentation/Configure.help  Thu Jan 11 14:43:12 2001
@@ -11762,7 +11762,7 @@
   cp862, cp863, cp864, cp865, cp866, cp869, cp874, cp932, cp936,
   cp949, cp950, euc-jp, euc-kr, gb2312, iso8859-1, iso8859-2, iso8859-3,
   iso8859-4, iso8859-5, iso8859-6, iso8859-7, iso8859-8, iso8859-9,
-  iso8859-14, iso8859-15, koi8-r, sjis
+  iso8859-14, iso8859-15, koi8-r, koi8-u, sjis
   If you specify a wrong value, it will use the built-in NLS; compatible
   with iso8859-1.
 
@@ -12034,7 +12034,7 @@
   input/output character sets. Say Y here for ISO8859-5, a Cyrillic
   character set with which you can type Bulgarian, Byelorussian,
   Macedonian, Russian, Serbian, and Ukrainian. Note that the charset
-  KOI8-R is preferred in Russia.
+  KOI8-R is preferred in Russia and KOI8-U is preferred in Ukraine.
 
 nls iso8859-6
 CONFIG_NLS_ISO8859_6
@@ -12110,6 +12110,14 @@
   from the Microsoft FAT file system family or from JOLIET CDROMs
   correctly on the screen, you need to include the appropriate
   input/output character sets. Say Y here for the preferred Russian
+  character set.
+
+nls koi8-u
+CONFIG_NLS_KOI8_U
+  If you want to display filenames with native language characters
+  from the Microsoft FAT file system family or from JOLIET CDROMs
+  correctly on the screen, you need to include the appropriate
+  input/output character sets. Say Y here for the preferred Ukrainian
   character set.
 
 Virtual terminal
diff -urN linux-vanilla/arch/alpha/defconfig linux/arch/alpha/defconfig
--- linux-vanilla/arch/alpha/defconfig  Tue Oct 17 01:38:41 2000
+++ linux/arch/alpha/defconfig  Thu Jan 11 14:49:02 2001
@@ -604,6 +604,7 @@
 # CONFIG_NLS_ISO8859_14 is not set
 # CONFIG_NLS_ISO8859_15 is not set
 # CONFIG_NLS_KOI8_R is not set
+# CONFIG_NLS_KOI8_U is not set
 # CONFIG_NLS_UTF8 is not set
 
 #
diff -urN linux-vanilla/arch/arm/def-configs/a5k
linux/arch/arm/def-configs/a5k
--- linux-vanilla/arch/arm/def-configs/a5k  Tue Nov 28 03:07:59 2000
+++ linux/arch/arm/def-configs/a5k  Thu Jan 11 14:46:44 2001
@@ -484,6 +484,7 @@
 # CONFIG_NLS_ISO8859_14 is not set
 # CONFIG_NLS_ISO8859_15 is not set
 # CONFIG_NLS_KOI8_R is not set
+# CONFIG_NLS_KOI8_U is not set
 # CONFIG_NLS_UTF8 is not set
 
 #
diff -urN linux-vanilla/arch/arm/def-configs/assabet
linux/arch/arm/def-configs/assabet
--- linux-vanilla/arch/arm/def-configs/assabet  Tue Nov 28 03:07:59
2000
+++ linux/arch/arm/def-configs/assabet  Thu Jan 11 14:47:31 2001
@@ -502,6 +502,7 @@
 # CONFIG_NLS_ISO8859_14 is not set
 # CONFIG_NLS_ISO8859_15 is not set
 # CONFIG_NLS_KOI8_R is not set
+# CONFIG_NLS_KOI8_U is not set
 # CONFIG_NLS_UTF8 is not set
 
 #
diff -urN linux-vanilla/arch/arm/def-configs/footbridge
linux/arch/arm/def-configs/footbridge
--- linux-vanilla/arch/arm/def-configs/footbridge   Tue Nov 28
03:07:59 2000
+++ linux/arch/arm/def-configs/footbridge   Thu Jan 11 14:46:51 2001
@@ -727,6 +727,7 @@
 # CONFIG_NLS_ISO8859_14 is not set
 CONFIG_NLS_ISO8859_15=m
 # CONFIG_NLS_KOI8_R is not set
+# CONFIG_NLS_KOI8_U is not set
 # CONFIG_NLS_UTF8 is not set
 
 #
diff -urN linux-vanilla/arch/arm/def-configs/graphicsclient
linux/arch/arm/def-configs/graphicsclient
--- linux-vanilla/arch/arm/def-configs/graphicsclient   Tue Nov 28
03:07:59 2000
+++ linux/arch/arm/def-configs/graphicsclient   Thu Jan 11 14:47:38
2001
@@ -494,6 +494,7 @@
 # CONFIG_NLS_ISO8859_14 is not set
 # CONFIG_NLS_ISO8859_15 is not set
 # CONFIG_NLS_KOI8_R is not set
+# CONFIG_NLS_KOI8_U is not set
 # CONFIG_NLS_UTF8 is not set
 
 #
diff -urN linux-vanilla/arch/arm/def-configs/neponset
linux/arch/arm/def-configs/neponset
--- linux-vanilla/arch/arm/def-configs/neponset Tue Nov 28 03:07:59
2000
+++ linux/arch/arm/def-configs/neponset Thu Jan 11 14:47:51 2001
@@ -510,6 +510,7 @@
 # CONFIG_NLS_ISO8859_14 is not set
 # CONFIG_NLS_ISO8859_15 is not set
 # CONFIG_NLS_KOI8_R is not set
+# CONFIG_NLS_KOI8_U is not set
 # CONFIG_NLS_UTF8 is not set
 
 #
diff -urN linux-vanilla/arch/arm/def-configs/rpc
linux/arch/arm/def-configs/rpc
--- linux-vanilla/arch/arm/def-configs/rpc  Tue Nov 28 03:07:59 2000
+++ linux/arch/arm/def-configs/rpc  Thu Jan 11 14:47:14 2001
@@ -600,6 +600,7 @@
 # CONFIG_NLS_ISO8859_14 is not set
 # CONFIG_NLS_ISO8859_15 is not set
 CONFIG_NLS_KOI8_R=m
+CONFIG_NLS_KOI8_U=m
 # CONFIG_NLS_UTF8 is not set
 
 #
diff -urN linux-vanilla/arch/arm/def-configs/shark
linux/arch/arm/def-configs/shark
--- linux-vanilla/arch/arm/def-configs/sharkTue Sep 19 01:15:24
2000
+++ linux/arch/arm/def-configs/sharkThu Jan 11 14:47:45 2001
@@ -559,6 +559,7 @@
 # CONF

Re: Proper way to release binary driver?

[J . A . Magallon]

On 04.06 Christopher Turcksin wrote:
> 
> In practice, that doesn't work. A driver compiled with 2.2.16 doesn't
> load with 2.2.16-5.0 (from RedHat 6.2) (just an example). 
> 

Thats is probably because RH 2.2.16-5.0 is not 2.2.16, but 2.2.17-pre-something.
Due to the bad idea of distros to name kernels in its own way, you can
never know which kernel are they giving if you do not read the changelog
from rpm.

For example, in Mandrake you get:

werewolf:~/in# rpm -q --changelog kernel-smp | more
* Thu Apr 05 2001 Chmouel Boudjnah <[EMAIL PROTECTED]> 2.4.3-8mdk

- btt upgrade to 0.7.62.

* Thu Apr 05 2001 Chmouel Boudjnah <[EMAIL PROTECTED]> 2.4.3-7mdk

- 2.4.3-ac3.
- Fix wait on psaux port (prumph).

So my naming scheme would be:
2.4.3-7mdk -> 2.4.3-ac3-1mdk
2.4.3-8mdk -> 2.4.3-ac3-2mdk.

An  or  release can have changed some important things from its
stable parent, and should be evident which version is a kernel from its
rpm name...

I do not think that the other patches distros apply change important things,
but correct bugs. So really you should only track the -preX and -acX releases
from Linus and Alan.

-- 
J.A. Magallon  #  Let the source
mailto:[EMAIL PROTECTED]  #  be with you, Luke... 

Linux werewolf 2.4.3-ac3 #1 SMP Thu Apr 5 00:28:45 CEST 2001 i686

-
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: gcc oopses with 2.4.3

[Norbert Preining]

On Fre, 06 Apr 2001, Chris Mason wrote:
> Neat, looks like you've installed the all new extreiser2fs.  Really though,
> do you have ext2 on the box at all?

Sounds great, yeah. No I have
/tmpext2
/boot   ext2
restreiserfs

> sigbus from gcc usually points to the ram, have you run a tester?

memtest2.5 for about 2 hours running, no error, 550MHz CPU, 128Mb RAM.

Best wishes

Norbert

-- 
ciao
norb

+---+
| Norbert Preining  http://www.logic.at/people/preining |
| University of Technology Vienna, Austria[EMAIL PROTECTED] |
| DSA: 0x09C5B094 (RSA: 0xCF1FA165) mail subject: get [DSA|RSA]-key |
+---+
-
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 times faster rawio and several fixes (2.4.3aa3)

[Andrea Arcangeli]

I merged some of SCT's fixes plus I fixed another couple of bugs and then I
boosted the code to run faster. There's still room for improvements for example
by using a ring of iobuf to walk pagetables and lock down pages for the next
atomic I/O chunk while the I/O of the previous iobuf is in progress (before
waiting synchronously) but with those first basic improvements it just runs
exactly 2 times faster than vanilla 2.4.3 on my hardware.  NOTE: since I made
the atomic I/O 512k to go in sync with the max size of a io-request and to take
advantage of the large I/O requests the MAX_KIO_SECTORS grown so much that it
cannot be loaded on the stack anymore (it was just a bad idea anyways to load
it on the stack anyways) so for things like the buffer array I preallocate an
helper buffer in the kiovec structure for that.

This should very significantly boost Oracle when the working set doesn't fit in
cache because the rawio path should be quite efficient now (comparable to
regular I/O through the cache).

2.4.3aa3 without rawio-1:

alpha:/home/andrea # time ./rawio-bench
Opening /dev/raw1
Allocating 50MB of memory
Reading from /dev/raw1
Writing data to /dev/raw1

real0m10.323s
user0m0.002s
sys 0m1.248s
alpha:/home/andrea # time ./rawio-bench
Opening /dev/raw1
Allocating 50MB of memory
Reading from /dev/raw1
Writing data to /dev/raw1

real0m10.299s
user0m0.002s
sys 0m1.247s
alpha:/home/andrea # time ./rawio-bench
Opening /dev/raw1
Allocating 50MB of memory
Reading from /dev/raw1
Writing data to /dev/raw1

real0m10.557s
user0m0.004s
sys 0m1.267s
alpha:/home/andrea # time ./rawio-bench
Opening /dev/raw1
Allocating 50MB of memory
Reading from /dev/raw1
Writing data to /dev/raw1

real0m10.310s
user0m0.003s
sys 0m1.282s
alpha:/home/andrea # 

2.4.3aa3 with rawio-1:

root@alpha:/home/andrea > time ./rawio-bench 
Opening /dev/raw1
Allocating 50MB of memory
Reading from /dev/raw1
Writing data to /dev/raw1

real0m5.208s
user0m0.001s
sys 0m1.162s
root@alpha:/home/andrea > time ./rawio-bench 
Opening /dev/raw1
Allocating 50MB of memory
Reading from /dev/raw1
Writing data to /dev/raw1

real0m5.233s
user0m0.002s
sys 0m1.184s
root@alpha:/home/andrea > time ./rawio-bench 
Opening /dev/raw1
Allocating 50MB of memory
Reading from /dev/raw1
Writing data to /dev/raw1

real0m5.378s
user0m0.002s
sys 0m1.213s
root@alpha:/home/andrea > time ./rawio-bench 
Opening /dev/raw1
Allocating 50MB of memory
Reading from /dev/raw1
Writing data to /dev/raw1

real0m5.258s
user0m0.001s
sys 0m1.183s
root@alpha:/home/andrea > 

Original patch is here:


ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.3aa3/20_rawio-1

however to apply cleanly to lvm you need to first apply the lvm patches into
the 2.4.3aa3 directory to upgrade to 0.9.1 beta6 (btw, I appreciated very much
the sistina folks that gone back to IPO 10 as suggested a few weeks ago,
thanks! :)

I also ported the patch to vanilla 2.4.3 for inclusion (however that version is
untested but the only rejects was in lvm-snap.c and they were obvious enough not
to require testing) but lvm people please look at the other patch that will
just apply cleanly to your CVS tree:


ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.3/rawio-1

Andrea
-
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: Proper way to release binary driver?

[Joel Jaeggli]

Hi,

I'd take a look at how nvidia delivers the module for their video
cards...

http://www.nvidia.com/Products/Drivers.nsf/Linux.html

you build the module with your current kernel or download the one for your
distribution (limited number)

4-front tenchnologies has also done a long-term good job on this with oss

joelja

On Fri, 6 Apr 2001, Christopher Turcksin wrote:

> "Eric W. Biederman" wrote:
>
> > If what you are after is a way to release a driver that is not a
> > hassle to add to an already working system, you will find a more
> > receptive ear.  I have heard some talk, that it would be a good idea
> > to figure out how to standardize how to compile a kernel driver
> > outside the kernel tree, so it could be trivial enough that anyone
> > could do it.  To date there are enough people around who don't have
> > problems compiling their own kernel that this hasn't become a major
> > issue.
>
> Eric,
>
> I am finding myself exactly in this situation, and I've got a feeling
> that this won't be the last time either.
>
> I expect that every future Linux driver I get involved with will be
> released under GPL. However, I think that the majority of our customers
> will be running a distribution that does not yet support a new driver,
> and even at Linux speeds, it'll take a long enough time that customers
> cannot afford to wait for the next release that includes the driver.
>
> So the big issue for us appears to be how we support these customers.
>
> There is no way that we can support customers who have custom kernels,
> but since they are 'in it' enough to compile their own kernel, I guess
> they're able to apply our patch and recompile it. I actually suspect
> that there aren't that many who do this anyway.
>
> Where we find we have a problem is the number of different 'standard'
> kernels out there. We find that we need to support all releases since
> the last year or so for each distribution. And for each of those, we
> find that there are many different kernel versions (some bugfixes, some
> provide half a dozen different kernels with the CDs, aso.). And since we
> do not expect these customers to compile their own kernel, we see no
> option but to provide a precompiled binary driver. The numbers multiply
> quickly and building all of those becomes an interesting problem.
>
> We had hoped that MODVERSIONS would allow us to provide a single (or at
> most a few) binary driver. Kernels with even minor version numbers are
> supposed to be stable (even if they are buggy) ie. not have wildly
> changing kernel interfaces.
>
> In practice, that doesn't work. A driver compiled with 2.2.16 doesn't
> load with 2.2.16-5.0 (from RedHat 6.2) (just an example).
>
>
>
>

-- 
--
Joel Jaeggli   [EMAIL PROTECTED]
Academic User Services   [EMAIL PROTECTED]
 PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E
--
It is clear that the arm of criticism cannot replace the criticism of
arms.  Karl Marx -- Introduction to the critique of Hegel's Philosophy of
the right, 1843.


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

[QUESTION]: Support and scalability on SMP Alpha

[Bart Trojanowski]

I am working on a project which will require a lot of CPU power.  I will
be running TCP, a managable number of busy threads, and gigabit ether.

I was curious how good the alpha processor support is in Linux as
compared to, say, i386.  Also How well do alpha processors scale up on
Linux 2.4 in a veriety of different n-way alpha boxes.

TIA,
Bart.

-- 
WebSig: http://www.jukie.net/~bart/sig/


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

linux 2.2.19 smp interrupt problems?

[Armin Obersteiner]

hi!

i get a lot of messages of this kind:

Apr  6 17:44:33 home kernel: eth0: RTL8139 Interrupt line blocked, status 4.
Apr  6 17:44:33 home kernel: eth0: SMP simultaneous entry of an interrupt handler.

linux 2.2.19
dual pentium 166
rtl8139
high network load (encrypted x applications over network)

with a low load i don't get the messages.

everything seems to work fine. are these interrupt problems "bad" or merely
indicators of a high load. can/should one get rid of them?

MfG,
Armin Obersteiner
--
[EMAIL PROTECTED]pgp public key on requestCU
-
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: gcc oopses with 2.4.3

[Chris Mason]

On Friday, April 06, 2001 05:44:42 PM +0200 Norbert Preining
<[EMAIL PROTECTED]> wrote:

> Hi!
> 
> I get frequent `internal compiler error', killed with Sig 4  or Sig 11
> and sometimes Ooops from compiling X or kernel. 
> 
> System: 2.4.3-vanilla, reiserfs, glibc-2.1.3
> [~] gcc -v
> Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs
> gcc version 2.95.2 19991024 (release)
> 
> 
> Here a decoded Ooops:
> 
> ksymoops 0.7c on i586 2.4.3.  Options used
>  -V (default)
>  -k /proc/ksyms (default)
>  -l /proc/modules (default)
>  -o /lib/modules/2.4.3/ (default)
>  -m /boot/System.map-2.4.3 (specified)
> 
> Unable to handle kernel NULL pointer dereference at virtual address
>  c0145e41
> *pde = 
> Oops: 
> CPU:0
> EIP:0010:[ext2_new_block+317/1808]
> EFLAGS: 00010282
> eax:    ebx: c7261de8   ecx:    edx: 
> esi: c6dab000   edi:    ebp: c7261dec   esp: c7261d9c
> ds: 0018   es: 0018   ss: 0018
> Process cc1 (pid: 20767, stackpage=c7261000)
> Stack: c2f280e0 0001 c7261e3c 0001 c01675d0  
> c6dab038  c6dab034 c7261e7c c7261e94 c020e91c 0001 0009 0008
>c7cc7c00  c1265800  c473c9e0 c1264120 c7261e40 c014755c
>c2f280e0 0001  Call Trace: [search_by_key+2028/3140]
> [ext2_alloc_block+120/128] [ext2_alloc_branch+41/456]
> [ext2_get_block+695/1152] [create_empty_buffers+23/108]
> [__block_prepare_write+234/560] [block_prepare_write+29/52]  Code: 74 04
> 31 d2 eb 52 83 be c8 00 00 00 08 77 20 8d 04 bd 00 00  Using defaults
> from ksymoops -t elf32-i386 -a i386

Neat, looks like you've installed the all new extreiser2fs.  Really though,
do you have ext2 on the box at all?

sigbus from gcc usually points to the ram, have you run a tester?

-chris

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

Proper way to release binary driver?

[Christopher Turcksin]

"Eric W. Biederman" wrote:

> If what you are after is a way to release a driver that is not a
> hassle to add to an already working system, you will find a more
> receptive ear.  I have heard some talk, that it would be a good idea
> to figure out how to standardize how to compile a kernel driver
> outside the kernel tree, so it could be trivial enough that anyone
> could do it.  To date there are enough people around who don't have
> problems compiling their own kernel that this hasn't become a major
> issue.

Eric,

I am finding myself exactly in this situation, and I've got a feeling
that this won't be the last time either.

I expect that every future Linux driver I get involved with will be
released under GPL. However, I think that the majority of our customers
will be running a distribution that does not yet support a new driver,
and even at Linux speeds, it'll take a long enough time that customers
cannot afford to wait for the next release that includes the driver.

So the big issue for us appears to be how we support these customers.

There is no way that we can support customers who have custom kernels,
but since they are 'in it' enough to compile their own kernel, I guess
they're able to apply our patch and recompile it. I actually suspect
that there aren't that many who do this anyway.

Where we find we have a problem is the number of different 'standard'
kernels out there. We find that we need to support all releases since
the last year or so for each distribution. And for each of those, we
find that there are many different kernel versions (some bugfixes, some
provide half a dozen different kernels with the CDs, aso.). And since we
do not expect these customers to compile their own kernel, we see no
option but to provide a precompiled binary driver. The numbers multiply
quickly and building all of those becomes an interesting problem.

We had hoped that MODVERSIONS would allow us to provide a single (or at
most a few) binary driver. Kernels with even minor version numbers are
supposed to be stable (even if they are buggy) ie. not have wildly
changing kernel interfaces.

In practice, that doesn't work. A driver compiled with 2.2.16 doesn't
load with 2.2.16-5.0 (from RedHat 6.2) (just an example). 



-- 
bfn,
wabbit

IBM Global Services, UK AMS in Greenock, Scotland.

" To err is human, but to really foul things up requires the root
password. "
-
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: [PATCH] Re: Race in fs/proc/generic.c:make_inode_number()

[Tom Leete]

Maneesh Soni wrote:
> 
> Just a couple of points:
> 
> On Thu, Apr 05, 2001 at 10:36:10AM -0400, Tom Leete wrote:
> [...]
> > +spinlock_t proc_alloc_map_lock = RW_LOCK_UNLOCKED;
> > +
> Why not make this static?
> Initializer should be SPIN_LOCK_UNLOCKED.
> 

Thanks, you're right on both counts.

Linus, Alan, this version is more correct. I also checked for other uses of
proc_alloc_map[], The only case is in deallocation, and it looks ok to me.

Tom

-- 
The Daemons lurk and are dumb. -- Emerson

diff -u linux-2.4.3/fs/proc/generic.c.orig linux-2.4.3/fs/proc/generic.c
--- linux-2.4.3/fs/proc/generic.c.orig  Thu Apr  5 10:03:02 2001
+++ linux-2.4.3/fs/proc/generic.c   Thu Apr  5 10:22:48 2001
@@ -192,13 +192,22 @@
 
 static unsigned char proc_alloc_map[PROC_NDYNAMIC / 8];
 
+spinlock_t proc_alloc_map_lock = RW_LOCK_UNLOCKED;
+
 static int make_inode_number(void)
 {
-   int i = find_first_zero_bit((void *) proc_alloc_map, PROC_NDYNAMIC);
-   if (i<0 || i>=PROC_NDYNAMIC) 
-   return -1;
+   int i;
+   spin_lock(&proc_alloc_map_lock);
+   i = find_first_zero_bit((void *) proc_alloc_map, PROC_NDYNAMIC);
+   if (i<0 || i>=PROC_NDYNAMIC) {
+   i = -1;
+   goto out;
+   }
set_bit(i, (void *) proc_alloc_map);
-   return PROC_DYNAMIC_FIRST + i;
+   i += PROC_DYNAMIC_FIRST;
+out:
+   spin_unlock(&proc_alloc_map_lock);
+   return i;
 }
 
 static int proc_readlink(struct dentry *dentry, char *buffer, int buflen)
-
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: console.c unblank_screen problem

[Mikael Pettersson]

On Wed, 4 Apr 2001 13:09:11 +0200 (MET DST), Mikael Petterson wrote:

> On Sun, 25 Mar 2001 18:40:03 +0200, Benjamin Herrenschmidt wrote:
> 
> >There is a problem with the power management code for console.c
> >
> >The current code calls do_blank_screen(0); on PM_SUSPEND, and
> >unblank_screen() on PM_RESUME.
> >
> >The problem happens when X is the current display while putting the
> >machine to sleep. The do_blank_screen(0) code will do nothing as
> >the console is not in KD_TEXT mode.
> >However, unblank_screen has no such protection. That means that
> >on wakeup, the cursor timer & console blank timers will be re-enabled
> >while X is frontmost, causing the blinking cursor to be displayed on
> >top of X, and other possible issues.
> >
> >I hacked the following pacth to work around this. It appear to work
> >fine, but since the console code is pretty complex, I'm not sure about
> >possible side effects and I'd like some comments before submiting it
> >to Linus:
>...
> Before the patch: After a few days with a 2.4 kernel and RH7.0
> (XFree86-4.0.1-1 and XFree86-SVGA-3.3.6-33) the latop would
> misbehave at a resume event: when I opened the lid the screen would
> unblank and then after less than a second the entire screen would
> shift (wrap/rotate) left by about 40% of its width.
>...
> With the patch: No problem after 10 days with frequent suspend/resume
> cycles. (2.4.2-ac24 + the patch)

Correction: While the patch eliminated the X screen wrap problem at resume,
it caused a new problem: now when I exit X the console is left in a blanked
state. This seems to happen if at least one suspend/resume cycle has
occurred before X is terminated.

After some experimentation I came up with the patch below (vs. 2.4.3-ac3)
which _so_far_ behaves ok on my laptop. If the resume-while-in-X problems
resurface or not I won't know until after several more days of testing,
but at least the console is unblanked correctly again.

Does _anyone_ understand this code and its interactions with X? I'm lost...

/Mikael

--- linux-2.4.3-ac3/drivers/char/console.c.~1~  Thu Apr  5 15:57:36 2001
+++ linux-2.4.3-ac3/drivers/char/console.c  Thu Apr  5 18:52:43 2001
@@ -2713,23 +2713,23 @@
printk("unblank_screen: tty %d not allocated ??\n", fg_console+1);
return;
}
-   currcons = fg_console;
-   if (vcmode != KD_TEXT) {
-   console_blanked = 0;
-   return;
-   }
console_timer.function = blank_screen;
if (blankinterval) {
mod_timer(&console_timer, jiffies + blankinterval);
}
-
+   currcons = fg_console;
console_blanked = 0;
if (console_blank_hook)
console_blank_hook(0);
set_palette(currcons);
-   if (sw->con_blank(vc_cons[currcons].d, 0))
+   if (sw->con_blank(vc_cons[currcons].d, 0)) {
+   if (vcmode != KD_TEXT)
+   return;
/* Low-level driver cannot restore -> do it ourselves */
update_screen(fg_console);
+   }
+   if (vcmode != KD_TEXT)
+   return;
set_cursor(fg_console);
 }
 
-
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/

gcc oopses with 2.4.3

[Norbert Preining]

Hi!

I get frequent `internal compiler error', killed with Sig 4  or Sig 11
and sometimes Ooops from compiling X or kernel. 

System: 2.4.3-vanilla, reiserfs, glibc-2.1.3
[~] gcc -v
Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs
gcc version 2.95.2 19991024 (release)


Here a decoded Ooops:

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

Unable to handle kernel NULL pointer dereference at virtual address 
c0145e41
*pde = 
Oops: 
CPU:0
EIP:0010:[ext2_new_block+317/1808]
EFLAGS: 00010282
eax:    ebx: c7261de8   ecx:    edx: 
esi: c6dab000   edi:    ebp: c7261dec   esp: c7261d9c
ds: 0018   es: 0018   ss: 0018
Process cc1 (pid: 20767, stackpage=c7261000)
Stack: c2f280e0 0001 c7261e3c 0001 c01675d0   c6dab038 
   c6dab034 c7261e7c c7261e94 c020e91c 0001 0009 0008 c7cc7c00 
   c1265800  c473c9e0 c1264120 c7261e40 c014755c c2f280e0 0001 
Call Trace: [search_by_key+2028/3140] [ext2_alloc_block+120/128] 
[ext2_alloc_branch+41/456] [ext2_get_block+695/1152] [create_empty_buffers+23/108] 
[__block_prepare_write+234/560] [block_prepare_write+29/52] 
Code: 74 04 31 d2 eb 52 83 be c8 00 00 00 08 77 20 8d 04 bd 00 00 
Using defaults from ksymoops -t elf32-i386 -a i386

Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   74 04 je 6 <_EIP+0x6> 0006 Before first symbol
Code;  0002 Before first symbol
   2:   31 d2 xor%edx,%edx
Code;  0004 Before first symbol
   4:   eb 52 jmp58 <_EIP+0x58> 0058 Before first symbol
Code;  0006 Before first symbol
   6:   83 be c8 00 00 00 08  cmpl   $0x8,0xc8(%esi)
Code;  000d Before first symbol
   d:   77 20 ja 2f <_EIP+0x2f> 002f Before first symbol
Code;  000f Before first symbol
   f:   8d 04 bd 00 00 00 00  lea0x0(,%edi,4),%eax


I hope it helps a bit, but it doesn't look like ;-)

Please Cc: me any answers, thanks!

Best wishes

Norbert


-- 
ciao
norb

+---+
| Norbert Preining  http://www.logic.at/people/preining |
| University of Technology Vienna, Austria[EMAIL PROTECTED] |
| DSA: 0x09C5B094 (RSA: 0xCF1FA165) mail subject: get [DSA|RSA]-key |
+---+
-
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: memory allocation problems

[Andi Kleen]

On Fri, Apr 06, 2001 at 10:06:47AM -0400, [EMAIL PROTECTED] wrote:
>   Essentially, the problem can be summarized to be that on a machine
>   with ample ram (2G, 4G, etc), I am unable to malloc a gig if I ask 
>   for the memory in small ( <= 128k) chunks. I've enclosed some results 
>   and a little program which was put together to demonstrate the problems
>   we're having.  All of the failures seem to occur around 930MB.

It's bumping against some mapping (just do system("cat /proc/self/maps")
on allocation failure to see which). Usual suspects are shared libraries.
One possible solution is to upgrade to a newer glibc, the 2.2 glibc malloc 
should handle this case better.  
A way to get mappings like shared libraries out of the way is to 
increase the value of TASK_UNMAPPED_BASE in include/asm-i386/processor.h.
For that the kernel needs to be recompiled and it should be smaller
TASK_SIZE-enough space for your shared libraries. With that even the older
malloc will probably work.


-Andi
-
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: ethernet phy link state info

[Mathieu Chouquet-Stringer]

Try http://www.scyld.com/diag/

[EMAIL PROTECTED] ("Johan Adolfsson") writes:
> I don't have an answer but a related question:
> Is there any "standard ioctl" to force an interface
> to a certain link state, eg. auto, 10Mbs, 100Mbps,
> half/full duplex etc.?
> 
> If not, can we create a standard ioctl mechanism for it?
> 
> /Johan
> 
> - Original Message -
> From: Bernhard Bender <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, April 06, 2001 16:54
> Subject: ethernet phy link state info
> 
> 
> >
> >
> > Hi all,
> >
> > where do I find information about the current link state of the ethernet
> PHY
> > (e.g. 100mbit/s full duplex) ?
> > Something like /proc/sys/net/* ?
> >
> > Thanks
> > Bernhard
> >
> >
> > -
> > 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/
> 

-- 
Mathieu CHOUQUET-STRINGER  E-Mail : [EMAIL PROTECTED]
 Learning French is trivial: the word for horse is cheval, and
   everything else follows in the same way.
-- Alan J. Perlis
-
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: syslog insmod please!

[Mr. James W. Laferriere]

Hello Wichert ,
On Fri, 6 Apr 2001, Artur Frysiak wrote:
> On Fri, Apr 06, 2001 at 07:43:29AM -0700, Mr. James W. Laferriere wrote:
> > On 6 Apr 2001, Wichert Akkerman wrote:
> > > In article <[EMAIL PROTECTED]>,
> > > Mr. James W. Laferriere <[EMAIL PROTECTED]> wrote:
> > > > Not the problem being discussed ,  This is a user now root &
> > > > having gained root is now attempting to from the command line
> > > > to load a module .  How do we get this event recorded ?
> > > Recent versions of modutils (2.4.3 and later iirc) log that info
> > > in /var/log/ksymoops

> But r00tkit may have own version of insmod.
OK ,  There are no special features accorded to /var/log/ksymoops
than to any other file .  Unless otherwise configured .
Am I that mistaken ?  I hope not .  Tia ,  JimL

   ++
   | James   W.   Laferriere | System  Techniques | Give me VMS |
   | NetworkEngineer | 25416  22nd So |  Give me Linux  |
   | [EMAIL PROTECTED] | DesMoines WA 98198 |   only  on  AXP |
   ++

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

Seems to be a lot of confusion about aic7xxx in linux 2.4.3

[Jeffrey W. Baker]

I've been seeing a lot of complaints about aic7xxx in the 2.4.3 kernel.  I
think that people are missing the crucial point: aic7xxx won't compile if
you patch up from 2.4.2, but if you download the complete 2.4.3 tarball,
it compiles fine.

So, I conclude that the patch was created incorrectly, or that something
changed between cutting the patch and the tarball.

-jwb

-
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: ethernet phy link state info

[Johan Adolfsson]

I don't have an answer but a related question:
Is there any "standard ioctl" to force an interface
to a certain link state, eg. auto, 10Mbs, 100Mbps,
half/full duplex etc.?

If not, can we create a standard ioctl mechanism for it?

/Johan

- Original Message -
From: Bernhard Bender <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, April 06, 2001 16:54
Subject: ethernet phy link state info


>
>
> Hi all,
>
> where do I find information about the current link state of the ethernet
PHY
> (e.g. 100mbit/s full duplex) ?
> Something like /proc/sys/net/* ?
>
> Thanks
> Bernhard
>
>
> -
> 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: syslog insmod please!

[Artur Frysiak]

On Fri, Apr 06, 2001 at 07:43:29AM -0700, Mr. James W. Laferriere wrote:
> 
>   Hello Wichert ,
> 
> On 6 Apr 2001, Wichert Akkerman wrote:
> > In article <[EMAIL PROTECTED]>,
> > Mr. James W. Laferriere <[EMAIL PROTECTED]> wrote:
> > >   Not the problem being discussed ,  This is a user now root &
> > >   having gained root is now attempting to from the command line
> > >   to load a module .  How do we get this event recorded ?
> > Recent versions of modutils (2.4.3 and later iirc) log that info
> > in /var/log/ksymoops

But r00tkit may have own version of insmod.

Regards
-- 
Artur Frysiak
Click and Buy Sp. z o.o.
tel. (071) 327-95-00 wew. 67
tel. GSM (0606) 506-414
-
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/

ethernet phy link state info

[Bernhard Bender]

Hi all,

where do I find information about the current link state of the ethernet PHY
(e.g. 100mbit/s full duplex) ?
Something like /proc/sys/net/* ?

Thanks
Bernhard


-
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: syslog insmod please!

[Mr. James W. Laferriere]

Hello Wichert ,

On 6 Apr 2001, Wichert Akkerman wrote:
> In article <[EMAIL PROTECTED]>,
> Mr. James W. Laferriere <[EMAIL PROTECTED]> wrote:
> > Not the problem being discussed ,  This is a user now root &
> > having gained root is now attempting to from the command line
> > to load a module .  How do we get this event recorded ?
> Recent versions of modutils (2.4.3 and later iirc) log that info
> in /var/log/ksymoops
Thank you .  Does anyone know why this information is being put
into /var/log/ksymoops ?  If anything I'd have used a differant
filename .  Tia ,  JimL

   ++
   | James   W.   Laferriere | System  Techniques | Give me VMS |
   | NetworkEngineer | 25416  22nd So |  Give me Linux  |
   | [EMAIL PROTECTED] | DesMoines WA 98198 |   only  on  AXP |
   ++

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

memory allocation problems

[majer]

  Hi. Im hoping someone on here can help me out. I posted something
  similar to this back in June 2000 when I was on the 2.2.X line and
  was waiting to see if the 2.4 kernel would provide a fix.

  Essentially, the problem can be summarized to be that on a machine
  with ample ram (2G, 4G, etc), I am unable to malloc a gig if I ask 
  for the memory in small ( <= 128k) chunks. I've enclosed some results 
  and a little program which was put together to demonstrate the problems
  we're having.  All of the failures seem to occur around 930MB.

  I'm more than happy to try any tunings, patches, etc and my 
  time is at your disposal.

  Thanks,

  Karl


Karl Majer  [EMAIL PROTECTED] 
Sr Systems Architect617 577 7999 xt 251

 "Think for yourselves and let others enjoy the privilege to do so, too."
 --Voltaire


  The fields are: 
  Iteration, Addr of ptr, Addr stored by ptr, alloc'd mem

  size: 4096
  #228852 (401F07D8) (3FFFC948) allocated 937381888 bytes total.
  #228853 (401F07DC) (3FFFD950) allocated 937385984 bytes total.
  malloc error Cannot allocate memory
  
  size: 8192
  #114536 (40180DA8) (3FFF94E8) allocated 938287104 bytes total.
  #114537 (40180DAC) (3FFFB4F0) allocated 938295296 bytes total.
  malloc error Cannot allocate memory
   
  size: 16384
  #57294 (40148F40) (3FFF1818) allocated 938721280 bytes total.
  #57295 (40148F44) (3FFF5820) allocated 938737664 bytes total.
  malloc error Cannot allocate memory
  
  size: 32768
  #28653 (4012CFBC) (3FFE9910) allocated 938934272 bytes total.
  #28654 (4012CFC0) (3FFF1918) allocated 938967040 bytes total.
  malloc error Cannot allocate memory
  
  size: 65536
  #14325 (805797C) (3FFC5958) allocated 938868736 bytes total.
  #14326 (8057980) (3FFD5960) allocated 938934272 bytes total.
  #14327 (8057984) (3FFE5968) allocated 938999808 bytes total.
  malloc error Cannot allocate memory
  
  size: 131072
  #8186 (8051990) (3FF9F980) allocated 1073086464 bytes total.
  #8187 (8051994) (3FFBF988) allocated 1073217536 bytes total.
  malloc error Cannot allocate memory
  
  size: 262144
  #4094 (804D9A0) (37FD39A0) allocated 1073479680 bytes total.
  #4095 (804D9A4) (380139A8) allocated 1073741824 bytes total.
  success
   


#include
#include
#include
#include

unsigned int i,num,bites,total,delay=0;
char **memhog;

int main(int argc,char *argv[]){

  if(argc!=4){
fprintf(stderr,"usage: %s [# of chunks] [bytes per chunk] [delay in 
sec]\n",argv[0]);
return(1);
  } 

  num=atoi(argv[1]);
  bites=atoi(argv[2]);
  delay=atoi(argv[3]);

  memhog=malloc(sizeof(char*) * num); 
  if(!memhog){
fprintf(stderr,"malloc error %s\n",strerror(errno));  
exit(1);
  }

  for(i=0;i

Re: syslog insmod please!

[Wichert Akkerman]

In article <[EMAIL PROTECTED]>,
Mr. James W. Laferriere <[EMAIL PROTECTED]> wrote:
>   Not the problem being discussed ,  This is a user now root &
>   having gained root is now attempting to from the command line
>   to load a module .  How do we get this event recorded ?

Recent versions of modutils (2.4.3 and later iirc) log that info
in /var/log/ksymoops

Wichert.


-- 
   
 / Generally uninteresting signature - ignore at your convenience  \
| [EMAIL PROTECTED]  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

-
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: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

[Eric W. Biederman]

Ivan Kokshaysky <[EMAIL PROTECTED]> writes:

> On Thu, Apr 05, 2001 at 12:20:22PM -0600, Eric W. Biederman wrote:
> > The point is on the Alpha all ram is always cached, and i/o space is
> > completely uncached.  You cannot do write-combing for video card
> > memory.
> 
> Incorrect. Alphas have write buffers - 6x32 bytes on ev5 and
> 4x64 on ev6, IIRC. So alphas do write up to 32 or 64 bytes
> in a single pci transaction.

Sorry I was thinking the current alpha the ev6.  So what I'm saying
doesn't apply to the alpha architecture in general just it's current
specific implementation.   

Yes for the ev6 you have write buffers but can't say just use the
write buffers,  on an arbitrary area of memory. 
 
> >  Memory barriers are a separate issue.  On the alpha the
> > natural way to implement it would be in the page table fill code.
> > Memory barriers are o.k. but the really don't help the case when what
> > you want to do is read the latest value out of a pci register.  
> 
> You don't need memory barrier for that. "Write memory barriers" are
> used to ensure correct write order, and "memory barriers" are used
> to ensure that all pending reads/writes will complete before next read
> or write.

100% Agreed. That is what I was saying.  What the ev6 doesn't have
is the ability to say this: I am using this area of the memory address
space in a particular way: don't cache it but do write combing on it.

Theoretically you could use memory barrier instructions for this but
it would require an I/O bus that supported a cache coherency
protocol.  At which point the problem moves down to your PCI bus
controller.

I recall on the ev6 all memory accesses to locations with bit 40 set 
are always to IO space are never cached and are never write buffered.
Accesses to memory locations with bit 40 clear are always to RAM are
always cached and always write buffered. 

With the high I/O bus speeds unless you are trying to push things to
the absolute limit you are unlikely to see the IO accesses being the
bottleneck in or out to a PCI device.  At which point DMA probably
already compensates, for most devices.

IIRC For PCI card IO regions where you need maximum IO speed through
the memory address space (like frame buffers) the ev6 falls down.

I really like the alpha this is why this gals me so much about the
ev6.  I hope they have it fixed for the ev7 or ev8.  If those chips
ever actually arrive.  But as the ev7 is just supposed to be the ev6
core with an on chip cache I don't have much hope.

Eric
-
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: a quest for a better scheduler

[Hubertus Franke]

Torrey, nothing to worry about (or at least not yet).

The new scheduler only replaces the current SMP scheduler, not the single
cpu scheduler. So the devices that you refer to are not affected at
all by these changes.

The desire for interactivity etc, lead us to stick to the current
proposed MQ scheduler semantics, namely not to completely isolate the
runqueues from each other (e.g. the HP-MQ does so), but do some cross
checking to ensure that high priority tasks are run when they need to.

First you get the same (similar good or bad scheduler semantics as the
current one) but at a significantly lower cost for medium to high end
loads (defined as #runnable tasks > #cpus)

Here is a simple approximate arithmetic. Assume the following:
- Let X be the fixed overhead to get through the scheduler (cur or MQ)
once.
- Let Y the overhead of touching a task to inspect its goodness
- Let N be the number of tasks
- Let C be the number of cpus.

The cost for the current scheduler is: X(cur) + N*Y.
The cost for the MQ scheduler is: X(MQ)  + (N/C)*Y + C*Y
  I assumed here equal runqueue length.

You can see that this ballpark math shows that if X(cur) ~ X(MQ)
MQ is expected to be better when (N/C) + C < N   or
if (  N  >  C*C/(C-1)  )

C=2 N>4
C=3 N>4
C=4 N>5
C=5 N>6
C=6 N>7
C=7 N>8
C=8 N>9

Turns out that for C>2  this amounts to N > C+1 MQ will do better.
Now this is in the face of lack of runqueue lock contention. When
runqueue lock contention surfaces, then this will shift in favor of MQ.




Hubertus Franke
Enterprise Linux Group (Mgr),  Linux Technology Center (Member Scalability)
, OS-PIC (Chair)
email: [EMAIL PROTECTED]
(w) 914-945-2003(fax) 914-945-4425   TL: 862-2003



Torrey Hoffman <[EMAIL PROTECTED]>@vger.kernel.org on 04/05/2001
07:53:27 PM

Sent by:  [EMAIL PROTECTED]


To:   "'Timothy D. Witham'" <[EMAIL PROTECTED]>, Linux Kernel List
  <[EMAIL PROTECTED]>
cc:
Subject:  RE: a quest for a better scheduler



Timothy D. Witham wrote :
[...]
> I propose that we work on setting up a straight forward test harness
> that allows developers to quickly test a kernel patch against
> various performance yardsticks.

[...
(proposed large server testbeds)
...]

I like this idea, but could the testbeds also include some
resource-constrained "embedded" or appliance-style systems, and
include performance yardsticks for latency and responsiveness?

It would be unfortunate if work on a revised scheduler resulted
in Linux being a monster web server on 4-way systems, but having
lousy interactive performance on web pads, hand helds, and set top
boxes.

How about a 120Mhz Pentium with 32MB of RAM and a flash disk, a 200
Mhz PowerPC with 64 MB?  Maybe a Transmeta web pad?

For the process load, something that tests responsiveness and
latency - how about a set of processes doing multicast network
transfers, CPU-intensive MPEG video and audio encode / decode,
and a test app that measures "user response", i.e. if X Windows
was running, would the mouse pointer move smoothly or jerkily?

The "better" scheduler for these applications would make sure that
multicast packets were never dropped, the MPEG decode never dropped
frames, and the "user interface" stayed responsive, etc.

Also, I would not mind a bit if the kernel had tuning options, either
in configuration or through /proc to adjust for these very different
situations.

Torrey Hoffman
[EMAIL PROTECTED]

-
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: syslog insmod please!

[Philip Blundell]

>I'm not wonderfully impressed with the way that you can't load the FPU 
>emulation module on ARM at the moment without having some form of FPU 
>emulation in your kernel already, either :)

Floating point on ARM is indeed something of a crock, but that particular case
used to work -- can you tell where it's going wrong?  See entry-armv.S, 
about line 680, for the very bad hack that was supposed to facilitate this 
kind of thing.

p.

-
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: VIA 82C686 Audio Codec: Clicks

[Harald Dunkel]

Jani Monoses wrote:
> 
> You could try the ALSA driver if you're certain it is not a hw problem.It
> works better here than the one in the kernel.
> 

Now, _this_ is an improvement! I tried the 0.9.0beta3 version of Alsa.
No more clicks! Amazing. 


Many thanx for your help

Harri
-
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: Arch specific/multiple Configure.help files? [PATCH included]

[Johan Adolfsson]

- Original Message -
From: Giacomo Catenazzi <[EMAIL PROTECTED]>
To: Johan Adolfsson <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, April 06, 2001 13:34
Subject: Re: Arch specific/multiple Configure.help files? [PATCH included]


> Johan Adolfsson wrote:
> >
> > > This change is too big for 2.4 kernel.
> >
> > It doesnt look that big to mee, so here it is for everyones
consideration
> > (the mailprogram probably screws up tabs etc. but you get the idea,
> > I apologise if posting patches like this is the wrong way)
> >
> > The normal user/developer shouldn't even notice the difference,
> > the patch shouldn't break anything, just make it possible to
> > use multiple help files.
> >
> > linux/Makefile: (linenumber probably a bit off)
> > @@ -40,6 +44,10 @@ MODFLAGS = -DMODULE
> >  CFLAGS_KERNEL =
> >  PERL = perl
> >
> > +# Helpfiles used in the config system
> > +# (merged to Documentation/Configure.help.generated)
> > +HELPFILES   = arch/$(ARCH)/Configure.help
Documentation/Configure.help
> > +
> >  export VERSION PATCHLEVEL SUBLEVEL EXTRAVERSION KERNELRELEASE ARCH \
> >   CONFIG_SHELL TOPDIR HPATH HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC \
> >   CPP AR NM STRIP OBJCOPY OBJDUMP MAKE MAKEFILES GENKSYMS MODFLAGS PERL
> > @@ -260,19 +270,22 @@ symlinks:
> >   @if [ ! -d include/linux/modules ]; then \
> >   mkdir include/linux/modules; \
> >   fi
> > +
> > +helpfiles:
> > + -cat $(HELPFILES) >Documentation/Configure.help.generated 2>/dev/null
> >
> > -oldconfig: symlinks
> > +oldconfig: symlinks helpfiles
>
> No!
> Documentation/Configure.help.generated: $(HELPFILES)
> -cat $(HELPFILES) >Documentation/Configure.help.generated
> 2>/dev/null
>
> oldconfig: symlinks Documentation/Configure.help.generated
> ...
>
> Really you should include the ARCH/COnfigure.help in
> $(HELPFILES) only
> if it exists (else make will complain)

That's why I had the -cat and the 2>/dev/null
and not dependencies to them :-)

I'm not a Makefile wizard but the following seems to work,
but it might skip the generation of Configure.help.generated
if you change ARCH and happen to have an old help file
in the arch directory, so I'm not so sure it really is a good idea.
It's safer to generate the file everytime, it doesn't cost much
in time compared to the gerenetion of the configure scripts.


+ # Helpfiles used in the config system
+ # (merged to Documentation/Configure.help.generated)
+ # Add arch specific help if it exists:
+ ifeq (arch/${ARCH}/Configure.help,$(wildcard arch/${ARCH}/Configure.help))
+ HELPFILES   = arch/$(ARCH)/Configure.help
+ else
+ HELPFILES   =
+ endif
+ # Always use good old Documentation/Configure.help:
+ HELPFILES   += Documentation/Configure.help


+ Documentation/Configure.help.generated: $(HELPFILES)
+  cat $(HELPFILES) >Documentation/Configure.help.generated



> >   $(CONFIG_SHELL) scripts/Configure -d arch/$(ARCH)/config.in
> >
> > -xconfig: symlinks
> > +xconfig: symlinks helpfiles
> >   $(MAKE) -C scripts kconfig.tk
> >   wish -f scripts/kconfig.tk
> >
> > -menuconfig: include/linux/version.h symlinks
> > +menuconfig: include/linux/version.h symlinks helpfiles
> >   $(MAKE) -C scripts/lxdialog all
> >   $(CONFIG_SHELL) scripts/Menuconfig arch/$(ARCH)/config.in
> >
> > -config: symlinks
> > +config: symlinks helpfiles
> >   $(CONFIG_SHELL) scripts/Configure arch/$(ARCH)/config.in
> >
>
> ditto.
>
> >  include/config/MARKER: scripts/split-include include/linux/autoconf.h
> >
> > RCS file: /n/cvsroot/os/linux/scripts/Configure,v
> > retrieving revision 1.1.1.2
> > diff -u -p -r1.1.1.2 Configure
> > --- scripts/Configure 2001/01/10 13:28:58 1.1.1.2
> > +++ scripts/Configure 2001/04/06 09:57:44
>
> OK!

Does this meen you think this suggestion is ok?

/Johan


-
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: softirq buggy [Re: Serial port latency]

[Pavel Machek]

Hi!

> > > Ok, there are 2 bugs that are (afaics) impossible to fix without
> > > checking for pending softirq's in cpu_idle():
> > >
> > > a)
> > > queue_task(my_task1, tq_immediate);
> > > mark_bh();
> > > schedule();
> > > ;within schedule: do_softirq()
> > > ;within my_task1:
> > > mark_bh();
> > > ; bh returns, but do_softirq won't loop
> > > ; do_softirq returns.
> > > ; schedule() clears current->need_resched
> > > ; idle thread scheduled.
> > > --> idle can run although softirq's are pending
> >
> > Or anything else can run altrough softirqs are pending. If it is
> > computation job, softinterrupts are delayed quiet a bit, right?
> >
> > So right fix seems to be "loop in do_softirq".
> >
> No, it's the wrong fix.
> A network server under high load would loop forever within the softirq,
> never returning to process level.
> 
> do_softirq cannot loop, the right fix is "check often for pending
> softirq's".
> It's checked before a process returns to user space, it's checked when a
> process schedules. What's missing is that the idle functions must check
> for pending softirqs, too.

Ok. I was missing the fact it is checked on going userspace.

-- 
The best software in life is free (not shareware)!  Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Re: Race in fs/proc/generic.c:make_inode_number()

[Maneesh Soni]

Just a couple of points:

On Thu, Apr 05, 2001 at 10:36:10AM -0400, Tom Leete wrote:
[...]
> +spinlock_t proc_alloc_map_lock = RW_LOCK_UNLOCKED;
> +
Why not make this static?
Initializer should be SPIN_LOCK_UNLOCKED.

Maneesh Soni
Linux Technology Center,
IBM Bangalore.
-
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: syslog insmod please!

[David Woodhouse]

[EMAIL PROTECTED] said:
>  Is there a good reason why insmod should not call syslog() to log any
> module that gets installed ? I know things like bttv get very verbose
> in the module itself, and I tried patching insmod to log the first
> argument and it seemed to work for me.

Consider "insmod unix.o".

I'm not wonderfully impressed with the way that you can't load the FPU 
emulation module on ARM at the moment without having some form of FPU 
emulation in your kernel already, either :)

--
dwmw2


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

very large file system

[Philippe Amelant]

hi,

Is it possible to have 12 To fs  with linux ?
if not what is the current limitation ? (2 To ??) and are they a work
around ?
all info welcome

thanks



-
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: Arch specific/multiple Configure.help files?

[Giacomo Catenazzi]

Andrzej Krzysztofowicz wrote:
> 
> "Giacomo Catenazzi wrote:"
> > Johan Adolfsson wrote:
> > >
> > > Having the help close to the config sounds like a good idea
> > > from a maintenance point of view.
> >
> > But in 2.5.x the config.in are centralized, thus also
> > Configure.help sould be centralized.
> > And in this case I think that a big file hurts nobody.
> 
> What about common config options (like CONFIG_PCI, CONFIG_BINFMT_ELF,
> CONFIG_SMP, CONFIG_SERIAL), which have Configure.help entries wtitten in
> PC-centric style?
> 
> What is info about ISA/EISA bus for sparc users for? Why no info about SBUS
> there?
> What is COM3 for Amiga user?
> How can alpha user compile kernel for Pentium?
> What is the difference between ELF and A.OUT for architectures that do not
> support a.out at all?
> 
> IMO some, even very standard, options may need different explanations for
> different architectures.
> 
> Maybe some kind of architecture-specyfic #include in Configure.help entries?


Two possibilities: With std configuration language change:
: bool 'std IPC support' CONFIG_IPC
into
: bool 'arch specific IPC help' CONFIG_IPC_STRANGE_ARCH
: define_bool CONFIG_IPC CONFIG_IPC_STRANGE_ARCH

This is "clean" and is allowed by CML1 (and in CML2 with a
similar change).

Or we can use the method of Johan.
But if we move some option in i386/Configure.help, users of
other arch
instead of being little confused, their will see no help ->
worse!

Maybe before to make changes, all developers should read the
documentation
and update/change it in a non i386 centric view.

BTW some other arch will use i386 devices, thus or we
duplicate (and
that one of the copy will be old) some entry of we must make
configure.help
i386 centric (and provide other help for other arch). But
SPARC and SPARC64
will use some configuration (different to i386), thus we
should duplicate
half configuration in SPARC.. ?

giacomo
-
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: 2.2.19 + ide 2.2.19 03252001 patch problem

[Robert A. Morris]

>This is a problem the old via-code did "82C686A" fine but knew nothing
>about "82C686B" and the new code does not do well with "82C686A" but
good
>with "82C686B".

I'd be glad to test any patchesIn the meantime, is 
there an older patch that will work + apply relatively cleanly to 
2.2.19?

>Why are we mixing drives this class?

On the same cable?  I seem to get better data rates (according 
to testing with hdparm) if the newer drives are the masters.  It only
amounts to a few tenths of a MB/sec, though, so I suppose the
old drive could be the secondary master on the cable with the 
DVD-ROM.  Would this help?

Thanks for your help!
-
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: __switch_to macro

[Jamie Lokier]

[EMAIL PROTECTED] wrote:
> There's one thing that confuses me: don't you get a segment_not_present
> fault?  If so, traps.c's do_segment_not_present doesn't appear to search
> the exception table, and the code in loadsegment would not work.
> 
> >>> well.. I peeked into traps.c.. I do seem a call to die_if_no_fixup
> in this function. And I think loadsegment is already making an entry in
> exception table.

Ah, you're right.  I didn't follow DO_ERROR all the way to do_trap and
hency search_exception_table.

-- Jamie
-
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: syslog insmod please!

[Mr. James W. Laferriere]

Hello Ion ,

On Thu, 5 Apr 2001, Ion Badulescu wrote:
> On Thu, 5 Apr 2001, Andreas Dilger wrote:
> > Why do it from user space?  Simply add a printk() to sys_init_module() or
> > similar.
> Agreed, but at that point the solution has absolutely nothing to do with
> insmod anymore. :-)

> Besides, as you said, I don't really see the point. It certainly doesn't
> help with logging the actions of an attacker, and on the other hand kmod
> already logs its own actions.
Not the problem being discussed ,  This is a user now root &
having gained root is now attempting to from the command line
to load a module .  How do we get this event recorded ?  kmod
only works when the user calles for the service & then it loads
it .  Tia ,  JimL
   ++
   | James   W.   Laferriere | System  Techniques | Give me VMS |
   | NetworkEngineer | 25416  22nd So |  Give me Linux  |
   | [EMAIL PROTECTED] | DesMoines WA 98198 |   only  on  AXP |
   ++

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

A fork-like C-wrapper for clone()?

[Francesc Oller]

Hi all!

is there a fork-like C-wrapper for clone which would let write
something like:

  if ((pid=clone(0,SIGCHLD|CLONE_VM))==0) /* child */
{
  child_code;
  _exit(0);
}
  else
{
  assert(pid>0); /* mother */
  mother_code;
  exit(0);
}

I'm not thinking in glibc'__clone or Linus' clone.c example since
they encapsulate the main thread code in a function. (i.e. not
fork-like)

Can somebody point me to some sample code?

I'll thank a CC to my e-mail

cheers

Francesc Oller
-
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: Arch specific/multiple Configure.help files? [PATCH included]

[Giacomo Catenazzi]

Johan Adolfsson wrote:
> 
> > This change is too big for 2.4 kernel.
> 
> It doesnt look that big to mee, so here it is for everyones consideration
> (the mailprogram probably screws up tabs etc. but you get the idea,
> I apologise if posting patches like this is the wrong way)
> 
> The normal user/developer shouldn't even notice the difference,
> the patch shouldn't break anything, just make it possible to
> use multiple help files.
> 
> linux/Makefile: (linenumber probably a bit off)
> @@ -40,6 +44,10 @@ MODFLAGS = -DMODULE
>  CFLAGS_KERNEL =
>  PERL = perl
> 
> +# Helpfiles used in the config system
> +# (merged to Documentation/Configure.help.generated)
> +HELPFILES   = arch/$(ARCH)/Configure.help Documentation/Configure.help
> +
>  export VERSION PATCHLEVEL SUBLEVEL EXTRAVERSION KERNELRELEASE ARCH \
>   CONFIG_SHELL TOPDIR HPATH HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC \
>   CPP AR NM STRIP OBJCOPY OBJDUMP MAKE MAKEFILES GENKSYMS MODFLAGS PERL
> @@ -260,19 +270,22 @@ symlinks:
>   @if [ ! -d include/linux/modules ]; then \
>   mkdir include/linux/modules; \
>   fi
> +
> +helpfiles:
> + -cat $(HELPFILES) >Documentation/Configure.help.generated 2>/dev/null
> 
> -oldconfig: symlinks
> +oldconfig: symlinks helpfiles

No!
Documentation/Configure.help.generated: $(HELPFILES)
-cat $(HELPFILES) >Documentation/Configure.help.generated
2>/dev/null

oldconfig: symlinks Documentation/Configure.help.generated
...

Really you should include the ARCH/COnfigure.help in
$(HELPFILES) only
if it exists (else make will complain)

>   $(CONFIG_SHELL) scripts/Configure -d arch/$(ARCH)/config.in
> 
> -xconfig: symlinks
> +xconfig: symlinks helpfiles
>   $(MAKE) -C scripts kconfig.tk
>   wish -f scripts/kconfig.tk
> 
> -menuconfig: include/linux/version.h symlinks
> +menuconfig: include/linux/version.h symlinks helpfiles
>   $(MAKE) -C scripts/lxdialog all
>   $(CONFIG_SHELL) scripts/Menuconfig arch/$(ARCH)/config.in
> 
> -config: symlinks
> +config: symlinks helpfiles
>   $(CONFIG_SHELL) scripts/Configure arch/$(ARCH)/config.in
> 

ditto.

>  include/config/MARKER: scripts/split-include include/linux/autoconf.h
> 
> RCS file: /n/cvsroot/os/linux/scripts/Configure,v
> retrieving revision 1.1.1.2
> diff -u -p -r1.1.1.2 Configure
> --- scripts/Configure 2001/01/10 13:28:58 1.1.1.2
> +++ scripts/Configure 2001/04/06 09:57:44

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

IV calculation, blocksize (and CBC type encryptions) in loop.c

[Herbert Valerio Riedel]

hello...

On Thu, 5 Apr 2001, Jens Axboe wrote:
> On Thu, Apr 05 2001, Herbert Valerio Riedel wrote:
> > I've had success w/ your lvm-stack-1 patch on my system...
> > (next thing I'll testing will be w/ the real crypto patch)
> Ok, good so far.

well... after some hours of code reading and experimenting I'm a bit stuck
with the next problem: the blocksize in the loop's transfer function...

I've got this one problem:

for encryption to work, especially the cbc variants (which are the only
one supported for loop encryption by the newest crypt patch), I need to
read the data block with the same block length, which it was written
with

e.g. since user space programs aren't able to set the blocksize on loop
devices, they use the last active blocksize for that loop device.

on the other hand kernel space code is able to set blocksize... or at
least it seems so...
(btw, does loop_get_bs() return always the same blocksize... ?)

I've noticed that kernelspace filesystem code is able to do so... what

I've tried: I modified transfer_none() to spit out the arguments it got
passed, then I set up a loop device (about 1 gig large), then I created a
filesystem with mke2fs, making sure a blocksize greater than BLOCK_SIZE
was used, then I tried to sync/flush the buffer cache, and then I mounted
that filesystem... (using XFS shows the problem even better, since that
filesystem uses different blocksizes for the different sections)

$ losetup /dev/loop0 /dev/hda1

$ mke2fs -b 4096 /dev/loop0
this showed transfer's were done with size % 1024 == 0...

$ [...flush/sync buffers...]

$ mount /dev/loop0 /mnt/foo
this showed that transfer's were done mostly with size % 4096 == 0
and real_block % 4 == 0

$ umount /dev/loop0

$ mke2fs -b 4096 /dev/loop0
now all transfer's have size % 4096 == 0 and real_block % 4 == 0...

(btw, trying to set the blocksize by ioctl() from user space fails...)

now I could just workaround that problem, by operating on smaller blocks
in the transfer_function, and incrementing that IV by myself...
but then another problem is, that the IV calculation
breaks if the blocksize is set below 1024 byte, and only partial blocks
(as those blocksizes on which IV calculation relays) get processed... :-/

it's quite a mess :-(

you can test for yourself the effects, by making the transfer_xor
scrambling key depending on the real_block argument... (w/o having to
apply the full crypto patches...)

any ideas how to get IV+cbc based crypto 'fixed'?
(btw, I'm talking about block device backed loop setup's, no lvm
involved... just /dev/hda1...)

I hope I've succeeded explaining the problem clear enough...

greetings,
--

-
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: Arch specific/multiple Configure.help files?

[Andrzej Krzysztofowicz]

"Giacomo Catenazzi wrote:"
> Johan Adolfsson wrote:
> > 
> > Having the help close to the config sounds like a good idea
> > from a maintenance point of view.
> 
> But in 2.5.x the config.in are centralized, thus also
> Configure.help sould be centralized.
> And in this case I think that a big file hurts nobody.

What about common config options (like CONFIG_PCI, CONFIG_BINFMT_ELF,
CONFIG_SMP, CONFIG_SERIAL), which have Configure.help entries wtitten in
PC-centric style?

What is info about ISA/EISA bus for sparc users for? Why no info about SBUS
there?
What is COM3 for Amiga user?
How can alpha user compile kernel for Pentium?
What is the difference between ELF and A.OUT for architectures that do not
support a.out at all?

IMO some, even very standard, options may need different explanations for
different architectures.

Maybe some kind of architecture-specyfic #include in Configure.help entries?

Just my 0.03 PLZ

Andrzej
-
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: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

[Ivan Kokshaysky]

On Thu, Apr 05, 2001 at 12:20:22PM -0600, Eric W. Biederman wrote:
> The point is on the Alpha all ram is always cached, and i/o space is
> completely uncached.  You cannot do write-combing for video card
> memory.

Incorrect. Alphas have write buffers - 6x32 bytes on ev5 and
4x64 on ev6, IIRC. So alphas do write up to 32 or 64 bytes
in a single pci transaction.

>  Memory barriers are a separate issue.  On the alpha the
> natural way to implement it would be in the page table fill code.
> Memory barriers are o.k. but the really don't help the case when what
> you want to do is read the latest value out of a pci register.  

You don't need memory barrier for that. "Write memory barriers" are
used to ensure correct write order, and "memory barriers" are used
to ensure that all pending reads/writes will complete before next read
or write.

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

mirror

[Fabio Massimo Di Nitto]

Hi all,
there are some files on zeus.kernel.org that probably
have some wrong permissions:

Failed to get kernel/people/sct/ext3/e2fsprogs/e2fsprogs.spec: 550
kernel/people/sct/ext3/e2fsprogs/e2fsprogs.spec: Permission denied
Failed to get file 550 kernel/people/sct/ext3/e2fsprogs/e2fsprogs.spec:
Permission denied
Failed to get kernel/v2.2/ChangeLog-2.2.19: 550
kernel/v2.2/ChangeLog-2.2.19: Permission denied
Failed to get file 550 kernel/v2.2/ChangeLog-2.2.19: Permission denied

Can someone fix theme please?

Regards
Fabio
-
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: Arch specific/multiple Configure.help files? [PATCH included]

[Johan Adolfsson]

- Original Message -
From: Giacomo Catenazzi <[EMAIL PROTECTED]>
To: Johan Adolfsson <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, April 06, 2001 11:39
Subject: Re: Arch specific/multiple Configure.help files?


> Johan Adolfsson wrote:
> >
> > > - IIRC there is only few ARCH specific configuration, thus we
> > > don't
> > >   reduce the size of che Configure.help
> > >   Note that the arch/config.in have to much configuration item
> > >   (but they repeat in (nearly) all arch/config.in files, thus
> > > you
> > >   should count only the really arch specific item.
> >
> > Here are some results:
> > $ wc arch/cris/Configure.help
> > 6214424   28373 arch/cris/Configure.help
> > $ wc Documentation/Configure.help
> >   17480  121037  773694 Documentation/Configure.help
> > $ grep CONFIG arch/cris/Configure.help |wc
> >  75 1382337
> > $ grep CONFIG Documentation/Configure.help |wc
> >14861640   30135
> >
> > it's not entiraly correct since the CONFIG_BLUETOOTH help
> > is in the arch/cris directory and that should probably be in
> > Documentation/ or in the OpenBT package and merged from there.
> > The file also contains the # LocalWords: rows from the original
> > Configure.help.
> >
> > But the ETRAX/CRIS config is 3-5% of the total config.
>
> This seem too much. If all arch have a so big CONFIG space, I
> think that your idea can do some improvement.

The file contains some stuff we used in the 2.0 uC-linux version
that we now implement using the netfilter and an application (6 options),
and the bluetooth stuff has 10 options, but the rest is more or less
hardware (ETRAX) specific stuff.

> But: user don't see the difference. Do you think that
> developers
> would like your proposal? (If arch maintainers agree, you can
> try to publish your patch)
As a developer I would ;-) (although I'm not the real maintainer)
Using this feature is not mandatory, but for SOC solutions
that are not PC based, I think it could be helpful.

> > Having the help close to the config sounds like a good idea
> > from a maintenance point of view.
>
> But in 2.5.x the config.in are centralized, thus also
> Configure.help sould be centralized.
> And in this case I think that a big file hurts nobody.
>
> >
> > Sounds better than dealing with two different help files in the
> > config system.
> > Is there an ETA when ESR CML2 will be in the official kernel?
> > (I guess I should catch up on what it will provide instead of
> >  wasting peoples time...)
>
> In 2.5.2 kernel. What We don't know is when 2.5.2 will be
> released!
>
> >
> > Would adding support for merging help files in the current config
> > system be accepted in the meanwhile?
>
> In 2.4: No. Distribution expect a stable interface.

I'm not sure about the definition of a "stable interface",
but this will not really change the interface at all.

> In 2.5 will be the new CML2.
> Again if arch maintainer agree with your proposal, you can
> change
> the CML2. Not so difficult (and you change only in one place
> for all interfaces (olconfig/config/menuconfig/xconfig)
>
> > E.g. Configure, Menuconfig and header.tk is changed to use
> > Documentation/Configure.help.generated
> > and the top Makefile does
> > cat $(HELPFILES) >Documentation/Configure.help.generated 2>/dev/null
> > for oldconfig, config, menuconfig and xconfig targets?
> > And HELPFILES is set to:
> > HELPFILES = arch/$(ARCH)/Configure.help Documentation/Configure.help
> >
> > External patches that add functionality could easaly add
> > HELPFILES += some new help files
> > rows to get the help as well.
>
> This change is too big for 2.4 kernel.

It doesnt look that big to mee, so here it is for everyones consideration
(the mailprogram probably screws up tabs etc. but you get the idea,
I apologise if posting patches like this is the wrong way)

The normal user/developer shouldn't even notice the difference,
the patch shouldn't break anything, just make it possible to
use multiple help files.

linux/Makefile: (linenumber probably a bit off)
@@ -40,6 +44,10 @@ MODFLAGS = -DMODULE
 CFLAGS_KERNEL =
 PERL = perl

+# Helpfiles used in the config system
+# (merged to Documentation/Configure.help.generated)
+HELPFILES   = arch/$(ARCH)/Configure.help Documentation/Configure.help
+
 export VERSION PATCHLEVEL SUBLEVEL EXTRAVERSION KERNELRELEASE ARCH \
  CONFIG_SHELL TOPDIR HPATH HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC \
  CPP AR NM STRIP OBJCOPY OBJDUMP MAKE MAKEFILES GENKSYMS MODFLAGS PERL
@@ -260,19 +270,22 @@ symlinks:
  @if [ ! -d include/linux/modules ]; then \
  mkdir include/linux/modules; \
  fi
+
+helpfiles:
+ -cat $(HELPFILES) >Documentation/Configure.help.generated 2>/dev/null

-oldconfig: symlinks
+oldconfig: symlinks helpfiles
  $(CONFIG_SHELL) scripts/Configure -d arch/$(ARCH)/config.in

-xconfig: symlinks
+xconfig: symlinks helpfiles
  $(MAKE) -C scripts kconfig.tk
  wish -f scripts/kconfig.tk

-menuconfig: include/linux/version.h symlinks
+menuconfig: inclu

2.0.39 stat/inode handling race? [2.0.39 oopses in sys_new(l)stat]

[Ville Herva]

On Thu, Apr 05, 2001 at 11:34:46PM +0200, you [David Weinehall] claimed:
> 
> I'll look into it. A note, however: the additional oops:es that follow
> the first one are almost never ever useful, because the system is no
> longer in a consistent state after the first one.

Apr  5 05:33:35 some kernel: general protection: 
Apr  5 05:33:36 some kernel: CPU:0
Apr  5 05:33:36 some kernel: EIP:0010:[__iget+60/544]
Apr  5 05:33:36 some kernel: EFLAGS: 00010292
Apr  5 05:33:36 some kernel: eax: 0341   ebx: 9a0004b6   ecx: 000203e5 edx: 
001c7658
Apr  5 05:33:36 some kernel: esi: 001ba164   edi:    ebp: 001c7658 esp: 
06436ef0
Apr  5 05:33:36 some kernel: ds: 0018   es: 0018   fs: 002b   gs: 002b   ss: 0018
Apr  5 05:33:36 some kernel: Process rsync (pid: 15624, process nr: 76, 
stackpage=06436000)
Apr  5 05:33:36 some kernel: Stack: 05144d00 07ff1418 0004 03070004 07ff1418 
00154f27 001c7658 000203e5
Apr  5 05:33:36 some kernel:0001 05144d00 06436f74 06436f74 0004 
0897eaf8 000203e5 0012ce12
Apr  5 05:33:36 some kernel:05144d00 03070004 0004 06436f74  
06436f74 06436fb4 bfffdb30
Apr  5 05:33:36 some kernel: Call Trace: [ext2_lookup+343/368]
[lookup+222/248] [_namei+90/228] [lnamei+48/72] [sys_newlstat+41/88]
[system_call+85/124]
Apr  5 05:33:36 some kernel: Code: 66 39 03 75 0d 8b 4c 24 1c 39 4b 04 0f 84 fa 00 00 
00 8b 5b

I'm trying to make sense of the oops. Looking at the __iget and ext2_lookup
source, (1) 000203e5 might be the inode number? Is (2) 0004 the length
of the filename? Looking at the System.map (0012cd34 T lookup), (3) seems to
be the return address to lookup+222, and (4) the return address to
ext2_lookup+343.

Stack: 05144d00 07ff1418 0004 03070004 07ff1418 00154f27 001c7658 000203e5
 (2)(4)   (1)
   0001 05144d00 06436f74 06436f74 0004 0897eaf8 000203e5 0012ce12
  (3)
   05144d00 03070004 0004 06436f74  06436f74 06436fb4 bfffdb30

Inode 132069 is (0x000203e5) is

  File: "./mnt/hdb/backup/backup-versioned/2001-03-10_05.23.01/dev/vcs6"
  Size: 0Filetype: Character Device
  Mode: (0620/crw--w) Uid: ( 1414/  vherva)  Gid: (5/
tty)
Device:  3,0   Inode: 132069Links: 30Device type:  7,0 
Access: Tue May  5 23:32:27 1998(01066.13:15:05)
Modify: Tue May  5 23:32:27 1998(01066.13:15:05)
Change: Fri Apr  6 05:28:24 2001(0.07:19:08)

At the time of the oops, to heavy stat() callers where running: a cron job
that rsyncs pretty much the whole / to a backup fs (where there are
mutually hardlinked daily snapshots of /) and a cvs checkout that checks out
~20MB of source and then builds it. Rsync runs on root fs and backup fs,
where as the cvs is running only on /. Perhaps there is some kind of race
for example in the inode cache handling? This is of course just a wild
guess... (Note that this is UP, though). It'd be curious, though, that the
race wouldn't have showed up before.

In addition to the instense and concurrent stat()'ing activity, one
noteworthy thing might be that on the backup fs, the inodes are likely to
have quite high link counts. I don't know what it could affect, though.

Any ideas?


-- v --

[EMAIL PROTECTED]
-
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/

[DRIVER] New framebuffer driver for Permedia3 (2.2.x & 2.4.y)

[Romain Dolbeau]

[To:linux-kernel & CC:linux-fbdev-devel]

Hello,

I've written a framebuffer (fbdev) driver for the 3DLabs Permedia3
chipset, targeted at both kernel 2.2.x and 2.4.y, and available at:



As mentioned on the page, the driver hasn't been thoroughly
tested except on my board, as even after two announcements
on the fbdev-devel list there hasn't been any answer beside
a XFree86 driver develloper. Fortunately that's two different
boards on two different architectures of different endianess.

The only _known_ remaining bug relate to depth switching,
going from 8 to 16/32 bpp give a wrong colormap (need to
go to X and back to restore). The only known current fix
is a small patch again driver/video/fbgen.c that probably
break something else, so I haven't included it in the
distributed patch.

If the driver is ever integrated, here's the MAINTAINERS
stuff: (not yet included in the linux kernel patches)

PERMEDIA 3 FRAMEBUFFER DRIVER
P: Romain Dolbeau
M: [EMAIL PROTECTED]
L: [EMAIL PROTECTED]
W: 
S: Maintained

Hope someone will find it useful,

-- 
DOLBEAU Romain   | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann| je l'ai imaginee d'un bout a l'autre
[EMAIL PROTECTED] |   -- Boris Vian
-
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: Arch specific/multiple Configure.help files?

[Giacomo Catenazzi]

Johan Adolfsson wrote:
> 
> > - IIRC there is only few ARCH specific configuration, thus we
> > don't
> >   reduce the size of che Configure.help
> >   Note that the arch/config.in have to much configuration item
> >   (but they repeat in (nearly) all arch/config.in files, thus
> > you
> >   should count only the really arch specific item.
> 
> Here are some results:
> $ wc arch/cris/Configure.help
> 6214424   28373 arch/cris/Configure.help
> $ wc Documentation/Configure.help
>   17480  121037  773694 Documentation/Configure.help
> $ grep CONFIG arch/cris/Configure.help |wc
>  75 1382337
> $ grep CONFIG Documentation/Configure.help |wc
>14861640   30135
> 
> it's not entiraly correct since the CONFIG_BLUETOOTH help
> is in the arch/cris directory and that should probably be in
> Documentation/ or in the OpenBT package and merged from there.
> The file also contains the # LocalWords: rows from the original
> Configure.help.
> 
> But the ETRAX/CRIS config is 3-5% of the total config.

This seem too much. If all arch have a so big CONFIG space, I
think that your idea can do some improvement.
But: user don't see the difference. Do you think that
developers
would like your proposal? (If arch maintainers agree, you can
try to publish your patch)

> 
> Having the help close to the config sounds like a good idea
> from a maintenance point of view.

But in 2.5.x the config.in are centralized, thus also
Configure.help sould be centralized.
And in this case I think that a big file hurts nobody.

> > > > ESR CML2 have the defualt path for Configure.help build in
> > > > the rules files, but it can be overriden by command options
> > > > to use an other Configure.help (the format do not change).
> > >
> > > I want to be able to use two help files.
> >
> > I think it is not a big issue. In Makefile we can
> > : cat Conf.help.1 Conf.help2 > .Conf.help
> 
> Sounds better than dealing with two different help files in the
> config system.
> Is there an ETA when ESR CML2 will be in the official kernel?
> (I guess I should catch up on what it will provide instead of
>  wasting peoples time...)

In 2.5.2 kernel. What We don't know is when 2.5.2 will be
released!

> 
> Would adding support for merging help files in the current config
> system be accepted in the meanwhile?

In 2.4: No. Distribution expect a stable interface.
In 2.5 will be the new CML2.
Again if arch maintainer agree with your proposal, you can
change
the CML2. Not so difficult (and you change only in one place
for all interfaces (olconfig/config/menuconfig/xconfig)

> E.g. Configure, Menuconfig and header.tk is changed to use
> Documentation/Configure.help.generated
> and the top Makefile does
> cat $(HELPFILES) >Documentation/Configure.help.generated 2>/dev/null
> for oldconfig, config, menuconfig and xconfig targets?
> And HELPFILES is set to:
> HELPFILES = arch/$(ARCH)/Configure.help Documentation/Configure.help
> 
> External patches that add functionality could easaly add
> HELPFILES += some new help files
> rows to get the help as well.

This change is too big for 2.4 kernel.

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

Kernel 2.4.3 compile error - why ??

[Wojciech \"Sas\" Cieciwa]

Hi,

I try to compile kernel downloaded from
ftp.kernel.org.
I have all programs that this kernel require.
But I can't compile kernel :(

Ooops, can't compile kernel modules:

[...]
make[3]: Opuszczam katalog `/users/cieciwa/rpm/BUILD/linux/drivers/media/radio'
make -C video modules
make[3]: Wchodzę katalog `/users/cieciwa/rpm/BUILD/linux/drivers/media/video'
ld -m elf_i386  -r -o bttv.o bttv-driver.o bttv-cards.o bttv-if.o
ld -m elf_i386  -r -o zoran.o zr36120.o zr36120_i2c.o zr36120_mem.o
gcc -D__KERNEL__ -I/users/cieciwa/rpm/BUILD/linux/include -Wall -Wstrict-prototypes 
-O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 
-march=i686 -DMODULE   -c -o buz.o buz.c
buz.c: In function `v4l_fbuffer_alloc':
buz.c:188: `KMALLOC_MAXSIZE' undeclared (first use in this function)
buz.c:188: (Each undeclared identifier is reported only once
buz.c:188: for each function it appears in.)
buz.c: In function `jpg_fbuffer_alloc':
buz.c:262: `KMALLOC_MAXSIZE' undeclared (first use in this function)
buz.c:256: warning: `alloc_contig' might be used uninitialized in this function
buz.c: In function `jpg_fbuffer_free':
buz.c:322: `KMALLOC_MAXSIZE' undeclared (first use in this function)
buz.c:316: warning: `alloc_contig' might be used uninitialized in this function
buz.c: In function `zoran_ioctl':
buz.c:2837: `KMALLOC_MAXSIZE' undeclared (first use in this function)
make[3]: *** [buz.o] Błąd 1
make[3]: Opuszczam katalog `/users/cieciwa/rpm/BUILD/linux/drivers/media/video'
make[2]: *** [_modsubdir_video] Błąd 2
make[2]: Opuszczam katalog `/users/cieciwa/rpm/BUILD/linux/drivers/media'
make[1]: *** [_modsubdir_media] Błąd 2
make[1]: Opuszczam katalog `/users/cieciwa/rpm/BUILD/linux/drivers'
make: *** [_mod_drivers] Błąd 2

What's wrong ??

Thanx.
Sas.
P.S.
Sorry for my "language".
-- 
{Wojciech 'Sas' Cieciwa}  {Member of PLD Team   }
{e-mail: [EMAIL PROTECTED], http://www2.zarz.agh.edu.pl/~cieciwa}

-
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: __switch_to macro

[alad]

Jamie Lokier <[EMAIL PROTECTED]> on 04/06/2001 03:18:13 PM

To:   Amol Lad/HSS@HSS
cc:   [EMAIL PROTECTED]

Subject:  Re: __switch_to macro




[EMAIL PROTECTED] wrote:
> 1) What exactly is meant by ' stale segment register values' in the note.
> 2) In the above macro, I think we recover gracefully from error
>condition while recovering fs and gs segment registers . The
>loadsegment(fs,next->tss.fs) and loadsegment(gs,next->tss.gs) does
>it.  I am not able to understand loadsegment macro. The macro is as under
>
> /** Load a segment. Fall back on loading a zero segment if something goes
wrong
> **/
> #define loadsegment(seg,value)   \
>  asm volatile("\n" \
>   "1:\t"   \
>   "movl %0,%%" #seg "\n"   \
>   "2:\n"   \
>   "3:\t"   \
>   "pushl $0\n\t"   \
>   "jmp 2b\n"   \
>   ".previous\n"\
>   ".section __ex_table,\"a\"\n\t  \
>   "/align 4\n\t"   \
>   ".long 1b,3b\n"  \
>   ".previous"  \
>   : :"m" (*(unsigned int *)&(value)))
>
> I also want to know what is 'something' in the comment above the macro

The answers to 1. and 'something' are the same: stale segment values.
You can't load any value into %ss, %ds, %es, %fs or %gs.  They must be
valid references into the GDT or LDT, with the appropriote protection
level, or 0.

Usually the values stored in tss are ok, as they were valid values when
they were stored.  However for programs that use modify_ldt, it's
possible for a valid LDT entry to be made invalid while some tss still
refers to that segment.

>>> Thanks a lot.. good explanation..

At the next attempt to load the segment value into a segment register,
you get a fault.  The code in loadsegment traps this fault and loads
zero into the segment register instead when this happens.  Zero is
always allowed.  If the user program then tries to access data
referenced by that segment register, user space will get a
general_protection fault.  As it's only user space that calls modify_ldt
to invalidate an LDT entry, that's reasonable.

There's one thing that confuses me: don't you get a segment_not_present
fault?  If so, traps.c's do_segment_not_present doesn't appear to search
the exception table, and the code in loadsegment would not work.

>>> well.. I peeked into traps.c.. I do seem a call to die_if_no_fixup
in this function. And I think loadsegment is already making an entry in
exception table.

Amol


-- Jamie




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