- 22 Jun, 2005 40 commits
-
-
Jesper Juhl authored
Timer Midlevel,ALSA sequencer,ALSA<-OSS sequencer,Digigram VX core I2C tea6330t,GUS Library,VIA82xx driver,VIA82xx-modem driver CA0106 driver,CS46xx driver,EMU10K1/EMU10K2 driver,YMFPCI driver Digigram VX Pocket driver,Common EMU synth,USB generic driver,USB USX2Y Checking a pointer for NULL before calling kfree() on it is redundant, kfree() deals with NULL pointers just fine. This patch removes such checks from sound/ This patch also makes another, but closely related, change. It avoids casting pointers about to be kfree()'ed. Signed-off-by:
Jesper Juhl <juhl-lkml@dif.dk> Signed-off-by:
Takashi Iwai <tiwai@suse.de>
-
James Courtier-Dutton authored
Intel8x0 driver To avoid confusion, the structure members vendor/device were renamed to subvendor/subdevice, because we compare them with PCI subsystem vendor and subsystem device. Signed-off-by:James Courtier-Dutton <James@superbug.co.uk>
-
Jaroslav Kysela authored
AC97 Codec,ATIIXP driver,VIA82xx driver To avoid confusion, the structure members vendor/device were renamed to subvendor/subdevice, because we compare them with PCI subsystem vendor and subsystem device. Signed-off-by:Jaroslav Kysela <perex@suse.cz>
-
Jaroslav Kysela authored
VIA82xx driver - 0x1071, 0x8399 == VIA_DXS_ENABLE - Umax AB 595T (VIA K8N800A - VT8237) - reporter: Honza Machacek <Hloupy.Honza@centrum.cz> Signed-off-by: -
Sasha Khapyorsky authored
ALI5451 driver This patch adds modem support for ali5451. Since it is same pci device all is done in ali5451.c. Signed-off-by:
Sasha Khapyorsky <sashak@smlink.com> Signed-off-by:
-
Tobias Klauser authored
CA0106 driver Use the DMA_32BIT_MASK constant from dma-mapping.h when calling pci_set_dma_mask() or pci_set_consistent_dma_mask() See http://marc.theaimsgroup.com/?t=108001993000001&r=1&w=2 for details Signed-off-by:
Tobias Klauser <tklauser@nuerscht.ch> Signed-off-by:
Domen Puncer <domen@coderock.org> Signed-off-by:
-
Sasha Khapyorsky authored
ATIIXP-modem driver,Intel8x0-modem driver,VIA82xx-modem driver Modem drivers (atiixp-modem, intel8x0m, via82xx-modem) migration for using MC97 generic modem mixer for off-hook operation. Signed-off-by:
-
Sasha Khapyorsky authored
AC97 Codec Simple MC97 modem mixer with two common controls: Off-hook and CID, and Si3056 MC specific control: Modem Speaker. Signed-off-by:
-
James Courtier-Dutton authored
CA0106 driver Signed-off-by: -
James Courtier-Dutton authored
CA0106 driver Signed-off-by: -
James Courtier-Dutton authored
CA0106 driver Notes: This adds a new mixer item to switch between Mic and Line-in. Signed-off-by: -
James Courtier-Dutton authored
CA0106 driver Notes: MIC capture not tested yet. Signed-off-by: -
-
-
Jesper Juhl authored
This patch removes some unneeded checks of pointers being NULL before calling kfree() on them. kfree() handles NULL pointers just fine, checking first is pointless. Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
NeilBrown authored
Due to the use of write-behind, it is possible for md to write a page to the bitmap file that is still completing writeback. This is not allowed. With this patch, we detect those cases and either force a sync write, or back off and try later, as appropriate. Signed-off-by:
Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by:
-
NeilBrown authored
1/ Must typecast int to (sector_t) before inverting or we might not invert enough bits. 2/ When "bitmap_offset" was added to mdp_superblock_1, we didn't increase the count of words-used (96 to 100). Signed-off-by:
-
NeilBrown authored
currently, md updates all superblocks (one on each device) in series. It waits for one write to complete before starting the next. This isn't a big problem as superblock updates don't happen that often. However it is neater to do it in parallel, and if the drives in the array have gone to "sleep" after a period of idleness, then waking them is parallel is faster (and someone else should be worrying about power drain). Futher, we will need parallel superblock updates for a future patch which keeps the intent-logging bitmap near the superblock. Also remove the silly code that retired superblock updates 100 times. This simply never made sense. Signed-off-by:
-
NeilBrown authored
This provides an alternate to storing the bitmap in a separate file. The bitmap can be stored at a given offset from the superblock. Obviously the creator of the array must make sure this doesn't intersect with data.... After is good for version-0.90 superblocks. Signed-off-by:
-
NeilBrown authored
Before completing a 'write' the md superblock might need to be updated. This is best done by the md_thread. The current code schedules this up and queues the write request for later handling by the md_thread. However some personalities (Raid5/raid6) will deadlock if the md_thread tries to submit requests to its own array. So this patch changes things so the processes submitting the request waits for the superblock to be written and then submits the request itself. This fixes a recently-created deadlock in raid5/raid6 Signed-off-by:
-
NeilBrown authored
When an array is degraded, bit in the intent-bitmap are never cleared. So if a recently failed drive is re-added, we only need to reconstruct the block that are still reflected in the bitmap. This patch adds support for this re-adding. Signed-off-by:
-
NeilBrown authored
Otherwise it could have a random value and might BUG. This fixes a BUG during resync problem in raid1 introduced by the bitmap-based-intent-loggin patches. Signed-off-by:
-
NeilBrown authored
The logic here is wrong. if fullsync is 0, it WILL BUG. Signed-off-by:
-
NeilBrown authored
Signed-off-by:
-
NeilBrown authored
When looking for pages that need cleaning we skip pages that don't have BITMAP_PAGE_CLEAN set. But if it is the 'current' page we will have cleared that bit ourselves, so skipping it is wrong. So: move the 'skip this page' inside 'if page != lastpage'. Also fold call of file_page_offset into the one place where the value (bit) is used. Signed-off-by:
-
NeilBrown authored
Currently we don't wait for updates to the bitmap to be flushed to disk properly. The infrastructure all there, but it isn't being used.... A separate kernel thread (bitmap_writeback_daemon) is needed to wait for each page as we cannot get callbacks when a page write completes. Signed-off-by:
-
NeilBrown authored
Signed-off-by:
-
NeilBrown authored
- report sync_size properly - need /2 to convert sectors to KB - move everything over 2 spaces to allow proper spelling of "events cleared". Signed-off-by:
-
akpm@osdl.org authored
A u64 is not an unsigned long long. On power4 it is `long', and printk warns. Signed-off-by:
-
NeilBrown authored
As the array-wide clean bit (in the superblock) is set more agressively than the bits in the bitmap are cleared, it is possible to have an array which is clean despite there being bits set in the bitmap. These bits will currently never get cleared, as they can only be cleared by a resync pass, which never happens. No, when reading bits from disk, be aware of whether the whole array is known to be in sync, and act accordingly. Signed-off-by:
-
NeilBrown authored
Signed-off-by:
-
NeilBrown authored
The debugging message printed the wrong pid, which didn't help remove bugs.... Signed-off-by:
-
NeilBrown authored
bitmap_daemon_work clears bits in the bitmap for blocks that haven't been written to for a while. It needs to be called regularly to make sure the bitmap doesn't endup full of ones .... but it wasn't. So call it from the increasingly-inaptly-named md_check_recovery Signed-off-by:
-
NeilBrown authored
1/ When init from disk, it is a BUG if there is nowhere to init from, 2/ use seq_path to print path in /proc/mdstat Signed-off-by:
-
NeilBrown authored
With this patch, the intent to write to some block in the array can be logged to a bitmap file. Each bit represents some number of sectors and is set before any update happens, and only cleared when all writes relating to all sectors are complete. After an unclean shutdown, information in this bitmap can be used to optimise resync - only sectors which could be out-of-sync need to be updated. Also if a drive is removed and then added back into an array, the recovery can make use of the bitmap to optimise reconstruction. This is not implemented in this patch. Currently the bitmap is stored in a file which must (obviously) be stored on a separate device. The patch only provided infrastructure. It does not update any personalities to bitmap intent logging. Md arrays can still be used with no bitmap file. This patch has minimal impact on such arrays. Signed-off-by:
-
NeilBrown authored
1/ change the return value (which is number-of-sectors synced) from 'int' to 'sector_t'. The number of sectors is usually easily small enough to fit in an int, but if resync needs to abort, it may want to return the total number of remaining sectors, which could be large. Also errors cannot be returned as negative numbers now, so use 0 instead 2/ Add a 'skipped' return parameter to allow the array to report that it skipped the sectors. This allows md to take this into account in the speed calculations. Currently there is no important skipping, but the bitmap-based-resync that is coming will use this. Signed-off-by:
-
NeilBrown authored
When md marks the superblock dirty before a write, it calls generic_make_request (to write the superblock) from within generic_make_request (to write the first dirty block), which could cause problems later. With this patch, the superblock write is always done by the helper thread, and write request are delayed until that write completes. Also, the locking around marking the array dirty and writing the superblock is improved to avoid possible races. Signed-off-by:
-
NeilBrown authored
md_enter_safemode checks if it is time to mark the md superblock as 'clean'. i.e. if all writes have completed and a suitable delay has passed. This is currently called from md_handle_safemode which in-turn is called (almost) every time md_check_recovery is called, and from the end of md_do_sync which causes the mddev->thread to run, which will always call md_check_recovery as well. So it doesn't need to be a separate function and fits quite well into md_check_recovery. The "almost" is because multipathd calls md_check_recovery but not md_handle_safemode. This is OK because the code from md_enter_safemode is a no-op if mddev->safemode == 0, which it always is for a multipathd (providing we don't allow it to be set to 2 on a signal...) Signed-off-by:
-
NeilBrown authored
Currently if add_new_disk is used to hot-add a drive to a degraded array, recovery doesn't start ... because we didn't tell it to. Signed-off-by:
-
NeilBrown authored
i.e. missing or failed drives are moved to the end of the list. The means a 3 drive md array with the first drive missing can be shrunk to a two drive array. Currently that isn't possible. Also, the "last_used" device number might be out-of-range after the number of devices is reduced, so we set it to 0. Signed-off-by:
-
