Re: pcmcia-issues with 2.2.18 & 2.4.0

[Pau Aliagas]

On 13 Feb 2001, Stig Brautaset wrote:

> I have a Xircom Combo CardBus (32 bit) 10/100 Ethernet Card + 56k
> Modem (didn't try the modem part) that I have not been able to run
> under 2.2.18 or 2.4.0. The weird part is that everything seems to load
> fine, and I am able to configure the card with an ip-address and
> everything. Only sad part is that I can not reach out to the world. I
> just get connection time-outs when trying to acces the 'net.

> BTW, The driver used by the card is tulip_cb, and the machine it runs
> on is a Dell Latitude CPx H500GT.

I use:
alias eth0 xircom_tulip_cb

and when this happens -90% if times when I boot and 100% of time when I
awake after a sleep- I just do the following:

ifconfig eth0 -promisc

and it works again.

Pau

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

startup error (pcmcia) 2.4.1

[Aaron Dewell]

Hi all,

I am observing a problem with 2.4.1 (and 2.4.0, all the -test releases
were fine) with pcmcia on my laptop.  At boot time, I have to pop the
ethernet card twice after the bus detection and before the card's 
module gets loaded or eth0 isn't found.  Actually, I don't have to do
it immediately, but I have to do it before trying to use the network,
it's just that this order keeps the init scripts happy. :)

Here's my environment:

Dell Latitude CPx
Ositech Jack of Spades (epic100 driver)
This is the kernel pcmcia support I'm using, not David Hinds'.  I have
  other problems with that package that are unrelated.
I tried with epic100 compiled in first, this iteration I thought I'd
  try as a module.  Same result except more irritating to work around.
2.4.1-ac9 same result, but I changed back to 2.4.1 for OSS

Attached is /proc/pci, /proc/interrupts, dmesg output (you can see where 
I ejected the card twice), and the kernel config.  Let me know if you
need anything else, and I am available for testing.

Aaron



PCI devices found:
  Bus  0, device   0, function  0:
Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 3).
  Master Capable.  Latency=32.  
  Prefetchable 32 bit memory at 0xf400 [0xf7ff].
  Bus  0, device   1, function  0:
PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 3).
  Master Capable.  Latency=32.  Min Gnt=140.
  Bus  0, device   3, function  0:
CardBus bridge: Texas Instruments PCI1225 (rev 1).
  IRQ 11.
  Master Capable.  Latency=168.  Max Lat=5.
  Non-prefetchable 32 bit memory at 0x1000 [0x1fff].
  Bus  0, device   3, function  1:
CardBus bridge: Texas Instruments PCI1225 (#2) (rev 1).
  IRQ 11.
  Master Capable.  Latency=168.  Min Gnt=192.Max Lat=5.
  Non-prefetchable 32 bit memory at 0x10001000 [0x10001fff].
  Bus  0, device   7, function  0:
Bridge: Intel Corporation 82371AB PIIX4 ISA (rev 2).
  Bus  0, device   7, function  1:
IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 1).
  Master Capable.  Latency=32.  
  I/O at 0x860 [0x86f].
  Bus  0, device   7, function  2:
USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 1).
  IRQ 11.
  Master Capable.  Latency=32.  
  I/O at 0xdce0 [0xdcff].
  Bus  0, device   7, function  3:
Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 3).
  Bus  0, device   8, function  0:
Multimedia audio controller: ESS Technology ES1983S Maestro-3i PCI Audio 
Accelerator (rev 16).
  IRQ 5.
  Master Capable.  Latency=32.  Min Gnt=2.Max Lat=24.
  I/O at 0xd800 [0xd8ff].
  Non-prefetchable 32 bit memory at 0xfaffe000 [0xfaff].
  Bus  1, device   0, function  0:
VGA compatible controller: ATI Technologies Inc 3D Rage P/M Mobility AGP 2x (rev 
100).
  IRQ 11.
  Master Capable.  Latency=32.  Min Gnt=8.
  Non-prefetchable 32 bit memory at 0xfd00 [0xfdff].
  I/O at 0xec00 [0xecff].
  Non-prefetchable 32 bit memory at 0xfcfff000 [0xfcff].
  Bus  2, device   0, function  0:
Ethernet controller: PCI device 10b8:0006 (rev 1).
  IRQ 11.
  Master Capable.  Latency=64.  Min Gnt=8.Max Lat=28.
  I/O at 0x1000 [0x10ff].
  Non-prefetchable 32 bit memory at 0x1080 [0x10800fff].
  Bus  2, device   0, function  1:
Serial controller: PCI device 10b8:0006 (rev 1).
  IRQ 11.
  I/O at 0x1400 [0x14ff].
  Non-prefetchable 32 bit memory at 0x10801000 [0x10801fff].


   CPU0   
  0: 905112  XT-PIC  timer
  1:  22318  XT-PIC  keyboard
  2:  0  XT-PIC  cascade
  3: 139898  XT-PIC  serial
  5:  12336  XT-PIC  ESS Maestro3 1998
  8:  1  XT-PIC  rtc
  9:  4  XT-PIC  acpi
 11: 481680  XT-PIC  Texas Instruments PCI1225, Texas Instruments PCI1225 
(#2), usb-uhci, eth0
 12:  23094  XT-PIC  PS/2 Mouse
 14:  37128  XT-PIC  ide0
 15:   1947  XT-PIC  ide1
NMI:  0 
ERR:  28136


Linux version 2.4.1 (acd@shirley) (gcc version 2.95.3 20010125 (prerelease)) #1 Fri 
Feb 2 22:07:46 MST 2001
BIOS-provided physical RAM map:
 BIOS-e820: 0009fc00 @  (usable)
 BIOS-e820: 0400 @ 0009fc00 (reserved)
 BIOS-e820: c000 @ 000c (reserved)
 BIOS-e820: 0feec000 @ 0010 (usable)
 BIOS-e820: 4000 @ 0ffec000 (reserved)
 BIOS-e820: 0006 @ 100a (reserved)
 BIOS-e820: 0020 @ ffe0 (reserved)
Scan SMP from c000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f for 65536 bytes.
Scan SMP from c009fc00 for 4096 bytes.
On node 0 totalpages: 65516
zone(0): 4096 pages.
zone(1): 61420 pages.
zone(2): 0 pages.
mapped APIC to e000 

NFSD die with 2.4.1

[Jean-Eric Cuendet]

Hi all,
I have a machine with kernel 2.4.1 . It exports some volume via NFS
(installed with RedHat 7.0 + custom 2.4.1 kernel)
NFSD dies unexpectedly with a Oops (see below).
At the beginning, I have 8 NFSD processes, but suddenly, they all die. I
can't see why it happens, because the machine is a production one and I
can't reboot it too often. But when I reboot, all is fine for a moment. And
suddenly, the 8 NFSD die altogether...
When running lsmod, nfsd.o has 8 locks even after NFSD died, so it's
impossible to make a rmmod (the 8 NFSD processes don't give their ressources
back).
Anyone have similar problems?
Thanks for any help on that topic

Bye
-jec
PS: I'm not in the list, so CC please.

The Oops: (repeated 8 times in the logs)
Feb  8 10:20:42 fatboy kernel: Unable to handle kernel NULL pointer
dereference at virtual address 
Feb  8 10:20:42 fatboy kernel:  printing eip:
Feb  8 10:20:42 fatboy kernel: 
Feb  8 10:20:42 fatboy kernel: *pde = 
Feb  8 10:20:42 fatboy kernel: Oops: 
Feb  8 10:20:42 fatboy kernel: CPU:0
Feb  8 10:20:42 fatboy kernel: EIP:0010:[acpi_exit+0/-1072693248]
Feb  8 10:20:42 fatboy kernel: EFLAGS: 00010282
Feb  8 10:20:42 fatboy kernel: eax:    ebx: c4fa803c   ecx: c29cc660
edx: c88a5450
Feb  8 10:20:42 fatboy kernel: esi: c5002ce4   edi: c4fa803c   ebp: c4fa803c
esp: c4fa7f38
Feb  8 10:20:42 fatboy kernel: ds: 0018   es: 0018   ss: 0018
Feb  8 10:20:42 fatboy kernel: Process nfsd (pid: 2690, stackpage=c4fa7000)
Feb  8 10:20:42 fatboy kernel: Stack: c88a54b4 c29cc660 8000 c4fad000
c88a8ba0 c4fa8014 c4fad000 c29cc660
Feb  8 10:20:42 fatboy kernel:a1ff8014 c889e5bb c4fad000 c4fa801c
c5002cc0 c4fad138 c88a8ba0 c5002d14
Feb  8 10:20:42 fatboy kernel:cf08 c4fad000 c4fa8014 c4fa6000
003dea49 c7f69ca0 c4fa6550 c5002cc0
Feb  8 10:20:42 fatboy kernel: Call Trace: [] []
[] [] [] [] []
Feb  8 10:20:42 fatboy kernel:[] [kernel_thread+35/48]
Feb  8 10:20:42 fatboy kernel:
Feb  8 10:20:42 fatboy kernel: Code:  Bad EIP value.



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



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

Re: [OT] Major Clock Drift

[Abramo Bagnara]

Andrew Morton wrote:
> 
> Alan Cox wrote:
> >
> > > > queued_writes=1;
> > > > return;
> > > > }
> > > > }
> > >
> > > Unfortunately, that means that if machine crashes in interrupt, it may
> > > "loose" printk message. That is considered bad (tm).
> >
> > The alternative is that the machine clock slides continually and the machine
> > is unusable. This is considered even worse by most people
> 
> Neither.  I was going to dust off my enhanced "bust_spinlocks"
> patch which sets a little flag when we're doing an
> oops, BUG(), panic() or die().  If the flag
> is set, printk() just punches through the lock.

IMO to treat this as an exception it's not the right solution.

A better alternative is to flush one entry of Alan proposed queue on the
following conditions:
- in_interrupt() is true AND queue is full

-- 
Abramo Bagnara   mailto:[EMAIL PROTECTED]

Opera Unica  Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project ishttp://www.alsa-project.org
sponsored by SuSE Linuxhttp://www.suse.com

It sounds good!
-
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.[01] and duron - unresolved symbol _mmx_memcpy

[Keith Owens]

On Tue, 13 Feb 2001 07:47:33 +0100, 
"Ph. Marek" <[EMAIL PROTECTED]> wrote:
>and the modules dependencies are not all set!
>make modules_install does not check for modules compilation - says
>"cp: file not found". I think that's because modules_install doesn't
>depend on the modules

Correct.  The current recursive makefile design means it is difficult
to get a definitive list of modules without excessive overhead.  So
modules_install assumes that you have compiled the modules already and
lets the 'cp' command fail.  The 2.5 Makefile redesign will get this
right.

>grep _mmx_memcpy /proc/ksyms
>   c01a4e20 _mmx_memcpy_R__ver__mmx_memcpy

Broken 2.4 makefile design.  http://www.tux.org/lkml/#s8-8
The 2.5 makefile redesign will kill this problem once and for all.

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

Routing table change indication...

[nomit kalidhar]

Hello,

I have been trying to get a solution to a minor problem but unfortunately i
have not been able to solve it or get some help on it and i am stuck up from
a long time.

Is there any way i can find out that there has been a change in the kernel
routing table in linux ?

In the file rtnetlink.h there is a rtm_flags feild RTM_F_NOTIFY which says
it notifies the user of route change but i have not been able to capture it
when there is a change in the routing table. 
Is this the right approach ??? 
please give some pointers..

with warm regards

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

[UPDATE] zerocopy + powder rule

[David S. Miller]

The only change is to update things to 2.4.2-pre3:

ftp://ftp.kernel.org/pub/linux/kernel/people/davem/zerocopy-2.4.2p3-1.diff.gz

All the reports I am getting now appear to be consistent,
and they all basically show me that:

1) There are no known bugs (as in things that crash the
   kernel or corrupt data)

2) The loopback etc. raw performance anomalies have been
   killed by the P-II Mendocino unaligned memcpy workaround.

3) The acenic/gbit performance anomalies have been cured
   by reverting the PCI mem_inval tweaks.

4) The zerocopy patches have a small yet non-neglible
   cpu usage cost for normal write/send/sendmsg.

If this truly is the current state of affairs, then I am
pretty happy as this is where I wanted things to be when
I first began to publish these zerocopy diffs.  The next
step is to begin profiling things heavily to see if we
can back some of that extra cpu usage the pages SKBs
afford us.

Due to the powder rule (Lake Tahoe received 6 or so feet of snow this
past weekend) I will be a bit quiet until Friday night.  However, I'll
be doing my own profiling of the zerocopy stuff on my laptop while I'm
up there.

Later,
David Snowboard 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: [ANNOUNCE] Animated framebuffer logo for 2.4.1

[Rafael E. Herrera]

> Not good enough in isolation.  Suppose the kernel freezes at a very early
> stage, such as while detecting the CPU(s) or PCI bridge - are your geeky
> reaction times fast enough to dismiss the logo in time to see the relevant
> messages?  I agree with others that this should be a boot option - and not
...
> Eg: in lilo.conf use append = "bootlogo" to turn the logo on (it should
> always be off by default, but can be turned on by distro makers or
> end-users) - but then if you type "linux nologo" at the LILO prompt, the
> "nologo" should over-ride the "bootlogo" so there's always a way to see all
> the messages.

In a PC and if using lilo, you always get a lilo prompt (if so
configured) after the initial power on tests. Passing a "nologo" option
to lilo would seem a reasonable way to turn the feature off. The same
could apply to othe boot loaders and other archs. By the way, suse 7.1
has a graphical boot, no animation though, just a big penguin; some
hacked lilo version, maybe?
-- 
 Rafael
-
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.1 swaps hardware addresses for ethernet cards

[al goldstein]

I have 2 ether cards 59x (eth0) and 509 (eth1). I have been adding 509
at boot in lilo.conf. Using this same config in 2.4.1 results in 
the hardware addresses for the cards to be swapped. If I remove 509 from 
Lilo I get the same result. Suggestions would be appreciated  

-
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: [UPDATE] zerocopy patch against 2.4.2-pre2

[David S. Miller]

Andrew Morton writes:
 > Changing the memory copy function did make some difference
 > in my setup.  But the performance drop on send(8k) is only approx 10%,
 > partly because I changed the way I'm testing it - `cyclesoak' is
 > now penalised more heavily by cache misses, and amount of cache
 > missing which networking causes cyclesoak is basically the same,
 > whether or not the ZC patch is applied.

Ok ok ok, but are we at the point where there are no sizable "over the
wire" performance anomalies anymore?  That is what is important, what
are the localhost bandwidth measurements looking like for you now
with/without the patch applied?

I want to reach a known state where we can conclude "over the wire is
about as good or better than before, but there is a cpu/cache usage
penalty from the zerocopy stuff".

This is important.  It lets us get to the next stage which is to
use your tools, numbers, and some profiling to see if we can get
some of that cpu overhead back.

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: WOL failure after shutdown

[Philipp Matthias Hahn]

On Sun, 11 Feb 2001, James Brents wrote:

> Sorry, I wrote that in a hurry. Its a 3Com PCI 3c905C Tornado. I can
> successfully use wakeonlan if I power off the machine immeadiatly after
> turning it on. Using the shutdown command, which it will when I need it
> to power back up, it will not work.
Look at the page of Donald Becker at
http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html
Last time there was a small program to reactivate the D3-ACPI state which
is necessary to wake your nic. I think it's calles "pci-config.c"

BYtE
Philipp
-- 
  / /  (_)__  __   __ Philipp Hahn
 / /__/ / _ \/ // /\ \/ /
//_/_//_/\_,_/ /_/\_\ [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: Major Clock Drift

[Josh Myer]

Hello again,

When i originally posted this, it was _highly_ OT. the machine in question
runs windows ME, but i figured the best place to find hardware gurus was
here.

the topic has rather degraded, and while i enjoy getting mail from alan,
the fact that it has nothing to do with me dampens the enthusiasm =)

if you're going to go changing the subject, at least mention framebuffers,
as that seems to be the common thread.

if you all could de-cc me on these, it'd be appreciated.
--
- josh

On Mon, 12 Feb 2001, george anzinger wrote:

> I may be off base here, but the problem as described below does _NOT_
> seem to be OT so I removed that from the subject line.  A clock drift
> change with an OS update is saying _something_ about the OS, not the
> hardware.  In this case it seems to be the 2.4.x OS that is loosing
> time.  I suspect the cause is some driver that is not being nice to the
> hardware, either by abusing the interrupt off code or locking up the bus
> or some such.  In any case I think it should _not_ be considered OT.
> 
> George

--
/jbm, but you can call me Josh. Really, you can.
  Rap-Rock is neither Modern nor Alternative.
 Not that I'm bitter.


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

Re: 2.4.[01] and duron - unresolved symbol _mmx_memcpy

[Ph. Marek]

>I need the output from these commands on a running 2.4.x kernel
>compiled for duron.
>
>grep _mmx_memcpy /proc/ksyms
>strings -a `/sbin/modprobe -l '*tulip*'` | grep _mmx_memcpy

Short version: it's caused by CONFIG_MODVERSIONS=y.
see the logs on the end.
If I turn it off and compile again, it works.

But: in isa-pnp there is another undefined symbol!
I even deleted drivers/pnp/isa-pnp*.o and made modules - 
didn't work.


thanks everybody!

###

BTW:

while compiling, I found several warnings:
fib_semantics.c: warning: indirect lcall without "*"
in lines 765, 850, 937, 976, 1008, 1040,1071, 1100, 1129, 1410, 1520

and the modules dependencies are not all set!
make modules_install does not check for modules compilation - says "cp: file not 
found". I think that's because modules_install doesn't depend on the modules


 long log for problem _mmx_memcpy not found.


gcc version 2.95.2 (19991024) (SuSE 7.0)


make mrproper
cp ../kernel-config .config
make oldconfig
make dep
make -j 2 bzlilo modules
make modules_install

reboot

modprobe floppy
/lib/modules/2.4.1/kernel/drivers/block/floppy.o: unresolved symbol 
irq_stat_R23f3d834
/lib/modules/2.4.1/kernel/drivers/block/floppy.o: unresolved symbol 
end_that_request_first_Rb6024308
/lib/modules/2.4.1/kernel/drivers/block/floppy.o: unresolved symbol 
blk_cleanup_queue_Ra477b792
/lib/modules/2.4.1/kernel/drivers/block/floppy.o: unresolved symbol 
blk_init_queue_Re2cb5b96
/lib/modules/2.4.1/kernel/drivers/block/floppy.o: unresolved symbol 
_mmx_memcpy_R15670e2d
/lib/modules/2.4.1/kernel/drivers/block/floppy.o: unresolved symbol 
end_that_request_last_Re8a8d3c5
/lib/modules/2.4.1/kernel/drivers/block/floppy.o: insmod 
/lib/modules/2.4.1/kernel/drivers/block/floppy.o failed
/lib/modules/2.4.1/kernel/drivers/block/floppy.o: insmod floppy failed


modprobe tulip
/lib/modules/2.4.1/kernel/drivers/net/tulip/tulip.o: unresolved symbol 
__netdev_watchdog_up_R4ca6a7b3
/lib/modules/2.4.1/kernel/drivers/net/tulip/tulip.o: unresolved symbol 
skb_over_panic_R1c20e36c
/lib/modules/2.4.1/kernel/drivers/net/tulip/tulip.o: unresolved symbol 
softnet_data_R8ab49beb
/lib/modules/2.4.1/kernel/drivers/net/tulip/tulip.o: unresolved symbol 
alloc_skb_R9db24f25
/lib/modules/2.4.1/kernel/drivers/net/tulip/tulip.o: unresolved symbol 
init_etherdev_Rec41243a
/lib/modules/2.4.1/kernel/drivers/net/tulip/tulip.o: unresolved symbol 
irq_stat_R23f3d834
/lib/modules/2.4.1/kernel/drivers/net/tulip/tulip.o: unresolved symbol 
__kfree_skb_R485f8550
/lib/modules/2.4.1/kernel/drivers/net/tulip/tulip.o: unresolved symbol 
netif_rx_R1e84c968
/lib/modules/2.4.1/kernel/drivers/net/tulip/tulip.o: unresolved symbol 
unregister_netdev_Rb02a0cb3
/lib/modules/2.4.1/kernel/drivers/net/tulip/tulip.o: unresolved symbol 
eth_type_trans_Rd53b3dc6
/lib/modules/2.4.1/kernel/drivers/net/tulip/tulip.o: unresolved symbol 
_mmx_memcpy_R15670e2d
/lib/modules/2.4.1/kernel/drivers/net/tulip/tulip.o: insmod 
/lib/modules/2.4.1/kernel/drivers/net/tulip/tulip.o failed
/lib/modules/2.4.1/kernel/drivers/net/tulip/tulip.o: insmod tulip failed

grep _mmx_memcpy /proc/ksyms
c01a4e20 _mmx_memcpy_R__ver__mmx_memcpy

strings -a `modprobe -l "*tulip*"` | grep _mmx_memcpy
_mmx_memcpy_R15670e2d

cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 3
model name  : AMD Duron(tm) Processor 
stepping: 1
cpu MHz : 656.471
cache size  : 64 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat 
pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips: 1310.72


cat .config

#
# Automatically generated by make menuconfig: don't edit
#
CONFIG_X86=y
CONFIG_ISA=y
# CONFIG_SBUS is not set
CONFIG_UID16=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set

Re: Linux 2.4.1-ac7

[Mike Galbraith]

On Mon, 12 Feb 2001, Marcelo Tosatti wrote:

> On Sun, 11 Feb 2001, Mike Galbraith wrote:
> 
> > On Sun, 11 Feb 2001, Rik van Riel wrote:
> > 
> > > On Sun, 11 Feb 2001, Mike Galbraith wrote:
> > > > On Sun, 11 Feb 2001, Mike Galbraith wrote:
> > > > 
> > > > > Something else I see while watching it run:  MUCH more swapout than
> > > > > swapin.  Does that mean we're sending pages to swap only to find out
> > > > > that we never need them again?
> > > > 
> > > > (numbers might be more descriptive)
> > > > 
> > > > user  :   0:07:21.70  54.3%  page in :   142613
> > > > nice  :   0:00:00.00   0.0%  page out:   155454
> > > > system:   0:03:40.63  27.1%  swap in :56334
> > > > idle  :   0:02:30.50  18.5%  swap out:   149872
> > > > uptime:   0:13:32.83 context :   519726
> > > 
> > > Indeed, in this case we send a lot more pages to swap
> > > than we read back in from swap, this means that the
> > > data is still sitting in swap space and was never needed
> > > again.
> > 
> > But it looks and feels (box is I/O hyper-saturated) like
> > it wrote it all to disk.
> > 
> > (btw, ac5 does more disk read.. ie the reduced cache size
> > of earlier kernels under heavy pressure does have it's price
> > with this workload.. quite visible in agregates.  looks to
> > be much cheaper than swap though.. for this workload)
> 
> Mike,
> 
> Could you please try the attached patch on top of latest Rik's patch?

Sure thing.. (few minutes later) no change.

-Mike

P.S.

(said I'd try other loads...)

I tried a different workload yesterday (only one because it took
the entire day to finish).  Glimpseindexing my webserver test area
played well.  As it was running, all of it's growth was pushed to
swap (very slow trickle for some hours).  I figured it would get
beaten up when it started actually using the dataset it was building,
but the way it used it, sending it to swap was perfect.  When it
started using, it paged in a small burst and then used this data
combined with a truckload of I/O (actual database building bit).
Since there were hours between dataset generation and subsequent
use, I had free use of about ~30 mb of pages for those hours.

Doing other things (like letting lynx webcrawl over my other box's
server area while it was running) were not even visible.. ie caused
no additional paging, so huge cache/buffers space (~100mb of 128mb)
was not plugging up the mana supply in any way.  What was in cache
_looked_ to be old cruft, and the system released these resources
just fine.  (so why won't it give up cache to gcc?  either the vm
doesn't like gcc, or I flat don't understand page aging yet. nod;)

Very boring test session.  I hope the results mean more to you than
they do to me ;-)

-
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: LILO and serial speeds over 9600

[H. Peter Anvin]

Adrian Levi wrote:
> 
> I usually lurk on the list and don't contribute but I would like to
> place my 2 bob in to the fro. Would a modified X-Modem protocol stack suit
> this operation? No sliding window and don't send anything until you
> receive an ack back?
> 

Not particularly.  Xmodem and TFTP are very similar.

Anyway, I repeat what I said about there being too many cooks in the
kitchen at the moment...

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

DMA blues... (Raid5 + Promise ATA/100)

[Jasmeet Sidhu]

I have a software raid setup using the latest kernel, but the system keeps 
crashing.

Each drive is connected to the respective ide port via ATA100 capable 
cables.  Each drive is a master..no slaves.  The configuration is that 
/dev/hdc is a hot spare and /dev/hd[e,g,i,k,m,o,q,s] are all setup as raid 
5.  These are all 75GB drives and are recognized as such.

I have searched the linux-kernel archives and saw many posts addressing the 
problems that I was experiencing, namely the freezing caused by the code in 
the body of delay_50ms() in drivers/ide/ide.c.  This was fixed in the 
current patch and as discussed earlier on the linux-kernel mailing list by 
using mdelay(50).  This fixed the problems to some extent, the system 
seemed very reliable and I did not get a single "DriveStatusError BadCRC" 
or a "DriveReady SeekComplete Index Error" for a while.  But after I had 
copied  a large amount of data to the raid, about 17GB, the system crashed 
completely and could only be recovered by a cold reboot.  Before using the 
latest patches, the system would usually crash after about 4-6GB of data 
had been moved.  Here are the log entries...

Feb 12 06:41:12 bertha kernel: hdo: dma_intr: status=0x53 { DriveReady 
SeekComplete Index Error }
Feb 12 06:41:12 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError 
BadCRC }
Feb 12 06:45:42 bertha kernel: hdo: timeout waiting for DMA
Feb 12 06:45:42 bertha kernel: hdo: ide_dma_timeout: Lets do it again!stat 
= 0x50, dma_stat = 0x20
Feb 12 06:45:42 bertha kernel: hdo: irq timeout: status=0x50 { DriveReady 
SeekComplete }
Feb 12 06:45:42 bertha kernel: hdo: ide_set_handler: handler not null; 
old=c01d0710, new=c01dac70
Feb 12 06:45:42 bertha kernel: bug: kernel timer added twice at c01d0585.
Feb 12 09:13:15 bertha syslogd 1.3-3: restart.

Let me know If I should post any additional information that might help in 
troubleshooting.  Is this a possible issue with the kernel code or is this 
a problem with hardware?  Any help is appreciated...

- Jasmeet Sidhu

Some other info that might help:

[root@bertha /root]# uname -a
Linux bertha 2.4.1-ac9 #1 Mon Feb 12 02:43:08 PST 2001 i686 unknown

Patches Applied to Kernel 2.4.1:
1) ide.2.4.1-p8.all.01172001.patch
2) patch-2.4.1-ac9

Asus A7V VIA KT133 and Onboard Promise ATA100 Controller (PDC20267)
1GHz AMD Thunderbird Athalon Processor
Four Promise PCI ATA100 Controllers (PDC20267)
Netgear GA620 Gigabit Ethernet Card

Boot Drive (Root + Swap)
hda: IBM-DTLA-307020, ATA DISK drive

Raid 5 Drives:
hdc: IBM-DTLA-307075, ATA DISK drive*SPARE*
hde: IBM-DTLA-307075, ATA DISK drive
hdg: IBM-DTLA-307075, ATA DISK drive
hdi: IBM-DTLA-307075, ATA DISK drive
hdk: IBM-DTLA-307075, ATA DISK drive
hdm: IBM-DTLA-307075, ATA DISK drive
hdo: IBM-DTLA-307075, ATA DISK drive
hdq: IBM-DTLA-307075, ATA DISK drive
hds: IBM-DTLA-307075, ATA DISK drive

-
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://vger.kernel.org/lkml/

Re: Problem with Netscape/Linux v.2.4.x [repeat] (MTU problem??)

[roger]

Re: Tom's message (below)


Thanks for your comments and description of symptoms. There may well
be an underlying common cause. Have you looked at the MTU/MSS
settings? 
 

>Do you get errors on your ppp0 interface?  Just curious.  Now that I know I'm 
>not just crazy maybe I'll look into it more.

I get a large number of RX errors (25%) when running telnet in console
mode (and very poor performance). Again this is confined to the 2.4.x
kernel. Oddly enough (with 2.4.x) there is little packet loss with telnet
under X. Similarly during a Netscape session (locked or not) there is
little packet loss registered


Roger Young.

...
Quoting [EMAIL PROTECTED]:

> Symptoms: The browser (Netscape or Lynx) will not download from remote
> web sites (dynamic ppp connection via external modem).
> 
> This looks to be a problem for my PC and the 2.4.x kernel,

It is very interesting that your are having this problem.  I have been having a 
similar problem with with 2.4.x on my laptop and had been unable to totally put 
it all together.  Here's my basic symtoms:

I can use the web quite normally for quite some time, but certain sites seem to 
be a trigger.  For example, if I go to IBM site and attempt to download they're 
JDK I immediately start getting errors on my ppp0 interface.  From that point 
on I get errors on other sites that previously were working, and the ppp0 
errors continue to increase throughout the entire duration of the call.  If I 
hang up and dial back everything goes back to normal again until I attempt to 
connect to the IBM download site again.

I originally thought this was a problem with my Xircom adapter, but if I fire 
up VMware I can use Windows 2000 to dial the same link and everything works 
fine to all the same sites.  This certainly implies that the serial layer is 
working properly since VMware still simply passes control of /dev/ttyS1 to the 
VM.

I was unable to reproduce this problem on the same system with kernel 2.2.18, 
all other things being the same.  I don't think my ISP uses trasparent proxies, 
but it is possible the remote IBM system uses some transparent web 
accelerator/load balancer.  Most of the IBM web site works properly, only the 
software download site seems to trigger the problem.  The problem does exhibit 
itself on other sites, but the IBM site is where began to realize it was 
repeatable.

Do you get errors on your ppp0 interface?  Just curious.  Now that I know I'm 
not just crazy maybe I'll look into it more.

Later,
Tom
-
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://vger.kernel.org/lkml/


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

Re: Software Mestizo Manifesto

[Michael Trausch]

Alan Cox wrote:
> 
> > > It seems that people are using open source software to do idiotic
> > > things. Many open source references were made in the article, I should
> > > see if the article is online at all to maybe be able to use it as a
> > > reference.
> >
> > You probably mean that one:
> > http://www.usatoday.com/life/cyber/tech/2001-02-05-binladen.htm
> 
> It has to be said that if Im blowing up planes full of people then I'm probably
> not concerned about software licensing issues or a visit from the BSA.
> 
> Alan

ROFL... This is true.  However, I've got to wonder how many people
actually like Bin Laden are out there.  And seeing as though they can't
seem to catch him, he must be doing a pretty damn good job at working on
the software issue.  We'll see how long it takes for the Government to
finally decide to violate the Freedom of Speech and require Master Keys.

And I'd hope that the Linux community doesn't bend over and succumb to
that, becuase thinking logically here, if the M-Key fell in the wrong
hands it could be used without court orders.  That's the whole thing
that the Government apparently doesn't realize.

Anywayz, we'll see what happens.  I'm off of the list currently so that
I can work on my own software project for now, but I'll probably be back
on within a matter of months, we'll see how bored I get if I get free
time from my software project :-P.

- 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://vger.kernel.org/lkml/

Re: [ANNOUNCE] Animated framebuffer logo for 2.4.1

[Peter Kundrat]

On Sun, Feb 11, 2001 at 11:47:18PM +0100, Pavel Machek wrote:
> > Right.  Add the option.  Default to "spew mode",
> > but make it easy for distributions to show people
> > a non-threatening boot process.  
> 
> Wrong.
> > 
> > Since, as Christophe mentions, the boot messages would
> > still be accessible via CTRL-ALT-F2, I don't see what 
> > the problem is with at least making this an option.
> 
> If your system crashes hard, you have only graphical logo to stare
> at. Any warning messages are hidden. Not good.

One good compromise would be a small scrolling window with a few last kernel messages.
Another option would be to turn it off for next boot (assuming it is reproducible), 
either by setting bootparam or pressing alt-f2 early enough.

pkx
-- 
Peter Kundrat
[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://vger.kernel.org/lkml/

Re: [ANNOUNCE] Animated framebuffer logo for 2.4.1

[Jonathan Morton]

>I've seen in recently purchased computers that the very initial
>messages, like memory test, are masked by some kind of picture or logo
>(example are the HP kayaks). They display a message saying that pressing
>ESC or some function key displays the messages. Why not having the same
>in this pretty boot option. I wouldn't mind not seeing all those
>messages.

Not good enough in isolation.  Suppose the kernel freezes at a very early
stage, such as while detecting the CPU(s) or PCI bridge - are your geeky
reaction times fast enough to dismiss the logo in time to see the relevant
messages?  I agree with others that this should be a boot option - and not
one that needs said option to switch it off (though there should be one).

Eg: in lilo.conf use append = "bootlogo" to turn the logo on (it should
always be off by default, but can be turned on by distro makers or
end-users) - but then if you type "linux nologo" at the LILO prompt, the
"nologo" should over-ride the "bootlogo" so there's always a way to see all
the messages.

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

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

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

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


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

gzipped executables

[Matt Stegman]

Is there any kernel patch that would allow Linux to properly recognize,
and execute gzipped executables?

I know I could use binfmt_misc to run a wrapper script:

decompress to /tmp/prog.decompressed
execute /tmp/prog.decompressed
rm /tmp/prog.decompressed

But that's not as clean, secure, or fast as the kernel transparently
decompressing & executing.  Is there a better way to do this?

  -Matt


-
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://vger.kernel.org/lkml/

Re: eepro100 + 2.2.18 + laptop problems

[CaT]

On Tue, Feb 13, 2001 at 09:26:38AM +0800, Andrey Savochkin wrote:
> On Sun, Feb 11, 2001 at 10:40:33PM +1100, CaT wrote:
> [snip]
> > Feb 11 22:30:18 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout 
>with(0x70)!
> 
> Please try the attached patch.
> Actually, it's designed to solve another problem, but may be your one has the
> same origin as that other.

Cool. Thanks. I recompiled the module and am trying it now. So far the
ethernet connection is fine but the above problem isn't reproducable with 
100% accuracy and so it'll take me a wee while before I decide '
a... that rocks my boat. it's fixed.'. :)

As such I'll try to give you a holler either in a few weeks time (if nothing
happens) or as soon as it breaks again.

-- 
CaT ([EMAIL PROTECTED])*** Jenna has joined the channel.
 speaking of mental giants..
 me, a giant, bullshit
 And i'm not mental
- An IRC session, 20/12/2000

-
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://vger.kernel.org/lkml/

Re: Problem with Netscape/Linux v.2.4.x [repeat] (MTU problem??)

[Tom Sightler]

Quoting [EMAIL PROTECTED]:

> Symptoms: The browser (Netscape or Lynx) will not download from remote
> web sites (dynamic ppp connection via external modem).
> 
> This looks to be a problem for my PC and the 2.4.x kernel,

It is very interesting that your are having this problem.  I have been having a 
similar problem with with 2.4.x on my laptop and had been unable to totally put 
it all together.  Here's my basic symtoms:

I can use the web quite normally for quite some time, but certain sites seem to 
be a trigger.  For example, if I go to IBM site and attempt to download they're 
JDK I immediately start getting errors on my ppp0 interface.  From that point 
on I get errors on other sites that previously were working, and the ppp0 
errors continue to increase throughout the entire duration of the call.  If I 
hang up and dial back everything goes back to normal again until I attempt to 
connect to the IBM download site again.

I originally thought this was a problem with my Xircom adapter, but if I fire 
up VMware I can use Windows 2000 to dial the same link and everything works 
fine to all the same sites.  This certainly implies that the serial layer is 
working properly since VMware still simply passes control of /dev/ttyS1 to the 
VM.

I was unable to reproduce this problem on the same system with kernel 2.2.18, 
all other things being the same.  I don't think my ISP uses trasparent proxies, 
but it is possible the remote IBM system uses some transparent web 
accelerator/load balancer.  Most of the IBM web site works properly, only the 
software download site seems to trigger the problem.  The problem does exhibit 
itself on other sites, but the IBM site is where began to realize it was 
repeatable.

Do you get errors on your ppp0 interface?  Just curious.  Now that I know I'm 
not just crazy maybe I'll look into it more.

Later,
Tom
-
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://vger.kernel.org/lkml/

Re: [PATCH] guard mm->rss with page_table_lock (241p11)

[Marcelo Tosatti]

On Mon, 12 Feb 2001, george anzinger wrote:

> Excuse me if I am off base here, but wouldn't an atomic operation be
> better here.  There are atomic inc/dec and add/sub macros for this.  It
> just seems that that is all that is needed here (from inspection of the
> patch).

Most functions which touch mm->rss already hold mm->page_table_lock (also
this functions are called more often and they use more CPU).

Making those functions use an atomic instruction just to optimize the
functions which do not lock mm->page_table_lock is not a good tradeoff.


-
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://vger.kernel.org/lkml/

Re: [ANNOUNCE] Animated framebuffer logo for 2.4.1

[Rafael E. Herrera]

I've seen in recently purchased computers that the very initial
messages, like memory test, are masked by some kind of picture or logo
(example are the HP kayaks). They display a message saying that pressing
ESC or some function key displays the messages. Why not having the same
in this pretty boot option. I wouldn't mind not seeing all those
messages.

-- 
 Rafael
-
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://vger.kernel.org/lkml/

Re: /proc/pci and cpuinfo

[David Weinehall]

On Mon, Feb 12, 2001 at 06:49:13PM -0800, xcp wrote:
> I have a machine here with a discrepency on the pci information
> in /proc/pci:
> us  0, device  20, function  0:
> Ethernet controller: 3Com Unknown device (rev 48).
>   Vendor id=10b7. Device id=7646.
>   Medium devsel.  IRQ 12.  Master Capable.  Latency=32.  Min
> Gnt=10.Max Lat=10.
>   I/O at 0xe400 [0xe401].
>   Non-prefetchable 32 bit memory at 0xdf00 [0xdf00].
> 
> from lspci:
> 00:14.0 Ethernet controller: 3Com Corporation 3cSOHO100-TX Hurricane (rev
> 30)
> 
> clearly /proc/pci is wrong!

Exactly where? bus 0, device 20, function 0 == hex(00:14.0)
Revision 48 = hex(30)

And both says that it's an Ethernet controller from 3Com. The fact that
the PCI-ID database in v2.2.18 isn't quite as extensive as the one in
lspci isn't something that makes your system malfunction...

> kernel is 2.2.18 on a P3-450 256mb.
> 
> Also, where does Linux detect and document the L2 or L1 cache size on a
> socket7 system?  On the pentium3 its in cpuinfo as cache_size, no such
> value exists on my P120 system.

That's probably because there is no simple way to query the processor for
this information. I'll let Peter Anvin answer this one, however.


/David Weinehall
  _ _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://vger.kernel.org/lkml/

Re: 2.2.19pre9 Kernel panic aic7xxx

[Doug Ledford]

Carlos Carvalho wrote:
> 
> Doug Ledford ([EMAIL PROTECTED]) wrote on 9 February 2001 16:41:
>  >The latest patch I sent Alan had both the hosts.c fix and some other fixes, so
>  >I'm thinking it hasn't made it into his 2.2.19pre9 kernel.  The next one
>  >should work fine as far as aic7xxx is concerned.
> 
> I think you should post your patch here, because pre9 is unusable
> without it. Well, at least for me, but this is the first time in
> almost 9 years that this happens. I have fairly standard 7890, in
> 2940, 2940UW adaptecs. If it doesn't work for me, it's likely to not
> work for many others. Since pre9 is urgent because of the security
> patches, it'd be good to upgrade as soon as possible.
> 
> Another alternative is that Alan posts the security part separately.
> Or that he releases pre10, including all Trond's fixes for nfs as
> well :-) :-)

The patches needed to get the aic7xxx driver working with 2.2.19-pre9 are now
up on my web page (see my sig).

-- 

 Doug Ledford <[EMAIL PROTECTED]>  http://people.redhat.com/dledford
  Please check my web site for aic7xxx updates/answers before
  e-mailing me about problems
-
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://vger.kernel.org/lkml/

Re: [PATCH] guard mm->rss with page_table_lock (241p11)

[george anzinger]

Excuse me if I am off base here, but wouldn't an atomic operation be
better here.  There are atomic inc/dec and add/sub macros for this.  It
just seems that that is all that is needed here (from inspection of the
patch).

George


Rasmus Andersen wrote:
> 
> On Mon, Jan 29, 2001 at 07:30:01PM -0200, Rik van Riel wrote:
> > On Mon, 29 Jan 2001, Rasmus Andersen wrote:
> >
> > > Please comment. Or else I will continue to sumbit it :)
> >
> > The following will hang the kernel on SMP, since you're
> > already holding the spinlock here. Try compiling with
> > CONFIG_SMP and see what happens...
> 
> You are right. Sloppy research by me :(
> 
> New patch below with the vmscan part removed.
> 
> diff -aur linux-2.4.1-pre11-clean/mm/memory.c linux/mm/memory.c
> --- linux-2.4.1-pre11-clean/mm/memory.c Sun Jan 28 20:53:13 2001
> +++ linux/mm/memory.c   Sun Jan 28 22:43:04 2001
> @@ -377,7 +377,6 @@
> address = (address + PGDIR_SIZE) & PGDIR_MASK;
> dir++;
> } while (address && (address < end));
> -   spin_unlock(>page_table_lock);
> /*
>  * Update rss for the mm_struct (not necessarily current->mm)
>  * Notice that rss is an unsigned long.
> @@ -386,6 +385,7 @@
> mm->rss -= freed;
> else
> mm->rss = 0;
> +   spin_unlock(>page_table_lock);
>  }
> 
> 
> @@ -1038,7 +1038,9 @@
> flush_icache_page(vma, page);
> }
> 
> +   spin_lock(>page_table_lock);
> mm->rss++;
> +   spin_unlock(>page_table_lock);
> 
> pte = mk_pte(page, vma->vm_page_prot);
> 
> @@ -1072,7 +1074,9 @@
> return -1;
> clear_user_highpage(page, addr);
> entry = pte_mkwrite(pte_mkdirty(mk_pte(page, vma->vm_page_prot)));
> +   spin_lock(>page_table_lock);
> mm->rss++;
> +   spin_unlock(>page_table_lock);
> flush_page_to_ram(page);
> }
> set_pte(page_table, entry);
> @@ -,7 +1115,9 @@
> return 0;
> if (new_page == NOPAGE_OOM)
> return -1;
> +   spin_lock(>page_table_lock);
> ++mm->rss;
> +   spin_unlock(>page_table_lock);
> /*
>  * This silly early PAGE_DIRTY setting removes a race
>  * due to the bad i386 page protection. But it's valid
> diff -aur linux-2.4.1-pre11-clean/mm/mmap.c linux/mm/mmap.c
> --- linux-2.4.1-pre11-clean/mm/mmap.c   Sat Dec 30 18:35:19 2000
> +++ linux/mm/mmap.c Sun Jan 28 22:43:04 2001
> @@ -879,8 +879,8 @@
> spin_lock(>page_table_lock);
> mpnt = mm->mmap;
> mm->mmap = mm->mmap_avl = mm->mmap_cache = NULL;
> -   spin_unlock(>page_table_lock);
> mm->rss = 0;
> +   spin_unlock(>page_table_lock);
> mm->total_vm = 0;
> mm->locked_vm = 0;
> while (mpnt) {
> diff -aur linux-2.4.1-pre11-clean/mm/swapfile.c linux/mm/swapfile.c
> --- linux-2.4.1-pre11-clean/mm/swapfile.c   Fri Dec 29 23:07:24 2000
> +++ linux/mm/swapfile.c Sun Jan 28 22:43:04 2001
> @@ -231,7 +231,9 @@
> set_pte(dir, pte_mkdirty(mk_pte(page, vma->vm_page_prot)));
> swap_free(entry);
> get_page(page);
> +   spin_lock(>vm_mm->page_table_lock);
> ++vma->vm_mm->rss;
> +   spin_unlock(>vm_mm->page_table_lock);
>  }
> 
>  static inline void unuse_pmd(struct vm_area_struct * vma, pmd_t *dir,
> 
> --
> Rasmus([EMAIL PROTECTED])
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
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://vger.kernel.org/lkml/

Re: Major Clock Drift

[george anzinger]

I may be off base here, but the problem as described below does _NOT_
seem to be OT so I removed that from the subject line.  A clock drift
change with an OS update is saying _something_ about the OS, not the
hardware.  In this case it seems to be the 2.4.x OS that is loosing
time.  I suspect the cause is some driver that is not being nice to the
hardware, either by abusing the interrupt off code or locking up the bus
or some such.  In any case I think it should _not_ be considered OT.

George



"Michael B. Trausch" wrote:
> 
> On Sun, 4 Feb 2001, Tom Eastep wrote:
> 
> > Thus spoke Michael B. Trausch:
> >
> > > On Sat, 3 Feb 2001, Josh Myer wrote:
> > >
> > > > Hello all,
> > > >
> > > > I know this _really_ isn't the forum for this, but a friend of mine has
> > > > noticed major, persistent clock drift over time. After several weeks, the
> > > > clock is several minutes slow (always slow). Any thoughts on the
> > > > cause? (Google didn't show up anything worthwhile in the first couple of
> > > > pages, so i gave up).
> > > >
> > >
> > > I'm having the same problem here.  AMD K6-II, 450 MHz, VIA Chipset, Kernel
> > > 2.4.1.
> > >
> >
> >
> > The video on this system is an onboard ATI 3D Rage LT Pro; I use vesafb
> > rather than atyfb because the latter screws up X.
> >
> 
> I'm not using any framebuffer on my machine (I have an ATI 3D Rage 128
> Pro, myself).  I use the standard 80x50 console, and X when I need
> it.  I'm about to put Debian on the system and see how that works and if I
> like it, I just got the .ISO of disc 1 downloaded (after about a week) and
> now it's burning.  (I hate having a 33.6 connection!)
> 
> However the clock drift didn't happen as much, if at all, with 2.2.xx
> kernels.  It's kept itself pretty well sane.  But now I'm losing something
> on the order of a half hour a week - that didn't happen before.
> 
> - Mike
> 
> ===
> Michael B. Trausch[EMAIL PROTECTED]
> Avid Linux User since April, '96!   AIM:  ML100Smkr
> 
>   Contactable via IRC (DALNet) or AIM as ML100Smkr
> ===
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
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://vger.kernel.org/lkml/

/proc/pci and cpuinfo

[xcp]

I have a machine here with a discrepency on the pci information
in /proc/pci:
us  0, device  20, function  0:
Ethernet controller: 3Com Unknown device (rev 48).
  Vendor id=10b7. Device id=7646.
  Medium devsel.  IRQ 12.  Master Capable.  Latency=32.  Min
Gnt=10.Max Lat=10.
  I/O at 0xe400 [0xe401].
  Non-prefetchable 32 bit memory at 0xdf00 [0xdf00].

from lspci:
00:14.0 Ethernet controller: 3Com Corporation 3cSOHO100-TX Hurricane (rev
30)

clearly /proc/pci is wrong!
kernel is 2.2.18 on a P3-450 256mb.

Also, where does Linux detect and document the L2 or L1 cache size on a
socket7 system?  On the pentium3 its in cpuinfo as cache_size, no such
value exists on my P120 system.

Thanks

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

Problem with Netscape/Linux v.2.4.x [repeat] (MTU problem??)

[roger]

Symptoms: The browser (Netscape or Lynx) will not download from remote
web sites (dynamic ppp connection via external modem).

This is a second post. The problem is still not resolved, but can now
be described in more detail, thanks to help given by David Woodhouse
(and others) and my ISP.

Description: Typically Netscape/Lynx will connect to a remote site but
will not download (it will hang indefinitely). When the browser is in 
such a hung state I am still able to ping/telnet/ftp to the URL. I have
no difficulty browsing with Linux 2.2.16. The problem only occurs with 
the 2.4.x kernels (2.4.0, 2.4.1).

My ISP operates a "transparent proxy server". According to tcpdump
TX packets from my machine are passed on by the proxy server to the
remote site, and the response from the latter is also logged by the 
server and passed on to me. However at that point there is no further
traffic from the proxy server.

This looks to be a problem for my PC and the 2.4.x kernel, however
the proxy server is also involved for the following reason: although
the browser is locked for almost all remote sites, I _am_ able to
connect to (the web page of) the proxy server itself. And after I do
this the browser is *unlocked*, and I can connect/download from any web
address. However this only lasts for 5 minutes or so, after which time
I must reconnect to the ISP proxy server. It is as though some information
has been cached and then lost after a time??

Now I include a note from my ISP:


>Roger, as we discussed I think the problem is to do with the MTU being =
>used for TCP connections in combination with the 2.4.1 kernel and PPP.
>
>At any rate, what we have found from the packet dumps are when you use =
>kernel 2.2.16 and you set the MTU at 552 our cache receives SYN packets =
>from your host with a "mss" option set at 512 (MTU =3D 552 - IP header =
>(20) - TCP header (20)) (and here is a packet dump of that):
>
>19:29:33.146337 131.203.xxx.yyy.1028 > www.google.com.www: S =
>1878153551:1878153551(0) win 15872 614080,nop,wscale 0> (DF)
>
>however, when your 2.4.1 kernel also set with an MTU of 552 does the =
>same thing, we find a "mss" option set at 536 (MTU =3D 576 - IP header - =
>TCP header) not 552! Here is the packet trace:
>
>19:34:17.559674 131.203.xxx.yyy.32771 > www.google.com.www: S =
>2178626299:2178626299(0) win 2144 175390,nop,wscale 0> (DF)
>
>There is more in the trace that indicates packets with data segment =
>sizes of 536 are not getting through, and when the data segment drops to =
>468 it does get through, likewise with the 2.2.16 kernel packets only =
>get as big as 512 and they all get through ok.
>
>This indicates that although the MTU is being set to 552, this is being =
>ignored by the 2.4.1 kernel and it is using 576 instead.  Kernel 2.2.16 =
>correctly uses the 552 as specified.


This is as far as my understanding of the situation reaches. There
appear to be 3 interdependent elements:

(1) the web browser
(2) the 2.4.x kernel
(3) the ISP transparent proxy server

Can anyone throw further light on this problem and/or suggest how to
fix it?  I'll say straight away that it has nothing to do with ECN
since this has not been selected as a kernel option.  Our analysis
seems to suggest that with 2.4.x the MTU is being incorrectly set, but
I don't know whether this is the whole explanation.

Thanks for any help you can provide...

Roger Young.
([EMAIL PROTECTED])

...
Motherboard: GA-6VX7-4X with Via Apollo Pro AGP chipset
CPU: P3/733 MHz
Memory: 256 Mb SDRAM
Modem: Dynalink 56K external modem. Serial port IRQ4, I/O 03F8-03FF

Distribution: Slackware 7.1
Linux kernel(s): 2.4.1/2.4.0/2.2.16
PPP: 2.4.0. MTU 552
Netscape: 4.76
XFree86: 4.0.2
modutils: 2.4.1
binutils: 2.10.1
-
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://vger.kernel.org/lkml/

[PATCH] 2.4.1 SCSI reservation/reset handling

[James Bottomley]

The attached patch corrects the linux kernel reservation handling.  Currently 
linux fails badly when presented with SCSI reservations in a clustered 
environment.  The patch also completes Doug Gilbert's reset injection system 
in the sg driver.  The patches have no effect on the main line SCSI code, but 
they are fairly essential to those of us working in clustering and using 
reservations for I/O fencing.

I've run the patch through a 12 hour stress test in a two node cluster using 
the sym53c875 and aic7xxx (AHA 2944/UW) SCSI cards.

James Bottomley



Index: linux/drivers/scsi/scsi.c
===
RCS file: /home/cvs/CVSROOT/linux/2.4/drivers/scsi/scsi.c,v
retrieving revision 1.1.1.4
retrieving revision 1.1.1.4.6.4
diff -u -r1.1.1.4 -r1.1.1.4.6.4
--- linux/drivers/scsi/scsi.c   2000/11/30 17:19:15 1.1.1.4
+++ linux/drivers/scsi/scsi.c   2001/02/12 04:58:05 1.1.1.4.6.4
@@ -146,7 +146,12 @@
  */
 extern void scsi_old_done(Scsi_Cmnd * SCpnt);
 extern void scsi_old_times_out(Scsi_Cmnd * SCpnt);
+extern int scsi_old_reset(Scsi_Cmnd *SCpnt, unsigned int flag);
 
+/* 
+ * private interface into the new error handling code
+ */
+extern int scsi_new_reset(Scsi_Cmnd *SCpnt, unsigned int flag);
 
 /*
  * Function:scsi_initialize_queue()
@@ -2657,6 +2662,67 @@
  */
scsi_release_commandblocks(SDpnt);
 kfree(SDpnt);
+}
+
+/* Dummy done routine.  We don't want the bogus command used for the
+ * bus/device reset to find its way into the mid-layer so we intercept
+ * it here */
+static void
+scsi_reset_provider_done_command(Scsi_Cmnd *SCpnt) {
+/* Empty function.  Some low level drivers will call scsi_done
+ * (and end up here), others won't bother */
+}
+
+
+/*
+ * Function:   scsi_reset_provider
+ *
+ * Purpose:Send requested reset to a bus or device at any phase.
+ *
+ * Arguments:  device  - device to send reset to
+ * flag - reset type (see scsi.h)
+ *
+ * Returns:SUCCESS/FAILURE.
+ *
+ * Notes:  This is used by the SCSI Generic driver to provide
+ * Bus/Device reset capability.
+ */
+int
+scsi_reset_provider(Scsi_Device *dev, int flag)
+{
+int rtn;
+Scsi_Cmnd *SCpnt;
+
+/* get a dummy command to issue the reset to */
+SCpnt = scsi_allocate_device(dev, 1, 1);
+/* NULL indicates interrupt */
+if(SCpnt == NULL)
+return -EINTR;
+
+/* initialise the command */
+memset(>cmnd, '\0', sizeof(SCpnt->cmnd));
+
+SCpnt->channel = dev->channel;
+SCpnt->lun = dev->lun;
+SCpnt->target = dev->id;
+SCpnt->owner = SCSI_OWNER_MIDLEVEL;
+SCpnt->scsi_done = scsi_reset_provider_done_command;
+SCpnt->done = NULL;
+SCpnt->reset_chain = NULL;
+
+SCpnt->internal_timeout = NORMAL_TIMEOUT;
+SCpnt->abort_reason = DID_ABORT;
+
+if(dev->host->hostt->use_new_eh_code) {
+rtn = scsi_new_reset(SCpnt, flag);
+} else {
+rtn = scsi_old_reset(SCpnt, flag);
+}
+if(timer_pending(>eh_timeout))
+scsi_delete_timer(SCpnt);
+scsi_release_command(SCpnt);
+
+return rtn;
 }
 
 /*
Index: linux/drivers/scsi/scsi.h
===
RCS file: /home/cvs/CVSROOT/linux/2.4/drivers/scsi/scsi.h,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 scsi.h
--- linux/drivers/scsi/scsi.h   2001/01/11 16:39:27 1.1.1.3
+++ linux/drivers/scsi/scsi.h   2001/02/12 17:58:41
@@ -842,6 +842,14 @@
remove_wait_queue(QUEUE, );\
current->state = TASK_RUNNING;  \
 }; }
+/* reset request from external source (private to sg.c, scsi.c
+ * scsi_error.c and scsi_obsolete.c)
+ * */
+#define SCSI_TRY_RESET_DEVICE  1
+#define SCSI_TRY_RESET_BUS 2
+#define SCSI_TRY_RESET_HOST3
+
+extern int scsi_reset_provider(Scsi_Device *, int);
 
 #endif
 
Index: linux/drivers/scsi/scsi_error.c
===
RCS file: /home/cvs/CVSROOT/linux/2.4/drivers/scsi/scsi_error.c,v
retrieving revision 1.1.1.2
retrieving revision 1.1.1.2.6.1
diff -u -r1.1.1.2 -r1.1.1.2.6.1
--- linux/drivers/scsi/scsi_error.c 2000/09/30 17:38:23 1.1.1.2
+++ linux/drivers/scsi/scsi_error.c 2001/02/11 17:33:42 1.1.1.2.6.1
@@ -996,9 +996,17 @@
case DID_SOFT_ERROR:
goto maybe_retry;
 
+case DID_ERROR:
+if(msg_byte(SCpnt->result) == COMMAND_COMPLETE 
+   && status_byte(SCpnt->result) == RESERVATION_CONFLICT)
+/* execute reservation conflict processing
+   code lower down */
+break;
+/* fall through */
+
+
case DID_BUS_BUSY:
case DID_PARITY:
-   case DID_ERROR:
goto maybe_retry;
case DID_TIME_OUT:

Test - Please Disregard

[linux]

Test.

-
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://vger.kernel.org/lkml/

Re: VT82C597 + Maxtor UDMA failures

[Ryan Hayle]

Hey Vojtech,
Thanks for your response.  I tried using 2.4.2-pre3 and the same problem
occurs, in exactly the same manner.  The only other problem I can identify
is a boot message:

IRQ routing conflict in pirq table for device 00:0a.0

lspci reveals that 00:0a.0 is my network card:

00:0a.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone]

But I'm not sure why that would have any problem, as it works perfectly,
and I don't see any conflicts:

/proc/interrupts:
   CPU0
  0: 416389  XT-PIC  timer
  1:  18840  XT-PIC  keyboard
  2:  0  XT-PIC  cascade
  8:  1  XT-PIC  rtc
  9: 135491  XT-PIC  soundblaster
 10:  83005  XT-PIC  eth0
 11: 386543  XT-PIC  nvidia
 12: 121397  XT-PIC  PS/2 Mouse
 14:   3967  XT-PIC  ide0
 15: 249701  XT-PIC  ide1
NMI:  0
ERR:  0

If you would like any other info, or have any ideas, please let me
know.  The cable seems to be fine, and like I said it works okay in
Windows.

Thanks again,
Ryan


On Fri, 9 Feb 2001, Vojtech Pavlik wrote:

> Hi!
> 
> Please try 2.4.2-pre kernels, they have a newer VIA IDE driver.
> 
> Vojtech
> 
> On Wed, Feb 07, 2001 at 03:37:49PM -0600, Ryan Hayle wrote:
> > I'm trying to troubleshoot a failure with my Maxtor hard drive that I have
> > experienced consistantly, even in the 2.2.x kernels (I'm now running
> > 2.2.1-test10, .config is attached).  It detects all of my drives fine:
> > 
> > block: queued sectors max/low 126786kB/95090kB, 384 slots per queue
> > Uniform Multi-Platform E-IDE driver Revision: 6.31
> > ide: Assuming 33MHz system bus speed for PIO modes; override with
> > idebus=xx
> > VP_IDE: IDE controller on PCI bus 00 dev 39
> > VP_IDE: chipset revision 6
> > VP_IDE: not 100% native mode: will probe irqs later
> > VP_IDE: VIA vt82c586b IDE UDMA33 controller on pci0:7.1
> > ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:DMA, hdb:DMA
> > ide1: BM-DMA at 0xe008-0xe00f, BIOS settings: hdc:DMA, hdd:DMA
> > hda: Maxtor 52049U4, ATA DISK drive
> > hdb: WDC AC31200F, ATA DISK drive
> > ide: Assuming 33MHz system bus speed for PIO modes; override with
> > idebus=xx
> > hdc: Maxtor 90680D4, ATA DISK drive
> > hdd: ATAPI 40X CDROM DRIVE, ATAPI CD/DVD-ROM drive
> > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> > ide1 at 0x170-0x177,0x376 on irq 15
> > hda: 40020624 sectors (20491 MB) w/2048KiB Cache, CHS=2491/255/63,
> > UDMA(33)
> > hdb: 2503872 sectors (1282 MB) w/64KiB Cache, CHS=621/64/63, DMA
> > hdc: 13281408 sectors (6800 MB) w/256KiB Cache, CHS=13176/16/63, UDMA(33)
> > hdd: ATAPI 40X CD-ROM drive, 128kB Cache, UDMA(33)
> > 
> > And then all the services load up, etc.  Once I log in, though, either in
> > gdm or on the console, it will pause for around 10-15 seconds, and then
> > display this:
> > 
> > hdc: timeout waiting for DMA
> > ide_dmaproc: chipset supported ide_dma_timeout func only: 14
> > hdc: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
> > hdc: status timeout: status=0xd0 { Busy }
> > hdc: DMA disabled
> > hdd: DMA disabled
> > hdc: drive not ready for command
> > ide1: reset: success
> > 
> > (hdc is the problem, obviously)  Once this occurs, the system appears to
> > run normally.  I don't really care about hdd (cdrom), although I figure
> > they are probably related somehow.
> > 
> > Windows is able to use UDMA fine on this drive.  Also note that this isn't
> > a UDMA66 drive, and I'm not trying to use it (most of the other posts
> > I've seen with similar problems were related to 66).  
> > 
> > Drives on ide0 seem to run in udma mode just fine, also...
> > 
> > Here's /proc/ide/via:
> > 
> > --VIA BusMastering IDE Configuration
> > Driver Version: 2.1e
> > South Bridge:   VIA vt82c586b rev 0x47
> > Command register:   0x7
> > Latency timer:  64
> > PCI clock:  33MHz
> > Master Read  Cycle IRDY:1ws
> > Master Write Cycle IRDY:1ws
> > FIFO Output Data 1/2 Clock Advance: off
> > BM IDE Status Register Read Retry:  on
> > Max DRDY Pulse Width:   No limit
> > ---Primary IDE---Secondary IDE--
> > Read DMA FIFO flush:   on  on
> > End Sect. FIFO flush:  on  on
> > Prefetch Buffer:   on  on
> > Post Write Buffer: on  on
> > FIFO size:  8   8
> > Threshold Prim.:  1/2 1/2
> > Bytes Per Sector: 512 512
> > Both channels togth:  yes yes
> > ---drive0drive1drive2drive3-
> > BMDMA enabled:yes   yesnono
> > Transfer Mode:   UDMA   DMA/PIO  UDMA  UDMA
> > Address Setup:   30ns   

Re: eepro100 + 2.2.18 + laptop problems

[Andrey Savochkin]

On Sun, Feb 11, 2001 at 10:40:33PM +1100, CaT wrote:
[snip]
> Feb 11 22:30:18 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout 
>with(0x70)!

Please try the attached patch.
Actually, it's designed to solve another problem, but may be your one has the
same origin as that other.

Best regards
Andrey


Index: eepro100.c
===
RCS file: /home/oursoft/eepro100/eepro100.c,v
retrieving revision 1.20.2.13
diff -u -r1.20.2.13 eepro100.c
--- eepro100.c  2000/09/14 04:41:58 1.20.2.13
+++ eepro100.c  2001/02/13 01:22:07
@@ -726,6 +726,7 @@
   This takes less than 10usec and will easily finish before the next
   action. */
outl(PortReset, ioaddr + SCBPort);
+   inl(ioaddr + SCBPort);
/* Honor PortReset timing. */
udelay(10);
 
@@ -814,6 +815,7 @@
 #endif  /* kernel_bloat */
 
outl(PortReset, ioaddr + SCBPort);
+   inl(ioaddr + SCBPort);
/* Honor PortReset timing. */
udelay(10);
 
@@ -1037,6 +1039,9 @@
/* Set the segment registers to '0'. */
wait_for_cmd_done(ioaddr + SCBCmd);
outl(0, ioaddr + SCBPointer);
+   /* impose a delay to avoid a bug */
+   inl(ioaddr + SCBPointer);
+   udelay(10);
outb(RxAddrLoad, ioaddr + SCBCmd);
wait_for_cmd_done(ioaddr + SCBCmd);
outb(CUCmdBase, ioaddr + SCBCmd);
@@ -1298,6 +1303,7 @@
end_bh_atomic();
/* Reset the Tx and Rx units. */
outl(PortReset, ioaddr + SCBPort);
+   inl(ioaddr + SCBPort);
/* We may get spurious interrupts here.  But I don't think that they
   may do much harm.  1999/12/09 SAW */
udelay(10);

Re: fwd: Mylex dac960 not SMP-safe?

[Olli Lounela]

On Tue, Feb 13, 2001 at 02:28:06AM +0200, Olli Lounela wrote:
>
> Okay, I goofed. The motherboard reset the interrupts to the same old stoopid
> values when I shuffled the cards. I have now separated them, no difference.

Progress: not only did I goof, I was wrong too.

This time it booted once the network timed out, but the eepro is not
functioning properly; it seems unable to receive. I can see it sends alright
from the dhcpserver log.

IRQ's are now

   Mylex10
   aic7880  17
   eepro18
   VGA  19

Mylex still hangs without nosmp. IRQ routing problem in APIC initialization,
maybe?

Darn this old piece of junk is slow to boot...

-- 
Olli   ...and he thought I'm serious! Hahahaha...
-
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://vger.kernel.org/lkml/

[PATCH] swapin flush cache bug

[Marcelo Tosatti]

Hi,

Niibe Yutaka noted (and added an entry on the MM bugzilla system) that
cache flushing on do_swap_page() is buggy. Here: 

---
struct page *page = lookup_swap_cache(entry);
pte_t pte;

if (!page) {
lock_kernel();
swapin_readahead(entry);
page = read_swap_cache(entry);
unlock_kernel();
if (!page)
return -1;

flush_page_to_ram(page);
flush_icache_page(vma, page);
}

mm->rss++;
--

If lookup_swap_cache() finds a page in the swap cache, and that page was
in memory because of the swapin readahead, the cache is not flushed.

Here is a patch to fix the problem by always flushing the cache including
for pages in the swap cache:

--- linux.orig/mm/memory.c.orig   Thu Feb  8 10:52:20 2001
+++ linux/mm/memory.cThu Feb  8 10:54:07 2001
@@ -1033,12 +1033,12 @@
unlock_kernel();
if (!page)
return -1;
-
-   flush_page_to_ram(page);
-   flush_icache_page(vma, page);
}
 
mm->rss++;
+
+   flush_page_to_ram(page);
+   flush_icache_page(vma, page);
 
pte = mk_pte(page, vma->vm_page_prot);




-
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://vger.kernel.org/lkml/

Re: [PATCH] new version of the starfire driver for 2.2.19pre

[Ion Badulescu]

On Mon, 12 Feb 2001, Ion Badulescu wrote:

> Here is an incremental patch from the version in 2.2.19pre10 to the latest 
> version of starfire.c. Please apply, the 2219pre10 version doesn't work if 
> compiled-in (because drivers/net builds net.a not net.o). It also fixes 
> the MII interface detection problem mentioned by Don Becker.
> 
> The patch is longish, but it's mostly whitespace and moving code around. 
> It also removes all the code that's #ifdef ZEROCOPY, since Jeff Garzik 
> doesn't want it in 2.4.x and it definitely can't work in 2.2.x.

And of course I forgot to diff Space.c. Patch attached, sorry about that.

Thanks,
Ion

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

--- /usr/src/local/linux-2.2.18-vanilla/drivers/net/Space.c Sun Dec 10 16:49:42 
2000
+++ linux-2.2.18/drivers/net/Space.cSun Feb 11 14:53:02 2001
@@ -126,6 +126,7 @@
 extern int rcpci_probe(struct device *);
 extern int dmfe_probe(struct device *);
 extern int sktr_probe(struct device *dev);
+extern int starfire_probe(struct device *dev);
 
 /* Gigabit Ethernet adapters */
 extern int yellowfin_probe(struct device *dev);
@@ -277,9 +278,12 @@
 #ifdef CONFIG_VIA_RHINE
{via_rhine_probe, 0},
 #endif
-#ifdef CONFI_NET_DM9102
+#ifdef CONFIG_NET_DM9102
{dmfe_probe, 0},
-#endif 
+#endif
+#ifdef CONFIG_ADAPTEC_STARFIRE
+   {starfire_probe, 0},
+#endif
{NULL, 0},
 };
 

-
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://vger.kernel.org/lkml/

SO_RCVTIMEO, SO_SNDTIMEO

[Chris Evans]

Hi,

I notice the entities in the subject line have appeared in Linux 2.4.

What is their functional specification? I guess they trigger if no bytes
are received/send within a consecutive period. How does the app get the
error? -EPIPE for a blocking read/write? If so, does SIGPIPE
get raised? Or is -ETIMEDOUT used? ...

TIA,
Chris

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

Re: fwd: Mylex dac960 not SMP-safe?

[Olli Lounela]

On Tue, Feb 13, 2001 at 01:55:01AM +0200, Olli Lounela wrote:
> 
> Finally got 2.4.2pre3 nosmp boot dmesg, attached. Also current lspci -vvvxx

Okay, I goofed. The motherboard reset the interrupts to the same old stoopid
values when I shuffled the cards. I have now separated them, no difference.
-- 
Olli   ...and he thought I'm serious! Hahahaha...
-
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://vger.kernel.org/lkml/

APIC problems

[David D.W. Downey]

I asked for some information and seems at least 1 person took the "tone"
of my email to mean I had an attitude while asking.

On the premise that perhaps I did ask with an attitude, even if I don't
see it, I'd like to ask for some information.

Here is a synopsis of what I'm running up against and what I've done
to try to fix it.

I have the Abit VP6 mainboard loaded with 1GB of RAm and dual PIII-733s.
On heavy I/O I get "APIC error on CPU# ##(##)" (replace #'s with CPUID#
and APIC error code)

In this case I'm getting 08(02) 04(08) 04(02) 02(04) 02(08) as the
returned codes. Now the person that responded told me that it meant I had
crap hardware. The Abit VP6 is an extremely popular board in the linux
crowd from what I've been able to glean through IRC channels and other
conversations. If the board was truly that bad, I have a hard time
believing it would be as popular as it is. (OK, so this comment is
subjective. :) )

Tracing back through the kernel code I found the list of error codes in
apic.c. I'm specifically looking at function...

asmlinkage smp_error_interrupt(void)

>From what I understand of C, the error code returned is generated
by a call to apic_read(APIC_ESR) which stores the value in 'v', sets the
ESR register to 0 via the call to apic_write(APIC_ESR, 0);, regets the
value via apic_read(APIC_ESR); yet again and stores that value in 'v1',
acknowledges the IRQ service call, the APIC controller made, and finally
increments the irq error count.


It appears that it's using the modulus value as the actual error code.
OK, so now that I know what the error code is but I still don't see how it
can return a value of 08 which is not listed as an error code.

I can see that the error codes are actually the values of ESR both before
and after the apic_write() call. I see that the codes are the modulus'd
value before and after the apic_write call. What I'm not understanding is
how to translate that into a valid ID for determining what the exact error
is. In this instance 08 doesn't appear to be a valid return. Or am I
missing something here??


Here are the APIC errors

APIC error on CPU0: 00(08)
APIC error on CPU1: 00(08)
APIC error on CPU1: 08(08)
APIC error on CPU1: 08(08)
APIC error on CPU1: 08(08)
APIC error on CPU0: 08(08)
APIC error on CPU0: 08(08)
APIC error on CPU0: 08(08)
APIC error on CPU0: 08(08)
APIC error on CPU1: 08(08)
APIC error on CPU1: 08(08)
APIC error on CPU0: 08(08)
APIC error on CPU1: 08(02)
APIC error on CPU1: 02(02)
APIC error on CPU1: 02(08)
APIC error on CPU0: 08(02)
APIC error on CPU1: 08(01)
APIC error on CPU0: 02(02)
APIC error on CPU1: 01(02)
APIC error on CPU0: 02(02)
APIC error on CPU1: 02(04)
APIC error on CPU1: 04(04)
APIC error on CPU1: 04(02)
APIC error on CPU1: 02(08)
APIC error on CPU1: 08(02)
APIC error on CPU1: 02(02)



When I review my dmesg I see the following error as well.


mapped IOAPIC to d000 (fec0)
CALLIN, before setup_local_APIC().
ENABLING IO-APIC IRQs
...changing IO-APIC physical APIC ID to 2 ... ok.
init IO_APIC IRQs
 IO-APIC (apicid-pin) 2-0, 2-9, 2-10, 2-11, 2-20, 2-21, 2-22, 2-23 not connected.
number of IO-APIC #2 registers: 24.
testing the IO APIC...
IO APIC #2..
...: physical APIC id: 02
... : IO APIC version: 0011
WARNING: unexpected IO-APIC, please mail
calibrating APIC timer ...
PCI->APIC IRQ transform: (B0,I7,P3) -> 19
PCI->APIC IRQ transform: (B0,I7,P3) -> 19
PCI->APIC IRQ transform: (B0,I10,P0) -> 17
PCI->APIC IRQ transform: (B0,I12,P0) -> 19
PCI->APIC IRQ transform: (B0,I13,P0) -> 18
PCI->APIC IRQ transform: (B0,I14,P0) -> 18
PCI->APIC IRQ transform: (B1,I0,P0) -> 16



After about 50% completion of creating a 1.0GB file, the system will lock
up with no errors or warnings. I can flip VTs, but if I try to log in it
will not respond, nor will any commands like a simple ls -al $HOME/


The controller my drives sit on is the HPT370 ATA100/RAID controller
Info is below

HPT370: IDE controller on PCI bus 00 dev 70
HPT370: chipset revision 3
HPT370: not 100% native mode: will probe irqs later
HPT370: ATA-66/100 forced bit set (WARNING)!!
ide2: BM-DMA at 0xc800-0xc807, BIOS settings: hde:DMA, hdf:DMA
HPT370: ATA-66/100 forced bit set (WARNING)!!
ide3: BM-DMA at 0xc808-0xc80f, BIOS settings: hdg:DMA, hdh:pio
hde: WDC WD300BB-00AUA1, ATA DISK drive
hdf: WDC WD300BB-00AUA1, ATA DISK drive
hdg: WDC WD300BB-00AUA1, ATA DISK drive
ide2 at 0xb800-0xb807,0xbc02 on irq 18
ide3 at 0xc000-0xc007,0xc402 on irq 18
hde: 58633344 sectors (30020 MB) w/2048KiB Cache, CHS=58168/16/63, UDMA(100)
hdf: 58633344 sectors (30020 MB) w/2048KiB Cache, CHS=58168/16/63, UDMA(100)
hdg: 58633344 sectors (30020 MB) w/2048KiB Cache, CHS=58168/16/63, UDMA(100)


I am not using the RAID ability, simply the ATA100. hdparm -t -T shows
that my buffered disk reads sit at around 32MB/s. I get excellent speed on
files smaller than 512MB. No lock ups, no problems. Go over the 512MB or
thereabouts (sometimes it locks around 

Re: LILO and serial speeds over 9600

[H. Peter Anvin]

James Sutherland wrote:
> >
> > Well, any time there is a network there needs to be buffering, if you
> > want to have any kind of ACK protocol.
> 
> Yes, but only the last packet sent, if you limit to one packet at a
> time... Shouldn't be a problem, even for the smallest code.
> 

Of course.  Either way I was planning to use the TCP technique of ACKing
a byte position, not a packet number (unlike TFTP.)

Anyway, perhaps we should take this off linux-kernel and reconvene once
we get a sourceforge list up.

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://vger.kernel.org/lkml/

Re: LILO and serial speeds over 9600

[H. Peter Anvin]

Alan Cox wrote:
> 
> > I'm sure you can.  That doesn't mean it's the right solution.
> 
> And the UDP proposal will be at least as big if it does retransmits, and if
> it doesnt , its junk. It will also need as much buffering, if not the same
> packing trick
> 

Within limits, you're right, of course.  I suspect it won't be *as* big
(especially not if it's talking to a PXE card which does the IP and UDP
layers in firmware, but not TCP), but I still suspect better tradeoffs
can be made this way.

That being said, I'll look at TCP as well.

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://vger.kernel.org/lkml/

Re: LILO and serial speeds over 9600

[James Sutherland]

On Mon, 12 Feb 2001, H. Peter Anvin wrote:

> James Sutherland wrote:
> > >
> > > Depends on what the client can handle.  For the kernel, that might be
> > > true, but for example a boot loader may only have a few K worth of buffer
> > > space.
> > 
> > Fortunately, the bulky stuff (printk's from the booting kernel) will be
> > going from the boot loader to the server, and should be buffered there
> > OK until they can be processed. Only the stuff sent to the client will
> > need buffering, and that should be simple keystrokes...
> 
> Well, any time there is a network there needs to be buffering, if you
> want to have any kind of ACK protocol.

Yes, but only the last packet sent, if you limit to one packet at a
time... Shouldn't be a problem, even for the smallest code.


James.

-
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://vger.kernel.org/lkml/

Re: LILO and serial speeds over 9600

[H. Peter Anvin]

Tim Wright wrote:
> 
> Yup,
> those who fail to learn from TCP are doomed to re-invent it, badly, at the
> wrong level .
> Seriously, the console subsystem on the Sequent (now IBM) NUMA-Q systems
> originally used UDP. It wound up as a serious mess. We changed to TCP.
> I'll admit that the NUMA-Q console subsystem does more than what is being
> proposed here currently, but it's likely to grow.
> In general UDP is only appropriate if you *can* afford to drop data.
> Did RDP ever get anywhere ?
> 

That's the whole crux of the matter.  For something like this, you *will*
drop data under certain circumstances.  I suspect it's better to have
this done in a controlled manner, rather than stop completely, which is
what TCP would do.

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://vger.kernel.org/lkml/

Re: opl3sa not detected anymore

[Chris Funderburg]

On Mon, 12 Feb 2001, Scott Murray wrote:

Thanks!

The isapnp=0 fixed it.  I don't actually have an isapnp.conf file.

On my next compile I'll just disable the ISA Pnp driver.
I don't actually need it, but it's something that I've never bothered to
turn off. :)

CF

> On Mon, 12 Feb 2001, Chris Funderburg wrote:
>
> >
> > After the updates to the opl3sa2 driver (2.4.2-pre3?) my card isn't being
> > detected anymore.  Are there further updates to come, or do I need to
> > change the settings?  The driver is being loaded as a module with the
> > following in /etc/modules.conf:
> [snip]
> > The midi works fine, but 'modprobe sound' reports:
> >
> > opl3sa2: No cards found
> > opl3sa2: 0 PnP card(s) found.
>
> If you've configured ISA PnP support into the kernel, then the driver
> ignores those settings unless you specify isapnp=0.  What I'd suggest
> is that you try disabling the configuration done by the isapnp tools,
> which can be done on RedHat and derived systems by renaming your
> /etc/isapnp.conf to something else.  There seem to be some issues
> with resetting the PnP configuration with isapnp after the in-kernel
> ISA PnP driver has done its stuff, as a couple of other people have
> mentioned similiar problems.
>
> Scott
>
>
>

-- 
... Any resemblance between the above views and those of my employer,
my terminal, or the view out my window are purely coincidental.  Any
resemblance between the above and my own views is non-deterministic.  The
question of the existence of views in the absence of anyone to hold them
is left as an exercise for the reader.  The question of the existence of
the reader is left as an exercise for the second god coefficient.  (A
discussion of non-orthogonal, non-integral polytheism is beyond the scope
of this article.)


-
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://vger.kernel.org/lkml/

pcmcia-issues with 2.2.18 & 2.4.0

[Stig Brautaset]

I am no kernel hacker, but I would like to file a bug-report none the
less. Please CC me with follow-ups (if any ;-) since I am not
subscribing to the mailing list.

I have a Xircom Combo CardBus (32 bit) 10/100 Ethernet Card + 56k
Modem (didn't try the modem part) that I have not been able to run
under 2.2.18 or 2.4.0. The weird part is that everything seems to load
fine, and I am able to configure the card with an ip-address and
everything. Only sad part is that I can not reach out to the world. I
just get connection time-outs when trying to acces the 'net.

The card runs fine under 2.2.17, but not with pcmcia-cs package
version later than 3.1.20 (I do realize that this probably have little
to do with the kernel).

BTW, The driver used by the card is tulip_cb, and the machine it runs
on is a Dell Latitude CPx H500GT.

Regards, Stig
-
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://vger.kernel.org/lkml/

Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1

[Chris Mason]

On Tuesday, February 13, 2001 01:39:02 AM +0300 Hans Reiser
<[EMAIL PROTECTED]> wrote:
> Chris, your quoting is very confusing above. but I get your very
> interesting remark (thanks for noticing) that the nulls are specific to
> crashes on 2.2, and therefor could be due to the elevator bug on 2.4.  It
> even makes rough sense that the elevator bug (said to occasionally cause
> a premature write of the wrong buffer) could cause an effect similar to a
> crash.  I hope it is true, let's ask all users to upgrade to pre2 (a good
> idea anyway) and see if it cures.
> 

Ok, I'll try again ;-)  People have been seeing null bytes in data files on
reiserfs.  They see this without seeing any other corruption of any kind,
and they only see it on files of very specific sizes.  They see this
without crashing, and without hard drive suspend kicking in.  They see it
on scsi and ide, on servers and laptops.

Elevator bugs and general driver bugs could certainly cause nulls in data
files.  But they would also cause other corruptions and probably would not
be selective enough to pick files that happen to have the same range in
size that reiserfs packs tails on.

In other words, updating to 2.4.2pre2 or your favorite ac series kernel is
probably a good plan.  It won't fix this bug ;-)

Perhaps I haven't seen it yet because I've also been testing code that does
direct->indirect conversions slightly differently, I'll try again on a pure
kernel.

-chris

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

Re: LILO and serial speeds over 9600

[Tim Wright]

Yup,
those who fail to learn from TCP are doomed to re-invent it, badly, at the
wrong level .
Seriously, the console subsystem on the Sequent (now IBM) NUMA-Q systems
originally used UDP. It wound up as a serious mess. We changed to TCP.
I'll admit that the NUMA-Q console subsystem does more than what is being
proposed here currently, but it's likely to grow.
In general UDP is only appropriate if you *can* afford to drop data.
Did RDP ever get anywhere ?

Regards,

Tim

On Tue, Feb 13, 2001 at 12:11:01AM +, Alan Cox wrote:
> > I'm sure you can.  That doesn't mean it's the right solution.
> 
> And the UDP proposal will be at least as big if it does retransmits, and if
> it doesnt , its junk. It will also need as much buffering, if not the same
> packing trick
> 
> -
> 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://vger.kernel.org/lkml/

-- 
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
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://vger.kernel.org/lkml/

Re: opl3sa not detected anymore

[Chris Funderburg]

Well what do you know...
I added isapnp=0 and it worked.

 at 0x370
 at 0x534 irq 5 dma 1,0
 at 0x330 irq 5 dma -1,0

The dma and the MSS address (0x534) looks odd, but at least it
seems to play now.

And no, AFAIK, this driver has never been able to detect PNP settings.
If you try to run it without them, you get this:

opl3sa2: io, mss_io, irq, dma, and dma2 must be set

Thanks for your help!

CF


On Tue, 13 Feb 2001, Jérôme Augé wrote:

> Chris Funderburg wrote:
> > following in /etc/modules.conf:
> >
> > alias sound-slot-0 opl3sa2
> > options sound dmabuf=1
> > alias midi opl3
> > options opl3 io=0x388
> > options opl3sa2 mss_io=0x530 irq=5 dma=1 dma2=0 mpu_io=0x330 io=0x370
> >
> > The midi works fine, but 'modprobe sound' reports:
> >
> > opl3sa2: No cards found
> > opl3sa2: 0 PnP card(s) found.
> >
> > If the settings above look ok, then how can help debug it?
>
> Try to add "isapnp=0" to the opl3sa2 options list :
>
> opl3sa2 mss_io=0x530 irq=5 dma=1 dma2=0 mpu_io=0x330 io=0x370 isapnp=0
>
> I had the same problem and adding isapnp=0 solved it, but PNP isn't
> supposed to automaticaly detect those options ?
>
>

-- 
... Any resemblance between the above views and those of my employer,
my terminal, or the view out my window are purely coincidental.  Any
resemblance between the above and my own views is non-deterministic.  The
question of the existence of views in the absence of anyone to hold them
is left as an exercise for the reader.  The question of the existence of
the reader is left as an exercise for the second god coefficient.  (A
discussion of non-orthogonal, non-integral polytheism is beyond the scope
of this article.)


-
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://vger.kernel.org/lkml/

Re: LILO and serial speeds over 9600

[Alan Cox]

> I'm sure you can.  That doesn't mean it's the right solution.

And the UDP proposal will be at least as big if it does retransmits, and if
it doesnt , its junk. It will also need as much buffering, if not the same
packing trick

-
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://vger.kernel.org/lkml/

Re: LARGE bug with 2.4.1ac10 and loop filesystem

[Sean]

All,

I just compiled 2.4.1-ac10 with the loop-3 patch from adoeb and it seems to fix
the loopback problems.  This is for someone NOT using the encrypted FS since I
did not test this.

If anyone has a better way to make sure everything is working correctly other
than using mkinitrd to test if the loopback works then please let me know.

Thanks for the fix,

Sean 


On Mon, 12 Feb 2001 22:28:28 + (GMT), Alan Cox said:

> > > That was Im afraid pure luck. Jens is currently sorting out the
>  > > loop problems and has test patches
>  > 
>  > By any chance, are these loop problems the same ones affecting
>  > 2.4.2-pre2 and -pre3?
>  
>  And to varying degrees all 2.4.x kernels right now
>  -
>  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://vger.kernel.org/lkml/
>  
>  

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

Re: opl3sa not detected anymore

[Scott Murray]

On Mon, 12 Feb 2001, Chris Funderburg wrote:

>
> After the updates to the opl3sa2 driver (2.4.2-pre3?) my card isn't being
> detected anymore.  Are there further updates to come, or do I need to
> change the settings?  The driver is being loaded as a module with the
> following in /etc/modules.conf:
[snip]
> The midi works fine, but 'modprobe sound' reports:
>
> opl3sa2: No cards found
> opl3sa2: 0 PnP card(s) found.

If you've configured ISA PnP support into the kernel, then the driver
ignores those settings unless you specify isapnp=0.  What I'd suggest
is that you try disabling the configuration done by the isapnp tools,
which can be done on RedHat and derived systems by renaming your
/etc/isapnp.conf to something else.  There seem to be some issues
with resetting the PnP configuration with isapnp after the in-kernel
ISA PnP driver has done its stuff, as a couple of other people have
mentioned similiar problems.

Scott


-- 
=
Scott Murrayemail: [EMAIL PROTECTED]
http://www.spiteful.org (coming soon) ICQ: 10602428
-
 "Good, bad ... I'm the guy with the gun." - Ash, "Army of Darkness"

-
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://vger.kernel.org/lkml/

Re: fwd: Mylex dac960 not SMP-safe?

[Olli Lounela]

On Mon, Feb 12, 2001 at 09:02:00AM -0800, Leonard N. Zubkoff wrote:
> 
> I seem to recall that the Intel Providence motherboard has been
> problematic in many configurations.  Have you contacted Mylex Technical
> Support to inquire about compatibility issues between the AcceleRAID 250
> and the PR440FX motherboard?  They are far more expert than I when
> hardware compatibility is in question.

I have done that now, but don't really expect response before tomorrow at
earliest.

Just to mention what I earlier forgot, I've made darn sure the cooling is
good enough. The raid pack is in external box, so power quality should not
affect the issue.

> Busmastering jumper?  The only jumper on the AcceleRAID 250 I recall is the one
> that controls whether the SISL support for onboard Symbios SCSI chips is
> activated.  Having this jumper in the wrong position could lead to interrupt
> problems, I expect.

OK. The documentation about the meaning of SISL was not exactly the best in
the World, so to say. The onboard controller is aic7880, I didn't think it
uses Symbios chips... ohwell.

> If it hangs right after the driver banner is printed, but before the
> configuration of the controller is reported, this almost certainly means that
> the driver is not receiving interrupts from the DAC960.  This generally

This is the case. With nosmp, it gets recognized and initialized all right,
the filesystems in the disk set pass e2fsck without problems, but the boot
still eventually hangs hard at eepro100 initialization once init changes to
runlevel 3 (this is RedHat, alright).

There is a difference here, from Mylex init hang I can do soft reboot, eepro
init hangs hard. And yes, I've waited half an hour to see if it recovers.
No such luck.

With 2.2-UP (stock RH 2.2.16-3) I seem to be able to run the machine with no
problems, though SMP variant of the same still hangs hard, apparently at
network traffic.

> indicates compatibility problems between the motherboard, its BIOS, and the
> DAC960 hardware/firmware, a buggy motherboard, or it can indicate that the

I've now also upgraded the flsh ROMs to the latest I found from Mylex' web
site (Firmware 4.08-0-35, BIOS 4.10-41).

> Linux kernel is not dealing properly with the motherboard APIC configuration.
> I thought that the latter type of issue is no longer likely.

This is what it sounds like, to me, if the driver works fine. Especially
since 2.2 is different from 2.4, and also since the motherboard has worked
before. Perhaps the kernel mis-initializes APIC, and interrupts go awry.

I have now tested several kernels, going all the way back to 2.4.0-test10 
(I thought there might be something in common with Jan-Benedict Glaw's
report about PCI problems with DAC1164). No difference at all with any of
the kernels.

However, I still have no real idea how to start debugging the case. I sure
hope it isn't undebuggable.

> eepro100, so I am initially much more suspicious of the PR440FX motherboard
> combination.

My feelings exactly. I suspect SMP PPro is no longer all that common, and
Mylex there might be much less so. eepro100/B with 82557 should not be
uncommon, however. Strange, however, that it's the dac960 that exposes the
problem.

> I notice that the AcceleRAID 250 and eepro100 are sharing IRQ 10.  WHile in
> theory this should work fine, and does in other systems, is it possible to
> place the AcceleRAID 250 in a different slot or assign it another IRQ?

Forcing these to different IRQ's made no difference, nor did shuffling
around the PCI-cards (just two, S3 Virge and Mylex).

Finally got 2.4.2pre3 nosmp boot dmesg, attached. Also current lspci -vvvxx

-- 
Olli   ...and he thought I'm serious! Hahahaha...


Linux version 2.4.2-pre3 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 
19990314/Linux (egcs-1.1.2 release)) #3 SMP Tue Feb 13 03:23:46 EET 2001
BIOS-provided physical RAM map:
 BIOS-e820: 0009fc00 @  (usable)
 BIOS-e820: 0bf0 @ 0010 (usable)
 BIOS-e820: 0018 @ ffe8 (reserved)
 BIOS-e820: 9000 @ fec0 (reserved)
Scan SMP from c000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f for 65536 bytes.
found SMP MP-table at 000f7ef0
hm, page 000f7000 reserved twice.
hm, page 000f8000 reserved twice.
hm, page 000f7000 reserved twice.
hm, page 000f8000 reserved twice.
On node 0 totalpages: 49152
zone(0): 4096 pages.
zone(1): 45056 pages.
zone(2): 0 pages.
Intel MultiProcessor Specification v1.4
Virtual Wire compatibility mode.
OEM ID: INTELProduct ID: PR440FX  APIC at: 0xFEC08000
Processor #0 Pentium(tm) Pro APIC version 17
Floating point unit present.
Machine Exception supported.
64 bit compare & exchange supported.
Internal APIC present.
SEP present.
MTRR  present.
PGE  present.
MCA  present.
CMOV  present.
Bootup CPU
Processor #12 Pentium(tm) Pro APIC version 17
Floating point unit 

Re: LILO and serial speeds over 9600

[Michael Rothwell]

> Then HPA may ask: but why do you want to run the serial console at
> 115200?? The answer is simple: because we ...

... don't want to drag out debugging the kernel on a 38400 connection.
Because printks are our only debugging option ("thanks", Linus), and a slow
serial port block and can change the timing of when code runs, I need the
serial port to run as fast as possible. It would be keen to be able to use
an ethernet debugging console rather than (or in addition to) serial,
because it would be even faster, and if I'm debugging (for instance) a
serial driver, I won't have to use the system I'm debugging to debug the
system I'm debugging.

Of course, a supported kernel debugger would make a nice addition to faster
console output, but I won't hold my breath waiting for Linux to acquire what
pretty much every other operating system already has.

-M

-
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://vger.kernel.org/lkml/

Re: LILO and serial speeds over 9600

[H. Peter Anvin]

Alan Cox wrote:
> 
> > Depends on what the client can handle.  For the kernel, that might be
> > true, but for example a boot loader may only have a few K worth of buffer
> > space.
> 
> That same constraint is true of any UDP protocol too, and indeed any protocol
> not entirely based on FEC (which rather rules out ethernet based solutions)
> 
> You also dont need much buffering for a smart embedded stack, its no secret
> that some embedded tcps dont buffer the data but pointers to constant data and
> values for only non constant objects. You really can make a minimal TCP very
> low resource.
> 

I'm sure you can.  That doesn't mean it's the right solution.

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://vger.kernel.org/lkml/

Re: dc295

[Kurt Garloff]

On Sat, Feb 10, 2001 at 11:18:25AM -0500, Nick Papadonis wrote:
> I saw a posting about the DC-395 from you.
> 
> What the current state of the driver?  Where is it? =20

http://www.garloff.de/kurt/linux/dc395/

Works perfectly for most people, but corrupts data for some.

> I just bought the card thinking a Linux driver was available, but one
> doesn't appear to be in the 2.4 kernel tree.

I won't push it into the kernel with the "corruption for a few" feature.
Data loss is not what you expect from your Linux.
And it's hard to fix without any reasonable chipset docu.

> Any insight appreciated.

Regards,
-- 
Kurt Garloff   <[EMAIL PROTECTED]> [Eindhoven, NL]
Physics: Plasma simulations  <[EMAIL PROTECTED]>  [TU Eindhoven, NL]
Linux: SCSI, Security  <[EMAIL PROTECTED]>   [SuSE Nuernberg, FRG]
 (See mail header or public key servers for PGP2 and GPG public keys.)
-
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://vger.kernel.org/lkml/

Re: LILO and serial speeds over 9600

[H. Peter Anvin]

James Sutherland wrote:
> >
> > Depends on what the client can handle.  For the kernel, that might be
> > true, but for example a boot loader may only have a few K worth of buffer
> > space.
> 
> Fortunately, the bulky stuff (printk's from the booting kernel) will be
> going from the boot loader to the server, and should be buffered there
> OK until they can be processed. Only the stuff sent to the client will
> need buffering, and that should be simple keystrokes...
> 

Well, any time there is a network there needs to be buffering, if you
want to have any kind of ACK protocol.

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://vger.kernel.org/lkml/

Re: opl3sa not detected anymore

[Alan Cox]

> > The midi works fine, but 'modprobe sound' reports:
> > opl3sa2: No cards found
> > opl3sa2: 0 PnP card(s) found.

Thats ok, it may not be set up for isapnp

> Try to add "isapnp=3D0" to the opl3sa2 options list :
> 
> opl3sa2 mss_io=3D0x530 irq=3D5 dma=3D1 dma2=3D0 mpu_io=3D0x330 io=3D0x3=
> 70 isapnp=3D0
> 
> I had the same problem and adding isapnp=3D0 solved it, but PNP isn't
> supposed to automaticaly detect those options ?

No, but if you set options it would kind of make sense to turn off the
isapnp automatically 8). I'll look into that.
-
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://vger.kernel.org/lkml/

Re: LILO and serial speeds over 9600

[David Weinehall]

On Mon, Feb 12, 2001 at 03:17:04PM -0800, Ivan Passos wrote:
> 
> On Mon, 12 Feb 2001, Scott Laird wrote:
> > 
> > On 12 Feb 2001, H. Peter Anvin wrote:
> > >
> > > Just checked my own code, and SYSLINUX does indeed support 115200 (I
> > > changed this to be a 32-bit register ages ago, apparently.)  Still
> > > doesn't answer the question "why"... all I think you do is increase
> > > the risk for FIFO overrun and lost characters (flow control on a boot
> > > loader console is vestigial at the best.)
> > 
> > It's simple -- we want the kernel to have its serial console running at
> > 115200, and we don't want to have to change speeds to talk to the
> > bootloader. 
> 
> Exactly.
> 
> Then HPA may ask: but why do you want to run the serial console at
> 115200?? The answer is simple: because we can (or more precisely, because
> the HW can ;).
> 
> If the hardware is supposed to support 115.2Kbps, why can't / shouldn't 
> we use it?? Remember, this is not a modem connection, there is no
> compression involved, both sides are running 115.2Kbps, so there should
> NOT be a risk for FIFO overruns (unless you have buggy hardware). And in
> this case, you can then decrease your baud rate. But at least you have the
> _option_! :)
> 
> 
> > Some boot processes, particularaly fsck, can be *REALLY*
> > verbose on screwed up systems.  I've seen systems take hours to run fsck,
> > even on small filesystems, simply because they were blocking on a 9600 bps
> > console.
> 
> This is true!!
> 
> Another one (not as critical as the fsck though): when compiling the
> kernel, sometimes the kernel compilation is done, but the console output
> isn't finished yet (I'm serious).

Dunno about others, but I always pipe stdout to /dev/null when compiling
kernels. This way, everything important is still shown (warnings/errors)
as those go to stderr anyway, and all non-interesting stuff goes down
the drain.


/David Weinehall
  _ _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://vger.kernel.org/lkml/

Re: PCI bridge handling 2.4.0-test10 -> 2.4.2-pre3

[Adam Lackorzynski]

On Mon Feb 12, 2001 at 14:04:20 +0100, Jan-Benedict Glaw wrote:
> I've got a "Bull Express5800/Series" (dual P3) with a DAC1164 RAID
> controller. The mainboard is ServerWorks based and however, 2.4.2-pre3
> fails to find the RAID controller. I think there's a problem at
> scanning PCI busses behind PCI bridges. Here's the PCI bus layout as
> 2.4.0-test10 recognizes it:

There's was a change in the PCI bus scan code in pre3.


Could you please apply the following patch to arch/i386/kernel/pci-pc.c (against
2.4.1-pre3) and tell us your results? The fixup functions do not seem to
work right now so we'll trust the BIOS...

--- pci-pc.c.orig   Tue Feb 13 00:02:50 2001
+++ pci-pc.cTue Feb 13 00:19:29 2001
@@ -953,9 +953,6 @@
 struct pci_fixup pcibios_fixups[] = {
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_INTEL,PCI_DEVICE_ID_INTEL_82451NX,   
 pci_fixup_i450nx },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_INTEL,PCI_DEVICE_ID_INTEL_82454GX,   
 pci_fixup_i450gx },
-   { PCI_FIXUP_HEADER, PCI_VENDOR_ID_SERVERWORKS,  
PCI_DEVICE_ID_SERVERWORKS_HE,   pci_fixup_serverworks },
-   { PCI_FIXUP_HEADER, PCI_VENDOR_ID_SERVERWORKS,  
PCI_DEVICE_ID_SERVERWORKS_LE,   pci_fixup_serverworks },
-   { PCI_FIXUP_HEADER, PCI_VENDOR_ID_SERVERWORKS,  
PCI_DEVICE_ID_SERVERWORKS_CMIC_HE,  pci_fixup_serverworks },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_COMPAQ,   PCI_DEVICE_ID_COMPAQ_6010, 
 pci_fixup_compaq },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_UMC,  PCI_DEVICE_ID_UMC_UM8886BF,
 pci_fixup_umc_ide },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_SI,   PCI_DEVICE_ID_SI_5513, 
pci_fixup_ide_trash },



Adam
-- 
Adam [EMAIL PROTECTED]
  Lackorzynski http://a.home.dhs.org
-
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://vger.kernel.org/lkml/

Re: opl3sa not detected anymore

[Jérôme Augé]

Chris Funderburg wrote:
> following in /etc/modules.conf:
> 
> alias sound-slot-0 opl3sa2
> options sound dmabuf=1
> alias midi opl3
> options opl3 io=0x388
> options opl3sa2 mss_io=0x530 irq=5 dma=1 dma2=0 mpu_io=0x330 io=0x370
> 
> The midi works fine, but 'modprobe sound' reports:
> 
> opl3sa2: No cards found
> opl3sa2: 0 PnP card(s) found.
> 
> If the settings above look ok, then how can help debug it?

Try to add "isapnp=0" to the opl3sa2 options list :

opl3sa2 mss_io=0x530 irq=5 dma=1 dma2=0 mpu_io=0x330 io=0x370 isapnp=0

I had the same problem and adding isapnp=0 solved it, but PNP isn't
supposed to automaticaly detect those options ?

-- 
Jérôme Augé
echo [EMAIL PROTECTED] | tr khplmndvqyc nirtelacufj
-
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://vger.kernel.org/lkml/

Re: LILO and serial speeds over 9600

[James Sutherland]

On Mon, 12 Feb 2001, H. Peter Anvin wrote:

> Alan Cox wrote:
> > 
> > > > Explain 'controlled buffer overrun'.
> > >
> > > That's probably the ability to send new data even if there's unacked old
> > > data (e.g. because the receiver can't keep up or because we've had losses).
> > 
> > Well let me see, the typical window on the other end of the connection if
> > its a normal PC class host will be 32K. I think that should be sufficient.
> 
> Depends on what the client can handle.  For the kernel, that might be
> true, but for example a boot loader may only have a few K worth of buffer
> space.

Fortunately, the bulky stuff (printk's from the booting kernel) will be
going from the boot loader to the server, and should be buffered there
OK until they can be processed. Only the stuff sent to the client will
need buffering, and that should be simple keystrokes...


James.

-
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://vger.kernel.org/lkml/

Re: LILO and serial speeds over 9600

[Alan Cox]

> Depends on what the client can handle.  For the kernel, that might be
> true, but for example a boot loader may only have a few K worth of buffer
> space.

That same constraint is true of any UDP protocol too, and indeed any protocol
not entirely based on FEC (which rather rules out ethernet based solutions)

You also dont need much buffering for a smart embedded stack, its no secret
that some embedded tcps dont buffer the data but pointers to constant data and
values for only non constant objects. You really can make a minimal TCP very
low resource.

Alan

-
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://vger.kernel.org/lkml/

Re: LILO and serial speeds over 9600

[Alan Cox]

> I *REALLY* don't know if that is reasonable; it may have to fall into the
> category of "supported but not required".  Requiring an SHA hash in a
> small bootstrap loader may not exactly be a reasonable expectation! 

tea is very very small so may be appropriate instead.

> However, I think the protocol is inherently going to be asymmetric, with
> as much as possible unloaded.

Nod.

-
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://vger.kernel.org/lkml/

Re: TRM-S1040/DC395 Driver?

[Tim Wright]

Well, it's back up again now.
I've been using the patches for a couple of months with no problems.
This is on a 4-processor P6 box, so the SMP support seems sound. I only have
a CDRW attached on this SCSI bus so I can't comment on disk support etc.

Kurt, have you submitted this driver to be included into the mainstream
kernel ? It seems solid enough to me.

Regards,

Tim

On Sat, Feb 10, 2001 at 11:22:19AM -0500, Nick Papadonis wrote:
> Hi,
> 
> Anyone know where the kernel patches for the DC395U with the Tekram TRM-S1040
> chip are?
> 
> http://www.garloff.de/ appears to be down.
> 
> Will these be included in the 2.4.x kernel tree?
> 
> Thanks.
> 
> -- 
> - Nick
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

-- 
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
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://vger.kernel.org/lkml/

opl3sa not detected anymore

[Chris Funderburg]

After the updates to the opl3sa2 driver (2.4.2-pre3?) my card isn't being
detected anymore.  Are there further updates to come, or do I need to
change the settings?  The driver is being loaded as a module with the
following in /etc/modules.conf:

alias sound-slot-0 opl3sa2
options sound dmabuf=1
alias midi opl3
options opl3 io=0x388
options opl3sa2 mss_io=0x530 irq=5 dma=1 dma2=0 mpu_io=0x330 io=0x370

The midi works fine, but 'modprobe sound' reports:

opl3sa2: No cards found
opl3sa2: 0 PnP card(s) found.

If the settings above look ok, then how can help debug it?

Regards
CF
-- 
... Any resemblance between the above views and those of my employer,
my terminal, or the view out my window are purely coincidental.  Any
resemblance between the above and my own views is non-deterministic.  The
question of the existence of views in the absence of anyone to hold them
is left as an exercise for the reader.  The question of the existence of
the reader is left as an exercise for the second god coefficient.  (A
discussion of non-orthogonal, non-integral polytheism is beyond the scope
of this article.)


-
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://vger.kernel.org/lkml/

Re: LILO and serial speeds over 9600

[H. Peter Anvin]

Alan Cox wrote:
> 
> > This is true, but one thing I'd really like to have is controlled buffer
> > overrun, which TCP *doesn't* have.  I really think an ad hoc UDP protocol
> > (I've already begun sketching on the details) is more appropriate in this
> > particular case.
> 
> Explain 'controlled buffer overrun'. BTW if you make it UDP please include
> something like SHA hash or tea hash and shared secret
> 

I *REALLY* don't know if that is reasonable; it may have to fall into the
category of "supported but not required".  Requiring an SHA hash in a
small bootstrap loader may not exactly be a reasonable expectation! 
However, I think the protocol is inherently going to be asymmetric, with
as much as possible unloaded.

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://vger.kernel.org/lkml/

Re: LILO and serial speeds over 9600

[H. Peter Anvin]

Alan Cox wrote:
> 
> > > Explain 'controlled buffer overrun'.
> >
> > That's probably the ability to send new data even if there's unacked old
> > data (e.g. because the receiver can't keep up or because we've had losses).
> 
> Well let me see, the typical window on the other end of the connection if
> its a normal PC class host will be 32K. I think that should be sufficient.
> 

Depends on what the client can handle.  For the kernel, that might be
true, but for example a boot loader may only have a few K worth of buffer
space.

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://vger.kernel.org/lkml/

Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1

[Hans Reiser]

Chris Mason wrote:
> 
> On Monday, February 12, 2001 11:42:38 PM +0300 Hans Reiser
> <[EMAIL PROTECTED]> wrote:
> 
> >> Chris,
> >>
> >> Do you know if the people reporting the corruption with reiserfs on
> >> 2.4 were using IDE drives with PIO mode and IDE multicount turned on?
> >>
> >> If so, it may be caused by the problem fixed by Russell King on
> >> 2.4.2-pre2.
> >>
> >> Without his fix, I was able to corrupt ext2 while using PIO+multicount
> >> very very easily.
> >
> 
> I suspect the bugfixes in pre2 will fix some of the more exotic corruption
> reports we've seen, but this one (nulls in log files) probably isn't caused
> by a random (or semi-random) lower layer corruption.  These users are not
> seeing random metadata corruption, so I suspect this bug is different (and
> reiserfs specific).
> 
> > Was the bug you describe also present in the 2.2.* series?  If not, then
> > the bugs are not the same.
> >
> 
> In 2.2 code the only data file corruption I know if is caused by a crash
> 
> -chris

I'd like to announce on our website and mailing list that all  XXX users should
upgrade to 2.4.2pre2.  Do you all agree with this?

What is the exact definition of XXX?

Hans
-
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://vger.kernel.org/lkml/

Re: LILO and serial speeds over 9600

[Ivan Passos]

On Mon, 12 Feb 2001, Scott Laird wrote:
> 
> On 12 Feb 2001, H. Peter Anvin wrote:
> >
> > Just checked my own code, and SYSLINUX does indeed support 115200 (I
> > changed this to be a 32-bit register ages ago, apparently.)  Still
> > doesn't answer the question "why"... all I think you do is increase
> > the risk for FIFO overrun and lost characters (flow control on a boot
> > loader console is vestigial at the best.)
> 
> It's simple -- we want the kernel to have its serial console running at
> 115200, and we don't want to have to change speeds to talk to the
> bootloader. 

Exactly.

Then HPA may ask: but why do you want to run the serial console at
115200?? The answer is simple: because we can (or more precisely, because
the HW can ;).

If the hardware is supposed to support 115.2Kbps, why can't / shouldn't 
we use it?? Remember, this is not a modem connection, there is no
compression involved, both sides are running 115.2Kbps, so there should
NOT be a risk for FIFO overruns (unless you have buggy hardware). And in
this case, you can then decrease your baud rate. But at least you have the
_option_! :)


> Some boot processes, particularaly fsck, can be *REALLY*
> verbose on screwed up systems.  I've seen systems take hours to run fsck,
> even on small filesystems, simply because they were blocking on a 9600 bps
> console.

This is true!!

Another one (not as critical as the fsck though): when compiling the
kernel, sometimes the kernel compilation is done, but the console output
isn't finished yet (I'm serious).

Later,
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://vger.kernel.org/lkml/

Re: LILO and serial speeds over 9600

[Alan Cox]

> > Explain 'controlled buffer overrun'.
> 
> That's probably the ability to send new data even if there's unacked old
> data (e.g. because the receiver can't keep up or because we've had losses).

Well let me see, the typical window on the other end of the connection if
its a normal PC class host will be 32K. I think that should be sufficient.


-
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://vger.kernel.org/lkml/

Re: LILO and serial speeds over 9600

[Werner Almesberger]

Alan Cox wrote:
> Explain 'controlled buffer overrun'.

That's probably the ability to send new data even if there's unacked old
data (e.g. because the receiver can't keep up or because we've had losses).

Such a feature would be mainly useful in cases where data becomes useless
if too old, e.g. VoIP. Ironically, for the console, the opposite may be
true: if the kernel all of a sudden starts vomiting printks, the relevant
information is more likely to be at the beginning than at the end.

One advantage of TCP would be that such an implementation is more likely
to get congestion control right, so it would be safer to use over the
Internet. (And using UDP wouldn't make this any easier.) Also, when using
TCP, it's more likely that some reasonable session management is built
into the design.

BTW, as far as the boot loader is concerned: any of the Linux boots Linux
designs should nicely solve this, with the possible exception of
environments where a legacy OS needs to be booted. Reminds me that I should
find some time besides traffic control to work a bit on bootimg ...

- Werner

-- 
  _
 / Werner Almesberger, ICA, EPFL, CH   [EMAIL PROTECTED] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/
-
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://vger.kernel.org/lkml/

Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1

[Hans Reiser]

Chris Mason wrote:
> 
> On Monday, February 12, 2001 11:42:38 PM +0300 Hans Reiser
> <[EMAIL PROTECTED]> wrote:
> 
> >> Chris,
> >>
> >> Do you know if the people reporting the corruption with reiserfs on
> >> 2.4 were using IDE drives with PIO mode and IDE multicount turned on?
> >>
> >> If so, it may be caused by the problem fixed by Russell King on
> >> 2.4.2-pre2.
> >>
> >> Without his fix, I was able to corrupt ext2 while using PIO+multicount
> >> very very easily.
> >
> 
> I suspect the bugfixes in pre2 will fix some of the more exotic corruption
> reports we've seen, but this one (nulls in log files) probably isn't caused
> by a random (or semi-random) lower layer corruption.  These users are not
> seeing random metadata corruption, so I suspect this bug is different (and
> reiserfs specific).
> 
> > Was the bug you describe also present in the 2.2.* series?  If not, then
> > the bugs are not the same.
> >
> 
> In 2.2 code the only data file corruption I know if is caused by a crash
> 
> -chris

Chris, your quoting is very confusing above. but I get your very interesting
remark (thanks for noticing) that the nulls are specific to crashes on 2.2, and
therefor could be due to the elevator bug on 2.4.  It even makes rough sense
that the elevator bug (said to occasionally cause a premature write of the wrong
buffer) could cause an effect similar to a crash.  I hope it is true, let's ask
all users to upgrade to pre2 (a good idea anyway) and see if it cures.

zam is perhaps very clever for deferring working on this bug..:-)

Hans
-
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://vger.kernel.org/lkml/

Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1

[Chris Mason]

On Monday, February 12, 2001 11:42:38 PM +0300 Hans Reiser
<[EMAIL PROTECTED]> wrote:

>> Chris,
>> 
>> Do you know if the people reporting the corruption with reiserfs on
>> 2.4 were using IDE drives with PIO mode and IDE multicount turned on?
>> 
>> If so, it may be caused by the problem fixed by Russell King on
>> 2.4.2-pre2.
>> 
>> Without his fix, I was able to corrupt ext2 while using PIO+multicount
>> very very easily.
> 

I suspect the bugfixes in pre2 will fix some of the more exotic corruption
reports we've seen, but this one (nulls in log files) probably isn't caused
by a random (or semi-random) lower layer corruption.  These users are not
seeing random metadata corruption, so I suspect this bug is different (and
reiserfs specific).

> Was the bug you describe also present in the 2.2.* series?  If not, then
> the bugs are not the same.
> 

In 2.2 code the only data file corruption I know if is caused by a crash

-chris

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

Re: LILO and serial speeds over 9600

[James Sutherland]

On Mon, 12 Feb 2001, H. Peter Anvin wrote:
> James Sutherland wrote:
> > 
> My thinking at the moment is to require kernel IP configuration (either
> ip= or RARP/BOOTP/DHCP).  It seems to be the only practical way;
> otherwise you miss too much at the beginning.  However, that mechanism is
> already in place, and shouldn't be too hard to piggy-back on.

Yes: that should be easy enough, specially DHCP and ip=.

> > I'll do a server to receive these sessions - simple text (no vt100 etc),
> > one window per session - and work on the protocol spec. Anyone willing
> > to do the client end of things - lilo, grub, kernel, etc??
> 
> I'll do PXELINUX, for sure.  I'd prefer to do the protocol spec, if you
> don't mind -- having done PXELINUX I think I know the kinds of pitfalls
> that you run into doing an implementation in firmware or firmware-like
> programming (PXELINUX isn't firmware, but it might as well be.)

Fine by me: we seem to agree on the basic concept already, and there isn't
going to be very much protocol involved!

> Doing it in LILO would be extremely difficult, since LILO has no ability
> to handle networking, and no reasonable way to graft it on (you need a
> driver for networking.)  GRUB I can't really comment on.

I haven't seen much of GRUB, but it does seem to have DHCP support, so it
must have some facility for sending/receiving packets. LILO's command-line
approach would be better suited to this, really, though...

> I might just decide to do the kernel as well.
> 
> Hmmm... this sounds like it's turning into a group effort.  Would you (or
> someone else) like to set up a sourceforge project for this?  I would
> prefer not to have to deal with that end myself.

OK, I've filled in the paperwork - we should have a project account
sometime tomorrow. I put the license type as "Other", since the heart of
the project is the protocol, and patches to add support to the kernel,
FreeBSD etc. will have to be under the license of the OS in question.

Title: "Network Console Protocol" for now?


James.


-
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://vger.kernel.org/lkml/

Re: LILO and serial speeds over 9600

[Alan Cox]

> It's not a huge undertaking, I know, but UDP will probably still be
> a bit simpler. Turn the question around: would using TCP bring any real
> benefits, in a system which will only be used to shift a few kb each boot
> time?

Im not convinced it will be any smaller by the time your UDP code has dealt
with retransmits, out of order acks, and backoff.

> for the kernel-side code: once you have a fully-fledged IP stack, why not
> use it. There's no reason the server couldn't support both, and machines
> would just use whichever was more appropriate at the time.

The IP layer is easy. Thats about 30 lines of code for a minimal IP. You'll
need more code to implement ARP, which you will require

-
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://vger.kernel.org/lkml/

mispellings and other preprocessing problems

[Jean-Luc Leger]

Hi,

I am a computer scientist from France. I currently play with
a source code analyser of mine.
 
Here are some "bugs" (or are they not ?) it detected :
(my own comments begin with ->)
 
/usr/src/linux-2.4.1/include/asm-parisc/som.h : EOF in comment
-> this one is self explained ..

/usr/src/linux-2.4.1/drivers/char/dz.c : 233IDENTIFIER expected in #ifdef
-> line 233 is : #ifdef 0
-> maybe #if 0 ? (and then, it is not so important since cpp understand it
->  correctly)

/usr/src/linux-2.4.1/arch/ia64/sn/io/klgraph_hack.c : 
 142   IDENTIFIER expected in #ifdef
-> same thing with #ifdef 0

/usr/src/linux-2.4.1/drivers/char/joystick/amijoy.c : 
 EOF in string started in line 116
-> unknown identifier 'Denise' (probably should be 'i')
-> unexpected double quote which is the origin of the problem

/usr/src/linux-2.4.1/drivers/scsi/NCR5380.c : 
 2267  NEWLINE expected in #ifdef
-> line 2267 is : #ifdef READ_OVERRUNS if (p & SR_IO) { c -= 2;
-> this line should be split in 2
 
/usr/src/linux-2.4.1/drivers/atm/nicstar.h : 616unknown directive
/usr/src/linux-2.4.1/drivers/atm/nicstar.h : 628unknown directive
-> #eliif in place of #elif

/usr/src/linux-2.4.1/arch/ia64/sn/io/klconflib.c : 
 514  Constant expression expected in #ifdef
-> closing bracket at wrong position in expression

/usr/src/linux-2.4.1/arch/ia64/sn/io/ml_SN_init.c : 
 351 NEWLINE expected in #ifdef
-> #ifdef CONFIG_SGI_IP35 || CONFIG_IA64_SGI_SN1 || CONFIG_IA64_GENERIC
-> should be : 
-> #if defined (CONFIG_SGI_IP35) || defined(CONFIG_IA64_SGI_SN1) 
   || defined(CONFIG_IA64_GENERIC)


That's all. Of course, I advise those who know to check my corrections :)

Thanks for this interesting system :)

JLL

-
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://vger.kernel.org/lkml/

Re: LILO and serial speeds over 9600

[James Sutherland]

On Mon, 12 Feb 2001, Alan Cox wrote:

> > > I have toyed a few times about having a simple Ethernet- or UDP-based
> > > console protocol (TCP is too heavyweight, sorry) where a machine would
> > > seek out a console server on the network.  Anyone has any ideas about
> > > it?
> > 
> > Excellent plan: data centre sysadmins the world over will worship your
> > name if it works...
> 
> Sounds like MOP on the old Vaxen. TCP btw isnt as heavyweight as people 
> sometimes think. You can (and people have) implemented a simple TCP client
> and IP and SLIP in 8K of EPROM on a 6502. There is a common misconception
> that a TCP must be complex.
> 
> All you actually _have_ to support is receiving frames in order, sending one
> frame at a time when the last data is acked and basic backoff. You dont have
> to parse tcp options, you dont have to support out of order reassembly.

It's not a huge undertaking, I know, but UDP will probably still be
a bit simpler. Turn the question around: would using TCP bring any real
benefits, in a system which will only be used to shift a few kb each boot
time?

At a later date, perhaps TCP could be used - it would certainly make sense
for the kernel-side code: once you have a fully-fledged IP stack, why not
use it. There's no reason the server couldn't support both, and machines
would just use whichever was more appropriate at the time.


James.


-
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://vger.kernel.org/lkml/

Re: Linux 2.4.1-ac7

[Marcelo Tosatti]

On Sun, 11 Feb 2001, Mike Galbraith wrote:

> On Sun, 11 Feb 2001, Rik van Riel wrote:
> 
> > On Sun, 11 Feb 2001, Mike Galbraith wrote:
> > > On Sun, 11 Feb 2001, Mike Galbraith wrote:
> > > 
> > > > Something else I see while watching it run:  MUCH more swapout than
> > > > swapin.  Does that mean we're sending pages to swap only to find out
> > > > that we never need them again?
> > > 
> > > (numbers might be more descriptive)
> > > 
> > > user  :   0:07:21.70  54.3%  page in :   142613
> > > nice  :   0:00:00.00   0.0%  page out:   155454
> > > system:   0:03:40.63  27.1%  swap in :56334
> > > idle  :   0:02:30.50  18.5%  swap out:   149872
> > > uptime:   0:13:32.83 context :   519726
> > 
> > Indeed, in this case we send a lot more pages to swap
> > than we read back in from swap, this means that the
> > data is still sitting in swap space and was never needed
> > again.
> 
> But it looks and feels (box is I/O hyper-saturated) like
> it wrote it all to disk.
> 
> (btw, ac5 does more disk read.. ie the reduced cache size
> of earlier kernels under heavy pressure does have it's price
> with this workload.. quite visible in agregates.  looks to
> be much cheaper than swap though.. for this workload)

Mike,

Could you please try the attached patch on top of latest Rik's patch?

Thanks!

--- linux.orig/mm/vmscan.c  Sun Feb 11 07:56:29 2001
+++ linux/mm/vmscan.c   Sun Feb 11 11:05:30 2001
@@ -563,7 +566,8 @@
/* The buffers were not freed. */
if (!clearedbuf) {
add_page_to_inactive_dirty_list(page);
-   flushed_pages++;
+   if (wait)
+   flushed_pages++;

/* The page was only in the buffer cache. */
} else if (!page->mapping) {




-
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://vger.kernel.org/lkml/

Re: RedHat 7.0 4.1 / lpd warning

[Tim Waugh]

On Mon, Feb 12, 2001 at 10:50:23PM +0100, John B. Jacobsen wrote:

> Starting lpd: Warning - lp: cannot open lp device '/dev/lp0' - No such device
> Warning - dj: cannot open lp device '/dev/lp0' - No such device
> 
> Why is that ? /dev/lp surely exists !

It's telling you that the driver is not loaded or won't load.  What
happens if you do 'modprobe parport_lowlevel'?

Tim.
*/

 PGP signature

Machine Freeze

[Grahame Jordan]

Hi!,

We have several machines running Supermicro 370DLE motherboad with dual
733MHz Processors.
We are running reiserfs on some partitions.  2 x 9.1GB SCSI HDD and 1 x
18GB SCSI HDD.
Kernel 2.2.18

Every so often the machines freezes, possibly whilst we are rsyncing to
the machine, but it does not
freeze every day.

Error messages copied from the screen:
Freeze 1
kmem_alloc: Bad slab magic (corrupt)
cname=skbuff_head_cache

Freeze 2
unable to handle kernel NULL pointer dereference at virtual address

current tss.cr3=140C9000 %cr3-140e9000 *pde=
Opps=0002
Cpu=1
EIP=00/0=[,c0136130>]
EFLAGS=00010246
eax: ebx ecx etc
Process rsync (pid=1728, process nr=90, stackpage=d41d9000)

In both of these the kernel was corrupt on the boot sector and had to
use a floppy to boot. Rerun lilo it is OK.

Thanks


--
Grahame Jordan
Network Manager - Consumer, Education
Spherion Group Limited

1st Floor, 493 St Kilda Rd, Melbourne VIC 3004
Tel: 61 3 9243 2220   Mobile: 61 3 408 058 209   Fax: 61 3 9820 2010
[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://vger.kernel.org/lkml/

Re: 2.2.19pre10 doesn't compile on alphas (sunrpc)

[David S. Miller]

Alan Cox writes:
 > I suspect adding 
 > 
 > #define BUG()  __asm__ __volatile__("call_pal 129 # bugchk")
 > 
 > to include/asm-alpha/page.h will do the right thing, since it works on 2.4

You have to add a few bits to arch/alpha/kernel/traps.c
I could be wrong though...

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

Re: 2.2.x: TCP lockups with tcp_timestamps

[Max Parke]

On Mon, 12 Feb 2001 [EMAIL PROTECTED] wrote:

> Hello!
> 
> > Machine (IP address 1.2.3.4) is running kernel 2.2.13 and dials in
> > over an annoyingly high-latency PPP link via ordinary modems.
> > 
> > Machine (IP address 5.6.7.8) connects via a cable modem and is running
> > RH6.2 and kernel 2.2.14.
> 
> Are they connected directly? Any routers between them?

They're both connected to the Internet, there are several routers, etc.
(including PPP dial-in server) between them.

> Another question: what's about masquerading et al?

Yes.  The 5.6.7.8 machine is connected to the Internet via a Linksys
"router" that is also performing masquerade.  

I will be very angry if this turns out to be the culprit.

The 1.2.3.4 machine has masq compiled into the kernel but isn't in use in
the case shown.

> 
> Needed, of course. tcpdump of one bad session on both of ends.

Below, both ends are attached.

> I am afraid that it is not a workaround. You observe some corruption
> _NOT_ detected by checksum. Disabling timestamps can hide problem,
> but corruption might remain. Disable vjcomp better (if it is enabled).

OK.

*Many* thanks

Max

---

[Note, I can reformat these using tcpdump -x[e] if needed]

Trace taken from 1.2.3.4 machine

20:29:34.730716 1.2.3.4.379 > 5.6.7.8.1053: P 16364:16468(104) ack 65097 win 31856 
 (DF)
20:29:35.115762 5.6.7.8.1053 > 1.2.3.4.379: . 65097:65097(0) ack 16468 win 32120 
 (DF)
20:29:35.155767 5.6.7.8.1053 > 1.2.3.4.379: P 65097:65157(60) ack 16468 win 32120 
 (DF)
20:29:35.155818 5.6.7.8.1053 > 1.2.3.4.379: P 65157:65211(54) ack 16468 win 32120 
 (DF)
20:29:35.175778 1.2.3.4.379 > 5.6.7.8.1053: . 16468:16468(0) ack 65211 win 31856 
 (DF)
20:29:35.179648 1.2.3.4.379 > 5.6.7.8.1053: P 16468:16528(60) ack 65211 win 31856 
 (DF)
20:29:35.535768 5.6.7.8.1053 > 1.2.3.4.379: P 65211:66288(1077) ack 16468 win 32120 
 (DF)
20:29:35.925800 1.2.3.4.379 > 5.6.7.8.1053: . 16528:16528(0) ack 66288 win 31856 
 (DF)
20:29:35.929720 1.2.3.4.379 > 5.6.7.8.1053: P 16528:16588(60) ack 66288 win 31856 
 (DF)
20:29:35.995781 5.6.7.8.1053 > 1.2.3.4.379: . 66288:66288(0) ack 16528 win 32120 
 (DF)
20:29:36.305771 5.6.7.8.1053 > 1.2.3.4.379: . 66288:66288(0) ack 16528 win 32120 
 (DF)
20:29:36.695769 5.6.7.8.1053 > 1.2.3.4.379: P 66288:67415(1127) ack 16528 win 32120 
 (DF)
20:29:36.702543 1.2.3.4.379 > 5.6.7.8.1053: P 16588:16648(60) ack 67415 win 31856 
 (DF)
20:29:36.923237 1.2.3.4.379 > 5.6.7.8.1053: P 16648:16752(104) ack 67415 win 31856 
 (DF)
20:29:37.215797 5.6.7.8.1053 > 1.2.3.4.379: . 67415:67415(0) ack 16528 win 32120 
 (DF)
20:29:37.225784 5.6.7.8.1053 > 1.2.3.4.379: . 67415:67415(0) ack 16528 win 32120 
 (DF)
20:29:37.225872 1.2.3.4.379 > 5.6.7.8.1053: P 16528:16648(120) ack 67415 win 31856 
 (DF)
20:29:37.830074 1.2.3.4.379 > 5.6.7.8.1053: P 16752:16856(104) ack 67415 win 31856 
 (DF)
20:29:37.835833 5.6.7.8.1053 > 1.2.3.4.379: . 67415:67415(0) ack 16528 win 32120 
 (DF)
20:29:38.105797 5.6.7.8.1053 > 1.2.3.4.379: . 67415:67415(0) ack 16528 win 32120 
 (DF)
20:29:38.635785 5.6.7.8.1053 > 1.2.3.4.379: P 66288:67415(1127) ack 16528 win 32120 
 (DF)
20:29:38.635869 1.2.3.4.379 > 5.6.7.8.1053: . 16856:16856(0) ack 67415 win 31856 
 (DF)
20:29:39.295770 5.6.7.8.1053 > 1.2.3.4.379: P 67415:68542(1127) ack 16528 win 32120 
 (DF)
20:29:39.302532 1.2.3.4.379 > 5.6.7.8.1053: P 16856:16916(60) ack 68542 win 31856 
 (DF)
20:29:39.515796 5.6.7.8.1053 > 1.2.3.4.379: . 68542:68542(0) ack 16528 win 32120 
 (DF)
20:29:39.650291 1.2.3.4.379 > 5.6.7.8.1053: P 16916:17020(104) ack 68542 win 31856 
 (DF)
20:29:40.325784 5.6.7.8.1053 > 1.2.3.4.379: . 68542:68542(0) ack 16528 win 32120 
 (DF)
20:29:41.545775 5.6.7.8.1053 > 1.2.3.4.379: P 67415:68542(1127) ack 16528 win 32120 
 (DF)
20:29:41.545865 1.2.3.4.379 > 5.6.7.8.1053: . 17020:17020(0) ack 68542 win 31856 
 (DF)
20:29:43.290905 1.2.3.4.379 > 5.6.7.8.1053: P 17020:17124(104) ack 68542 win 31856 
 (DF)
20:29:43.525801 5.6.7.8.1053 > 1.2.3.4.379: . 68542:68542(0) ack 16528 win 32120 
 (DF)
20:29:44.065769 5.6.7.8.1053 > 1.2.3.4.379: P 68542:69669(1127) ack 16528 win 32120 
 (DF)
20:29:44.072538 1.2.3.4.379 > 5.6.7.8.1053: P 17124:17184(60) ack 69669 win 31856 
 (DF)
20:29:44.285753 5.6.7.8.1053 > 1.2.3.4.379: . 69669:69669(0) ack 16528 win 32120 
 (DF)
20:29:46.005767 5.6.7.8.1053 > 1.2.3.4.379: P 68542:69669(1127) ack 16528 win 32120 
 (DF)
20:29:46.005851 1.2.3.4.379 > 5.6.7.8.1053: . 17184:17184(0) ack 69669 win 31856 
 (DF)
20:29:50.572142 1.2.3.4.379 > 5.6.7.8.1053: P 17184:17288(104) ack 69669 win 31856 
 (DF)
20:29:50.915801 5.6.7.8.1053 > 1.2.3.4.379: . 69669:69669(0) ack 16528 win 32120 
 (DF)
20:29:53.895781 5.6.7.8.1053 > 1.2.3.4.379: P 69669:70796(1127) ack 16528 win 32120 
 (DF)
20:29:53.902581 1.2.3.4.379 > 5.6.7.8.1053: P 17288:17348(60) ack 70796 win 31856 
 (DF)
20:29:54.155798 5.6.7.8.1053 > 1.2.3.4.379: . 70796:70796(0) ack 16528 win 32120 
 (DF)
20:29:55.825770 

Re: [ANNOUNCE] Animated framebuffer logo for 2.4.1

[Miles Lane]

Martin Laberge wrote:

> Juergen Schneider wrote:
> 
> 
>> Hello everybody,
>> 
>> I've created a patch for kernel 2.4.1 that adds some fancy options for
>> the framebuffer console driver concerning the boot logo.
>> I've added logo animation and logo centering.
>> People may find this not very useful but nice to look at. :-)
>> 
>> It can be downloaded from:
>>
>> 
>> With this tar ball comes the patch for kernel 2.4.1 and a small
>> program called xpm2splash to create animated linux_logo.h files
>> from XPM files.
>> The patch also contains an animated boot logo (that's why it is
>> so big).
>> It is the dancing penguin I've taken from the apache default
>> configuration of a SuSE 6.4 distribution.
>> (BTW who created this nice animation???)
>> 
>> So, try it and send your comments.
>> 
>> Juergen Schneider
>> 
>> PS: The patch should work with kernel 2.4.0 too.
>> 
>> PPS: Our FTP server seems to have some problems with the "ls"
>>  command. You should use "ls -l" or "dir" to get a
>>  directory listing. Sorry for that.
>> 
>> --
>> Dipl.-Inf. Juergen Schneider<[EMAIL PROTECTED]>
>> TUXIA Deutschland GmbH
> 
> 
> I beleive it is a very good idea... there has been many objections where
> SYSTEM-HANG or CRASH or ANY-BAD-THING
> would be difficult to trace for the geek... BUT , are you all believing the
> system will be crashing most of the time, or will it be
> running perfectly most of the time...

Linux does crash early in the boot process sometimes.  Folks are
correct to be worried about handling these early crashes in such
a way that the user can learn what is going wrong with the OS.



> I believe linux should be one of those systems... you start it and then use
> it... it don't crash, don't hang...   it works...

It does crash and users can't know when it will happen 
ahead of time.  For example, I add a new piece of 
hardware that triggers a driver bug and BANG, the 
machine locks up on boot.  

Now, we can still have a "innocuous pretty boot" process,
as long as a boot parameter can be passed so that when
a kernel is crashing early in the boot process, the user
can disable the prettyboot and get to all the kernel 
messages.



Miles

-
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://vger.kernel.org/lkml/

Re: LARGE bug with 2.4.1ac10 and loop filesystem

[Alan Cox]

> > That was Im afraid pure luck. Jens is currently sorting out the
> > loop problems and has test patches
> 
> By any chance, are these loop problems the same ones affecting
> 2.4.2-pre2 and -pre3?

And to varying degrees all 2.4.x kernels right now
-
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://vger.kernel.org/lkml/

Re: LILO and serial speeds over 9600

[Alan Cox]

> This is true, but one thing I'd really like to have is controlled buffer
> overrun, which TCP *doesn't* have.  I really think an ad hoc UDP protocol
> (I've already begun sketching on the details) is more appropriate in this
> particular case.

Explain 'controlled buffer overrun'. BTW if you make it UDP please include
something like SHA hash or tea hash and shared secret
-
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://vger.kernel.org/lkml/

Re: lkml subject line

[Mohammad A. Haque]

Or you could just check Sender which is already there.

On 12 Feb 2001, Kai Henningsen wrote:

>
> Indeed. What a bad idea that would be.
>
> >   If you want to pre-filter messages traveling thru  linux-kernel  list,
> >   all you need to do is to check the content of   Return-Path:  header.
>
> On the other hand, that's also not a very good scheme. There *is* a good
> way to do this, and it would be really nice if vger could be taught to do
> it: add a List-Id: header (draft-chandhok-listid-04.txt RFC-to-be,
> implemented in lots of mailing list managers already).
>
> Examples from that doc:
>
> List-Id: List Header Mailing List 
> List-Id: 
> List-Id: "Lena's Personal Joke List"
>  
> List-Id: "An internal CMU List" <0Jks9449.list-id.cmu.edu>
> List-Id: 
>
> >   Or perhaps my utter aborrence is due to the way how GNU MAILMAN handles
> >   that tagging (badly, that is).
>
> Mailman, incidentally, _has_ List-Id: support.
>

-- 

=
Mohammad A. Haque  http://www.haque.net/
   [EMAIL PROTECTED]

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [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://vger.kernel.org/lkml/

Re: LARGE bug with 2.4.1ac10 and loop filesystem

[Michael J. Maravillo]

On Mon, Feb 12, 2001 at 09:58:43PM +, Alan Cox wrote:
> > Kernel 2.4.1ac9 works OK from that point of view.
> 
> That was Im afraid pure luck. Jens is currently sorting out the
> loop problems and has test patches

By any chance, are these loop problems the same ones affecting
2.4.2-pre2 and -pre3?

-- 
 .--.  Michael J. Maravillo   office://+63.2.894.3592/
( () ) Q Linux Solutions, Inc.  mobile://+63.917.897.0919/
 `--\\ A Philippine Open Source Solutions Co.  http://www.q-linux.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://vger.kernel.org/lkml/

Re: 2.2.19pre10 doesn't compile on alphas (sunrpc)

[Alan Cox]

> Hmm... Looks more difficult than I expected. Can we just change the
> one call to BUG to something sensible on alphas? I'm really eager to
> run this kernel..

The 'something sensible' is what you need to define BUG() to be, so its no
harder to do it right IMHO

I suspect adding 

#define BUG()  __asm__ __volatile__("call_pal 129 # bugchk")

to include/asm-alpha/page.h will do the right thing, since it works on 2.4



-
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://vger.kernel.org/lkml/

Re: LILO and serial speeds over 9600

[H. Peter Anvin]

Alan Cox wrote:
> 
> Sounds like MOP on the old Vaxen. TCP btw isnt as heavyweight as people
> sometimes think. You can (and people have) implemented a simple TCP client
> and IP and SLIP in 8K of EPROM on a 6502. There is a common misconception
> that a TCP must be complex.
> 
> All you actually _have_ to support is receiving frames in order, sending one
> frame at a time when the last data is acked and basic backoff. You dont have
> to parse tcp options, you dont have to support out of order reassembly.
> 

This is true, but one thing I'd really like to have is controlled buffer
overrun, which TCP *doesn't* have.  I really think an ad hoc UDP protocol
(I've already begun sketching on the details) is more appropriate in this
particular case.

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://vger.kernel.org/lkml/

Re: 2.2.19pre10 doesn't compile on alphas (sunrpc)

[Carlos Carvalho]

Alan Cox ([EMAIL PROTECTED]) wrote on 12 February 2001 21:49:
 >The ideal solution would be for someone to provide BUG() on the
 >Alpha platform as in 2.4. That would sort things cleanly

Hmm... Looks more difficult than I expected. Can we just change the
one call to BUG to something sensible on alphas? I'm really eager to
run this kernel..
-
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://vger.kernel.org/lkml/

Re: PS/2 Mouse/Keyboard conflict and lockup

[Mark Swanson]

 >I'm also seeing a ps/2 mouse bug, with 2.4.0-pre5 (I think) on a 
 >CS433 (486/33 laptop) 
 >Freezes after some time in X, killing keyboard.
 >Is there a generic approach to finding where this sort of problem lies?

The exact same thing happens to me too. Winbook XL2 laptop.
I can ssh to the box and kill X, and then I can use the keyboard/PS2 
mouse again!

The same thing happens in console mode. Keyboard/mouse lock up, I ssh, 
do the reverse of above (startx) and I can use my mouse and keyboard again!


-
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://vger.kernel.org/lkml/

Re: LARGE bug with 2.4.1ac10 and loop filesystem

[Mircea Ciocan]

Those patches are online somewhere ???
If you need a hand (trained monkey willing to do compilings, testing
and traceing :) I'm here.

Mircea C.
Alan Cox wrote:
> 
> > Kernel 2.4.1ac9 works OK from that point of view.
> 
> That was Im afraid pure luck. Jens is currently sorting out the loop problems
> and has test patches
-
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://vger.kernel.org/lkml/

Re: lkml subject line

[Eli Carter]

Kai Henningsen wrote:
> 
> [EMAIL PROTECTED] (Matti Aarnio)  wrote on 12.02.01 in 
><[EMAIL PROTECTED]>:
> 
> > On Mon, Feb 12, 2001 at 11:20:40AM +, Guennadi Liakhovetski wrote:
> > > Dear all (and list maintainers in particular)
> > >
> > > Wouldn't it be a good idea to prepend all lkml subjects with [LKML] like
> > > many other lists do to distinguish lkml messages from the rest.
> >
> >   NO!
> 
> Indeed. What a bad idea that would be.
> 
> >   If you want to pre-filter messages traveling thru  linux-kernel  list,
> >   all you need to do is to check the content of   Return-Path:  header.
> 
> On the other hand, that's also not a very good scheme. There *is* a good
> way to do this, and it would be really nice if vger could be taught to do
> it: add a List-Id: header (draft-chandhok-listid-04.txt RFC-to-be,
> implemented in lots of mailing list managers already).

Have you looked at the headers in an LK email?

Sender: [EMAIL PROTECTED]
X-Mailing-List: [EMAIL PROTECTED]
^^ Should provide that List-Id you want.

Eli
.  Rule of Accuracy: When working toward
Eli Carter  |   the solution of a problem, it always 
[EMAIL PROTECTED] `- helps if you know the answer.
-
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://vger.kernel.org/lkml/

2.4.1-ac10 loop/encryption lockups.

[Mark Swanson]

FYI:

With ac5 I could mount loopback filesystems that were aes encrypted. All 
I get with ac10 is a lockup.

Will test patches.

-
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://vger.kernel.org/lkml/

problem with modules in 2.2.14

[John R Lenton]

Hello all.

We've written a module for kernel 2.2.14 that includes a driver
for 2 "virtual" devices. These devices don't actually exist,
they're implemented with two circular buffers; what's written
into one of the devices is read from the other, and viceversa.

We believe the buffer is correctly written, but we have the
following problem: We can insmod, read, write, and rmmod, and
everything's OK. However, as soon as we logout we get 'INIT: Id
"n" respawning too fast: disabled for 5 minutes.', where "n" is
each of the consoles we were logged in at (5 minutes later, the
same message occurrs).

We have no idea what it could be, any pointers?

Julio Bianco
Edgardo Hames
FaMAF - UNC


[ forwarded w/translation by me ]

-- 
John Lenton ([EMAIL PROTECTED]) -- Random fortune:
Somewhere, just out of sight, the unicorns are gathering.
-
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://vger.kernel.org/lkml/

Re: LARGE bug with 2.4.1ac10 and loop filesystem

[Alan Cox]

> Kernel 2.4.1ac9 works OK from that point of view.

That was Im afraid pure luck. Jens is currently sorting out the loop problems
and has test patches
-
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://vger.kernel.org/lkml/

Re: [ANNOUNCE] Animated framebuffer logo for 2.4.1

[Miles Lane]

Pavel Machek wrote:

> Hi!
> 
> 
>> Right.  Add the option.  Default to "spew mode",
>> but make it easy for distributions to show people
>> a non-threatening boot process.  
> 
> Wrong.

We're talking about an _option_.  In fact, it could 
be set up as a boot time parameter.  Then, if a boot
process gets wedged, the user can just reboot with
the option disabled.

I really don't understand why this is such a hot
button for some people.  I repeat "option."

>> Since, as Christophe mentions, the boot messages would
>> still be accessible via CTRL-ALT-F2, I don't see what 
>> the problem is with at least making this an option.
> 
> If your system crashes hard, you have only graphical logo to stare
> at. Any warning messages are hidden. Not good.

Again.  Boot parameter.

Miles

-
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://vger.kernel.org/lkml/

RedHat 7.0 4.1 / lpd warning

[John B. Jacobsen]

I got the following warning when I compiled
kernel 2.4.0 and 2.4.1 :

Starting lpd: Warning - lp: cannot open lp device '/dev/lp0' - No such device
Warning - dj: cannot open lp device '/dev/lp0' - No such device

Why is that ? /dev/lp surely exists !

regards

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