Re: Break 2.4 VM in five easy steps

[C. Martins]

  In my everyday desktop workstation (PII 350) I have 64MB of RAM and use 300MB of 
swap, 150MB on 
each hard disk. After upgrading to 2.4, and maintaining the same set of applications 
(KDE, Netscape
& friends), the machine performance is _definitely_ much worse, in terms of 
responsiveness and 
throughput. Most of applications just take much longer to load, and once you've made 
something
that required more memory for a while (like compiling a kernel, opening a large JPEG 
in gimp, etc)
it takes lots of time to come back to normal. Strangely, with 2.4 the workstation just 
feels that
someone stole the 64MB DIMM and put in a 16MB one!!
  One thing I find strange is that with 2.4 if you run top or something similar you 
notice that
memory allocated for cache is almost always using more than half total RAM. I don't 
remember seeing
this with 2.2 kernel series...

  Anyway I think there is something really broken with respect to 2.4 VM. It is just 
NOT acceptable
that when running the same set of apps and type of work and you upgrade your kernel, 
your hardware
no longer is up to the job, when it fited perfectly right before. This is just MS way 
of solving
problems here.

  Best regards

 Claudio Martins 


On Wed, Jun 06, 2001 at 06:58:39AM -0700, Gerhard Mack wrote:
> 
> I have several boxes with 2x ram as swap and performance still sucks
> compared to 2.2.17.  
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: missing sysrq

[D. Stimits]

"Mike A. Harris" wrote:
> 
> On Fri, 1 Jun 2001, Dieter Nützel wrote:
> 
> >> > In article <[EMAIL PROTECTED]> you wrote:
> >> > > However, if I go to /proc/sys/kernel/sysrq does not exist.
> >> >
> >> > It is a compile time option, so the person who compiled your kernel
> >> > left it out.
> >>
> >> I compiled it, and the sysrq is definitely in the config. No doubt at
> >> all. I also use make mrproper and config again before dep and actual
> >> compile. Maybe it is just a quirk/oddball.
> >>
> >> D. Stimits, [EMAIL PROTECTED]
> >
> >Have you tried "echo 1 > /proc/sys/kernel/sysrq"?
> >You need both, compiled in and activation.

Since then I've completely removed that kernel source and kernel, only
the config file remains (and it had it activated if the config followed
it). All kernels before worked, and those since then also work, so I
know it isn't the keyboard. I also always run make mrproper and config
it again between compiles (I keep a list of config history), so I don't
know what was wrong, but replacing the kernel fixed it, and is no longer
an issue. I will, however, keep the showkey suggestion handy in case it
ever does it again.

D. Stimits, [EMAIL PROTECTED]

> 
> If you *know* it is compiled into your kernel, and you *know* it
> is enabled via the above, and it still does not work, do the
> following:
> 
> Run:
> 
> showkey -s
> 
> Then press LALT quickly followed by SYSRQ, and keep holding both
> down, and you should see:
> 
> 0x38
> 0x54
> 
> You might see a bunch of extra 0x38's which is ok.
> 
> If however when you press ALT-SYSRQ you see:
> 
> 0x38 0x54 0xd4
> 
> and are still holding both keys down, then your keyboard is
> broken and incompatible with the kernel SYSRQ feature.
> 
> A proper keyboard will only show "0x38 0x54".  I have written a
> patch for SYSRQ to allow it to be used with broken keyboards that
> send the make+break code for the SYSRQ sequence simultaneously.
> 
> If you need it, let me know and I'll send it to you.
> 
> --
> Mike A. Harris  -  Linux advocate  -  Open Source advocate
>Opinions and viewpoints expressed are solely my own.
> --
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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/

rdev command

[kpraveen]

Hi,
   I am using yellow dog linux on Apple, I am not finding "rdev"
command here.
Is there any equivalent command or replacement is present in Apple?.
Thanks in advance,

Praveen K


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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/

what's up with IRQ routing in 2.4.x ?

[Aaron Krowne]

Greetings.  I've been wondering about the behavior of linux IRQ routing on
certain systems running 2.4.x kernels (particularly .3 and above).  

I have an AMD KT133A system.  I have two friends with PIII-based laptops (one
toshiba, one thinkpad.)  We have all noticed the exact same strange behavior
despite our various hardware.  We're all running linux 2.4.4 or 2.4.5.  The
strange thing is that, whenever it has the opportunity to set an IRQ, linux
puts the device in question on the same IRQ which seems fixed for the system. 
But it gets stranger.  This IRQ is always IRQ 11.  On all 3 systems.  On my
system, I can specify "assign IRQ for USB".  When I do this, USB gets its own
IRQ and works (sorta).  When I do not, USB goes on IRQ 11 too!  And, in this
case, lots of devices on USB refuse their addresses and such, which does not
happen when USB has its own IRQ.

What gives?  Shouldn't devices go to whatever IRQs are free, instead of sharing
when there is no need to share?  Now, I would just find this a curiosity,
except I think it adversely effects devices in many cases.  For example, on the
toshiba, the sound card and ethernet card share an IRQ.  This makes the sound
card flakey.  Sometimes the driver for the sound card will not load at boot. 
Some times the device stops responding when in use (as playing an mp3).  On my
desktop AMD machine, I always get "PIRQ routing error" at boot, as my network
card and sound card also share an IRQ.  Also, my two USB ports share the same
IRQ, and I think this is causing problems with some devices (for instance, my
digital camera used to respond to my PC in linux, but then this randomly
stopped working).  

This would not be so bad if we could somehow manually assign IRQs until this
behavior is fixed.  But there is really no way to this via software in linux. 
Perhaps I am just uneducated, but setpci has never worked for this purpose
despite my best attempts.  I'm fairly sure this is possible, as many devices
can do this under windows.  (But.. shouldn't devices be able to share IRQs and
function fine?) At any rate, this appears to be impeding the usefulness of
devices that are otherwise supported.  

Any advice/info would be appreciated (I can provide logs for diagnostic
purposes, upon request.)

Aaron Krowne


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: scsi disk defect or kernel driver defect ?

[Johan Kullstam]

"J . A . Magallon" <[EMAIL PROTECTED]> writes:

> On 06.07 Nico Schottelius wrote:
> > >
> > > Based upon the lspci output you posted earlier, aic7880 has a single
> > > SCSI bus.
> > 
> > Oh. That could really be a problem.. I though having two different
> > connectors on the board would make two different buses..
> > I must have been wrong.
> > 
> > > So you must mean two internal connectors. Both of your devices
> > > (HD and Tape) do show up on the same bus during scan. Since you have
> > > connected devices to both connectors on the card, you must terminate
> > > both devices.
> > 
> > Okay, so far I understood.
> > 
> 
> And, AFAIK, the controller stands in the bus between the disk and the tape,
> so you should terminate both

yes.

> AND disable the controller internal terminator

no.  you should terminate high-on low-off.  how can the 50 pin end
terminate the extra wires of the 68 conductor wide side?

> or leave it in AUTO mode.

this might well work.  if not, set host adapter/controller to
terminate high-on low-off.

-- 
J o h a n  K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: missing sysrq

[Mike A. Harris]

On Fri, 1 Jun 2001, Dieter Nützel wrote:

>> > In article <[EMAIL PROTECTED]> you wrote:
>> > > However, if I go to /proc/sys/kernel/sysrq does not exist.
>> >
>> > It is a compile time option, so the person who compiled your kernel
>> > left it out.
>>
>> I compiled it, and the sysrq is definitely in the config. No doubt at
>> all. I also use make mrproper and config again before dep and actual
>> compile. Maybe it is just a quirk/oddball.
>>
>> D. Stimits, [EMAIL PROTECTED]
>
>Have you tried "echo 1 > /proc/sys/kernel/sysrq"?
>You need both, compiled in and activation.

If you *know* it is compiled into your kernel, and you *know* it
is enabled via the above, and it still does not work, do the
following:

Run:

showkey -s

Then press LALT quickly followed by SYSRQ, and keep holding both
down, and you should see:

0x38
0x54

You might see a bunch of extra 0x38's which is ok.

If however when you press ALT-SYSRQ you see:

0x38 0x54 0xd4

and are still holding both keys down, then your keyboard is
broken and incompatible with the kernel SYSRQ feature.

A proper keyboard will only show "0x38 0x54".  I have written a
patch for SYSRQ to allow it to be used with broken keyboards that
send the make+break code for the SYSRQ sequence simultaneously.

If you need it, let me know and I'll send it to you.



--
Mike A. Harris  -  Linux advocate  -  Open Source advocate
   Opinions and viewpoints expressed are solely my own.
--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: temperature standard - global config option?

[Michael H. Warfield]

On Thu, Jun 07, 2001 at 08:03:58PM -0400, Albert D. Cahalan wrote:
> Chris Boot writes:
> 
>  Kelvins good idea in general - it is always positive ;-)
> 
>  0.01*K fits in 16 bits and gives reasonable range.
> ...
> > OK, I think by now we've all agreed the following:
> >  - The issue is NOT displaying temperatures to the user, but a userspace
> >program reading them from the kernel.  The userspace program itself can
> >do temperature conversions for the user if he/she wants.
> >  - The most preferable units would be decikelvins, as the value can give a
> >relatively precise as well as wide range of numbers ranging from absolute
> >zero to about 6340 degrees Celsius ((65535 / 10) - 273) which is well
> >within anything that a computer can operate.  It also gives us a good
> >base for all sorts of other temperature sensing devices.
> >
> > Do we all agree on those now?
> 
> I nearly do.
> 
> There isn't any need to cram the data into 16 bits.
> The offset to Celsius is 273.15 degrees.
> So hundredths of a degree, in Kelvin, is a better choice.

[Let's see if I can argue boths sides of this fence plus a
third here.]

Who cares if you cram it into 16 bits.  It still works.

I think we can agree that negative degrees Kelvin are not relevant
(outside of VERY esoteric physics circles where negative absolute
temperatures are real and represent quantum mechanical states in
"population inversions".  i.e. Quantum mechanical temperatures hotter
than infinite - reference SciAm back in the mid 1970s.  I won an arguement
with a PhD high energy physics prof over that point back then).

Therefore, we have a 16 bit unsigned quantity which gives us a
range of 0 - 65535.  Translated as hundreths of a Kelvin, that works
out to 0 -> 655.35 K.  Ok...  That's -273.15 C -> 382.20 C.  And...
That's roughly -524 F -> 720 F.  Ok...  That covers everything from
superfluid Helium through MELTS GLASS with room for bobble.

In 16 bits.

What's the problem?

Other than what's the need for two digits of precision in something
that does not have even 1/100 of that accuracy?

A plague of many measuring systems is "false precision".  Why
provide precision (the units to which a measurement can be divided or
quantized) when the accuracy can not support it.  I would be amazed if
ANY CPU temperature monitors were any more accurate than to a degree C/K
or ~2 degrees F).  Hundreths of a degree K is basically silly nonsense.
The precision even for tenths of a degree K or C are just not supported by
the accuracy of the measuring device and are meaningless.  Even if it
COULD provide even something remotely similar to that level of precision
in it's accuracy, is it really relevant to know the CPU temperature to
1/100 of a degree C?

Looking at most temperature measuring chips today, unless you are
looking at lab-quality high-precision high-accuracy sensors, you are really
talking about a 12 bit sensor (+- a couple of bits) with an accuracy of
not much better than +-1 C.

Add the tenths if you want to be silly but returning hundreths
is just meaningless jibberish.

Mike
-- 
 Michael H. Warfield|  (770) 985-6132   |  [EMAIL PROTECTED]
  (The Mad Wizard)  |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9  |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471|  possible worlds.  A pessimist is sure of it!

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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/

oops in 2.4.2: in d_instantiate(), inode->i_dentry.next was 0

[Michael Walfish]

Received an oops in the 2.4.2 kernel on an x86 SMP system, 640 MB RAM
(Compaq DL380 Server). The line of code this crashed on is in fs/dcache.c:
void d_instantiate(struct dentry *entry, struct inode * inode)
[snip]
-->list_add(>d_alias, >i_dentry);

Believe inode->i_dentry.next was equal to 0.

Sadly, am unable to reproduce this. Relevant part of .config at the end of
this message. Oops is below. I have a memory dump (from the lkcd utilities)
if anyone is interested. Please let me know if you would like more
information.

Please include me in replies as I am not on the mailing list. Thank you in
advance.

-Mike Walfish

++

Unable to handle kernel NULL pointer dereference at virtual address 00
04
c01463b0
*pde = 
Oops: 0002
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax: e7936a58   ebx: e7936a20   ecx: d33a5a40   edx: 
esi: c2fdc1e0   edi: c574bf60   ebp: 0007   esp: c574bf38
ds: 0018   es: 0018   ss: 0018
Process exim (pid: 1628, stackpage=c574b000)
Stack: e7936a20 c01c782f e7936a20 d33a5a40  080b7310 080ab1c2
bfffe134
   3131315b 005d3538 c0145aa9 c05a4740 c0258cd8 c2fdc1e0 e7d478c0
c0133b71
   c574bf58 0007 2bb1 c01c8330 d33a5b44  d33a5b44
c01c8f8c
Call Trace: [] [] [] [] []
[] []
Code: 89 42 04 89 53 38 8d 51 10 89 50 04 89 41 10 89 4b 08 c6 05

>>EIP; c01463b0<=
Trace; c01c782f 
Trace; c0145aa9 
Trace; c0133b71 
Trace; c01c8330 
Trace; c01c8f8c 
Code;  c01463b0 
 <_EIP>:
Code;  c01463b0<=
   0:   89 42 04  mov%eax,0x4(%edx)   <=
Code;  c01463b3 
   3:   89 53 38  mov%edx,0x38(%ebx)
Code;  c01463b6 
   6:   8d 51 10  lea0x10(%ecx),%edx
Code;  c01463b9 
   9:   89 50 04  mov%edx,0x4(%eax)
Code;  c01463bc 
   c:   89 41 10  mov%eax,0x10(%ecx)
Code;  c01463bf 
   f:   89 4b 08  mov%ecx,0x8(%ebx)
Code;  c01463c2 
  12:   c6 05 00 00 00 00 00  movb   $0x0,0x0


==

CONFIG_X86=y
CONFIG_ISA=y
CONFIG_UID16=y
CONFIG_MODULES=y
CONFIG_KMOD=y
CONFIG_MPENTIUMIII=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_PGE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_NOHIGHMEM=y
CONFIG_MTRR=y
CONFIG_SMP=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_NET=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
CONFIG_HOTPLUG=y
CONFIG_SYSVIPC=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
CONFIG_PM=y
CONFIG_PNP=y
CONFIG_ISAPNP=y
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_CPQ_DA=y
CONFIG_BLK_DEV_LOOP=m
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_RAID0=y
CONFIG_PACKET=y
CONFIG_NETFILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_NF_CONNTRACK=m
CONFIG_IP_NF_FTP=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_NAT_FTP=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_COMPAT_IPCHAINS=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_CMD640=y
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDE_MODES=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_SD_EXTRA_DEVS=40
CONFIG_SCSI_DEBUG_QUEUES=y
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_AIC7XXX=y
CONFIG_AIC7XXX_TCQ_ON_BY_DEFAULT=y
CONFIG_AIC7XXX_CMDS_PER_DEVICE=32
CONFIG_AIC7XXX_RESET_DELAY=5
CONFIG_SCSI_SYM53C8XX=y
CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=32
CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32
CONFIG_SCSI_NCR53C8XX_SYNC=80
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
CONFIG_NET_ETHERNET=y
CONFIG_NET_PCI=y
CONFIG_EEPRO100=m
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_SERIAL_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
CONFIG_MOUSE=y
CONFIG_PSMOUSE=y
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_NTFS_FS=m
CONFIG_PROC_FS=y
CONFIG_DEVPTS_FS=y
CONFIG_EXT2_FS=y
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
CONFIG_SUNRPC=m
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_SMB_FS=m
CONFIG_MSDOS_PARTITION=y
CONFIG_SMB_NLS=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m

Re: temperature standard - global config option?

[Michael H. Warfield]

On Thu, Jun 07, 2001 at 09:30:54PM +, mirabilos {Thorsten Glaser} wrote:
> It was posted by L. K. where I now add my 0.02 EUR...
> > On Thu, 7 Jun 2001, Albert D. Cahalan wrote:
> > > Negative temperatures do not really exist.
> > Are you really sure about this ?

> I am. I made Abitur (german degree after 13yrs of school)
> with physics being an important course, and there can not
> be any temperature less than 0 K (or -273.15°C if you want).
> This is because temperature is nothing but the movement of
> pieces of materie (and even photons, ergo energy).

Then you must have blown your quantum finals.  Royally.  ESPECIALLY
after that statement about "temperature is nothing but the movement of
pieces of materie".  Not even close, once you get into the quant.

Mathematically and quantum mechanically, negative absolute
temperatures do exist.  In quantum mechanics, temperature is expressed as
probability populations in various quantum states.

Absolute zero is the quantum state were all particles are in
the ground state.  An infinite temperature is, quantum mechanically,
the condition where all states, ground and energetic, have an equal
probability of population.

A "population inversion" (a condition where the energized states
are more likely to be populated than the ground states) is at the heart
of many things we take for granted today such as lasers, masers, leds,
NMR (Nuclear Magnetic Resonance) and MRI (the medical use of NMR).

Those "population inversions" represents an "energized state"
that is more energetic than the state that would be present in a steady
state infinite temperature.

Mathematically, those states can actually be treated as negative
absolute temperatures.  IOW, negative absolute temperatures are actually
hotter than infinite.

It's true that these are not STEADY STATE conditions or in
equilibrium (which is how we take advantage of populations inversions -
by their actions in returning to equilibrium), but the math still works.
Just check out a few issues of Scientific American from the mid 1970's
on "Negative Absolute Temperatures in Nuclear Magnetic Resonance" and
to the scientific journals they reference.  I won an argument with
a physics prof (PhD in high energy physics) over that very issue when
I did the same thing in a 400 level senior level physics lab on NMR back
then.  It's actually pretty damn simple, once you work the math, and it
agravated him that he didn't believe it but couldn't argue with the math
till he saw the work and publication from someone else.  Then he conceeded
that I had him and I had been right.

IAC...  Negative absolute temperatures are about as meaningless
to this particular discussion as is expressing the temperature in 1/100s
of a Kelvin which would have a precision than exceeds the accuracy of
the measuring chips by two orders of magnitude.  IOW...  Both are silly
and meaningless to this case.  One is out of range in magnitude and one
is out of the range of accuracy.

> -mirabilos
> -- 
> C:\>debug
> -e100 EA F0 FF 00 F0
> -g
> --->Enjoy!

Mike
-- 
 Michael H. Warfield|  (770) 985-6132   |  [EMAIL PROTECTED]
  (The Mad Wizard)  |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9  |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471|  possible worlds.  A pessimist is sure of it!

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: missing sysrq

[Mike A. Harris]

On Thu, 31 May 2001, D. Stimits wrote:

>Date: Thu, 31 May 2001 17:48:34 -0600
>From: D. Stimits <[EMAIL PROTECTED]>
>To: unlisted-recipients:;;@timpanogas.com (no To-header on input)
>Cc: [EMAIL PROTECTED]
>Content-Type: text/plain; charset=us-ascii
>Subject: Re: missing sysrq
>
>Bernd Eckenfels wrote:
>>
>> In article <[EMAIL PROTECTED]> you wrote:
>> > However, if I go to /proc/sys/kernel/sysrq does not exist.
>>
>> It is a compile time option, so the person who compiled your kernel left it
>> out.
>
>I compiled it, and the sysrq is definitely in the config. No doubt at
>all. I also use make mrproper and config again before dep and actual
>compile. Maybe it is just a quirk/oddball.

What does this say:

ksyms -a |grep -i sysrq


--
Mike A. Harris  -  Linux advocate  -  Open Source advocate
   Opinions and viewpoints expressed are solely my own.
--
Who knows what dangerous code lurks in the hearts of men?
Only the Shadowman(TM) knows...  Mike A. Harris <[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: [patch] 32-bit dma memory zone

[David S. Miller]

Richard Henderson writes:
 > On most alphas we use only one zone -- ZONE_DMA.  The iommu makes it
 > possible to do 32-bit pci to the entire memory space.
 > 
 > For those alphas without an iommu, we also set up ZONE_NORMAL.

And on sparc64 since all machines have an iommu, we use just ZONE_DMA
for everything.

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: VM Report was:Re: Break 2.4 VM in five easy steps

[Jonathan Morton]

At 12:29 am +0100 8/6/2001, Shane Nay wrote:
>(VM report at Marcelo Tosatti's request.  He has mentioned that rather than
>complaining about the VM that people mention what there experiences were.  I
>have tried to do so in the way that he asked.)

>> By performance you mean interactivity or throughput?
>
>Interactivity.  I don't have any throughput needs to speak of.
>
>I just ran a barage of tests on my machine, and the smallest it would ever
>make the cache was 16M, it would prefer to kill processes rather than make
>the cache smaller than that.

http://www.chromatix.uklinux.net/linux-patches/vm-update-2.patch

Try this.  I can't guarantee it's SMP-safe yet (I'm leaving the gurus to
that, but they haven't told me about any errors in the past hour so I'm
assuming they aren't going to find anything glaringly wrong...), but you
might like to see if your performance improves with it.  It also fixes the
OOM-killer bug, which you refer to above.

Some measurements, from my own box (1GHz Athlon, 256Mb RAM):

For the following benchmarks, physical memory availability was reduced
according to the parameter in the left column.  The benchmark is the
wall-clock time taken to compile MySQL.

mem=2.4.5   earlier tweaks  now
48M 8m30s   6m30s   5m58s
32M unknown 2h15m   12m34s

The following was performed with all 256Mb RAM available.  This is
compilation of MySQL using make -j 15.

kernel: 2.4.5   now
time:   6m30s   6m15s
peak swap:  190M70M

For the following test, the 256Mb swap partition on my IDE drive was
disabled and replaced with a 1Gb swapfile on my Ultra160 SCSI drive.  This
is compilation of MySQL using make -j 20.

kernel: 2.4.5   now
time:   7m20s   6m30s
peak swap:  370M254M

Draw your own conclusions.  :)

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

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

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+(*)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: VM suggestion...

[Marcelo Tosatti]

On Fri, 8 Jun 2001, Erik Mouw wrote:

> On Thu, Jun 07, 2001 at 04:36:05PM -0300, Marcelo Tosatti wrote:
> > On Thu, 7 Jun 2001, Jeff Garzik wrote:
> > > Statistics like this are cheap to use in runtime and should provide
> > > concrete information rather than guesses and estimations...
> > 
> > I've been using LTT (Linux Trace Toolkit) to do similar stuff. 
> 
> But you can't expect everybody to use LTT. If you just make a couple of
> counters and give an easy way to get the values from userspace (proc,
> sysctl, syslog), you'll get bug reports with real information. IMHO
> data from real world workloads make more sense than "it doesn't work"
> reports.

Agreed.

I'm looking forward to do something similar to what Paul Buder suggested,
when I have time. 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: temperature standard - global config option?

[Albert D. Cahalan]

Chris Boot writes:

 Kelvins good idea in general - it is always positive ;-)

 0.01*K fits in 16 bits and gives reasonable range.
...
> OK, I think by now we've all agreed the following:
>  - The issue is NOT displaying temperatures to the user, but a userspace
>program reading them from the kernel.  The userspace program itself can
>do temperature conversions for the user if he/she wants.
>  - The most preferable units would be decikelvins, as the value can give a
>relatively precise as well as wide range of numbers ranging from absolute
>zero to about 6340 degrees Celsius ((65535 / 10) - 273) which is well
>within anything that a computer can operate.  It also gives us a good
>base for all sorts of other temperature sensing devices.
>
> Do we all agree on those now?

I nearly do.

There isn't any need to cram the data into 16 bits.
The offset to Celsius is 273.15 degrees.
So hundredths of a degree, in Kelvin, is a better choice.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: VM suggestion...

[Erik Mouw]

On Thu, Jun 07, 2001 at 04:36:05PM -0300, Marcelo Tosatti wrote:
> On Thu, 7 Jun 2001, Jeff Garzik wrote:
> > Statistics like this are cheap to use in runtime and should provide
> > concrete information rather than guesses and estimations...
> 
> I've been using LTT (Linux Trace Toolkit) to do similar stuff. 

But you can't expect everybody to use LTT. If you just make a couple of
counters and give an easy way to get the values from userspace (proc,
sysctl, syslog), you'll get bug reports with real information. IMHO
data from real world workloads make more sense than "it doesn't work"
reports.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: [EMAIL PROTECTED]
WWW: http://www-ict.its.tudelft.nl/~erik/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: Large ramdisk crashes system

[David Woodhouse]

[EMAIL PROTECTED] said:
> the kernel is 2.4.5 with 'Simple RAM-based file system support' turned on.

> I issued the following commands.

> mkfs /dev/ram0 40
> mount /dev/ram0 /mnt
> dd if=/dev/zero of=/mnt/junk bs=1024 count=50 

Why turn on ramfs if you're not going to use it? 

 mount -t ramfs none /mnt/junk

Use the one in the -ac tree and you get resource limits, which will be 
useful. The VM will still be broken, but you should get away with a little 
more.

--
dwmw2


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

Re: Large ramdisk crashes system

[Marcelo Tosatti]

On Thu, 7 Jun 2001, Paul Buder wrote:

> I am trying to create a system which boots off of a cd and has no hard
> disks.  So it needs ramdisks.  But I haven't had much luck creating
> large ones.
> 
> I tried on two different boxes.  In both cases the kernel is 2.4.5 with
> 'Simple RAM-based file system support' turned on.
> 
> One box is a dual Pentium 750 with a gig of ram in it.  I had the
> kernel 'Default RAM disk size' set to 80 for this box.  I issued
> the following commands.
> 
> mkfs /dev/ram0 40
> mount /dev/ram0 /mnt
> dd if=/dev/zero of=/mnt/junk bs=1024 count=50
> 
> This is fine, dd creates a 400 meg file, reports there isn't enough
> space and exits.  But if I change the first line to
> 
> mkfs /dev/ram0 50
> 
> I'm essentially crashed.  I can ping the box and switch between virtual
> terminals but that's it.  Any program that was running on the other
> virtual terminals is frozen (as in top, tail, login).  The dd is frozen
> and can't be control-c'd.  so I can't do anything other than powercycle.
> I should have at least 400 megs of ram left for the system so I don't
> get it.
> 
> I tried the same thing on a 128 meg box.  The results were similar.  A 40
> meg ram disk worked.  A 60 meg ram disk crashed the box.  The numbers
> seem a little odd since in both cases the magic threshold seems to be
> roughly 40% of ram.
> 
> I get no messages in the system logfiles nor an oops on the screen.
> 
> Any ideas?

Can you get the (traced by ksymoops) backtrace of dd and kswapd
everything is locked? 

You can do that with sysrq. 

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

Re: Linux support for PDC20268

[Andre Hedrick]

Frank,

"Frank Tiernan" does not exist at Promise anymore, and that company is
HOSTILE towards Linux Now.

On Tue, 5 Jun 2001, Frank Neuber wrote:

> Hi Andre,
> I try to set up IDE-Support for ARM-Integrator with an PDC20268.
> This controller is currently not supported in 
> linux/drivers/ide/pdc202xx.c
> It is possible to define this controller with the same behavior as 
> PDC20267 in linux/drivers/ide/pdc202xx.c?
> Because the ARM-Integrator is not compatible to i386 is it possible
> to get problems with the PDC-BIOS?
> 
> Best regards
> Frank
> 
> PS: The Mailaddress of Frank Tiernan ([EMAIL PROTECTED]) is not valid.
> Would you be so kind to give me his valid e-mail address ...
> 
> -- 
> Dipl.-Ing. Elektrotechnik convergence integrated media gmbh / HW
> Frank NeuberRosenthalerstr.51 / 10178 Berlin
> Email:  [EMAIL PROTECTED]   Phone:  +49(0)30-72 62 06 50
> WWW:www.convergence.de  Fax:+49(0)30-72 62 06 55
> 

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

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

Large ramdisk crashes system

[Paul Buder]

I am trying to create a system which boots off of a cd and has no hard
disks.  So it needs ramdisks.  But I haven't had much luck creating
large ones.

I tried on two different boxes.  In both cases the kernel is 2.4.5 with
'Simple RAM-based file system support' turned on.

One box is a dual Pentium 750 with a gig of ram in it.  I had the
kernel 'Default RAM disk size' set to 80 for this box.  I issued
the following commands.

mkfs /dev/ram0 40
mount /dev/ram0 /mnt
dd if=/dev/zero of=/mnt/junk bs=1024 count=50

This is fine, dd creates a 400 meg file, reports there isn't enough
space and exits.  But if I change the first line to

mkfs /dev/ram0 50

I'm essentially crashed.  I can ping the box and switch between virtual
terminals but that's it.  Any program that was running on the other
virtual terminals is frozen (as in top, tail, login).  The dd is frozen
and can't be control-c'd.  so I can't do anything other than powercycle.
I should have at least 400 megs of ram left for the system so I don't
get it.

I tried the same thing on a 128 meg box.  The results were similar.  A 40
meg ram disk worked.  A 60 meg ram disk crashed the box.  The numbers
seem a little odd since in both cases the magic threshold seems to be
roughly 40% of ram.

I get no messages in the system logfiles nor an oops on the screen.

Any ideas?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: scsi disk defect or kernel driver defect ?

[J . A . Magallon]

On 06.07 Nico Schottelius wrote:
> >
> > Based upon the lspci output you posted earlier, aic7880 has a single
> > SCSI bus.
> 
> Oh. That could really be a problem.. I though having two different
> connectors on the board would make two different buses..
> I must have been wrong.
> 
> > So you must mean two internal connectors. Both of your devices
> > (HD and Tape) do show up on the same bus during scan. Since you have
> > connected devices to both connectors on the card, you must terminate
> > both devices.
> 
> Okay, so far I understood.
> 

And, AFAIK, the controller stands in the bus between the disk and the tape,
so you should terminate both AND disable the controller internal terminator
or leave it in AUTO mode.

-- 
J.A. Magallon   #  Let the source be with you...
mailto:[EMAIL PROTECTED]
Linux Mandrake release 8.1 (Cooker) for i586
Linux werewolf 2.4.5-ac9 #1 SMP Wed Jun 6 09:57:46 CEST 2001 i686
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CacheFS

[Albert D. Cahalan]

Jan Kasprzak writes:

> Another goal is to use the Linux filesystem
> as a backing store (as opposed to the block device or single large file
> used by CODA).
...
> - kernel module, implementing the filesystem of the type "cachefs"
>   and a character device /dev/cachefs
> - user-space daemon, which would communicate with the kernel
>   over /dev/cachefs and which would manage the backing store
>   in a given directory.
>
>   Every file on the front filesystem (NFS or so) volume will be cached
> in two local files by cachefsd: The first one would contain the (parts of)
...
> * Should the cachefsd be in user space (as it is in the prototype
> implementation) or should it be moved to the kernel space? The
> former allows probably better configuration (maybe a deeper
> directory structure in the backing store), but the later is
> faster as it avoids copying data between the user and kernel spaces.

I think that, if speed is your goal, you should have the kernel
code use swap space for the cache. Look at what tmpfs does, but
running over top of tmpfs leaves you with the overhead of running
two filesystems and a daemon. It is better to be direct.

Maybe this shouldn't even be a filesystem. You could have a general
way to flag a filesystem as being significantly slower than swap.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: temperature standard - global config option?

[Chris Adams]

Once upon a time, L. K. <[EMAIL PROTECTED]> said:
>On Thu, 7 Jun 2001, Albert D. Cahalan wrote:
>> Negative temperatures do not really exist.
>
>Are you really sure about this ?

He's positive!


-- 
Chris Adams <[EMAIL PROTECTED]>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: VM suggestion...

[Marcelo Tosatti]

On Thu, 7 Jun 2001, Stuart MacDonald wrote:

> From: "Marcelo Tosatti" <[EMAIL PROTECTED]>
> > The problem is that we _cannot_ base ourselves simply on practical results
> > from a _limited_ amount of workloads. Also remember the tests we (at least
> > I do) are benchmarks which try to use all resources all the time upon
> > completion.
> 
> Isn't this the point of the X.odd.Y kernels? Spit the stats out into the
> syslog, along with a message of "If you see these, please mail them
> along to [EMAIL PROTECTED] and a description of your workload
> if it's not too much trouble."

First of all, [EMAIL PROTECTED][EMAIL PROTECTED]/. 

That sounds interesting, yes. I'll look into that once I find sometime.

Thanks for your suggestion. 

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

RE: PROBLEM: I/O system call never returns if file desc is closed in the

[David Schwartz]

> At 22:35 +0100 2001-06-06, Alan Cox wrote:

> >  > This report describes a problem in the usage of file
> >  > descriptors across

> >>  multiple threads. When one thread closes a file descriptor, another
> >>  thread which waits for an I/O on that file descriptor is not notified
> >>  and blocks forever.

> >THe I/O does not block forever, it blocks until completed.

> That's still "forever" if you don't specify a timeout in the select.

If you don't want to block until an operation completes, then don't ask to!

> >The actual final
> >closure of the object occurs when the last operation on it exits

> Select is defined as to return, with the appropriate bit set, if/when
> a nonblocking read/write on the file descriptor won't block. You'd
> get EBADF in this case, therefore causing the select to return would
> be a Good Thing.

That is not quite correct. That is a good approximate definition of
'select's behavior, but it is not exact. As for your assertion that a
noblocking read/write wouldn't block, that's not necessarily true. Remember,
the 'close' may not have taken affect yet, since the descriptor is still in
use by virtue of being selected on.

> A related problem is that the second thread my be inside a blocking
> read() instead of a select() call. It'd never continue.  :-(

Perfect. Doing this is absolutely, positively wrong and the more you are
punished for it, the better. It's as wrong as calling 'free' on a chunk of
memory when another thread may be usign it. It is impossible to make this
work safely, as another thread could open a socket or file and get the same
descriptor write before the call to 'read' is entered. There's no possible
way to do this because there is no 'unlock a mutex and read' operation.

> HOWEVER: IMHO it's bad design to distribute the responsibility for
> file descriptors between threads.

Why? That's a great design and it's absolutely essential in many cases.
Suppose, for example, I have two descriptors I want to write to. If I assign
one thread to each socket permanently, then I'm 100% guaranteed a context
switch every time I change which socket I'm writing to, so if there's lots
of small bits of data going out both of them, my performance will suck. But
if I assign one thread to both socket descriptors, I'm guaranteed that one
connection will stall if the the application-level send queue for the other
has been swapped out to disk. Not distributing network I/O across threads
dynamically is a recipe for either low performance or bursty performance.

DS

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: temperature standard - global config option?

[Chris Boot]

Hi,

>>> Kelvins good idea in general - it is always positive ;-)
>>> 
>>> 0.01*K fits in 16 bits and gives reasonable range.
>>> 
>>> but may be something like K<<6 could be a option? (to allow use of shifts
>>> instead of muls/divs). It would be much more easier to extract int part.
>>> 
>>> just my 2 eurocents.
>> 
>> Why not make it in Celsius ? Is more easy to read it this way.
> 
> It's easier for you as a user to read, but slightly harder to deal with inside
> the code.  
> It's really a user-space issue, inside the kernel should be as standardized as
> possible, and
> Kelvins make the most sense there.

OK, I think by now we've all agreed the following:
 - The issue is NOT displaying temperatures to the user, but a userspace
   program reading them from the kernel.  The userspace program itself can
   do temperature conversions for the user if he/she wants.
 - The most preferable units would be decikelvins, as the value can give a
   relatively precise as well as wide range of numbers ranging from absolute
   zero to about 6340 degrees Celsius ((65535 / 10) - 273) which is well
   within anything that a computer can operate.  It also gives us a good
   base for all sorts of other temperature sensing devices.

Do we all agree on those now?

-- 
Chris Boot
[EMAIL PROTECTED]

#define QUESTION ((2b) || (!2b))

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: Break 2.4 VM in five easy steps

[Marcelo Tosatti]

On Thu, 7 Jun 2001, Shane Nay wrote:

> On Thursday 07 June 2001 13:00, Marcelo Tosatti wrote:
> > On Thu, 7 Jun 2001, Shane Nay wrote:
> > > (Oh, BTW, I really appreciate the work that people have done on the VM,
> > > but folks that are just talking..., well, think clearly before you impact
> > > other people that are writing code.)
> >
> > If all the people talking were reporting results we would be really happy.
> >
> > Seriously, we really lack VM reports.
> 
> Okay, I've had some problems with the VM on my machine, what is the most 
> usefull way to compile reports for you?  

1) Describe what you're running. (your workload)
2) Describe what you're feeling. (eg "interactivity is crap when I run
this or that thing", etc) 

If we need more info than that I'll request in private. 

Also send this reports to the linux-mm list, so other VM hackers can also
get those reports and we avoid traffic on lk.

> I have modified the kernel for a few different ports fixing bugs, and
> device drivers, etc., but the VM is all greek to me, I can just see
> that caching is hyper aggressive and doesn't look like it's going back
> to the pool..., which results in sluggish performance.

By performance you mean interactivity or throughput? 

> Now I know from the work that I've done that anecdotal information is
> almost never even remotely usefull.  

If we need more info, we will request. 

> Therefore is there any body of information that I can read up on to
> create a usefull set of data points for you or other VM hackers to
> look at?  (Or maybe some report in the past that you thought was
> especially usefull?)

Just do what I described above. 

Thanks

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

Re: Configure.help i18n system

[Andries . Brouwer]

> I wonder if the Configure.help text should not possibly be even _more_
> distributed than just splitting it up into different files. It might very
> well be acceptable to actually distribute it over the net (and have just
> a mapping of config options into www-addresses or something).

I think this is a bad idea.

(i) The kernel has high visibility, and work on the kernel
[even if only on the Documentation subdirectory] has high "prestige".
As a consequence, parts of the kernel tree are kept much better
up-to-date than documentation found elsewhere.

(I have been trying for years to find people willing to do something
to the very outdated ioctl_list.2 or proc.5 or bootparam.7.)

When distributed, very quickly Configure.help would be outdated,
and of very uneven format and quality.

(ii) So far, building a kernel involved getting a single tarball.
If the help for over a thousand configuration options is found
a hundred different places on the net, of which five are currently
unreachable, things get really cumbersome.

The current system is not so bad.

Andries

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: temperature standard - global config option?

[mirabilos {Thorsten Glaser}]

It was posted by L. K. where I now add my 0.02 EUR...
> On Thu, 7 Jun 2001, Albert D. Cahalan wrote:
> > Negative temperatures do not really exist.
> Are you really sure about this ?

I am. I made Abitur (german degree after 13yrs of school)
with physics being an important course, and there can not
be any temperature less than 0 K (or -273.15°C if you want).
This is because temperature is nothing but the movement of
pieces of materie (and even photons, ergo energy).

-mirabilos
-- 
C:\>debug
-e100 EA F0 FF 00 F0
-g
--->Enjoy!

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

Re: [patch] 32-bit dma memory zone

[Linus Torvalds]

On Thu, 7 Jun 2001, Jens Axboe wrote:
> 
> I'd like to push this patch from the block highmem patch set, to prune
> it down and make it easier to include it later on :-)
> 
> This patch implements a new memory zone, ZONE_DMA32. It holds highmem
> pages that are below 4GB, as we can do I/O on those directly. Also if we
> do need to bounce a > 4GB page, we can use pages from this zone and not
> always resort to < 960MB pages.

Patrick Mochel has another patch that adds another zone on x86: the "low
memory" zone for the 0-1MB area, which is special for some things, notably
real mode bootstrapping (ie the SMP stuff could use it instead of the
current special-case allocations, and Pat needs it for allocating low
memory pags for suspend/resumt).

I'd like to see what these two look like together.

But even more I'd like to see a more dynamic zone setup: we already have
people talking about adding memory dynamically at run-time on some of the
server machines, which implies that we might want to add zones at a later
time, along with binding those zones to different zonelists.

This is also an issue for different architectures: some of these zones do
not make any _sense_ on other architectures. For example, what's the
difference between ZONE_HIGHMEM and ZONE_NORMAL on a sane 64-bit
architecture (right now I _think_ the 64-bit architectures actually make
ZONE_NORMAL be what we call ZONE_DMA32 on x86, because they already need
to be able to distinguish between memory that can be PCI-DMA'd to, and
memory that needs bounce-buffers. Or maybe it's ZONE_DMA that they use for
the DMA32 stuff?).

Anyway, what I'm saying is that "GFP_HIGHMEM" already traverses three
zones, and with ZONE_1M and ZONE_DMA32, you'd have a list of five of them.
Of which only _two_ would actually be meaningful on some architectures.

So should we not try to have some nicer interface like

create_zone(, offset, end);

add_zone(, zonelist);

and then we could on x86 have

create_zone(zone+0, 0, 1M);
create_zone(zone+1, 1M, 16M);
create_zone(zone+2, 16M, 896M);
create_zone(zone+3, 896M, 4G);
create_zone(zone+4, 4G, 64G);

.. populate the zones ..

add_zone(zone+4, GFP_HIGHMEM);

add_zone(zone+3, GFP_HIGHMEM);
add_zone(zone+3, GFP_DMA32);

add_zone(zone+2, GFP_HIGHMEM);
add_zone(zone+2, GFP_DMA32);
add_zone(zone+2, GFP_NORMAL);

/* the 1M-16M zone is usable for just about everything */
add_zone(zone+1, GFP_HIGHMEM);
add_zone(zone+1, GFP_DMA32);
add_zone(zone+1, GFP_NORMAL);
add_zone(zone+1, GFP_DMA);

/* The low 1M can be used for everything */
add_zone(zone+0, GFP_HIGHMEM);
add_zone(zone+0, GFP_DMA32);
add_zone(zone+0, GFP_NORMAL);
add_zone(zone+0, GFP_DMA);
add_zone(zone+0, GFP_LOWMEM);

and eventually, when we get hot-plug memory, the hotplug event would be
just something like

zone = kmalloc(sizeof(struct zone), GFP_KERNEL);
create_zone(zone, start, end);

.. populate it with the newly added memory ..

/*
 * Add it to all the appropriate zones (I suspect hotplug will
 * only occur in high memory, but who knows? 
 */
add_zone(zone, GFP_HIGHMEM);
...

(Note how this might also be part of the equation of how you add nodes
dynamically in a NuMA environment).

And see how the above would mean that something like sparc64 wouldn't need
to see five zones when it reall yonly needs two of them.

Linus

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

Re: Please test: workaround to help swapoff behaviour

[Marcelo Tosatti]

On Thu, 7 Jun 2001, Bulent Abali wrote:

> 
> I tested your patch against 2.4.5.  It works.  No more lockups.  Without
> the
> patch it took 14 minutes 51 seconds to complete swapoff (this is to recover
> 1.5GB of
> swap space).  During this time the system was frozen.  No keyboard, no
> screen, etc. Practically locked-up.
> 
> With the patch there are no more lockups. Swapoff kept running in the
> background.
> This is a winner.
>
> But here is the caveat: swapoff keeps burning 100% of the cycles until it
> completes.

Yup. Wait a while until the dead swap cache issue is sorted out. 

When that finally happens, the time spent in swapoff will probably be
"acceptable".

> This is not going to be a big deal during shutdowns.  Only when you enter
> swapoff from
> the command line it is going to be a problem.
> 
> I looked at try_to_unuse in swapfile.c.  I believe that the algorithm is
> broken.

Yes. 

> For each and every swap entry it is walking the entire process list
> (for_each_task(p)).  It is also grabbing a whole bunch of locks
> for each swap entry.  It might be worthwhile processing swap entries in
> batches instead of one entry at a time.

The real fix is to make the processing the other way around --- go looking
into the pte's and from there do the swapins. 

Don't have the time to do everything, though. :) 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: Background scanning change on 2.4.6-pre1

[Andreas Dilger]

Linus writes:
> On Thu, 7 Jun 2001, Marcelo Tosatti wrote:
> > Who did this change to refill_inactive_scan() in 2.4.6-pre1 ? 
> 
> I think it was Andreas Dilger..

Definitely NOT.  I don't touch MM stuff.  I do filesystems and LVM only.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: Break 2.4 VM in five easy steps

[LA Walsh]

"Eric W. Biederman" wrote:

> LA Walsh <[EMAIL PROTECTED]> writes:
>
> > Now for whatever reason, since 2.4, I consistently use at least
> > a few Mb of swap -- stands at 5Meg now.  Weird -- but I notice things
> > like nscd running 7 copies that take 72M.  Seems like overkill for
> > a laptop.
>
> So the question becomes why you are seeing an increased swap usage.
> Currently there are two canidates in the 2.4.x code path.
>
> 1) Delayed swap deallocation, when a program exits after it
>has gone into swap it's swap usage is not freed. Ouch.

---
Double ouch.  Swap is backing a non-existent program?

>
>
> 2) Increased tenacity of swap caching.  In particular in 2.2.x if a page
>that was in the swap cache was written to the the page in the swap
>space would be removed.  In 2.4.x the location in swap space is
>retained with the goal of getting more efficient swap-ins.


But if the page in memory is 'dirty', you can't be efficient with swapping
*in* the page.  The page on disk is invalid and should be released, or am I
missing something?

> Neither of the known canidates from increasing the swap load applies
> when you aren't swapping in the first place.  They may aggrevate the
> usage of swap when you are already swapping but they do not cause
> swapping themselves.  This is why the intial recommendation for
> increased swap space size was made.  If you are swapping we will use
> more swap.
>
> However what pushes your laptop over the edge into swapping is an
> entirely different question.  And probably what should be solved.


On my laptop, it is insignificant and to my knowledge has no measurable
impact.  It seems like there is always 3-5 Meg used in swap no matter what's
running (or not) on the system.

> > I think that is the point -- it was supported in 2.2, it is, IMO,
> > a serious regression that it is not supported in 2.4.
>
> The problem with this general line of arguing is that it lumps a whole
> bunch of real issues/regressions into one over all perception.  Since
> there are multiple reasons people are seeing problems, they need to be
> tracked down with specifics.

---
Uhhh, yeah, sorta -- it's addressing the statement that a "new requirement of
2.4 is to have double the swap space".  If everyone agrees that's a problem, then
yes, we can go into specifics of what is causing or contributing to the problem.
It's getting past the attitude of some people that 2xMem for swap is somehow
'normal and acceptable -- deal with it".  In my case, seems like 10Mb of swap would
be all that would generally be used (I don't think I've ever seen swap usage over 7Mb)
on a 512M system.  To be told "oh, your wrong, you *should* have 1Gig or you are
operating in an 'unsupported' or non-standard configuration".  I find that very
user-unfriendly.


>
> The swapoff case comes down to dead swap pages in the swap cache.
> Which greatly increases the number of swap pages slows the system
> down, but since these pages are trivial to free we don't generate any
> I/O so don't wait for I/O and thus never enter the scheduler.  Making
> nothing else in the system runnable.

---
I haven't ever *noticed* this on my machine but that could be
because there isn't much in swap to begin with?  Could be I was
just blissfully ignorant of the time it took to do a swapoff.
Hmmmlet's see...  Just tried it.  I didn't get a total lock up,
but cursor movement was definitely jerky:
> time sudo swapoff -a

real0m10.577s
user0m0.000s
sys 0m9.430s

Looking at vmstat, the needed space was taken mostly out of the
page cache (86M->81.8M) and about 700K each out of free and buff.


> Your case is significantly different.  I don't know if you are seeing
> any issues with swapping at all.  With a 5M usage it may simply be
> totally unused pages being pushed out to the swap space.

---
Probably -- I guess the page cache and disk buffers put enough pressure to
push some things off to swap.

-linda
--
The above thoughts and   | They may have nothing to do with
writings are my own. | the opinions of my employer. :-)
L A Walsh| Senior MTS, Trust Tech, Core Linux, SGI
[EMAIL PROTECTED]  | Voice: (650) 933-5338


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: Break 2.4 VM in five easy steps

[Shane Nay]

Uh, last I checked on my linux based embedded device I didn't want to swap to 
flash.  Hmm.., now why was that..., oh, that's right, it's *much* more 
expensive than memory, oh yes, and it actually gets FRIED when you write to a 
block more than 100k times.  Oh, what was that other thing..., oh yes, and 
its SOLDERED ON THE BOARD.  Damn..., guess I just lost a grand or so.

Seriously folks, Linux isn't just for big webservers...

Thanks,
Shane Nay.
(Oh, BTW, I really appreciate the work that people have done on the VM, but 
folks that are just talking..., well, think clearly before you impact other 
people that are writing code.)

On Wednesday 06 June 2001 02:57, Dr S.M. Huen wrote:
> On Wed, 6 Jun 2001, Sean Hunter wrote:
> > For large memory boxes, this is ridiculous.  Should I have 8GB of swap?
>
> Do I understand you correctly?
> ECC grade SDRAM for your 8GB server costs £335 per GB as 512MB sticks even
> at today's silly prices (Crucial). Ultra160 SCSI costs £8.93/GB as 73GB
> drives.
>
> It will cost you 19x as much to put the RAM in as to put the
> developer's recommended amount of swap space to back up that RAM.  The
> developers gave their reasons for this design some time ago and if the
> ONLY problem was that it required you to allocate more swap, why should
> it be a priority item to fix it for those that refuse to do so?   By all
> means fix it urgently where it doesn't work when used as advised but
> demanding priority to fixing a problem encountered when a user refuses to
> use it in the manner specified seems very unreasonable.  If you can afford
> 4GB RAM, you certainly can afford 8GB swap.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: Break 2.4 VM in five easy steps

[Shane Nay]

On Thursday 07 June 2001 13:00, Marcelo Tosatti wrote:
> On Thu, 7 Jun 2001, Shane Nay wrote:
> > (Oh, BTW, I really appreciate the work that people have done on the VM,
> > but folks that are just talking..., well, think clearly before you impact
> > other people that are writing code.)
>
> If all the people talking were reporting results we would be really happy.
>
> Seriously, we really lack VM reports.

Okay, I've had some problems with the VM on my machine, what is the most 
usefull way to compile reports for you?  I have modified the kernel for a few 
different ports fixing bugs, and device drivers, etc., but the VM is all 
greek to me, I can just see that caching is hyper aggressive and doesn't look 
like it's going back to the pool..., which results in sluggish performance.  
Now I know from the work that I've done that anecdotal information is almost 
never even remotely usefull.  Therefore is there any body of information that 
I can read up on to create a usefull set of data points for you or other VM 
hackers to look at?  (Or maybe some report in the past that you thought was 
especially usefull?)

Thank You,
Shane Nay.
(I have in the past had many problems with the VM on embedded machines as 
well, but I'm not actively working on any right this second..., though my 
Psion is sitting next to me begging for me to run some VM tests on it :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: BUG: race-cond with partition-check and ll_rw_blk (all platforms, 2.4.*!)

[Andries . Brouwer]

From: [EMAIL PROTECTED]

We just had a problem when running some formatting-utils on
a large amount of disks synchronously: We got a NULL-pointer
violation when accessig blk_size[major] for our major number.
Further research showed, that grok_partitions was running at
that time, which has been called by register_disk, which our
device driver issues after a disk has been formatted.
Grok_partitions first initializes blk_size[major] with a NULL
pointer, detects the partitions and then assigns the original
value to blk_size[major] again.
Here's the interresting code from these functions, I cut some
irrelevant things out:
From grok_paritions:
 blk_size[dev->major] = NULL;
 check_partition(dev, MKDEV(dev->major, first_minor), 1 + first_minor);
 if (dev->sizes != NULL) {
  blk_size[dev->major] = dev->sizes;
 };
From generic_make_request:
 if (blk_size[major]) {
   if (blk_size[major][MINOR(bh->b_rdev)]) {

Can anyone explain to me, why grok_partitions has to clear
this pointer?

Well, among the irrelevant details you left out is the fact that
it is not
blk_size[dev->major] = NULL;
but
if(!dev->sizes)
blk_size[dev->major] = NULL;
...
if (dev->sizes)
blk_size[dev->major] = dev->sizes;

So, the idea is that either this major has an array with sizes,
and then one can find it in blk_size[dev->major], or it hasn't.
You seem to have a situation where dev->sizes is NULL but
blk_size[dev->major] is not? What device is this?

Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: Background scanning change on 2.4.6-pre1

[Linus Torvalds]

On Thu, 7 Jun 2001, Marcelo Tosatti wrote:
> 
> Who did this change to refill_inactive_scan() in 2.4.6-pre1 ? 

I think it was Andreas Dilger..

> /*
>  * When we are background aging, we try to increase the page aging
>  * information in the system.
>  */
> if (!target)
> maxscan = nr_active_pages >> 4;
> 
> This is going to make all pages have age 0 on an idle system after some
> time (the old code from Rik which has been replaced by this code tried to 
> avoid that)

He posted a nice explanation of how this change made behaviour noticeably
smoother, and how you could actually see the nicer balance between the
active and inactive lists using osview.

The code is not necessarily "correct", but this patch was accompanied by
useful real-life user information.

Now, I think the problem with the old code was that it didn't do _any_
background page aging if "inactive" was large enough. And that really
doesn't make all that much sense. Background page aging is needed to
"sort" the active list, regardless of how many inactive pages there are.

The decision to not do page aging should not be based on the number of
inactive pages, and I think the patch is correct in that sense.

Now, if you were to change the code to something like

/* background scanning? */
if (!target) {
if (atomic_read(page_aging) <= 0)
return 0;
maxscan = nr_active_pages >> 4;
}

and make the "page_aging" be something that goes up when we age stuff up
and goes down when we age it down, and does the proper balancing, THAT
would probably be ok. Then the decision to not age in the background would
be based on whether we have lots of pages getting aged up or not.

Heuristics should make sense, not be "random".

Linus

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

Re: temperature standard - global config option?

[Albert D. Cahalan]

L. K. writes:

> Why not make it in Celsius ? Is more easy to read it this way.

No, because then the software must handle negative numbers for
cooled computers. CentiKelvin is fine. Do C=cK/100-273.15 if you
really must... but you still have a number that is useless to
a human. Humans need a seconds-to-destruction value or an alarm.

Negative temperatures do not really exist.





-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: Background scanning change on 2.4.6-pre1

[Andreas Dilger]

Marcello writes:
> Who did this change to refill_inactive_scan() in 2.4.6-pre1 ? 
> 
> /*
>  * When we are background aging, we try to increase the page aging
>  * information in the system.
>  */
> if (!target)
> maxscan = nr_active_pages >> 4;

A quick check in the l-k archives shows this was Zlatko Calusic
<[EMAIL PROTECTED]> who submitted the patch.  See

http://marc.theaimsgroup.com/?l=linux-kernel=99151955000988=4

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: Break 2.4 VM in five easy steps

[Marcelo Tosatti]

On Thu, 7 Jun 2001, Shane Nay wrote:

> (Oh, BTW, I really appreciate the work that people have done on the VM, but 
> folks that are just talking..., well, think clearly before you impact other 
> people that are writing code.)

If all the people talking were reporting results we would be really happy. 

Seriously, we really lack VM reports.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: Background scanning change on 2.4.6-pre1

[Jonathan Morton]

>> > This is going to make all pages have age 0 on an idle system after some
>> > time (the old code from Rik which has been replaced by this code tried to
>> > avoid that)
>
>There's another reason why I think the patch may be ok even without any
>added logic: not only does it simplify the code and remove a illogical
>heuristic, but there is nothing that really says that "age 0" is
>necessarily very bad.

Here's my take on it.  The point of ageing is twofold - to age down pages
that aren't in use, and to age up pages that *are* in use.  So, pages that
are in use will remain with high ages even when background scanning is
being done, and pages that aren't in use will decay to zero age.

I can't see what's wrong with that.  When we need more memory, it's a Very
Good Thing to know that most of the pages in the system haven't been
accessed in yonks - we know exactly which ones we want to throw out first.

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

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

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+(*)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: VM suggestion...

[Marcelo Tosatti]

On Thu, 7 Jun 2001, Jeff Garzik wrote:

> While you guys are in there hacking, perhaps consider adding metrics
> which allows you to tell exactly when certain cases and conditions are
> hit.
>   page_aged_while_sleeping_in_page_lauder++
> 
> Statistics like this are cheap to use in runtime and should provide
> concrete information rather than guesses and estimations...

I've been using LTT (Linux Trace Toolkit) to do similar stuff. 

The problem is that we _cannot_ base ourselves simply on practical results
from a _limited_ amount of workloads. Also remember the tests we (at least
I do) are benchmarks which try to use all resources all the time upon
completion.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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/

VM suggestion...

[Jeff Garzik]

While you guys are in there hacking, perhaps consider adding metrics
which allows you to tell exactly when certain cases and conditions are
hit.
page_aged_while_sleeping_in_page_lauder++

Statistics like this are cheap to use in runtime and should provide
concrete information rather than guesses and estimations...

-- 
Jeff Garzik  | Andre the Giant has a posse.
Building 1024|
MandrakeSoft |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: Background scanning change on 2.4.6-pre1

[Linus Torvalds]

Forgot one comment..

> > This is going to make all pages have age 0 on an idle system after some
> > time (the old code from Rik which has been replaced by this code tried to 
> > avoid that)

There's another reason why I think the patch may be ok even without any
added logic: not only does it simplify the code and remove a illogical
heuristic, but there is nothing that really says that "age 0" is
necessarily very bad.

We should strive to keep the active/inactive lists in LRU order anyway, so
the ordering does tell you something about how recent (and thus how
important) the page is. Also, it's certainly MUCH preferable to let pages
age down to zero, than to let pages retain a maximum age over a long time,
like the old code used to do.

If, after long periods of inactivity, we start needing fresh pages again,
it's probably actually an _advantage_ to give the new pages a higher
relative importance. Caches tend to lose their usefulness over time, and
if the old cached pages are really relevant, then the new spurt of usage
will obviously mark them young again.

And if, after the idle time, the behaviour is different, the old pages
have appropriately been aged down and won't stand in the way of a new
cache footprint.

Do you actually have regular usage that shows the age-down to be a bad
thing? 

Linus

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

Re: Background scanning change on 2.4.6-pre1

[Marcelo Tosatti]

On Thu, 7 Jun 2001, Linus Torvalds wrote:

> 
> Forgot one comment..
> 
> > > This is going to make all pages have age 0 on an idle system after some
> > > time (the old code from Rik which has been replaced by this code tried to 
> > > avoid that)
> 
> There's another reason why I think the patch may be ok even without any
> added logic: not only does it simplify the code and remove a illogical
> heuristic, but there is nothing that really says that "age 0" is
> necessarily very bad.
> 
> We should strive to keep the active/inactive lists in LRU order anyway, so
> the ordering does tell you something about how recent (and thus how
> important) the page is. Also, it's certainly MUCH preferable to let pages
> age down to zero, than to let pages retain a maximum age over a long time,
> like the old code used to do.
> 
> If, after long periods of inactivity, we start needing fresh pages again,
> it's probably actually an _advantage_ to give the new pages a higher
> relative importance. Caches tend to lose their usefulness over time, and
> if the old cached pages are really relevant, then the new spurt of usage
> will obviously mark them young again.
> 
> And if, after the idle time, the behaviour is different, the old pages
> have appropriately been aged down and won't stand in the way of a new
> cache footprint.
> 
> Do you actually have regular usage that shows the age-down to be a bad
> thing? 

Fill the active list of cache and wait for a while to get the inactive
list full.

When that happens and pressure begins, refill_inactive_scan() from
try_to_free_pages() will not be called because the inactive list is full
(the kernel "thinks" we dont have an inactive shortage). Well, not sure if
this is a bad thing in the end. 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: temperature standard - global config option?

[L. K.]

On Thu, 7 Jun 2001, Albert D. Cahalan wrote:

> Negative temperatures do not really exist.
> 

Are you really sure about this ?



> 
> 
> 
> 
> 

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

Re: VM suggestion...

[Stuart MacDonald]

From: "Marcelo Tosatti" <[EMAIL PROTECTED]>
> The problem is that we _cannot_ base ourselves simply on practical results
> from a _limited_ amount of workloads. Also remember the tests we (at least
> I do) are benchmarks which try to use all resources all the time upon
> completion.

Isn't this the point of the X.odd.Y kernels? Spit the stats out into the
syslog, along with a message of "If you see these, please mail them
along to [EMAIL PROTECTED] and a description of your workload
if it's not too much trouble."

..Stu


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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/

PTRACE_ATTACH breaks wait4()

[Pavel Kankovsky]

Let A be a process and B its child. When another process, let's call
it C, does ptrace(PTRACE_ATTACH) on B, wait4(pid of B, ...) will always
return ECHILD when invoked from A after B has been attached to C because
wait4() does not take children traced by other processes into account.
The problem was observed on 2.2.19. I suppose it exists in 2.4 as well.

Apparently, I am not the first person who encountered this problem. See


--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: Please test: workaround to help swapoff behaviour

[Bulent Abali]

>This is for the people who has been experiencing the lockups while running
>swapoff.
>
>Please test. (against 2.4.6-pre1)
>
>
>--- linux.orig/mm/swapfile.c Wed Jun  6 18:16:45 2001
>+++ linux/mm/swapfile.c Thu Jun  7 16:06:11 2001
>@@ -345,6 +345,8 @@
> /*
>  * Find a swap page in use and read it in.
>  */
>+if (current->need_resched)
>+ schedule();
> swap_device_lock(si);
> for (i = 1; i < si->max ; i++) {
>  if (si->swap_map[i] > 0 && si->swap_map[i] != SWAP_MAP_BAD)
{


I tested your patch against 2.4.5.  It works.  No more lockups.  Without
the
patch it took 14 minutes 51 seconds to complete swapoff (this is to recover
1.5GB of
swap space).  During this time the system was frozen.  No keyboard, no
screen, etc. Practically locked-up.

With the patch there are no more lockups. Swapoff kept running in the
background.
This is a winner.

But here is the caveat: swapoff keeps burning 100% of the cycles until it
completes.
This is not going to be a big deal during shutdowns.  Only when you enter
swapoff from
the command line it is going to be a problem.

I looked at try_to_unuse in swapfile.c.  I believe that the algorithm is
broken.
For each and every swap entry it is walking the entire process list
(for_each_task(p)).  It is also grabbing a whole bunch of locks
for each swap entry.  It might be worthwhile processing swap entries in
batches instead of one entry at a time.

In any case, I think having this patch is worthwhile as a quick and dirty
remedy.

Bulent Abali



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: xircom_cb problems

[Ion Badulescu]

On Thu, 7 Jun 2001, Tom Sightler wrote:

> Transferring files between the eepro100 machine running 2.4.2-ac11 and my 
> laptop produced a result of 2.24MB/s for sending and 2.13MB/s recieving the 
> file.
> 
> Transfering files between the Alteon Gigabit machine running 2.2.19 and my 
> laptop resulted in the dismal numbers of 249KB/s sending and 185KB/s recieving, 
> close to the numbers you quoted above, but actually slightly worse.
> 
> I'm not sure what would explain the 2.2.19 1GB conencted box being 10x slower 
> than the 2.4.2-ac11 100MB machine.

Both of these are slow, actually. I'm getting 7.5-8MB/s when receiving 
from a 100Mbit box (tulip or starfire, doesn't seem to matter). 
Transmitting is still slow for me, but that is most likely a different 
problem -- and I'm looking into it.

Moreover, I'm getting 9+MB/s in both directions when using the other 
driver (xircom_tulip_cb), patched to do half-duplex only. So the card can 
definitely transfer at network speeds.

> I'll apply your patch with the change to MII handling and rerun some simple 
> file transfers and report the results soon.

Looking forward to seeing them...

Thanks,
Ion

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

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

Background scanning change on 2.4.6-pre1

[Marcelo Tosatti]

Hi Linus, 


Who did this change to refill_inactive_scan() in 2.4.6-pre1 ? 

/*
 * When we are background aging, we try to increase the page aging
 * information in the system.
 */
if (!target)
maxscan = nr_active_pages >> 4;

This is going to make all pages have age 0 on an idle system after some
time (the old code from Rik which has been replaced by this code tried to 
avoid that)

Could you please explain me the reasoning behind this change ?  

Thanks 

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

PATCH: via audio 1.1.15-pre1

[Jeff Garzik]

Attached is a patch against kernel 2.4.6-pre1 which includes fixes for
via audio.  It -should- patch against kernel 2.4.3 or later, though.

I'm interested in feedback from people having via audio problems, if
this patch fixes them.  I am of course also interested in general
testing, to ensure I did not break anything in the process of fixing
things.  :)

-- 
Jeff Garzik  | Andre the Giant has a posse.
Building 1024|
MandrakeSoft |

Index: linux_2_4/drivers/sound/via82cxxx_audio.c
diff -u linux_2_4/drivers/sound/via82cxxx_audio.c:1.1.1.19 
linux_2_4/drivers/sound/via82cxxx_audio.c:1.1.1.19.2.2
--- linux_2_4/drivers/sound/via82cxxx_audio.c:1.1.1.19  Mon Jun  4 19:43:41 2001
+++ linux_2_4/drivers/sound/via82cxxx_audio.c   Thu Jun  7 13:04:28 2001
@@ -15,7 +15,7 @@
  */
 
 
-#define VIA_VERSION"1.1.14b"
+#define VIA_VERSION"1.1.15-pre1"
 
 
 #include 
@@ -92,6 +92,7 @@
 #endif
 
 /* 82C686 function 5 (audio codec) PCI configuration registers */
+#define VIA_ACLINK_STATUS  0x40
 #define VIA_ACLINK_CTRL0x41
 #define VIA_FUNC_ENABLE0x42
 #define VIA_PNP_CONTROL0x43
@@ -187,6 +188,7 @@
 /* controller base 0 register bitmasks */
 #define VIA_INT_DISABLE_MASK   (~(0x01|0x02))
 #define VIA_SGD_STOPPED(1 << 2)
+#define VIA_SGD_PAUSED (1 << 6)
 #define VIA_SGD_ACTIVE (1 << 7)
 #define VIA_SGD_TERMINATE  (1 << 6)
 #define VIA_SGD_FLAG   (1 << 0)
@@ -381,7 +383,7 @@
  *
  */
 
-static inline void via_chan_stop (int iobase)
+static inline void via_chan_stop (long iobase)
 {
if (inb (iobase + VIA_PCM_STATUS) & VIA_SGD_ACTIVE)
outb (VIA_SGD_TERMINATE, iobase + VIA_PCM_CONTROL);
@@ -402,7 +404,7 @@
  *
  */
 
-static inline void via_chan_status_clear (int iobase)
+static inline void via_chan_status_clear (long iobase)
 {
u8 tmp = inb (iobase + VIA_PCM_STATUS);
 
@@ -425,6 +427,19 @@
 }
 
 
+static int sg_active (long iobase)
+{
+   u8 tmp = inb (iobase + VIA_PCM_STATUS);
+   if ((tmp & VIA_SGD_STOPPED) || (tmp & VIA_SGD_PAUSED)) {
+   printk(KERN_WARNING "via82cxxx warning: SG stopped or paused\n");
+   return 0;
+   }
+   if (tmp & VIA_SGD_ACTIVE)
+   return 1;
+   return 0;
+}
+
+
 /
  *
  * Miscellaneous debris
@@ -467,6 +482,8 @@
 
 static void via_stop_everything (struct via_info *card)
 {
+   u8 tmp, new_tmp;
+   
DPRINTK ("ENTER\n");
 
assert (card != NULL);
@@ -486,11 +503,32 @@
via_chan_status_clear (card->baseaddr + VIA_BASE0_FM_OUT_CHAN);
 
/*
-* clear any enabled interrupt bits, reset to 8-bit mono PCM mode
+* clear any enabled interrupt bits
 */
-   outb (0, card->baseaddr + VIA_BASE0_PCM_OUT_CHAN_TYPE);
-   outb (0, card->baseaddr + VIA_BASE0_PCM_IN_CHAN_TYPE);
-   outb (0, card->baseaddr + VIA_BASE0_FM_OUT_CHAN_TYPE);
+   tmp = inb (card->baseaddr + VIA_BASE0_PCM_OUT_CHAN_TYPE);
+   new_tmp = tmp & ~(VIA_IRQ_ON_FLAG|VIA_IRQ_ON_EOL|VIA_RESTART_SGD_ON_EOL);
+   if (tmp != new_tmp)
+   outb (0, card->baseaddr + VIA_BASE0_PCM_OUT_CHAN_TYPE);
+
+   tmp = inb (card->baseaddr + VIA_BASE0_PCM_IN_CHAN_TYPE);
+   new_tmp = tmp & ~(VIA_IRQ_ON_FLAG|VIA_IRQ_ON_EOL|VIA_RESTART_SGD_ON_EOL);
+   if (tmp != new_tmp)
+   outb (0, card->baseaddr + VIA_BASE0_PCM_IN_CHAN_TYPE);
+
+   tmp = inb (card->baseaddr + VIA_BASE0_FM_OUT_CHAN_TYPE);
+   new_tmp = tmp & ~(VIA_IRQ_ON_FLAG|VIA_IRQ_ON_EOL|VIA_RESTART_SGD_ON_EOL);
+   if (tmp != new_tmp)
+   outb (0, card->baseaddr + VIA_BASE0_FM_OUT_CHAN_TYPE);
+
+   udelay(10);
+   
+   /*
+* clear any existing flags
+*/
+   via_chan_status_clear (card->baseaddr + VIA_BASE0_PCM_OUT_CHAN);
+   via_chan_status_clear (card->baseaddr + VIA_BASE0_PCM_IN_CHAN);
+   via_chan_status_clear (card->baseaddr + VIA_BASE0_FM_OUT_CHAN);
+
DPRINTK ("EXIT\n");
 }
 
@@ -515,6 +553,8 @@
 
DPRINTK ("ENTER, rate = %d\n", rate);
 
+   if (chan->rate == rate)
+   goto out;
if (card->locked_rate) {
chan->rate = 48000;
goto out;
@@ -762,17 +802,17 @@
 {
DPRINTK ("ENTER\n");
 
-   synchronize_irq();
-
spin_lock_irq (>lock);
 
/* stop any existing channel output */
+   via_chan_status_clear (chan->iobase);
via_chan_stop (chan->iobase);
via_chan_status_clear (chan->iobase);
-   via_chan_pcm_fmt (chan, 1);
 
spin_unlock_irq (>lock);
 
+   synchronize_irq();
+
DPRINTK ("EXIT\n");
 }
 
@@ -840,7 +880,7 @@
/* if we are recording, enable recording fifo bit */
if (chan->is_record)
chan->pcm_fmt |= VIA_PCM_REC_FIFO;
-   /* set interrupt select bits where 

Re: scsi disk defect or kernel driver defect ?

[Nico Schottelius]

Khalid Aziz wrote:

> Nico Schottelius wrote:
> >
> > Hi all!
> >
> > The problem is solved, if I disconnect the hp streamer
> > from the bus. I wonder why there is a problem.
> > The aic7880 has two busses:
> >
> > ultra/ ultrawide.
> >
> > The ibm hard disk is connected to the uw port and is terminated.
> > No other uw device is attached.
> >
> > The hp streamer is also lonely on the ultra bus. I have
> > no documentation for that device, so I don't know
> > whether it is terminated nor if it is using parity.
> >
> > Btw, can somebody explain what the parity bit does to me ?
> >
> > Or does anybody have a hp c1536 streamer and can help me ?
>
> Based upon the lspci output you posted earlier, aic7880 has a single
> SCSI bus.

Oh. That could really be a problem.. I though having two different
connectors on the board would make two different buses..
I must have been wrong.

> So you must mean two internal connectors. Both of your devices
> (HD and Tape) do show up on the same bus during scan. Since you have
> connected devices to both connectors on the card, you must terminate
> both devices.

Okay, so far I understood.

> Sounds like you HD might be terminated.

It is.

> You need to terminate tape drive as well.

It seems like it is impossible:

> I do not have a C1536 handy,

the problem is I do have :)

> but if you look at the back of the drive you should see 10 pins aligned
> horizontally.

No. And that's the real problem.
I can see the following:

2 - 1 -0 for the id (every one with two pins), NC (one pin).
Under the device is a small claviar.
I mean a small think, a bank with small switches on it.

reading from left to right:
1 - 2 -3 -  4 -5 -6 -7 -8.
If the switch is up, it is on.

--
| o  |   on
| |
--

--
|  |   off.
| o  |
--

I hope you understand what I mean to say with thoses ascii figures.

Does anybody know what to do with these
switches ?

Nico

ps: oh, you are from hp, that's the reason why you know so much about this
device ;)


> They should all be labelled on the back panel and most
> likely are (from left to right) - TP, 2, 1, 0, NC. TP is the pair of
> Term Power Enable pins. Place a jumper over the leftmost two pins to
> enable termination on the drive and try again.
>
> --
> Khalid
>
> 
> Khalid Aziz Linux Development Laboratory
> (970)898-9214Hewlett-Packard
> [EMAIL PROTECTED]Fort Collins, CO
>
> Disclaimer: I do not speak for HP. These are my personal opinions.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: scsi disk defect or kernel driver defect ?

[Khalid Aziz]

Nico Schottelius wrote:
> 
> Hi all!
> 
> The problem is solved, if I disconnect the hp streamer
> from the bus. I wonder why there is a problem.
> The aic7880 has two busses:
> 
> ultra/ ultrawide.
> 
> The ibm hard disk is connected to the uw port and is terminated.
> No other uw device is attached.
> 
> The hp streamer is also lonely on the ultra bus. I have
> no documentation for that device, so I don't know
> whether it is terminated nor if it is using parity.
> 
> Btw, can somebody explain what the parity bit does to me ?
> 
> Or does anybody have a hp c1536 streamer and can help me ?

Based upon the lspci output you posted earlier, aic7880 has a single
SCSI bus. So you must mean two internal connectors. Both of your devices
(HD and Tape) do show up on the same bus during scan. Since you have
connected devices to both connectors on the card, you must terminate
both devices. Sounds like you HD might be terminated. You need to
terminate tape drive as well. I do not have a C1536 handy, but if you
look at the back of the drive you should see 10 pins aligned
horizontally. They should all be labelled on the back panel and most
likely are (from left to right) - TP, 2, 1, 0, NC. TP is the pair of
Term Power Enable pins. Place a jumper over the leftmost two pins to
enable termination on the drive and try again.

-- 
Khalid


Khalid Aziz Linux Development Laboratory
(970)898-9214Hewlett-Packard
[EMAIL PROTECTED]Fort Collins, CO

Disclaimer: I do not speak for HP. These are my personal opinions.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: pset patch??

[Mark Hounschell]

Tim Hockin wrote:
> 
> Khalid Aziz wrote:
> >
> > Try
> > .
> > It may do what you want.
> 
> > > I see references to this site http://isunix.it.ilstu.edu/~thockin/pset/.
> 
> try http://www.hockin.org/~thockin/pset
> 
> unfortunately, not ported to 2.4.x yet - should be easy, and is a more
> complete implementation of sysmp() than the others..
> 
> --
Thank you Tim. I beleive that was what I was looking for.

Regards
mark
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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.6 pre1 and 2.4.5 CONFIG_IP_NF_COMPAT_IPCHAINS missing?

[D. Stimits]

"D. Stimits" wrote:
> 
> I know somewhere there is a menuconfig item corresponding to
> CONFIG_IP_NF_COMPAT_IPCHAINS, and that selecting various other iptables
> options can make this item disappear and no longer be selectable. But I
> have fished all over, have set config to give devel and incomplete
> items, tried turning on or off anything possibly related to iptables,
> and cannot find this item in the make menuconfig. It still exists in
> Documentation/Configure.help, so I assume this has not yet been removed
> from available kernel compile options. I've been searching for the means
> to interactively select this item, with no luck. Can anyone tell me if
> ipchains compatibility has been removed from current config options? If
> not, how it can be selected, or if it is broken?
> 
> D. Stimits, [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/


Nevermind, I found the item in question. Turns out that the option is
added to the config menu, but not under the item that activated the
option...most of the way down the menu instead, so I didn't see it.

D. Stimits, [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: scsi disk defect or kernel driver defect ?

[Nico Schottelius]

Hi all!

The problem is solved, if I disconnect the hp streamer
from the bus. I wonder why there is a problem.
The aic7880 has two busses:

ultra/ ultrawide.

The ibm hard disk is connected to the uw port and is terminated.
No other uw device is attached.

The hp streamer is also lonely on the ultra bus. I have
no documentation for that device, so I don't know
whether it is terminated nor if it is using parity.

Btw, can somebody explain what the parity bit does to me ?

Or does anybody have a hp c1536 streamer and can help me ?


Regards,

Nico

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

Re: [PATCH] Reap dead swap cache earlier v2

[Jonathan Morton]

>> >As suggested by Linus, I've cleaned the reapswap code to be contained
>> >inside an inline function. (yes, the if statement is really ugly)
>>
>> I can't seem to find the patch which adds this behaviour to the background
>> scanning.
>
>I've just sent Linus a patch to free swap cache pages at the time we free
>the last pte. (requested by himself)
>
>With it applied we should get the old behaviour back again.
>
>I can put it on my webpage if you wish.

Just copy it to me so I can replace the dead-swap hacks you introduced earlier.

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

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

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+(*)


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

Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregistertable

[Matthias Urlichs]

Ahem...

David S. Miller wrote:
>This allows people to make proprietary implementations of TCP under
>Linux.  And we don't want this just as we don't want to add a way to
>allow someone to do a proprietary Linux VM.

*Sigh* and thence begin the proprietary-vs-OpenSource flame wars again.

_Any_ open protocol can be abused for proprietary stuff. It can also 
be used for Something Entirely Different.

Personally, I would _love_ to have TCP as a module, just so that the 
system can unload it on my poor underpowered laptop when it's not 
needed.

The fact that you can abuse this ability in order to replace the 
current TCP with Something Proprietary And Therefore Evil is a 
no-brainer. Anybody can do exactly the same thing with my network 
card driver, or the Unix-domain code, or the NFS server, or ...

So what's so damn special about the TCP stack that you need to shout 
"Absolutely not" here? I don't get it.

-- 
Matthias Urlichs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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/

Please test: workaround to help swapoff behaviour

[Marcelo Tosatti]

On Thu, 7 Jun 2001, Marcelo Tosatti wrote:

> 
> On Thu, 7 Jun 2001, Mike Galbraith wrote:
> 
> > On 6 Jun 2001, Eric W. Biederman wrote:
> > 
> > > Mike Galbraith <[EMAIL PROTECTED]> writes:
> > >
> > > > > If you could confirm this by calling swapoff sometime other than at
> > > > > reboot time.  That might help.  Say by running top on the console.
> > > >
> > > > The thing goes comatose here too. SCHED_RR vmstat doesn't run, console
> > > > switch is nogo...
> > > >
> > > > After running his memory hog, swapoff took 18 seconds.  I hacked a
> > > > bleeder valve for dead swap pages, and it dropped to 4 seconds.. still
> > > > utterly comatose for those 4 seconds though.
> > >
> > > At the top of the while(1) loop in try_to_unuse what happens if you put in.
> > > if (need_resched) schedule();
> > > It should be outside all of the locks.  It might just be a matter of everything
> > > serializing on the SMP locks, and the kernel refusing to preempt itself.
> > 
> > That did it.
> 
> What about including this workaround in the kernel ? 

Well, 

This is for the people who has been experiencing the lockups while running
swapoff.

Please test. (against 2.4.6-pre1)

Thanks for the suggestion, Eric. 


--- linux.orig/mm/swapfile.cWed Jun  6 18:16:45 2001
+++ linux/mm/swapfile.c Thu Jun  7 16:06:11 2001
@@ -345,6 +345,8 @@
/*
 * Find a swap page in use and read it in.
 */
+   if (current->need_resched)
+   schedule();
swap_device_lock(si);
for (i = 1; i < si->max ; i++) {
if (si->swap_map[i] > 0 && si->swap_map[i] != SWAP_MAP_BAD) {

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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.6 pre1 and 2.4.5 CONFIG_IP_NF_COMPAT_IPCHAINS missing?

[D. Stimits]

I know somewhere there is a menuconfig item corresponding to
CONFIG_IP_NF_COMPAT_IPCHAINS, and that selecting various other iptables
options can make this item disappear and no longer be selectable. But I
have fished all over, have set config to give devel and incomplete
items, tried turning on or off anything possibly related to iptables,
and cannot find this item in the make menuconfig. It still exists in
Documentation/Configure.help, so I assume this has not yet been removed
from available kernel compile options. I've been searching for the means
to interactively select this item, with no luck. Can anyone tell me if
ipchains compatibility has been removed from current config options? If
not, how it can be selected, or if it is broken?

D. Stimits, [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: [PATCH] Reap dead swap cache earlier v2

[Marcelo Tosatti]

On Thu, 7 Jun 2001, Jonathan Morton wrote:

> >As suggested by Linus, I've cleaned the reapswap code to be contained
> >inside an inline function. (yes, the if statement is really ugly)
> 
> I can't seem to find the patch which adds this behaviour to the background
> scanning.  

I've just sent Linus a patch to free swap cache pages at the time we free
the last pte. (requested by himself)

With it applied we should get the old behaviour back again. 

I can put it on my webpage if you wish. 

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

Re: [PATCH] Reap dead swap cache earlier v2

[Jonathan Morton]

>As suggested by Linus, I've cleaned the reapswap code to be contained
>inside an inline function. (yes, the if statement is really ugly)

I can't seem to find the patch which adds this behaviour to the background
scanning.  Can someone point me to it?

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

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

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+(*)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: Break 2.4 VM in five easy steps

[Miles Lane]

On 07 Jun 2001 11:49:47 -0400, Derek Glidden wrote:
> Miles Lane wrote:
> > 
> > So please, if you have new facts that you want to offer that
> > will help us characterize and understand these VM issues better
> > or discover new problems, feel free to share them.  But if you
> > just want to rant, I, for one, would rather you didn't.
> 
> *sigh*
> 
> Not to prolong an already pointless thread, but that really was the
> intent of my original message.  I had figured out a specific way, with
> easy-to-follow steps, to make the VM misbehave under very certain
> conditions.  I even offered to help figure out a solution in any way I
> could, considering I'm not familiar with kernel code.
> 
> However, I guess this whole "too much swap" issue has a lot of people on
> edge and immediately assumed I was talking about this subject, without
> actually reading my original message.

Actually, I think your original message was useful.  It has
spurred a reevaluation of some design assumptions implicit in the VM
in the 2.4 series and has also surfaced some bugs.  It was not you
who I felt was sending enflammatory remarks, it was the folks who
have been bellyaching about the current swap disk space requirements
without offering any new information to help developers remedy
the situation.

So, thanks for bringing the topic up.  :-)

Cheers,
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://www.tux.org/lkml/

Busy buffers and try_to_free_pages

[Steve Lord]

I am chasing around in circles with an issue where buffers pointing at
highmem pages are getting put onto the buffer free list, and later on
causing oops in ext2 when it gets assigned them for metadata via getblk.

Say one thread is performing a truncate on an inode and is currently in
truncate_inode_pages walking the pages and removing them from the
address space of the inode. If the try_to_free_buffers call fails to remove
the buffers from the page because the buffer_busy test fails, then
the buffers become anonymous and we disconnet the page from the address
space anyway. During unmount, these anonymous buffers get put on the free
list. A simple sync call running in parallel with the truncate can cause
the buffer to be seen as busy and get the system into this state.

What is supposed to prevent this from happening? It seems that pages
allocated from highmem should never be allowed to be cleaned up this
way.

Steve


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: Break 2.4 VM in five easy steps

[Marcelo Tosatti]

On Thu, 7 Jun 2001, Mike Galbraith wrote:

> On 6 Jun 2001, Eric W. Biederman wrote:
> 
> > Mike Galbraith <[EMAIL PROTECTED]> writes:
> >
> > > > If you could confirm this by calling swapoff sometime other than at
> > > > reboot time.  That might help.  Say by running top on the console.
> > >
> > > The thing goes comatose here too. SCHED_RR vmstat doesn't run, console
> > > switch is nogo...
> > >
> > > After running his memory hog, swapoff took 18 seconds.  I hacked a
> > > bleeder valve for dead swap pages, and it dropped to 4 seconds.. still
> > > utterly comatose for those 4 seconds though.
> >
> > At the top of the while(1) loop in try_to_unuse what happens if you put in.
> > if (need_resched) schedule();
> > It should be outside all of the locks.  It might just be a matter of everything
> > serializing on the SMP locks, and the kernel refusing to preempt itself.
> 
> That did it.

What about including this workaround in the 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://www.tux.org/lkml/

Re: xircom_cb problems

[Tom Sightler]

Quoting Ion Badulescu <[EMAIL PROTECTED]>:

> > 2.4.4-ac11 -- mostly works fine -- minor problems awaking from sleep
> 
> Can you run some performance testing with this driver, though? The
> speed
> of ftp transfers in both directions would be a good measure. The
> reason
> I'm asking is because we saw really poor performance on 100Mb
> full-duplex,
> something like 200-300KB/s when receiving.

OK, I did some simple FTP benchmarking, transferring a 100MB to and from my 
laptop connected to a Cisco Catalyst 6509.  The other systems were a PIII 
700Mhz UP with eepro100 NIC running 2.4.2-ac11, and a PIII 1Ghz SMP (2 proc) 
with Alteon Gigabit NIC running 2.2.19.

Transferring files between the eepro100 machine running 2.4.2-ac11 and my 
laptop produced a result of 2.24MB/s for sending and 2.13MB/s recieving the 
file.

Transfering files between the Alteon Gigabit machine running 2.2.19 and my 
laptop resulted in the dismal numbers of 249KB/s sending and 185KB/s recieving, 
close to the numbers you quoted above, but actually slightly worse.

I'm not sure what would explain the 2.2.19 1GB conencted box being 10x slower 
than the 2.4.2-ac11 100MB machine.

Transferring the same file between the two other boxes gives 9.81MB/s which is 
near the theoretical maximum for 100Mb.

> > 2.4.5-ac9 -- keeps logging "Link is absent" then "Linux is 100 mbit"
> over and
> > over when trying to pull an IP address via dhcp using pump or dhcpcd.
> 
> 
> pump likes to bring the interface up and down and up and down, so those
> 
> messages are not necessarily unusual.

Yea, I've actually complained of this before, the interface up/down things that 
pump does makes it very tough to use on a large network with full spanning tree 
as pump brings the interface down and up again right about the time spanning 
tree puts the port into forwarding mode.  I can get around this by setting 
Cisco's portfast feature, but doing that on all ports somewhat defeats the 
purpose of spanning tree and I move my laptop a lot.
 
> Hmm. I have an idea though. In set_half_duplex, we shouldn't touch the
> MII 
> if the new autoneg value is the same as the old one. It should certainly
> 
> help with things like pump. Arjan, what do you think?
> 
> > Interestingly manually setting an IP address seems to work fine with
> > this driver.
> 
> That's very good to know. So most likely the repeated up/down that
> pump's 
> doing is upsetting the card.

Commenting out the set_half_duplex made the driver in 2.4.5-ac9 work with DHCP 
again so your probably right.
 
I'll apply your patch with the change to MII handling and rerun some simple 
file transfers and report the results soon.

Thanks,
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://www.tux.org/lkml/

Re: scsi disk defect or kernel driver defect ?

[Khalid Aziz]

Nico Schottelius wrote:
> There is in fact no terminator, the scsi disc should terminate the bus
> itself. It is directly connected to the onboard aix7880 scsi controller.
> I will use another cable in about half an hour (when my friend arrives..)
> 
> Thanks for the hint!
> 
> Nico
> 

I would suggest checking "Term Enable" jumper on the disk just to be
sure. This jumper needs to be on for most (I would think all) drives to
terminate the bus.

--
Khalid
 

Khalid Aziz Linux Development Laboratory
(970)898-9214Hewlett-Packard
[EMAIL PROTECTED]Fort Collins, CO
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: Break 2.4 VM in five easy steps

[José Luis Domingo López]

On Thursday, 07 June 2001, at 09:23:42 +0200,
Helge Hafting wrote:

> Derek Glidden wrote:
> > 
> > Helge Hafting wrote:
> [...]
> The machine froze 10 seconds or so at the end of the minute, I can
> imagine that biting with bigger swap.
> 
Same behavior here with a Pentium III 600, 128 MB RAM and 128 MB of swap.
Filled mem and swap with the infamous glob() "bug" (ls ../*/.. etc.), made
swapoff, and the machine kept very responsive except for the last 10-15
seconds before swapoff ends.

Even scrolling complex pages with Mozilla 0.9 worked smoothly :).

-- 
José Luis Domingo López
Linux Registered User #189436 Debian GNU/Linux Potato (P166 64 MB RAM)
 
jdomingo EN internautas PUNTO org  => ¿ Spam ? Atente a las consecuencias
jdomingo AT internautas DOT   org  => Spam at your own risk

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: scsi disk defect or kernel driver defect ?

[Nico Schottelius]

> >  0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> >  I/O error: dev 08:01, sector 127304
> > SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 802
> > [valid=0] Info fld=0x0, Current sd08:01: sns = 70  b
> > ASC=47 ASCQ= 0
> > Raw sense data:0x70 0x00 0x0b 0x00 0x00 0x00 0x00 0x18 0x00 0x00 0x00 0x00 0x47 
>0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
>0x00 0x00
> >  I/O error: dev 08:01, sector 127312
> > SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 802
> > [valid=0] Info fld=0x0, Current sd08:01: sns = 70  b
> > ASC=47 ASCQ= 0
>
> You are seeing lots of parity errors (ASC=47 ASCQ=0). I would suggest
> checking cabling and terminator.

There is in fact no terminator, the scsi disc should terminate the bus
itself. It is directly connected to the onboard aix7880 scsi controller.
I will use another cable in about half an hour (when my friend arrives..)

Thanks for the hint!

Nico

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: scsi disk defect or kernel driver defect ?

[Nico Schottelius]

Guest section DW wrote:

> On Thu, Jun 07, 2001 at 06:22:59PM +0200, Nico Schottelius wrote:
>
> >  0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> >  I/O error: dev 08:01, sector 127304
> > SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 802
> > [valid=0] Info fld=0x0, Current sd08:01: sns = 70  b
> > ASC=47 ASCQ= 0
> > Raw sense data:0x70 0x00 0x0b 0x00 0x00 0x00 0x00 0x18 0x00 0x00 0x00 0x00 0x47 
>0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
>0x00 0x00
> >  I/O error: dev 08:01, sector 127312
>
> Aborted command: SCSI parity error.

Hmm...what to do against this ?
the 'disable parity' jumper is not set, should I set it ?

Or was this something to adjust in the boot up adaptec
menu ?

Whatever, thanks a lot to here !

Nico

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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/

random failures with megaraid driver on 2.4.4 SMP

[Kelly Martin]

I have an HP Netserver 1000r (dual Pentium 3) with a HP NetRAID-1M card
running Linux 2.4.4 with the megaraid driver included in 2.4.4 that has
twice now experienced kernel panics related to file system damage which
appear to be caused by the megaraid driver going mad and scribbling randomly
on the drive.  We have using this same driver with 2.2.x kernels on other
uniprocessor machines with the same NetRAID card for over a year with no
failures, so it seems likely that this is either a 2.4.x problem or an SMP
problem with this driver.  

This machine is slated to become a production system and I do not have a
similiarly-configured spare machine, so I am not going to pursue this
problem at this time.  This card works fine under 2.2.x so we are going to
use 2.2.19 on this machine for now.  However, doing so makes our second
processor little more than a space heater.  I have not tried using other
versions of the megaraid driver or kernels other than 2.4.4; I simply cannot
spare the time right now.

I am not subscribed to the mailing list; please cc: replies.

Kelly Martin
American Farm Bureau Federation
[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: ftape and kernel 2.4 problem

[Steven Walter]

Here's a patch I wrote to allow ftape to compile against 2.4.something.
It still works with 2.4.5.  I'm not sure if it works entirely (it seems
to), but it compiles and seems to work.  Enjoy!

On Thu, Jun 07, 2001 at 05:12:31PM +0200, Friedrich Lobenstock wrote:
> Hi!
> 
> As the linux-ftape mailing list is gone I'm asking you guys.
> 
> Can someone tell me how to adapt the ftape driver that I can use it
> under kernel 2.4.x (x >= 5)? I'm not that into kernel hacking that
> I know what changed from 2.2.x to 2.4.x. Below is the output of make.
> 
> BTW why wasn't the newer ftape driver ported to 2.4 but the stone age
> ftape driver is still in 2.4?
> 
> PS: Please CC me because I'm not on linux-kernel.
-- 
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
-- George Orwell


diff -ru ftape-4.04a/ftape/lowlevel/ftape-init.h 
ftape-4.04a.mod/ftape/lowlevel/ftape-init.h
--- ftape-4.04a/ftape/lowlevel/ftape-init.h Mon Jul  3 05:13:06 2000
+++ ftape-4.04a.mod/ftape/lowlevel/ftape-init.h Mon Feb  5 18:58:42 2001
@@ -67,7 +67,7 @@
 }
 extern inline int ft_sigtest(unsigned long mask)
 {
-   return (current->signal.sig[0] & mask);
+   return (current->sigpending & mask);
 }
 extern inline int ft_killed(void)
 {
diff -ru ftape-4.04a/include/linux/ftape.h ftape-4.04a.mod/include/linux/ftape.h
--- ftape-4.04a/include/linux/ftape.h   Tue Jul 25 06:04:47 2000
+++ ftape-4.04a.mod/include/linux/ftape.h   Mon Feb  5 18:59:35 2001
@@ -28,7 +28,7 @@
  *  for the QIC-40/80/3010/3020 floppy-tape driver for Linux.
  *
  */
-
+#define __initlocaldata __initdata
 #define FTAPE_VERSION "ftape v4.04a 07/25/2000"
 
 #ifdef __KERNEL__

Re: pset patch??

[Tim Hockin]

Khalid Aziz wrote:
> 
> Try
> .
> It may do what you want.

> > I see references to this site http://isunix.it.ilstu.edu/~thockin/pset/.


try http://www.hockin.org/~thockin/pset

unfortunately, not ported to 2.4.x yet - should be easy, and is a more
complete implementation of sysmp() than the others..

-- 
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[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: NULL characters in file on ReiserFS again.

[Eric W. Biederman]

"Stephen C. Tweedie" <[EMAIL PROTECTED]> writes:

> Hi,
> 
> On Thu, May 31, 2001 at 09:57:51AM -0700, Hans Reiser wrote:
> 
> > > /etc/hosts (or anywhere). As a tesult, startx hung starting X server; it was
> 
> > > not possible to switch to alpha console or kill X server. I pressed reset
> > > and after reboot looked into /var/log/XFree86*log - and there were a bunch
> > > of ^@ there.
> 
> > this is the nature of metadata journaling filesystems.
> 
> Umm, no, it isn't.  Ext3 would never allow that to happen in ordered
> metadata-journaling mode, and Chris Mason is already working to remove
> that window in reiserfs.  It is by no means a necessary consequence of
> doing metadata-only journaling.

Hans seemed to be refering to the fact that fsck.reiser returned
without errors on the partition being looked at.  Which is the nature
of metadata journalling.  The filesystem doesn't get corrupted though
the files might. 

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

Re: 2.4.5-ac9 console NULL pointer pointer dereference

[James Simmons]

> this happend with 2.4.5-ac9 with serial console on i386.
> 
> Full boot log and config can be found here:
> http://www.penguinppc.org/~olaf/bugs/245-ac9/

I can't seem to download those files. It complains they are not gz files.
Could you send me those files. Thanks!

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

Re: scsi disk defect or kernel driver defect ?

[Guest section DW]

On Thu, Jun 07, 2001 at 06:22:59PM +0200, Nico Schottelius wrote:

>  0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
>  I/O error: dev 08:01, sector 127304
> SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 802
> [valid=0] Info fld=0x0, Current sd08:01: sns = 70  b
> ASC=47 ASCQ= 0
> Raw sense data:0x70 0x00 0x0b 0x00 0x00 0x00 0x00 0x18 0x00 0x00 0x00 0x00 0x47 0x00 
>0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
>0x00 
>  I/O error: dev 08:01, sector 127312

Aborted command: SCSI parity error.

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

[PATCH] 2.4.5 ISA DMA hang on ALI 15x3

[Andreas Tscharner]

Hello World,

This little patch enables the workaround for the ISA DMA bug on ALi15x3
chipsets with the PCI-ISA bridge.

CHANGES:
Changed file: $KERNELROOT/drivers/pci/quirks.c

There is a DMA bug in the PCI-ISA host bridge of the ALi15x3 chipset.
The use of this DMA causes a hang.

The OSS and ALSA modules for the OPL3/SA2 and OPL3/SAx sound chip use
this DMA which causes a complete hang.

This combination of chipset and soundchip is found in the whole Acer
Extensa laptop series.

The patch adds the chipset mentioned above to the main table of quirks.

The patch was originally written by Angelo Di Filippo
<[EMAIL PROTECTED]> as a patch for Kernel 2.3.45. I adapted it to
Kernel 2.4.5


PATCH:
--- drivers/pci/quirks.c.orig   Thu May 31 22:32:12 2001
+++ drivers/pci/quirks.cThu May 31 22:36:08 2001
@@ -344,6 +344,7 @@
{ PCI_FIXUP_FINAL,  PCI_VENDOR_ID_VIA,  PCI_DEVICE_ID_VIA_82C586_0,
 quirk_isa_dma_hangs },
{ PCI_FIXUP_FINAL,  PCI_VENDOR_ID_VIA,  PCI_DEVICE_ID_VIA_82C596,  
 quirk_isa_dma_hangs },
{ PCI_FIXUP_FINAL,  PCI_VENDOR_ID_INTEL,PCI_DEVICE_ID_INTEL_82371SB_0, 
 quirk_isa_dma_hangs },
+   { PCI_FIXUP_FINAL,  PCI_VENDOR_ID_AL,   PCI_DEVICE_ID_AL_M1533,
+ quirk_isa_dma_hangs },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_S3,   PCI_DEVICE_ID_S3_868,  
 quirk_s3_64M },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_S3,   PCI_DEVICE_ID_S3_968,  
 quirk_s3_64M },
{ PCI_FIXUP_FINAL,  PCI_VENDOR_ID_INTEL,PCI_DEVICE_ID_INTEL_82437, 
 quirk_triton }, 


Have a nice day.

Regards
Andreas
-- 
Andreas Tscharner [EMAIL PROTECTED]
-
"Programming today is a race between software engineers striving to build 
bigger and better idiot-proof programs, and the Universe trying to produce 
bigger and better idiots. So far, the Universe is winning." -- Rich Cook 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: [driver] New life for Serial mice

[James Simmons]

> > I ported it over to my tree. I will have to figure out how to incorporate
> > the input serial stuff without breaking all the input drivers we have. In
> > CVS we have alot of them. This will make life so much easier since all I
> > will have to do is change one file for changes I make to the tty layer. I
> > have improved andrew mortons console patch to work with multiple consoles
> > and for different types of console devices. Instead of altering all the 
> > console drivers I'm planning on intergrating the locking into the tty
> > layer. That patch is needed for serial devices as well as video terminals.
> > Your work might help speed up devleopement.
> 
> Sounds cute. Where do I find the result of your work?

For Russell's work I placed it in the ruby tree under linux/drivers/serial. No
changes have happened to it. Well at least not yet. What I like to see is:

serial_driver -> serial common code -> serial tty 
  | 
  |--> serial input

For my one system I have for my only serial device a joystick. Do I really
need a serial terminal for this device. Termios changes to joystick, give
me a break. It just another layer of uneeded bloat. A nice clean design
like this would be really nice. The code is in CVS if you want to play
with it. 

As for the console lock it is already in CVS as well. Their are a few race
conditions dealing with printk and register_console to pound out but its
there and it works well. The basic changes I have made are the functions
acquire_console_sem and release_console_sem take a struct tty_driver
argument. This way we can flush one driver that was busy while printk was
running when the tty code finish doing what it was doing. Now when printk
gets called it attempts to write data to all the consoles if they already
not busy. This way it only locks out one console at a time. This way
serial console doesn't have to be locked waiting for fbcon to finish
printing to the console. A semaphore in struct tty_driver is shared with
struct console. The better news is now we can use IRQ/DMA based devices
for the console system. 



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: Break 2.4 VM in five easy steps

[Eric W. Biederman]

Helge Hafting <[EMAIL PROTECTED]> writes:

> A problem with this is that normal paging-in is allowed to page other
> things out as well.  But you can't have that when swap is about to
> be turned off.  My guess is that swapoff functionality was perceived to
> be so seldom used that they didn't bother too much with scheduling 
> or efficiency.

There is some truth in that.  You aren't allowed to allocate new pages
in the swap space currently being removed however.  The current swap
off code removes pages from the current swap space without breaking
any sharing between swap pages.  Depending on your load this may be
important.  Fixing swapoff to be more efficient while at the same time
keeping sharing between pages is tricky.  That under loads that are
easy to trigger in 2.4 swapoff never sleeps is a big bug.

> I don't have the same problem myself though.  Shutting down with
> 30M or so in swap never take unusual time on 2.4.x kernels here,
> with a 300MHz processor.  I did a test while typing this letter,
> almost filling the 96M swap partition with 88M.  swapoff
> took 1 minute at 100% cpu.  This is long, but the machine was responsive
> most of that time.  I.e. no worse than during a kernel compile.
> The machine froze 10 seconds or so at the end of the minute, I can
> imagine that biting with bigger swap.

O.k. so at some point you actually wait for I/O and other process get
a chance to run.  On the larger machines we never wait for I/O and
thus never schedule at all.

The problem is now understood.  Now we just need to fix it.

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

Re: Break 2.4 VM in five easy steps

[Eric W. Biederman]

LA Walsh <[EMAIL PROTECTED]> writes:

> Now for whatever reason, since 2.4, I consistently use at least
> a few Mb of swap -- stands at 5Meg now.  Weird -- but I notice things
> like nscd running 7 copies that take 72M.  Seems like overkill for
> a laptop.

So the question becomes why you are seeing an increased swap usage.
Currently there are two canidates in the 2.4.x code path.

1) Delayed swap deallocation, when a program exits after it
   has gone into swap it's swap usage is not freed. Ouch.

2) Increased tenacity of swap caching.  In particular in 2.2.x if a page
   that was in the swap cache was written to the the page in the swap
   space would be removed.  In 2.4.x the location in swap space is
   retained with the goal of getting more efficient swap-ins.

Neither of the known canidates from increasing the swap load applies
when you aren't swapping in the first place.  They may aggrevate the
usage of swap when you are already swapping but they do not cause
swapping themselves.  This is why the intial recommendation for
increased swap space size was made.  If you are swapping we will use
more swap.

However what pushes your laptop over the edge into swapping is an
entirely different question.  And probably what should be solved.

> I think that is the point -- it was supported in 2.2, it is, IMO,
> a serious regression that it is not supported in 2.4.

The problem with this general line of arguing is that it lumps a whole
bunch of real issues/regressions into one over all perception.  Since
there are multiple reasons people are seeing problems, they need to be
tracked down with specifics.

The swapoff case comes down to dead swap pages in the swap cache.
Which greatly increases the number of swap pages slows the system
down, but since these pages are trivial to free we don't generate any
I/O so don't wait for I/O and thus never enter the scheduler.  Making
nothing else in the system runnable.

Your case is significantly different.  I don't know if you are seeing 
any issues with swapping at all.  With a 5M usage it may simply be
totally unused pages being pushed out to the swap space.

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

Re: scsi disk defect or kernel driver defect ?

[Khalid Aziz]

Nico Schottelius wrote:
> 
> Hello guys!
> 
> Currently my scsi disc is only reporting errors!
> In the adaptect scsi bios I tried the verify media
> option and it worked fine. The output from the Linux
> kernel is more than worse!
> 
> Can you tell me what's wrong in my system ?
> 
> I will monitor the mailing list the next hours, if
> the hard disk allows that.
> 
> Please help me, this is the second scsi disc
> reporting such failures!
> 
> Regards,
> 
> Nico
>... stuff deleted ..
> 
>  0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
>  I/O error: dev 08:01, sector 127304
> SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 802
> [valid=0] Info fld=0x0, Current sd08:01: sns = 70  b
> ASC=47 ASCQ= 0
> Raw sense data:0x70 0x00 0x0b 0x00 0x00 0x00 0x00 0x18 0x00 0x00 0x00 0x00 0x47 0x00 
>0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
>0x00
>  I/O error: dev 08:01, sector 127312
> SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 802
> [valid=0] Info fld=0x0, Current sd08:01: sns = 70  b
> ASC=47 ASCQ= 0

You are seeing lots of parity errors (ASC=47 ASCQ=0). I would suggest
checking cabling and terminator. 

-- 
Khalid


Khalid Aziz Linux Development Laboratory
(970)898-9214Hewlett-Packard
[EMAIL PROTECTED]Fort Collins, CO
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: temperature standard - global config option?

[David Rees]

On Thu, Jun 07, 2001 at 03:20:03PM +0300, L. K. wrote:
> On Thu, 7 Jun 2001, Philips wrote:
> 
> > Kelvins good idea in general - it is always positive ;-)
> > 
> > 0.01*K fits in 16 bits and gives reasonable range.
> > 
> > but may be something like K<<6 could be a option? (to allow use of shifts
> > instead of muls/divs). It would be much more easier to extract int part.
> > 
> > just my 2 eurocents.
> 
> Why not make it in Celsius ? Is more easy to read it this way.

It's easier for you as a user to read, but slightly harder to deal with inside the 
code.  
It's really a user-space issue, inside the kernel should be as standardized as 
possible, and
Kelvins make the most sense there.

-Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: NULL characters in file on ReiserFS again.

[Tor Arntsen]

On Thu, May 31, 2001 at 09:57:51AM -0700, Hans Reiser wrote:
>Andrej Borsenkow wrote:
> > /etc/hosts (or anywhere). As a tesult, startx hung starting X server; it was
> > not possible to switch to alpha console or kill X server. I pressed reset
> > and after reboot looked into /var/log/XFree86*log - and there were a bunch
> > of ^@ there.

> this is the nature of metadata journaling filesystems.

Exactly the same thing happens on XFS filesystems on IRIX 6.5.
We had a bunch of Origin systems that crashed every so often because
of some PCI bus problems, and every time this happened every file
on the system that had been updated the last seconds before the
crash would be full of, or almost full of ^@.  Needless to say
this created havoc with CVS repositories and also checked-out
trees, since the CVS/Entries files would end up modified.

I first noticed this when my setiathome status files were empty
after the restarts.. *every* time.  I had to install a cron job 
that copied the status file every two minutes or so, the slightly
older copy would be okay so I could just copy it back after the
restart.

That was a nuisance, but when the CVS systems got wrecked it became
a little worse.  Obviously we have backups, but the problem was that
you wouldn't necessarily notice right away that anything was screwed.

Hopefully SGI will fix it, or maybe they have fixed it already -- 
I don't know.  I'm running 6.5.8 which isn't the latest (IRIX is
at 6.5.11 or 6.5.12 now I think), and it certainly wasn't fixed there.
If not, then XFS will never run on my Linux boxes, and certainly
not on the big Linux server that now holds our CVS repositories
instead of the SGI Origin system that we originally used :-)

In another posting Stephen Tweedie writes:
>Umm, no, it isn't.  Ext3 would never allow that to happen in ordered
>metadata-journaling mode, and Chris Mason is already working to remove
>that window in reiserfs.  It is by no means a necessary consequence of
>doing metadata-only journaling.

That's good news.

-Tor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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.5: extreme sluggishness/strange OOM

[Frank van Maarseveen]

A PIII with 64MB ram, 256MB swap became extremely sluggish. While still
inside X11 the caps-lock LED responded only after about 10 seconds. Disk
LED was continuously on. Impossible to connect from another system (just too
slow) but the box still responded to ICMP echo.

I played a bit with magic sysrq before the system was rebooted. This is an
excerpt from /var/log/messages. I don't know how to interpret everything but
certainly the long stack traces look suspicious to me. Obviously the system
ran out of memory and swap but I'm not sure how. Yes I know here are some VM
issues which _might_ be responsible.

Jun  7 16:49:51 posio kernel: Out of Memory: Killed process 10165 (gnome-terminal). 
Jun  7 16:49:54 posio automount[4566]: expired /usr/src/olman
Jun  7 16:50:40 posio automount[555]: attempting to mount entry /usr/src/olman
Jun  7 16:53:51 posio automount[6550]: expired /usr/src/olman
Jun  7 16:54:50 posio automount[555]: attempting to mount entry /usr/src/olman
Jun  7 16:56:32 posio automount[6694]: expired /usr/src/olman
Jun  7 16:58:08 posio kernel: Out of Memory: Killed process 6033 (gnome-terminal). 
Jun  7 16:58:10 posio kernel: Out of Memory: Killed process 12952 (gnome-terminal). 
Jun  7 16:58:10 posio kernel: Out of Memory: Killed process 16744 (gnomecal). 
Jun  7 16:58:10 posio kernel: Out of Memory: Killed process 16742 (gmc). 
Jun  7 16:58:10 posio kernel: Out of Memory: Killed process 16736 (panel). 
Jun  7 16:58:58 posio automount[555]: attempting to mount entry /usr/src/olman
Jun  7 17:04:08 posio kernel: Out of Memory: Killed process 7882 (cpumemusage_app). 
Jun  7 17:04:40 posio kernel: Out of Memory: Killed process 6756 (gmc). 
Jun  7 17:05:06 posio automount[13344]: expired /usr/src/olman
Jun  7 17:05:20 posio automount[555]: attempting to mount entry /usr/src/olman
Jun  7 17:06:32 posio automount[13829]: expired /usr/src/olman
Jun  7 17:07:53 posio kernel: Out of Memory: Killed process 6748 (panel). 
Jun  7 17:08:01 posio automount[555]: attempting to mount entry /usr/src/olman
Jun  7 17:11:13 posio automount[15088]: expired /usr/src/olman
Jun  7 17:12:09 posio automount[555]: attempting to mount entry /usr/src/olman
Jun  7 17:13:30 posio automount[15543]: expired /usr/src/olman
Jun  7 17:13:55 posio automount[555]: attempting to mount entry /usr/src/olman
Jun  7 17:15:12 posio automount[15778]: expired /usr/src/olman
Jun  7 17:19:42 posio automount[555]: attempting to mount entry /usr/src/olman
Jun  7 17:20:57 posio automount[16168]: expired /usr/src/olman
Jun  7 17:23:43 posio pam_rhosts_auth[16274]: allowed to [EMAIL PROTECTED] as fvm
Jun  7 17:24:04 posio kernel: SysRq: Show Memory 
Jun  7 17:24:04 posio kernel: Mem-info: 
Jun  7 17:24:04 posio kernel: Free pages:1768kB ( 0kB HighMem) 
Jun  7 17:24:04 posio kernel: ( Active: 346, inactive_dirty: 96, inactive_clean: 201, 
free: 442 (222 444 666) ) 
Jun  7 17:24:04 posio kernel: 115*4kB 7*8kB 1*16kB 1*32kB 1*64kB 1*128kB 1*256kB 
0*512kB 0*1024kB 0*2048kB = 1012kB) 
Jun  7 17:24:04 posio kernel: 85*4kB 8*8kB 2*16kB 0*32kB 1*64kB 0*128kB 1*256kB 
0*512kB 0*1024kB 0*2048kB = 756kB) 
Jun  7 17:24:04 posio kernel: = 0kB) 
Jun  7 17:24:04 posio kernel: Swap cache: add 940496, delete 940331, find 
2846139/4357658 
Jun  7 17:24:04 posio kernel: Free swap:0kB 
Jun  7 17:24:04 posio kernel: 16128 pages of RAM 
Jun  7 17:24:04 posio kernel: 0 pages of HIGHMEM 
Jun  7 17:24:04 posio kernel: 1029 reserved pages 
Jun  7 17:24:05 posio kernel: 2646 pages shared 
Jun  7 17:24:06 posio kernel: 165 pages swap cached 
Jun  7 17:24:07 posio kernel: 0 pages in page table cache 
Jun  7 17:24:07 posio kernel: Buffer memory:  152kB 
Alt-SysRq-T:
Jun  7 17:24:10 posio kernel: >] [] [] []  
Jun  7 17:24:10 posio kernel:[] [] [] 
[] [] [] [] []  
Jun  7 17:24:10 posio last message repeated 32 times
Jun  7 17:24:10 posio kernel:[] [] [] 
[] [] [] [] []  
Jun  7 17:24:10 posio kernel:[] [] [] 
[] [] [] [] []  
Jun  7 17:24:10 posio kernel:[] [] [] 
[] [] [] [] []  
Jun  7 17:24:10 posio kernel:[] [] [] 
[] [] [] [] []  
Jun  7 17:24:10 posio kernel:[] [] [] 
[] [] [] [] []  
Jun  7 17:24:10 posio kernel:[] [] [] 
[] [] [] [] []  
Jun  7 17:24:10 posio kernel:[] [] [] 
[] [] [] [] []  
Jun  7 17:24:10 posio kernel:[] [] [] 
[] [] [] []  
Jun  7 17:24:10 posio kernel: shS  0 15683  15251 15686  (NOTLB)   
  
Jun  7 17:24:10 posio kernel: Call Trace: [] [] [] 
[] [] [] []  
Jun  7 17:24:10 posio kernel:[] [] [] 
[] [] [] [] []  
Jun  7 17:24:10 posio kernel:[] [] [] 
[] [] [] [] []  
Jun  7 17:24:10 posio kernel:[] [] [] 
[] [] [] [] []  
Jun  7 17:24:11 posio kernel:[] [] [] 
[] [] [] [] []  
Jun  7 17:24:11 posio kernel:[] [] [] 
[] [] [] [] []  
Jun  7 17:24:11 posio kernel:[] [] [] 
[] [] [] [] []  
Jun  7 17:24:11 posio kernel:[] [] [] 
[] [] [] [] []  
Jun  7 17:24:11 posio 

scsi disk defect or kernel driver defect ?

[Nico Schottelius]

Hello guys!

Currently my scsi disc is only reporting errors!
In the adaptect scsi bios I tried the verify media
option and it worked fine. The output from the Linux
kernel is more than worse!

Can you tell me what's wrong in my system ?

I will monitor the mailing list the next hours, if
the hard disk allows that.

Please help me, this is the second scsi disc
reporting such failures!

Regards,

Nico


 Scsiinfo version 1.7(eowmob)

Inquiry command
---
Relative Address   0
Wide bus 320
Wide bus 161
Synchronous neg.   1
Linked Commands1
Command Queueing   1
SftRe  0
Device Type0
Peripheral Qualifier   0
Removable? 0
Device Type Modifier   0
ISO Version0
ECMA Version   0
ANSI Version   3
AENC   0
TrmIOP 0
Response Data Format   2
Vendor:IBM 
Product:   DNES-309170W
Revision level:SA30AJGE0980

Serial Number 'AJGE0980'
Data from Rigid Disk Drive Geometry Page

Number of cylinders11474
Number of heads5
Starting write precomp 0
Starting reduced current   0
Drive step rate0
Landing Zone Cylinder  0
RPL0
Rotational Offset  0
Rotational Rate7200

Data from Caching Page
--
Write Cache1
Read Cache 1
Prefetch units 0
Demand Read Retention Priority 0
Demand Write Retention Priority0
Disable Pre-fetch Transfer Length  65535
Minimum Pre-fetch  0
Maximum Pre-fetch  65535
Maximum Pre-fetch Ceiling  65535

Data from Format Device Page

Removable Medium   0
Supports Hard Sectoring1
Supports Soft Sectoring0
Addresses assigned by surface  0
Tracks per Zone5215
Alternate sectors per zone 0
Alternate tracks per zone  0
Alternate tracks per lun   0
Sectors per track  320
Bytes per sector   512
Interleave 1
Track skew factor  11
Cylinder skew factor   20

Data from Error Recovery Page
-
AWRE   1
ARRE   1
TB 0
RC 0
EER0
PER0
DTE0
DCR0
Read Retry Count   1
Correction Span0
Head Offset Count  0
Data Strobe Offset Count   0
Write Retry Count  1
Recovery Time Limit0

Data from Control Page
--
RLEC   0
QErr   0
DQue   0
EECA   0
RAENP  0
UUAENP 0
EAENP  0
Queue Algorithm Modifier   0
Ready AEN Holdoff Period   0

Data from Disconnect-Reconnect Page
---
Buffer full ratio  0
Buffer empty ratio 0
Bus Inactivity Limit   0
Disconnect Time Limit  0
Connect Time Limit 0
Maximum Burst Size 0
DTDC   0x0

Data from Defect Lists
--
151 entries in manufacturer table.
Format is: bytes from index [Cyl:Head:Off]
Offset -1 marks whole track as bad.

 137:3:70656 138:3:70656 139:3:70656 140:3:70656 141:3:70656
186:1:182272 367:4:92672382:0:122880382:0:123392 434:4:47104
 454:4:47104 458:4:47104 459:4:47104 460:4:47104 461:4:47104
 462:4:47104558:1:109056559:1:109056560:1:109056561:1:109056
 733:1:40960  1086:2:5121110:1:834561110:1:83968 1139:1:9216
1251:4:68608   1733:1:115712   1854:0:1484801926:Unable to read Peripheral 
Device Page 09h
1:199681940:4:82944
1974:1:112642156:1:404482440:1:486402497:1:78848   3416:0:146432
   3669:1:110592   3669:1:04   3669:1:111616   3669:1:112128   3669:1:112640
   3669:1:113152   3669:1:113664   3669:1:114176   3669:1:114688   3669:1:115200
   3669:1:115712   3669:1:116224   3669:1:116736   3669:1:1172484125:4:27136
   4142:4:126464   4222:1:1459204371:2:86528   4437:3:144384

ipv6: can't connect to myself?!

[Felix von Leitner]

I can't connect() to my own link-local address.
connect just hangs.

Before some wise guy now tells me I should be connecting to ::1 instead:
"oh, really!" ;)  The application is npush/npoll from my ncp program
suite, which can be found at http://www.fefe.de/ncp/.

Basically, the sender sends UDP announcements and the receiver connects
to the IP of the announcement on the interface of the announcement.

strace of the receiver reveals that it hangs in the connect() call.

Any takers?  Why does this not work?

Felix
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: Break 2.4 VM in five easy steps

[Derek Glidden]

Miles Lane wrote:
> 
> So please, if you have new facts that you want to offer that
> will help us characterize and understand these VM issues better
> or discover new problems, feel free to share them.  But if you
> just want to rant, I, for one, would rather you didn't.

*sigh*

Not to prolong an already pointless thread, but that really was the
intent of my original message.  I had figured out a specific way, with
easy-to-follow steps, to make the VM misbehave under very certain
conditions.  I even offered to help figure out a solution in any way I
could, considering I'm not familiar with kernel code.

However, I guess this whole "too much swap" issue has a lot of people on
edge and immediately assumed I was talking about this subject, without
actually reading my original message.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
#!/usr/bin/perl -w
$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map
{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;
$t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)
[$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join
"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d
>>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*
8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}
print+x"C*",@a}';s/x/pack+/g;eval 

usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \
| extract_mpeg2 | mpeg2dec - 

http://www.eff.org/http://www.opendvd.org/ 
 http://www.cs.cmu.edu/~dst/DeCSS/Gallery/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: CacheFS

[Jan Harkes]

On Thu, Jun 07, 2001 at 01:37:50PM +0200, Jan Kasprzak wrote:
>   The goal is to speed-up reading of potentially slow filesystems
> (NFS, maybe even CD-based ones) by the local on-disk cache in the same way
> IRIX or Solaris CacheFS works. I would expect this to be used on clusters
> of computers or university computer labs with NFS-mounted /usr or some
> other read-only filesystems. Another goal is to use the Linux filesystem
> as a backing store (as opposed to the block device or single large file
> used by CODA).

Coda definitely doesn't use a block device or single large file, but a
regular filesystem as backing store. Currently ext2, reiserfs and ramfs
are known to work, and at least tmpfs is know to be broken. I can easily
fix tmpfs, but it isn't urgent so I'm delaying working on it until 2.5
unless there is sufficient interest.

>   Every file on the front filesystem (NFS or so) volume will be cached
> in two local files by cachefsd: The first one would contain the (parts of)
> real file content, and the second one would contain file's metadata and the
> bitmap of valid blocks (or pages) of the first file. All files in cachefsd's
> backing store would be in a per-volume directory, and will be numbered by the
> inode number from the front filesystem.

- Intermezzo uses 'holes' in files to indicate that content isn't
  available.
- You might want to have a more hierarchical backing store, directory
  operations in large directories are not very efficient.
- I believe you are switching the meaning of front and backend
  filesystems around a lot in your description. Who exactly assigns the
  inode numbers?

>   Now here are some questions:
> 
> * Should the cachefsd be in user space (as it is in the prototype
> implementation) or should it be moved to the kernel space? The former
> allows probably better configuration (maybe a deeper directory
> structure in the backing store), but the later is faster as it avoids
> copying data between the user and kernel spaces.

If you only allow whole-file accesses, the Coda solution will minimize
data copying between user and kernel space. The file is fetched into the
cache when opened, and every subsequent access is transparently
redirected to the container-file without contacting userspace until the
file is closed.

I am not considering to ever add a bitmap based 'these parts are ok and
those aren't' file access implementation to the Coda kernel module.
However, I do consider a 'data is valid up to this point' offset field a
possible future extension. Basically the open would return early when
the first N pages have been streamed in from the server. Whenever the
client wants to write or read a page beyond this point the kernel makes
a request to userspace to extend the limit. This way quota's can be
enforced, access to large files that are read sequentially is faster,
but the kernel-userspace interactions are minimized.

> * Can the kernel part of CODA can be used for this?

Not if you want to intercept and redirect every single read and write
call. That's a whole other can of worms, and I'd advise you to let the
userspace cachemanager to act as an NFS daemon. In my opinion, the Coda
kernel module fills a specific niche, and should not become yet another
kernel NFS client implementation that happens to bounce requests to
userspace using read/write on a character device instead of RPC/UDP
packets to a socket.

If you are willing to work within the confines of the Coda semantics,
sure. I'd even be willing to push a bit more on the support of more
underlying filesystems and adding the 'valid data offset' logic.

Some references,

UserFS,
AFAIK one of the first userfs implementations for Linux,

http://www.goop.org/~jeremy/userfs/
http://www.penguin.cz/~jim/userfs/   (same one ported to 2.2?)


PodFuk,
Went from an NFS daemon implementation to using the Coda kernel
module,

http://atrey.karlin.mff.cuni.cz/~pavel/podfuk/podfuk.html
http://sourceforge.net/projects/uservfs/(aka UserVFS?)


AVFS,
Another userfs implementation that when from a shared library hack
to using the Coda kernel module,

http://sourceforge.net/projects/avfs


Jan

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

Re: [PATCH] Reap dead swap cache earlier v2

[Hugh Dickins]

On Thu, 7 Jun 2001, John Stoffel wrote:
> Shouldn't the "swap_count(page) == 1" check be earlier in the if
> statement, so we can fall through more quickly if there is no work to
> be done?  A small optimization, but putting the common cases first
> will help.

I don't think so: the out-of-line swap_count() function is considerably
more complicated than the macros and inline functions tested before it.

Hugh

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

Re: Break 2.4 VM in five easy steps

[Mike Galbraith]

On Thu, 7 Jun 2001, Bulent Abali wrote:

> I happened to saw this one with debugger attached serial port.
> The system was alive.  I think I was watching the free page count and
> it was decreasing very slowly may be couple pages per second.  Bigger
> the swap usage longer it takes to do swapoff.  For example, if I had
> 1GB in the swap space then it would take may be an half hour to shutdown...

I took a ~300ms ktrace snapshot of the no IO spot with 2.4.4.ikd..

  % TOTALTOTAL USECSAVG/CALL   NCALLS
  0.0693% 208.540.40  517 c012d4b9 __free_pages
  0.0755% 227.341.01  224 c012cb67 __free_pages_ok
  ...
 34.7195%  104515.150.95   110049 c012de73 unuse_vma
 53.3435%  160578.37  303.55  529 c012dd38 __swap_free
Total entries: 131051  Total usecs:301026.93 Idle: 0.00%

Andrew Morton could be right about that loop not being wonderful.

-Mike

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

Re: PROBLEM: I/O system call never returns if file desc is closedin the

[Alexander Viro]

On 7 Jun 2001, Florian Weimer wrote:

> There's a subtle difference: For malloc(), libc has a mutex (or
> whatever), but for open(), socket() etc., no locking is performed, and
> many libc functions create (and destroy) descriptors imlicitely.  

So? You don't have to close() descriptors you had not (to your code
knowledge) opened. End of story.

> I still don't see how you can write maintainable and reliable software
> with asynchronous close().  For example, if some select() call returns
> EBADF after an asynchronous close(), you would have to scan the
> descriptors to find the offending one, but in the meantime, it has
> been reused by another thread.  What do you do in this case?

You don't rely on EBADF. It's _your_ code that had closed the thing. Unless
you pass descriptors of unknown origin into select() (hardly a good idea)
you have all information you need to provide an exclusion.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: Break 2.4 VM in five easy steps

[LA Walsh]

"Eric W. Biederman" wrote:

> There are cetain scenario's where you can't avoid virtual mem =
> min(RAM,swap). Which is what I was trying to say, (bad formula).  What
> happens is that pages get referenced  evenly enough and quickly enough
> that you simply cannot reuse the on disk pages.  Basically in the
> worst case all of RAM is pretty much in flight doing I/O.  This is
> true of all paging systems.


So, if I understand, you are talking about thrashing behavior
where your active set is larger than physical ram.  If that
is the case then requiring 2X+ swap for "better" performance
is reasonable.  However, if your active set is truely larger
than your physical memory on a consistant basis, in this day,
the solution is usually "add more RAM".  I may be wrong, but
my belief is that with today's computers people are used to having
enough memory to do their normal tasks and that swap is for
"peak loads" that don't occur on a sustained basis.  Of course
I imagine that this is my belief as it is my own practice/view.
I want to have considerably more memory than my normal working
set.  Swap on my laptop disk is *slow*.  It's a low-power, low-RPM,
slow seek rate all to conserve power (difference between spinning/off
= 1W).  So I have 50% of my phys mem on swap -- because I want to
'feel' it when I goto swap and start looking for memory hogs.
For me, the pathological case is touching swap *at all*.  So the
idea of the entire active set being >=phys mem is already broken
on my setup.  Thus my expectation of swap only as 'warning'/'buffer'
zone.

Now for whatever reason, since 2.4, I consistently use at least
a few Mb of swap -- stands at 5Meg now.  Weird -- but I notice things
like nscd running 7 copies that take 72M.  Seems like overkill for
a laptop.

> However just because in the worst case virtual mem = min(RAM,swap), is
> no reason other cases should use that much swap.  If you are doing a
> lot of swapping it is more efficient to plan on mem = min(RAM,swap) as
> well, because frequently you can save on I/O operations by simply
> reusing the existing swap page.

---
Agreed.  But planning your swap space for a worst
case scenario that you never hit is wasteful.  My worst
case is using any swap.  The system should be able to live
with swap=1/2*phys in my situation.  I don't think I'm
unique in this respect.

> It's a theoretical worst case and they all have it.  In practice it is
> very hard to find a work load where practically every page in the
> system is close to the I/O point howerver.

---
Well exactly the point.  It was in such situations in some older
systems that some programs were swapped out and temporarily made
unavailable for running (they showed up in the 'w' space in vmstat).

> Except for removing pages that aren't used paging with swap < RAM is
> not useful.  Simply removing pages that aren't in active use but might
> possibly be used someday is a common case, so it is worth supporting.

---
I think that is the point -- it was supported in 2.2, it is, IMO,
a serious regression that it is not supported in 2.4.

-linda

--
The above thoughts and   | They may have nothing to do with
writings are my own. | the opinions of my employer. :-)
L A Walsh| Senior MTS, Trust Tech., Core Linux, SGI
[EMAIL PROTECTED]  | Voice: (650) 933-5338



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: es1371 compile issue in 2.4.5-ac9

[Keith Owens]

On Wed, 6 Jun 2001 14:45:10 -0700 (PDT), 
Alan Olsen <[EMAIL PROTECTED]> wrote:
>I rebuilt from clean source and patch for 2.4.5-ac9 and neglected to add
>in anything using the joystick.
>
>ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext ...
>   -o vmlinux
>drivers/sound/sounddrivers.o: In function `es1371_probe':
>drivers/sound/sounddrivers.o(.text+0x5e5d): undefined reference to
>`gameport_register_port'

Your attached .config (why was it in base64?) has
  # CONFIG_SOUND is not set
which is completely incompatible with the above error.  Either you
manually overrode the compile or you enclosed the wrong .config.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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/

ftape and kernel 2.4 problem

[Friedrich Lobenstock]

Hi!

As the linux-ftape mailing list is gone I'm asking you guys.

Can someone tell me how to adapt the ftape driver that I can use it
under kernel 2.4.x (x >= 5)? I'm not that into kernel hacking that
I know what changed from 2.2.x to 2.4.x. Below is the output of make.

BTW why wasn't the newer ftape driver ported to 2.4 but the stone age
ftape driver is still in 2.4?

PS: Please CC me because I'm not on linux-kernel.


friedl:/usr/src/ftape-4.04a # make
for i in ftape ; do make -C $i all ; done
make[1]: Entering directory `/mount/2/src/ftape-4.04a/ftape'
> ../include/linux/modftversions.h
for i in  lowlevel internal parport zftape compressor; \
do \
  make -C $i NODEP=true versions; \
done
make[2]: Entering directory `/mount/2/src/ftape-4.04a/ftape/lowlevel'
rm -f ../../include/linux/modules/ftape_syms.ver.tmp; gcc -D__KERNEL__ -I. 
-I../../include -I/usr/src/linux/include  -E -D__GENKSYMS__ ftape_syms.c | 
/sbin/genksyms ../../include/linux/modules 2> /dev/null; rm -f 
../../include/linux/modules/ftape_syms.ver.tmp
make[2]: Leaving directory `/mount/2/src/ftape-4.04a/ftape/lowlevel'
make[2]: Entering directory `/mount/2/src/ftape-4.04a/ftape/internal'
make[2]: Nothing to be done for `versions'.
make[2]: Leaving directory `/mount/2/src/ftape-4.04a/ftape/internal'
make[2]: Entering directory `/mount/2/src/ftape-4.04a/ftape/parport'
make[2]: Nothing to be done for `versions'.
make[2]: Leaving directory `/mount/2/src/ftape-4.04a/ftape/parport'
make[2]: Entering directory `/mount/2/src/ftape-4.04a/ftape/zftape'
rm -f ../../include/linux/modules/zftape_syms.ver.tmp; gcc -D__KERNEL__ -I. 
-I../../include -I/usr/src/linux/include  -E -D__GENKSYMS__ zftape_syms.c | 
/sbin/genksyms ../../include/linux/modules 2> /dev/null; rm -f 
../../include/linux/modules/zftape_syms.ver.tmp
updating ../../include/linux/modftversions.h
make[2]: Leaving directory `/mount/2/src/ftape-4.04a/ftape/zftape'
make[2]: Entering directory `/mount/2/src/ftape-4.04a/ftape/compressor'
make[2]: Nothing to be done for `versions'.
make[2]: Leaving directory `/mount/2/src/ftape-4.04a/ftape/compressor'
set -e; for i in  lowlevel internal parport zftape compressor; do make -C $i modules; 
done
make[2]: Entering directory `/mount/2/src/ftape-4.04a/ftape/lowlevel'
make[2]: Leaving directory `/mount/2/src/ftape-4.04a/ftape/lowlevel'
make[2]: Entering directory `/mount/2/src/ftape-4.04a/ftape/lowlevel'
gcc -Wall -Wstrict-prototypes -O2  -fomit-frame-pointer -fno-strength-reduce 
-D__KERNEL__ -I. -I../../include -I/usr/src/linux/include -DMODULE -DMODVERSIONS 
-include ../../include/linux/modftversions.h  -DEXPORT_SYMTAB -c ftape_syms.c
In file included from /usr/src/linux/include/linux/fs.h:12,
 from /usr/src/linux/include/linux/capability.h:17,
 from /usr/src/linux/include/linux/binfmts.h:5,
 from /usr/src/linux/include/linux/sched.h:9,
 from ../../include/linux/ftape.h:35,
 from ftape_syms.c:32:
/usr/src/linux/include/linux/wait.h: In function `__add_wait_queue_tail':
/usr/src/linux/include/linux/wait.h:220: warning: implicit declaration of function 
`list_add_tail'
In file included from ftape-tracing.h:35,
 from ftape_syms.c:33:
../lowlevel/ftape-init.h: In function `ft_sigtest':
../lowlevel/ftape-init.h:70: structure has no member named `signal'
../lowlevel/ftape-init.h:71: warning: control reaches end of non-void function
make[2]: *** [ftape_syms.o] Error 1
make[2]: Leaving directory `/mount/2/src/ftape-4.04a/ftape/lowlevel'
make[1]: *** [modules] Error 2
make[1]: Leaving directory `/mount/2/src/ftape-4.04a/ftape'
make: *** [all] Error 2
friedl:/usr/src/ftape-4.04a #

-- 
MfG / Regards
Friedrich Lobenstock
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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/

BUG: race-cond with partition-check and ll_rw_blk (all platforms, 2.4.*!)

[COTTE]

Hi kernel-list-readers!

We just had a problem when running some formatting-utils on
a large amount of disks synchronously: We got a NULL-pointer
violation when accessig blk_size[major] for our major number.
Further research showed, that grok_partitions was running at
that time, which has been called by register_disk, which our
device driver issues after a disk has been formatted.
Grok_partitions first initializes blk_size[major] with a NULL
pointer, detects the partitions and then assigns the original
value to blk_size[major] again.
Here's the interresting code from these functions, I cut some
irrelevant things out:
>From grok_paritions:
 blk_size[dev->major] = NULL;
 check_partition(dev, MKDEV(dev->major, first_minor), 1 + first_minor);
 if (dev->sizes != NULL) {
  blk_size[dev->major] = dev->sizes;
 };
>From generic_make_request:
 if (blk_size[major]) {
   if (blk_size[major][MINOR(bh->b_rdev)]) {
printk(KERN_INFO
   "attempt to access beyond end of device\n");
printk(KERN_INFO "%s: rw=%d, want=%ld, limit=%d\n",
   kdevname(bh->b_rdev), rw,
   (sector + count)>>1,
   blk_size[major][MINOR(bh->b_rdev)]);
   }

Can anyone explain to me, why grok_partitions has to clear
this pointer? Why is this all done without any lock which causes
race conditions all over the block-device layer (for example
generic_make_request() in ll_rw_blk.c first checks if the pointer
is set and afterwards accesses the array behind the pointer)?

mit freundlichem Gru


ß / with kind regards
Carsten Otte

IBM Deutschland Entwicklung GmbH
Linux for 390/zSeries Development - Device Driver Team
Phone: +49/07031/16-4076
IBM internal phone: *120-4076
--
We are Linux.
Resistance indicates that you're missing the point!

Re: temperature standard - global config option?

[L. K.]

Why not make it in Celsius ? Is more easy to read it this way.



On Thu, 7 Jun 2001, Philips wrote:

> Hello All!
> 
>   Kelvins good idea in general - it is always positive ;-)
> 
>   0.01*K fits in 16 bits and gives reasonable range.
> 
>   but may be something like K<<6 could be a option? (to allow use of shifts
> instead of muls/divs). It would be much more easier to extract int part.
> 
>   just my 2 eurocents.

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

Re: [PATCH] Reap dead swap cache earlier v2

[John Stoffel]

Marcelo> As suggested by Linus, I've cleaned the reapswap code to be
Marcelo> contained inside an inline function. (yes, the if statement
Marcelo> is really ugly)

Shouldn't the "swap_count(page) == 1" check be earlier in the if
statement, so we can fall through more quickly if there is no work to
be done?  A small optimization, but putting the common cases first
will help.

Marcelo> +static inline int clean_dead_swap_page (struct page* page)
Marcelo> +{
Marcelo> +  int ret = 0;
Marcelo> +  if (!TryLockPage (page)) { 
Marcelo> +  if (PageSwapCache(page) && PageDirty(page) &&
Marcelo> +  (page_count(page) - !!page->buffers) == 1 &&
Marcelo> +  swap_count(page) == 1) { 
Marcelo> +  ClearPageDirty(page);
Marcelo> +  ClearPageReferenced(page);
Marcelo> +  page->age = 0;
Marcelo> +  ret = 1;
Marcelo> +  }


Thanks,
John
   John Stoffel - Senior Unix Systems Administrator - Lucent Technologies
 [EMAIL PROTECTED] - http://www.lucent.com - 978-952-7548
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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.5-ac8 hardlocks when going to standby

[Remi Turk]

On Thu, Jun 07, 2001 at 01:00:15PM +0200, Mikael Pettersson wrote:
> On Wed, 6 Jun 2001 22:42:53 +0200, Remi Turk wrote:
> 
> Try the patch below. Reboot. Run 'apm -S' (or --standby) at the
> console. Did you see output from both send_event and apic_pm_callback?
> If so, repeat by pressing your power-switch-as-standby button. You
> should see the same output -- if not, something APM-related is broken.

apm --standby works fine now:
send_event: event 9
apic_pm_callback: rqst 0 data 3
nmi_pm_callback: rqst 0 data 3
and on resume:
send_event: event 11
apic_pm_callback: rqst 1 data 0
nmi_pm_callback: rqst 1 data 0

apm --suspend also does what it should (and already did):
send_event: event 10
apic_pm_callback: rqst 0 data 3
nmi_pm_callback: rqst 0 data 3
and on resume:
send_event: event 3
apic_pm_callback: rqst 1 data 0
nmi_pm_callback: rqst 1 data 0

My "standbybutton" still hardlocks however.
Should I dig up some more info about my mainboard/BIOS?

> FYI, the patch below to apm.c:send_event() [w/o the printk] prevents
> my ASUS P3B-F from hanging hard if I invoke apm standby in a UP-APIC
> enabled kernel. (Actually, standby doesn't do much on my box since
> it wakes up after 1 second or so. I don't know why, perhaps a hub->nic
> link beat? 'suspend' works ok, however. Oh, and I have to disable
Try "sleep 2; apm --standby" or paste the newline with your mouse.
It works for me - my keyboard probably still sends data when my
system is already going into standby.

> RedHat's worthless 'kudzu' crap, otherwise 'suspend' won't work.)
It slows down booting a few seconds, and besides, I usually
know it when I add hardware, so kudzu is one of the first
packages I remove when installing.

> 
> /Mikael
>
>   case APM_USER_SUSPEND:
> + case APM_SYS_STANDBY:
> + case APM_USER_STANDBY:
>   /* map all suspends to ACPI D3 */
>   if (pm_send_all(PM_SUSPEND, (void *)3)) {
>   if (event == APM_CRITICAL_SUSPEND) {
> @@ -932,6 +935,7 @@
>   break;
>   case APM_NORMAL_RESUME:
>   case APM_CRITICAL_RESUME:
> + case APM_STANDBY_RESUME:
>   /* map all resumes to ACPI D0 */

It locked when suspending so I don't expect the added
"case APM_STANDBY_RESUME" to make any difference.
printk() doesn't seem to be logical too, and I tried the
"case APM_SYS_STANDBY" and "case APM_SYS_SUSPEND" yesterday
(didn't make a difference) so it looks like the mdelay()
does it.

-- 
Linux 2.4.6-pre1 #1 Wed Jun 6 18:25:37 CEST 2001
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: isolating process..

[Bohdan Vlasyuk]

On Thu, Jun 07, 2001 at 03:28:36PM +0100, Russell King wrote:

> I believe that Netfilter will do this for you.  
a) that'll require 2.4.x
b) that'll require 2.4.x recompilation
c) that will definitely not solve all the problems arise

thanks, anyway

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 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: I810 Sound broke between 2.4.2 and 2.4.3

[Doug Ledford]

Ben Castricum wrote:
> 
> I use amp to play my mp3s and it seem to stop functioning since 2.4.3. I
> captured the kernel messages from the module :
> 
> --- 2.4.2 ---
> Intel 810 + AC97 Audio, version 0.01, 14:04:06 Jun  4 2001
> PCI: Found IRQ 10 for device 00:1f.5
> PCI: The same IRQ used for device 00:1f.3
> PCI: The same IRQ used for device 01:09.0
> PCI: Setting latency timer of device 00:1f.5 to 64
> i810: Intel ICH 82801AA found at IO 0xe100 and 0xe000, IRQ 10
> ac97_codec: AC97 Audio codec, id: 0x4144:0x5340 (Analog Devices AD1881)
> i810_audio: Codec refused to allow VRA, using 48Khz only.
> 
> --- 2.4.3 ---
> Intel 810 + AC97 Audio, version 0.01, 14:18:58 Jun  4 2001
> PCI: Found IRQ 10 for device 00:1f.5
> PCI: The same IRQ used for device 00:1f.3
> PCI: The same IRQ used for device 01:09.0
> PCI: Setting latency timer of device 00:1f.5 to 64
> i810: Intel ICH 82801AA found at IO 0xe100 and 0xe000, IRQ 10
> ac97_codec: AC97 Audio codec, id: 0x4144:0x5340 (Analog Devices AD1881)
> i810_audio: Codec refused to allow VRA, using 48Khz only.
> i810_audio: 9576 bytes in 50 milliseconds
> 
> an strace of amp seems to halt on writing to the /dev/dsp
> 
> I have an Intel Celeron on an Asus-MEW motherboard which has this soundcard
> integrated.
> 
> Any ideas?

Can you try xmms with the oss output module and tell me if that works?

-- 

 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://www.tux.org/lkml/