Re: goodbye

[Rik van Riel]

On Sun, 8 Apr 2001, David S. Miller wrote:
> Rik van Riel writes:
>  > Anyway, since linux-kernel has chosen to not receive email from me
> 
> Funny how this posting went through then...
> 
> If it is specifically when you are sending mail from some other place,
> state so, don't make blanket statements which obviously are not wholly
> true.

I'm temporarily using my ISP's smarthost.  However, I'll turn
this off again soon because I'd rather stop with linux-kernel
then give in to the guilty-by-default attitude that comes with
DUL.

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com.br/

-
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: 8139too.c and 2.4.4-pre1 kernel burp

[Frank Jacobberger]

Jeff Garzik wrote:

> Frank Jacobberger wrote:
> 
>> Jeff,
>> 
>> I noticed the following on boot with 2.4.4-pre1:
>> 
>> kernel: eth0: Too much work at interrupt, IntrStatus=0x0001.
>> 
>> What is this saying to me :)
> 
> 
> How often does this occur?  A lot, or just once or twice?
> 
Every time I boot the kernel... very last statement.



-
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: race condition on looking up inodes

[Bernd Eckenfels]

In article <000201c0c0a4$eb5c7b10$321ea8c0@saturn> you wrote:
>rename("/usr/hybrid/cfg/data","/usr/mytemp/data1"); /*for process 1*/
>  rename("/usr/mytemp/data1","/usr/test");/* for process 2*/

Rename syscall is expected to be atomic on unixoid systems. And I dont know of
a case where a problem is, besides if you use some network file system, where
nobody can realy gurantee anything (well kidding, but it is harder than on a
local one).

The second rename may see the result of the first rename or the original state
before the first rename. It will not see any half-state or locked nodes.

Greetings
Bernd
-
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: goodbye

[David S. Miller]

Rik van Riel writes:
 > Anyway, since linux-kernel has chosen to not receive email from me

Funny how this posting went through then...

If it is specifically when you are sending mail from some other place,
state so, don't make blanket statements which obviously are not wholly
true.

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: race condition on looking up inodes

[Alexander Viro]

On Mon, 9 Apr 2001, warren wrote:

> 
> 
> Hi,
> I had post a simillar message before.
> Thanks for the replay from Albert D. Cahalan. But i found some results
> confusing me.
> For example,  process 1 and process 2 run concurrently and execute the
> following system calls.
> 
> rename("/usr/hybrid/cfg/data","/usr/mytemp/data1"); /*for process 1*/
> 
>
> 
>   rename("/usr/mytemp/data1","/usr/test");/* for process 2*/

>   
>   It is possible that context switch happens when process 1 is look ing up
> the inode for "/usr/mytemp/data1"  or the inode for "/usr/hybrid/cfg/data".

>  It will result in diffrent behaviour for process 2 and confuses the
> application.

>   If so,how does Linux solve?

Solves what, precisely? Result depends on the order of these calls. If
you don't provide any serialization - you get timing-dependent results
you were asking for. What's the problem and what behaviour do you expect?

Besides, what's the difference caused by the moment of context switch?

-
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: goodbye

[Rik van Riel]

On Sun, 8 Apr 2001, Matti Aarnio wrote:

>   The incentive behind the DUL is to force users not to post
>   straight out to the world, but to use their ISP's servers
>   for outbound email --- normal M$ users do that, after all.
>   Only spammers - and UNIX powerusers - want to post directly
>   to the world from dialups.  And UNIX powerusers should know
>   better,

UNIX power users do know better.  They know their ISPs mail
server could show up in RSS or ORBS any moment. Therefor they
use their own machines for sending out email.

IMHO DUL is an unethical list to use because it assumes guilty
by default. This is different from all other spam blocking lists,
which only block hosts _after_ they've found something wrong with
them.

The other exception is untestable-netblocks.orbs.org, which blocks
everything it cannot test and is just as bad as DUL.

Anyway, since linux-kernel has chosen to not receive email from me
I won't bother answering VM bugreports or anything here. It's up to
Matti and Davem to decide how useful a place linux-kernel will be.

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com.br/

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

Network Driver

[Rajeev Nigam]

Hello All,

I have a blue tooth stack and a BT device and the device connects on the
serial port, over that I have to run tcpip.

Can u tell me which driver I have to need or Is there no need to write any
driver.

Should I have to write any character driver or network driver, can u pls
suggeste me over which tcpip wud be run.

Have u any idea about PCMCIA??

>From where i can get any sample code regarding our needs.
any further suggestion wud be appreciate.

Thanx & Regards 
Rajeev Nigam 
-
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: rw_semaphores

[Linus Torvalds]

The "down_writer_failed()" case was wrong:

On Sun, 8 Apr 2001, Linus Torvalds wrote:
>
>   __down_write_failed(sem)
>   {
>   
>   /*
>* Ignore other pending writers: but if there is
>* are pending readers or a write holder we should
>* sleep
>*/
>   if (value & 0xc0007fff) {


The "value & 0xc0007" test is wrong, because it's actually always true
for some normal contention case (multiple pending writers waiting for a
reader to release the lock). Because even if there is no write lock
holder, other pending writers (and we're one) will have caused the high
bits to be set, so the above would end up causing us to think that we
can't get the lock even if there is no real lock holder.

The comment is right, though. It's just the test that is simplistic and
wrong.

The pending readers part is correct, and obvious enough:

(value & 0x7fff) != 0

implies that there are readers. In which case we should try again. Simple
enough.

The pending writers part is slightly more subtle: we know that there is at
least _one_ pending writer, namely us. It turns out that we must check the
two high bits, and the logic is:

 - 11: only pending writers, no write lock holder (if we had a write lock
   holder, he would have set the bits to 11, but a pending writer
   would have borrowed from the lower bit, so you'd get bit pattern
   10).
 - 10: we have a real lock holder, and the pending writers borrowed from
   the low lock bit when they did the "subl 0x8000" to mark off
   contention.
 - 01: must not happen. BUG.
 - 00: we had a real write lock holder, but he released the lock and
   cleared both bits.

So the "si there a write lock holder" test basically becomes

(value & 0xc000) == 0x8000

and the full test should be

if ((value & 0x7fff) || ((value & 0xc000) == 0x8000) {
spin_unlock();
schedule();
spin_lock();
continue;
}

which might be rewritten some simpler way. I'm too lazy to think about it
even more.

For similar reasons, the "newvalue" calculation was subtly bogus: we must
make sure that we maintain the correct logic for the two upper bits in the
presense of _other_ pending writers. We can't just do the unconditional
binary "or" operation to set the two upper bits, because then we'd break
the above rules if there are other pending writers. So the newvalue
calculation should be something along the lines of

/* Undo _our_ contention marker */
newvalue = value + 0x8000;

/* Get rid of stale writer lock bits */
newvalue &= 0x3fff;

/*
 * If there were no other pending writers (newvalue == 0), we set
 * both high bits, otherwise we only set bit 31.
 * (see above on the "borrow bit being clear" logic).
 */
if (!newvalue)
newvalue = 0xc000;
newvalue |= 0x8000;

And THEN I think the algorithm in the email I'm following up to should
actually really work.

Does anybody find any other details I missed?

And no, I have not yet actually _tested_ any of this. But all my code
works on the first try (or, in this case, second try if you want to be a
stickler for details).

No wonder we didn't get this right first time through. It's not really all
that horribly complicated, but the _details_ kill you.

Linus

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

Fast & Wide chip info

[Jeff Walther]

You may already have this information, but in case this info will be useful
to someone, the data sheets for the successor (pin compatible) chip to the
SYMBIOS LOGIC 53C825A is here:
http://www.lsilogic.com/techlib/techdocs/storage_stand_prod/PCISCSICont/Chip
s/825A.BK.pdf

LSI Logic bought SYMBIOS several years ago.   Also SYMBIOS is the spinoff
name of NCR's semiconductor group.  So, for example, the NCR 53CF96 which
you'll find on the Power Mac 8100 became a SYMBIOS part and then became an
LSI Logic part.  I suspect that the 53CF96 was licensed and became the MESH
chip in later Macs.  I haven't had time to do a pinout comparison between
the 53CF96 and the MESH, but they're in the same package and on casual
inspection the hookups look similar.

Anyway, the 53C825 information is available there and LSI Logic claims to
have Linux drivers available for download, in case those weren't used when
support was added.

Jeff Walther

P.S.  Anyone have a Mac CPU daughter card slot pinout (x500 machines)?  I
just need about ten pins.  I have the rest figured out.  I'd be happy to
supply my Bandit chip pinout.


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

The same Maestro 2E Driver problems (2.2.17)

[Scott A Crosby]

Hi... I was going through kernel traffic and read the article on the
Maestro Driver problems.. I'm having very similar problems on my
Dell i5000e laptop.


The symtoms are:

When I play MP3's, on an otherwise unloaded system, I notice progressive
noisiness.. The longer it plays, (5-60 minutes), the stronger these
artifacts are. It's like a constant high-frequency twirping and very
annoying.

When I have xmms 'seek' around, that tends to cause it to start
introducing those artifacts.. If I stop the MP3 player and restart it, the
artifacts go away completely, though they come back again.

A second symptom is that occasionally a channel drops out; either left or
right.

Thse tends to happen on 'song boundries'. IE, times when the sound buffer
is switched before the chip finishes sending it.


Scott



--
Kernel version::
   Linux version 2.2.17 (root@hypercube) (gcc version 2.95.2 2220
(Debian GNU/Linux)) #20 Mon Sep 25 01:09:51 EDT 2000
--
Maestro Driver feedback and info:

maestro: Configuring ESS Maestro 2E found at IO 0x1400 IRQ 5
maestro:  subvendor id: 0x00cc1028
maestro: PCI power managment capability: 0x7622
maestro: AC97 Codec detected: v: 0x83847609 caps: 0x6940 pwr: 0xf
maestro: 1 channels configured.

--
/proc/pci

  Bus  0, device   8, function  0:
Multimedia audio controller: Unknown vendor Unknown device (rev 16).
  Vendor id=125d. Device id=1978.
  Medium devsel.  Fast back-to-back capable.  IRQ 5.  Master Capable.
Laten
cy=64.  Min Gnt=2.Max Lat=24.
  I/O at 0x1400 [0x1401].






--
No DVD movie will ever enter the public domain, nor will any CD. The last CD
and the last DVD will have moldered away decades before they leave copyright.
This is not encouraging the creation of knowledge in the public domain.


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

race condition on looking up inodes

[warren]

Hi,
I had post a simillar message before.
Thanks for the replay from Albert D. Cahalan. But i found some results
confusing me.
For example,  process 1 and process 2 run concurrently and execute the
following system calls.

rename("/usr/hybrid/cfg/data","/usr/mytemp/data1"); /*for process 1*/

   

  rename("/usr/mytemp/data1","/usr/test");/* for process 2*/

  
  It is possible that context switch happens when process 1 is look ing up
the inode for "/usr/mytemp/data1"  or the inode for "/usr/hybrid/cfg/data".

 It will result in diffrent behaviour for process 2 and confuses the
application.
  If so,how does Linux solve?

  Thanks.


Warren

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

user-mode port 0.40-2.4.3

[Jeff Dike]

The user-mode port of 2.4.3 is available.

Added --help and --version, which do the obvious things

UML now creates a /tmp/uml/ pid file.  The name can be set with the 
'-umid=' switch.  This is intended to make it easier for a UI to control 
a number of virtual machines.  There is a more general interface coming which 
will replace the pid file with a socket to a low-level console inside UML.

Fixed several major crashes and numerous smaller bugs.  The major fixes 
required some surgery from which UML still hasn't totally recovered, so it's 
still a bit wobbly.  In particular, if it swaps, processes will start 
segfaulting, and the swap code will start spitting out various 
frightening-sounding messages.

A number of hostfs bugfixes and cleanup.  One major new feature here - hostfs 
can now be the root filesystem.  This is done by assigning a directory to a 
ubd device, i.e. 'ubd0=/path/to/uml/root'.  A little bit of magic will cause 
this to be mounted as a hostfs filesystem.  Requirements: hostfs compiled into 
the kernel, /etc/fstab in that filesystem must have the / fs type as hostfs, 
you (the user running UML) must own all the files (they will be magically 
owned by root inside the virtual machine).

modify_ldt is now implemented.

/proc/cmdline is now right.

gdb automatically gets breakpoints set on panic and BUG.

The project's home page is http://user-mode-linux.sourceforge.net

Downloads are available at http://sourceforge.net/project/filelist.php?group_id
=429 and ftp://ftp.nl.linux.org/pub/uml/

Jeff


-
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: rw_semaphores

[Linus Torvalds]

On Sun, 8 Apr 2001, Andrew Morton wrote:
>
> One issue with the current implementation is the (necessary)
> design where one reader (or writer) is sleeping in
> down_x_failed_biased(), with its bias in place, whereas
> all other sleepers are sleeping in down_x_failed(), with
> their bias not in place.

Why not do this the same way the _real_ semaphores do it?

You have a fast-path that has a single integer, and a slow path which has
more state but and protected by a spinlock. The _only_ worry I see is to
make sure that we properly have a "contention" state, because both readers
and writers need to be able to know when they should wake things up. But
there's a _trivial_ contention state. Read on:

Forget about the BIAS stuff, and go back to the old simple "negative is
writer, positive is reader" implementation:

0   - unlocked
1..n- 1-n readers
0xc000  - writer
other <0- contention

Do you see anything wrong with this?

Implementation:

 - fast path:

down_read:
lock incl (%sem)
js __down_read_failed

down_write:
xorl %eax,%eax
movl $0xc000,%r
lock cmpxchgl %r,(%sem)
jne __down_write_failed

up_read:
lock decl (%sem)
js __up_read_wakeup

up_write:
lock andl $0x3fff,(%sem)
jne __up_write_wakeup

The above are all fairly obvious for the non-failure case, agreed?
Including the guarantee that _if_ there is contention, the "up()"
routines will always go to the slow path to handle the contention.

Now, the _slow_ case could be your generic "protected by a spinlock" code,
although I have a suggestion. As follows:

The only half-way "subtle" case is that __down_write_failed needs to make
sure that it marks itself as a contender (the down_read() fast-case code
will have done so already by virtue of incrementing the counter, which is
guaranteed to have resulted in a "contention" value.

While down_read() automatically gets a "contention value" on failure,
"down_write()" needs to do extra work. The extra work is not all that
expensive: the simplest thing is to just do

subl $0x8000,(%sem)

at the beginning - which will cause a "contention" value regardless of
whether it was pure-reader before (it goes negative by the simple
assumption that there will never be more than 32k concurrent readers), or
whether it was locked by a writer (it stays negative due to the 0x4000
bit in the write lock logic). In both cases, both a up_write() and a
up_read() will notice that they need to handle the contention of a waiting
writer-to-be.

Would you agree that the above fast-path implementation guarantees that we
always get to the spinlock-protected slow path?

Now, the above _heavily_ favours readers. There's no question that the
above is unfair. I think that's ok. I think fairness and efficiency tend
to be at odds. But queuing theory shows that the faster you can get out of
the critical region, the smaller your queue will be - exponentially. So
speed is worth it.

Let's take an example at this point:

 - lock is zero

 - writer(1) gets lock: lock is 0xc000

 - reader(2) tries to get in: lock becomes 0xc001, synchronizes on
   spinlock.

 - another writer(3) tries to get in: lock becomes 0xbfff8001, synchronizes
   on spinlock.

 - writer(1) does up_write: lock becomes 0x3fff8001, != 0, so writer  decides
   it needs to wake up, and synchronizes on spinlock.

 - another reader(4) comes on on another CPU, increments, and notices that
   it can do so without it being negative: lock becomes 0x3fff8002 and
   this one does NOT synchronize on the spinlock.

End result: reader(4) "stole base" and actually got the lock without ever
seeing any contention, and we now have (1), (2) and (3) who are serialized
inside the spinlock.

So we get to what the serializers have to do, ie the slow path:

First, let's do the __up_read/write_wakeup() case, because that one is the
easy one. In fact, I think it ends up being the same function:

spin_lock(>lock);
wake_up(>waiters);
spin_unlock(>lock);

and we're all done. The only optimization here (which we should do for
regular semaphores too) is to use the same spinlock for the semaphore lock
and the wait-queue lock.

The above is fairly obviously correct, and sufficient: we have shown that
we'll get here if there is contention, and the only other thing that the
wakup could sanely do would possibly be to select which process to wake.
Let's not do that yet.

The harder case is __down_read/write_failed(). Here is my suggested
pseudo-code:

__down_write_failed(sem)
{
DECLARE_WAIT_QUEUE(wait, current);

lock subl $0x8000,(%sem)/* Contention marker */
spin_lock(>lock);
add_wait_queue_exclusive(>wait, );
 

Re: 8139too.c and 2.4.4-pre1 kernel burp

[Jeff Garzik]

Frank Jacobberger wrote:
> 
> Jeff,
> 
> I noticed the following on boot with 2.4.4-pre1:
> 
> kernel: eth0: Too much work at interrupt, IntrStatus=0x0001.
> 
> What is this saying to me :)

How often does this occur?  A lot, or just once or twice?

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

8139too.c and 2.4.4-pre1 kernel burp

[Frank Jacobberger]

Jeff,

I noticed the following on boot with 2.4.4-pre1:

kernel: eth0: Too much work at interrupt, IntrStatus=0x0001.

What is this saying to me :)

Thanks,

Frank

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

[QUESTIONS] Transision from pcmcia-cs to 2.4 built-in PCMCIA

[Ryan Mack]

I have a 3c595 CardBus card and a Lucent Orinoco card

under pcmcia-cs I used the following drivers:

pcmcia_core, ds, and (I think) cs for low level stuff,
i82365 for the controller,
cb_enabler and 3c595_cb for the 3c595,
and wvlan_cs for the Orinoco

under the kernel pcmcia support, I use:

pcmcia_core and ds for low level stuff,
yenta_socket for the controller,
3c59x (same driver as PCI) for the 3c595,
and hermes and orinoco_cs for the Orinoco

Now after awhile I figured out what new drivers I should start using, but
I have a few things about the change that still confuse me...

First, why have I stopped needing cs and cb_enabler?

Second, why is yenta_socket only compiled if I enable CardBus support in
the kernel?  I'm running an Orinoco card on another machine, and since I
don't think it's CardBus (am I wrong?), I didn't enable CB in the kernel.
The i82365 driver is the only one compiled, but it seems to work fine on
that machine.  Should I enable CardBus support and use yenta_socket
instead?

Third, on the first machine with both cards, neither card works if I use
i82365 instead of yenta_socket, why?  The Orinoco gets Tx timeouts on
every packet, and inserting the 3c595 causes the controller (socket) to
time out waiting for reset and it doesn't recognize the 3c595.

Despite the confusion of changing systems, I must say that the orinoco
driver works much better than wvlan_cs for me, as the two Orinoco cards in
IBSS Ad-Hoc mode would get intermittent Tx timeouts with the wvlan_cs
driver.  It's also nice not to have to rebuild pcmcia-cs when I upgrade my
kernel anymore.  Keep up the good work!

Ryan

-
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.4-pre1 Unresolved symbols "strstr"

[Jeff Chua]

depmod version 2.4.5


Compiled 2.4.4-pre1 but running "depmod" generates a lot of these ...

depmod: *** Unresolved symbols in
/lib/modules/2.4.4-pre1/kernel/drivers/char/ltmodem.o
depmod: strstr
depmod: *** Unresolved symbols in
/lib/modules/2.4.4-pre1/kernel/drivers/char/serial.o
depmod: strstr
depmod: *** Unresolved symbols in
/lib/modules/2.4.4-pre1/kernel/drivers/ide/ide-cd.o
depmod: strstr
depmod: *** Unresolved symbols in
/lib/modules/2.4.4-pre1/kernel/drivers/ide/ide-mod.o
depmod: strstr
depmod: *** Unresolved symbols in
/lib/modules/2.4.4-pre1/kernel/drivers/ide/ide-probe-mod.o
depmod: strstr
depmod: *** Unresolved symbols in
/lib/modules/2.4.4-pre1/pcmcia/xirc2ps_cs.o
depmod: strstr


Thanks,
Jeff
[ [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: Zero Copy IO

[Douglas Gilbert]

"Alex Q Chen" <[EMAIL PROTECTED]> wrote:

> I am trying to find a way to pin down user space 
> memory from kernel, so that these user space buffer 
> can be used for direct IO transfer or otherwise 
> known as "zero copying IO".  Searching through the 
> Internet and reading comments on various news groups, 
> it would appear that most developers including Linus 
> himself doesn't believe in the benefit of "zero 
> copying IO".  Most of the discussion however was based 
> on network card drivers.  For certain other drivers 
> such as SCSI Tape driver, which need to handle great 
> deal of data transfer, it would seemed still be more
> advantageous to enable zero copy IO than copy_from_user() 
> and copy_to_user() all the data.  Other OS such as AIX 
> and OS2 have kernel functions that can be used to 
> accomplish such a task.  Has any ground work been done 
> in Linux 2.4 to enable "zero copying IO"?

Alex,
The kiobufs mechanism in the 2.4 series is the appropriate
tool for avoiding copy_from_user() and copy_to_user().
The definitive driver is in drivers/char/raw.c which
does synchronous IO to block devices such as disks
(but is probably not appropriate for tapes).

The SCSI generic (sg) driver supports direct IO. The driver
in lk 2.4.3 has the direct IO code commented out while
a version that I'm currently testing (sg 3.1.18 at
www.torque.net/sg) has its direct IO code activated. I have
a web page comparing throughput times and CPU utilizations
at http://www.torque.net/sg/rbuf_tbl.html . My testing
indicates that the kiobufs mechanism is now working
quite well. For various reasons I still think that it 
is best to default to indirect IO and let speed hungry
users enable dio (which is done in sg via procfs). Even 
when the user selects direct IO is should be possible to
fall back to indirect IO. [Sg does this when a SCSI
adapter can't support direct IO (e.g. an ISA adapter).]

Since the SCSI tape (st) driver is structurally similar 
to sg, it should be possible to add direct IO support 
to st.

One thing to note is that when you let the user provide
the buffer for direct IO (e.g. with malloc) then on
the i386 it won't be contiguous from a bus address POV.
This means large scatter gather lists (typically with
each element 4 KB on i386) which can be time consuming
to load on some SCSI adapters. One way around this would
be for a driver to provide "malloc/free" like ioctls.

Doug Gilbert
-
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] read/write semaphores

[Andrew Morton]

This is a new implementation.  After ~20 hours effort I couldn't get
the current x86 rwsem code to work.

This patch breaks all architechtures, but it's a good break and trivial
to fix.  It removes the `RW_LOCK_BIAS' arg in include/linux/sched.h:INIT_MM().

This code is architecture-independent.  It is intended (by me) that
all architectures dump their existing rwsem implementation and use
this one.  It creates include/linux/rw_semaphore.h and lib/rw_semaphore.c.
If other architectures are to use this implementation of rwsems then the
following must be done:

1: delete the existing rwsem code
2: in include/asm/semaphore.h, add:

#define ARCH_USES_GENERIC_RWSEM
#include 

It would be better to split rw_semaphore.h away from semaphore.h
altogether, but that's a lot of mangling.


There are several ways of designing rwsems.  This patch takes
a simple approach:

- If a writer wants the lock and it's free, grant.
- If a reader wants the lock and it's not held by a writer
  and there are no writers waiting for it, grant.
- when the lock is being released, and there are both
  readers and writers waiting on it, we grant it to
  writers.

So writers-starved-by-readers cannot occur.  This is because
new readers block when they see a writer is requesting the rwsem.

Writers *can* starve readers.  If a task is hammering away
on down_write()/up_write() then readers never manage to get
a hold of the semaphore.  Hopefully this won't be a problem.
It's fixable by introducing more state into the rwsem.

It is not legal to do an up_read() or up_write() from
interrupt context.  See the comments in rw_semaphore.c

It is not legal for one task to do more than one concurrent
down_read() on an rwsem.  You can't do:

down_read(sem);
...
down_read(sem);

because an intervening down_write() by another task will cause
deadlock.  See comments in rw_semaphore.c

Patches against 2.4.3-ac2 and 2.4.3 are attached.

There's some rwsem testing code at

http://www.uow.edu.au/~andrewm/linux/rwsem.tar.gz

which may be used to verify this patch.  rwsem-4.c is the
most useful.

-

--- linux-2.4.3-ac2/include/linux/sched.h   Tue Apr  3 21:47:31 2001
+++ ac/include/linux/sched.hSun Apr  8 15:47:54 2001
@@ -241,7 +241,7 @@
mm_users:   ATOMIC_INIT(2), \
mm_count:   ATOMIC_INIT(1), \
map_count:  1,  \
-   mmap_sem:   __RWSEM_INITIALIZER(name.mmap_sem, RW_LOCK_BIAS), \
+   mmap_sem:   __RWSEM_INITIALIZER(name.mmap_sem), \
page_table_lock: SPIN_LOCK_UNLOCKED,\
mmlist: LIST_HEAD_INIT(name.mmlist),\
 }
--- linux-2.4.3-ac2/include/linux/rw_semaphore.hThu Jan  1 00:00:00 1970
+++ ac/include/linux/rw_semaphore.h Sun Apr  8 15:43:14 2001
@@ -0,0 +1,136 @@
+/*
+ * include/linux/rw_semaphore.h
+ *
+ * An implementation of many reader/one writer sleeping locks
+ *
+ * 08Apr01 Andrew Morton <[EMAIL PROTECTED]>
+ * Created
+ */
+
+#ifdef __KERNEL__
+
+#ifndef __RW_SEMAPHORE_H_INCLUDED
+#define __RW_SEMAPHORE_H_INCLUDED
+
+#ifdef ARCH_USES_GENERIC_RWSEM
+
+//#define DEBUG_RWSEM  /* See lib/rw_semaphore.c */
+
+struct rw_semaphore {
+   /*
+* lock protects the integer counter and the waitqueues.
+*/
+   spinlock_t  lock;
+   /*
+* The number of tasks which currently hold a write
+* lock or a read lock.  If -1, it is held by a writer.
+* If +N, it is held by N readers.  If 0 it is free.
+*/
+   int nr_holders;
+   /*
+* Waitqueues for readers and writers.  The writer queue
+* is exclusive.
+*/
+   wait_queue_head_t   writers_wait;
+   wait_queue_head_t   readers_wait;
+};
+
+#define __RWSEM_INITIALIZER(_name) \
+{  \
+   lock:   SPIN_LOCK_UNLOCKED, \
+   nr_holders: 0,  \
+   writers_wait:   __WAIT_QUEUE_HEAD_INITIALIZER((_name).writers_wait),\
+   readers_wait:   __WAIT_QUEUE_HEAD_INITIALIZER((_name).readers_wait),\
+}
+
+#define DECLARE_RWSEM(name) \
+   struct rw_semaphore name = __RWSEM_INITIALIZER(name)
+
+extern void down_write_wait(struct rw_semaphore *sem);
+extern void down_read_wait(struct rw_semaphore *sem);
+extern void rwsem_wake_up(wait_queue_head_t *wq);
+
+#ifdef DEBUG_RWSEM
+extern struct rw_semaphore *rwsem_to_monitor;
+extern void dump_rwsem(const char *msg, struct rw_semaphore *sem);
+#else
+#define dump_rwsem(msg, sem) do {} while (0)
+#endif
+
+static inline void init_rwsem(struct rw_semaphore *sem)
+{
+   spin_lock_init(>lock);
+   sem->nr_holders = 0;
+   init_waitqueue_head(>writers_wait);
+   init_waitqueue_head(>readers_wait);

RE: No USB under 2.4.3 and 2.4.3-ac?

[Sid Boyce]

I found that the SuSE 7.1 install didn't put "usbdevfs" in /etc/fstab
on the Athlon, the PIII has broken USB port hardware.
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: Sources of entropy - /dev/random problem for network servers

[Andi Kleen]

On Sun, Apr 08, 2001 at 11:46:21PM +0100, Alex Bligh - linux-kernel wrote:
> The following patch fixes eepro100.c - others can be
> patched similarly.

Problem is that it allows someone with sniffer access to your network to
make a pretty good estimate of your random pool. If you search the archives
there was a big discussion about it some months ago. Currently there is no
good solution, except for using add-on hardware that offers randomness 
(that can be as simple as a spare sound card with some noise input) 

-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: Zero Copy IO

[Andi Kleen]

On Sun, Apr 08, 2001 at 04:31:27PM -0700, Alex Q Chen wrote:
> I am trying to find a way to pin down user space memory from kernel, so
> that these user space buffer can be used for direct IO transfer or
> otherwise known as "zero copying IO".  Searching through the Internet and
> reading comments on various news groups, it would appear that most
> developers including Linus himself doesn't believe in the benefit of "zero
> copying IO".  Most of the discussion however was based on network card
> drivers.  For certain other drivers such as SCSI Tape driver, which need to
> handle great deal of data transfer, it would seemed still be more
> advantageous to enable zero copy IO than copy_from_user() and copy_to_user
> () all the data.  Other OS such as AIX and OS2 have kernel functions that
> can be used to accomplish such a task.  Has any ground work been done in
> Linux 2.4 to enable "zero copying IO"?

Yes, e.g. the raw io device does it using kiovecs. See 
drivers/char/raw.c,fs/iobuf.c et.al. 2.4+zerocopy networking also has a 
different implementation.
The raw.c implementation is not very efficient at the moment though,
mostly because of limitations in the block device layer (but that 
should be no problem for a direct tape driver) 
This work is also in the 2.2 kernels of most distributions.


-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: Sources of entropy - /dev/random problem for network servers

[Jeff Garzik]

Alex Bligh - linux-kernel wrote:
> The machine in question is locked in a data center (can't be
> the only one) and thus sees none of the former two. IDE Entropy
> comes from executed IDE commands. The disk is physically largely
> inactive due to caching. But there's plenty of network traffic
> which should generate IRQs.

Use a hardware random number generator if you need a lot of entropy. 
The i810 RNG driver and userspace tools at
http://sourceforge.net/project/gkernel/ provide an example for an
implementation, if your hardware is not i8xx.


> However, only 3 drivers in drivers/net actually set
> SA_SAMPLE_RANDOM when calling request_irq(). I believe
> all of them should.

No, because an attacker can potentially control input and make it
non-random.

Jeff


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

Zero Copy IO

[Alex Q Chen]

I am trying to find a way to pin down user space memory from kernel, so
that these user space buffer can be used for direct IO transfer or
otherwise known as "zero copying IO".  Searching through the Internet and
reading comments on various news groups, it would appear that most
developers including Linus himself doesn't believe in the benefit of "zero
copying IO".  Most of the discussion however was based on network card
drivers.  For certain other drivers such as SCSI Tape driver, which need to
handle great deal of data transfer, it would seemed still be more
advantageous to enable zero copy IO than copy_from_user() and copy_to_user
() all the data.  Other OS such as AIX and OS2 have kernel functions that
can be used to accomplish such a task.  Has any ground work been done in
Linux 2.4 to enable "zero copying IO"?

Thanks in advance for any suggestions or comments

Sincerely,
Alex Chen

IBM SSD Device Driver Development
Office: 9000 S. Rita Rd 9032/2262
Email: [EMAIL PROTECTED]
Phone: (external) 520-799-5212 (Tie Line) (321)-5212

-
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: build -->/usr/src/linux

[Jamie Lokier]

Miquel van Smoorenburg wrote:
> .. but there should be a cleaner way to get at the CFLAGS used
> to compile the kernel.

There is a way though I'd not call it clean.  Here is an extract from
the Makefile I am using for separately-distributed modules.  It should
work with kernels 2.0 to 2.4, all supported architectures.

include $(KERNEL_SOURCE)/.config

CPPFLAGS := -DMODULE -D__KERNEL__ -nostdinc -I$(KERNEL_SOURCE)/include
CPPFLAGS += -I$(shell gcc -print-file-name=include)
CFLAGS   := $(CPPFLAGS) -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
AFLAGS   := -D__ASSEMBLY__ $(CPPFLAGS)

# For older kernels.
ifneq (,$(strip $(shell grep '^[]*SMP[  ]*:\?=[ ]*[^]' 
$(KERNEL_SOURCE)/Makefile)))
CONFIG_SMP=y
endif
ifdef CONFIG_SMP
CFLAGS += -D__SMP__
AFLAGS += -D__SMP__
endif

include $(KERNEL_SOURCE)/arch/$(ARCH)/Makefile

CFLAGS += $(shell if $(CC) -fno-strict-aliasing -S -o /dev/null -xc /dev/null 
>/dev/null 2>&1; then echo "-fno-strict-aliasing"; fi)
-
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/

Sources of entropy - /dev/random problem for network servers

[Alex Bligh - linux-kernel]

In debugging why my (unloaded) IMAP server takes many seconds
to open folders, I discovered what looks like a problem
in 2.4's feeding of entropy into /dev/random. When there
is insufficient entropy in the random number generator,
reading from /dev/random blocks for several seconds. /dev/random
is used (correctly) for crytographic key verification.

Entropy comes from 4 sources it seems: Keyboard, Mouse, Disk I/O
and IRQs.

The machine in question is locked in a data center (can't be
the only one) and thus sees none of the former two. IDE Entropy
comes from executed IDE commands. The disk is physically largely
inactive due to caching. But there's plenty of network traffic
which should generate IRQs.

However, only 3 drivers in drivers/net actually set
SA_SAMPLE_RANDOM when calling request_irq(). I believe
all of them should. And indeed this fixed the problem for
me using an eepro100().

The following patch fixes eepro100.c - others can be
patched similarly.

--
Alex Bligh

/usr/src/linux# diff -C3 drivers/net/eepro100.c{.keep,}
*** drivers/net/eepro100.c.keep Tue Feb 13 21:15:05 2001
--- drivers/net/eepro100.c  Sun Apr  8 22:17:00 2001
***
*** 923,929 
sp->in_interrupt = 0;

/* .. we can safely take handler calls during init. */
!   retval = request_irq(dev->irq, _interrupt, SA_SHIRQ, 
dev->name, dev);
if (retval) {
MOD_DEC_USE_COUNT;
return retval;
--- 923,929 
sp->in_interrupt = 0;

/* .. we can safely take handler calls during init. */
!   retval = request_irq(dev->irq, _interrupt, SA_SHIRQ | 
SA_SAMPLE_RANDOM, dev->name, dev);
if (retval) {
MOD_DEC_USE_COUNT;
return retval;

[ENDS]
-
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: davidel@xmailserver.org [Fwd: Returned mail: see transcript for details]

[David]

Your email address seems to be broken ;)

I tried from different networks.

rcpt to:<[EMAIL PROTECTED]>
550 Relay denied

-d




The original message was received at Sun, 8 Apr 2001 14:48:51 -0700
from [EMAIL PROTECTED] [208.179.59.198]

   - The following addresses had permanent fatal errors -
<[EMAIL PROTECTED]>
(reason: 550 Relay denied)

   - Transcript of session follows -
... while talking to host1.xmailserver.org.:
>>> DATA
<<< 550 Relay denied
550 5.1.1 <[EMAIL PROTECTED]>... User unknown
<<< 503 Bad sequence of commands


Reporting-MTA: dns; james.kalifornia.com
Arrival-Date: Sun, 8 Apr 2001 14:48:51 -0700

Final-Recipient: RFC822; [EMAIL PROTECTED]
Action: failed
Status: 5.1.1
Remote-MTA: DNS; host1.xmailserver.org
Diagnostic-Code: SMTP; 550 Relay denied
Last-Attempt-Date: Sun, 8 Apr 2001 15:00:03 -0700



Most MTAs already have capabilities developed to grant or revoke relay 
access based upon IP or host mask.

-d

Davide Libenzi wrote:

> I had the same problem of shifting down along the mail chain the knowledge of
> the incoming IP address.
> We develop VirusScreening and ContentFiltering MTA ( and appliances ) that
> usually goes in front of customers MTA.
> By putting our MTA in front of the customer MTAs chain We hide the peer IP
> address to MTAs that comes next in the mail chain.
> Our MTA uses a new ESMTP command :
> 
> XRMTIP remote-ip-address
> 
> to let customers MTA to know the remote IP address and let them to take all
> relay and generic permissions decisions about the mail path.
> We're going to distribute patches for most common MTAs like qmail, sendmail,
> exim, XMail and postfix.
> The patch rely on the presence of a file ( /etc/xrmtip.hosts ) that list the IPs
> from which the XRMTIP command sould be accepted.

Re: goodbye

[David Woodhouse]

On Sun, 8 Apr 2001, Rogier Wolff wrote:

> SMTP receivers should have the option of inserting a header line
> instead of blocking "bad" Emails. Then other layers can decide what to
> do with this Email.

http://www.exim.org/exim-html-3.20/doc/html/spec_46.html#SEC810

rbl_domains = dul.maps.vix.com/warn

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

cpu binding bug?

[Manfred Spraul]

Afaics cpu bindings could allow a thread to run with an "unlimited"
timeslice.

cpu0: one thread running with 'nice==19'.
NICE_TO_TICKS==1.

cpu1: lots of other threads with 'nice==0' (NICE_TO_TICKS==6)

cpu0 will enter schedule() every tick.
can_schedule() returns '0' for all threads bound to cpu1, thus
'recalculate' will be called every tick - that's faster than the threads
on cpu1 can use up their slice.
The currently running thread will run forever.

Is that problem fixed in the patches that allow user space to write
cpus_allowed?

--
Manfred
-
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: build -->/usr/src/linux

[Miquel van Smoorenburg]

In article <[EMAIL PROTECTED]>,
Marvin Stodolsky  <[EMAIL PROTECTED]> wrote:
>Thanks for responding.  But I would still like to understand what the
>functionality is of the build --> /usr/src/linuc.  Is it dispensable,
>once the module tree has been installed? 

It's needed for modules that are distributed sperately, so that
they can use cc -I /lib/modules/`uname -r`/build/include

Or even

l=`pwd`
cd /lib/modules/`uname -r`/build
make $l/module.o

.. but there should be a cleaner way to get at the CFLAGS used
to compile the kernel.

Mike.

-
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] Re: softirq buggy

[Manfred Spraul]

I've attached a new patch:

* cpu_is_idle() moved to 
* function uninlined due to header dependencies
* cpu_is_idle() doesn't call do_softirq directly, instead the caller
returns to schedule()
* cpu_is_idle() exported for modules.
* docu updated.

I'd prefer to inline cpu_is_idle(), but optimizing the idle code path is
probably not that important ;-)

--
Manfred

// $Header$
// Kernel Version:
//  VERSION = 2
//  PATCHLEVEL = 4
//  SUBLEVEL = 3
//  EXTRAVERSION = -ac3
--- 2.4/include/linux/pm.h  Thu Jan  4 23:50:47 2001
+++ build-2.4/include/linux/pm.hSun Apr  8 21:02:02 2001
@@ -186,6 +186,8 @@
 extern void (*pm_idle)(void);
 extern void (*pm_power_off)(void);
 
+int cpu_is_idle(void);
+
 #endif /* __KERNEL__ */
 
 #endif /* _LINUX_PM_H */
--- 2.4/kernel/sched.c  Sat Apr  7 22:02:27 2001
+++ build-2.4/kernel/sched.cSun Apr  8 21:02:37 2001
@@ -1242,6 +1242,28 @@
sched_data->last_schedule = get_cycles();
 }
 
+/**
+ * cpu_is_idle - helper function for idle functions
+ * 
+ * pm_idle functions must call this function to verify that
+ * the cpu is really idle.
+ * The return value is valid until local interrupts are
+ * reenabled.
+ * Return values:
+ * 1: go into power saving mode.
+ * 0: cpu is not idle, return to schedule()
+ */
+int cpu_is_idle(void)
+{
+   if (current->need_resched)
+   return 0;
+
+   if (softirq_active(smp_processor_id()) & softirq_mask(smp_processor_id()))
+   return 0;
+
+   return 1;
+}
+
 extern void init_timervecs (void);
 
 void __init sched_init(void)
--- 2.4/kernel/ksyms.c  Sat Apr  7 22:02:27 2001
+++ build-2.4/kernel/ksyms.cSun Apr  8 21:42:48 2001
@@ -440,6 +440,7 @@
 #endif
 EXPORT_SYMBOL(kstat);
 EXPORT_SYMBOL(nr_running);
+EXPORT_SYMBOL(cpu_is_idle);
 
 /* misc */
 EXPORT_SYMBOL(panic);
--- 2.4/arch/i386/kernel/process.c  Thu Feb 22 22:28:52 2001
+++ build-2.4/arch/i386/kernel/process.cSun Apr  8 21:25:23 2001
@@ -81,7 +81,7 @@
 {
if (current_cpu_data.hlt_works_ok && !hlt_counter) {
__cli();
-   if (!current->need_resched)
+   if (cpu_is_idle())
safe_halt();
else
__sti();
@@ -105,13 +105,10 @@
 */
oldval = xchg(>need_resched, -1);
 
-   if (!oldval)
-   asm volatile(
-   "2:"
-   "cmpl $-1, %0;"
-   "rep; nop;"
-   "je 2b;"
-   : :"m" (current->need_resched));
+   if (!oldval) {
+   while(cpu_is_idle())
+   rep_nop();
+   }
 }
 
 /*
@@ -131,7 +128,7 @@
void (*idle)(void) = pm_idle;
if (!idle)
idle = default_idle;
-   while (!current->need_resched)
+   while (cpu_is_idle())
idle();
schedule();
check_pgt_cache();
--- 2.4/drivers/acpi/cpu.c  Sat Apr  7 22:02:01 2001
+++ build-2.4/drivers/acpi/cpu.cSat Apr  7 23:55:17 2001
@@ -148,7 +148,7 @@
unsigned long diff;

__cli();
-   if (current->need_resched)
+   if (!cpu_is_idle())
goto out;
if (acpi_bm_activity())
goto sleep2;
@@ -171,7 +171,7 @@
unsigned long diff;
 
__cli();
-   if (current->need_resched)
+   if (!cpu_is_idle())
goto out;
if (acpi_bm_activity())
goto sleep2;
@@ -205,7 +205,7 @@
unsigned long diff;
 
__cli();
-   if (current->need_resched)
+   if (!cpu_is_idle())
goto out;
 
time = acpi_read_pm_timer();
@@ -235,7 +235,7 @@
unsigned long diff;
 
__cli();
-   if (current->need_resched)
+   if (!cpu_is_idle())
goto out;
time = acpi_read_pm_timer();
acpi_c1_count++;

Re: All processes hung under 2.4.3

[Disconnect]

Althought I was unable to do any debugging, I found the same thing earlier
today.  Syslog showed everything normal (uptimed reports, MARK, etc) and
ctrl-sysrq worked, but it had frozen hard.  I was using xlock, and it was
stopped in the middle of an opengl saver.  I had suspected it was related
to the nvidia drivers (I just got AGP enabled yesterday) but this looks a
lot like what I was seeing.

(On a side note, does anyone know if the K7 optimizations have been fixed
for those of us using the KK266 mobo?)

On Sun, 08 Apr 2001, Steven Walter did have cause to say:

> Earlier today, I tried to unlock xscreensaver on my desktop.  After
> typing in the password, it said "Checking..." and then hung.  In
> response, I hit Ctrl+Alt+Bksp, which killed X.  However, gdm did not
> restart X.  I tried logging in on the console, but none of them were
> responsive; characters would echo, but nothing else.
> 
> In hopes of finding the problem, I entered kdb, and did a bta.  All
> processes were hung in exactly the same spot, schedule+0x268!  This code
> is as follows:
> 
> 0xc0110d50 :jne0xc0110d7e 
> 0xc0110d52 :test   %eax,%eax
> 0xc0110d54 :jne0xc0110d72 
> 0xc0110d56 :mov0xffe4(%ecx),%edx
> 0xc0110d59 :test   %edx,%edx
> 0xc0110d5b :je 0xc0110d7e 
> 0xc0110d5d :mov0xfff0(%ecx),%eax
> 0xc0110d60 :cmp0xfff0(%ebp),%eax
> 0xc0110d63 :je 0xc0110d69 
> 0xc0110d65 :test   %eax,%eax
> 0xc0110d67 :jne0xc0110d6a 
> 0xc0110d69 :inc%edx
> 0xc0110d6a :add$0x14,%edx
> 0xc0110d6d :sub0x24(%esi),%edx
> 0xc0110d70 :jmp0xc0110d7e 
> 
> Additionally, I did a "ps" in kdb and found dozens of "cron" and "sh"
> started.  I suspect that these processes were somehow related to the
> lockup, as the machine should've been idle for hours, and no cron jobs
> were scheduled for the time.
> 
> The captured "bta" is availible if anyone is interested.  I don't know
> of a way to reproduce this offhand.
> -- 
> -Steven
> Freedom is the freedom to say that two plus two equals four.
> -
> 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/
---
   _.-==-._
| [EMAIL PROTECTED]| And Remember...
\  [EMAIL PROTECTED]  / He who controls Purple controls the Universe..
 PGP Key given on Request  Or at least the Purple parts!

-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P+>+++ L>+ 
E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)

[Martin Mares]

Hi Jeff!

> Is Martin still alive?  He hasn't been active in PCI development well
> over six months, maybe a year now.  Ivan (alpha hacker) appeared on the
> scene to fix serious PCI bridge bugs, DaveM has added some PCI DMA
> stuff, and I've added a couple driver-related things.  I haven't seen
> code from Martin in a long long time, and only a comment or two in
> recent memory.

I'm buried alive in mail, graph theory and several other projects,
so I'm now happy I'm able to at least keep track of kernel development
and answer some bug reports, but I hope it will get better soon.
If it won't, I'll probably have to pass the maintainer's sceptre
to someone less busy, but I'd rather like to avoid it as I still like
the PCI world very much though it's got somewhat messy these days.
 
> > --- linux-2.4.3-orig/include/linux/pci.hWed Apr  4 19:46:49 2001
> > +++ linux/include/linux/pci.h   Sat Apr  7 20:01:51 2001
> > @@ -454,6 +454,9 @@
> > void (*remove)(struct pci_dev *dev);/* Device removed (NULL if not a 
>hot-plug capable driver) */
> > void (*suspend)(struct pci_dev *dev);   /* Device suspended */
> > void (*resume)(struct pci_dev *dev);/* Device woken up */
> > +   int multifunction_quirks;   /* Quirks for PCI serial+parport 
>cards,
> > +   here multiple drivers are 
>allowed to register
> > +   for the same pci id match */
> >  };

This is incredibly ugly. IMHO the right solution is to add a driver for
each such multi-function device which will split the device to two virtual
devices as Linus has suggested, or maybe better to add a generic driver
doing such splitting for multiple similar multi-function cards.

Have a nice fortnight
-- 
Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/
bug, n: A son of a glitch.
-
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/

PROBLEM: kernel oops in reiserfs under 2.4.2-ac28 and 2.4.3-ac3 when rming files

[xOr]

[1.] kernel oops in reiserfs under 2.4.2-ac28 and 2.4.3-ac3 when rming files
[2.] when removing a directory on my harddrive with rm -rf, i get this oops. 
it occurs every time i try, and only on this one folder (so far). its 
actually in a subdirectory of the folder, im guessing at one file, but i feel 
it wouldnt help much to find the exact file (and that would require about 100 
reboots). i also get a segfault, though not a kernel oops when running 
reiserfsck on the filesystem.
[3.] reiserfs, kernel
[4.] Linux version 2.4.3-ac3 (root@rogue) (gcc version 2.95.3 20010315 
(release)) #2 
[5.] ksymoops output:
Unable to handle kernel NULL pointer dereference at virtual address 0008
Oops: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010293
eax: 1000   ebx: c7995b0b   ecx: c7995b40   edx: 
esi: 83cd   edi: c7ef0018   ebp: c7980210   esp: c642fa68
ds: 0018   es: 0018   ss: 0018
Process rm (pid: 138, stackpage=c642f000)
Stack: c7ef0018 1000 0016 0016  c7995b40  c78fa740
    c642fcdc 0030 0016 c7f08cc0 c0164ce7 c642fb14 c7995b40
   0001  c642fb14 c642fb04  0016 c0164f34 c642fb14
Call Trace: [] [] [] [] [] 
[] []
   [] [] [] [] [] 
[] [] []
   [] [] [] []
Code: 8b 42 08 ff d0 83 c4 08 85 c0 75 0b 31 c0 e9 9a 03 00 00 8d

>>EIP; c0164149<=
Trace; c0164ce7 
Trace; c0164f34 
Trace; c0164ffb 
Trace; c0155023 
Trace; c0155084 
Trace; c015fbeb 
Trace; c015ffd3 
Trace; c0160401 
Trace; c0157915 
Trace; c0169c84 
Trace; c016a007 
Trace; c016a3bc 
Trace; c01698c3 
Trace; c0159b28 
Trace; c01411be 
Trace; c013fd4c 
Trace; c0139b69 
Trace; c0139c47 
Trace; c0106e43 Before first symbol
Code;  c0164149 
 <_EIP>:
Code;  c0164149<=
   0:   8b 42 08  mov0x8(%edx),%eax   <=
Code;  c016414c 
   3:   ff d0 call   *%eax
Code;  c016414e 
   5:   83 c4 08  add$0x8,%esp
Code;  c0164151 
   8:   85 c0 test   %eax,%eax
Code;  c0164153 
   a:   75 0b jne17 <_EIP+0x17> c0164160 

Code;  c0164155 
   c:   31 c0 xor%eax,%eax
Code;  c0164157 
   e:   e9 9a 03 00 00jmp3ad <_EIP+0x3ad> c01644f6 

Code;  c016415c 
  13:   8d 00 lea(%eax),%eax
[6.] the command that causes it is:  `rm -rf /root/wine-directx`  its a wine 
source tree. tho any kind of access into the directory seems to screw me. for 
example a cvs update also does the same.
[7.1.] software:
Linux rogue 2.4.3-ac3 #2 Sun Apr 8 04:23:40 CDT 2001 i686 unknown
 
Gnu C  2.95.3
Gnu make   3.79
binutils   2.10.1
util-linux 2.11a
mount  2.11a
modutils   2.4.4
e2fsprogs  1.18
reiserfsprogs  3.x.0b
pcmcia-cs  3.1.16
PPP2.4.0
Linux C Library2.2.2
Dynamic linker (ldd)   2.2.2
Procps 2.0.6
Net-tools  1.59
Kbd0.99
Sh-utils   2.0
Modules Loaded interact ns558 gameport hid joydev input NVdriver 
3c59x emu10k1 ac97_codec nls_cp437 vfat fat
[7.2.] processor:
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 4
model name  : AMD Athlon(tm) Processor
stepping: 2
cpu MHz : 807.205
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips: 1608.90
[7.3.] modules:
interact2528   0 (unused)
ns558   2176   0 (unused)
gameport1344   0 [interact ns558]
hid11696   0 (unused)
joydev  5568   0 (unused)
input   3072   0 [interact hid joydev]
NVdriver  625584  12
3c59x  23680   1
emu10k139280   1 (autoclean)
ac97_codec  7536   0 (autoclean) [emu10k1]
nls_cp437   4384   1 (autoclean)
vfat8592   1 (autoclean)
fat29280   0 (autoclean) [vfat]
[7.4.] loaded driver/hardware info
-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0376-0376 : ide1
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(auto)
0cf8-0cff : PCI conf1
8000-803f : Promise Technology, Inc. 20265
  8000-8007 : ide2
  8008-800f : ide3
  8010-803f : PDC20265
8400-8403 : Promise Technology, Inc. 20265
8800-8807 : Promise Technology, Inc. 20265
9000-9003 : Promise Technology, Inc. 20265
9400-9407 : Promise Technology, Inc. 

Re: mouse problems in 2.4.2 -> lost byte -> Patch(2.4.3)!

[Gunther Mayer]

Original Problem: PS/2 mouse pointer goes upper right corner and stays there.
Diagnosis: one byte was lost and this is fatal for the mouse driver.

Various people wrote:
> 
> On Wed, Mar 28, 2001 at 05:19:33PM -0600, [EMAIL PROTECTED] wrote:
..
> > > > > > > I am experiencing debilitating intermittent mouse problems & was about
> > > > > >
> > > > > > This is easily explained: some byte of the mouse protocol was lost.
> 
> Plus, it's very likely the new PS/2 code will break on some systems that
> have not-so-compatible i8042 chips, so it is really something that can't


Losing bytes on psaux is a bug!

We must first understand, how bytes can be lost (most probable first):
- transmission error on the line can easily happen in noisy environments
   and is _not_ handled correctly by linux (i.e. should do RESEND)
- 0xAA is always handled as reconnect, if the mouse generates this byte,
   Linux will de-sync the mouse driver
- Mouse is defective or keyboard controller defective
- An error in the linux kbd/mouse driver (e.g. triggered by X11<->console switching)

This patch printk's necessary information on the first 2 cases and
should be applied to the stable kernel, as this will help to resolve a severe bug !

Regards, Gunther

P.S.
These messages can be generated:
Apr  8 21:49:23 linux kernel: psaux: reconnect 0xAA detected
Apr  8 21:49:42 linux kernel: pc_keyb: mouse error (0x75), byte ignored(ff).
Apr  8 21:49:43 linux kernel: psaux: reconnect 0xAA detected


--- linux-2.4.3-orig/drivers/char/pc_keyb.c Wed Apr  4 19:46:42 2001
+++ linux/drivers/char/pc_keyb.cSun Apr  8 21:45:37 2001
@@ -404,6 +404,11 @@
mouse_reply_expected = 0;
}
else if(scancode == AUX_RECONNECT){
+   // Under normal operation most mice don't generate 0xAA.
+   // But, Other devices might be unusable with this policy.
+   //  (My mouse easily generates 0xAAs on rapid movements,
+   //   when set to 10 samples/sec.)
+   printk("psaux: reconnect detected(0xaa), sending AUX_ENABLE.\n");
queue->head = queue->tail = 0;  /* Flush input queue */
__aux_write_ack(AUX_ENABLE_DEV);  /* ping the mouse :) */
return;
@@ -420,6 +425,9 @@
kill_fasync(>fasync, SIGIO, POLL_IN);
wake_up_interruptible(>proc_list);
}
+   else
+   // 2K buffer is enough for about 10 sec under normal 
+operations, here.
+   printk("psaux: buffer overflow, byte dropped.\n");
}
 #endif
 }
@@ -465,6 +473,11 @@
else
handle_keyboard_event(scancode);
}
+   else
+   // Fixme: Ignoring bytes will de-sync mouse protocol.
+   printk("pc_keyb: %s error (0x%02x), byte ignored(%02x).\n",
+   (status & KBD_STAT_MOUSE_OBF)?"mouse":"kbd",status,scancode);
+
 
status = kbd_read_status();
}
 gmdiff-lx243-psaux-error-reporting

Re: goodbye

[Ben Ford]

john slee wrote:

> On Sat, Apr 07, 2001 at 07:07:20PM -0700, Colonel wrote:
> 
>> Some ISPs rely on crap software & OS to process email, and have other
> 
> 
> so you don't use those ISPs

Some people don't have a choice of ISPs.  Some people are lucky if they 
can even *get* dial-up.

-b



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

All processes hung under 2.4.3

[Steven Walter]

Earlier today, I tried to unlock xscreensaver on my desktop.  After
typing in the password, it said "Checking..." and then hung.  In
response, I hit Ctrl+Alt+Bksp, which killed X.  However, gdm did not
restart X.  I tried logging in on the console, but none of them were
responsive; characters would echo, but nothing else.

In hopes of finding the problem, I entered kdb, and did a bta.  All
processes were hung in exactly the same spot, schedule+0x268!  This code
is as follows:

0xc0110d50 :  jne0xc0110d7e 
0xc0110d52 :  test   %eax,%eax
0xc0110d54 :  jne0xc0110d72 
0xc0110d56 :  mov0xffe4(%ecx),%edx
0xc0110d59 :  test   %edx,%edx
0xc0110d5b :  je 0xc0110d7e 
0xc0110d5d :  mov0xfff0(%ecx),%eax
0xc0110d60 :  cmp0xfff0(%ebp),%eax
0xc0110d63 :  je 0xc0110d69 
0xc0110d65 :  test   %eax,%eax
0xc0110d67 :  jne0xc0110d6a 
0xc0110d69 :  inc%edx
0xc0110d6a :  add$0x14,%edx
0xc0110d6d :  sub0x24(%esi),%edx
0xc0110d70 :  jmp0xc0110d7e 

Additionally, I did a "ps" in kdb and found dozens of "cron" and "sh"
started.  I suspect that these processes were somehow related to the
lockup, as the machine should've been idle for hours, and no cron jobs
were scheduled for the time.

The captured "bta" is availible if anyone is interested.  I don't know
of a way to reproduce this offhand.
-- 
-Steven
Freedom is the freedom to say that two plus two equals four.
-
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: struct stat{st_blksize} for /dev entries in 2.4.3

[Ulrich Drepper]

Russell Coker <[EMAIL PROTECTED]> writes:

> diff -ru textutils-2.0/src/cat.c textutils-new/src/cat.c
> --- textutils-2.0/src/cat.c Sun Apr  8 22:55:10 2001
> +++ textutils-new/src/cat.c Sun Apr  8 23:23:54 2001
> @@ -790,6 +790,9 @@
>if (options == 0)
> {
>   insize = max (insize, outsize);
> +#ifdef _SC_PHYS_PAGES
> + insize = max (insize, sysconf(_SC_PAGESIZE));
> +#endif
>   inbuf = (unsigned char *) xmalloc (insize);
>  
>   simple_cat (inbuf, insize);

The #ifdef is certainly wrong.  And there is no guarantee that any of
the _SC_* constants are defined as macros.  You'll have to add a
configure test.

-- 
---.  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \,---'   \  Sunnyvale, CA 94089 USA
Red Hat  `--' drepper at redhat.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/

2.2.19: cross-compile patch for drivers/net/Makefile

[Philip Blundell]

Cross-compiles need to use the target linker here.

p.

--- linux/drivers/net/Makefile~ Sun Apr  8 17:48:31 2001
+++ linux/drivers/net/Makefile  Sun Apr  8 19:31:29 2001
@@ -1445,7 +1445,7 @@
rm -f core *.o *.a *.s
 
 wanpipe.o: $(WANPIPE_OBJS)
-   ld -r -o $@ $(WANPIPE_OBJS)
+   $(LD) -r -o $@ $(WANPIPE_OBJS)
 
 rcpci.o: rcpci45.o rclanmtl.o
$(LD) -r -o rcpci.o rcpci45.o rclanmtl.o


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

[Manfred Spraul]

From: <[EMAIL PROTECTED]>
To: "Manfred Spraul" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, April 08, 2001 7:58 PM
Subject: Re: softirq buggy [Re: Serial port latency]


> Hello!
>
> > But with a huge overhead. I'd prefer to call it directly from within
the
> > idle functions, the overhead of schedule is IMHO too high.
>
>
> + if (current->need_resched) {
> + return 0;
> 
> + }
> + if (softirq_active(smp_processor_id()) &
softirq_mask(smp_processor_id())) {
> + do_softirq();
> + return 0;
> ^
> You return one value in both casesand I decided it means "schedule".
8)
> Apparently you meaned return 1 in the first case. 8)
>
No, the code is correct. 0 means "don't stop the cpu".
The pm_idle function pointer will return to cpu_idle()
(arch/i386/kernel/process.c), and that function contains another

while(!current->need_resched)
idle();

loop ;-)

> But in this case it becomes wrong. do_softirq() can raise need_reshed
> and moreover irqs arrive during it. Order of check should be
different.
>
Yes, I'll correct that.

>
> BTW what's about overhead... I suspect it is _lower_ in the case
> of schedule(). In the case of networking at least, when softirq
> most likely wakes some socket.
>
I'm not sure - what if the computer is just a router?
But OTHO: the cpu is idle, so it doesn't matter at all if the idle cpu
spends it's time within schedule() or within safe_hlt(), I'll change my
patch.

I have another question:
I added cpu_is_idle() into . Is that acceptable, or
is there a better header file for such a function?

--
Manfred

-
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 Fri, Apr 06, 2001 at 07:13:21PM +0200, Maciej W. Rozycki wrote:
>  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. 

Of course. I meant that if you are reading, for example, some status register
in a loop waiting for "ready bit" set, the memory barrier won't help you
to notice this event any faster. Actually you'll notice that *later*, as
"mb" is expensive.

Well, here is some info on ev6 IO write buffers - they are a bit different
than ev4/ev5 ones.
Merging rules:
 - byte/word stores aren't allowed to merge into a write buffer;
 - different size stores (32- and 64-bit) aren't allowed to merge;
 - addresses must be in ascending order and non-overlapping,
   but not necessarily consecutive.
The I/O register merge window close (ie write-buffer flushing) occurs after
 - mb and wmb instructions;
 - IO-space load instruction (!);
 - after 1024 cycles if there were no IO-space stores.
Store requests are sent offchip in program order (!).

All this explains, in particular, why XFree86-4.0 worked on ev6 without
memory barriers of any kind, while it crashed badly on ev4/ev5.

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/

Re: softirq buggy [Re: Serial port latency]

[kuznet]

Hello!

> But with a huge overhead. I'd prefer to call it directly from within the
> idle functions, the overhead of schedule is IMHO too high.


+   if (current->need_resched) {
+   return 0;

+   }
+   if (softirq_active(smp_processor_id()) & softirq_mask(smp_processor_id())) {
+   do_softirq();
+   return 0;
^
You return one value in both casesand I decided it means "schedule". 8)
Apparently you meaned return 1 in the first case. 8)

But in this case it becomes wrong. do_softirq() can raise need_reshed
and moreover irqs arrive during it. Order of check should be different.


BTW what's about overhead... I suspect it is _lower_ in the case
of schedule(). In the case of networking at least, when softirq
most likely wakes some socket.

Alexey
-
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: goodbye

[Davide Libenzi]

On 08-Apr-2001 Rogier Wolff wrote:
> Matti Aarnio wrote:
>> On Sun, Apr 08, 2001 at 02:10:52PM +0900, [EMAIL PROTECTED] wrote:
>> > How about creating an additional ML,
>> > the new ML (say LKML-DUL) is used to send mails from DUL to LKML, but
>> > such mails are not sent to LMKL.
>> 
>>  Layering and technology problem.
>> 
>>  SMTP receiver does those RBL/DUL/ORBS analysis, and its policy
>>  control does not know where exactly the email is heading into
>>  (that is, the reception policy is system level, not by recipients.)
> 
> Then fix it!
> 
> SMTP receivers should have the option of inserting a header line
> instead of blocking "bad" Emails. Then other layers can decide what to
> do with this Email.

I had the same problem of shifting down along the mail chain the knowledge of
the incoming IP address.
We develop VirusScreening and ContentFiltering MTA ( and appliances ) that
usually goes in front of customers MTA.
By putting our MTA in front of the customer MTAs chain We hide the peer IP
address to MTAs that comes next in the mail chain.
Our MTA uses a new ESMTP command :

XRMTIP remote-ip-address

to let customers MTA to know the remote IP address and let them to take all
relay and generic permissions decisions about the mail path.
We're going to distribute patches for most common MTAs like qmail, sendmail,
exim, XMail and postfix.
The patch rely on the presence of a file ( /etc/xrmtip.hosts ) that list the IPs
from which the XRMTIP command sould be accepted.



- Davide

-
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: UDMA(66) drive coming up as UDMA(33)?

[Wilfried Weissmann]

"David St.Clair" wrote:
> 
> I'm trying to get my hard drive to use UDMA/66.  I'm thinking the cable
> is not being detected.  When the HPT366 bios is set to UDMA 4; using

I think that should be UDMA 5 for 66? As far as I can remember UDMA4 is 33MHz with 
S.M.A.R.T. which
add some reporting functionality. But I might be wrong...

> hdparm -t, I get a transfer rate of 19.51 MB/s. When the HPT366 bios is
> set to PIO 4 the transfer rate is the same. Is this normal for a UDMA/66
> drive? What makes me think something is wrong is that the log says
> 
> "ide2: BM-DMA at 0xbc00-0xbc07, BIOS settings: hde:pio" <-- PIO?
> 
> and
> 
> "hde: 27067824 sectors (13859 MB) w/371KiB Cache, CHS=26853/16/63,
> UDMA(33)" <--- UDMA(33)? shouldn't it be UDMA(66)?

I got (kernel 2.2.18):

HPT370: IDE controller on PCI bus 00 dev 98
HPT370: chipset revision 3
HPT370: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xe800-0xe807, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xe808-0xe80f, BIOS settings: hdc:DMA, hdd:pio

hda and hdc are my hd's. My mainboard is a Abit KT7-RAID.

> 
> Any ideas what might be wrong? Possible bug?

I would set the UDMA5 for the HDs in the HPT bios.

good luck,
Wilfried
-
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: build -->/usr/src/linux

[Marvin Stodolsky]

Russell

Thanks for responding.  But I would still like to understand what the
functionality is of the build --> /usr/src/linuc.  Is it dispensable,
once the module tree has been installed? 

Incidentally, per below, my own modutils is current, though some of the
folks using our ltmodem.o compiler/installer kits may indeed need to
update. 
> You need to update your modutils package - there have been a number of
> important bug fixes, including some which allow it to work properly with
> 2.4 kernels.

# insmod -V
insmod version 2.4.2
# grep " # " /usr/src/linux-2.4.3/Documentation/Changes
o  Gnu C  2.91.66 # gcc --version
o  Gnu make   3.77# make --version
o  binutils   2.9.1.0.25  # ld -v
o  util-linux 2.10o   # fdformat --version
o  modutils   2.4.2   # insmod -V
etc.

MarvS


> Russell King wrote:
> 
> On Sun, Apr 08, 2001 at 09:47:06AM -0500, Marvin Stodolsky wrote:
> > It's presence has required some gymnastics, per below, during module
> > installation for the Winmodem driver, ltmodem.o requiring a subsequent
> > "depmod -a"
> 
> You need to update your modutils package - there have been a number of
> important bug fixes, including some which allow it to work properly with
> 2.4 kernels.
> 
> --
> Russell King ([EMAIL PROTECTED])The developer of ARM Linux
>  http://www.arm.linux.org.uk/personal/aboutme.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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]

[Manfred Spraul]

From: <[EMAIL PROTECTED]>
> Hello!
>
> > + if (softirq_active(smp_processor_id()) &
softirq_mask(smp_processor_id())) {
> > + do_softirq();
> > + return 0;
>
> BTW you may delete do_softirq()... schedule() will call this.
>

But with a huge overhead. I'd prefer to call it directly from within the
idle functions, the overhead of schedule is IMHO too high.

>
> > + *
> > + * Isn't this identical to default_idle with the 'no-hlt' boot
> > + * option? <[EMAIL PROTECTED]>
>
> Seeems, it is not. need_resched=-1 avoids useless IPIs.
>
I already wondered why need_resched is set to -1 ;-)

I'll remove that comment and repost the patch.

--
Manfred

-
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: TCP stack misbehaviour?

[kuznet]

Hello!

> empty, except for occasional ACKs. The utilization of the channel is about 4%.

1. tcpdump is required.
2. exact vesion of used kernel is required too.

Alexey
-
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: new queuing discipline

[kuznet]

Hello!

> packet in the queue. No other conditions i found. But i need repeatedly test
> the top packet in the queue.
> 
> How to accomplish it?

Look into sch_tbf.c for example. Hint: timer.

Alexey
-
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]

[kuznet]

Hello!

> + if (softirq_active(smp_processor_id()) & softirq_mask(smp_processor_id())) {
> + do_softirq();
> + return 0;

BTW you may delete do_softirq()... schedule() will call this.


> + *
> + * Isn't this identical to default_idle with the 'no-hlt' boot
> + * option? <[EMAIL PROTECTED]>

Seeems, it is not. need_resched=-1 avoids useless IPIs.

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

kgdb for 2.4.3 kernels

[Amit S. Kale]

Hi,

OOPS! I sent a wrong mail earlier under the same subject.

Linux kernel source level debugger, kgdb for linux kernel 2.4.3
is available from http://kgdb.sourceforge.net/

This version has following improvements over kgdb for 2.4.2 kernels:
1. Changed #ifdef __SMP__ statements to #ifdef CONFIG_SMP. 
2. Removed EXTRAVERSION=-kgdb line from the Makefile. This had
caused change in the name of the kernel. It was inconvenient in some
setups. If name of the kernel was already changed, the patch would fail
at this line.

Regards.
--
Amit S. Kale
<[EMAIL PROTECTED]>
Linux kernel source level debuggerhttp://kgdb.sourceforge.net/
Translation filesystemhttp://trfs.sourceforge.net/
-
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: TCP stack misbehaviour?

[clock]

On Sun, Apr 08, 2001 at 06:07:55PM +0200, Manfred Spraul wrote:
> Could you add more details and post them to linux-kernel?
> 
> * which kernel version

2.2.18

> * both sides linux, or one side linux, the other one something else

both sides 2.2.18 linux

> * a tcpdump that shows the problem, preferably 2 dumps, from both sides
> of the cable
> 
> --
> Manfred
> 

-- 
Karel Kulhavy http://atrey.karlin.mff.cuni.cz/~clock
-
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: goodbye

[Joseph Carter]

On Sun, Apr 08, 2001 at 02:22:49PM +0100, David Woodhouse wrote:
> > ORBS ... well, they called one of my old ISPs' mail an open relay when
> > it wasn't and took 3 months to decide to rectify the situation and
> > remove us from their list.  That doesn't instill much confidence.
> 
> I've heard that accusation many times, and on investigation, on the 
> occasions I could be bothered, it's _always_ turned out to be false - 
> generally caused by cluelessness on the part of the reporter.
> 
> It's very easy for ISPs to get landed in ORBS by customers who use the
> outgoing relay for spam which they've wrongly accepted. The ISP's mail
> relay doesn't have to accept the mail from the outside world and blatantly
> forward it.

Ah, then every ISP in the world belongs on the ORBS list since they all
will indiscriminantly forward their users' mail to other people.  Of
course if someone uses them to deliver spam they usually don't get to keep
their account long, but it's our own fault for using a relay which has
been used to send spam right?

Let's see, ORBS takes out the ISP route, DUL takes out the direct one.  Is
it any wonder people are hostile toward those two lists?

-- 
Joseph Carter <[EMAIL PROTECTED]>Free software developer

 i'd solve a windows key problem with fdisk :)


 PGP signature

Re: build -->/usr/src/linux

[Russell King]

On Sun, Apr 08, 2001 at 09:47:06AM -0500, Marvin Stodolsky wrote:
> It's presence has required some gymnastics, per below, during module
> installation for the Winmodem driver, ltmodem.o requiring a subsequent
> "depmod -a"

You need to update your modutils package - there have been a number of
important bug fixes, including some which allow it to work properly with
2.4 kernels.

--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
 http://www.arm.linux.org.uk/personal/aboutme.html

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

build -->/usr/src/linux

[Marvin Stodolsky]

MODULE SUPPORT [GENERAL], KMOD
P:  Keith Owens
M:  [EMAIL PROTECTED]
L:  [EMAIL PROTECTED]


Though I've done some rational searching through the Documetation,
an explanation hasn't manifested, as to why there has appeared in the
2.4.nn   ??:


# ls -l /lib/modules/2.4.3/
total 24
lrwxrwxrwx1 root root  ???   20 Apr  2 17:00 build ->
/usr/src/linux-2.4.3
drwxr-xr-x6 root root 1024 Apr  2 17:00 kernel
-rw-r--r--1 root root 4725 Apr  8 08:06 modules.dep
-rw-r--r--1 root root   31 Apr  8 08:06
modules.generic_string
-rw-r--r--1 root root 4388 Apr  8 08:06
modules.isapnpmap
-rw-r--r--1 root root   29 Apr  8 08:06
modules.parportmap
-rw-r--r--1 root root 8723 Apr  8 08:06 modules.pcimap
-rw-r--r--1 root root 1317 Apr  8 08:06 modules.usbmap
lrwxrwxrwx1 root root   35 Apr  2 17:05 pcmcia ->
/lib/modules/2.4.3-oldpcmcia/pcmcia

---
Could someone enlighten me?  What is it necessary for?

It's presence has required some gymnastics, per below, during module
installation for the Winmodem driver, ltmodem.o requiring a subsequent
"depmod -a"

MarvS
===
from the module install script  ./ltinst

# To avoid non-relevant complaint noise that would be generated during
#depmod -a   within update-modules
# under 2.4.nn kernels due to the symbolic Link
#   /lib/modules/2.4.nn/build --> /usr/src/linux
# if kernel-source "make clean" is run betweem build_module & 
#   ltinst (install ltmodem.o in the /lib/modules/  tree)
# The Link is moved to  /tmp and after "update-modules" is  restored.
if [ -L /lib/modules/$SYS/build ]; then
mv /lib/modules/$SYS/build /tmp
fi

# Updating module dependancies
if [ -f /etc/modutils/aliases ]; then
update-modules
else
depmod -a
fi

# Restoring build link if any
if [ -L /tmp/build ]; then
mv /tmp/build /lib/modules/$SYS/
fi
-
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/

TCP stack misbehaviour?

[clock]

The TCP stack in the linux kernel behaves this way:

I have got a FULL-DUPLEX 28.800kbps channel with BER <= 1*10-9
a) I start a long TCP connection in one direction
b) After 5 minutes I start another connection in the opposite direction

The second connection rusn for about half a minute, then converges to 0
throughtput. After several minutes, another 30 seconds of transmission ocuur.
The data path in the direction that should be used for this connection is
empty, except for occasional ACKs. The utilization of the channel is about 4%.

I would expect that both channels would be used for at least 95%. Instead, only
one is used.

Is this a bug of Linux kernel TCP stack, or a bug in the algorithm presented
in the appropriate RFC?

Isn't UDP more suitable for data transfers?

-- 
Karel Kulhavy http://atrey.karlin.mff.cuni.cz/~clock
-
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/

[OPPS] 2.2.19

[James Stevenson]

Hi

i woke up to these this morning :(

ksymoops 2.3.4 on i686 2.2.19.  Options used
 -V (default)
 -k /proc/ksyms (specified)
 -L (specified)
 -o /lib/modules/2.2.19/ (default)
 -m /boot/System.map (specified)

No modules in ksyms, skipping objects
Unable to handle kernel paging request at virtual address d66e8454 
current->tss.cr3 = 01d6f000, %cr3 = 01d6f000 
*pde =  
Oops:  
CPU:0 
EIP:0010:[read_chan+0/1804] 
EFLAGS: 00010286 
eax: bfffe6f0   ebx: c74a6000   ecx: bfffe6f0   edx: c01c01e4 
esi: c6cdb720   edi: c0cc2188   ebp: 1000   esp: c1d67f84 
ds: 0018   es: 0018   ss: 0018 
Process gnome-terminal (pid: 898, process nr: 51, stackpage=c1d67000) 
Stack: c6cdb720 bfffe6f0 1000 c6cdb720 ffea  c0124e8e c6cdb720  
   bfffe6f0 1000 c6cdb734 c1d66000 08336290 bfffe6f0 b708 c0109394  
   0011 bfffe6f0 1000 08336290 bfffe6f0 b708 0003 c010002b  
Call Trace: [sys_read+174/196] [system_call+52/56] [startup_32+43/286]  
Code: 10 8b 54 24 24 0f ca 85 d2 75 05 31 d2 eb 0b 90 0f bc c2 ba  
Using defaults from ksymoops -t elf32-i386 -a i386

Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   10 8b 54 24 24 0f adc%cl,0xf242454(%ebx)
Code;  0006 Before first symbol
   6:   ca 85 d2  lret   $0xd285
Code;  0009 Before first symbol
   9:   75 05 jne10 <_EIP+0x10> 0010 Before first symbol
Code;  000b Before first symbol
   b:   31 d2 xor%edx,%edx
Code;  000d Before first symbol
   d:   eb 0b jmp1a <_EIP+0x1a> 001a Before first symbol
Code;  000f Before first symbol
   f:   90nop
Code;  0010 Before first symbol
  10:   0f bc c2  bsf%edx,%eax
Code;  0013 Before first symbol
  13:   ba 00 00 00 00mov$0x0,%edx

Unable to handle kernel paging request at virtual address f656 
current->tss.cr3 = 0588d000, %cr3 = 0588d000 
*pde =  
Oops: 0002 
CPU:0 
EIP:0010:[schedule+139/644] 
EFLAGS: 00010086 
eax: f61a   ebx: c06de000   ecx: 0002   edx: c06de068 
esi: c1684400   edi: c06de068   ebp: c06de04c   esp: c06de03c 
ds: 0018   es: 0018   ss: 0018 
Process glimmer (pid: 1003, process nr: 46, stackpage=c06dd000) 
Stack: c06de068 f61a 08162038 c1684400 c06de070 c0111021 c06de000 c06de000  
   f656 c06de000 c06de068 c06de000 c06de114 c06de0f8 c01d6e30 08162518  
   08162500  c01d8a05 c06de000 0002 c010e8b8 c06de0f8 08162258  
Call Trace: [__down+77/164] [__down_failed+8/12] [stext_lock+105/13764] 
[do_page_fault+0/944] [error_code+53/64] [schedule+139/644] [__down+77/164]  
Code: 89 50 3c c7 43 3c 00 00 00 00 c7 43 40 00 00 00 00 c7 43 14  

Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   89 50 3c  mov%edx,0x3c(%eax)
Code;  0003 Before first symbol
   3:   c7 43 3c 00 00 00 00  movl   $0x0,0x3c(%ebx)
Code;  000a Before first symbol
   a:   c7 43 40 00 00 00 00  movl   $0x0,0x40(%ebx)
Code;  0011 Before first symbol
  11:   c7 43 14 00 00 00 00  movl   $0x0,0x14(%ebx)

Unable to handle kernel NULL pointer dereference at virtual address 000f 
current->tss.cr3 = 0208c000, %cr3 = 0208c000 
*pde =  
Oops:  
CPU:0 
EIP:0010:[rpcauth_gc_credcache+48/152] 
EFLAGS: 00010202 
eax: ddd6   ebx:    ecx: c7f9af90   edx: 0007 
esi: c2331da4   edi: c7f9af80   ebp: 0004   esp: c2331d24 
ds: 0018   es: 0018   ss: 0018 
Process xscreensaver (pid: 821, process nr: 48, stackpage=c2331000) 
Stack: c7f9af80  c01a2edc c7f9af80 c7f9af80 c2331da4 c7a51500 c2331d9c  
   c01a2fe2 c7f9af80  c2331da4 c2331da4 c019d8be c2331da4   
   c019d7aa c2331da4 c2331e54  c2331da4 c7a51500    
Call Trace: [rpcauth_lookup_credcache+64/156] [rpcauth_bindcred+58/84] 
[rpc_call_setup+58/108] [rpc_call_sync+102/160] [rpc_run_timer+0/68] 
[nfs_proc_lookup+144/184] [nfs_lookup_revalidate+286/500]  
Code: 66 83 7a 08 00 75 1d a1 40 4c 20 c0 8b 72 04 29 c6 89 f0 85  

Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   66 83 7a 08 00cmpw   $0x0,0x8(%edx)
Code;  0005 Before first symbol
   5:   75 1d jne24 <_EIP+0x24> 0024 Before first symbol
Code;  0007 Before first symbol
   7:   a1 40 4c 20 c0mov0xc0204c40,%eax
Code;  000c Before first symbol
   c:   8b 72 04  mov0x4(%edx),%esi
Code;  000f Before first symbol
   f:   29 c6 sub%eax,%esi
Code;  0011 Before first symbol
  11:   89 f0 mov%esi,%eax
Code;  0013 Before first symbol
  13:   85 00 test   %eax,(%eax)

Unable to handle kernel NULL pointer 

Re: goodbye

[Rogier Wolff]

Matti Aarnio wrote:
> On Sun, Apr 08, 2001 at 02:10:52PM +0900, [EMAIL PROTECTED] wrote:
> > How about creating an additional ML,
> > the new ML (say LKML-DUL) is used to send mails from DUL to LKML, but
> > such mails are not sent to LMKL.
> 
>   Layering and technology problem.
> 
>   SMTP receiver does those RBL/DUL/ORBS analysis, and its policy
>   control does not know where exactly the email is heading into
>   (that is, the reception policy is system level, not by recipients.)

Then fix it!

SMTP receivers should have the option of inserting a header line
instead of blocking "bad" Emails. Then other layers can decide what to
do with this Email.

I really would like to run "ORBS" on my incoming-mail-server. However
I find it unacceptable to be rejecting Email from possibly legitimate
clients. So Adding an "relay is listed on orbs" line would allow me to
sort this into a low priority "probably spam" mailbox, just like I'd
do with those tagged as such by LKML.

After adding the header line, you could easily make majordomo do
special stuff with this Email, but having the header line probably
makes that unneccesary.

If you're willing to pay a small amount to make this happen, or if
you're willing to earn a few bucks by implementing this, stop by:

http://www.cosource.com/cgi-bin/cos.pl/wish/info/402
and http://www.cosource.com/cgi-bin/cos.pl/wish/info/403

Roger.

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
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/

struct stat{st_blksize} for /dev entries in 2.4.3

[Russell Coker]

When you stat() the files under /dev the st_blksize is returned as 1024 
bytes.  Currently cat will look at the input block size and the output block 
size and use the maximum of them as it's buffer size.  I believe that 
programs such as cat should never use a buffer size smaller than a page of 
memory and reported this as a bug in cat.
Herbert Xu (the maintainer of the Debian package textutils which contains 
cat) considers that the device should return a larger number in the 
st_blksize.

Here are some test results, first a P3-650 with 256M of RAM using a 300M 
partition of a 10G disk:
root@lyta:/#time cat /dev/ide/host0/bus0/target0/lun0/part1 > /dev/null
 
real0m37.959s
user0m0.220s
sys 0m4.910s
My patched cat uses 25% of the user CPU time and 90% the system CPU time of 
the unpatched cat:
root@lyta:/#time /usr/src/textutils-new/src/cat 
/dev/ide/host0/bus0/target0/lun0/part1 > /dev/null
 
real0m35.502s
user0m0.060s
sys 0m4.440s

Now here's an AMD K6-350 with 64M of RAM using a 2G RAID-1 partition across 
two 46G disks:
root@ivanova:~#time cat /dev/md/1 > /dev/null
 
real2m25.906s
user0m2.200s
sys 1m16.290s

My patched cat uses 30% the user CPU time and 95% the system CPU time:
root@ivanova:~#time /tmp/cat /dev/md/1 > /dev/null
 
real2m14.845s
user0m0.720s
sys 1m12.030s


On an AMD Athlon 800 machine I noticed an even more significant difference 
(the command "cat /dev/zero > /dev/hdc1" was using 100% CPU time but the disk 
was not at maximum speed before I patched cat).  But I don't have suitable 
test results with me at this time so I can't give you the details.  Another 
issue is that an Athlon 800 is a reasonably fast CPU, and it should probably 
be able to handle 33000 reads and 33000 writes per second easily without 
using any significant amount of CPU time.


Now I would like some comments on the following issues:
Is this a bug in cat regardless of whether the behaviour of the kernel is 
right or wrong?  I have attached a patch for cat in case it is determined 
that cat is buggy.


Regardless of whether cat is doing the right thing or not, does it make sense 
for the st_blksize of /dev/* to be 1024 bytes?  Or should it be 4096?

My understanding is that the st_blksize is the recommended IO size (not 
mandatory).  So it shouldn't break anything if this is set to a minimum of 
the page size.  But setting it to the page size will hint that applications 
should use a page as the minimum IO block size and cause some applications to 
deliver better performance.



diff -ru textutils-2.0/src/cat.c textutils-new/src/cat.c
--- textutils-2.0/src/cat.c Sun Apr  8 22:55:10 2001
+++ textutils-new/src/cat.c Sun Apr  8 23:23:54 2001
@@ -790,6 +790,9 @@
   if (options == 0)
{
  insize = max (insize, outsize);
+#ifdef _SC_PHYS_PAGES
+ insize = max (insize, sysconf(_SC_PAGESIZE));
+#endif
  inbuf = (unsigned char *) xmalloc (insize);
 
  simple_cat (inbuf, insize);

-- 
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/   Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page
-
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/

swsusp & 2.4.3

[Pavel Machek]

Hi!

I found it works if I disable "save/restore of hw state".

I still need to restart driver of my psaux mouse.

Pavel
PS: BTW you should talk to acpi maintainers: acpi requires _os_ to do
this kind of stuff.

PPS: You should warn about logging filesystems. Using swsusp on
reiserfs could lead to pretty bad things: mounting of reiserfs (even
readonly!) means log is replayed, which means writes to
filesystem. That could lead to pretty bad corruption.
-- 
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [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: goodbye

[David Woodhouse]

On Sat, 7 Apr 2001, Joseph Carter wrote:

> ORBS ... well, they called one of my old ISPs' mail an open relay when
> it wasn't and took 3 months to decide to rectify the situation and
> remove us from their list.  That doesn't instill much confidence.

I've heard that accusation many times, and on investigation, on the 
occasions I could be bothered, it's _always_ turned out to be false - 
generally caused by cluelessness on the part of the reporter.

It's very easy for ISPs to get landed in ORBS by customers who use the
outgoing relay for spam which they've wrongly accepted. The ISP's mail
relay doesn't have to accept the mail from the outside world and blatantly
forward it.

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

Re: goodbye

[Rogier Wolff]

john slee wrote:
> On Sat, Apr 07, 2001 at 07:07:20PM -0700, Colonel wrote:
> > Some ISPs rely on crap software & OS to process email, and have other
> 
> so you don't use those ISPs

Out here I have choice between 

  dialup (lots to chose from): $200/month(*), not always online. 

  cable (one company): $25/month, always online, lowsy performance. 

  ADSL (one company): $50/month, always online, starting january 2001, 
  delayed without notice: Not yet available. 

My only real option is "cable". So that's what I have. These guys
manage to configure every thing badly. So when their mailserver is
unable to get any outside connections, the mail gets queued without
notice on their server, and I won't hear about it.

To me this is unacceptable, so I have to run my own mailserver. This
is not that bad, as I can be always online. (not being always online
means that Email may sit in the queue quite long if for example I'm
online 10% of the time, and a certain mailserver is online only 10% of
the time. I'd have a 1% chance of getting an Email through to this
server, but being always online increases the chances to 10%). 

Roger.

(*) Adding in some telephone charges.

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
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: goodbye

[Jeff Mcadams]

Also sprach Joseph Carter
>Even in those cases where broadband users are given a choice of providers,
>they have to know to ask for that choice since it is never offered and by
>exercising that choice you will usually find the price to be at least
>double if not triple - often through no fault of your chosen ISP.  If you
>order DSL without your telco's ISP, you'll usually discover a great many
>"fees" they only elect to charge if you don't cooperate.

This is getting to be *very* far off topic, so I'll post this and leave
it as it, but this is a subject that's very near and dear to me...

If your ILEC is doing the above (charging you more fees for DSL if
you're using an ISP other than their affiliated one), then I *HEARTILY*
encourage you (at least in the states) to contact your state Utilities
Commission.  Those actions are *blatently* illegal, and the state
utility commission is the organization that would handle that.

This advice obviously may not hold outside of the states.  If you'd like
to see an example of this type of action, check out case 1999-484 at the
Kentucky Public Service Commission at http://www.psc.state.ky.us.

Now, let's get back to actual kernel discussions where I can be totally
lost again.  :)
-- 
Jeff McAdamsEmail: [EMAIL PROTECTED]
Head Network Administrator  Voice: (502) 966-3848
IgLou Internet Services(800) 436-4456
-
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 to build modules outside the kernel tree? [Was: Proper way to release binary driver?]

[Jamie Lokier]

Eric W. Biederman wrote:
> 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?

I have done exactly this, which I've used for a few device drivers.  The
Makefile can usually find the kernel source tree for the running kernel
by looking in the sensible places, it knows where to install modules,
and it is even able to get the right $(CFLAGS) from a configured kernel
tree.

The package includes a "compat.h", which rather like other similar files
("kcompat24.h") provides a 2.4-series API that works with all kernels
going back to 2.0, on all platforms I hope.  (I grepped the patches to
find out when each API change that I'm interested in occurred).  This
doesn't include network driver API though, just your basic PCI search
and read/write/ioctl/mmap/get_user interfaces.

The nice result is that, from a single source .tar.gz, "make" builds and
installs a driver module written with (more or less) the 2.4 API on any
kernel from 2.0 to 2.4, and the driver source is not full of ifdefs.

I suppose you're wondering where to get these files.  Mail me and I'll
see if there's much demand.

cheers,
-- 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: problem when booting 2.4.3 from a floppy disk

[Thomas Molina]

On Sat, 7 Apr 2001, François Dupoux wrote:

> Hi,
>
> I have a strange bug when trying to boot a kernel-2.4.3 (official release)
> from an 1.44 MB floppy disk. Just after the "Loading...", there is an
> infinite loop, and this message is printed:
> 0200
> AX: 0212
> BX: BC00
> CX: 5101
> DX: 
> 0200
> AX: 0212
> BX: BC00
> CX: 5101
> DX: 
> 

Do you have any suspect hardware in your system?  The reason I ask is
that I have a part time job working in a computer shop where I build and
repair ix86 systems.  I've seen this occasionally when I use a 2.4.X
boot floppy to diagnose system problems.  It hasn't been consistent and
it hasn't happened often enough to correlate with anything else.

I've resolved to keep formal statistics on systems which exhibit this
problem so I would appreciate a cc on any followups to this.

-
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: Multi-function PCI devices

[Tim Waugh]

On Sun, Apr 08, 2001 at 02:05:36PM +0200, Michael Reinelt wrote:

> The simple solution: Gunters 'multifunction quirks'
> clean solution #1: a new module according to Jeffs sample code
> clean solution #2: 'invisible PCI bridge' from Linus
[...]
> Suggestion: multifunction quirks for 2.4, one of the clean solutions for
> 2.5?

I would rather we went for something in 2.4 and stick with it in 2.5
than changing again. (The parport ID list format changed in 2.2->2.4
already in order to handle subsystem IDs.)

Tim.
*/

 PGP signature

Re: Possible bug for Kernel 2.4.3 -> make modules_install

[Chmouel Boudjnah]

Patrick Shirkey <[EMAIL PROTECTED]> writes:

> I am having trouble installing modules. The command hangs at the
> following point in the install...
> 
> ---
>   Finished dependencies of target file `_modinst_post'.
>   Must remake target `_modinst_post'.
> if [ -r System.map ]; then /sbin/depmod -ae -F System.map  2.4.3; fi
> Putting child 0x08088a88 PID 01056 on the chain.
> Live child 0x08088a88 PID 1056
> /sbin/depmod: invalid option -- F
> Usage: depmod [-e -s -v ] -a [FORCED_KERNEL_VER]
>depmod [-e -s -v ] MODULE_1.o MODULE_2.o ...
> Create module-dependency information for modprobe.

(chmou@no)[linux/Documentation]-% grep modutils Changes 
o  modutils   2.4.2   # insmod -V
Upgrade to recent modutils to fix various outstanding bugs which are
requires that you upgrade to a recent modutils.
o  


-- 
MandrakeSoft Inc http://www.chmouel.org
  --Chmouel
-
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: Multi-function PCI devices

[Michael Reinelt]

Tim Waugh wrote:
> 
> On Sat, Apr 07, 2001 at 03:40:13PM -0400, Jeff Garzik wrote:
> 
> > Who said you have to have a separate driver for every single multi-IO
> > card?  A single driver could support all serial+parallel multi-IO cards,
> > for example.
> 
> Okay, I misunderstood.  I'll take a look at doing this for 2.4.
> 
> First of all, parport_pc will need to export the equivalent of
> register_serial (its equivalent is probably parport_pc_probe_port).
> [It actually already does this (conditionally on parport_cs).]
> 
> drivers/parport/parport_serial.c sound okay, or is a different place
> better?

Heh. These multi-I/O-cards come in a lot of different fashions. Let me
explain the NetMos chips a bit:

My card shows up with lspci like that:

lizard:~ # lspci -s 00:0c -vn
00:0c.0 Class 0780: 9710:9835 (rev 01)
Subsystem: 1000:0012
Flags: medium devsel, IRQ 11
I/O ports at 9400 [size=8]
I/O ports at 9000 [size=8]
I/O ports at 8800 [size=8]
I/O ports at 8400 [size=8]
I/O ports at 8000 [size=8]
I/O ports at 7800 [size=16]

as you can see, it's class is PCI_CLASS_COMMUNICATION_OTHER

There are 8 different chips from Netmos, they differ mainly in the
number of serial and parallel ports:

9705  -/1P
9735 2S/1P
9745 2S/-
9805  -/1P
9815  -/2P
9835 2S/1P
9845 2S/-
9855  -/2P

the chip id is the same as the PCI device ID. So there are chips with
only serial or parallel ports, and chips with both of them. A chip
without a parallel port (9845) does not really belong to
parport/parport_serial.c :-) On the other hand, a chip without a serial
port should have nothing to do whith serial.c.

At the moment there is a clean solution: serial.c contains only the
device ids of cards with serial ports, the same for parport_pc.c


to summarize the discussion, there are 3 possible solution. I wanted a
simple _and_ clean solution, this seems impossible. 

The simple solution: Gunters 'multifunction quirks'
clean solution #1: a new module according to Jeffs sample code
clean solution #2: 'invisible PCI bridge' from Linus

For both clean solutions I don't know how autoloading/hotplugging would
be handled. But they look good, especially Linus' one.

The simple solution would be _very_ easy to integrate, would not break
existing configurations, and would not require any design changes.

Suggestion: multifunction quirks for 2.4, one of the clean solutions for
2.5?

bye, Michael

-- 
netWorks  Vox: +43 316  692396
Michael Reinelt   Fax: +43 316  692343
Geisslergasse 4   GSM: +43 676 3079941
A-8045 Graz, Austria  e-mail: [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: Multi-function PCI devices

[Michael Reinelt]

Jeff Garzik wrote:
> 
> > Another (design) question: How will such a driver/module deal with
> > autodetection and/or devfs? I don't like to specify 'alias /dev/tts/4
> > netmos', because thats pure junk to me. What about pci hotplugging?
> 
> pci hotplugging happens pretty much transparently.  When a new device is
> plugged in, your pci_driver::probe routine is called.  When a new device
> is removed, your pci_driver::remove routine is called.

Thats clear to me. But the probe and remove routine can only be called
if the module is already loaded. My question was: who will load the
module? (I'll call it 'netmos.o')

devfs in its standard configuration knows about loading serial.o or
parport.o when /dev/tts/* or /dev/parport/* is accessed. Some other
module loads are triggered by module dependancies (e.g. lp.o requires
parport.o)

If I do a 'modprobe serial', how should the serial driver know that the
netmos.o should be loaded, too?

There is a file called 'modules.pcimap', which contains modules for
specific PCI devices. That's how hotplugging could detect that there's a
netmos card and that netmos.o should be loaded. That looks clean to me,
but I'm not shure if this sort of PCI hotplugging is already
implemented.

bye, Michael

-- 
netWorks  Vox: +43 316  692396
Michael Reinelt   Fax: +43 316  692343
Geisslergasse 4   GSM: +43 676 3079941
A-8045 Graz, Austria  e-mail: [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: goodbye

[Olaf Titz]

> It scares me that peoples' messages would be denied based on what
> degree of connection they choose to mail via. I sincerely hope that
> the DUL lists only list netblocks that are actively being used for
> spam. This would be sort of like the Usenet Death Penalty, instating
> bans on providers who refuse to deal with spamming. I think that's a

There's another list to do that: the original RBL. The DUL is only and
explicitly for the purpose of denying access based on the degree of
connection the users can afford.

Olaf

-
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-ac2 -- How do I determine if shm is being used?

[Christoph Rohland]

Hi Miles,

On Sat, 07 Apr 2001, Miles Lane wrote:
> I have mounted:
> 
>   none on /var/shm type shm (rw)

Not necessary any more.

>   tmpfs on /dev/shm type tmpfs (rw)

Also not necessary, but recommended for POSIX shm. BTW it will not
work with Linus' kernel. Type "shm" is supported by both versions.

> X Error of failed request: BadValue (integer parameter out of range
> for operation)
>   Major opcode of failed request:  146 (MIT-SHM)
>   Minor opcode of failed request:  3 (X_ShmPutImage)
>   Value in failed request:  0x161
>   Serial number of failed request:  35107
>   Current serial number in output stream:  35111

Ubfortunately this does not tell what it wanted to do.

> I'd like to check to make sure that shm is actually accessible
> to my programs.  Is there any easy way to do this?

ipcs should be your friend. Especially 'ipcs -lm'.

Greetings
Christoph


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

kgdb for 2.4.3 kernels

[Amit S. Kale]

Hi,

Here is another way of allowing sane access to file system specific
information, statistics and configuration. It involves using the translation
filesystem (http://trfs.sourceforge.net/). An example of filesystem
configuration: configurable forcing data flush for all writes to files in a
filesystem, is implemented and is available for download. It is implemented
for ext2tr filesystem, which is ext2 filesystem with few modifications to use
the translation filesystem.

Filesystem views 

Filesystem views give information about filesystems and allow users to
configure them. Filesystem views for files and directories residing in the
same filesystem are identical. They are applicable to the whole filesystem.
An example filesystem view fs/config has been provided for ext2tr filesytem.
This view can be used to configure the filesystem to immediately flush data
written to files in the filesystem. 


Uses of filesystem views 
---
Filesystems can allow users to configure them through filesystem configuration
views. Although ioctls can be used for the same purpose, using views is
better. A comparison of ioctls and translation filesystem views is given on
the translation filesystem webpage. A View that gives information for a
filesystem can be put into the fs view at fs/info. The view can be
instantiated into a directory which contains text files giving filesystem
information. Filesystem statistics can be put into fs/stats.  fs/config view
can be used to configure a filesystem. 

Example of fs/config view 
-
The ext2tr filesystem (available from downloads page) contains an example
translator for fs/config view. The view instantiates into a directory, which
contains a file forcedsync. This file is used to control data sync behavior
for an ext2tr filesystem. If forcedsync file contains a character 0, flags
specified while opening a file in the filesystem are used to determine whether
data written to the file is immediately flushed to disk. If forcedsync file
contains a character 1, all data written to a file in the filesystem is
immediately flushed to disk regardless of the flags specified while opening
the file. Contents of the file can be checked by reading it and can be changed
by writing to it. A usage of the view is shown below. In the example, dd
command required 0.10 seconds when forcedsync was not enabled. After enabling
forcedsync, dd command required 1.62 seconds because data was being flushed at
each write system call. 

[root@localhost /root]# mkfs -t ext2 /dev/hda5 > /dev/null 
mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 
[root@localhost /root]# mount -t ext2tr /dev/hda5 /mnt0 
[root@localhost /root]# time dd if=/dev/zero of=/mnt0/foo bs=1024 count=100 
100+0 records in 
100+0 records out 
0.00user 0.02system 0:00.10elapsed 18%CPU (0avgtext+0avgdata 0maxresident)k 
0inputs+0outputs (116major+20minor)pagefaults 0swaps 
[root@localhost /root]# umount /mnt0 
[root@localhost /root]# mkfs -t ext2 /dev/hda5 > /dev/null 
mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 
[root@localhost /root]# mount -t ext2tr /dev/hda5 /mnt0 
[root@localhost /root]# /home/amit/developement/trfs/cmds/vcmd/vcmd /mnt0
fs/config -c ls @1/ 
forcedsync 
[root@localhost /root]# /home/amit/developement/trfs/cmds/vcmd/vcmd /mnt0
fs/config -c cat
@1/forcedsync 
[root@localhost /root]# echo 1 | /home/amit/developement/trfs/cmds/vcmd/vcmd
/mnt0 fs/config -c
dd of=@1/forcedsync bs=1 count=1 
1+0 records in 
1+0 records out 
[root@localhost /root]# /home/amit/developement/trfs/cmds/vcmd/vcmd /mnt0
fs/config -c cat
@1/forcedsync 
[root@localhost /root]# time dd if=/dev/zero of=/mnt0/foo bs=1024 count=100 
100+0 records in 
100+0 records out 
0.00user 0.01system 0:01.62elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k 
0inputs+0outputs (116major+20minor)pagefaults 0swaps

--
Amit S. Kale
<[EMAIL PROTECTED]>
Linux kernel source level debugger   http://kgdb.sourceforge.net/
Translation Filesystem   http://trfs.sourceforge.net/
-
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: Multi-function PCI devices

[Kai Henningsen]

[EMAIL PROTECTED] (Tim Waugh)  wrote on 07.04.01 in <[EMAIL PROTECTED]>:

> On Sat, Apr 07, 2001 at 01:23:27PM -0400, Jeff Garzik wrote:
>
> > You asked in your last message to show you code, here is a short
> > example.  Note that I would love to rip out the SUPERIO code in parport
> > and make it a separate driver like this short, contrived example.  Much
> > more modular than the existing solution.
>
> (The superio code is on its way out anyway, for different reasons..)
>
> More modular?  Yes, it adds another module to support a card, so yes
> there are more modules.
>
> But with the multifunction_quirks approach, support is a question of
> adding two lines in a table.

So why not make Jeff's example use a multifunction board table to do it's  
job?

MfG Kai
-
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.2 ac2x & 2.4.3. loss of VC displays

[Roeland Th. Jansen]

hi all

regently I see weird things with X.

XFree86 Version 4.0.2 / X Window System
(protocol Version 11, revision 0, vendor release 6400)
Release Date: 18 December 2000

(II) NV: driver for NVIDIA chipsets: RIVA128, RIVATNT, RIVATNT2,
RIVATNT2 (Ultra), RIVATNT2 (Vanta), RIVATNT2 M64,
RIVATNT2 (Integrated), GeForce 256, GeForce DDR, Quadro,
GeForce2 GTS, GeForce2 GTS (rev 1), GeForce2 ultra, Quadro 2 Pro,
GeForce2 MX, GeForce2 MX DDR, Quadro 2 MXR, GeForce 2 Go
(--) Chipset RIVATNT found

this is a SuSE 7.0 std X thing. no specific NVIDIA obfuscated source
binary or something.

what happens is that after some time, I switch back & forth from and to
X. sometimes, most within a day of work, switching from X to a VC, the
VC's blank. it reacts to commands but display is blank.

I don't have special modules launched and no patches to the kernel
except the lm_sensors / i2c stuff. removed it for test and still
happens.

someone an idea ?


-- 
Grobbebol's Home   |  Don't give in to spammers.   -o)
http://www.xs4all.nl/~bengel   | Use your real e-mail address   /\
Linux 2.2.16 SMP 2x466MHz / 256 MB |on Usenet. _\_v  
-
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: goodbye

[Matti Aarnio]

On Sun, Apr 08, 2001 at 02:10:52PM +0900, [EMAIL PROTECTED] wrote:
> How about creating an additional ML,
> the new ML (say LKML-DUL) is used to send mails from DUL to LKML, but
> such mails are not sent to LMKL.

Layering and technology problem.

SMTP receiver does those RBL/DUL/ORBS analysis, and its policy
control does not know where exactly the email is heading into
(that is, the reception policy is system level, not by recipients.)

List-processing is done separately from input at Majordomo.
Long after the reception processing.

> --
> Computer Systems Laboratory, Fujitsu Labs.
> [EMAIL PROTECTED]

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

new queuing discipline

[Oldrich Kepka]

Hi,
I am developing new queuing disciline. The purpose of this queue is to delay
outgoing packets. I wrote module sch_delay.o. This module implements delay_e
nqueue() and delay_dequeue() functions. I also modify tc to comunicate throu
gh netlink with my module. Because i want to dequeue only when there are suf
ficiently old packet on the top of the queue, i immediately return from dequ
eue function returning NULL. But the dequeue function is called only when so
me event occures. I found out, that i occures for example when there are new
packet in the queue. No other conditions i found. But i need repeatedly test
the top packet in the queue.

How to accomplish it?

Thanks
Olda




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

Possible bug for Kernel 2.4.3 -> make modules_install

[Patrick Shirkey]

I am having trouble installing modules. The command hangs at the
following point in the install...

---
  Finished dependencies of target file `_modinst_post'.
  Must remake target `_modinst_post'.
if [ -r System.map ]; then /sbin/depmod -ae -F System.map  2.4.3; fi
Putting child 0x08088a88 PID 01056 on the chain.
Live child 0x08088a88 PID 1056
/sbin/depmod: invalid option -- F
Usage: depmod [-e -s -v ] -a [FORCED_KERNEL_VER]
   depmod [-e -s -v ] MODULE_1.o MODULE_2.o ...
Create module-dependency information for modprobe.
 
  -a, --all  visit all modules
  -d, --debugrun in debug mode
  -e output unresolved symbols
  -i ignore symbol versions
  -m, --system-map use the symbols in 
  -s, --system-log   use the system log for error reporting
  --help display this help and exit
  -v, --verbose  run in verbose mode
  -V, --version  output version information and exit
Got a SIGCHLD; 1 unreaped children.
Reaping losing child 0x08088a88 PID 1056
make: *** [_modinst_post] Error 1
Removing child 0x08088a88 PID 1056 from chain.
---

Can anyone tell me how to fix this prob?

My system is:

Mandrake 7.0
kernel 2.4.3 nee 2.2.14-15mdk

[root@localhost linux]# cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 8
model name  : Pentium III (Coppermine)
stepping: 1
cpu MHz : 501.143
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 mmx fxsr sse
bogomips: 999.42  

[root@localhost linux]# cat /proc/ioports
-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
02f8-02ff : serial(auto)
0376-0376 : ide1
0378-037a : parport0
03c0-03df : vga+
03f6-03f6 : ide0
0cf8-0cff : PCI conf1
1000-100f : Intel Corporation 82371AB PIIX4 IDE
  1000-1007 : ide0
  1008-100f : ide1
1010-1017 : Lucent Microelectronics 56k WinModem
1020-103f : Intel Corporation 82371AB PIIX4 USB
  1020-103f : usb-uhci
1400-14ff : ESS Technology ES1978 Maestro 2E
1800-18ff : Lucent Microelectronics 56k WinModem
1c00-1fff : PCI CardBus #02
  1c00-1cff : PCI device 10ec:8138
1c00-1cff : 8139too
2180-219f : Intel Corporation 82371AB PIIX4 ACPI
2400-2fff : PCI CardBus #06
8000-803f : Intel Corporation 82371AB PIIX4 ACPI
9000-9fff : PCI Bus #01
  9000-90ff : ATI Technologies Inc 3D Rage LT Pro AGP-133
[root@localhost linux]# 

[root@localhost linux]# cat /proc/iomem
-0009f7ff : System RAM
0009f800-0009 : reserved
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000f-000f : System ROM
0010-0fff : System RAM
  0010-001fb27b : Kernel code
  001fb27c-0027f8bf : Kernel data
1000-1fff : Texas Instruments PCI1251B
10001000-10001fff : Texas Instruments PCI1251B (#2)
1080-10bf : PCI CardBus #02
  1080-108001ff : PCI device 10ec:8138
1080-108001ff : 8139too
10c0-10ff : PCI CardBus #06
1100-113f : PCI CardBus #06
6000-6fff : PCI CardBus #02
f400-f4ff : Lucent Microelectronics 56k WinModem
f410-f41f : PCI Bus #01
  f410-f4100fff : ATI Technologies Inc 3D Rage LT Pro AGP-133
f500-f5ff : PCI Bus #01
  f500-f5ff : ATI Technologies Inc 3D Rage LT Pro AGP-133
f800-fbff : Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
fff8- : reserved
[root@localhost linux]#   


Thanks.

Patrick Shirkey.

   
-- 
Boost Hardware.
Importing Korean Computer Hardware to New Zealand.

Http://www.boosthardware.com for latest stock and prices.
-
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: P-III Oddity.

[Manfred Spraul]

Just a guess:

Perhaps one bios is older and contains an older microcode patch?

Have you tried the microcode driver?

--
Manfred
-
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]

[Manfred Spraul]

Pavel Machek wrote:
> 
> Ok. I was missing the fact it is checked on going userspace.
>

What about the attached patch?

--
Manfred

// $Header$
// Kernel Version:
//  VERSION = 2
//  PATCHLEVEL = 4
//  SUBLEVEL = 3
//  EXTRAVERSION = -ac3
--- 2.4/include/linux/interrupt.h   Thu Feb 22 22:29:53 2001
+++ build-2.4/include/linux/interrupt.h Sat Apr  7 23:51:31 2001
@@ -269,4 +269,25 @@
 extern int probe_irq_off(unsigned long);   /* returns 0 or negative on failure */
 extern unsigned int probe_irq_mask(unsigned long); /* returns mask of ISA 
interrupts */
 
+/**
+ * cpu_is_idle - helper function for idle functions
+ * 
+ * pm_idle functions must call this function to verify that
+ * the cpu is really idle. It must be called with disabled
+ * local interrupts.
+ * Return values:
+ * 0: cpu was not idle.
+ * 1: go into power saving mode.
+ */
+static inline int cpu_is_idle(void)
+{
+   if (current->need_resched) {
+   return 0;
+   }
+   if (softirq_active(smp_processor_id()) & softirq_mask(smp_processor_id())) {
+   do_softirq();
+   return 0;
+   }
+   return 1;
+}
 #endif
--- 2.4/arch/i386/kernel/process.c  Thu Feb 22 22:28:52 2001
+++ build-2.4/arch/i386/kernel/process.cSat Apr  7 23:51:46 2001
@@ -73,6 +73,7 @@
hlt_counter--;
 }
 
+
 /*
  * We use this if we don't have any better
  * idle routine..
@@ -81,7 +82,7 @@
 {
if (current_cpu_data.hlt_works_ok && !hlt_counter) {
__cli();
-   if (!current->need_resched)
+   if (cpu_is_idle())
safe_halt();
else
__sti();
@@ -92,26 +93,21 @@
  * On SMP it's slightly faster (but much more power-consuming!)
  * to poll the ->need_resched flag instead of waiting for the
  * cross-CPU IPI to arrive. Use this option with caution.
+ *
+ * Isn't this identical to default_idle with the 'no-hlt' boot
+ * option? <[EMAIL PROTECTED]>
  */
 static void poll_idle (void)
 {
int oldval;
 
+   for(;;) {
+   if (!cpu_is_idle())
+   break;
+   __sti();
+   rep_nop();
+   }
__sti();
-
-   /*
-* Deal with another CPU just having chosen a thread to
-* run here:
-*/
-   oldval = xchg(>need_resched, -1);
-
-   if (!oldval)
-   asm volatile(
-   "2:"
-   "cmpl $-1, %0;"
-   "rep; nop;"
-   "je 2b;"
-   : :"m" (current->need_resched));
 }
 
 /*
--- 2.4/drivers/acpi/cpu.c  Sat Apr  7 22:02:01 2001
+++ build-2.4/drivers/acpi/cpu.cSat Apr  7 23:55:17 2001
@@ -148,7 +148,7 @@
unsigned long diff;

__cli();
-   if (current->need_resched)
+   if (!cpu_is_idle())
goto out;
if (acpi_bm_activity())
goto sleep2;
@@ -171,7 +171,7 @@
unsigned long diff;
 
__cli();
-   if (current->need_resched)
+   if (!cpu_is_idle())
goto out;
if (acpi_bm_activity())
goto sleep2;
@@ -205,7 +205,7 @@
unsigned long diff;
 
__cli();
-   if (current->need_resched)
+   if (!cpu_is_idle())
goto out;
 
time = acpi_read_pm_timer();
@@ -235,7 +235,7 @@
unsigned long diff;
 
__cli();
-   if (current->need_resched)
+   if (!cpu_is_idle())
goto out;
time = acpi_read_pm_timer();
acpi_c1_count++;

rep nop question

[Manfred Spraul]

The Intel documentation recommends that spinlocks should use

loop:
rep;nop;
cmp $0,lock_var
jne loop

ftp://download.intel.com/design/perftool/cbts/appnotes/sse2/w_spinlock.pdf

but the linux spinlock implementation uses

loop:
cmp $0, lock_var
rep; nop;
jne loop.

Why?
According to the Intel documentation, rep nop is a predefined delay that
slows down the cpu to the speed of the memory bus. The linux
implementation will delay again _after_ the lock was released.

What about the attached patch? It also adds 'rep;nop' into the rw
spinlock implementation.

It boots with my Pentium III, but the cpu doesn't support 'rep nop'
(i.e. returns immediately)

--
Manfred

// $Header$
// Kernel Version:
//  VERSION = 2
//  PATCHLEVEL = 4
//  SUBLEVEL = 3
//  EXTRAVERSION = -ac3
--- 2.4/arch/i386/kernel/semaphore.cSun Nov 19 02:31:25 2000
+++ build-2.4/arch/i386/kernel/semaphore.c  Sat Apr  7 21:26:35 2001
@@ -430,7 +430,8 @@
 .globl __write_lock_failed
 __write_lock_failed:
" LOCK "addl$" RW_LOCK_BIAS_STR ",(%eax)
-1: cmpl$" RW_LOCK_BIAS_STR ",(%eax)
+1: rep; nop
+   cmpl$" RW_LOCK_BIAS_STR ",(%eax)
jne 1b
 
" LOCK "subl$" RW_LOCK_BIAS_STR ",(%eax)
@@ -442,7 +443,8 @@
 .globl __read_lock_failed
 __read_lock_failed:
lock ; incl (%eax)
-1: cmpl$1,(%eax)
+1: rep; nop
+   cmpl$1,(%eax)
js  1b
 
lock ; decl (%eax)
--- 2.4/include/asm-i386/spinlock.h Sat Apr  7 22:02:23 2001
+++ build-2.4/include/asm-i386/spinlock.h   Sat Apr  7 22:01:43 2001
@@ -58,10 +58,10 @@
"js 2f\n" \
".section .text.lock,\"ax\"\n" \
"2:\t" \
-   "cmpb $0,%0\n\t" \
"rep;nop\n\t" \
-   "jle 2b\n\t" \
-   "jmp 1b\n" \
+   "cmpb $0,%0\n\t" \
+   "jg 1b\n\t" \
+   "jmp 2b\n" \
".previous"
 
 /*

Re: goodbye

[Aaron Lehmann]

On Sun, Apr 08, 2001 at 02:32:28AM +0300, Matti Aarnio wrote:
>   The incentive behind the DUL is to force users not to post
>   straight out to the world, but to use their ISP's servers
>   for outbound email --- normal M$ users do that, after all.
>   Only spammers - and UNIX powerusers - want to post directly
>   to the world from dialups.  And UNIX powerusers should know
>   better, and be able to use ISP relay service anyway.

Personally, this concerns me.

I have a personal mailserver on my DSL line. Now, DSL isn't dialup,
but it's quite widespread and I'm sure it's even more popular among
spammers than the mass market. The doomsday scenario is that one day
all messages messages will have to be relayed through Hotmail, Yahoo,
or another one of a handful of large, untrustworthy corporations. Of
course I know this isn't likely, but what's to prevent people who
can't afford T1's from becoming unable to run mail servers?

It scares me that peoples' messages would be denied based on what
degree of connection they choose to mail via. I sincerely hope that
the DUL lists only list netblocks that are actively being used for
spam. This would be sort of like the Usenet Death Penalty, instating
bans on providers who refuse to deal with spamming. I think that's a
lot more acceptable than shutting everyone who happens to connect to
the internet in a certain way from sending mail directly out of their
local machines.
-
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: goodbye

[Aaron Lehmann]

On Sun, Apr 08, 2001 at 02:32:28AM +0300, Matti Aarnio wrote:
   The incentive behind the DUL is to force users not to post
   straight out to the world, but to use their ISP's servers
   for outbound email --- normal M$ users do that, after all.
   Only spammers - and UNIX powerusers - want to post directly
   to the world from dialups.  And UNIX powerusers should know
   better, and be able to use ISP relay service anyway.

Personally, this concerns me.

I have a personal mailserver on my DSL line. Now, DSL isn't dialup,
but it's quite widespread and I'm sure it's even more popular among
spammers than the mass market. The doomsday scenario is that one day
all messages messages will have to be relayed through Hotmail, Yahoo,
or another one of a handful of large, untrustworthy corporations. Of
course I know this isn't likely, but what's to prevent people who
can't afford T1's from becoming unable to run mail servers?

It scares me that peoples' messages would be denied based on what
degree of connection they choose to mail via. I sincerely hope that
the DUL lists only list netblocks that are actively being used for
spam. This would be sort of like the Usenet Death Penalty, instating
bans on providers who refuse to deal with spamming. I think that's a
lot more acceptable than shutting everyone who happens to connect to
the internet in a certain way from sending mail directly out of their
local machines.
-
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]

[Manfred Spraul]

Pavel Machek wrote:
 
 Ok. I was missing the fact it is checked on going userspace.


What about the attached patch?

--
Manfred

// $Header$
// Kernel Version:
//  VERSION = 2
//  PATCHLEVEL = 4
//  SUBLEVEL = 3
//  EXTRAVERSION = -ac3
--- 2.4/include/linux/interrupt.h   Thu Feb 22 22:29:53 2001
+++ build-2.4/include/linux/interrupt.h Sat Apr  7 23:51:31 2001
@@ -269,4 +269,25 @@
 extern int probe_irq_off(unsigned long);   /* returns 0 or negative on failure */
 extern unsigned int probe_irq_mask(unsigned long); /* returns mask of ISA 
interrupts */
 
+/**
+ * cpu_is_idle - helper function for idle functions
+ * 
+ * pm_idle functions must call this function to verify that
+ * the cpu is really idle. It must be called with disabled
+ * local interrupts.
+ * Return values:
+ * 0: cpu was not idle.
+ * 1: go into power saving mode.
+ */
+static inline int cpu_is_idle(void)
+{
+   if (current-need_resched) {
+   return 0;
+   }
+   if (softirq_active(smp_processor_id())  softirq_mask(smp_processor_id())) {
+   do_softirq();
+   return 0;
+   }
+   return 1;
+}
 #endif
--- 2.4/arch/i386/kernel/process.c  Thu Feb 22 22:28:52 2001
+++ build-2.4/arch/i386/kernel/process.cSat Apr  7 23:51:46 2001
@@ -73,6 +73,7 @@
hlt_counter--;
 }
 
+
 /*
  * We use this if we don't have any better
  * idle routine..
@@ -81,7 +82,7 @@
 {
if (current_cpu_data.hlt_works_ok  !hlt_counter) {
__cli();
-   if (!current-need_resched)
+   if (cpu_is_idle())
safe_halt();
else
__sti();
@@ -92,26 +93,21 @@
  * On SMP it's slightly faster (but much more power-consuming!)
  * to poll the -need_resched flag instead of waiting for the
  * cross-CPU IPI to arrive. Use this option with caution.
+ *
+ * Isn't this identical to default_idle with the 'no-hlt' boot
+ * option? [EMAIL PROTECTED]
  */
 static void poll_idle (void)
 {
int oldval;
 
+   for(;;) {
+   if (!cpu_is_idle())
+   break;
+   __sti();
+   rep_nop();
+   }
__sti();
-
-   /*
-* Deal with another CPU just having chosen a thread to
-* run here:
-*/
-   oldval = xchg(current-need_resched, -1);
-
-   if (!oldval)
-   asm volatile(
-   "2:"
-   "cmpl $-1, %0;"
-   "rep; nop;"
-   "je 2b;"
-   : :"m" (current-need_resched));
 }
 
 /*
--- 2.4/drivers/acpi/cpu.c  Sat Apr  7 22:02:01 2001
+++ build-2.4/drivers/acpi/cpu.cSat Apr  7 23:55:17 2001
@@ -148,7 +148,7 @@
unsigned long diff;

__cli();
-   if (current-need_resched)
+   if (!cpu_is_idle())
goto out;
if (acpi_bm_activity())
goto sleep2;
@@ -171,7 +171,7 @@
unsigned long diff;
 
__cli();
-   if (current-need_resched)
+   if (!cpu_is_idle())
goto out;
if (acpi_bm_activity())
goto sleep2;
@@ -205,7 +205,7 @@
unsigned long diff;
 
__cli();
-   if (current-need_resched)
+   if (!cpu_is_idle())
goto out;
 
time = acpi_read_pm_timer();
@@ -235,7 +235,7 @@
unsigned long diff;
 
__cli();
-   if (current-need_resched)
+   if (!cpu_is_idle())
goto out;
time = acpi_read_pm_timer();
acpi_c1_count++;

rep nop question

[Manfred Spraul]

The Intel documentation recommends that spinlocks should use

loop:
rep;nop;
cmp $0,lock_var
jne loop

ftp://download.intel.com/design/perftool/cbts/appnotes/sse2/w_spinlock.pdf

but the linux spinlock implementation uses

loop:
cmp $0, lock_var
rep; nop;
jne loop.

Why?
According to the Intel documentation, rep nop is a predefined delay that
slows down the cpu to the speed of the memory bus. The linux
implementation will delay again _after_ the lock was released.

What about the attached patch? It also adds 'rep;nop' into the rw
spinlock implementation.

It boots with my Pentium III, but the cpu doesn't support 'rep nop'
(i.e. returns immediately)

--
Manfred

// $Header$
// Kernel Version:
//  VERSION = 2
//  PATCHLEVEL = 4
//  SUBLEVEL = 3
//  EXTRAVERSION = -ac3
--- 2.4/arch/i386/kernel/semaphore.cSun Nov 19 02:31:25 2000
+++ build-2.4/arch/i386/kernel/semaphore.c  Sat Apr  7 21:26:35 2001
@@ -430,7 +430,8 @@
 .globl __write_lock_failed
 __write_lock_failed:
" LOCK "addl$" RW_LOCK_BIAS_STR ",(%eax)
-1: cmpl$" RW_LOCK_BIAS_STR ",(%eax)
+1: rep; nop
+   cmpl$" RW_LOCK_BIAS_STR ",(%eax)
jne 1b
 
" LOCK "subl$" RW_LOCK_BIAS_STR ",(%eax)
@@ -442,7 +443,8 @@
 .globl __read_lock_failed
 __read_lock_failed:
lock ; incl (%eax)
-1: cmpl$1,(%eax)
+1: rep; nop
+   cmpl$1,(%eax)
js  1b
 
lock ; decl (%eax)
--- 2.4/include/asm-i386/spinlock.h Sat Apr  7 22:02:23 2001
+++ build-2.4/include/asm-i386/spinlock.h   Sat Apr  7 22:01:43 2001
@@ -58,10 +58,10 @@
"js 2f\n" \
".section .text.lock,\"ax\"\n" \
"2:\t" \
-   "cmpb $0,%0\n\t" \
"rep;nop\n\t" \
-   "jle 2b\n\t" \
-   "jmp 1b\n" \
+   "cmpb $0,%0\n\t" \
+   "jg 1b\n\t" \
+   "jmp 2b\n" \
".previous"
 
 /*

Re: P-III Oddity.

[Manfred Spraul]

Just a guess:

Perhaps one bios is older and contains an older microcode patch?

Have you tried the microcode driver?

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

Possible bug for Kernel 2.4.3 - make modules_install

[Patrick Shirkey]

I am having trouble installing modules. The command hangs at the
following point in the install...

---
  Finished dependencies of target file `_modinst_post'.
  Must remake target `_modinst_post'.
if [ -r System.map ]; then /sbin/depmod -ae -F System.map  2.4.3; fi
Putting child 0x08088a88 PID 01056 on the chain.
Live child 0x08088a88 PID 1056
/sbin/depmod: invalid option -- F
Usage: depmod [-e -s -v ] -a [FORCED_KERNEL_VER]
   depmod [-e -s -v ] MODULE_1.o MODULE_2.o ...
Create module-dependency information for modprobe.
 
  -a, --all  visit all modules
  -d, --debugrun in debug mode
  -e output unresolved symbols
  -i ignore symbol versions
  -m, --system-map fileuse the symbols in file
  -s, --system-log   use the system log for error reporting
  --help display this help and exit
  -v, --verbose  run in verbose mode
  -V, --version  output version information and exit
Got a SIGCHLD; 1 unreaped children.
Reaping losing child 0x08088a88 PID 1056
make: *** [_modinst_post] Error 1
Removing child 0x08088a88 PID 1056 from chain.
---

Can anyone tell me how to fix this prob?

My system is:

Mandrake 7.0
kernel 2.4.3 nee 2.2.14-15mdk

[root@localhost linux]# cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 8
model name  : Pentium III (Coppermine)
stepping: 1
cpu MHz : 501.143
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 mmx fxsr sse
bogomips: 999.42  

[root@localhost linux]# cat /proc/ioports
-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
02f8-02ff : serial(auto)
0376-0376 : ide1
0378-037a : parport0
03c0-03df : vga+
03f6-03f6 : ide0
0cf8-0cff : PCI conf1
1000-100f : Intel Corporation 82371AB PIIX4 IDE
  1000-1007 : ide0
  1008-100f : ide1
1010-1017 : Lucent Microelectronics 56k WinModem
1020-103f : Intel Corporation 82371AB PIIX4 USB
  1020-103f : usb-uhci
1400-14ff : ESS Technology ES1978 Maestro 2E
1800-18ff : Lucent Microelectronics 56k WinModem
1c00-1fff : PCI CardBus #02
  1c00-1cff : PCI device 10ec:8138
1c00-1cff : 8139too
2180-219f : Intel Corporation 82371AB PIIX4 ACPI
2400-2fff : PCI CardBus #06
8000-803f : Intel Corporation 82371AB PIIX4 ACPI
9000-9fff : PCI Bus #01
  9000-90ff : ATI Technologies Inc 3D Rage LT Pro AGP-133
[root@localhost linux]# 

[root@localhost linux]# cat /proc/iomem
-0009f7ff : System RAM
0009f800-0009 : reserved
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000f-000f : System ROM
0010-0fff : System RAM
  0010-001fb27b : Kernel code
  001fb27c-0027f8bf : Kernel data
1000-1fff : Texas Instruments PCI1251B
10001000-10001fff : Texas Instruments PCI1251B (#2)
1080-10bf : PCI CardBus #02
  1080-108001ff : PCI device 10ec:8138
1080-108001ff : 8139too
10c0-10ff : PCI CardBus #06
1100-113f : PCI CardBus #06
6000-6fff : PCI CardBus #02
f400-f4ff : Lucent Microelectronics 56k WinModem
f410-f41f : PCI Bus #01
  f410-f4100fff : ATI Technologies Inc 3D Rage LT Pro AGP-133
f500-f5ff : PCI Bus #01
  f500-f5ff : ATI Technologies Inc 3D Rage LT Pro AGP-133
f800-fbff : Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
fff8- : reserved
[root@localhost linux]#   


Thanks.

Patrick Shirkey.

   
-- 
Boost Hardware.
Importing Korean Computer Hardware to New Zealand.

Http://www.boosthardware.com for latest stock and prices.
-
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/

new queuing discipline

[Oldrich Kepka]

Hi,
I am developing new queuing disciline. The purpose of this queue is to delay
outgoing packets. I wrote module sch_delay.o. This module implements delay_e
nqueue() and delay_dequeue() functions. I also modify tc to comunicate throu
gh netlink with my module. Because i want to dequeue only when there are suf
ficiently old packet on the top of the queue, i immediately return from dequ
eue function returning NULL. But the dequeue function is called only when so
me event occures. I found out, that i occures for example when there are new
packet in the queue. No other conditions i found. But i need repeatedly test
the top packet in the queue.

How to accomplish it?

Thanks
Olda




-
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: goodbye

[Matti Aarnio]

On Sun, Apr 08, 2001 at 02:10:52PM +0900, [EMAIL PROTECTED] wrote:
 How about creating an additional ML,
 the new ML (say LKML-DUL) is used to send mails from DUL to LKML, but
 such mails are not sent to LMKL.

Layering and technology problem.

SMTP receiver does those RBL/DUL/ORBS analysis, and its policy
control does not know where exactly the email is heading into
(that is, the reception policy is system level, not by recipients.)

List-processing is done separately from input at Majordomo.
Long after the reception processing.

 --
 Computer Systems Laboratory, Fujitsu Labs.
 [EMAIL PROTECTED]

/Matti Aarnio
-
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.2 ac2x 2.4.3. loss of VC displays

[Roeland Th. Jansen]

hi all

regently I see weird things with X.

XFree86 Version 4.0.2 / X Window System
(protocol Version 11, revision 0, vendor release 6400)
Release Date: 18 December 2000

(II) NV: driver for NVIDIA chipsets: RIVA128, RIVATNT, RIVATNT2,
RIVATNT2 (Ultra), RIVATNT2 (Vanta), RIVATNT2 M64,
RIVATNT2 (Integrated), GeForce 256, GeForce DDR, Quadro,
GeForce2 GTS, GeForce2 GTS (rev 1), GeForce2 ultra, Quadro 2 Pro,
GeForce2 MX, GeForce2 MX DDR, Quadro 2 MXR, GeForce 2 Go
(--) Chipset RIVATNT found

this is a SuSE 7.0 std X thing. no specific NVIDIA obfuscated source
binary or something.

what happens is that after some time, I switch back  forth from and to
X. sometimes, most within a day of work, switching from X to a VC, the
VC's blank. it reacts to commands but display is blank.

I don't have special modules launched and no patches to the kernel
except the lm_sensors / i2c stuff. removed it for test and still
happens.

someone an idea ?


-- 
Grobbebol's Home   |  Don't give in to spammers.   -o)
http://www.xs4all.nl/~bengel   | Use your real e-mail address   /\
Linux 2.2.16 SMP 2x466MHz / 256 MB |on Usenet. _\_v  
-
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: Multi-function PCI devices

[Kai Henningsen]

[EMAIL PROTECTED] (Tim Waugh)  wrote on 07.04.01 in [EMAIL PROTECTED]:

 On Sat, Apr 07, 2001 at 01:23:27PM -0400, Jeff Garzik wrote:

  You asked in your last message to show you code, here is a short
  example.  Note that I would love to rip out the SUPERIO code in parport
  and make it a separate driver like this short, contrived example.  Much
  more modular than the existing solution.

 (The superio code is on its way out anyway, for different reasons..)

 More modular?  Yes, it adds another module to support a card, so yes
 there are more modules.

 But with the multifunction_quirks approach, support is a question of
 adding two lines in a table.

So why not make Jeff's example use a multifunction board table to do it's  
job?

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

kgdb for 2.4.3 kernels

[Amit S. Kale]

Hi,

Here is another way of allowing sane access to file system specific
information, statistics and configuration. It involves using the translation
filesystem (http://trfs.sourceforge.net/). An example of filesystem
configuration: configurable forcing data flush for all writes to files in a
filesystem, is implemented and is available for download. It is implemented
for ext2tr filesystem, which is ext2 filesystem with few modifications to use
the translation filesystem.

Filesystem views 

Filesystem views give information about filesystems and allow users to
configure them. Filesystem views for files and directories residing in the
same filesystem are identical. They are applicable to the whole filesystem.
An example filesystem view fs/config has been provided for ext2tr filesytem.
This view can be used to configure the filesystem to immediately flush data
written to files in the filesystem. 


Uses of filesystem views 
---
Filesystems can allow users to configure them through filesystem configuration
views. Although ioctls can be used for the same purpose, using views is
better. A comparison of ioctls and translation filesystem views is given on
the translation filesystem webpage. A View that gives information for a
filesystem can be put into the fs view at fs/info. The view can be
instantiated into a directory which contains text files giving filesystem
information. Filesystem statistics can be put into fs/stats.  fs/config view
can be used to configure a filesystem. 

Example of fs/config view 
-
The ext2tr filesystem (available from downloads page) contains an example
translator for fs/config view. The view instantiates into a directory, which
contains a file forcedsync. This file is used to control data sync behavior
for an ext2tr filesystem. If forcedsync file contains a character 0, flags
specified while opening a file in the filesystem are used to determine whether
data written to the file is immediately flushed to disk. If forcedsync file
contains a character 1, all data written to a file in the filesystem is
immediately flushed to disk regardless of the flags specified while opening
the file. Contents of the file can be checked by reading it and can be changed
by writing to it. A usage of the view is shown below. In the example, dd
command required 0.10 seconds when forcedsync was not enabled. After enabling
forcedsync, dd command required 1.62 seconds because data was being flushed at
each write system call. 

[root@localhost /root]# mkfs -t ext2 /dev/hda5  /dev/null 
mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 
[root@localhost /root]# mount -t ext2tr /dev/hda5 /mnt0 
[root@localhost /root]# time dd if=/dev/zero of=/mnt0/foo bs=1024 count=100 
100+0 records in 
100+0 records out 
0.00user 0.02system 0:00.10elapsed 18%CPU (0avgtext+0avgdata 0maxresident)k 
0inputs+0outputs (116major+20minor)pagefaults 0swaps 
[root@localhost /root]# umount /mnt0 
[root@localhost /root]# mkfs -t ext2 /dev/hda5  /dev/null 
mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 
[root@localhost /root]# mount -t ext2tr /dev/hda5 /mnt0 
[root@localhost /root]# /home/amit/developement/trfs/cmds/vcmd/vcmd /mnt0
fs/config -c ls @1/ 
forcedsync 
[root@localhost /root]# /home/amit/developement/trfs/cmds/vcmd/vcmd /mnt0
fs/config -c cat
@1/forcedsync 
[root@localhost /root]# echo 1 | /home/amit/developement/trfs/cmds/vcmd/vcmd
/mnt0 fs/config -c
dd of=@1/forcedsync bs=1 count=1 
1+0 records in 
1+0 records out 
[root@localhost /root]# /home/amit/developement/trfs/cmds/vcmd/vcmd /mnt0
fs/config -c cat
@1/forcedsync 
[root@localhost /root]# time dd if=/dev/zero of=/mnt0/foo bs=1024 count=100 
100+0 records in 
100+0 records out 
0.00user 0.01system 0:01.62elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k 
0inputs+0outputs (116major+20minor)pagefaults 0swaps

--
Amit S. Kale
[EMAIL PROTECTED]
Linux kernel source level debugger   http://kgdb.sourceforge.net/
Translation Filesystem   http://trfs.sourceforge.net/
-
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-ac2 -- How do I determine if shm is being used?

[Christoph Rohland]

Hi Miles,

On Sat, 07 Apr 2001, Miles Lane wrote:
 I have mounted:
 
   none on /var/shm type shm (rw)

Not necessary any more.

   tmpfs on /dev/shm type tmpfs (rw)

Also not necessary, but recommended for POSIX shm. BTW it will not
work with Linus' kernel. Type "shm" is supported by both versions.

 X Error of failed request: BadValue (integer parameter out of range
 for operation)
   Major opcode of failed request:  146 (MIT-SHM)
   Minor opcode of failed request:  3 (X_ShmPutImage)
   Value in failed request:  0x161
   Serial number of failed request:  35107
   Current serial number in output stream:  35111

Ubfortunately this does not tell what it wanted to do.

 I'd like to check to make sure that shm is actually accessible
 to my programs.  Is there any easy way to do this?

ipcs should be your friend. Especially 'ipcs -lm'.

Greetings
Christoph


-
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: goodbye

[Olaf Titz]

 It scares me that peoples' messages would be denied based on what
 degree of connection they choose to mail via. I sincerely hope that
 the DUL lists only list netblocks that are actively being used for
 spam. This would be sort of like the Usenet Death Penalty, instating
 bans on providers who refuse to deal with spamming. I think that's a

There's another list to do that: the original RBL. The DUL is only and
explicitly for the purpose of denying access based on the degree of
connection the users can afford.

Olaf

-
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: Multi-function PCI devices

[Michael Reinelt]

Jeff Garzik wrote:
 
  Another (design) question: How will such a driver/module deal with
  autodetection and/or devfs? I don't like to specify 'alias /dev/tts/4
  netmos', because thats pure junk to me. What about pci hotplugging?
 
 pci hotplugging happens pretty much transparently.  When a new device is
 plugged in, your pci_driver::probe routine is called.  When a new device
 is removed, your pci_driver::remove routine is called.

Thats clear to me. But the probe and remove routine can only be called
if the module is already loaded. My question was: who will load the
module? (I'll call it 'netmos.o')

devfs in its standard configuration knows about loading serial.o or
parport.o when /dev/tts/* or /dev/parport/* is accessed. Some other
module loads are triggered by module dependancies (e.g. lp.o requires
parport.o)

If I do a 'modprobe serial', how should the serial driver know that the
netmos.o should be loaded, too?

There is a file called 'modules.pcimap', which contains modules for
specific PCI devices. That's how hotplugging could detect that there's a
netmos card and that netmos.o should be loaded. That looks clean to me,
but I'm not shure if this sort of PCI hotplugging is already
implemented.

bye, Michael

-- 
netWorks  Vox: +43 316  692396
Michael Reinelt   Fax: +43 316  692343
Geisslergasse 4   GSM: +43 676 3079941
A-8045 Graz, Austria  e-mail: [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: Multi-function PCI devices

[Michael Reinelt]

Tim Waugh wrote:
 
 On Sat, Apr 07, 2001 at 03:40:13PM -0400, Jeff Garzik wrote:
 
  Who said you have to have a separate driver for every single multi-IO
  card?  A single driver could support all serial+parallel multi-IO cards,
  for example.
 
 Okay, I misunderstood.  I'll take a look at doing this for 2.4.
 
 First of all, parport_pc will need to export the equivalent of
 register_serial (its equivalent is probably parport_pc_probe_port).
 [It actually already does this (conditionally on parport_cs).]
 
 drivers/parport/parport_serial.c sound okay, or is a different place
 better?

Heh. These multi-I/O-cards come in a lot of different fashions. Let me
explain the NetMos chips a bit:

My card shows up with lspci like that:

lizard:~ # lspci -s 00:0c -vn
00:0c.0 Class 0780: 9710:9835 (rev 01)
Subsystem: 1000:0012
Flags: medium devsel, IRQ 11
I/O ports at 9400 [size=8]
I/O ports at 9000 [size=8]
I/O ports at 8800 [size=8]
I/O ports at 8400 [size=8]
I/O ports at 8000 [size=8]
I/O ports at 7800 [size=16]

as you can see, it's class is PCI_CLASS_COMMUNICATION_OTHER

There are 8 different chips from Netmos, they differ mainly in the
number of serial and parallel ports:

9705  -/1P
9735 2S/1P
9745 2S/-
9805  -/1P
9815  -/2P
9835 2S/1P
9845 2S/-
9855  -/2P

the chip id is the same as the PCI device ID. So there are chips with
only serial or parallel ports, and chips with both of them. A chip
without a parallel port (9845) does not really belong to
parport/parport_serial.c :-) On the other hand, a chip without a serial
port should have nothing to do whith serial.c.

At the moment there is a clean solution: serial.c contains only the
device ids of cards with serial ports, the same for parport_pc.c


to summarize the discussion, there are 3 possible solution. I wanted a
simple _and_ clean solution, this seems impossible. 

The simple solution: Gunters 'multifunction quirks'
clean solution #1: a new module according to Jeffs sample code
clean solution #2: 'invisible PCI bridge' from Linus

For both clean solutions I don't know how autoloading/hotplugging would
be handled. But they look good, especially Linus' one.

The simple solution would be _very_ easy to integrate, would not break
existing configurations, and would not require any design changes.

Suggestion: multifunction quirks for 2.4, one of the clean solutions for
2.5?

bye, Michael

-- 
netWorks  Vox: +43 316  692396
Michael Reinelt   Fax: +43 316  692343
Geisslergasse 4   GSM: +43 676 3079941
A-8045 Graz, Austria  e-mail: [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: Possible bug for Kernel 2.4.3 - make modules_install

[Chmouel Boudjnah]

Patrick Shirkey [EMAIL PROTECTED] writes:

 I am having trouble installing modules. The command hangs at the
 following point in the install...
 
 ---
   Finished dependencies of target file `_modinst_post'.
   Must remake target `_modinst_post'.
 if [ -r System.map ]; then /sbin/depmod -ae -F System.map  2.4.3; fi
 Putting child 0x08088a88 PID 01056 on the chain.
 Live child 0x08088a88 PID 1056
 /sbin/depmod: invalid option -- F
 Usage: depmod [-e -s -v ] -a [FORCED_KERNEL_VER]
depmod [-e -s -v ] MODULE_1.o MODULE_2.o ...
 Create module-dependency information for modprobe.

(chmou@no)[linux/Documentation]-% grep modutils Changes 
o  modutils   2.4.2   # insmod -V
Upgrade to recent modutils to fix various outstanding bugs which are
requires that you upgrade to a recent modutils.
o  ftp://ftp.kernel.org/pub/linux/utils/kernel/modutils/v2.4/


-- 
MandrakeSoft Inc http://www.chmouel.org
  --Chmouel
-
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: Multi-function PCI devices

[Tim Waugh]

On Sun, Apr 08, 2001 at 02:05:36PM +0200, Michael Reinelt wrote:

 The simple solution: Gunters 'multifunction quirks'
 clean solution #1: a new module according to Jeffs sample code
 clean solution #2: 'invisible PCI bridge' from Linus
[...]
 Suggestion: multifunction quirks for 2.4, one of the clean solutions for
 2.5?

I would rather we went for something in 2.4 and stick with it in 2.5
than changing again. (The parport ID list format changed in 2.2-2.4
already in order to handle subsystem IDs.)

Tim.
*/

 PGP signature

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

[Jamie Lokier]

Eric W. Biederman wrote:
 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?

I have done exactly this, which I've used for a few device drivers.  The
Makefile can usually find the kernel source tree for the running kernel
by looking in the sensible places, it knows where to install modules,
and it is even able to get the right $(CFLAGS) from a configured kernel
tree.

The package includes a "compat.h", which rather like other similar files
("kcompat24.h") provides a 2.4-series API that works with all kernels
going back to 2.0, on all platforms I hope.  (I grepped the patches to
find out when each API change that I'm interested in occurred).  This
doesn't include network driver API though, just your basic PCI search
and read/write/ioctl/mmap/get_user interfaces.

The nice result is that, from a single source .tar.gz, "make" builds and
installs a driver module written with (more or less) the 2.4 API on any
kernel from 2.0 to 2.4, and the driver source is not full of ifdefs.

I suppose you're wondering where to get these files.  Mail me and I'll
see if there's much demand.

cheers,
-- 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: problem when booting 2.4.3 from a floppy disk

[Thomas Molina]

On Sat, 7 Apr 2001, Franois Dupoux wrote:

 Hi,

 I have a strange bug when trying to boot a kernel-2.4.3 (official release)
 from an 1.44 MB floppy disk. Just after the "Loading...", there is an
 infinite loop, and this message is printed:
 0200
 AX: 0212
 BX: BC00
 CX: 5101
 DX: 
 0200
 AX: 0212
 BX: BC00
 CX: 5101
 DX: 
 

Do you have any suspect hardware in your system?  The reason I ask is
that I have a part time job working in a computer shop where I build and
repair ix86 systems.  I've seen this occasionally when I use a 2.4.X
boot floppy to diagnose system problems.  It hasn't been consistent and
it hasn't happened often enough to correlate with anything else.

I've resolved to keep formal statistics on systems which exhibit this
problem so I would appreciate a cc on any followups to this.

-
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: goodbye

[Jeff Mcadams]

Also sprach Joseph Carter
Even in those cases where broadband users are given a choice of providers,
they have to know to ask for that choice since it is never offered and by
exercising that choice you will usually find the price to be at least
double if not triple - often through no fault of your chosen ISP.  If you
order DSL without your telco's ISP, you'll usually discover a great many
"fees" they only elect to charge if you don't cooperate.

This is getting to be *very* far off topic, so I'll post this and leave
it as it, but this is a subject that's very near and dear to me...

If your ILEC is doing the above (charging you more fees for DSL if
you're using an ISP other than their affiliated one), then I *HEARTILY*
encourage you (at least in the states) to contact your state Utilities
Commission.  Those actions are *blatently* illegal, and the state
utility commission is the organization that would handle that.

This advice obviously may not hold outside of the states.  If you'd like
to see an example of this type of action, check out case 1999-484 at the
Kentucky Public Service Commission at http://www.psc.state.ky.us.

Now, let's get back to actual kernel discussions where I can be totally
lost again.  :)
-- 
Jeff McAdamsEmail: [EMAIL PROTECTED]
Head Network Administrator  Voice: (502) 966-3848
IgLou Internet Services(800) 436-4456
-
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: goodbye

[David Woodhouse]

On Sat, 7 Apr 2001, Joseph Carter wrote:

 ORBS ... well, they called one of my old ISPs' mail an open relay when
 it wasn't and took 3 months to decide to rectify the situation and
 remove us from their list.  That doesn't instill much confidence.

I've heard that accusation many times, and on investigation, on the 
occasions I could be bothered, it's _always_ turned out to be false - 
generally caused by cluelessness on the part of the reporter.

It's very easy for ISPs to get landed in ORBS by customers who use the
outgoing relay for spam which they've wrongly accepted. The ISP's mail
relay doesn't have to accept the mail from the outside world and blatantly
forward it.

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