All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: PROBLEM: dvd-drive no longer works (2.4.20)
From: Alvaro Lopes @ 2002-12-11 17:15 UTC (permalink / raw)
  To: Brendon Higgins; +Cc: linux-kernel
In-Reply-To: <200212111204.59505.bh_doc@users.sourceforge.net>

Brendon Higgins wrote:

>hdc: status error: status=0x7f { DriveReady DeviceFault SeekComplete 
>DataRequest CorrectedError Index Error }
>  
>
This looks weird. It's signalling a device fault *and * corrected error. 
Jens ?



^ permalink raw reply

* [TRIVIAL] 'extremal' in Documentation/Configure.help
From: John Bradford @ 2002-12-11 17:28 UTC (permalink / raw)
  To: linux-kernel; +Cc: akpm, jgarzik

> Documentation/Configure.help:
> during periods of extremal congestion. At the moment only a couple

Should 'extremal' be external, or extreme?  Both make sense in
context.

John.

^ permalink raw reply

* 2.5 Changes doc update.
From: Dave Jones @ 2002-12-11 17:25 UTC (permalink / raw)
  To: Linux Kernel

By popular (Well, 2 people) request (and various recent
repeated questions already answered here), here's another update
to the document I wrote detailing the various changes worth
knowing about if you are an end-user/tester of 2.5

		Dave



                     The post-halloween document. v0.19
                        (aka, 2.5 - what to expect)

                    Dave Jones <davej@codemonkey.org.uk>

                          (Updated as of 2.5.48)

This document explains some of the new functionality to be found in the 2.5
Linux kernel, some pitfalls you may encounter, and also points out some new
features which could really use testing.
Note, that "contact foo@bar.com" below also implies that you should also
cc: linux-kernel@vger.kernel.org.

Latest version of this document can always be found at
http://www.codemonkey.org.uk/post-halloween-2.5.txt

Thanks to Andrew Morton, Alan Cox, Alan Willis, Ingo Molnar, Robert Love
and many others for valuable feedback.

Note, that this document is somewhat x86-centric, but most features
documented here affect all platforms anyway.


Regressions.
~~~~~~~~~~~~
(Things not expected to work just yet)
- The hptraid/promise RAID drivers are currently non functional, and
  will probably be converted to use device-mapper.
- Some filesystems still need work (Intermezzo, UFS, HFS, HPFS..)
- A number of drivers don't compile currently due to them needing various
  work to convert them to the new APIs


Deprecated features.
~~~~~~~~~~~~~~~~~~~~
- khttpd is gone.
- Older Direct Rendering Manager (DRM) support (For XFree86 4.0)
  has been removed. Upgrade to XFree86 4.1.0 or higher.
- LVM1 has been removed. See Device-mapper below.
- boot time root= parsing changed.
  ramdisks now have ram<n> isntead of rd<n> and cm206 - cm206cd (instead of cm206).


Modules.
~~~~~~~~
- The in-kernel module loader got reimplemented.
- You need replacement module utilities from
  http://www.kernel.org/pub/linux/kernel/people/rusty/modules/
- A backwards compatable set of module utilities is available
  including v0.7 of the new-style utils in source RPM format from
  http://www.kernel.org/pub/linux/kernel/people/rusty/modules/modutils-2.4.21-5.src.rpm


Kernel build system.
~~~~~~~~~~~~~~~~~~~~
- Versus 2.4, the build system has been much improved.
  You should notice quicker builds, and less spontaneous rebuilds
  of files on subsequent builds from already built trees.
- make xconfig now requires the qt libraries.
- Make menuconfig/oldconfig has no user-visible changes other than speed,
  whilst numerous improvements have been made.
- Several new debug targets exist: 'allyesconfig' 'allnoconfig' 'allmodconfig'.
- For infomation: The above improvements are not CML2 / kbuild-2.5 related.


IO subsystem.
~~~~~~~~~~~~~
- You should notice considerable throughput improvements over 2.4 due
  to much reworking of the block and the memory management layers.
- Report any regressions in this area to Jens Axboe <axboe@suse.de>
  and Andrew Morton <akpm@digeo.com>.
- Assorted changes throughout the block layer meant various block
  device drivers had a large scale cleanup whilst being updated to
  newer APIs.
- The size and alignment of O_DIRECT file IO requests now matches that
  of the device, not the filesystem.  Typically this means that you
  can perform O_DIRECT IO with 512-byte granularity rather than 4k.

  But if you rely upon this, your application will not work on 2.4 kernels
  and will not work on some devices.


Enormous block size support.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Thanks to work done by Peter Chubb, block devices can now access up to
  16TB on 32-bit architectures, and up to 8EB on 64bit architectures.
- To use the new BLKGETSZ64 ioctls, you'll need updated file-utils.
  (Currently only jfsutils 1.0.20 has this change, patches for other
   filesystems are still pending merging)


POSIX ACLs & Extended attributes.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Userspace tools available at http://acl.bestbits.at


VM Changes.
~~~~~~~~~~~
- Version zero swap partitions are no longer supported (everything is
  using v1 now anyway - rerun mkswap if in doubt).
  Linux 2.0.x requires v0 swap space, Linux v2.1.117 and later
  support v1.  mkswap(8) can format swap space in either format.
- The bdflush() system call is still there and still just causes
  the calling process to exit.  This strangeness is presumably there
  to support people whose initscripts are trying to start the obsolete
  'update' daemon. It's likely this will become deprecated and usage of
  this will start logging messages to syslog.
- The actual 'reverse mappings' part of Rik van Riel's rmap vm was merged.
  VM behaviour under certain loads should improve.
- VM misbehaviour should be reported to linux-mm@kvack.org
- The VM explicitly checks for sparse swapfiles, and aborts if one is found.
- /proc/sys/vm/swappiness defines the kernel's preference for pagecache over
   mapped memory. Setting it to 100 (percent) makes it treat both types of
   memory equally. Setting it to zero makes the kernel very much prefer to
   reclaim plain pagecache rather than mapped-into-pagetables memory.


Kernel preemption.
~~~~~~~~~~~~~~~~~~
- The much talked about preemption patches made it into 2.5.
  With this included you should notice much lower latencies especially
  in demanding multimedia applications. 
- Note, there are still cases where preemption must be temporarily disabled
  where we do not. These areas occur in places where per-CPU data is used.
- If you get "xxx exited with preempt count=n" messages in syslog,
  don't panic, these are non fatal, but are somewhat unclean.
  (Something is taking a lock, and exiting without unlocking)
- If you DO notice high latency with kernel preemption enabled in
  a specific code path, please report that to Andrew Morton <akpm@digeo.com>
  and Robert Love <rml@tech9.net>.
  The report should be something like "the latency in my xyz application
  hits xxx ms when I do foo but is normally yyy" where foo is an action
  like "unlink a huge directory tree".


Process scheduler improvements.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Another much talked about feature. Ingo Molnar reworked the process
  scheduler to use an O(1) algorithm.  In operation, you should notice
  no changes with low loads, and increased scalability with large numbers
  of processes, especially on large SMP systems.
- Robert Love wrote various utilities for changing behaviour of the
  scheduler (binding processes to CPUs etc). You can find these tools at
  http://tech9.net/rml/schedutils
- Regressions to mingo@redhat.com and rml@tech9.net


Fast userspace mutexes (Futexes).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Rusty Russell added functionality that allows userspace to have
  fast mutexes that only use syscalls when there is contention.


epoll
~~~~~
Davide Libenzi wrote an edge triggered poll replacement that got
included in 2.5.  More info available at
http://www.xmailserver.org/linux-patches/nio-improve.html
http://lwn.net/Articles/13587/


Threading improvements.
~~~~~~~~~~~~~~~~~~~~~~~
- Ingo Molnar put a lot of work into threading improvements during 2.5.
  Some of the features of this work are:
  -  Generic pid allocator (arbitrary number of PIDs with no slowdown,
     unified pidhash).
  -  Thread Local Storage syscalls
  -  sys_clone() enhancements (CLONE_SETTLS, CLONE_SETTID, CLONE_CLEARTID,
     CLONE_DETACHED)
  -  POSIX thread signals stuff (atomic signals, shared signals, etc.)
  -  Per-CPU GDT
  -  Threaded coredumping support
  -  sys_exit() speedups (O(1) exit)
  -  Generic, improved futexes, vcache
  -  New, threading related ptrace features
  -  exit/fork task cache
  -  /proc updates for threading
  -  API changes for threading.
- Users should notice is a significant speedup in basic thread
  operations - this is true even for old-threading userspace libraries such
  as LinuxThreads.
- Regressions should go to Ingo Molnar <mingo@redhat.com> and phil-list@redhat.com.
  Regressions could happen in the area of signal handling and related threading
  semantics, plus coredumping.
- Native Posix Threading Library (NPTL).
  Ulrich Drepper worked closely with Ingo on the threading enhancements, and
  developed a 1:1 model threading library. You can find NPTL at
  ftp://people.redhat.com/drepper/nptl/


Enhanced coredump naming.
~~~~~~~~~~~~~~~~~~~~~~~~~
2.5 offers you the ability to configure the way core files are
named through a /proc/sys/kernel/core_pattern file.
You can use various format identifiers in this name to affect
how the core dump is named.

	%p - insert pid into filename
	%u - insert current uid into filename
	%g - insert current gid into filename
	%s - insert signal that caused the coredump into the filename
	%t - insert UNIX time that the coredump occured into filename
	%h - insert hostname where the coredump happened into filename
	%e - insert coredumping executable name into filename

You should ensure that the string does not exceed 64 bytes.


Input layer.
~~~~~~~~~~~~
- Possibly the most visible change to the end user. If misconfigured,
  you'll find that your keyboard/mouse/other input device will no longer work.
  2.5 offers a much more flexable interface to devices such as keyboards.
- The downside is more confusing options.
  In the "Input device support" menu, be sure to enable at least the following.

                    --- Input I/O drivers
                    < > Serial i/o support
                    < >   i8042 PC Keyboard controller
                    [ ] Keyboards
                    [ ] Mice

  (Also choose the relevant keyboard/mouse from the list)

- If you find your keyboard/mouse still don't work, edit the file
  drivers/input/serio/i8042.c, and replace the #undef DEBUG
  with a #define DEBUG

  When you boot, you should now see a lot more debugging information.
  Forward this information to Vojtech Pavlik <vojtech@suse.cz>

- If you use a KVM switcher, and experience problems, booting with the boot
  time argument 'psmouse_noext' should fix your problems.
- Users of multimedia keys without X will see changes in how the kernel
  handles those keys. People who customize keymaps or keycodes in 2.4
  may need to make some changes in 2.5


PnP layer.
~~~~~~~~~~
- Support for plug and play devices such as early ISAPnP cards has improved a
  lot in the 2.5 kernel. The new code behaves more closely to the code
  handling PCI devices (probe, remove etc callbacks), and also merges
  PnP BIOS access code.
- Report any regressions in plug & play functionality to
  Adam Belay <ambx1@neo.rr.com>


ALSA.
~~~~~
- The advanced linux sound architecture got merged into 2.5.
  This offers considerably improved functionality over the older OSS drivers,
  but requires new userspace tools.
- Several distros have shipped ALSA for some time, so you may already have the
  necessary tools. If not, you can find them at http://www.alsa-project.org/
- Note that the OSS drivers are also still functional, and still present.
  Many features/fixes that went into 2.4 are still not applied to these
  drivers, and it's still unclear if they will remain when 2.6/3.0 ships.
  The long term goal is to get everyone moved over to (the superior) ALSA.


procps.
~~~~~~~
- The 2.5 /proc filesystems changed some statistics, which confuse older
  versions of procps. Rik van Riel and Robert Love have been maintaining a
  version of procps during the 2.5 cycle which tracks changes to /proc which
  you can find at http://tech9.net/rml/procps/
- Alternatively, the procps by Albert Cahalan now supports the altered formats
  since v3.0.5, but lags behind the bleeding edge version maintained by Rik
  and Robert. -- http://procps.sf.net/
- The /proc/meminfo format changed slightly which also broke gtop in strange
  ways.


Framebuffer layer.
~~~~~~~~~~~~~~~~~~
- James Simmons has reworked the framebuffer/console layer considerably during
  2.5. Support for some cards is still lagging a little, but it should be
  functionally no different than previous incarnations.
- Any problems should go to <jsimmons@infradead.org>


IDE.
~~~~
- The IDE code was subject to much criticism in early 2.5.x, which
  put off a lot of people from testing. This work was then subsequently
  dropped, and reverted back to a 2.4.18 IDE status.
  Since then additional work has occured, but not to the extent
  of the first cleanup attempts.
- Known problems with the current IDE code. 
  o  Simplex IDE devices (eg Ali15x3) are missing DMA sometimes
  o  Serverworks OSB4 may panic on bad blocks or other non fatal errors
  o  PCMCIA IDE hangs on eject
  o  Most PCMCIA devices have unload races and may oops on eject
  o  Modular IDE does not yet work, modular IDE PCI modules sometimes
     oops on loading
  o  Silicon Image controllers give really bad performance currently.


IDE TCQ.
~~~~~~~~
- Tagged command queueing for IDE devices has been included.
- Not all combinations of controllers & devices may like this,
  so handle with care.
  READ AS: ** Don't use IDE TCQ on any data you value.
  It's likely bad combinations will be blacklisted as and when discovered.

- If you didn't choose the "TCQ on by default" option, you can enable
  it by using the command

    echo "using_tcq:32" > /proc/ide/hdX/settings

  (replacing 32 with 0 disables TCQ again).

- Report success/failure stories to Jens Axboe <axboe@suse.de> with
  inclusion of hdparm -i /dev/hdX, and lspci output.


SCSI.
~~~~~
- Various SCSI drivers still need work, and don't even compile.
- Various drivers currently lack error handling.
  These drivers will cause warnings during compilation due to
  missing abort: & reset: functions.
- Note, that some drivers have had these members removed, but still
  lack error handling. Those noticed so far are ncr53c8xxx, sym53c8xx and inia100


v4l2.
~~~~~
- The video4linux API finally got its long awaited cleanup.
- xawtv, bttv and most other existing v4l tools are also compatable
  with the new v4l2 layer. You should notice no loss in functionality.
- See http://bytesex.org/v4l/ for more information.


Quota reworking.
~~~~~~~~~~~~~~~~
The new quota system needs new tools.
http://www.sf.net/projects/linuxquota/


CD Recording.
~~~~~~~~~~~~~
- Jens Axboe added the ability to use DMA for writing CDs on
  ATAPI devices. Writing CDs should be much faster than it
  was in 2.4, and also less prone to buffer underruns and the like.
- Updated cdrecord in rpm and tar.gz can be found at
  *.kernel.org/pub/linux/kernel/people/axboe/tools/
- With the above tools, you also no longer need ide-scsi in order to use
  an IDE CD writer.
- Ripping audio tracks off of CDs now also uses DMA and should be
  notably faster. You can also find an updated cdda2wav at the same location.
- Send good/bad reports of audio extraction with cdda2wav and burning with
  the modified cdrecord to Jens Axboe <axboe@suse.de>
- More info at http://lwn.net/Articles/13538/ & http://lwn.net/Articles/13160/


USB:
~~~~
- Very little user visible changes, the only noticable 'major' change
  is that there is now only one UHCI driver.


Nanosecond stat:
~~~~~~~~~~~~~~~~
The stat64() syscall got changed to return jiffies granularity.
This allows make(1) to make better decisions on whether or not it
needs to recompile a file.


Filesystems:
~~~~~~~~~~~~
A number of additional filesystems have made their way into 2.5.
Whilst these have had testing out of tree, the level of testing
after merging is unparalleled. Be wary of trusting data to immature
filesystems.  A number of new features and improvements have also
been made to the existing filesystems from 2.4.

Reports of stress testing with the various tools available would
be beneficial.

EXT2.
~~~~~
- 2.5.49 included an extension to ext2 which will cause it to not attach
  buffer_head structures to file or directory pagecache at all, ever.
  This is for the big highmem machines.  It is enabled via the `-o nobh'
  mount option.

EXT3.
~~~~~
- The ext3 filesystem has gained indexed directory support, which offers
  considerable performance gains when used on filesystems with directories
  containing large numbers of files.
- In order to use the htree feature, you need at least version 1.32 of e2fsprogs.
- Existing filesystems can be converted using the command

    tune2fs -O dir_index /dev/hdXXX

- The latest e2fsprogs can be found at http://prdownloads.sourceforge.net/e2fsprogs

NFS.
~~~~
- Basic support has been added for NFSv4 (server and client)
- Additionally, kNFSD now supports transport over TCP.
  This experimental feature is also backported to 2.4.20
- Interoperability reports with other OS's would be useful.
- Problems to nfs@lists.sourceforge.net

sysfs.
~~~~~~
In simple terms, the sysfs filesystem is a saner way for
drivers to export their innards than /proc.
This filesystem is always compiled in, and can be mounted
just like another virtual filesystem. No userspace tools
beyond cat and echo are needed.

	mount -t sysfs none /sys

See Documentation/filesystems/sysfs.txt for more info.

JFS.
~~~~
IBM's JFS got merged during 2.5. (And backported to 2.4.20, but
it was still a new feature here first. You can read more about JFS at
http://www-124.ibm.com/developerworks/oss/jfs/index.html

XFS.
~~~~
The SGI XFS filesystem has been merged, and has a number of userspace
features. Users are encouraged to read http://oss.sgi.com/projects/xfs
for more information.
The various utilties for creating and manipulating XFS volumes can
be found on SGI's ftp server..
ftp://oss.sgi.com/projects/xfs/download/download/cmd_tars/xfsprogs-2.2.2.src.tar.gz

CIFS.
~~~~~
Support utilities and documentation for the common internet file system (CIFS)
can be found at http://us1.samba.org/samba/Linux_CIFS_client.html

Internal filesystems.
~~~~~~~~~~~~~~~~~~~~~
/proc/filesystems will contain several filesystems that are not
mountable in userspace, but are used internally by the kernel
to keep track of things. These filesystems are futexfs, eventpollfs
and hugetlbfs


Oprofile.
~~~~~~~~~
A system wide performance profiler has been included in 2.5.
With this option compiled in, you'll get an oprofilefs filesystem
which you can mount, that the userspace utilities talk to.
The userspace utilities for this are very young, and still being developed.
You can find out more at http://oprofile.sourceforge.net/oprofile-2.5.html


Simple boot flag support.
~~~~~~~~~~~~~~~~~~~~~~~~~
The SBF specification is an x86 BIOS extension that allows improved
system boot speeds. It does this by marking a CMOS field to say
"I booted okay, skip extensive POST next reboot".
Userspace tool is at http://www.codemonkey.org.uk/cruft/sbf.c
More info on SBF is at http://www.microsoft.com/hwdev/resources/specs/simp_bios.asp


x86 CPU detection.
~~~~~~~~~~~~~~~~~~
- The CPU detection code got a pretty hefty shake up. To be certain your
  CPU has all relevant workarounds applied, be sure to check that it was
  detected correctly. cat /proc/cpuinfo will tell what the kernel thinks it is.
- Likewise, the x86 MTRR driver got a considerable makeover.
  Check that XFree86 sets up MTRRs in the same way it did in 2.4
  (Failures will get logged in /var/log/XFree86.log)
- Early PII Xeon processors and possibly other early PII processors
  require microcode updates either from the BIOS or the microcode driver
  to handle the O(1) scheduler reliably.
  You can find the relevant microcode tools at http://www.urbanmyth.org/microcode/
- Any regressions in both should go to mochel@osdl.org Cc: davej@suse.de


Extra tainting.
~~~~~~~~~~~~~~~
Running certain AMD processors in SMP boxes is out of spec, and will taint
the kernel with the 'S' flag.  Running 2 Athlon XPs for example may seem to
work fine, but may also introduce difficult to pin down bugs.
In time it's likely this tainting will be extended to cover other out of
spec cases.

Additionally, the new modules interface will taint the kernel if you try
to 'force' a module to unload with rmmod -f.


Power management.
~~~~~~~~~~~~~~~~~
- 2.5 contains a more up to date snapshot of the ACPI driver. Should
  you experience any problems booting, try booting with the argument
  "acpi=off" to rule out any ACPI interaction. ACPI has a much more involved
  role in bringing the system up in 2.5 than it did in 2.4
- The old "acpismp=force" boot option is now obsolete, and will be ignored
  due to the old "mini ACPI" parser being removed.
- software suspend is still in development, and in need of more work.
  It is unlikely to work as expected currently.


CPU frequency scaling.
~~~~~~~~~~~~~~~~~~~~~~
Certain processors have the facility to scale their voltage/clockspeed.
2.5 introduces an interface to this feature, see Documentation/cpufreq
for more information. This functionality also covers features like
Intel's speedstep, and will be extended in time to cover the Powernow
feature present in mobile Athlons.  In addition to x86 variants, this
framework also supports various ARM CPUs.
You can find a userspace daemon that monitors battery life and
adjusts accordingly at: http://www.staikos.net/~staikos/cpufreqd/


Background polling of MCE.
~~~~~~~~~~~~~~~~~~~~~~~~~~
The machine check handler has been extended so that it regularly polls
for any problems on AMD Athlon, and Intel Pentium 4 systems.
This may result in machine check exceptions occuring more frequently
than they did in 2.4 on out of spec systems (Overclocking/inadequate
cooling/underated PSU etc..).


LVM2 - DeviceMapper.
~~~~~~~~~~~~~~~~~~~~
The LVM1 code got removed wholesale, and replaced with a much better
designed 'device mapper'.
- This is backwards compatable with the LVM1 disk format.
- Device mapper does require new tools to manage volumes however.
  You can get these from ftp://ftp.sistina.com/pub/LVM2/tools/


Debugging options.
~~~~~~~~~~~~~~~~~~
During the stabilising period, it's likely that the debugging options
in the kernel hacking menu will trigger quite a few problems.
Please report any of these problems to linux-kernel@vger.kernel.org
rather than just disabling the relevant CONFIG_ options.

Merging of kksymoops means that the kernel will now spit out
automatically decoded oopses (no more feeding them to ksymoops).
For this reason, you should always enable the option in the
kernel hacking menu labelled "Load all symbols for debugging/kksymoops".

Testing with CONFIG_PREEMPT will also increase the amount of debug
code that gets enabled in the kernel. Kernel preemption gives us
the ability to do a whole slew of debugging checks like sleeping
with locks held, scheduling while atomic, exiting with locks held, etc.
		

Compiler issues.
~~~~~~~~~~~~~~~~
- The recommended compiler (for x86) is still 2.95.3.
- When compiled with a modern gcc (Ie gcc 3.x), 2.5 will use additional
  optimisations that 2.4 didn't. This may shake out compiler bugs that
  2.4 didn't expose.
- Do not use gcc 3.0.x due to a stack pointer handling bug.


Security concerns.
~~~~~~~~~~~~~~~~~~
Several security issues solved in 2.4 are yet to be forward ported
to 2.5. For this reason 2.5.x kernels should not be tested on
untrusted systems.  Testing known 2.4 exploits and reporting results
is useful.


Networking.
~~~~~~~~~~~
- ebtables
  The bridging firewall code got merged. To manage these you'll need the ebtables
  tool available from http://users.pandora.be/bart.de.schuymer/ebtables/
  More on bridge-nf can be found at http://bridge.sourceforge.net
- Bridged packets can now be 'seen' by iptables.
- IPSec
  Linux finally has IPSec support in mainline.
  Use the KAME tools port on ftp://ftp.inr.ac.ru/ip-routing/ipsec/
  racoon won't compile, you don't need it yet.
  For more info see http://www.lib.uaa.alaska.edu/linux-kernel/archive/2002-Week-44/1127.html
  Also Bert Hubert has a howto at http://lartc.org/howto/lartc.ipsec.html


CryptoAPI.
~~~~~~~~~~
- A generic crypto API has been merged, offering support for various
  algorithms (HMAC,MD4,MD5,SHA-1,DES,Triple DES EDE, Blowfish)
- This functionality is currently only used by IPSec, but will later
  be extended to be used by other parts of the kernel. It's possible
  that it will later also be available for use in userspace through
  a crypto device, possibly compatable with the OpenBSD crypto userspace.


Ports.
~~~~~~
- 2.5 features support for several new architectures.
  - x86-64 (AMD Hammer)
    in-tree isn't up to date with ftp.x86-64.org
  - ppc64
  - UML (User mode Linux)
    See http://user-mode-linux.sf.net for more information.
  - uCLinux. 68k(w/o MMU) and v850.
  - Several in-tree ports are lagging behind their out-of-tree variants.


TODO.
~~~~~
- IPv6
  FIXME: userspace?
- AIO
  FIXME: Anything to add ?


Need checking.
~~~~~~~~~~~~~~
- Someone reported evolution locks up when calender/tasks/contacts is selected.
  Further digging has revealed a change to the getpeername syscall changed
  behaviour. See http://lists.ximian.com/archives/public/evolution-hackers/2002-October/005218.html
  for a patch to ORBit.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Everything below this line isn't included yet. It may feature in Linus'
bitkeeper tree ready for the next release, or maybe in -ac, -mm etc
or may not happen. Time will tell..


Deprecated. (FIXME: Included in -mm)
~~~~~~~~~~~
- elvtune is deprecated (as are the ioctl's it used).
  FIXME: not yet in mainline.
  Instead, the io scheduler tunables are exported in sysfs (see below)
  in the /sys/block/<device>/iosched directory.
  Jens wrote a document explaining the tunables of the new scheduler at
  http://www.lib.uaa.alaska.edu/linux-kernel/archive/2002-Week-44/att-deadline-iosched.txt


-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

^ permalink raw reply

* Re: [PATCH] epoll: don't printk pointer value
From: Davide Libenzi @ 2002-12-11 17:16 UTC (permalink / raw)
  To: Robert Love; +Cc: Linux Kernel Mailing List
In-Reply-To: <1039588045.833.3.camel@phantasy>

On Tue, 11 Dec 2002, Robert Love wrote:

> Davide,
>
> I really cannot think of a good reason why eventpoll_init() should print
> a pointer value to user-space - especially the value of current?
>
> I do not think this is good practice and someone might even consider it
> a security hole.  Personally, I would prefer to remove the "successfully
> initialized" message altogether, but at the very least can we not print
> current's address?

It's ok Robert, it was used for debugging purposes and now it can be
completely removed ( the whole printk() ). I'll post a patch to Linus that
removes the printk() ...



- Davide


^ permalink raw reply

* Re: Aic7xxx v6.2.22 and Aic79xx v1.3.0Alpha2 Released
From: Alan Cox @ 2002-12-11 17:06 UTC (permalink / raw)
  To: Justin T. Gibbs; +Cc: Christoph Hellwig, James Bottomley, linux-scsi
In-Reply-To: <1313340000.1039622906@aslan.scsiguy.com>

On Wed, 2002-12-11 at 16:08, Justin T. Gibbs wrote:
> Tell that to the OEMs that Adaptec has to support.  They still test and
> require 7.2 drivers.

Joyous. I guess you need the 2.4.7 drivers to install to update to the
errata though


^ permalink raw reply

* Re: Cache routine patch
From: Jun Sun @ 2002-12-11 17:06 UTC (permalink / raw)
  To: Carsten Langgaard; +Cc: Ralf Baechle, linux-mips, jsun
In-Reply-To: <3DF719D0.658530E2@mips.com>

[-- Attachment #1: Type: text/plain, Size: 19956 bytes --]


Part of you patches fixes an off-by-one problem in flushing
cache for a range of addresses.  I have a different version
for that part which is a little more visually pleasing.

See attachment.

Jun

On Wed, Dec 11, 2002 at 11:56:17AM +0100, Carsten Langgaard wrote:
> I have attached a patch, containing some fixes for some of the cache
> routines.
> Most of it is related to the MIPS32/MIPS64 specific routines, but it
> also contain a fix, which appear to be needed in all of the dma flushing
> routines. The problem is that we sometimes flush a cache line too much.
> Ralf, could you please take a look at it ?
> 
> /Carsten
> 
> 
> 
> --
> _    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
> |\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
> | \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
>   TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
>                    Denmark             http://www.mips.com
> 
> 

> Index: arch/mips/mm/c-mips32.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/mm/c-mips32.c,v
> retrieving revision 1.3.2.7
> diff -u -r1.3.2.7 c-mips32.c
> --- arch/mips/mm/c-mips32.c	2 Dec 2002 00:24:49 -0000	1.3.2.7
> +++ arch/mips/mm/c-mips32.c	11 Dec 2002 10:00:18 -0000
> @@ -298,13 +298,18 @@
>  static void
>  mips32_flush_icache_page(struct vm_area_struct *vma, struct page *page)
>  {
> -	int address;
> -
> +	/*
> +	 * If there's no context yet, or the page isn't executable, no icache 
> +	 * flush is needed.
> +	 */
>  	if (!(vma->vm_flags & VM_EXEC))
>  		return;
>  
> -	address = KSEG0 + ((unsigned long)page_address(page) & PAGE_MASK & (dcache_size - 1));
> -	blast_icache_page_indexed(address);
> +	/*
> +	 * We're not sure of the virtual address(es) involved here, so
> +	 * conservatively flush the entire caches.
> +	 */
> +	flush_cache_all();
>  }
>  
>  /*
> @@ -317,11 +322,11 @@
>  	unsigned int flags;
>  
>  	if (size >= dcache_size) {
> -		flush_cache_all();
> +		blast_dcache();
>  	} else {
>  	        __save_and_cli(flags);
>  		a = addr & ~(dc_lsize - 1);
> -		end = (addr + size) & ~(dc_lsize - 1);
> +		end = (addr + size - 1) & ~(dc_lsize - 1);
>  		while (1) {
>  			flush_dcache_line(a); /* Hit_Writeback_Inv_D */
>  			if (a == end) break;
> @@ -338,12 +343,12 @@
>  	unsigned long end, a;
>  
>  	if (size >= scache_size) {
> -		flush_cache_all();
> +		blast_scache();
>  		return;
>  	}
>  
>  	a = addr & ~(sc_lsize - 1);
> -	end = (addr + size) & ~(sc_lsize - 1);
> +	end = (addr + size - 1) & ~(sc_lsize - 1);
>  	while (1) {
>  		flush_scache_line(a);	/* Hit_Writeback_Inv_SD */
>  		if (a == end) break;
> @@ -358,13 +363,13 @@
>  	unsigned int flags;
>  
>  	if (size >= dcache_size) {
> -		flush_cache_all();
> +		blast_dcache();
>  	} else {
>  	        __save_and_cli(flags);
>  		a = addr & ~(dc_lsize - 1);
> -		end = (addr + size) & ~(dc_lsize - 1);
> +		end = (addr + size - 1) & ~(dc_lsize - 1);
>  		while (1) {
> -			flush_dcache_line(a); /* Hit_Writeback_Inv_D */
> +			invalidate_dcache_line(a); /* Hit_Inv_D */
>  			if (a == end) break;
>  			a += dc_lsize;
>  		}
> @@ -380,14 +385,14 @@
>  	unsigned long end, a;
>  
>  	if (size >= scache_size) {
> -		flush_cache_all();
> +		blast_scache();
>  		return;
>  	}
>  
>  	a = addr & ~(sc_lsize - 1);
> -	end = (addr + size) & ~(sc_lsize - 1);
> +	end = (addr + size - 1) & ~(sc_lsize - 1);
>  	while (1) {
> -		flush_scache_line(a); /* Hit_Writeback_Inv_SD */
> +		invalidate_scache_line(a); /* Hit_Inv_SD */
>  		if (a == end) break;
>  		a += sc_lsize;
>  	}
> @@ -412,7 +417,7 @@
>  
>  static void mips32_flush_icache_all(void)
>  {
> -	if (mips_cpu.cputype == CPU_20KC) {
> +	if (mips_cpu.icache.flags | MIPS_CACHE_VTAG_CACHE) {
>  		blast_icache();
>  	}
>  }
> @@ -423,6 +428,7 @@
>          unsigned long config1;
>  	unsigned int lsize;
>  
> +	mips_cpu.icache.flags = 0;
>          if (!(config & (1 << 31))) {
>  	        /*
>  		 * Not a MIPS32 complainant CPU.
> @@ -452,6 +458,16 @@
>  	       ic_lsize = mips_cpu.icache.linesz;
>  	       icache_size = mips_cpu.icache.sets * mips_cpu.icache.ways *
>  		             ic_lsize;
> +
> +	       if ((config & 0x8) || (mips_cpu.cputype == CPU_20KC)) {
> +		       /* 
> +			* The CPU has a virtually tagged I-cache.
> +			* Some older 20Kc chips doesn't have the 'VI' bit in
> +			* the config register, so we also check for 20Kc.
> +			*/
> +		       mips_cpu.icache.flags = MIPS_CACHE_VTAG_CACHE;
> +		       printk("Virtually tagged I-cache detected\n");
> +	       }
>  	}
>  	printk("Primary instruction cache %dkb, linesize %d bytes (%d ways)\n",
>  	       icache_size >> 10, ic_lsize, mips_cpu.icache.ways);
> @@ -462,6 +478,7 @@
>          unsigned long config1;
>  	unsigned int lsize;
>  
> +	mips_cpu.dcache.flags = 0;
>          if (!(config & (1 << 31))) {
>  	        /*
>  		 * Not a MIPS32 complainant CPU.
> Index: arch/mips/mm/c-r4k.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/mm/c-r4k.c,v
> retrieving revision 1.3.2.12
> diff -u -r1.3.2.12 c-r4k.c
> --- arch/mips/mm/c-r4k.c	6 Dec 2002 18:46:47 -0000	1.3.2.12
> +++ arch/mips/mm/c-r4k.c	11 Dec 2002 10:00:18 -0000
> @@ -970,7 +970,7 @@
>  #endif
>  
>  		a = addr & ~(dc_lsize - 1);
> -		end = (addr + size) & ~(dc_lsize - 1);
> +		end = (addr + size - 1) & ~(dc_lsize - 1);
>  		while (1) {
>  			flush_dcache_line(a); /* Hit_Writeback_Inv_D */
>  			if (a == end) break;
> @@ -993,7 +993,7 @@
>  	}
>  
>  	a = addr & ~(sc_lsize - 1);
> -	end = (addr + size) & ~(sc_lsize - 1);
> +	end = (addr + size - 1) & ~(sc_lsize - 1);
>  	while (1) {
>  		flush_scache_line(a);	/* Hit_Writeback_Inv_SD */
>  		if (a == end) break;
> @@ -1016,7 +1016,7 @@
>  #endif
>  
>  		a = addr & ~(dc_lsize - 1);
> -		end = (addr + size) & ~(dc_lsize - 1);
> +		end = (addr + size - 1) & ~(dc_lsize - 1);
>  		while (1) {
>  			flush_dcache_line(a); /* Hit_Writeback_Inv_D */
>  			if (a == end) break;
> @@ -1040,7 +1040,7 @@
>  	}
>  
>  	a = addr & ~(sc_lsize - 1);
> -	end = (addr + size) & ~(sc_lsize - 1);
> +	end = (addr + size - 1) & ~(sc_lsize - 1);
>  	while (1) {
>  		flush_scache_line(a); /* Hit_Writeback_Inv_SD */
>  		if (a == end) break;
> Index: arch/mips/mm/c-r5432.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/mm/c-r5432.c,v
> retrieving revision 1.4.2.3
> diff -u -r1.4.2.3 c-r5432.c
> --- arch/mips/mm/c-r5432.c	2 Dec 2002 00:24:49 -0000	1.4.2.3
> +++ arch/mips/mm/c-r5432.c	11 Dec 2002 10:00:18 -0000
> @@ -384,7 +384,7 @@
>  		flush_cache_all();
>  	} else {
>  		a = addr & ~(dc_lsize - 1);
> -		end = (addr + size) & ~(dc_lsize - 1);
> +		end = (addr + size - 1) & ~(dc_lsize - 1);
>  		while (1) {
>  			flush_dcache_line(a); /* Hit_Writeback_Inv_D */
>  			if (a == end) break;
> @@ -403,7 +403,7 @@
>  		flush_cache_all();
>  	} else {
>  		a = addr & ~(dc_lsize - 1);
> -		end = (addr + size) & ~(dc_lsize - 1);
> +		end = (addr + size - 1) & ~(dc_lsize - 1);
>  		while (1) {
>  			flush_dcache_line(a); /* Hit_Writeback_Inv_D */
>  			if (a == end) break;
> Index: arch/mips/mm/c-rm7k.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/mm/c-rm7k.c,v
> retrieving revision 1.4.2.5
> diff -u -r1.4.2.5 c-rm7k.c
> --- arch/mips/mm/c-rm7k.c	2 Dec 2002 00:24:49 -0000	1.4.2.5
> +++ arch/mips/mm/c-rm7k.c	11 Dec 2002 10:00:18 -0000
> @@ -131,7 +131,7 @@
>  	unsigned long end, a;
>  
>  	a = addr & ~(sc_lsize - 1);
> -	end = (addr + size) & ~(sc_lsize - 1);
> +	end = (addr + size - 1) & ~(sc_lsize - 1);
>  	while (1) {
>  		flush_dcache_line(a);	/* Hit_Writeback_Inv_D */
>  		flush_scache_line(a);	/* Hit_Writeback_Inv_SD */
> @@ -143,7 +143,7 @@
>  		return;
>  
>  	a = addr & ~(tc_pagesize - 1);
> -	end = (addr + size) & ~(tc_pagesize - 1);
> +	end = (addr + size - 1) & ~(tc_pagesize - 1);
>  	while(1) {
>  		invalidate_tcache_page(a);	/* Page_Invalidate_T */
>  		if (a == end) break;
> @@ -157,7 +157,7 @@
>  	unsigned long end, a;
>  
>  	a = addr & ~(sc_lsize - 1);
> -	end = (addr + size) & ~(sc_lsize - 1);
> +	end = (addr + size - 1) & ~(sc_lsize - 1);
>  	while (1) {
>  		invalidate_dcache_line(a);	/* Hit_Invalidate_D */
>  		invalidate_scache_line(a);	/* Hit_Invalidate_SD */
> @@ -169,7 +169,7 @@
>  		return;
>  
>  	a = addr & ~(tc_pagesize - 1);
> -	end = (addr + size) & ~(tc_pagesize - 1);
> +	end = (addr + size - 1) & ~(tc_pagesize - 1);
>  	while(1) {
>  		invalidate_tcache_page(a);	/* Page_Invalidate_T */
>  		if (a == end) break;
> Index: arch/mips/mm/c-tx39.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/mm/c-tx39.c,v
> retrieving revision 1.4.2.3
> diff -u -r1.4.2.3 c-tx39.c
> --- arch/mips/mm/c-tx39.c	2 Dec 2002 00:24:50 -0000	1.4.2.3
> +++ arch/mips/mm/c-tx39.c	11 Dec 2002 10:00:18 -0000
> @@ -65,7 +65,7 @@
>  
>  	iob();
>  	a = addr & ~(dcache_lsize - 1);
> -	end = (addr + size) & ~(dcache_lsize - 1);
> +	end = (addr + size - 1) & ~(dcache_lsize - 1);
>  	while (1) {
>  		invalidate_dcache_line(a); /* Hit_Invalidate_D */
>  		if (a == end) break;
> @@ -198,7 +198,7 @@
>  		flush_cache_all();
>  	} else {
>  		a = addr & ~(dcache_lsize - 1);
> -		end = (addr + size) & ~(dcache_lsize - 1);
> +		end = (addr + size - 1) & ~(dcache_lsize - 1);
>  		while (1) {
>  			flush_dcache_line(a); /* Hit_Writeback_Inv_D */
>  			if (a == end) break;
> @@ -215,7 +215,7 @@
>  		flush_cache_all();
>  	} else {
>  		a = addr & ~(dcache_lsize - 1);
> -		end = (addr + size) & ~(dcache_lsize - 1);
> +		end = (addr + size - 1) & ~(dcache_lsize - 1);
>  		while (1) {
>  			invalidate_dcache_line(a); /* Hit_Invalidate_D */
>  			if (a == end) break;
> Index: arch/mips/mm/c-tx49.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/mm/c-tx49.c,v
> retrieving revision 1.3.2.3
> diff -u -r1.3.2.3 c-tx49.c
> --- arch/mips/mm/c-tx49.c	2 Dec 2002 00:24:50 -0000	1.3.2.3
> +++ arch/mips/mm/c-tx49.c	11 Dec 2002 10:00:18 -0000
> @@ -311,7 +311,7 @@
>  		__save_and_cli(flags);
>  
>  		a = addr & ~(dc_lsize - 1);
> -		end = (addr + size) & ~(dc_lsize - 1);
> +		end = (addr + size - 1) & ~(dc_lsize - 1);
>  		while (1) {
>  			flush_dcache_line(a); /* Hit_Writeback_Inv_D */
>  			if (a == end) break;
> @@ -333,7 +333,7 @@
>  		__save_and_cli(flags);
>  
>  		a = addr & ~(dc_lsize - 1);
> -		end = (addr + size) & ~(dc_lsize - 1);
> +		end = (addr + size - 1) & ~(dc_lsize - 1);
>  		while (1) {
>  			flush_dcache_line(a); /* Hit_Writeback_Inv_D */
>  			if (a == end) break;
> Index: arch/mips64/mm/c-mips64.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips64/mm/c-mips64.c,v
> retrieving revision 1.1.2.4
> diff -u -r1.1.2.4 c-mips64.c
> --- arch/mips64/mm/c-mips64.c	2 Dec 2002 00:24:52 -0000	1.1.2.4
> +++ arch/mips64/mm/c-mips64.c	11 Dec 2002 10:00:18 -0000
> @@ -301,13 +301,18 @@
>  static void
>  mips64_flush_icache_page(struct vm_area_struct *vma, struct page *page)
>  {
> -	unsigned long address;
> -
> +	/*
> +	 * If there's no context yet, or the page isn't executable, no icache 
> +	 * flush is needed.
> +	 */
>  	if (!(vma->vm_flags & VM_EXEC))
>  		return;
>  
> -	address = KSEG0 + ((unsigned long)page_address(page) & PAGE_MASK & ((unsigned long)icache_size - 1));
> -	blast_icache_page_indexed(address);
> +	/*
> +	 * We're not sure of the virtual address(es) involved here, so
> +	 * conservatively flush the entire caches.
> +	 */
> +	flush_cache_all();
>  }
>  
>  /*
> @@ -324,7 +329,7 @@
>  	} else {
>  	        __save_and_cli(flags);
>  		a = addr & ~(dc_lsize - 1);
> -		end = (addr + size) & ~((unsigned long)dc_lsize - 1);
> +		end = (addr + size - 1) & ~((unsigned long)dc_lsize - 1);
>  		while (1) {
>  			flush_dcache_line(a); /* Hit_Writeback_Inv_D */
>  			if (a == end) break;
> @@ -346,7 +351,7 @@
>  	}
>  
>  	a = addr & ~(sc_lsize - 1);
> -	end = (addr + size) & ~(sc_lsize - 1);
> +	end = (addr + size - 1) & ~(sc_lsize - 1);
>  	while (1) {
>  		flush_scache_line(a);	/* Hit_Writeback_Inv_SD */
>  		if (a == end) break;
> @@ -365,7 +370,7 @@
>  	} else {
>  	        __save_and_cli(flags);
>  		a = addr & ~((unsigned long)dc_lsize - 1);
> -		end = (addr + size) & ~((unsigned long)dc_lsize - 1);
> +		end = (addr + size - 1) & ~((unsigned long)dc_lsize - 1);
>  		while (1) {
>  			invalidate_dcache_line(a); /* Hit_Inv_D */
>  			if (a == end) break;
> @@ -388,7 +393,7 @@
>  	}
>  
>  	a = addr & ~(sc_lsize - 1);
> -	end = (addr + size) & ~(sc_lsize - 1);
> +	end = (addr + size - 1) & ~(sc_lsize - 1);
>  	while (1) {
>  		invalidate_scache_line(a); /* Hit_Writeback_Inv_SD */
>  		if (a == end) break;
> @@ -416,7 +421,7 @@
>  static void
>  mips64_flush_icache_all(void)
>  {
> -	if (mips_cpu.cputype == CPU_20KC) {
> +	if (mips_cpu.icache.flags | MIPS_CACHE_VTAG_CACHE) {
>  		blast_icache();
>  	}
>  }
> @@ -428,6 +433,7 @@
>          unsigned long config1;
>  	unsigned int lsize;
>  
> +	mips_cpu.icache.flags = 0;
>          if (!(config & (1 << 31))) {
>  	        /*
>  		 * Not a MIPS64 complainant CPU.
> @@ -457,6 +463,16 @@
>  	       ic_lsize = mips_cpu.icache.linesz;
>  	       icache_size = mips_cpu.icache.sets * mips_cpu.icache.ways *
>  		             ic_lsize;
> +
> +	       if ((config & 0x8) || (mips_cpu.cputype == CPU_20KC)) {
> +		       /* 
> +			* The CPU has a virtually tagged I-cache.
> +			* Some older 20Kc chips doesn't have the 'VI' bit in
> +			* the config register, so we also check for 20Kc.
> +			*/
> +		       mips_cpu.icache.flags = MIPS_CACHE_VTAG_CACHE;
> +		       printk("Virtually tagged I-cache detected\n");
> +	       }
>  	}
>  	printk("Primary instruction cache %dkb, linesize %d bytes (%d ways)\n",
>  	       icache_size >> 10, ic_lsize, mips_cpu.icache.ways);
> @@ -467,6 +483,7 @@
>          unsigned long config1;
>  	unsigned int lsize;
>  
> +	mips_cpu.dcache.flags = 0;
>          if (!(config & (1 << 31))) {
>  	        /*
>  		 * Not a MIPS64 complainant CPU.
> Index: include/asm-mips/cache.h
> ===================================================================
> RCS file: /home/cvs/linux/include/asm-mips/cache.h,v
> retrieving revision 1.10.2.1
> diff -u -r1.10.2.1 cache.h
> --- include/asm-mips/cache.h	27 Jun 2002 14:21:23 -0000	1.10.2.1
> +++ include/asm-mips/cache.h	11 Dec 2002 10:00:22 -0000
> @@ -27,6 +27,7 @@
>   * Flag definitions
>   */
>  #define MIPS_CACHE_NOT_PRESENT 0x00000001
> +#define MIPS_CACHE_VTAG_CACHE  0x00000002 /* Virtually tagged cache. */
>  
>  #if defined(CONFIG_CPU_R3000) || defined(CONFIG_CPU_R6000) || defined(CONFIG_CPU_TX39XX)
>  #define L1_CACHE_BYTES		16
> Index: include/asm-mips/mips32_cache.h
> ===================================================================
> RCS file: /home/cvs/linux/include/asm-mips/mips32_cache.h,v
> retrieving revision 1.2.2.1
> diff -u -r1.2.2.1 mips32_cache.h
> --- include/asm-mips/mips32_cache.h	5 Aug 2002 23:53:37 -0000	1.2.2.1
> +++ include/asm-mips/mips32_cache.h	11 Dec 2002 10:00:22 -0000
> @@ -37,45 +37,70 @@
>  
>  static inline void flush_icache_line_indexed(unsigned long addr)
>  {
> -	__asm__ __volatile__(
> -		".set noreorder\n\t"
> -		".set mips3\n\t"
> -		"cache %1, (%0)\n\t"
> -		".set mips0\n\t"
> -		".set reorder"
> -		:
> -		: "r" (addr),
> -		  "i" (Index_Invalidate_I));
> +	unsigned long waystep = icache_size/mips_cpu.icache.ways;
> +	unsigned int way;
> +
> +	for (way = 0; way < mips_cpu.icache.ways; way++)
> +	{
> +		__asm__ __volatile__(
> +			".set noreorder\n\t"
> +			".set mips3\n\t"
> +			"cache %1, (%0)\n\t"
> +			".set mips0\n\t"
> +			".set reorder"
> +			:
> +			: "r" (addr),
> +			"i" (Index_Invalidate_I));
> +		
> +		addr += waystep;
> +	}
>  }
>  
>  static inline void flush_dcache_line_indexed(unsigned long addr)
>  {
> -	__asm__ __volatile__(
> -		".set noreorder\n\t"
> -		".set mips3\n\t"
> -		"cache %1, (%0)\n\t"
> -		".set mips0\n\t"
> -		".set reorder"
> -		:
> -		: "r" (addr),
> -		  "i" (Index_Writeback_Inv_D));
> +	unsigned long waystep = dcache_size/mips_cpu.dcache.ways;
> +	unsigned int way;
> +
> +	for (way = 0; way < mips_cpu.dcache.ways; way++)
> +	{
> +		__asm__ __volatile__(
> +			".set noreorder\n\t"
> +			".set mips3\n\t"
> +			"cache %1, (%0)\n\t"
> +			".set mips0\n\t"
> +			".set reorder"
> +			:
> +			: "r" (addr),
> +			"i" (Index_Writeback_Inv_D));
> +
> +		addr += waystep;
> +	}
>  }
>  
>  static inline void flush_scache_line_indexed(unsigned long addr)
>  {
> -	__asm__ __volatile__(
> -		".set noreorder\n\t"
> -		".set mips3\n\t"
> -		"cache %1, (%0)\n\t"
> -		".set mips0\n\t"
> -		".set reorder"
> -		:
> -		: "r" (addr),
> -		  "i" (Index_Writeback_Inv_SD));
> +	unsigned long waystep = scache_size/mips_cpu.scache.ways;
> +	unsigned int way;
> +
> +	for (way = 0; way < mips_cpu.scache.ways; way++)
> +	{
> +		__asm__ __volatile__(
> +			".set noreorder\n\t"
> +			".set mips3\n\t"
> +			"cache %1, (%0)\n\t"
> +			".set mips0\n\t"
> +			".set reorder"
> +			:
> +			: "r" (addr),
> +			"i" (Index_Writeback_Inv_SD));
> +
> +		addr += waystep;
> +	}
>  }
>  
>  static inline void flush_icache_line(unsigned long addr)
>  {
> +
>  	__asm__ __volatile__(
>  		".set noreorder\n\t"
>  		".set mips3\n\t"
> @@ -210,12 +235,17 @@
>  
>  static inline void blast_dcache_page_indexed(unsigned long page)
>  {
> -	unsigned long start = page;
> -	unsigned long end = (start + PAGE_SIZE);
> -
> -	while(start < end) {
> -		cache_unroll(start,Index_Writeback_Inv_D);
> -		start += dc_lsize;
> +	unsigned long start;
> +	unsigned long end = (page + PAGE_SIZE);
> +	unsigned long waystep = dcache_size/mips_cpu.dcache.ways;
> +	unsigned int way;
> +
> +	for (way = 0; way < mips_cpu.dcache.ways; way++) {
> +		start = page + way*waystep;
> +		while(start < end) {
> +			cache_unroll(start,Index_Writeback_Inv_D);
> +			start += dc_lsize;
> +		}
>  	}
>  }
>  
> @@ -243,12 +273,17 @@
>  
>  static inline void blast_icache_page_indexed(unsigned long page)
>  {
> -	unsigned long start = page;
> -	unsigned long end = (start + PAGE_SIZE);
> -
> -	while(start < end) {
> -		cache_unroll(start,Index_Invalidate_I);
> -		start += ic_lsize;
> +	unsigned long start;
> +	unsigned long end = (page + PAGE_SIZE);
> +	unsigned long waystep = icache_size/mips_cpu.icache.ways;
> +	unsigned int way;
> +
> +	for (way = 0; way < mips_cpu.icache.ways; way++) {
> +		start = page + way*waystep;
> +		while(start < end) {
> +			cache_unroll(start,Index_Invalidate_I);
> +			start += ic_lsize;
> +		}
>  	}
>  }
>  
> @@ -276,12 +311,17 @@
>  
>  static inline void blast_scache_page_indexed(unsigned long page)
>  {
> -	unsigned long start = page;
> -	unsigned long end = page + PAGE_SIZE;
> -
> -	while(start < end) {
> -		cache_unroll(start,Index_Writeback_Inv_SD);
> -		start += sc_lsize;
> +	unsigned long start;
> +	unsigned long end = (page + PAGE_SIZE);
> +	unsigned long waystep = scache_size/mips_cpu.scache.ways;
> +	unsigned int way;
> +
> +	for (way = 0; way < mips_cpu.scache.ways; way++) {
> +		start = page + way*waystep;
> +		while(start < end) {
> +			cache_unroll(start,Index_Writeback_Inv_SD);
> +			start += sc_lsize;
> +		}
>  	}
>  }
>  
> Index: include/asm-mips64/cache.h
> ===================================================================
> RCS file: /home/cvs/linux/include/asm-mips64/cache.h,v
> retrieving revision 1.7.2.3
> diff -u -r1.7.2.3 cache.h
> --- include/asm-mips64/cache.h	24 Jul 2002 16:12:11 -0000	1.7.2.3
> +++ include/asm-mips64/cache.h	11 Dec 2002 10:00:22 -0000
> @@ -27,6 +27,7 @@
>   * Flag definitions
>   */
>  #define MIPS_CACHE_NOT_PRESENT 0x00000001
> +#define MIPS_CACHE_VTAG_CACHE  0x00000002 /* Virtually tagged cache. */
>  
>  #if defined(CONFIG_CPU_R3000) || defined(CONFIG_CPU_R6000) || defined(CONFIG_CPU_TX39XX)
>  #define L1_CACHE_BYTES		16


[-- Attachment #2: off-by-one-flush-cache.patch --]
[-- Type: text/plain, Size: 8041 bytes --]

diff -Nru linux/arch/mips/mm/c-mips32.c.orig linux/arch/mips/mm/c-mips32.c
--- linux/arch/mips/mm/c-mips32.c.orig	Fri May 10 09:12:29 2002
+++ linux/arch/mips/mm/c-mips32.c	Wed Nov 13 11:11:49 2002
@@ -324,12 +324,9 @@
 	} else {
 	        __save_and_cli(flags);
 		a = addr & ~(dc_lsize - 1);
-		end = (addr + size) & ~(dc_lsize - 1);
-		while (1) {
+		end = (addr + size + dc_lsize - 1) & ~(dc_lsize - 1);
+		for (; a != end; a += dc_lsize)
 			flush_dcache_line(a); /* Hit_Writeback_Inv_D */
-			if (a == end) break;
-			a += dc_lsize;
-		}
 		__restore_flags(flags);
 	}
 	bc_wback_inv(addr, size);
@@ -346,12 +343,9 @@
 	}
 
 	a = addr & ~(sc_lsize - 1);
-	end = (addr + size) & ~(sc_lsize - 1);
-	while (1) {
+	end = (addr + size + sc_lsize - 1) & ~(sc_lsize - 1);
+	for (; a != end; a += sc_lsize)
 		flush_scache_line(a);	/* Hit_Writeback_Inv_SD */
-		if (a == end) break;
-		a += sc_lsize;
-	}
 }
 
 static void
@@ -365,12 +359,9 @@
 	} else {
 	        __save_and_cli(flags);
 		a = addr & ~(dc_lsize - 1);
-		end = (addr + size) & ~(dc_lsize - 1);
-		while (1) {
+		end = (addr + size + dc_lsize - 1) & ~(dc_lsize - 1);
+		for (; a != end; a += dc_lsize)
 			flush_dcache_line(a); /* Hit_Writeback_Inv_D */
-			if (a == end) break;
-			a += dc_lsize;
-		}
 		__restore_flags(flags);
 	}
 
@@ -388,12 +379,9 @@
 	}
 
 	a = addr & ~(sc_lsize - 1);
-	end = (addr + size) & ~(sc_lsize - 1);
-	while (1) {
+	end = (addr + size + sc_lsize - 1) & ~(sc_lsize - 1);
+	for (; a != end; a += sc_lsize)
 		flush_scache_line(a); /* Hit_Writeback_Inv_SD */
-		if (a == end) break;
-		a += sc_lsize;
-	}
 }
 
 static void
diff -Nru linux/arch/mips/mm/c-r4k.c.orig linux/arch/mips/mm/c-r4k.c
--- linux/arch/mips/mm/c-r4k.c.orig	Fri May 10 09:12:29 2002
+++ linux/arch/mips/mm/c-r4k.c	Wed Nov 13 11:15:47 2002
@@ -1167,12 +1167,9 @@
 		*(volatile unsigned long *)KSEG1;
 
 		a = addr & ~(dc_lsize - 1);
-		end = (addr + size) & ~(dc_lsize - 1);
-		while (1) {
+		end = (addr + size + dc_lsize - 1) & ~(dc_lsize - 1);
+		for (; a != end; a += dc_lsize)
 			flush_dcache_line(a); /* Hit_Writeback_Inv_D */
-			if (a == end) break;
-			a += dc_lsize;
-		}
 		__restore_flags(flags);
 	}
 	bc_wback_inv(addr, size);
@@ -1189,12 +1186,9 @@
 	}
 
 	a = addr & ~(sc_lsize - 1);
-	end = (addr + size) & ~(sc_lsize - 1);
-	while (1) {
+	end = (addr + size + sc_lsize - 1) & ~(sc_lsize - 1);
+	for (; a != end; a += sc_lsize)
 		flush_scache_line(a);	/* Hit_Writeback_Inv_SD */
-		if (a == end) break;
-		a += sc_lsize;
-	}
 }
 
 static void
@@ -1211,12 +1205,9 @@
 		*(volatile unsigned long *)KSEG1;
 
 		a = addr & ~(dc_lsize - 1);
-		end = (addr + size) & ~(dc_lsize - 1);
-		while (1) {
+		end = (addr + size + dc_lsize - 1) & ~(dc_lsize - 1);
+		for (; a != end; a += dc_lsize)
 			flush_dcache_line(a); /* Hit_Writeback_Inv_D */
-			if (a == end) break;
-			a += dc_lsize;
-		}
 		__restore_flags(flags);
 	}
 
@@ -1234,12 +1225,9 @@
 	}
 
 	a = addr & ~(sc_lsize - 1);
-	end = (addr + size) & ~(sc_lsize - 1);
-	while (1) {
+	end = (addr + size + sc_lsize - 1) & ~(sc_lsize - 1);
+	for (; a != end; a += sc_lsize)
 		flush_scache_line(a); /* Hit_Writeback_Inv_SD */
-		if (a == end) break;
-		a += sc_lsize;
-	}
 }
 
 static void
diff -Nru linux/arch/mips/mm/c-r5432.c.orig linux/arch/mips/mm/c-r5432.c
--- linux/arch/mips/mm/c-r5432.c.orig	Fri May 10 09:12:29 2002
+++ linux/arch/mips/mm/c-r5432.c	Wed Nov 13 11:13:41 2002
@@ -384,12 +384,9 @@
 		flush_cache_all();
 	} else {
 		a = addr & ~(dc_lsize - 1);
-		end = (addr + size) & ~(dc_lsize - 1);
-		while (1) {
+		end = (addr + size + dc_lsize - 1) & ~(dc_lsize - 1);
+		for (; a != end; a += dc_lsize)
 			flush_dcache_line(a); /* Hit_Writeback_Inv_D */
-			if (a == end) break;
-			a += dc_lsize;
-		}
 	}
 	bc_wback_inv(addr, size);
 }
@@ -403,12 +400,9 @@
 		flush_cache_all();
 	} else {
 		a = addr & ~(dc_lsize - 1);
-		end = (addr + size) & ~(dc_lsize - 1);
-		while (1) {
+		end = (addr + size + dc_lsize - 1) & ~(dc_lsize - 1);
+		for (; a != end; a += dc_lsize)
 			flush_dcache_line(a); /* Hit_Writeback_Inv_D */
-			if (a == end) break;
-			a += dc_lsize;
-		}
 	}
 
 	bc_inv(addr, size);
diff -Nru linux/arch/mips/mm/c-rm7k.c.orig linux/arch/mips/mm/c-rm7k.c
--- linux/arch/mips/mm/c-rm7k.c.orig	Fri May 10 09:12:29 2002
+++ linux/arch/mips/mm/c-rm7k.c	Wed Nov 13 11:14:14 2002
@@ -130,25 +130,20 @@
 	unsigned long end, a;
 
 	a = addr & ~(sc_lsize - 1);
-	end = (addr + size) & ~(sc_lsize - 1);
-	while (1) {
+	end = (addr + size + sc_lsize - 1) & ~(sc_lsize - 1);
+	for (; a != end; a += sc_lsize) {
 		flush_dcache_line(a);	/* Hit_Writeback_Inv_D */
 		flush_icache_line(a);	/* Hit_Invalidate_I */
 		flush_scache_line(a);	/* Hit_Writeback_Inv_SD */
-		if (a == end) break;
-		a += sc_lsize;
 	}
 
 	if (!rm7k_tcache_enabled) 
 		return;
 
 	a = addr & ~(tc_pagesize - 1);
-	end = (addr + size) & ~(tc_pagesize - 1);
-	while(1) {
+	end = (addr + size + tc_pagesize - 1) & ~(tc_pagesize - 1);
+	for (; a != end; a += tc_pagesize) 
 		invalidate_tcache_page(a);	/* Page_Invalidate_T */
-		if (a == end) break;
-		a += tc_pagesize;
-	}
 }
 	       
 static void
@@ -157,13 +152,11 @@
 	unsigned long end, a;
 
 	a = addr & ~(sc_lsize - 1);
-	end = (addr + size) & ~(sc_lsize - 1);
-	while (1) {
+	end = (addr + size + sc_lsize - 1) & ~(sc_lsize - 1);
+	for (; a != end; a += sc_lsize) {
 		invalidate_dcache_line(a);	/* Hit_Invalidate_D */
 		flush_icache_line(a);		/* Hit_Invalidate_I */
 		invalidate_scache_line(a);	/* Hit_Invalidate_SD */
-		if (a == end) break;
-		a += sc_lsize;
 	}
 
 	if (!rm7k_tcache_enabled) 
@@ -171,11 +164,8 @@
 
 	a = addr & ~(tc_pagesize - 1);
 	end = (addr + size) & ~(tc_pagesize - 1);
-	while(1) {
+	for (; a != end; a += tc_pagesize) 
 		invalidate_tcache_page(a);	/* Page_Invalidate_T */
-		if (a == end) break;
-		a += tc_pagesize;
-	}
 }
 
 static void
diff -Nru linux/arch/mips/mm/c-tx39.c.orig linux/arch/mips/mm/c-tx39.c
--- linux/arch/mips/mm/c-tx39.c.orig	Fri May 10 09:12:29 2002
+++ linux/arch/mips/mm/c-tx39.c	Wed Nov 13 11:09:01 2002
@@ -66,12 +66,9 @@
 	wbflush();
 
 	a = addr & ~(dcache_lsize - 1);
-	end = (addr + size) & ~(dcache_lsize - 1);
-	while (1) {
+	end = (addr + size + dcache_lsize - 1) & ~(dcache_lsize - 1);
+	for (; a != end; a += dcache_lsize)
 		invalidate_dcache_line(a); /* Hit_Invalidate_D */
-		if (a == end) break;
-		a += dcache_lsize;
-	}
 }
 
 
@@ -199,12 +196,9 @@
 		flush_cache_all();
 	} else {
 		a = addr & ~(dcache_lsize - 1);
-		end = (addr + size) & ~(dcache_lsize - 1);
-		while (1) {
+		end = (addr + size + dcache_lsize - 1) & ~(dcache_lsize - 1);
+		for (; a != end; a += dcache_lsize)
 			flush_dcache_line(a); /* Hit_Writeback_Inv_D */
-			if (a == end) break;
-			a += dcache_lsize;
-		}
 	}
 }
 
@@ -216,12 +210,9 @@
 		flush_cache_all();
 	} else {
 		a = addr & ~(dcache_lsize - 1);
-		end = (addr + size) & ~(dcache_lsize - 1);
-		while (1) {
+		end = (addr + size + dcache_lsize - 1) & ~(dcache_lsize - 1);
+		for (; a != end; a += dcache_lsize)
 			invalidate_dcache_line(a); /* Hit_Invalidate_D */
-			if (a == end) break;
-			a += dcache_lsize;
-		}
 	}
 }
 
diff -Nru linux/arch/mips/mm/c-tx49.c.orig linux/arch/mips/mm/c-tx49.c
--- linux/arch/mips/mm/c-tx49.c.orig	Mon Oct  7 18:17:40 2002
+++ linux/arch/mips/mm/c-tx49.c	Wed Nov 13 11:10:28 2002
@@ -310,12 +310,9 @@
 		__save_and_cli(flags);
 
 		a = addr & ~(dc_lsize - 1);
-		end = (addr + size) & ~(dc_lsize - 1);
-		while (1) {
+		end = (addr + size + dc_lsize - 1) & ~(dc_lsize - 1);
+		for (; a != end; a += dc_lsize) 
 			flush_dcache_line(a); /* Hit_Writeback_Inv_D */
-			if (a == end) break;
-			a += dc_lsize;
-		}
 		__restore_flags(flags);
 	}
 }
@@ -332,12 +329,9 @@
 		__save_and_cli(flags);
 
 		a = addr & ~(dc_lsize - 1);
-		end = (addr + size) & ~(dc_lsize - 1);
-		while (1) {
+		end = (addr + size + dc_lsize - 1) & ~(dc_lsize - 1);
+		for (; a != end; a += dc_lsize) 
 			flush_dcache_line(a); /* Hit_Writeback_Inv_D */
-			if (a == end) break;
-			a += dc_lsize;
-		}
 		__restore_flags(flags);
 	}
 }

^ permalink raw reply

* Re: Is this going to be true ?
From: Serge Kuznetsov @ 2002-12-11 17:12 UTC (permalink / raw)
  To: Joseph D. Wagner, linux-kernel
In-Reply-To: <001801c2a0a9$02613f40$2e863841@joe>

I totaly agree with you.

But why do you think Microsoft will come back to *nix lane?
AFAIK, they closed their Xenix project back in 80s.
Do you think they will resurrect it?

All the best!
Serge.

^ permalink raw reply

* Re: Malta board patch
From: Jun Sun @ 2002-12-11 17:04 UTC (permalink / raw)
  To: Carsten Langgaard; +Cc: Ralf Baechle, linux-mips, jsun
In-Reply-To: <3DF6F54C.64858797@mips.com>


A couple of nit-picking points ...

On Wed, Dec 11, 2002 at 09:20:28AM +0100, Carsten Langgaard wrote:
> Index: arch/mips/mips-boards/generic/pci.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/mips-boards/generic/pci.c,v
> retrieving revision 1.5.2.4
> diff -u -r1.5.2.4 pci.c
> --- arch/mips/mips-boards/generic/pci.c	28 Sep 2002 18:28:44 -0000	1.5.2.4
> +++ arch/mips/mips-boards/generic/pci.c	11 Dec 2002 08:11:56 -0000
> @@ -405,6 +405,12 @@
>  			".set\treorder");
>  
>  		irq = *(volatile u32 *)(KSEG1ADDR(BONITO_PCICFG_BASE));
> +		__asm__ __volatile__(
> +			".set\tnoreorder\n\t"
> +			".set\tnoat\n\t"
> +			"sync\n\t"
> +			".set\tat\n\t"
> +			".set\treorder");
>  		irq &= 0xff;
>  		BONITO_PCIMAP_CFG = 0;
>  		break;

Would a higher level macro such as __sync or fast_mb be better here?

> Index: arch/mips/mips-boards/malta/malta_int.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/mips-boards/malta/malta_int.c,v
> retrieving revision 1.8.2.6
> diff -u -r1.8.2.6 malta_int.c
> --- arch/mips/mips-boards/malta/malta_int.c	5 Aug 2002 23:53:34 -0000	1.8.2.6
> +++ arch/mips/mips-boards/malta/malta_int.c	11 Dec 2002 08:11:57 -0000
> @@ -91,6 +91,9 @@
>  {
>          unsigned int data,datahi;
>  
> +	/* Mask out corehi interrupt. */
> +	clear_c0_status(IE_IRQ3);
> +
>          printk("CoreHI interrupt, shouldn't happen, so we die here!!!\n");
>          printk("epc   : %08lx\nStatus: %08lx\nCause : %08lx\nbadVaddr : %08lx\n"
>  , regs->cp0_epc, regs->cp0_status, regs->cp0_cause, regs->cp0_badvaddr);
> @@ -125,7 +128,6 @@
>  
>          /* We die here*/
>          die("CoreHi interrupt", regs);
> -        while (1) ;
>  }
>  
>  void __init init_IRQ(void)

I think corehi interrupt should be blocked from the beginning.  I seem to 
remember a board errata itme that recommands not using it.

Jun

^ permalink raw reply

* RE: [Dri-devel] Re: 2.4.20 AGP for I845 wrong ?
From: Margit Schubert-While @ 2002-12-11 17:12 UTC (permalink / raw)
  To: linux-kernel


  >                intel_830mp_setup },
 > Surely this is wrong or ?
 > Should be "intel_845_setup", I think.

Well, I don't know. With the 830mp_setup, I get
  (WW) RADEON(0): Bad V_BIOS checksum
in the X log (hard) and a few other sporadic effects that I cannot nail down.
With the intel_845_setup, everything appears to be OK.
Board is a D845PESVL with Radeon 7500.
As the D845G have onboard VGA and the PE not, I would suspect
that maybe a different init sequence is necessary.

Margit 


^ permalink raw reply

* Re: Completely discharging LION batteries
From: Frank Mehnert @ 2002-12-11 17:03 UTC (permalink / raw)
  To: acpi-devel-pyega4qmqnRoyOMFzWx49A
In-Reply-To: <B900970C7DD9474C972986EB3EC7C58F04EA7D-PWLG29+z7hEKeIAE67mlpo2P0GrZ+RbP@public.gmane.org>

On Wednesday 11 December 2002 10:26, Herbert Nachtnebel wrote:

> > I'm using Linux 2.4.20 together with the acpi patches
> > 20021205-2.4.20 on a
> > Thinkpad T20. If I use two batteries (the builtin and a
> > second in the Ultra-
> > Bay), the second battery first gets discharged _completely_
> > and after that the internal battery is used.
>
> That's normal, but yes it is not the smartest idea to do.

What I'm wondering about is that in the Windows 2000 Help of
the Thinkpad Laptop, IBM advises that it is better to discharge
the battery sometimes completely to refresh the full capacity
at least partly. That advise is completely the opposite of what
I've seen. But it could be an mistake in their documentation or
they could target NiMH batteries.

It is possible that there are some mechanisms that Windows knows
about and uses but Linux not?

Frank
-- 
Frank Mehnert
## Dept. of Computer Science, Dresden University of Technology, Germany ##
## E-Mail: fm3-IG//nw+yl+iQIjdd1DhZXWfrygkm6VTR@public.gmane.org    http://os.inf.tu-dresden.de/~fm3 ##


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

^ permalink raw reply

* Re: how do you successful compile or install 2.5.50?
From: bill davidsen @ 2002-12-11 17:09 UTC (permalink / raw)
  To: linux-kernel
In-Reply-To: <3DF5EC8E.9050603@centurytel.net>

In article <3DF5EC8E.9050603@centurytel.net>,
eric lin  <fsshl@centurytel.net> wrote:

|    I also download from kernel.org 2.5.50, it have error at make modules 
| or make install


|    highly appreciate your experience on compile or install new kernel 
| especailly experiamental kernel


I highly commend disabling module support and building everything
directly in the kernel. If you get this working you can visit the list
archives and read about modules after 2.5.47, and decide if you really
need modules in 2.5 kernels, and what to change if you do.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

^ permalink raw reply

* Typo in reiserfsck
From: Julian Hall @ 2002-12-11 17:00 UTC (permalink / raw)
  To: reiserfs-list

While rebuilding my file system's tree today, I noticed this message:

####### Pass 1 #######
Looking for allocable blocks .. fininshed

And a quick comment: the program doesn't really give much indication of 
how long rebuilding the tree will take.  When I started I certainly had 
no idea that it would take over 4 hours (it hasn't finished yet, but I 
think its getting close now...) to complete, and if I knew I would 
probably have left the operation until I had more time available. 
 Read-only access to the file system would have been useful, but 
unfortunately that option was not left open to me by the time I realised 
that the operation would take so long...



^ permalink raw reply

* Re: Is this going to be true ?
From: Serge Kuznetsov @ 2002-12-11 17:06 UTC (permalink / raw)
  To: Joseph D. Wagner, linux-kernel
In-Reply-To: <001801c2a0a9$02613f40$2e863841@joe>

What I can say is what Linux kernel development outperforms
M$-Windows development in timeline by many parameters.

That what I know for sure.

For this moment M$ have only nice and comfy GUI, but I hope it will change very soon. 


All the Best!

^ permalink raw reply

* Re: watch exception only for kseg0 addresses..?
From: Daniel Jacobowitz @ 2002-12-11 16:58 UTC (permalink / raw)
  To: Maciej W. Rozycki; +Cc: Ralf Baechle, linux-mips
In-Reply-To: <Pine.GSO.3.96.1021204182756.29982G-100000@delta.ds2.pg.gda.pl>

On Wed, Dec 04, 2002 at 06:54:02PM +0100, Maciej W. Rozycki wrote:
> On Wed, 4 Dec 2002, Daniel Jacobowitz wrote:
> 
> > Sorry, by "not handy" I meant I didn't have the manuals available :)
> 
>  'http://www.mips.com/Documentation/R4400_Uman_book_Ed2.pdf' or see under
> "Publications"/"R4000...".  There are other sources of the book available,
> e.g. somewhere within SGI web pages.  R10k implements a single watchpoint
> this way, too. 
> 
> > >  What do you think?
> > 
> > You don't reveal to userland what size watchpoints are available - i.e.
> > how large a watchpoint can be.  Does the mask match the hardware
> > implementation, and what are the restrictions on it?
> 
>  For that you set up a disabled watchpoint with a mask set to all ones (or
> the range you are interested in).  Then when you retrieve it, you may see
> which bits stayed at ones.  Similarly you may check for hardwired
> don't-cares by using a mask with all zeroes.  The mask may differ for each
> watchpoint, e.g. for R4650 it's different for IWatch and DWatch, so you
> really want to have a per-watchpoint setting.  Also the MIPS32/64 ISA
> specification implies a mask need not be contiguous. 
> 
>  Similarly you may check for access types permitted, by enabling all of
> them (or ones you are interested in) and seeing which ones remained
> enabled.  Per-watchpoint, again. 
> 
>  I'd prefer not to overdesign the API leaving as much information as
> possible passed as is.  This way userland gets more control over what's
> available.

That way we expose more of the hardware to userland; and the thing
that's most important to me is that GDB not have to know if it's on a
MIPS32 or an R4650 when determining how watchpoints work. 
IWatch/DWatch are two particular watchpoints or distinguished by access
type?  I.E. what would GDB need to know to know which it is setting?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

^ permalink raw reply

* Re: [parisc-linux] another kernel compilation error
From: Thibaut VARENE @ 2002-12-11 16:57 UTC (permalink / raw)
  To: Tim Kemna; +Cc: parisc-linux
In-Reply-To: <006e01c2a11c$71745200$4fe85982@kabel.utwente.nl>

Le mercredi, 11 d=E9c 2002, =E0 14:51 Europe/Paris, Tim Kemna a =E9crit =
:
>
> drivers/char/char.o: In function `hp_diva_check':
> drivers/char/char.o(.text.hp_diva_check+0x60): undefined reference to
> `rs_interr
> upt'
> make: *** [vmlinux] Error 1
>
Weird I'm also having an error on char.o:

         -o vmlinux
drivers/char/char.o: In function `.L1757':
drivers/char/char.o(.text.vt_ioctl+0x51c): undefined reference to=20
`key_maps'
drivers/char/char.o: In function `handle_scancode':
drivers/char/char.o(.text.handle_scancode+0x25c): undefined reference=20
to `key_maps'
drivers/char/char.o: In function `handle_diacr':
drivers/char/char.o(.text.handle_diacr+0x1c): undefined reference to=20
`accent_table_size'
drivers/char/char.o: In function `do_fn':
drivers/char/char.o(.text.do_fn+0x8): undefined reference to=20
`func_table'
drivers/char/char.o: In function `compute_shiftstate':
drivers/char/char.o(.text.compute_shiftstate+0x90): undefined reference=20=

to `key_maps'
drivers/char/char.o: In function `do_slock':
drivers/char/char.o(.text.do_slock+0x74): undefined reference to=20
`key_maps'
make: *** [vmlinux] Error 1

same kernel; 64bit UP for a B2600 in graphic mode (SuckyIO/STIcon...)

I'm gonna investigate soon...
Mail me for .config...=

^ permalink raw reply

* Re: PPTP+NAT+MASQ anyone?
From: Roy Sigurd Karlsbakk @ 2002-12-11 16:54 UTC (permalink / raw)
  To: Martin Josefsson; +Cc: Netfilter mailinglist
In-Reply-To: <1039624902.20562.91.camel@tux>

On Wednesday 11 December 2002 17:41, Martin Josefsson wrote:
> On Wed, 2002-12-11 at 17:01, Roy Sigurd Karlsbakk wrote:
> > seems like newnat-udp-helper.patch
> > [root@fw linux]# patch -p1 <
> > ../netfilter/patch-o-matic/pending/newnat-udp-helper.patch
> > patching file include/linux/netfilter_ipv4/ip_nat_helper.h
> > Hunk #1 succeeded at 36 (offset -14 lines).
> > patching file net/ipv4/netfilter/ip_nat_helper.c
> > Hunk #1 FAILED at 8.
> > Hunk #2 succeeded at 18 (offset -7 lines).
> > Hunk #3 succeeded at 53 (offset -2 lines).
> > Hunk #4 succeeded at 75 (offset -7 lines).
> > Hunk #5 succeeded at 174 (offset -2 lines).
> > Hunk #6 succeeded at 203 with fuzz 2 (offset -7 lines).
> > 1 out of 6 hunks FAILED -- saving rejects to file
> > net/ipv4/netfilter/ip_nat_helper.c.rej
> > patching file net/ipv4/netfilter/ip_nat_standalone.c
> > Hunk #1 FAILED at 358.
> > 1 out of 1 hunk FAILED -- saving rejects to file
> > net/ipv4/netfilter/ip_nat_standalone.c.rej
>
> This patch applies fine here after applying the other submitted patches
> first.

then what is wrong?????????? The kernels I've tried patching, is downloaded 
from kernel.org, and everything else works, except netfilter/p-o-m
-- 
Roy Sigurd Karlsbakk, Datavaktmester
ProntoTV AS - http://www.pronto.tv/
Tel: +47 9801 3356

Computers are like air conditioners.
They stop working when you open Windows.



^ permalink raw reply

* Re: [parisc-linux] another kernel compilation error
From: Paul Bame @ 2002-12-11 16:54 UTC (permalink / raw)
  To: Tim Kemna; +Cc: parisc-linux
In-Reply-To: <006e01c2a11c$71745200$4fe85982@kabel.utwente.nl>

> drivers/char/char.o: In function `hp_diva_check':
> drivers/char/char.o(.text.hp_diva_check+0x60): undefined reference to
> `rs_interrupt'
> make: *** [vmlinux] Error 1
> 
> What am I doing wrong?

Probably nothing but I did :-)  My Diva changes currently require
CONFIG_SERIAL_SHARE_IRQ to be set -- need to fix that.

        -P

^ permalink raw reply

* Re: [2.4]ALi M5451 sound hangs on init; workaround
From: Fedor Karpelevitch @ 2002-12-11 16:52 UTC (permalink / raw)
  To: Alan Cox; +Cc: lkml, Vicente Aguilar, alsa-devel, Debian-Laptops
In-Reply-To: <1039625298.18087.61.camel@irongate.swansea.linux.org.uk>

> > I have ALi M5451 souncard in my laptop (Compaq Presario 900z for
> > those searching) and it hangs the machine with any kernel I tried
> > (currently 2.4.20-ac1 + hirofumi patch). I traced it down to the
> > line where it hangs - that is drivers/sound/trident.c:3379 which
> > says: pci_write_config_byte(pci_dev, 0xB8, ~temp);
>
> Looking at the docs it looks like the code Matt Wu added may have
> been meant to do
>
> 	pci_read_config_byte(pci_dev, 0x59, temp)
> 	temp &= ~0x80
> 	pci_write...
>

just to make sure I got it right, is the following what you suggest? 
(pseudo-patch):

--------
static int ali_close_multi_channels(void)
{
        char temp = 0;
        struct pci_dev *pci_dev = NULL;

	pci_dev =pci_find_device(PCI_VENDOR_ID_AL,PCI_DEVICE_ID_AL_M1533,
		pci_dev);
        if (pci_dev == NULL)
                return -1;
-       temp = 0x80;
+	pci_read_config_byte(pci_dev, 0x59, temp);
+      temp &= ~0x80;
-       pci_write_config_byte(pci_dev, 0x59, ~temp);
+	pci_write_config_byte(pci_dev, 0x59, temp);

        pci_dev = pci_find_device(PCI_VENDOR_ID_AL,
		PCI_DEVICE_ID_AL_M7101, pci_dev);
        if (pci_dev == NULL)
                return -1;

-       temp = 0x20;
+	pci_read_config_byte(pci_dev, 0xB8, temp);
+	temp &= ~0x20
-       pci_write_config_byte(pci_dev, 0xB8, ~temp);  // the line I 
+	pci_write_config_byte(pci_dev, 0xB8, temp);  //commented out

        return 0;
}
---------------------
I'll try it and will tell you what the result is. Anyway, what are 
those commands doing, i.e. what am I loosing when I comment it out? 
Is there some specific functionality I should test to see the result 
of these changes?

> and similarly for the other port
>
> (Ditto with fixing setup_multi_cannnels)
>
> Does it work sanely with those fixd ?


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

^ permalink raw reply

* Linux on LSI SC2000
From: Simon Wood @ 2002-12-11 16:51 UTC (permalink / raw)
  To: linux-mips

Hi all,
Does anyone have any information on the Linux port to the LSI SC2000 (Tiny
Mips core). There is a page on AstonLinux's web site but I can't find any
source around the net....

http://www.astonlinux.com/solution/LSI.htm

Hopefully there is something I can make use of in my hacking around

Thanks,
Simon Wood
(in a personal capacity).

^ permalink raw reply

* Re: GDB patch
From: Daniel Jacobowitz @ 2002-12-11 16:52 UTC (permalink / raw)
  To: Nigel Stephens; +Cc: Carsten Langgaard, Ralf Baechle, linux-mips
In-Reply-To: <3DF6514E.8040100@mips.com>

On Tue, Dec 10, 2002 at 08:40:46PM +0000, Nigel Stephens wrote:
> I thought the Linux community prided itself on inventing new and 
> "non-standard" extensions to the toolchain  ;-). But yes, we should try 
> to avoid incompatible changes. As part of MIPS we will hopefully have 
> the resources to interface with the rest of the GNU community, and argue 
> for the inclusion of our patches in the CVS trees.

Actually, we've been trying to pride ourselves on not doing so :)

> Yup. SDE-MIPS 1.1 shipped in 1992. :-)

Wow...

> Yeah, that's why we dropped 'R' in our more recent gdb ports, but I 
> wasn't aware of the new use of 'r' - I'll check out that page. 

I think it's an old use, actually.  I'm not sure where it was used
though.

> Certainly 'p' is the logical inverse of 'P', so we'll change our gdb 
> remote stub to use that. So how about accepting Carsten's change, with 
> the 'R' case removed, and 'r' changed to 'p'?

Can't do it.  I strongly suspect that it will render the stub unusable
with current versions of FSF GDB.  Your tools add an explicit size to
the packet and the community tools do not; so when they probe for and
discover the P packet, they will probably try to use it and get
confused.  That's why I'd like to discuss this on the GDB list first.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

^ permalink raw reply

* Re: IDE module problem
From: Jun Sun @ 2002-12-11 16:49 UTC (permalink / raw)
  To: Maciej W. Rozycki; +Cc: linux-mips, jsun
In-Reply-To: <Pine.GSO.3.96.1021211141709.22157A-100000@delta.ds2.pg.gda.pl>

On Wed, Dec 11, 2002 at 02:21:48PM +0100, Maciej W. Rozycki wrote:
> On Mon, 9 Dec 2002, Jun Sun wrote:
> 
> > If you configure IDE support as a module (CONFIG_IDE), you
> > will soon find that ide-std.o and ide-no.o are missing.
> > This is because arch/mips/lib/Makefile says:
> > 
> > obj-$(CONFIG_IDE)               += ide-std.o ide-no.o
> [...]
> > 3) use some smart trick in Makefile so that we include those
> > two files only if CONFIG_IDE is 'y' or 'm'.  (How?)
> 
>  obj-$(CONFIG_IDE_MODULE)
>

This does not work.  Apparently, CONFIG_IDE_MODULE is not created 
for makefile part.

Jun

^ permalink raw reply

* Re: [2.4]ALi M5451 sound hangs on init; workaround
From: Fedor Karpelevitch @ 2002-12-11 16:52 UTC (permalink / raw)
  To: Alan Cox; +Cc: lkml, Vicente Aguilar, alsa-devel, Debian-Laptops
In-Reply-To: <1039625298.18087.61.camel@irongate.swansea.linux.org.uk>

> > I have ALi M5451 souncard in my laptop (Compaq Presario 900z for
> > those searching) and it hangs the machine with any kernel I tried
> > (currently 2.4.20-ac1 + hirofumi patch). I traced it down to the
> > line where it hangs - that is drivers/sound/trident.c:3379 which
> > says: pci_write_config_byte(pci_dev, 0xB8, ~temp);
>
> Looking at the docs it looks like the code Matt Wu added may have
> been meant to do
>
> 	pci_read_config_byte(pci_dev, 0x59, temp)
> 	temp &= ~0x80
> 	pci_write...
>

just to make sure I got it right, is the following what you suggest? 
(pseudo-patch):

--------
static int ali_close_multi_channels(void)
{
        char temp = 0;
        struct pci_dev *pci_dev = NULL;

	pci_dev =pci_find_device(PCI_VENDOR_ID_AL,PCI_DEVICE_ID_AL_M1533,
		pci_dev);
        if (pci_dev == NULL)
                return -1;
-       temp = 0x80;
+	pci_read_config_byte(pci_dev, 0x59, temp);
+      temp &= ~0x80;
-       pci_write_config_byte(pci_dev, 0x59, ~temp);
+	pci_write_config_byte(pci_dev, 0x59, temp);

        pci_dev = pci_find_device(PCI_VENDOR_ID_AL,
		PCI_DEVICE_ID_AL_M7101, pci_dev);
        if (pci_dev == NULL)
                return -1;

-       temp = 0x20;
+	pci_read_config_byte(pci_dev, 0xB8, temp);
+	temp &= ~0x20
-       pci_write_config_byte(pci_dev, 0xB8, ~temp);  // the line I 
+	pci_write_config_byte(pci_dev, 0xB8, temp);  //commented out

        return 0;
}
---------------------
I'll try it and will tell you what the result is. Anyway, what are 
those commands doing, i.e. what am I loosing when I comment it out? 
Is there some specific functionality I should test to see the result 
of these changes?

> and similarly for the other port
>
> (Ditto with fixing setup_multi_cannnels)
>
> Does it work sanely with those fixd ?

^ permalink raw reply

* Re: [lkcd-devel] Re: [PATCH] Notifier for significant events on i386
From: Stephen Hemminger @ 2002-12-11 16:56 UTC (permalink / raw)
  To: vamsi
  Cc: William Lee Irwin III, Kernel List, lkcd-devel, ak, cminyard,
	vamsi_krishna
In-Reply-To: <20021211171337.A17600@in.ibm.com>

On Wed, 2002-12-11 at 03:43, Vamsi Krishna S . wrote:
> On Wed, Dec 11, 2002 at 03:16:39AM -0800, William Lee Irwin III wrote:
> > On Wed, Dec 11, 2002 at 04:51:53PM +0530, Vamsi Krishna S . wrote:
> > > <snip>
> > >
> > > I am considering using a RCU-based list for notifier chains.
> > > Corey has done some work on these lines to add NMI notifier
> > > chain, I think it should be generalised on for all notifiers.
> > 
> > A coherent explanation of how notifier locking is supposed to work
> > would be wonderful to have. I'd like to register notifiers but am
> > pig ignorant of how to lock my structures down to work with it.
> > 
> Unless I am missing something, notifiers have always been racy. 
> No amount of locking you do in individual modules to prevent
> races will help as the notifier chain is walked inside 
> notifier_call_chain() in kernel/sys.c. One would need to
> add some form of locking there (*) so that users of notifier
> chains need not worry about races/locking at all.
> 
> (*) converting the notifier chain to an RCU-based list guarentees
> to modules using the notifier chains that their handlers will
> not be called once the handler is unregistered.
> 
> > Bill
> Vamsi.

There should be a register/unregister interface that uses RCU.  That
makes sense.  This assumes that this is an uncommon thing that happens
at init/load and unload. The notifier callback's better not change
themselves! Especially, since they get called when the system may be in
a unstable state like in a panic or other error handling.

-- 
Stephen Hemminger <shemminger@osdl.org>
Open Source Devlopment Lab


^ permalink raw reply

* Re: [2.4]ALi M5451 sound hangs on init; workaround
From: Alan Cox @ 2002-12-11 16:48 UTC (permalink / raw)
  To: Fedor Karpelevitch; +Cc: lkml, Vicente Aguilar, alsa-devel, Debian-Laptops
In-Reply-To: <200212110715.20617.fedor@apache.org>

On Wed, 2002-12-11 at 15:15, Fedor Karpelevitch wrote:
> I have ALi M5451 souncard in my laptop (Compaq Presario 900z for those 
> searching) and it hangs the machine with any kernel I tried 
> (currently 2.4.20-ac1 + hirofumi patch). I traced it down to the line 
> where it hangs - that is drivers/sound/trident.c:3379 which says:
> pci_write_config_byte(pci_dev, 0xB8, ~temp);

Looking at the docs it looks like the code Matt Wu added may have 
been meant to do

	pci_read_config_byte(pci_dev, 0x59, temp)
	temp &= ~0x80
	pci_write...

and similarly for the other port

(Ditto with fixing setup_multi_cannnels)

Does it work sanely with those fixd ?

^ permalink raw reply

* Re: IBM spamms me with error messages
From: Richard A Nelson @ 2002-12-11 16:53 UTC (permalink / raw)
  To: kernel list
In-Reply-To: <200212110258.gBB2wXCb025160@badlands.lexington.ibm.com>

On Tue, 10 Dec 2002, David S. Miller wrote:

> Pavel, you're not the only person seeing this, and you're
> certainly not the only one sending emails to IBM's postmasters
> asking them to fix this.
>
> The lack of any response or actions by IBM's postmasters is certainly
> quite disturbing.  Is there that much red tape at the company? :-)

At times, yes :(

I've not yet traced this fully, but it looks like it might be the RSCS
gateway in action - I'll try to get the relevant folks to look at it.

Unfortunately, there are several groups involved - AT&T handles the
exterior gateway servers, another group handles the Lotus gateways,
and I beleive a third does the ip->rscs(mainframe) gateway.

-- 
Rick Nelson
Now I know someone out there is going to claim, "Well then, UNIX is intuitive,
because you only need to learn 5000 commands, and then everything else follows
from that! Har har har!"
	-- Andy Bates on "intuitive interfaces", slightly defending Macs

^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.