- 05 Feb, 2007 5 commits
-
-
Lars Ellenberg authored
md raidX make_request functions strip off the BIO_RW_SYNC flag, thus introducing additional latency. Fixing this in raid1 and raid10 seems to be straightforward enough. For our particular usage case in DRBD, passing this flag improved some initialization time from ~5 minutes to ~5 seconds. Acked-by:
NeilBrown <neilb@suse.de> Signed-off-by:
Lars Ellenberg <lars@linbit.com> Acked-by:
Jens Axboe <jens.axboe@oracle.com> Cc: <stable@kernel.org> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Chris Wright <chrisw@sous-sol.org>
-
Michael Buesch authored
This changes all HWRNG driver initcalls to module_init(). We must probe the RNGs after the major kernel subsystems are already up and running (like PCI). This fixes Bug 7730. http://bugzilla.kernel.org/show_bug.cgi?id=7730Signed-off-by:
Michael Buesch <mb@bu3sch.de> Signed-off-by:
-
Christoph Lameter authored
Both process_zones() and drain_node_pages() check for populated zones before touching pagesets. However, __drain_pages does not do so, This may result in a NULL pointer dereference for pagesets in unpopulated zones if a NUMA setup is combined with cpu hotplug. Initially the unpopulated zone has the pcp pointers pointing to the boot pagesets. Since the zone is not populated the boot pageset pointers will not be changed during page allocator and slab bootstrap. If a cpu is later brought down (first call to __drain_pages()) then the pcp pointers for cpus in unpopulated zones are set to NULL since __drain_pages does not first check for an unpopulated zone. If the cpu is then brought up again then we call process_zones() which will ignore the unpopulated zone. So the pageset pointers will still be NULL. If the cpu is then again brought down then __drain_pages will attempt to drain pages by following the NULL pageset pointer for unpopulated zones. Signed-off-by:
Christoph Lameter <clameter@sgi.com> Signed-off-by:
Linus Torvalds <torvalds@osdl.org> Signed-off-by:
-
Philippe De Muyter authored
m41t00.c forgets to set the year field in set_rtc_time; fix that. Signed-off-by:
Philippe De Muyter <phdm@macqel.be> Acked-by:
Mark A. Greer <mgreer@mvista.com> Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Maxime Bizon authored
I have a Marvell board which has the same i2c hw block than mv64xxx, so I'm trying to use i2c-mv64xxx driver. But I get the following random oops at boot: Unable to handle kernel NULL pointer dereference at virtual address 00000002 Backtrace: [<c0397e4c>] (mv64xxx_i2c_intr+0x0/0x2b8) from [<c02879c4>] (__do_irq+0x4c/0x8c) [<c0287978>] (__do_irq+0x0/0x8c) from [<c0287c0c>] (do_level_IRQ+0x68/0xc0) r8 = C0501E08 r7 = 00000005 r6 = C0501E08 r5 = 00000005 r4 = C048BB78 [<c0287ba4>] (do_level_IRQ+0x0/0xc0) from [<c02885f8>] (asm_do_IRQ+0x50/0x134) r6 = C0449C78 r5 = F1020000 r4 = FFFFFFFF [<c02885a8>] (asm_do_IRQ+0x0/0x134) from [<c02869c4>] (__irq_svc+0x24/0x100) r8 = C1CAC400 r7 = 00000005 r6 = 00000002 r5 = F1020000 r4 = FFFFFFFF [<c0287efc>] (setup_irq+0x0/0x124) from [<c02880d0>] (request_irq+0xb0/0xd0) r7 = C041B2AC r6 = C0397E4C r5 = 00000000 r4 = 00000005 [<c0288020>] (request_irq+0x0/0xd0) from [<c03985f4>] (mv64xxx_i2c_probe+0x148/0x244) [<c03984ac>] (mv64xxx_i2c_probe+0x0/0x244) from [<c038bedc>] (platform_drv_probe+0x20/0x24) The oops is caused by a spurious interrupt that occurs when request_irq is called. mv64xxx_i2c_fsm() tries to read drv_data->msg, which is NULL. I noticed that hardware init is done after requesting irq. Thus any pending irq from previous hardware usage may cause this. The following patch fixes it: Signed-off-by:
Maxime Bizon <mbizon@freebox.fr> Acked-by:
-
- 10 Jan, 2007 35 commits
-
-
Chris Wright authored
-
Peter Zijlstra authored
- add flush_cache_page() for all those virtual indexed cache architectures. - handle s390. Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
-
Linus Torvalds authored
Doug Chapman noticed that mincore() will doa "copy_to_user()" of the result while holding the mmap semaphore for reading, which is a big no-no. While a recursive read-lock on a semaphore in the case of a page fault happens to work, we don't actually allow them due to deadlock schenarios with writers due to fairness issues. Doug and Marcel sent in a patch to fix it, but I decided to just rewrite the mess instead - not just fixing the locking problem, but making the code smaller and (imho) much easier to understand. Cc: Doug Chapman <dchapman@redhat.com> Cc: Marcel Holtmann <holtmann@redhat.com> Cc: Hugh Dickins <hugh@veritas.com> Cc: Andrew Morton <akpm@osdl.org> [chrisw: fold in subsequent fix: 4fb23e43] Acked-by:
Hugh Dickins <hugh@veritas.com> [chrisw: fold in subsequent fix: 825020c3] Signed-off-by:
Oleg Nesterov <oleg@tv-sign.ru> Signed-off-by:
-
Hugh Dickins authored
These days, if you swapoff when there isn't enough memory, OOM killer gives "BUG: scheduling while atomic" and the machine hangs: badness() needs to do its PF_SWAPOFF return after the task_unlock (tasklist_lock is also held here, so p isn't going to be freed: PF_SWAPOFF might get turned off at any moment, but that doesn't really matter). Signed-off-by:
-
Erik Jacobson authored
On ia64, the various functions that make up cn_proc.c cause kernel unaligned access errors. If you are using these, for example, to get notification about all tasks forking and exiting, you get multiple unaligned access errors per process. Use put_unaligned() in the appropriate palces to fix this. Signed-off-by:
Erik Jacobson <erikj@sgi.com> Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Cc: Tony Luck <tony.luck@intel.com> Cc: <stable@kernel.org> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by:
-
Paul Moore authored
Back when the original NetLabel patches were being changed to use Netlink attributes correctly some code was accidentially dropped which set all of the undefined CIPSOv4 level and category mappings to a sentinel value. The result is the mappings data in the kernel contains bogus mappings which always map to zero. Having level and category mappings that map to zero could result in the kernel assigning incorrect security attributes to packets. This patch restores the old/correct behavior by initializing the mapping data to the correct sentinel value. Signed-off-by:
Paul Moore <paul.moore@hp.com> Signed-off-by:
-
David Hollis authored
The attached patch fixes a PHY selection problem that prevents AX88772 based devices (Linksys USB200Mv2, etc) devices from working. The interface comes up and everything seems fine except the device doesn't send/receive any packets. The one-liner attached fixes this issue and makes the devices usable again. Signed-off-by:
David Hollis <dhollis@davehollis.com> Signed-off-by:
-
David L Stevens authored
It is important that we only assign dev->ip{,6}_ptr only after all portions of the inet{,6} are setup. Otherwise we can receive packets before the multicast spinlocks et al. are initialized. Signed-off-by:David L Stevens <dlstevens@us.ibm.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
David Miller authored
This matches what the ISA cs4231 driver uses. Tested by Georg Chini. Signed-off-by:
-
Georg Chini authored
SBUS: Change IRQ-handler return value from 0 to IRQ_HANDLED and fix some initialisation problems. Change period_bytes_min from 4096 to 256 to allow driver to work with low latency (VOIP) applications. Hope this does not break EBUS. Signed-off-by:
Georg Chini <georg.chini@triaton-webhosting.com> Signed-off-by:
-
Chuck Ebbert authored
We cannot compute the gap until we know we have a 'struct ebt_entry' and not 'struct ebt_entries'. Failure to check can cause crash. Tested-by:
Santiago Garcia Mantinan <manty@manty.net> Acked-by:
Al Viro <viro@zeniv.linux.org.uk> Acked-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
Chuck Ebbert <76306.1226@compuserve.com> Signed-off-by:
-
Jean Delvare authored
reference to .init.text: from .text between 'cx88_card_setup' (at offset 0x68c) and 'cx88_risc_field' Caused by leadtek_eeprom() being declared __devinit and called from a non-devinit context. Signed-off-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab@infradead.org> Signed-off-by:
-
Ang Way Chuang authored
CRC-32 checking during ULE decapsulation always failed on x86_64 systems due to the size of a variable used to store CRC. This bug was discovered on Fedora Core 6 with kernel-2.6.18-1.2849. The i386 counterpart has no such problem. This patch has been tested on 64-bit system as well as 32-bit system. Signed-off-by:
Ang Way Chuang <wcang@nrg.cs.usm.my> Signed-off-by:
-
Hans Verkuil authored
This bug broke the MPEG audio mode controls. Signed-off-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
-
Linus Torvalds authored
The VM layer (on the face of it, fairly reasonably) expected that when it does a ->writepage() call to the filesystem, it would write out the full page at that point in time. Especially since it had earlier marked the whole page dirty with "set_page_dirty()". But that isn't actually the case: ->writepage() does not actually write a page, it writes the parts of the page that have been explicitly marked dirty before, *and* that had not got written out for other reasons since the last time we told it they were dirty. That last caveat is the important one. Which _most_ of the time ends up being the whole page (since we had called "set_page_dirty()" on the page earlier), but if the filesystem had done any dirty flushing of its own (for example, to honor some internal write ordering guarantees), it might end up doing only a partial page IO (or none at all) when ->writepage() is actually called. That is the correct thing in general (since we actually often _want_ only the known-dirty parts of the page to be written out), but the shared dirty page handling had implicitly forgotten about these details, and had a number of cases where it was doing just the "->writepage()" part, without telling the low-level filesystem that the whole page might have been re-dirtied as part of being mapped writably into user space. Since most of the time the FS did actually write out the full page, we didn't notice this for a loong time, and this needed some really odd patterns to trigger. But it caused occasional corruption with rtorrent and with the Debian "apt" database, because both use shared mmaps to update the end result. This fixes it. Finally. After way too much hair-pulling. Acked-by:
Nick Piggin <nickpiggin@yahoo.com.au> Acked-by:
Martin J. Bligh <mbligh@google.com> Acked-by:
Martin Michlmayr <tbm@cyrius.com> Acked-by:
Martin Johansson <martin@fatbob.nu> Acked-by:
Ingo Molnar <mingo@elte.hu> Acked-by:
Andrei Popa <andrei.popa@i-neo.ro> Cc: High Dickins <hugh@veritas.com> Cc: Andrew Morton <akpm@osdl.org>, Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Segher Boessenkool <segher@kernel.crashing.org> Cc: David Miller <davem@davemloft.net> Cc: Arjan van de Ven <arjan@infradead.org> Cc: Gordon Farquharson <gordonfarquharson@gmail.com> Cc: Guillaume Chazarain <guichaz@yahoo.fr> Cc: Theodore Tso <tytso@mit.edu> Cc: Kenneth Cheng <kenneth.w.chen@intel.com> Cc: Tobias Diedrich <ranma@tdiedrich.de> Signed-off-by:
-
Jan Andersson authored
Add sg->offset to sg->dvma_address in pci_map_sg() on sparc32. Without the offset, transfers to buffers that do not begin on a page boundary will not work as expected. Signed-off-by:
Jan Andersson <jan.andersson@ieee.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: William Lee Irwin III <wli@holomorphy.com> Signed-off-by:
-
David Woodhouse authored
Don't add it there please; add it lower down inside the existing #ifdef __KERNEL__. You just made the _userspace_ net.h include random.h, which then fails to compile unless <asm/types.h> was already included. Signed-off-by:
David Woodhouse <dwmw2@infradead.org> Signed-off-by:
-
David Miller authored
And this points out that the return value from isa_dev_get_resource() and the 'pregs' arg to isa_dev_get_irq() are totally unused. Based upon a patch from Richard Mortimer <richm@oldelvet.org.uk> Signed-off-by:
-
David Miller authored
We were not being careful enough. When we trim the physical memory areas, we have to make sure we don't remove the kernel image or initial ramdisk image ranges. Signed-off-by:
-
Robert Olsson authored
Signed-off-by:
-
Eric Sandeen authored
This one was pointed out on the MOKB site: http://kernelfun.blogspot.com/2006/11/mokb-09-11-2006-linux-26x-ext2checkpage.html If a directory's i_size is corrupted, ext2_find_entry() will keep processing pages until the i_size is reached, even if there are no more blocks associated with the directory inode. This patch puts in some minimal sanity-checking so that we don't keep checking pages (and issuing errors) if we know there can be no more data to read, based on the block count of the directory inode. This is somewhat similar in approach to the ext3 patch I sent earlier this year. Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Signed-off-by:
-
Phillip Lougher authored
Steve Grubb's fzfuzzer tool (http://people.redhat.com/sgrubb/files/ fsfuzzer-0.6.tar.gz) generates corrupt Cramfs filesystems which cause Cramfs to kernel oops in cramfs_uncompress_block(). The cause of the oops is an unchecked corrupted block length field read by cramfs_readpage(). This patch adds a sanity check to cramfs_readpage() which checks that the block length field is sensible. The (PAGE_CACHE_SIZE << 1) size check is intentional, even though the uncompressed data is not going to be larger than PAGE_CACHE_SIZE, gzip sometimes generates compressed data larger than the original source data. Mkcramfs checks that the compressed size is always less than or equal to PAGE_CACHE_SIZE << 1. Of course Cramfs could use the original uncompressed data in this case, but it doesn't. Signed-off-by:
Phillip Lougher <phillip@lougher.org.uk> Signed-off-by:
-
Eric Sandeen authored
I've been using Steve Grubb's purely evil "fsfuzzer" tool, at http://people.redhat.com/sgrubb/files/fsfuzzer-0.4.tar.gz Basically it makes a filesystem, splats some random bits over it, then tries to mount it and do some simple filesystem actions. At best, the filesystem catches the corruption gracefully. At worst, things spin out of control. As you might guess, we found a couple places in ext3 where things spin out of control :) First, we had a corrupted directory that was never checked for consistency... it was corrupt, and pointed to another bad "entry" of length 0. The for() loop looped forever, since the length of ext3_next_entry(de) was 0, and we kept looking at the same pointer over and over and over and over... I modeled this check and subsequent action on what is done for other directory types in ext3_readdir... (adding this check adds some computational expense; I am testing a followup patch to reduce the number of times we check and re-check these directory entries, in all cases. Thanks for the idea, Andreas). Next we had a root directory inode which had a corrupted size, claimed to be > 200M on a 4M filesystem. There was only really 1 block in the directory, but because the size was so large, readdir kept coming back for more, spewing thousands of printk's along the way. Per Andreas' suggestion, if we're in this read error condition and we're trying to read an offset which is greater than i_blocks worth of bytes, stop trying, and break out of the loop. With these two changes fsfuzz test survives quite well on ext3. Signed-off-by:
-
Ulrich Kunitz authored
The driver called ieee80211_rx in hardware interrupt context. This has been against the intention of the ieee80211_rx function. It caused a bug in the crypto routines used by WPA. This patch calls ieee80211_rx in a tasklet. Signed-off-by:
Ulrich Kunitz <kune@deine-taler.de> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Ulrich Kunitz authored
In 2.6.19 a deauthentication from the AP doesn't start a reassociation by the softmac code. It appears that mac->associnfo.associating must be set and the ieee80211softmac_assoc_work function must be scheduled. This patch fixes that. Signed-off-by:
-
Shantanu Goel authored
Fix a rather obvious buglet. Noticed while instrumenting the VM using /proc/vmstat. Cc: Christoph Lameter <clameter@engr.sgi.com> Cc: <stable@kernel.org> Signed-off-by:
-
Dimitri Gorokhovik authored
ramfs doesn't provide the .set_dirty_page a_op, and when the BLOCK layer is not configured in, 'set_page_dirty' makes a call via a NULL pointer. Signed-off-by:
Dimitri Gorokhovik <dimitri.gorokhovik@free.fr> Cc: <stable@kernel.org> Signed-off-by:
-
Shaohua Li authored
In VMSPLIT mode, kernel PGD might have more entries than user space Signed-off-by:
Shaohua Li <shaohua.li@intel.com> Signed-off-by:
-
Mike Miller authored
This patch fixes a stupid bug. Sometime during the 2tb enhancement I ended up replacing the macros XFER_READ and XFER_WRITE with h->cciss_read and h->cciss_write respectively. It seemed to work somehow at least on x86_64 and ia64. I don't know how. But people started complaining about command timeouts on older controllers like the 64xx series and only on ia32. This resolves the issue reproduced in our lab. Please consider this for inclusion. Signed-off-by:
Mike Miller <mike.miller@hp.com> Signed-off-by:
-
David Miller authored
When this code was converted to use sk_for_each() the logic for the "best hash chain length" code was reversed, breaking everything. The original code was of the form: size = 0; do { if (++size >= best_size_so_far) goto next; } while ((sk = sk->next) != NULL); best_size_so_far = size; best = result; next:; and this got converted into: sk_for_each(sk2, node, head) if (++size < best_size_so_far) { best_size_so_far = size; best = result; } Which does something very very different from the original. Signed-off-by: -
Ed L Cashin authored
Fix a bug that only appears when AoE goes over a network card that does not support scatter-gather. The headers in the linear part of the skb appeared to be larger than they really were, resulting in data that was offset by 24 bytes. This patch eliminates the offset data on cards that don't support scatter-gather or have had scatter-gather turned off. There remains an unrelated issue that I'll address in a separate email. Fixes bugzilla #7662 Signed-off-by:
"Ed L. Cashin" <ecashin@coraid.com> Cc: <stable@kernel.org> Cc: Greg KH <greg@kroah.com> Cc: <boddingt@optusnet.com.au> Signed-off-by:
-
Vitaly Wool authored
Fix the compilation failure for smc911x.c when NET_POLL_CONTROLLER is set. Signed-off-by:
Vitaly Wool <vitalywool@gmail.com> Cc: Jeff Garzik <jeff@garzik.org> Cc: <stable@kernel.org> Signed-off-by:
-
Badari Pulavarty authored
Ran into BUG() while doing madvise(REMOVE) testing. If we are punching a hole into shared memory segment using madvise(REMOVE) and the entire hole is below the indirect blocks, we hit following assert. BUG_ON(limit <= SHMEM_NR_DIRECT); Signed-off-by:
Badari Pulavarty <pbadari@us.ibm.com> Cc: Hugh Dickins <hugh@veritas.com> Cc: <stable@kernel.org> Signed-off-by:
-
Ingo Molnar authored
Fernando Lopez-Lezcano reported frequent scheduling latencies and audio xruns starting at the 2.6.18-rt kernel, and those problems persisted all until current -rt kernels. The latencies were serious and unjustified by system load, often in the milliseconds range. After a patient and heroic multi-month effort of Fernando, where he tested dozens of kernels, tried various configs, boot options, test-patches of mine and provided latency traces of those incidents, the following 'smoking gun' trace was captured by him: _------=> CPU# / _-----=> irqs-off | / _----=> need-resched || / _---=> hardirq/softirq ||| / _--=> preempt-depth |||| / ||||| delay cmd pid ||||| time | caller \ / ||||| \ | / IRQ_19-1479 1D..1 0us : __trace_start_sched_wakeup (try_to_wake_up) IRQ_19-1479 1D..1 0us : __trace_start_sched_wakeup <<...>-5856> (37 0) IRQ_19-1479 1D..1 0us : __trace_start_sched_wakeup (c01262ba 0 0) IRQ_19-1479 1D..1 0us : resched_task (try_to_wake_up) IRQ_19-1479 1D..1 0us : __spin_unlock_irqrestore (try_to_wake_up) ... <idle>-0 1...1 11us!: default_idle (cpu_idle) ... <idle>-0 0Dn.1 602us : smp_apic_timer_interrupt (c0103baf 1 0) ... <...>-5856 0D..2 618us : __switch_to (__schedule) <...>-5856 0D..2 618us : __schedule <<idle>-0> (20 162) <...>-5856 0D..2 619us : __spin_unlock_irq (__schedule) <...>-5856 0...1 619us : trace_stop_sched_switched (__schedule) <...>-5856 0D..1 619us : trace_stop_sched_switched <<...>-5856> (37 0) what is visible in this trace is that CPU#1 ran try_to_wake_up() for PID:5856, it placed PID:5856 on CPU#0's runqueue and ran resched_task() for CPU#0. But it decided to not send an IPI that no CPU - due to TS_POLLING. But CPU#0 never woke up after its NEED_RESCHED bit was set, and only rescheduled to PID:5856 upon the next lapic timer IRQ. The result was a 600+ usecs latency and a missed wakeup! the bug turned out to be an idle-wakeup bug introduced into the mainline kernel this summer via an optimization in the x86_64 tree: commit 495ab9c0 Author: Andi Kleen <ak@suse.de> Date: Mon Jun 26 13:59:11 2006 +0200 [PATCH] i386/x86-64/ia64: Move polling flag into thread_info_status During some profiling I noticed that default_idle causes a lot of memory traffic. I think that is caused by the atomic operations to clear/set the polling flag in thread_info. There is actually no reason to make this atomic - only the idle thread does it to itself, other CPUs only read it. So I moved it into ti->status. the problem is this type of change: if (!hlt_counter && boot_cpu_data.hlt_works_ok) { - clear_thread_flag(TIF_POLLING_NRFLAG); + current_thread_info()->status &= ~TS_POLLING; smp_mb__after_clear_bit(); while (!need_resched()) { local_irq_disable(); this changes clear_thread_flag() to an explicit clearing of TS_POLLING. clear_thread_flag() is defined as: clear_bit(flag, &ti->flags); and clear_bit() is a LOCK-ed atomic instruction on all x86 platforms: static inline void clear_bit(int nr, volatile unsigned long * addr) { __asm__ __volatile__( LOCK_PREFIX "btrl %1,%0" hence smp_mb__after_clear_bit() is defined as a simple compile barrier: #define smp_mb__after_clear_bit() barrier() but the explicit TS_POLLING clearing introduced by the patch: + current_thread_info()->status &= ~TS_POLLING; is not an atomic op! So the clearing of the TS_POLLING bit is freely reorderable with the reading of the NEED_RESCHED bit - and both now reside in different memory addresses. CPU idle wakeup very much depends on ordered memory ops, the clearing of the TS_POLLING flag must always be done before we test need_resched() and hit the idle instruction(s). [Symmetrically, the wakeup code needs to set NEED_RESCHED before it tests the TS_POLLING flag, so memory ordering is paramount.] Fernando's dual-core Athlon64 system has a sufficiently advanced memory ordering model so that it triggered this scenario very often. ( And it also turned out that the reason why these latencies never triggered on my testsystems is that i routinely use idle=poll, which was the only idle variant not affected by this bug. ) The fix is to change the smp_mb__after_clear_bit() to an smp_mb(), to act as an absolute barrier between the TS_POLLING write and the NEED_RESCHED read. This affects almost all idling methods (default, ACPI, APM), on all 3 x86 architectures: i386, x86_64, ia64. Signed-off-by:Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> [chrisw: backport to 2.6.19.1] Signed-off-by:
-
Dirk Eibach authored
On a custom board with ds1337 RTC I found that upgrade from 2.6.15 to 2.6.18 broke RTC support. The main problem are changes to ds1337_init_client(). When a ds1337 recognizes a problem (e.g. power or clock failure) bit 7 in status register is set. This has to be reset by writing 0 to status register. But since there are only 16 byte written to the chip and the first byte is interpreted as an address, the status register (which is the 16th) is never written. The other problem is, that initializing all registers to zero is not valid for day, date and month register. Funny enough this is checked by ds1337_detect(), which depends on this values not being zero. So then treated by ds1337_init_client() the ds1337 is not detected anymore, whereas the failure bit in the status register is still set. Broken by commit f9e89579 (2.6.16-rc1, 2006-01-06). This fix is in Linus' tree since 2.6.20-rc1 (commit 763d9c04). Signed-off-by:
Dirk Stieler <stieler@gdsys.de> Signed-off-by:
Dirk Eibach <eibach@gdsys.de> Signed-off-by:
-
