Russell King <[EMAIL PROTECTED]> wrote:
> v. whining
>
> 1. To utter a plaintive, high-pitched,
> protracted sound, as in pain,
>fear, supplication, or complaint.
> 2. To complain or protest in a childish fashion.
> 3. To produce a sustained noise of relatively
> high pitch: je
On Wed, 13 Jul 2005 23:28:15 -0700, Jesse Brandeburg <[EMAIL PROTECTED]> wrote:
>On 7/13/05, Mikhail Kshevetskiy <[EMAIL PROTECTED]> wrote:
>> symptom
>> ===
>> modprobe e100
>> ifconfig eth0 netmask
>>
>> result:
>> ===
>> SIOCADDRT: Network is unreachable
>>
>> There were no such err
On Thu, 2005-07-14 at 14:04 +1000, Dave Airlie wrote:
> Hi,
> I'd like to move the interface DRM header files (drm.h and *_drm.h)
> somewhere more useful and also more "user-space" visible, (i.e. so
> kernel-headers could start picking them up.)
I would suggest making ONE userspace visible header,
> IOW, nothing ever sees any "variable frequency", and there's never any
> question about what the timer tick is: the timer tick is 2kHz as far as
> everybody is concerned. It's just that the ticks sometimes come in
> "bunches of 20".
btw we can hide all of this a lot nicer from just about the
On Thu, 2005-07-14 at 11:03 +0530, RVK wrote:
> Robert Hancock wrote:
>
> > RVK wrote:
> >
> >> Can anyone suggest me how to get the threadId using 2.6.x kernels.
> >> pthread_self() does not work and returns some -ve integer.
> >
> >
> > What do you mean, negative integer? It's not an integer, it
> /** The major number of the fuse character device */
> -#define FUSE_MAJOR 10
> +#define FUSE_MAJOR MISC_MAJOR
OK, this makes some sense.
> /** The minor number of the fuse character device */
> -#define FUSE_MINOR 229
> +#define FUSE_MINOR MISC_DYNAMIC_MINOR
Why?
FUSE has an allocated fix
On Monday 11 July 2005 10:29, Marc Haber wrote:
> After rebooting, the VLANs on the Intel-based interfaces worked fine, while
> the tg3-based interfaces didn't answer to tagged ARP requests. The untagged
> VLAN on the tg3-based interfaces was fine as well. When tcpdumping the
> subinterfaces, I saw
On Wed, Jul 13, 2005 at 10:53:19AM -0700, karl malbrain wrote:
> I've also noticed that the boot sequence probes for modems on the serial
> ports. Is it possible that 8250.c is having a problem servicing an
> interrupt from a character/state-change left over from this initialization?
I did ask fo
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> I suspect that it is impractical to reprogram the PIT on a very fine
> granularity.
yes - reprogramming the PIT can take up to 10 usecs even on recent PCs.
(in fact the cost is pretty much system-independent due to PIO.) On
modern, PIT-less times
Hi all,
I'm in the process of overhauling some aspects of the PCI subsystem.
This patch series is a rewrite of the PCI probing and detection code.
It creates a well defined PCI bus class API and allows a standard PCI
driver to bind to PCI bridge devices. This results in the following:
* cleaner
This patch adds very simplistic suspend/resume support for the PCI
bridge driver. Soon this will be replaced with bridge specific code,
but for now we'll try using pci_save/restore_state().
Signed-off-by: Adam Belay <[EMAIL PROTECTED]>
--- a/drivers/pci/bus/pci-bridge.c 2005-07-14 04:22:13.
This patch updates pci_scan_bus_parented() and also has some important
fixes to the PCI bus class.
Signed-off-by: Adam Belay <[EMAIL PROTECTED]>
--- a/drivers/pci/bus/bus.c 2005-07-12 01:08:20.0 -0400
+++ b/drivers/pci/bus/bus.c 2005-07-13 02:01:57.0 -0400
@@ -81,7 +81,7 @
This patch adds pci_add_bus() for PCI bus registration. It also moves
pci_remove_bus() from remove.c to bus/bus.c for consistency.
Signed-off-by: Adam Belay <[EMAIL PROTECTED]>
--- a/drivers/pci/bus/bus.c 2005-07-12 00:59:58.0 -0400
+++ b/drivers/pci/bus/bus.c 2005-07-12 01:01:1
This patch moves all device registration related functions to
bus/device.c.
Signed-off-by: Adam Belay <[EMAIL PROTECTED]>
--- a/drivers/pci/bus/device.c 1969-12-31 19:00:00.0 -0500
+++ b/drivers/pci/bus/device.c 2005-07-12 01:32:41.0 -0400
@@ -0,0 +1,187 @@
+/*
+ * device.c - PC
This patch adds a basic PCI<->PCI bridge driver that utilizes the new
PCI bus class API.
Signed-off-by: Adam Belay <[EMAIL PROTECTED]>
--- a/drivers/pci/bus/pci-bridge.c 1969-12-31 19:00:00.0 -0500
+++ b/drivers/pci/bus/pci-bridge.c 2005-07-08 02:18:43.0 -0400
@@ -0,0 +1
This patch prevents the root bridge drivers from using the legacy API.
It also updates the PCI<->PCI bridge driver to better coexist with the
legacy code.
Signed-off-by: Adam Belay <[EMAIL PROTECTED]>
--- a/drivers/pci/bus/pci-bridge.c 2005-07-14 02:17:04.735566464 -0400
+++ b/drivers/pci/bu
This patch divides the PCI probing code into three smaller files:
config.c - PCI configuration space parsing
probe.c - PCI bus detection routines
bus.c - the PCI bus class driver core
These files are placed in the new directory "drivers/pci/bus". It will
be used for functions related to the PCI
The PCI bridge driver now checks if changing bridge_ctrl is necessary.
It also restores the original bridge_ctl settings when finished scanning
for devices. Finally, a pci_bus setup fix is included.
Signed-off-by: Adam Belay <[EMAIL PROTECTED]>
--- a/drivers/pci/bus/pci-bridge.c 2005-07-12
This patch prevents the PCI<->PCI bridge driver from binding to PCI
express devices. This is needed to coexist with the PCI express root
port driver. Eventually we may want to rework and better integrate
linux PCI express link support, but for now this should work.
Signed-off-by: Adam Belay <[EM
"My expectation is if we want to beat the competition, we'll want
the ability to go *under* 100Hz."
>>>
>>> What does Windows do here?
>>
>> windows xp base rate is 100Hz... but multimedia apps can ask for almost
>
> 83Hz
Well, Windoes 98 (vmmon) shows very different ones:
/dev/vmmon[
>Looks like, since [1] was merged, a blanked console
>(due to inactivity for example) doesn't get unblanked
>anymore when new output is written to it.
The console is unblanked when you hit a key (or probably move a mouse too),
not when some application outputs something on stdout/stderr/etc.
>[
On Thu 14 Jul 2005, Neil Brown wrote:
> > Aug 9 20:09:18 localhost kernel:
> > {:raid0:raid0_make_request+472}
>
> Looks like the problem is at:
> sector_div(x, (unsigned long)conf->hash_spacing);
> zone = conf->hash_table[x];
[...]
> Anyway, the following patch, if i
On Wed, Jul 13, 2005 at 05:29:32PM -0400, Chuck Ebbert wrote:
> On Wed, 13 Jul 2005 at 00:23:42 -0700, Andrew Morton wrote:
>
> >>...and BTW why does every line in the series file have a trailing space?
> >
> > Not in my copy of
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6
Hi,
>> /** The minor number of the fuse character device */
>> -#define FUSE_MINOR 229
>> +#define FUSE_MINOR MISC_DYNAMIC_MINOR
>
>FUSE has an allocated fix minor. Dynamic minor is much harder to
>handle with legacy /dev (not udev).
How many users of 2.6.13 and up really do not have/run udev?
I just tried 2.6.12.2 with skas-V8.2. The server (otherwise reliable),
had a kernel crash (which I was unable to capture) within a couple of
hours of boot up.
Regards, Peter
Blaisorblade wrote:
On Tuesday 12 July 2005 00:26, Peter wrote:
Nothing in the logs prior to the first error message
On Wed, 13 Jul 2005, Lee Revell wrote:
> Did anyone else find this strange:
>
> "The RTC is used in periodic mode to provide the system profiling
> interrupt on uni-processor systems and the clock interrupt on
> multi-processor systems."
>
> We just take NR_CPUS * HZ timer interrupts per second,
Chuck Ebbert wrote:
>Looks like Quilt is adding the space during push/pop operations. Only the
> lines it has touched in the series file have the trailing space.
Quilt versions prior to 0.39 would add a trailing space to the series
file entry when doing a quilt refresh with the default -p1 pa
> >> /** The minor number of the fuse character device */
> >> -#define FUSE_MINOR 229
> >> +#define FUSE_MINOR MISC_DYNAMIC_MINOR
> >
> >FUSE has an allocated fix minor. Dynamic minor is much harder to
> >handle with legacy /dev (not udev).
>
> How many users of 2.6.13 and up really do not have
>> Patch 19/19 contains a .po file.
>
>Yes, the patch 19/19 contains the translation of configuration...
>I see Linus doesn't want the huge language files in kernel source.
>But what is Linus opinion about this little .po file?
What is little? Given that there's 'roughly' 119 languages (find
/usr
On Wed, 13 Jul 2005, Benjamin LaHaise wrote:
> That's one thing I truely dislike about the current timer code. If we
> could program the RTC interrupt to come into the system as an NMI (iirc
> oprofile already has code to do this), we could get much better TSC
> interpolation since we would be
Vinay Venkataraghavan wrote:
I know how to implement buffer overflow attacks. But
how would an intrusion detection system detect a
buffer overflow attack.
Buffer overflow attacks vary, but have one thing in common. The
overflow string is much longer than what's usual for the app/protocol in
Arjan van de Ven wrote:
On Thu, 2005-07-14 at 11:03 +0530, RVK wrote:
Robert Hancock wrote:
RVK wrote:
Can anyone suggest me how to get the threadId using 2.6.x kernels.
pthread_self() does not work and returns some -ve integer.
What do you mean, negative integer? I
Hi,
--- Jan Engelhardt <[EMAIL PROTECTED]>
escribió:
> The console is unblanked when you hit a key (or
> probably move a mouse too),
> not when some application outputs something on
> stdout/stderr/etc.
Before 2.6.12-rc2, the console was unblanked by just
writing to the console.
For keyboardles
Linus Torvalds <[EMAIL PROTECTED]> writes:
> And in short-term things, the timeval/jiffie conversion is likely to be a
> _bigger_ issue than the crystal frequency conversion.
>
> So we should aim for a HZ value that makes it easy to convert to and from
> the standard user-space interface formats.
I don't think buffer overflow has anything to do with transparent proxy.
Transparent proxying is just doing some protocol filtering. Still the
proxy code may have some buffer overflows. The best way is first to try
avoiding any buffer overflows and take programming precautions. Other
way is to
On Thu, 2005-07-14 at 15:36 +0530, RVK wrote:
> >
> >it doesn't return a number it returns a pointer ;) or a floating point
> >number. You don't know :)
> >
> >what it returns is a *cookie*. A cookie that you can only use to pass
> >back to various pthread functions.
> >
> >
> >
> Hahaha..co
On my x86-64 laptop (Targa Visionary 811: Athlon64 + VIA chipset,
Arima OEM:d HW also sold by eMachines and others), ACPI is broken
and hangs the x86-64 2.6.13-rc3 kernel.
During boot, ACPI reduces the screen's brightness (it's always
done this in the x86-64 kernels but not the i386 ones), so I
ha
On Thu, 2005-07-14 at 15:36 +0530, RVK wrote:
> bits/pthreadtypes.h:150:typedef unsigned long int pthread_t;
That's an implementation detail which you cannot determine any
information from.
What Arjan is saying is that pthread_t is a cookie -- this means that
you cannot interpret it in any way,
On Thu, Jul 14, 2005 at 12:12:02AM -0700, Sam Song wrote:
> It turned out the conflict of uart init definition
> like MPC10X_UART0_IRQ in ../syslib/mpc10x_common.c
> and SERIAL_PORT_DFNS in ../platform/sandpoint.h. By
> now, only MPC10X_UART0_IRQ stuff is needed.
> SERIAL_PORT_DFNS should be omi
- Bug fixes:
1) On CX88 code, some cards needs to have audio reprogramed after
changing video channel;
2) Tuner autodetection code seems not to work on some cards. Now,
no_autodetect insmod option allows disabling autodetection code;
3) Minor fixes at tea5767 to reduce integer trunc;
4) T
Ian Campbell wrote:
On Thu, 2005-07-14 at 15:36 +0530, RVK wrote:
bits/pthreadtypes.h:150:typedef unsigned long int pthread_t;
That's an implementation detail which you cannot determine any
information from.
What Arjan is saying is that pthread_t is a cookie -- this means that
you c
On Thu, 2005-07-14 at 16:32 +0530, RVK wrote:
> Ian Campbell wrote:
> >What Arjan is saying is that pthread_t is a cookie -- this means that
> >you cannot interpret it in any way, it is just a "thing" which you can
> >pass back to the API, that pthread_t happens to be typedef'd to unsigned
> >long
Arjan van de Ven wrote:
On Thu, 2005-07-14 at 15:36 +0530, RVK wrote:
it doesn't return a number it returns a pointer ;) or a floating point
number. You don't know :)
what it returns is a *cookie*. A cookie that you can only use to pass
back to various pthread functions.
Hahaha.
Ian Campbell wrote:
On Thu, 2005-07-14 at 16:32 +0530, RVK wrote:
Ian Campbell wrote:
What Arjan is saying is that pthread_t is a cookie -- this means that
you cannot interpret it in any way, it is just a "thing" which you can
pass back to the API, that pthread_t happens to be typedef'
I attach a patch that modifies the mount program in the util-linux
package so that if /etc/mtab is a symbolic link (to a location outside
of /proc) then mount accesses mtab at the target of the symbolic link.
This feature is useful when the root filesystem is mounted read-only;
/etc/mtab can then
>Before 2.6.12-rc2, the console was unblanked by just
>writing to the console.
>For keyboardless and mouseless systems (which is my
>case, embedded) this new behaviour is a bit annoying.
Interesting. I have observed the following (2.6.13-rc1 and a little
earlier):
mplayer bla.avi -vo cvidix
The setup-bus code doesn't work correctly for configurations
with more than one display adapter in the same PCI domain.
This stuff actually is a leftover of an early 2.4 PCI setup code
and apparently it stopped working after some "bridge_ctl" changes.
So the best thing we can do is just to remove i
Stelian Pop schrieb:
> After resyncing cogito to the latest version (which incorporates the
> 'pack' changes, which were causing the failure), it does indeed work
> again, when using rsync.
>
hm, i haven't updated my git-tree (linux-2.6.git) for a while and i got
similiar error messages. i update
Hi Linus, please pull from
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/aia21/ntfs-2.6.git/HEAD
This is a big NTFS update. It was meant for as soon as 2.6.12 was released
but it was delayed due to the need for a patch I submitted to Andrew for -mm
to make it to the mainline kernel (which it
On Thu, Jul 14, 2005 at 09:42:18AM +0200, Arjan van de Ven wrote:
> > IOW, nothing ever sees any "variable frequency", and there's never any
> > question about what the timer tick is: the timer tick is 2kHz as far as
> > everybody is concerned. It's just that the ticks sometimes come in
> > "bu
RVK wrote:
I don't think buffer overflow has anything to do with transparent
proxy. Transparent proxying is just doing some protocol filtering.
A transparent proxy is a protocol filter, which is why it is an
ideal way of detecting protocol-dependent buffer overflow attacks.
The detection code
On Thu, Jul 14, 2005 at 12:25:40PM +0200, Krzysztof Halasa wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > And in short-term things, the timeval/jiffie conversion is likely to be a
> > _bigger_ issue than the crystal frequency conversion.
> >
> > So we should aim for a HZ value that mak
Proxies can be a good way of filtering but it can't avoid buffer
overflows. It can only increase it. More code more bugs. If it is
running on a hardware firewall as a service then its more dangerous as
once it is compramised then IDS signatures also can be deleated :-). No
use of IDS the right
> >
> So then what is the meaning of that typedef and why its still there ?
the typedef means that the *IMPLEMENTATION* uses an unsigned long to
store its cookie in.
>
> >Other implementations are allowed to use different types for this. In
> >fact, I'd be surprised if NPTL and LinuxThreads wou
Patrick, Hebert,
This issues stills seems to be in the latest trees - is this patch or a
variation on it still bumping around?
Thanks!
Yair Itzhaki wrote:
Can anyone propose a patch that I can start checking?
I have come up with the following:
--- net/core/netfilter.c.orig 2005-04-18 2
On Thu, Jul 14, 2005 at 02:25:43PM +0200, Arjan van de Ven wrote:
> pure luck. NPTL threading uses it to store a pointer to per thread info
> structure; other threading (linuxthreads) may have stored a pid there to
> identify the internal thread. nptl is 2.6 only so you might have
> switched implem
Am Mittwoch, 13. Juli 2005 16:01 schrieb K.R. Foley:
> Ingo Molnar wrote:
> > * Chuck Harding <[EMAIL PROTECTED]> wrote:
> >
> >
> >>>CC [M] sound/oss/emu10k1/midi.o
> >>>sound/oss/emu10k1/midi.c:48: error: syntax error before '__attribute__'
> >>>sound/oss/emu10k1/midi.c:48: error: syntax error
Hello,
I am not sure the "rm -rf linux/arch/i386/boot" is an acceptable delta
for the current code management system, but anyways it is only the second
step - after the attached patch has been discussed, modified and
hopefully accepted.
Unfortunately this second step will break compatibility w
RVK wrote:
Proxies can be a good way of filtering but it can't avoid buffer
overflows.
Yes they can - did you read and udnerstand my previous post at all?
A proxy _can_ avoid a buffer overflow by noticing the
anomalously large data item and simply refuse to pass
it on to the real server! The
> And you certainly shouldn't be using gettid () syscall in NPTL, as it
> is just an implementation detail that there is a 1:1 mapping between
> NPTL threads and kernel threads. It can change at any time.
Maybe I missed the point, but I thought the 1:1 mapping between NPTL
threads and kernel th
mb_cache_shrink() tries to free all sort of mbcache in the lru list.
All user of mb_cache_shrink() are ext2/ext3 xattr.
Signed-off-by: Akinobu Mita <[EMAIL PROTECTED]>
--- 2.6-rc/fs/mbcache.c.orig2005-07-14 20:40:34.0 +0900
+++ 2.6-rc/fs/mbcache.c 2005-07-14 20:43:42.0 +0900
Daniel McNeil <[EMAIL PROTECTED]> writes:
> This patch relaxes the direct i/o alignment check so that user addresses
> do not have to be a multiple of the device block size.
The original reason for this limit was that lots of drivers
(not only IDE) explode when you give them odd sizes. Sometimes
On 7/14/05, Dave Airlie <[EMAIL PROTECTED]> wrote:
> > > I'm thinking include/linux/drm/
> > > but include/linux would also be possible.
> > >
> > > Any suggestions or ideas?
> >
> > If you're in a mood to move things, how about moving drivers/char/drm
> > to drivers/video/drm.
>
> But that has li
Hi,
On Mon, 11 Jul 2005, Andrew Morton wrote:
> > > Hi Andrew, can you please merge relayfs? It provides a low-overhead
> > > logging and buffering capability, which does not currently exist in
> > > the kernel.
> >
> > While the code is pretty nicely in shape it seems rather pointless to
> > m
On 7/14/05, Ivan Kokshaysky <[EMAIL PROTECTED]> wrote:
> The setup-bus code doesn't work correctly for configurations
> with more than one display adapter in the same PCI domain.
> This stuff actually is a leftover of an early 2.4 PCI setup code
> and apparently it stopped working after some "bridg
Ingo Molnar wrote:
* Chuck Harding <[EMAIL PROTECTED]> wrote:
I missed getting -51-29 but just booted up -51-30 and all is well.
Thanks. Just out of curiosity, what was changed between -51-28, 29,
and 30?
-51-29 had new IO-APIC optimizations - and i reverted them in -51-30.
Ingo
On Wed, Jul 13, 2005 at 11:04:56AM -0600, Alex Williamson wrote:
> On Mon, 2005-07-11 at 15:17 -0600, Alex Williamson wrote:
> >No, I think this is a problem with the broken A2 UARTs getting
> > confused in serial8250_set_sleep(). If I remove either UART_CAP_SLEEP
> > or UART_CAP_EFR from the
I always thought;
First 446 bytes are boot code and all
Next 64 bytes are for 4 partition records, 16 bytes each
Last 2 bytes are signature
?
-fd
On Wed, 2005-07-13 at 06:24, Jan Engelhardt wrote:
> > Guys, thanks a lot for the explanations!
> >
> > Actually, it seems like one can backup info
Jakub Jelinek wrote:
On Thu, Jul 14, 2005 at 02:25:43PM +0200, Arjan van de Ven wrote:
pure luck. NPTL threading uses it to store a pointer to per thread info
structure; other threading (linuxthreads) may have stored a pid there to
identify the internal thread. nptl is 2.6 only so you might
On Thu, Jul 14, 2005 at 03:53:44PM +0400, Ivan Kokshaysky wrote:
> The setup-bus code doesn't work correctly for configurations
> with more than one display adapter in the same PCI domain.
> This stuff actually is a leftover of an early 2.4 PCI setup code
> and apparently it stopped working after s
2005/7/14, Nathan Scott <[EMAIL PROTECTED]>:
> On Wed, Jul 13, 2005 at 06:22:28PM +0300, Yura Pakhuchiy wrote:
> > I found patch by Greg Ungreger to fix this problem, but why it's still
> > not in mainline? Or it's a gcc problem and should be fixed by gcc folks?
>
> Yes, IIRC the patch was incorre
Karsten Wiese wrote:
Am Mittwoch, 13. Juli 2005 16:01 schrieb K.R. Foley:
Ingo Molnar wrote:
* Chuck Harding <[EMAIL PROTECTED]> wrote:
CC [M] sound/oss/emu10k1/midi.o
sound/oss/emu10k1/midi.c:48: error: syntax error before '__attribute__'
sound/oss/emu10k1/midi.c:48: error: syntax error
Helge Hafting wrote:
RVK wrote:
Proxies can be a good way of filtering but it can't avoid buffer
overflows.
Yes they can - did you read and udnerstand my previous post at all?
A proxy _can_ avoid a buffer overflow by noticing the
anomalously large data item and simply refuse to pass
it on t
On 7/14/05, Russell King <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 14, 2005 at 03:53:44PM +0400, Ivan Kokshaysky wrote:
> > The setup-bus code doesn't work correctly for configurations
> > with more than one display adapter in the same PCI domain.
> > This stuff actually is a leftover of an early 2.
K.R. Foley wrote:
Karsten Wiese wrote:
Am Mittwoch, 13. Juli 2005 16:01 schrieb K.R. Foley:
Ingo Molnar wrote:
* Chuck Harding <[EMAIL PROTECTED]> wrote:
CC [M] sound/oss/emu10k1/midi.o
sound/oss/emu10k1/midi.c:48: error: syntax error before
'__attribute__'
sound/oss/emu10k1/midi.c:4
K.R. Foley wrote:
K.R. Foley wrote:
Karsten Wiese wrote:
Am Mittwoch, 13. Juli 2005 16:01 schrieb K.R. Foley:
Ingo Molnar wrote:
* Chuck Harding <[EMAIL PROTECTED]> wrote:
CC [M] sound/oss/emu10k1/midi.o
sound/oss/emu10k1/midi.c:48: error: syntax error before
'__attribute__'
sound/
On Thu, 2005-07-14 at 11:24 +0200, Jan Engelhardt wrote:
> "My expectation is if we want to beat the competition, we'll want
> the ability to go *under* 100Hz."
> >>>
> >>> What does Windows do here?
> >>
> >> windows xp base rate is 100Hz... but multimedia apps can ask for almost
> >
>
On July 8 I sent out a patch which re-implemented the rcu-refcounting
of the LSM list in stacker for the sake of supporting safe security
module unloading. (patch reattached here for convenience) Here are
some performance results with and without that patch. Tests were run
on a 16-way ppc64 mach
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Wed, 13 Jul 2005, Jan Engelhardt wrote:
> >
> > No, some kernel code causes a triple-fault-and-reboot when the HZ is >=
> > 10KHz. Maybe the highest possible value is 8192 Hz, not sure.
>
> Can you post the triple-fault message? It really shouldn't
RVK wrote:
Ian Campbell wrote:
On Thu, 2005-07-14 at 15:36 +0530, RVK wrote:
bits/pthreadtypes.h:150:typedef unsigned long int pthread_t;
That's an implementation detail which you cannot determine any
information from.
What Arjan is saying is that pthread_t is a cookie -- this means
If bailing out because there is nothing to receive in rp_do_receive(),
tty_ldisc_deref is not called. Failure to do so increases the ref count
and causes release_dev() to hang since it can't get the ref count to 0.
---
Signed-off-by: Michal Ostrowski <[EMAIL PROTECTED]>
drivers/char/rocket.c
Alex Williamson wrote:
>
> David, would you mind
> trying this on the XR16L255x part? (ie. don't use console=ttyS, use
> console=uart,...) Thanks,
I wasn't even aware you could do this...
These are the serial ports I have:
ttyS0 at MMIO 0xc800 (irq = 15) is a XScale IXP425 internal
ttyS1
On Thu, Jul 14, 2005 at 04:50:01PM +0300, Yura Pakhuchiy wrote:
> 2005/7/14, Nathan Scott <[EMAIL PROTECTED]>:
> > On Wed, Jul 13, 2005 at 06:22:28PM +0300, Yura Pakhuchiy wrote:
> > > I found patch by Greg Ungreger to fix this problem, but why it's still
> > > not in mainline? Or it's a gcc proble
2005/7/14, Christoph Hellwig <[EMAIL PROTECTED]>:
> On Thu, Jul 14, 2005 at 04:50:01PM +0300, Yura Pakhuchiy wrote:
> > 2005/7/14, Nathan Scott <[EMAIL PROTECTED]>:
> > > On Wed, Jul 13, 2005 at 06:22:28PM +0300, Yura Pakhuchiy wrote:
> > > > I found patch by Greg Ungreger to fix this problem, but
On Thu, Jul 14, 2005 at 05:45:15PM +0300, Yura Pakhuchiy wrote:
> Yes, but a lof of people use older versions of compilers and suffer
> from this bug.
> I personally was very unhappy when lost my data.
then host the patch somewhere and make sure to apply it.
-
To unsubscribe from this list: send
On Wednesday 13 July 2005 17:38, James Bottomley wrote:
> [PATCH] Remove i386_ksyms.c, almost
>
> made files like smp.c do their own EXPORT_SYMBOLS. This means that all
> subarchitectures that override these symbols now have to do the exports
> themselves. This patch adds the exports for voyager
On Thu, 2005-07-14 at 10:38 +0200, Ingo Molnar wrote:
> - there are real-time applications (robotic environments: fast rotating
>tools, media and mobile/phone applications, etc.) that want 10
>usecs precision. If such users increased HZ to 100,000 or even
>1000,000, the current timer i
Andy Isaacson wrote:
> Yesterday I booted my laptop to 2.6.13-rc2-mm1, suspended to swsusp, and
> then resumed. It ran fine overnight, including a fair amount of IO
> (running firefox, rsyncing ~/Mail/archive from my mail server, hg pull,
> etc). This morning I did a swsusp:
>
> echo shutd
Roman Zippel writes:
> Hi,
>
> On Mon, 11 Jul 2005, Andrew Morton wrote:
>
> > > > Hi Andrew, can you please merge relayfs? It provides a low-overhead
> > > > logging and buffering capability, which does not currently exist in
> > > > the kernel.
> > >
> > > While the code is pretty ni
On Thu, 14 Jul 2005, Lee Revell wrote:
> On Thu, 2005-07-14 at 10:38 +0200, Ingo Molnar wrote:
> > - there are real-time applications (robotic environments: fast rotating
> >tools, media and mobile/phone applications, etc.) that want 10
> >usecs precision. If such users increased HZ to 10
On Thu, Jul 14, 2005 at 09:21:07AM -0500, [EMAIL PROTECTED] wrote:
> On July 8 I sent out a patch which re-implemented the rcu-refcounting
> of the LSM list in stacker for the sake of supporting safe security
> module unloading. (patch reattached here for convenience) Here are
> some performance
On Thu, 2005-07-14 at 08:02 -0700, Christoph Lameter wrote:
> I doubt that increasing the timer frequency is the way to go to solve
> these issues. HZ should be as low as possible and we should strive for
> a tickless system.
Agreed. Most of those applications are driven by their own interrupt
s
On Thu, 2005-07-14 at 07:23 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > > The whole point of using a semaphore in the pagebuf is because there
> > > is no tracking of who "owns" the lock so we can actually release it
> > > in a different context. Semaphores were in
Take a look at FUSE, it should be able to do all you need
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Thu, 2005-07-14 at 06:18, Andi Kleen wrote:
> Daniel McNeil <[EMAIL PROTECTED]> writes:
>
> > This patch relaxes the direct i/o alignment check so that user addresses
> > do not have to be a multiple of the device block size.
>
> The original reason for this limit was that lots of drivers
> (n
> It was always effectual for IO where the mask is 0x.
Okay, point taken :) So for cases of base == maxbase, why would we ever
want to return a nonzero value? What is the intended purpose of the
second part of that conditional?
-
To unsubscribe from this list: send the line "unsubscribe lin
Hello!
The attached patch passed about 36 hours of torture test on each of two
4-CPU x86 machines (about 100 passes through the torture-test script), so
am officially declaring it to be semi-sane. That said, on eight runs of
kernbench+LTP (also on 4-CPU x86 machines), only six passed, and the oth
Hi kernel.
* kernel <[EMAIL PROTECTED]> dixit:
> First 446 bytes are boot code and all
> Next 64 bytes are for 4 partition records, 16 bytes each
> Last 2 bytes are signature
And that's right, but only for the MBR. If you set up an extended
partition in the MBR, the partition table for t
Hi Willy,
I think at least I can remove the LOCK instruction when the lock is already
held by someone else and enter the spinning wait directly, right?
0: cmpb $0, slp
jle 2f# lock is not available, then spinning
directly without locking the bus
1: lock; decb slp
Hello,
I would like to get some feedback on this patch for the kernel. It's sole
purpose is to help in reducing boot time by not waiting to synchronize the
clock edge with the hardware clock. This when combined with other boot
reduction patched can bring the kernel boot time to well under 10 s
1 - 100 of 323 matches
Mail list logo
