Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history 
yaml
---
r: 29441
b: refs/heads/master
c: 200d5a7
h: refs/heads/master
i:
  29439: d7a8cd6
v: v3
  • Loading branch information
Tejun Heo authored and Jeff Garzik committed Mar 22, 2006
1 parent 897fac2 commit c35db2b
Show file tree
Hide file tree
Showing 5,337 changed files with 195,696 additions and 266,318 deletions.
The diff you're trying to view is too large. We only load the first 3000 changed files.
2 changes: 1 addition & 1 deletion [refs]
View file
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
---
refs/heads/master: efa6e7e9d40fe01406d889a5bed62f2e0da49bff
refs/heads/master: 200d5a7684cc49ef4be40e832daf3f217e70dfbb
1 change: 0 additions & 1 deletion trunk/.gitignore
View file
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,6 @@
#
# Top-level generic files
#
tags
vmlinux*
System.map
Module.symvers
Expand Down
36 changes: 19 additions & 17 deletions trunk/CREDITS
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1127,10 +1127,8 @@ S: Carnegie, Pennsylvania 15106-4304
S: USA

N: Philip Gladstone
E: philip@gladstonefamily.net
E: philip@raptor.com
D: Kernel / timekeeping stuff
S: Carlisle, MA 01741
S: USA

N: Jan-Benedict Glaw
E: jbglaw@lug-owl.de
Expand Down Expand Up @@ -1194,9 +1192,15 @@ S: Brecksville, OH 44141-1334
S: USA

N: Tristan Greaves
E: tristan@extricate.org
W: http://www.extricate.org/
E: Tristan.Greaves@icl.com
E: tmg296@ecs.soton.ac.uk
W: http://www.ecs.soton.ac.uk/~tmg296
D: Miscellaneous ipv4 sysctl patches
S: 15 Little Mead
S: Denmead
S: Hampshire
S: PO7 6HS
S: United Kingdom

N: Michael A. Griffith
E: grif@cs.ucr.edu
Expand Down Expand Up @@ -2003,14 +2007,13 @@ S: University of Stuttgart, Germany and
S: Ecole Nationale Superieure des Telecommunications, Paris

N: Jamie Lokier
E: jamie@shareable.org
W: http://www.shareable.org/
E: jamie@imbolc.ucc.ie
D: Reboot-through-BIOS for broken 486 motherboards
D: Parport fixes, futex improvements
D: First instruction of x86 sysenter path :)
S: 51 Sunningwell Road
D: Some parport fixes
S: 11 Goodson Walk
S: Marston
S: Oxford
S: OX1 4SZ
S: OX3 0HX
S: United Kingdom

N: Mark Lord
Expand Down Expand Up @@ -3376,7 +3379,7 @@ S: Germany

N: Geert Uytterhoeven
E: geert@linux-m68k.org
W: http://users.telenet.be/geertu/
W: http://home.tvd.be/cr26864/
P: 1024/862678A6 C51D 361C 0BD1 4C90 B275 C553 6EEA 11BA 8626 78A6
D: m68k/Amiga and PPC/CHRP Longtrail coordinator
D: Frame buffer device and XF68_FBDev maintainer
Expand All @@ -3386,8 +3389,8 @@ D: Amiga Buddha and Catweasel chipset IDE
D: Atari Falcon chipset IDE
D: Amiga Gayle chipset IDE
D: mipsel NEC DDB Vrc-5074
S: Haterbeekstraat 55B
S: B-3200 Aarschot
S: Emiel Vlieberghlaan 2A/21
S: B-3010 Kessel-Lo
S: Belgium

N: Chris Vance
Expand Down Expand Up @@ -3737,11 +3740,10 @@ D: Mylex DAC960 PCI RAID driver
D: Miscellaneous kernel fixes

N: Alessandro Zummo
E: a.zummo@towertech.it
E: azummo@ita.flashnet.it
W: http://freepage.logicom.it/azummo/
D: CMI8330 support is sb_card.c
D: ISAPnP fixes in sb_card.c
D: ZyXEL omni.net lcd plus driver
D: RTC subsystem
S: Italy

N: Marc Zyngier
Expand Down
113 changes: 0 additions & 113 deletions trunk/Documentation/BUG-HUNTING
View file
Original file line number Diff line number Diff line change
@@ -1,56 +1,3 @@
Table of contents
=================

Last updated: 20 December 2005

Contents
========

- Introduction
- Devices not appearing
- Finding patch that caused a bug
-- Finding using git-bisect
-- Finding it the old way
- Fixing the bug

Introduction
============

Always try the latest kernel from kernel.org and build from source. If you are
not confident in doing that please report the bug to your distribution vendor
instead of to a kernel developer.

Finding bugs is not always easy. Have a go though. If you can't find it don't
give up. Report as much as you have found to the relevant maintainer. See
MAINTAINERS for who that is for the subsystem you have worked on.

Before you submit a bug report read REPORTING-BUGS.

Devices not appearing
=====================

Often this is caused by udev. Check that first before blaming it on the
kernel.

Finding patch that caused a bug
===============================



Finding using git-bisect
------------------------

Using the provided tools with git makes finding bugs easy provided the bug is
reproducible.

Steps to do it:
- start using git for the kernel source
- read the man page for git-bisect
- have fun

Finding it the old way
----------------------

[Sat Mar 2 10:32:33 PST 1996 KERNEL_BUG-HOWTO lm@sgi.com (Larry McVoy)]

This is how to track down a bug if you know nothing about kernel hacking.
Expand Down Expand Up @@ -143,63 +90,3 @@ it does work and it lets non-hackers help fix bugs. And it is cool
because Linux snapshots will let you do this - something that you can't
do with vendor supplied releases.

Fixing the bug
==============

Nobody is going to tell you how to fix bugs. Seriously. You need to work it
out. But below are some hints on how to use the tools.

To debug a kernel, use objdump and look for the hex offset from the crash
output to find the valid line of code/assembler. Without debug symbols, you
will see the assembler code for the routine shown, but if your kernel has
debug symbols the C code will also be available. (Debug symbols can be enabled
in the kernel hacking menu of the menu configuration.) For example:

objdump -r -S -l --disassemble net/dccp/ipv4.o

NB.: you need to be at the top level of the kernel tree for this to pick up
your C files.

If you don't have access to the code you can also debug on some crash dumps
e.g. crash dump output as shown by Dave Miller.

> EIP is at ip_queue_xmit+0x14/0x4c0
> ...
> Code: 44 24 04 e8 6f 05 00 00 e9 e8 fe ff ff 8d 76 00 8d bc 27 00 00
> 00 00 55 57 56 53 81 ec bc 00 00 00 8b ac 24 d0 00 00 00 8b 5d 08
> <8b> 83 3c 01 00 00 89 44 24 14 8b 45 28 85 c0 89 44 24 18 0f 85
>
> Put the bytes into a "foo.s" file like this:
>
> .text
> .globl foo
> foo:
> .byte .... /* bytes from Code: part of OOPS dump */
>
> Compile it with "gcc -c -o foo.o foo.s" then look at the output of
> "objdump --disassemble foo.o".
>
> Output:
>
> ip_queue_xmit:
> push %ebp
> push %edi
> push %esi
> push %ebx
> sub $0xbc, %esp
> mov 0xd0(%esp), %ebp ! %ebp = arg0 (skb)
> mov 0x8(%ebp), %ebx ! %ebx = skb->sk
> mov 0x13c(%ebx), %eax ! %eax = inet_sk(sk)->opt

Another very useful option of the Kernel Hacking section in menuconfig is
Debug memory allocations. This will help you see whether data has been
initialised and not set before use etc. To see the values that get assigned
with this look at mm/slab.c and search for POISON_INUSE. When using this an
Oops will often show the poisoned data instead of zero which is the default.

Once you have worked out a fix please submit it upstream. After all open
source is about sharing what you do and don't you want to be recognised for
your genius?

Please do read Documentation/SubmittingPatches though to help your code get
accepted.
49 changes: 13 additions & 36 deletions trunk/Documentation/DMA-API.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -33,9 +33,7 @@ pci_alloc_consistent(struct pci_dev *dev, size_t size,

Consistent memory is memory for which a write by either the device or
the processor can immediately be read by the processor or device
without having to worry about caching effects. (You may however need
to make sure to flush the processor's write buffers before telling
devices to read that memory.)
without having to worry about caching effects.

This routine allocates a region of <size> bytes of consistent memory.
it also returns a <dma_handle> which may be cast to an unsigned
Expand Down Expand Up @@ -306,12 +304,12 @@ dma address with dma_mapping_error(). A non zero return value means the mapping
could not be created and the driver should take appropriate action (eg
reduce current DMA mapping usage or delay and try again later).

int
dma_map_sg(struct device *dev, struct scatterlist *sg,
int nents, enum dma_data_direction direction)
int
pci_map_sg(struct pci_dev *hwdev, struct scatterlist *sg,
int nents, int direction)
int
dma_map_sg(struct device *dev, struct scatterlist *sg, int nents,
enum dma_data_direction direction)
int
pci_map_sg(struct pci_dev *hwdev, struct scatterlist *sg,
int nents, int direction)

Maps a scatter gather list from the block layer.

Expand All @@ -329,33 +327,12 @@ critical that the driver do something, in the case of a block driver
aborting the request or even oopsing is better than doing nothing and
corrupting the filesystem.

With scatterlists, you use the resulting mapping like this:

int i, count = dma_map_sg(dev, sglist, nents, direction);
struct scatterlist *sg;

for (i = 0, sg = sglist; i < count; i++, sg++) {
hw_address[i] = sg_dma_address(sg);
hw_len[i] = sg_dma_len(sg);
}

where nents is the number of entries in the sglist.

The implementation is free to merge several consecutive sglist entries
into one (e.g. with an IOMMU, or if several pages just happen to be
physically contiguous) and returns the actual number of sg entries it
mapped them to. On failure 0, is returned.

Then you should loop count times (note: this can be less than nents times)
and use sg_dma_address() and sg_dma_len() macros where you previously
accessed sg->address and sg->length as shown above.

void
dma_unmap_sg(struct device *dev, struct scatterlist *sg,
int nhwentries, enum dma_data_direction direction)
void
pci_unmap_sg(struct pci_dev *hwdev, struct scatterlist *sg,
int nents, int direction)
void
dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nhwentries,
enum dma_data_direction direction)
void
pci_unmap_sg(struct pci_dev *hwdev, struct scatterlist *sg,
int nents, int direction)

unmap the previously mapped scatter/gather list. All the parameters
must be the same as those and passed in to the scatter/gather mapping
Expand Down
28 changes: 7 additions & 21 deletions trunk/Documentation/DMA-mapping.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -58,15 +58,11 @@ translating each of those pages back to a kernel address using
something like __va(). [ EDIT: Update this when we integrate
Gerd Knorr's generic code which does this. ]

This rule also means that you may use neither kernel image addresses
(items in data/text/bss segments), nor module image addresses, nor
stack addresses for DMA. These could all be mapped somewhere entirely
different than the rest of physical memory. Even if those classes of
memory could physically work with DMA, you'd need to ensure the I/O
buffers were cacheline-aligned. Without that, you'd see cacheline
sharing problems (data corruption) on CPUs with DMA-incoherent caches.
(The CPU could write to one word, DMA would write to a different one
in the same cache line, and one of them could be overwritten.)
This rule also means that you may not use kernel image addresses
(ie. items in the kernel's data/text/bss segment, or your driver's)
nor may you use kernel stack addresses for DMA. Both of these items
might be mapped somewhere entirely different than the rest of physical
memory.

Also, this means that you cannot take the return of a kmap()
call and DMA to/from that. This is similar to vmalloc().
Expand Down Expand Up @@ -198,13 +194,11 @@ document for how to handle this case.
Finally, if your device can only drive the low 24-bits of
address during PCI bus mastering you might do something like:

if (pci_set_dma_mask(pdev, DMA_24BIT_MASK)) {
if (pci_set_dma_mask(pdev, 0x00ffffff)) {
printk(KERN_WARNING
"mydev: 24-bit DMA addressing not available.\n");
goto ignore_this_device;
}
[Better use DMA_24BIT_MASK instead of 0x00ffffff.
See linux/include/dma-mapping.h for reference.]

When pci_set_dma_mask() is successful, and returns zero, the PCI layer
saves away this mask you have provided. The PCI layer will use this
Expand All @@ -216,7 +210,7 @@ functions (for example a sound card provides playback and record
functions) and the various different functions have _different_
DMA addressing limitations, you may wish to probe each mask and
only provide the functionality which the machine can handle. It
is important that the last call to pci_set_dma_mask() be for the
is important that the last call to pci_set_dma_mask() be for the
most specific mask.

Here is pseudo-code showing how this might be done:
Expand Down Expand Up @@ -288,11 +282,6 @@ There are two types of DMA mappings:

in order to get correct behavior on all platforms.

Also, on some platforms your driver may need to flush CPU write
buffers in much the same way as it needs to flush write buffers
found in PCI bridges (such as by reading a register's value
after writing it).

- Streaming DMA mappings which are usually mapped for one DMA transfer,
unmapped right after it (unless you use pci_dma_sync_* below) and for which
hardware can optimize for sequential accesses.
Expand All @@ -312,9 +301,6 @@ There are two types of DMA mappings:

Neither type of DMA mapping has alignment restrictions that come
from PCI, although some devices may have such restrictions.
Also, systems with caches that aren't DMA-coherent will work better
when the underlying buffers don't share cache lines with other data.


Using Consistent DMA mappings.

Expand Down
10 changes: 2 additions & 8 deletions trunk/Documentation/DocBook/Makefile
View file
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
# This makefile is used to generate the kernel documentation,
# primarily based on in-line comments in various source files.
# See Documentation/kernel-doc-nano-HOWTO.txt for instruction in how
# to document the SRC - and how to read it.
# to ducument the SRC - and how to read it.
# To add a new book the only step required is to add the book to the
# list of DOCBOOKS.

Expand All @@ -28,7 +28,7 @@ PS_METHOD = $(prefer-db2x)

###
# The targets that may be used.
PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs
.PHONY: xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs

BOOKS := $(addprefix $(obj)/,$(DOCBOOKS))
xmldocs: $(BOOKS)
Expand Down Expand Up @@ -211,9 +211,3 @@ clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS))

#man put files in man subdir - traverse down
subdir- := man/


# Declare the contents of the .PHONY variable as phony. We keep that
# information in a variable se we can use it in if_changed and friends.

.PHONY: $(PHONY)
Loading

0 comments on commit c35db2b

Please sign in to comment.