* Re: parsecvs tool now creates git repositories
From: Keith Packard @ 2006-04-04 2:07 UTC (permalink / raw)
To: Martin Langhoff; +Cc: keithp, Git Mailing List
In-Reply-To: <46a038f90604031538x3c94d86ap9f1400427513a3a7@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 776 bytes --]
On Tue, 2006-04-04 at 10:38 +1200, Martin Langhoff wrote:
> Looks nifty. Though I thought you'd go for writing a smarter cvsps, so
> that git-cvsimport could take advantage of it.
Once I had the change set information sitting in memory, it was far
easier to just generate the appropriate git commands than attempt to
recreate the cvsps output format...
> Looks like I'll have to brush up on my C to get to play... :-(
Trust me, it wasn't because I wanted to replace git-cvsimport; it's
solely that cvsps was generating complete garbage for most of my
repositories.
My new tool isn't perfect yet; it isn't getting exactly the expected
answers for the postgresql repository, but it's working perfectly for my
X server one.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* EBS effect
From: Peter J Zhu @ 2006-04-04 2:01 UTC (permalink / raw)
To: linux-mtd
In-Reply-To: <20060331014718.12468.qmail@web15110.mail.cnb.yahoo.com>
hello,
Recently I enanbled EBS with 2.6.15 on Samsung small
page(oobblock = 512B)NAND chip. The results is as
following:
Without EBS With EBS
Imagesize 31378292B 42379624B
Mouttime 17s ~ 14s ~
The overhead space is too much while providing NOT
high mout time improvement But from the thread
http://mhonarc.axis.se/jffs-dev/msg01763.html,
results seems too bad compared with what's claimed.
The only diff I can imagine is that he might use big
page NAND. Any hints are very much appreciated.
Thanks
Peter
___________________________________________________________
雅虎1G免费邮箱百分百防垃圾信
http://cn.mail.yahoo.com/
^ permalink raw reply
* Re: git-svnimport on OSX?
From: Martin Langhoff @ 2006-04-04 2:11 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86fyku2ltk.fsf@blue.stonehenge.com>
On 03 Apr 2006 18:04:07 -0700, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
>
> Working for anyone? Not working for me, and just wondered if it was me or a
> known thing. Maybe I'm just holding my mouth wrong, and yes, I have SVN::Core
> installed. If anyone wants details, I can provide.
I think I tried and gave up on it a month or two ago, but can't
remember the details. Fink's SVN::Core is too old, and having all the
SVN toolchain is a pain. What is the problem?
BTW, getting git-svnimport to work normally takes me quite a few tries
with different options, so OSX may be perfectly innocent this time...
m
^ permalink raw reply
* RE: Fix ia64 bit ops: Full barriers for bit operations returning a
From: Christoph Lameter @ 2006-04-04 2:11 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <Pine.LNX.4.64.0604031129510.21064@schroedinger.engr.sgi.com>
On Mon, 3 Apr 2006, Chen, Kenneth W wrote:
> Looks good to me.
> Acked-by: Ken Chen <kenneth.w.chen@intel.com>
Ummm.. Are you sure? The release should come before the acquire. The
final store of the cmpxchg may be delayed until after stores following the cmpxchg?
I am not sure how to fix this in an elegant way without adding a explicit
mf(). Any ideas?
^ permalink raw reply
* Re: smpnice loadbalancing with high priority tasks
From: Siddha, Suresh B @ 2006-04-04 2:11 UTC (permalink / raw)
To: Peter Williams
Cc: Siddha, Suresh B, Andrew Morton, Mike Galbraith, Nick Piggin,
Ingo Molnar, Con Kolivas, Chen, Kenneth W,
Linux Kernel Mailing List
In-Reply-To: <4431CA4F.3020304@bigpond.net.au>
On Tue, Apr 04, 2006 at 11:22:23AM +1000, Peter Williams wrote:
> OK. I think this means some fiddling with avg_load may be necessary in
> some cases but this will be complex. I'm not really happy about making
> this code more complex until some of the current unnecessary complexity
> is removed. I.e. until a proper solution to the problem of triggering
> active_load_balance() is implemented.
Here is Nicks view about active_load_balance()
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3950745131e23472fb5ace2ee4a2093e7590ec69
> >
> > c) DP system: if the cpu-0 has two high priority and cpu-1 has one normal
> > priority task, how can the current code detect this imbalance..
>
> How would it not?
imbalance will be always < busiest_load_per_task and
max_load - this_load will be < 2 * busiest_load_per_task...
and pwr_move will be <= pwr_now...
> > d) 4-way MP system: if the cpu-0 has two high priority tasks, cpu-1 has
> > one high priority and four normal priority and cpu-2,3 each has one
> > high priority task.. how does the current code distribute the normal
> > priority tasks among cpu-1,2,3... (in this case, max_load will always
> > point to cpu-0 and will never distribute the noraml priority tasks...)
>
> This should cause cpu-0 to lose one of its tasks creating a new state
how? in this case also...
imbalance will be always < busiest_load_per_task and
max_load - this_load will be < 2 * busiest_load_per_task...
and pwr_move will be <= pwr_now...
> Without smpnice, can you show how the default load balancing would
> result in the "nice" values being reliably enforced in your examples.
I agree with the issue that we are trying to fix here.. but I feel
it is incomplete.. With the current code in mainline, anyone can say the
behavior by going through the code.... with smpnice code, code is complex
and really doesn't achieve what that patch really wants to fix..
> The good news is that, in real life, high priority tasks generally only
> use very short bursts of CPU. :-)
do we then really need smpnice complexity?
thanks,
suresh
^ permalink raw reply
* Re: libata machine check on Alpha
From: Albert Lee @ 2006-04-04 2:12 UTC (permalink / raw)
To: Tejun Heo, Jonathan Blake Benson; +Cc: linux-ide
In-Reply-To: <4431CF4D.6000806@gmail.com>
Tejun Heo wrote:
> Jonathan Blake Benson wrote:
>
>> I posted a couple of months ago regarding enabling libata.atapi on a
>> Digital Alpha 164LX, equipped with a Silicon Image 3114 controller. I
>> decied to give kernel 2.6.16 (release, was previously using rc-1) a
>> shot, and it no longer longer panics. I still have a Lite-ON DVD ROM
>> drive connected via a sil3611 bridge to port number 4, hoping that I
>> can avoid using the onboard CMD646.
>>
>> No panic this time, though it appears to throw a machine check. The
>> system continues all the way to multi-user, and the Maxtor drives are
>> usable. Hope the attached dmesg helps. Let me know if I can be of
>> any assitance.
>>
>
> Can you build your kernel with ATA_DEBUG set and post dmesg? Just
> change #undef ATA_DEBUG to #define ATA_DEBUG at the top of
> include/linux/libata.h
>
For the SiI 3611 bridge + ATAPI devices, maybe the ATAPI_ENABLE_DMADIR
workaround should also be turned on as well. (in linux/libata.h)
My JMicron 20330 bridge + SiI 3112 can handle ATAPI DMA without
the ATAPI_ENABLE_DMADIR workaround. However, the SiI 3611 bridge seems
need it.
--
Albert
^ permalink raw reply
* Re: [RFC] install_session_keyring
From: Suzanne Wood @ 2006-04-04 2:13 UTC (permalink / raw)
To: dhowells; +Cc: linux-kernel, paulmck
> From David Howells Mon Apr 3 12:08:16 2006
> Suzanne Wood <suzannew@cs.pdx.edu> wrote:
> > Since RCU is applicable in read intensive environments and I
> > look for rcu_dereference() on the read side to be paired with
> > rcu_assign_pointer() on the update side, I wonder if key_put()
> > might be redundant or risky after synchronize_rcu(),
> No, it's not redundant, and neither is it risky, at least, not as far as I can
> tell from the RCU docs.
> > because key_put() opens with if(key)
> That's just to permit key_put(NULL) to avoid going splat.
> > and employs atomic_dec_and_test(&key->usage)) before
> > schedule_work(&key_cleanup_task).
> How else does the cleaner-upper know to dispose of the key? And which key?
> The cleaner scans the entire key tree and weeds out any key that is dead.
> > If the memory referenced by old has already been reclaimed which appears is
> > made possible by synchronize_rcu(), it seems that there is a contention
> > here.
>From P. McKenney's 'What is RCU?': "synchronize_rcu() marks the end of updater
code and the beginning of reclaimer code. It does this by blocking until all
pre-existing RCU read-side critical sections on all CPUs have completed. Note
that synchronize_rcu() will not necessarily wait for any subsequent RCU read-side
critical sections to complete."
It seems that once synchronize_rcu() is called, the rcu-protected memory
can be reclaimed which means available for reuse, so a NULL check wouldn't be
reliable.
> It will not be reclaimed until after its refcount is zero, and once that
> happens, there can't be any other valid links to it.
> > Yes, so I guess you mean to get rid of 'old' altogether and the three
> > lines that refer to it. But I think the original intent was to have
> > the former session keyring persist to some extent.
> Sorry, I'm not sure what you mean.
We do find rcu_dereference(tsk->signal->session_keyring) within
rcu_read_lock()/unlock() pairs (and similarly current->signal->session_keyring
and context->signal->session_keyring) in security/keys/process_keys.c and
request_key.c.
> I can't get rid of "old". I have to exchange the new pointer for the old
> pointer and then release the old object, otherwise there's a resource leak.
> However, I think the code should probably be:
> spin_lock_irqsave(&tsk->sighand->siglock, flags);
> old = tsk->signal->session_keyring;
> rcu_assign_pointer(tsk->signal->session_keyring, keyring);
> spin_unlock_irqrestore(&tsk->sighand->siglock, flags);
> The code then calls synchronize_rcu() to make sure no one can then follow that
> pointer and then releases the reference on it. Anyone who wants the object to
> persist beyond the rcu_read_lock()'d region must have incremented the refcount
> whilst inside that region. But once the synchronize_rcu() completes, it must
> be safe for me to release the reference.
When synchronize_rcu() reclaims memory, it's because the old references to stale
data were retained just for the duration of the rcu readside critical sections.
> It's possible, if not probable, that a memory barrier is required before the
> atomic_dec_and_test() in key_put().
> I don't think one is required after an atomic_inc() between rcu_read_lock()
> and rcu_read_unlock() because I think those need to imply LOCK/UNLOCK barrier
> semantics. Maybe Paul McKenney thinks otherwise, though I think I convinced
> him to agree with me.
> By the way, the use of schedule_work() to dispose of keys is so that the key
> destroyer can be relatively slow; it also keeps the latency of key_get() as
> minimal as possible in the slow case, but that's a lesser consideration. It
> also makes the locking simpler. Note that there is no intention for the key
> to persist any great length of time after its usage count reaches zero.
> Note also that the replacement of the session keyring does not suggest that
> the session keyring will most likely be destroyed; in fact the likelyhood is
> that it won't. It's a _session_ keyring, and is most probably going to be
> shared by quite a few processes.
> So, to sum up, I think there's three potential problems with my code:
> (1) key_put() probably needs smp_mb__before_atomic_dec().
> (2) key_get() may need smp_mb__after_atomic_inc() inside of rcu_read_lock()'d
> sections, but I don't think that's necessary as the mere fact it's inside
> a locked section should obviate that need.
> (3) rcu_dereference() is a waste of processing time inside the spinlocks in
> install_session_keyring(). It should be a direct dereference. The
> semantics of spin_unlock() should obviate the need for the
> smp_read_barrier_depends().
> But thanks for pointing out the potential problems in my code. That's much
> appreciated. The kernel needs a good memory barrier audit.
> David
I'm hoping to develop rules to automate a correct application
of the RCU-API and appreciate your help. And memory barrier issues
specific to different architectures provide complexity.
Thanks.
Suzanne
^ permalink raw reply
* Re: POLLRDHUP inconsistency between poll() and epoll
From: Davide Libenzi @ 2006-04-04 2:14 UTC (permalink / raw)
To: Michael Kerrisk; +Cc: Linux Kernel Mailing List, michael.kerrisk
In-Reply-To: <20134.1144115394@www102.gmx.net>
On Tue, 4 Apr 2006, Michael Kerrisk wrote:
> Davide,
>
> While playing about with the new POLLRDHUP flag, I've noticed
> an inconsistency, which may or may not be intentional...
>
> When a POLLRDHUP condition occurs, epoll_wait() tells us about
> the condition, regardless of whether or not we specified
> (E)POLLRDHUPP in the 'events' flag given to epoll_ctl()
> EPOLL_CTL_ADD. In this respect, POLLRDHUP is treated just like
> POLLHUP and POLLERR. This seems perfectly reasonable.
>
> By contrast, poll() will only tell us that POLLRDHUP occurred
> if we specified POLLRDHUP in the file descriptor 'events' mask
> given to the poll() call. In other words, poll() treats
> POLLRDHUP differently from POLLHUP and POLLERR. This seems
> a little strange.
>
> Is this difference really intended? If it is, what is the
> reason for the difference?
No. It is definitely better to keep behaviour consistent with poll/select.
I'll submit a patch ASAP. Thank you spotting this out!
- Davide
^ permalink raw reply
* Re: libata machine check on Alpha
From: Tejun Heo @ 2006-04-04 2:15 UTC (permalink / raw)
To: albertl; +Cc: Jonathan Blake Benson, linux-ide
In-Reply-To: <4431D5F5.4010905@tw.ibm.com>
Albert Lee wrote:
> Tejun Heo wrote:
>> Jonathan Blake Benson wrote:
>>
>>> I posted a couple of months ago regarding enabling libata.atapi on a
>>> Digital Alpha 164LX, equipped with a Silicon Image 3114 controller. I
>>> decied to give kernel 2.6.16 (release, was previously using rc-1) a
>>> shot, and it no longer longer panics. I still have a Lite-ON DVD ROM
>>> drive connected via a sil3611 bridge to port number 4, hoping that I
>>> can avoid using the onboard CMD646.
>>>
>>> No panic this time, though it appears to throw a machine check. The
>>> system continues all the way to multi-user, and the Maxtor drives are
>>> usable. Hope the attached dmesg helps. Let me know if I can be of
>>> any assitance.
>>>
>> Can you build your kernel with ATA_DEBUG set and post dmesg? Just
>> change #undef ATA_DEBUG to #define ATA_DEBUG at the top of
>> include/linux/libata.h
>>
>
> For the SiI 3611 bridge + ATAPI devices, maybe the ATAPI_ENABLE_DMADIR
> workaround should also be turned on as well. (in linux/libata.h)
>
> My JMicron 20330 bridge + SiI 3112 can handle ATAPI DMA without
> the ATAPI_ENABLE_DMADIR workaround. However, the SiI 3611 bridge seems
> need it.
Is there any way to make this thing automatic? 'Recompile with #define
tweak if you have some invisible bridge chip' doesn't sound too hot.
--
tejun
^ permalink raw reply
* platinumfb broken in 2.6.16
From: Bob Brose @ 2006-04-04 2:09 UTC (permalink / raw)
To: linuxppc-dev
Worked in 2.6.14:
platinumfb: Found Apple Platinum video hardware
platinumfb: Total VRAM = 2MB (0011)
platinumfb: DACula type 0x3c
platinumfb: Monitor sense value = 0x62b, platinumfb: Using video mode 6 and col
or mode 2.
line_length: a20
Console: switching to colour frame buffer device 80x30
fb0: Apple Platinum frame buffer device
Macintosh non-volatile memory driver v1.1
This is all I get in 2.6.16:
Platinumfb: Found Apple Platinum video hardware
Macintosh non-volatile memory driver v1.1
The screen has the boot params on it but is otherwise blank.
Everything else works as normal.
^ permalink raw reply
* Re: parsecvs tool now creates git repositories
From: Martin Langhoff @ 2006-04-04 2:16 UTC (permalink / raw)
To: Keith Packard; +Cc: Git Mailing List
In-Reply-To: <1144116459.2303.129.camel@neko.keithp.com>
On 4/4/06, Keith Packard <keithp@keithp.com> wrote:
> Trust me, it wasn't because I wanted to replace git-cvsimport; it's
> solely that cvsps was generating complete garbage for most of my
> repositories.
Oh, I don't mind -- we may as well bury cvsimport but I can't do C
like I can do Perl, and I surely want to help on this one.
> My new tool isn't perfect yet; it isn't getting exactly the expected
> answers for the postgresql repository, but it's working perfectly for my
> X server one.
Meh, had you done it in Perl, I'd be helping you with the Pg repo,
attic files and ensuring that files created on a branch and then put
into HEAD are handled gracefully. (But you'll get Linus' and Junio's
attention. Smarty cookie.)
Does it run incrementally? Can it discover non-binary files and pass -kk?
cheers,
martin
^ permalink raw reply
* Does dom0 see all physical processors? (RE: SAL INFO virtualization)
From: Tian, Kevin @ 2006-04-04 2:17 UTC (permalink / raw)
To: Magenheimer, Dan (HP Labs Fort Collins), Tristan Gingold,
xen-ia64-devel
Cc: xen-devel
>From: Magenheimer, Dan (HP Labs Fort Collins)
>[mailto:dan.magenheimer@hp.com]
>Sent: 2006年4月3日 23:55
>>
>> Just an unrelated comment, Dom0 should always run on every
>physical
>> processor, which is the base requirement for performance
>> reason. It's not
>> "therefore" result of this specific issue and instead you can
>> take it as the
>> basic assumption for your thought. :-)
>>
>> Thanks,
>> Kevin
>
>Hmmm... are you saying that on a 16-processor Xen system,
>domain0 will run as a 16-way SMP guest?
OK, seems that I didn't describe the case clearly. :-) For current xen
model, dom0 default runs on all physical cpus which is however
configurable.:
if ( opt_dom0_max_vcpus == 0 )
opt_dom0_max_vcpus = num_online_cpus();
if ( opt_dom0_max_vcpus > MAX_VIRT_CPUS )
opt_dom0_max_vcpus = MAX_VIRT_CPUS;
printk("Dom0 has maximum %u VCPUs\n", opt_dom0_max_vcpus);
for ( i = 1; i < opt_dom0_max_vcpus; i++ )
(void)alloc_vcpu(d, i, i); /* vcpu N runs on physical cpu N */
In this case, max vcpus of dom0 is configurable but each vcpu is running
at different physical processor once allocated. For a typical SMP box,
such model can provide better performance or else dom0 will become the
bottle neck if only owning one physical processor.
Then consider your question about a large box with many processors.
How about the real environment? Is it the case to provide a 16-way SMP
box, or a 16-way NUMA box? I prefer to the latter. If it's a NUMA box,
dom0 sees physical ACPI table and can be configured as NUMA aware.
Yes, such binding model may change later but it's always bad to have
dom0 only running on single physical processor.
CC to a wider list for comments. :-)
Thanks,
Kevin
>
>This isn't the case today with Xen (x86 or ia64) and I
>don't expect that it will work this way in the future
>either.
>
>Dan
^ permalink raw reply
* [PATCH 2.6.17-rc1] [SERIAL] DCC(JTAG) serial and the console emulation support(revised#3)
From: Hyok S. Choi @ 2006-04-04 2:19 UTC (permalink / raw)
To: linux-kernel; +Cc: rmk+lkml
From: Hyok S. Choi <hyok.choi@samsung.com>
Many of JTAG debuggers for ARM support DCC protocol over JTAG
connection, which is very useful to debug hardwares which has no
serial port. This patch adds DCC serial emulation and the console
support. System timer based polling method is used for the
emulation of serial input interrupt handling.
Signed-off-by: Hyok S. Choi <hyok.choi@samsung.com>
---
drivers/serial/Kconfig | 31 +++
drivers/serial/Makefile | 1
drivers/serial/dcc.c | 467 +++++++++++++++++++++++++++++++++++++++++++
include/linux/serial_core.h | 3
4 files changed, 502 insertions(+), 0 deletions(-)
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 7d22dc0..3c3a3f1 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -352,6 +352,37 @@ config SERIAL_CLPS711X_CONSOLE
your boot loader (lilo or loadlin) about how to pass options to the
kernel at boot time.)
+config SERIAL_DCC
+ bool "JTAG ICE/ICD DCC serial port emulation support"
+ depends on ARM
+ select SERIAL_CORE
+ help
+ This selects serial port emulation driver for ICE/ICD JTAG debugger
+ (e.g. Trace32) for ARM architecture. You should make an terminal with
+ DCC(JTAG1) protocol.
+
+ if unsure, say N.
+
+config SERIAL_DCC_CONSOLE
+ bool "Support for console on JTAG ICE/ICD DCC"
+ depends on SERIAL_DCC
+ select SERIAL_CORE_CONSOLE
+ help
+ Say Y here if you wish to use ICE/ICD JTAG DCC serial port emulation
+ as the system console.
+
+ if unsure, say N.
+
+config SERIAL_DCC_STDSERIAL
+ bool "Install JTAG ICE/ICD DCC as standard serial"
+ default y
+ depends on !SERIAL_8250 && SERIAL_DCC
+ help
+ Say Y here if you want to install DCC driver as a normal serial port
+ /dev/ttyS0 (major 4, minor 64). Otherwise, it appears as /dev/ttyJ0
+ (major 204, minor 186) and can co-exist with other UARTs, such as
+ 8250/16C550 compatibles.
+
config SERIAL_S3C2410
tristate "Samsung S3C2410 Serial port support"
depends on ARM && ARCH_S3C2410
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index 0a71bf6..63f2462 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_SERIAL_8250_AU1X00) += 8250
obj-$(CONFIG_SERIAL_AMBA_PL010) += amba-pl010.o
obj-$(CONFIG_SERIAL_AMBA_PL011) += amba-pl011.o
obj-$(CONFIG_SERIAL_CLPS711X) += clps711x.o
+obj-$(CONFIG_SERIAL_DCC) += dcc.o
obj-$(CONFIG_SERIAL_PXA) += pxa.o
obj-$(CONFIG_SERIAL_SA1100) += sa1100.o
obj-$(CONFIG_SERIAL_S3C2410) += s3c2410.o
diff --git a/drivers/serial/dcc.c b/drivers/serial/dcc.c
new file mode 100644
index 0000000..ff7419b
--- /dev/null
+++ b/drivers/serial/dcc.c
@@ -0,0 +1,467 @@
+/*
+ * linux/drivers/serial/dcc.c
+ *
+ * serial port emulation driver for the JTAG DCC Terminal.
+ *
+ * DCC(JTAG1) protocol version for JTAG ICE/ICD Debuggers:
+ * Copyright (C) 2003, 2004, 2005 Hyok S. Choi (hyok.choi@samsung.com)
+ * SAMSUNG ELECTRONICS Co.,Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Changelog:
+ * Oct-2003 Hyok S. Choi Created
+ * Feb-2004 Hyok S. Choi Updated for serial_core.c and 2.6 kernel
+ * Mar-2005 Hyok S. Choi renamed from T32 to DCC
+ * Apr-2006 Hyok S. Choi revised including the MAJOR number
+ *
+ */
+
+#include <linux/config.h>
+#include <linux/module.h>
+#include <linux/tty.h>
+#include <linux/ioport.h>
+#include <linux/init.h>
+#include <linux/serial.h>
+#include <linux/console.h>
+#include <linux/sysrq.h>
+#include <linux/tty_flip.h>
+#include <linux/major.h>
+
+#include <asm/io.h>
+#include <asm/irq.h>
+
+#include <linux/serial_core.h>
+
+/*
+ * if real irq interrupt used for receiving character,
+ * uncomment below line and modify the DCC_IRQ to correct one.
+ * Unless polling method id used.
+ */
+//#define DCC_IRQ_USED
+//#define DCC_IRQ (INT_N_EXT0)
+
+#ifndef DCC_IRQ_USED
+static struct work_struct dcc_poll_task;
+static void dcc_poll(void *data);
+/* need to schedule itself? (>=1:yes, 0:no) */
+static unsigned int dcc_poll_run = 0;
+#endif
+
+#define UART_NR 1 /* we have only one JTAG port */
+
+#ifdef CONFIG_SERIAL_DCC_STDSERIAL
+/* use ttyS for emulation of standard serial driver */
+#define SERIAL_DCC_NAME "ttyS"
+#define SERIAL_DCC_MAJOR TTY_MAJOR
+#define SERIAL_DCC_MINOR 64
+#else
+/* use ttyJ0(128) */
+#define SERIAL_DCC_NAME "ttyJ"
+#define SERIAL_DCC_MAJOR 204
+#define SERIAL_DCC_MINOR 186
+#endif
+
+/* DCC Status Bits */
+#define DCC_STATUS_RX (1 << 0)
+#define DCC_STATUS_TX (1 << 1)
+
+/* primitive JTAG1 protocol utilities */
+static inline u32 __dcc_getstatus(void)
+{
+ u32 ret;
+
+ asm("mrc p14, 0, %0, c0, c0 @ read comms ctrl reg"
+ : "=r" (ret));
+
+ return ret;
+}
+
+static inline char __dcc_getchar(void)
+{
+ char c;
+
+ asm("mrc p14, 0, %0, c1, c0 @ read comms data reg"
+ : "=r" (c));
+
+ return c;
+}
+
+static inline void __dcc_putchar(char c)
+{
+ asm("mcr p14, 0, %0, c1, c0 @ write a char"
+ : /* no output register */
+ : "r" (c));
+}
+/* end of JTAG1 dependencies */
+
+static void dcc_putchar(struct uart_port *port, int ch)
+{
+ while (__dcc_getstatus() & DCC_STATUS_TX)
+ cpu_relax();
+ __dcc_putchar((char)(ch & 0xFF));
+}
+
+static inline void xmit_string(struct uart_port *port, char *p, int len)
+{
+ for ( ; len; len--, p++)
+ dcc_putchar(port, *p);
+}
+
+static inline void dcc_transmit_buffer(struct uart_port *port)
+{
+ struct circ_buf *xmit = &port->info->xmit;
+ int pendings = uart_circ_chars_pending(xmit);
+
+ if (pendings + xmit->tail > UART_XMIT_SIZE) {
+ xmit_string(port, &(xmit->buf[xmit->tail]),
+ UART_XMIT_SIZE - xmit->tail);
+ xmit_string(port, &(xmit->buf[0]), xmit->head);
+ } else
+ xmit_string(port, &(xmit->buf[xmit->tail]), pendings);
+
+ xmit->tail = (xmit->tail + pendings) & (UART_XMIT_SIZE-1);
+ port->icount.tx += pendings;
+}
+
+static inline void dcc_transmit_x_char(struct uart_port *port)
+{
+ dcc_putchar(port, port->x_char);
+ port->icount.tx++;
+ port->x_char = 0;
+}
+
+static void dcc_start_tx(struct uart_port *port)
+{
+ dcc_transmit_buffer(port);
+}
+
+static inline void dcc_rx_chars(struct uart_port *port)
+{
+ unsigned char ch;
+ struct tty_struct *tty = port->info->tty;
+
+ /*
+ * check input.
+ * checking JTAG flag is better to resolve the status test.
+ * incount is NOT used for JTAG1 protocol.
+ */
+
+ if (__dcc_getstatus() & DCC_STATUS_RX) {
+ /* for JTAG 1 protocol, incount is always 1. */
+ ch = __dcc_getchar();
+
+ if (tty) {
+ tty_insert_flip_char(tty, ch, TTY_NORMAL);
+ port->icount.rx++;
+ tty_flip_buffer_push(tty);
+ }
+ }
+}
+
+static inline void dcc_tx_chars(struct uart_port *port)
+{
+ struct circ_buf *xmit = &port->info->xmit;
+
+ if (port->x_char) {
+ dcc_transmit_x_char(port);
+ return;
+ }
+
+ if (uart_circ_empty(xmit) || uart_tx_stopped(port))
+ return;
+
+ dcc_transmit_buffer(port);
+
+ if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+ uart_write_wakeup(port);
+}
+
+#ifdef DCC_IRQ_USED /* real IRQ used */
+static irqreturn_t dcc_int(int irq, void *dev_id, struct pt_regs *regs)
+{
+ struct uart_port *port = dev_id;
+ int handled = 0;
+
+ spin_lock(&port->lock);
+
+ dcc_rx_chars(port);
+ dcc_tx_chars(port);
+
+ handled = 1;
+ spin_unlock(&port->lock);
+
+ return IRQ_RETVAL(handled);
+}
+#else /* emulation by scheduled work */
+static void dcc_poll(void *data)
+{
+ struct uart_port *port = data;
+
+ spin_lock(&port->lock);
+
+ /*
+ * The dcc polling task rescheduling is controlled by
+ * dcc_startup and dcc_shutdown. To avoid the race condition,
+ * which comes from rescheduling by the task itself,
+ * dcc_poll_run is increased or decreased by the functions,
+ * and the rescheduling is stopped when comes to '0'.
+ */
+ if (dcc_poll_run == 0)
+ goto dcc_poll_out;
+
+ dcc_rx_chars(port);
+ dcc_tx_chars(port);
+
+ schedule_delayed_work(&dcc_poll_task, 1);
+
+dcc_poll_out:
+ spin_unlock(&port->lock);
+}
+#endif /* end of DCC_IRQ_USED */
+
+static unsigned int dcc_tx_empty(struct uart_port *port)
+{
+ return TIOCSER_TEMT;
+}
+
+static unsigned int dcc_get_mctrl(struct uart_port *port)
+{
+ return TIOCM_CTS | TIOCM_DSR | TIOCM_CD;
+}
+
+static int dcc_startup(struct uart_port *port)
+{
+#ifdef DCC_IRQ_USED /* real IRQ used */
+ int retval;
+
+ /* Allocate the IRQ */
+ retval = request_irq(port->irq, dcc_int, SA_INTERRUPT,
+ "serial_dcc", port);
+ if (retval)
+ return retval;
+#else /* emulation */
+ /* shcedule the polling work */
+ spin_lock(&port->lock);
+ dcc_poll_run++;
+ spin_unlock(&port->lock);
+ schedule_delayed_work(&dcc_poll_task, 1);
+#endif
+
+ return 0;
+}
+
+static void dcc_shutdown(struct uart_port *port)
+{
+#ifdef DCC_IRQ_USED /* real IRQ used */
+ free_irq(port->irq, port);
+#else
+ spin_lock(&port->lock);
+ dcc_poll_run--;
+ spin_unlock(&port->lock);
+ cancel_rearming_delayed_work(&dcc_poll_task);
+#endif
+}
+
+static void dcc_set_termios(struct uart_port *port, struct termios *termios,
+ struct termios *old)
+{
+#ifdef DCC_IRQ_USED
+ unsigned long flags;
+#endif
+ unsigned int baud, quot;
+
+ /*
+ * We don't support parity, stop bits, or anything other
+ * than 8 bits, so clear these termios flags.
+ */
+ termios->c_cflag &= ~(CSIZE | CSTOPB | PARENB | PARODD | CREAD);
+ termios->c_cflag |= CS8;
+
+ /*
+ * We don't appear to support any error conditions either.
+ */
+ termios->c_iflag &= ~(INPCK | IGNPAR | IGNBRK | BRKINT);
+
+ /*
+ * Ask the core to calculate the divisor for us.
+ */
+ baud = uart_get_baud_rate(port, termios, old, 0, port->uartclk/16);
+ quot = uart_get_divisor(port, baud);
+
+#ifdef DCC_IRQ_USED
+ spin_lock_irqsave(&port->lock, flags);
+#endif
+
+ uart_update_timeout(port, termios->c_cflag, baud);
+
+#ifdef DCC_IRQ_USED
+ spin_unlock_irqrestore(&port->lock, flags);
+#endif
+}
+
+static const char * dcc_type(struct uart_port *port)
+{
+ return port->type == PORT_DCC_JTAG1 ? "DCC" : NULL;
+}
+
+static int dcc_request_port(struct uart_port *port)
+{
+ return 0;
+}
+
+/*
+ * Configure/autoconfigure the port.
+ */
+static void dcc_config_port(struct uart_port *port, int flags)
+{
+ if (flags & UART_CONFIG_TYPE) {
+ port->type = PORT_DCC_JTAG1;
+ dcc_request_port(port);
+ }
+}
+
+/*
+ * verify the new serial_struct (for TIOCSSERIAL).
+ */
+static int dcc_verify_port(struct uart_port *port, struct serial_struct *ser)
+{
+ int ret = 0;
+ if (ser->type != PORT_UNKNOWN && ser->type != PORT_DCC_JTAG1)
+ ret = -EINVAL;
+ if (ser->irq < 0 || ser->irq >= NR_IRQS)
+ ret = -EINVAL;
+ if (ser->baud_base < 9600)
+ ret = -EINVAL;
+ return ret;
+}
+
+/* dummy operation handlers for uart_ops */
+static void dcc_dummy_ops(struct uart_port *port)
+{
+}
+static void dcc_dummy_ops_ui(struct uart_port *port, unsigned int ui)
+{
+}
+static void dcc_dummy_ops_i(struct uart_port *port, int i)
+{
+}
+
+static struct uart_ops dcc_pops = {
+ .tx_empty = dcc_tx_empty,
+ .set_mctrl = dcc_dummy_ops_ui,
+ .get_mctrl = dcc_get_mctrl,
+ .stop_tx = dcc_dummy_ops,
+ .start_tx = dcc_start_tx,
+ .stop_rx = dcc_dummy_ops,
+ .enable_ms = dcc_dummy_ops,
+ .break_ctl = dcc_dummy_ops_i,
+ .startup = dcc_startup,
+ .shutdown = dcc_shutdown,
+ .set_termios = dcc_set_termios,
+ .type = dcc_type,
+ .release_port = dcc_dummy_ops,
+ .request_port = dcc_request_port,
+ .config_port = dcc_config_port,
+ .verify_port = dcc_verify_port,
+};
+
+static struct uart_port dcc_port = {
+ .membase = (char*)0x12345678, /* we need these garbages */
+ .mapbase = 0x12345678, /* for serial_core.c */
+ .iotype = UPIO_MEM,
+#ifdef DCC_IRQ_USED
+ .irq = DCC_IRQ,
+#else
+ .irq = 0,
+#endif
+ .uartclk = 14745600,
+ .fifosize = 0,
+ .ops = &dcc_pops,
+ .flags = UPF_BOOT_AUTOCONF,
+ .line = 0,
+};
+
+
+#ifdef CONFIG_SERIAL_DCC_CONSOLE
+static void dcc_console_write(struct console *co, const char *s, unsigned int count)
+{
+ uart_console_write(&dcc_port, s, count, dcc_putchar);
+}
+
+static int __init dcc_console_setup(struct console *co, char *options)
+{
+ struct uart_port *port = &dcc_port;
+ int baud = 9600;
+ int bits = 8;
+ int parity = 'n';
+ int flow = 'n';
+
+ if (options)
+ uart_parse_options(options, &baud, &parity, &bits, &flow);
+
+ return uart_set_options(port, co, baud, parity, bits, flow);
+}
+
+extern struct uart_driver dcc_reg;
+static struct console dcc_console = {
+ .name = SERIAL_DCC_NAME,
+ .write = dcc_console_write,
+ .device = uart_console_device,
+ .setup = dcc_console_setup,
+ .flags = CON_PRINTBUFFER,
+ .index = -1,
+ .data = &dcc_reg,
+};
+
+static int __init dcc_console_init(void)
+{
+ register_console(&dcc_console);
+ return 0;
+}
+console_initcall(dcc_console_init);
+
+#define DCC_CONSOLE &dcc_console
+#else
+#define DCC_CONSOLE NULL
+#endif
+
+static struct uart_driver dcc_reg = {
+ .owner = THIS_MODULE,
+ .driver_name = SERIAL_DCC_NAME,
+ .dev_name = SERIAL_DCC_NAME,
+ .major = SERIAL_DCC_MAJOR,
+ .minor = SERIAL_DCC_MINOR,
+ .nr = UART_NR,
+ .cons = DCC_CONSOLE,
+};
+
+static int __init dcc_init(void)
+{
+ int ret;
+
+ printk(KERN_INFO "DCC: JTAG1 Serial emulation driver driver $Revision: 1.1 $\n");
+
+ ret = uart_register_driver(&dcc_reg);
+
+ if (ret)
+ return ret;
+
+#ifndef DCC_IRQ_USED
+ /* initialize the poll work */
+ INIT_WORK(&dcc_poll_task, dcc_poll, &dcc_port);
+#endif
+
+ uart_add_one_port(&dcc_reg, &dcc_port);
+
+ return 0;
+}
+
+__initcall(dcc_init);
+
+MODULE_DESCRIPTION("DCC(JTAG1) JTAG debugger console emulation driver");
+MODULE_AUTHOR("Hyok S. Choi <hyok.choi@samsung.com>");
+MODULE_SUPPORTED_DEVICE(SERIAL_DCC_NAME);
+MODULE_LICENSE("GPL");
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index c32e60e..561bc6a 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -130,6 +130,9 @@
/* SUN4V Hypervisor Console */
#define PORT_SUNHV 72
+/* DCC(JTAG) emulation port types */
+#define PORT_DCC_JTAG1 73
+
#ifdef __KERNEL__
#include <linux/config.h>
^ permalink raw reply related
* VMware-workstation-3.2.1-2242
From: Stephen Clark @ 2006-04-04 2:21 UTC (permalink / raw)
To: linux-kernel
Hi,
Anyone able to get VMware-workstation-3.2.1-2242 running on 2.6.15 or
2.6.16?
Thanks,
Steve
^ permalink raw reply
* Re: parsecvs tool now creates git repositories
From: Keith Packard @ 2006-04-04 2:24 UTC (permalink / raw)
To: Martin Langhoff; +Cc: keithp, Git Mailing List
In-Reply-To: <46a038f90604031916r4651b572lb9bae4c5a3d47bc9@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 767 bytes --]
On Tue, 2006-04-04 at 14:16 +1200, Martin Langhoff wrote:
> Meh, had you done it in Perl, I'd be helping you with the Pg repo,
> attic files and ensuring that files created on a branch and then put
> into HEAD are handled gracefully. (But you'll get Linus' and Junio's
> attention. Smarty cookie.)
I think those parts are working correctly, I've had plenty of examples
of that kind of adventure.
> Does it run incrementally? Can it discover non-binary files and pass -kk?
It doesn't run incrementally, and it unconditionally passes -kk. It's
currently using rcs to check out versions of the files, so it should
deal with binary content as well as rcs does. Is there something magic I
need to do here? Like for DOS?
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [NFS] Re: [PATCH 011 of 16] knfsd: svcrpc: WARN() instead of returning an error from svc_take_page
From: J. Bruce Fields @ 2006-04-04 2:26 UTC (permalink / raw)
To: Ingo Oeser; +Cc: NeilBrown, nfs, linux-kernel, Andrew Morton
In-Reply-To: <200604040002.22544.ioe-lkml@rameria.de>
On Tue, Apr 04, 2006 at 12:02:21AM +0200, Ingo Oeser wrote:
> On Monday, 3. April 2006 07:19, you wrote:
> > diff ./include/linux/sunrpc/svc.h~current~ ./include/linux/sunrpc/svc.h
> > --- ./include/linux/sunrpc/svc.h~current~ 2006-04-03 15:12:15.000000000 +1000
> > +++ ./include/linux/sunrpc/svc.h 2006-04-03 15:12:15.000000000 +1000
> > @@ -197,15 +197,13 @@ svc_take_res_page(struct svc_rqst *rqstp
> > return rqstp->rq_respages[rqstp->rq_resused++];
> > }
> >
> > -static inline int svc_take_page(struct svc_rqst *rqstp)
> > +static inline void svc_take_page(struct svc_rqst *rqstp)
> > {
> > - if (rqstp->rq_arghi <= rqstp->rq_argused)
> > - return -ENOMEM;
> > + WARN_ON(rqstp->rq_arghi <= rqstp->rq_argused);
> > rqstp->rq_arghi--;
> > rqstp->rq_respages[rqstp->rq_resused] =
> > rqstp->rq_argpages[rqstp->rq_arghi];
> > rqstp->rq_resused++;
> > - return 0;
> > }
>
> What will prevent underflow of ->rq_arghi and overflow of ->rq_resused here?
>
> Before that change, this code would return without
> modifying both members here on error.
>
> Now this code makes the error worse with each call.
>
> Just ignore me, if this is ok :-)
No, you're right, apologies. The results could be worse than if we'd
just BUG()'d there.
So we should probably either just bite the bullet and make that a BUG(),
or add back the return. The latter option appended in the form of a
replacement patch....
--b.
svcrpc: WARN() instead of returning an error from svc_take_page
Every caller of svc_take_page ignores its return value and assumes it
succeeded. So just WARN() instead of returning an ignored error. This
would have saved some time debugging a recent nfsd4 problem.
If there are still failure cases here, then the result is probably that we
overwrite an earlier part of the reply while xdr-encoding.
While the corrupted reply is a nasty bug, it would be worse to panic here
and create the possibility of a remote DOS; hence WARN() instead of BUG().
Thanks to Ingo Oeser for noticing a bug in an earlier version of this
patch.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
include/linux/sunrpc/svc.h | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/include/linux/sunrpc/svc.h b/include/linux/sunrpc/svc.h
index 50cab2a..5035643 100644
--- a/include/linux/sunrpc/svc.h
+++ b/include/linux/sunrpc/svc.h
@@ -197,15 +197,16 @@ svc_take_res_page(struct svc_rqst *rqstp
return rqstp->rq_respages[rqstp->rq_resused++];
}
-static inline int svc_take_page(struct svc_rqst *rqstp)
+static inline void svc_take_page(struct svc_rqst *rqstp)
{
- if (rqstp->rq_arghi <= rqstp->rq_argused)
- return -ENOMEM;
+ if (rqstp->rq_arghi <= rqstp->rq_argused) {
+ WARN_ON(1);
+ return;
+ }
rqstp->rq_arghi--;
rqstp->rq_respages[rqstp->rq_resused] =
rqstp->rq_argpages[rqstp->rq_arghi];
rqstp->rq_resused++;
- return 0;
}
static inline void svc_pushback_allpages(struct svc_rqst *rqstp)
^ permalink raw reply related
* Re: [PATCH 2.6.17-rc1] [SERIAL] DCC(JTAG) serial and the console emulation support(revised#2)
From: Hyok S. Choi @ 2006-04-04 2:27 UTC (permalink / raw)
To: Russell King; +Cc: linux-kernel
In-Reply-To: <20060403194448.GC5616@flint.arm.linux.org.uk>
On Tuesday 04 April 2006 04:44 am, Russell King wrote:
> On Mon, Apr 03, 2006 at 08:24:10PM +0900, Hyok S. Choi wrote:
>
> > +static void dcc_shutdown(struct uart_port *port)
> > +{
> > +#ifdef DCC_IRQ_USED /* real IRQ used */
> > + free_irq(port->irq, port);
> > +#else
> > + spin_lock(&port->lock);
> > + cancel_rearming_delayed_work(&dcc_poll_task);
>
> cancel_rearming_delayed_work() might sleep due to it calling
> flush_workqueue. Therefore, you must not be holding a spinlock.
Thus, I've just revised the code to lock around a counter variable
operation, which is used for life control of the polling task.
I've just posted the revised #3. :-)
--
Hyok
ARM Linux 2.6 MPU/noMMU Project http://opensrc.sec.samsung.com/
^ permalink raw reply
* Header Sanitizing Project
From: Jim Gifford @ 2006-04-04 2:31 UTC (permalink / raw)
To: LKML
I've been working on a way to sanitize the headers. I've come up with a
process, that works for what I do, and hope to expand it with all the
positive feedback I've been getting. The product of this research is at
http://ftp.jg555.com/headers/headers2, and has a requirement of unifdef,
which is listed in the script itself.
When I was working on this project, I've noticed a lot of headers are
missing minor little things. Example. most if the if_*.h files are
missing asm/types.h. linux/input.h has a complete procedure that should
be under __KERNEL__. Should I submit these as bugs along with the
patches? I have no problem submitting them.
Please advise me on the proper procedure on the findings, I can provide
more details, but everything is in my little script for sanitizing the
headers.
Thank you for all your help
Jim Gifford
maillist@jg555.com
^ permalink raw reply
* Re: [ck] lowmem_reserve question
From: Con Kolivas @ 2006-04-04 2:35 UTC (permalink / raw)
To: ck; +Cc: Nick Piggin, Andrew Morton, linux list
In-Reply-To: <200604031248.13532.kernel@kolivas.org>
On Mon, 3 Apr 2006 12:48 pm, Con Kolivas wrote:
> While trying to digest just what the lowmem_reserve does
> and how it's utilised I looked at some of the numbers
>
> int sysctl_lowmem_reserve_ratio[MAX_NR_ZONES-1] = { 256, 256, 32 };
>
> lower_zone->lowmem_reserve[j] = present_pages /
> sysctl_lowmem_reserve_ratio[idx];
>
> This is interesting because there are no bounds on this value and it seems
> possible to set the sysctl to have a lowmem_reserve that is larger than the
> zone size. Ok that's a sysctl so if a user is setting it wrongly that's
> their fault... or should there be some upper bound?
>
> Furthermore, now that we have the option of up to 3GB lowmem split on 32bit
> we can have a default lowmem_reserve of almost 12MB (if I'm reading it
> right) which seems very tight with only 16MB of ZONE_DMA.
>
> On a basically idle 1GB lowmem box that I have it looks like this:
>
> Node 0, zone DMA
> pages free 1025
> min 15
> low 18
> high 22
> active 2185
> inactive 0
> scanned 555 (a: 21 i: 6)
> spanned 4096
> present 4096
> protection: (0, 0, 1007, 1007)
>
> With 3GB lowmem the default settings seem too tight to me. The way I see
> it, there should be some upper bounds on the lowmem reserves. Or perhaps
> I'm just missing something again... I'm feeling even thicker than usual.
Silence. Low priority I guess.
If I propose a patch that might get some response. /me threatens to post a
patch.
Cheers,
Con
^ permalink raw reply
* Re: VMware-workstation-3.2.1-2242
From: Jeffrey V. Merkey @ 2006-04-04 2:43 UTC (permalink / raw)
To: Stephen.Clark; +Cc: linux-kernel
In-Reply-To: <4431D840.5000105@seclark.us>
Stephen Clark wrote:
> Hi,
>
> Anyone able to get VMware-workstation-3.2.1-2242 running on 2.6.15 or
> 2.6.16?
Not without some adjustment to their driver build.
Jeff
>
> Thanks,
> Steve
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: parsecvs tool now creates git repositories
From: Martin Langhoff @ 2006-04-04 2:42 UTC (permalink / raw)
To: Keith Packard; +Cc: Git Mailing List
In-Reply-To: <1144117473.2303.132.camel@neko.keithp.com>
On 4/4/06, Keith Packard <keithp@keithp.com> wrote:
> On Tue, 2006-04-04 at 14:16 +1200, Martin Langhoff wrote:
>
> > Meh, had you done it in Perl, I'd be helping you with the Pg repo,
> > attic files and ensuring that files created on a branch and then put
> > into HEAD are handled gracefully. (But you'll get Linus' and Junio's
> > attention. Smarty cookie.)
>
> I think those parts are working correctly, I've had plenty of examples
> of that kind of adventure.
Cool. What's the matter with the Pg repo? (Where can I get hold of that repo?)
> > Does it run incrementally? Can it discover non-binary files and pass -kk?
>
> It doesn't run incrementally, and it unconditionally passes -kk. It's
I thought that the .git-cvs directory it created was to be able to run
incrementally (btw, I think it's fair game to create subdirs inside
.git for this kind of status-tracking). And passing -kk uncoditionally
is destructive in some cases (I know... git-cvsimport does it, and I
want to fix that). If you can ask rcs about the mode if the file and
not pass -kk for binary files...
> currently using rcs to check out versions of the files, so it should
> deal with binary content as well as rcs does. Is there something magic I
> need to do here? Like for DOS?
We'll let DOS take care of itself ;)
m
^ permalink raw reply
* blade servers?
From: Larry McVoy @ 2006-04-04 2:42 UTC (permalink / raw)
To: linux-kernel
I figured that people here would know. If you were looking for blade
servers and you were more interested in cost and heat generation than the
most performance, what would you buy? We're looking for 20 x86 cpus.
They have to beat ASUS terminators (nice little boxes, if you haven't
checked them out you should, about $100 + cpu + mem + disk and they are
quiet and run on ~100watt power supplies so they don't generate a lot
of heat).
So far, the stuff at www.rackmount.com looks pretty good but they are
(like everyone else so far as I can tell) focussed on performance.
For all of the Unix like platforms, we'd be happy with 2Ghz Athlons (don't
need opterons) with 256MB. It's true that for the windows platforms we
like 2GB because we use 1GB as a ram disk to get reasonable performance
out of @#!! Windows.
Thanks in advance,
--lm
^ permalink raw reply
* Re: sata_mv: module reloading doesn't work
From: Mark Lord @ 2006-04-04 2:47 UTC (permalink / raw)
To: Dan Aloni
Cc: Eric D. Mudama, Linux Kernel List, Jeff Garzik, Mark Lord,
IDE/ATA development list
In-Reply-To: <20060403215729.GA17731@localdomain>
Dan Aloni wrote:
>
> * Normal boot
> * insmod sata_mv
> * all is okay, as expected
> * rmmod sata_mv
> * insmod sata_mv
> * all is bad, as expected
> * kexec
> * insmod sata_mv
> * all is bad!
>
> Conclusion: sata_mv's shutdown does something bad.
sata_mv seems to just use the default libata shutdown sequence,
so perhaps it's leaving the device in EDMA mode with interrupt
coalescing still on (from the BIOS), and interrupts are still
coming in or something..
I suppose it really ought to shut down the device before exiting,
and maybe the default of pci_disable_device() is not enough.. ?
Cheers
^ permalink raw reply
* Re: [PATCH] PoC "make xconfig" Search Facility
From: Kurt Wall @ 2006-04-04 2:48 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <200603272150.42305.shlomif@iglu.org.il>
On Mon, Mar 27, 2006 at 09:50:41PM +0200, Shlomi Fish took 238 lines to write:
> Hi all!
>
> [ I'm not subscribed to this list so please CC me on your replies. ]
>
> This patch adds a proof-of-concept search facility to "make xconfig". Current
> problems and limitations:
>
> 1. Only case-insensitive single-substring search is supported.
That's a good start.
> 2. The style is completely wrong, as I could not find a suitable vim
> configuration for editing Linux kernel source (and Google was not help). If
> anyone can refer me to one, I'll be grateful.
Documentation/CodingStyle
scripts/Lindent
Kurt
--
Forgetfulness, n.:
A gift of God bestowed upon debtors in compensation for their
destitution of conscience.
^ permalink raw reply
* Re: libata machine check on Alpha
From: Albert Lee @ 2006-04-04 2:49 UTC (permalink / raw)
To: Tejun Heo; +Cc: Jonathan Blake Benson, linux-ide
In-Reply-To: <4431D6D1.9020206@gmail.com>
Tejun Heo wrote:
> Albert Lee wrote:
>
>> Tejun Heo wrote:
>>
>>> Jonathan Blake Benson wrote:
>>>
>>>> I posted a couple of months ago regarding enabling libata.atapi on a
>>>> Digital Alpha 164LX, equipped with a Silicon Image 3114 controller. I
>>>> decied to give kernel 2.6.16 (release, was previously using rc-1) a
>>>> shot, and it no longer longer panics. I still have a Lite-ON DVD ROM
>>>> drive connected via a sil3611 bridge to port number 4, hoping that I
>>>> can avoid using the onboard CMD646.
>>>>
>>>> No panic this time, though it appears to throw a machine check. The
>>>> system continues all the way to multi-user, and the Maxtor drives are
>>>> usable. Hope the attached dmesg helps. Let me know if I can be of
>>>> any assitance.
>>>>
>>> Can you build your kernel with ATA_DEBUG set and post dmesg? Just
>>> change #undef ATA_DEBUG to #define ATA_DEBUG at the top of
>>> include/linux/libata.h
>>>
>>
>> For the SiI 3611 bridge + ATAPI devices, maybe the ATAPI_ENABLE_DMADIR
>> workaround should also be turned on as well. (in linux/libata.h)
>>
>> My JMicron 20330 bridge + SiI 3112 can handle ATAPI DMA without
>> the ATAPI_ENABLE_DMADIR workaround. However, the SiI 3611 bridge seems
>> need it.
>
>
> Is there any way to make this thing automatic? 'Recompile with #define
> tweak if you have some invisible bridge chip' doesn't sound too hot.
>
The bridge is transparent to the software. So, it's hard to detect the chip
used. Maybe the SiImage developers know how to detect the chip?
For the time being, maybe we can use a module paramater instead of
compile time #ifdef. Will submit a patch for this later.
--
Albert
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.