Hi Ralf,
On Thu, 3 Feb 2005 13:37:15 +0100
Ralf Baechle <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 31, 2005 at 07:46:18AM +0900, Yoichi Yuasa wrote:
>
> > This patch adds iomap functions to MIPS system.
>
> And it still only works for a single PCI bus.
Which boards are there a problem?
ocelot-c
On Thu, Feb 03, 2005 at 02:19:01PM -0800, David S. Miller wrote:
>
> They are for cases where you want strict ordering even for the
> non-return-value-giving atomic_t ops.
I see. I got atomic_dec and atomic_dec_and_test mixed up.
So the problem isn't as big as I thought which is good. sk_buff
On Friday, 4 of February 2005 00:34, Nigel Cunningham wrote:
> Hi.
>
> On Fri, 2005-02-04 at 10:15, Rafael J. Wysocki wrote:
> > Instead of trying to blow up the battery I used the patch that forces the
> > CPU
> > to 800 MHz and it apparently survives resuming on batteries - at least 3
> >
Hi,
(B
(BOn 03 Feb 2005 02:58:02 -0700
(B[EMAIL PROTECTED] (Eric W. Biederman) wrote:
(B
(B> Itsuro Oda <[EMAIL PROTECTED]> writes:
(B>
(B> > Hi,
(B> >
(B> > This is not for kdump but an experience of our project(mkdump).
(B> > The dump kernel(not SMP config) boot hangs if
On Thursday 03 February 2005 21:12, Mark A. Greer wrote:
> > >+ mv64xxx_i2c_fsm(drv_data, status);
> >
> >It can set drv_data->rc to -ENODEV or -EIO. In both cases ->action goes to
> >MV64XXX_I2C_ACTION_SEND_STOP and mv64xxx_i2c_do_action() will writel()
> >something. Is it correct to
Rik van Riel writes:
> I'm not convinced. Zeroing a page takes 2000-4000 CPU
> cycles, while faulting the page from RAM into cache takes
> 200-400 CPU cycles per cache line, or 6000-12000 CPU
> cycles.
On my G5 it takes ~200 cycles to zero a whole page. In other words it
takes about the same
Hi,
On Thu, 2005-02-03 at 22:42, Mikael Pettersson wrote:
> I believe there is some accounting error in the ext3 code
> for the case when CONFIG_EXT3_FS_XATTR is not selected.
>
> Whenever any one of my development boxes triggers an fsck
> at boot because some file system, usually /, has been
Hi,
On Thursday, 3 of February 2005 23:00, Pavel Machek wrote:
> Hi!
>
> > > You may not run k8 notebook on max frequency on battery. Your system
> > > will crash; and you might even damage battery.
> >
> > When I don't compile in cpufreq, it seems to run at 1,8 GHz (the max)
> > all the time,
Hi.
On Fri, 2005-02-04 at 10:15, Rafael J. Wysocki wrote:
> Instead of trying to blow up the battery I used the patch that forces the CPU
> to 800 MHz and it apparently survives resuming on batteries - at least 3
> times out of 3 attempts (I'll try some times more tomorrow).
>
> It seems to boot
> "AG" == Andreas Gruenbacher <[EMAIL PROTECTED]> writes:
AG> On Wed, 2005-02-02 at 11:50, Herbert Xu wrote:
>> What if a/b aren't aligned?
AG> If people sort arrays that are unaligned even though the
AG> element size is a multiple of sizeof(long) (or sizeof(u32)
AG> as Matt proposes), they
Hi,
On 03 Feb 2005 02:00:51 -0700
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
> A better description is probably make a list of memory regions
> using an ELF header data structure in user space.
> Use sys_kexec_load to put that list the dump kernel and a little
> big of glue code in the
On Fri, 4 Feb 2005 01:27:05 +1100
Anton Blanchard <[EMAIL PROTECTED]> wrote:
> Its difficult stuff, everyone gets it wrong and Andrew keeps
> hassling me to write up a document explaining it.
Ok, here goes nothing. Can someone run with this? It should
be rather complete, and require only minor
On Thursday, 3 of February 2005 15:22, Pavel Machek wrote:
> Hi!
>
> > > > So, would it be acceptable to check in _suspend() if the state is S4
> > > > and drop the frequency in that case or do nothing otherwise?
> > >
> > > No. The point is that this is _very_ system-specific. Some systems
On Thu, Feb 03, 2005 at 10:41:33PM +0100, Ingo Molnar wrote:
> * Bill Huey <[EMAIL PROTECTED]> wrote:
> > It's clever that they do that, but additional control is needed in the
> > future. jackd isn't the most sophisticate media app on this planet (not
> > too much of an insult :)) [...]
>
> i
I believe there is some accounting error in the ext3 code
for the case when CONFIG_EXT3_FS_XATTR is not selected.
Whenever any one of my development boxes triggers an fsck
at boot because some file system, usually /, has been mounted
sufficiently many times, an inconsistency error occurs:
Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> I hope that Roland's changes for higher resolution of cputime would
> make that possible. But this is Jay's thing not mine. I just want to make
> sure that the CSA patches does not get in the way of our attempts to
> improve the performance of the
Hi!
> > You may not run k8 notebook on max frequency on battery. Your system
> > will crash; and you might even damage battery.
>
> When I don't compile in cpufreq, it seems to run at 1,8 GHz (the max)
> all the time, on AC power as well as on battery. Along with what you're
> saying it leads
* Pavel Machek <[EMAIL PROTECTED]> [050203 02:57]:
> Hi!
>
> > > > > > > I used your config advices from second mail, still it does not
> > > > > > > work as
> > > > > > > expected: system gets "too sleepy". Like it takes a nap during
> > > > > > > boot
> > > > > > > after "dyn-tick: Maximum
Vojtech,
Here is a patch that exposes the IBM TrackPoint's extended properties
as well as scroll wheel emulation.
I would appreciate comments and suggestions to make this more acceptable.
Stephen
diff -uNr a/drivers/input/mouse/Makefile b/drivers/input/mouse/Makefile
---
Bartlomiej Zolnierkiewicz wrote:
Sorry for the delay.
On Mon, 17 Jan 2005 09:25:30 +, David Woodhouse <[EMAIL PROTECTED]> wrote:
On resume from sleep, via_set_speed() doesn't reinstate the correct DMA
mode, because it thinks the drive is already configured correctly. This
one-line hack is
On Thu, 3 Feb 2005, Andrew Morton wrote:
> Has any performance testing been done?
Jay did some performance testing and found minor performance increases
without my page fault patches. But then the performance without the page
fault patches is already so bad due to the page_table_lock
contention
On Thu, Feb 03, 2005 at 12:20:49PM -0800, Larry McVoy wrote:
> > As Peter said, once every 6 hours is fine. Or even more often, what
> > the heck, as I said in a previous post I don't think an incremental
> > export is that much costly. It could be done at the same time as
> > the -bkX patches...
Hi!
> > You may not run k8 notebook on max frequency on battery. Your system
> > will crash; and you might even damage battery.
>
> When I don't compile in cpufreq, it seems to run at 1,8 GHz (the max)
> all the time, on AC power as well as on battery. Along with what you're
> saying it leads
On Thu, 2005-02-03 at 09:11 +0100, Arkadiusz Miskiewicz wrote:
> On Thursday 03 of February 2005 07:38, Benjamin Herrenschmidt wrote:
>
> > > Are you seriously proposing this for 2.6.11??
> >
> > Well... There should be no problem with
> > add-try_acquire_console_sem.patch and
> >
> I really don't want to start a new BK flamewar. You asked what could
> you do and I said what would be nice to have. End of story.
>
> > - The idea that the granularity in CVS is unreasonable is pure
>
> I didn't say it was unreasonable, I said it could be better.
Sure, everything can
Bartlomiej Zolnierkiewicz wrote:
On Thu, 3 Feb 2005 14:32:29 +0100, Jens Axboe <[EMAIL PROTECTED]> wrote:
On Thu, Feb 03 2005, Bartlomiej Zolnierkiewicz wrote:
On Thu, 3 Feb 2005 12:37:10 +0100, Jens Axboe <[EMAIL PROTECTED]> wrote:
On Thu, Feb 03 2005, Bartlomiej Zolnierkiewicz wrote:
On Wed, 2
On Fri, 4 Feb 2005 07:30:10 +1100
Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 04, 2005 at 01:27:05AM +1100, Anton Blanchard wrote:
> >
> > Architectures should guarantee that any of the atomics and bitops that
> > return values order in both directions. So you dont need the
> >
* Paul Davis <[EMAIL PROTECTED]> wrote:
> >having this API on 2.4 kernels. But it would have one big advantage: it
> >would be evidently and trivially RT-safe :-)
>
> no small advantage.
>
> it has another big advantage from the user space perspective: no other
> information is required apart
On Thu, 03 Feb 2005 17:14:50 -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Bartlomiej Zolnierkiewicz wrote:
> > Sorry for the delay.
> >
> > On Mon, 17 Jan 2005 09:25:30 +, David Woodhouse <[EMAIL PROTECTED]>
> > wrote:
> >
> >>On resume from sleep, via_set_speed() doesn't reinstate the
>that might be all well and good, but i believe you still dont understand
>my point: for yield_to() to work the target task _needs to be running_.
correct, i did not understand. perhaps Con didn't either. my idea was
related to:
>in theory it would be possible to add two new syscalls:
Jon Smirl wrote:
Since it looks like ide is being worked on, can you convert ide to use
the PCI ROM access calls in drivers/pci/rom.c instead of directly
manipulating PCI config space? The new ROM calls work on all
architectures.
These are the places that need to be fix:
[EMAIL PROTECTED] ide]$
Giuseppe Bilotta <[EMAIL PROTECTED]> writes:
> Peter Osterlund wrote:
> > Only parse a "z == 127" packet as a relative Dualpoint stick packet if
> > the touchpad actually is a Dualpoint device. The Glidepoint models
> > don't have a stick, and can report z == 127 for a very wide finger. If
> >
* Paul Davis <[EMAIL PROTECTED]> wrote:
> >well, no. Unless i misunderstood your application model, you want
> >threads to sleep until they are woken up. So you want a very basic
> >sleep/wake mechanism. But yield_to() does not achieve that! yield_to()
> >will yield to _already running_ (i.e. in
Hi!
> > # dmsetup table /dev/mapper/volume1
> > 0 200 crypt aes-plain 0123456789abcdef0123456789abcdef 0 7:0 0
>
> > Obviously, root can in principle recover this password from the
> > running kernel but it seems silly to make it so easy.
>
> There seemed little point obfuscating it -
Vojtech Pavlik <[EMAIL PROTECTED]> writes:
> On Wed, Feb 02, 2005 at 11:58:05PM +0100, Peter Osterlund wrote:
>
> > In practice I don't think it will make any significant difference. What
> > the code should do depends on what you want to happen if you move the
> > mouse pointer 1/2 pixel with
While super-nifty, the new page_owner code assumes a contiguous
mem_map, which we don't all have. This patch changes the
iterator in the read_page_owner() to be a pfn instead of a
'struct page'. This makes it easy to jump around to different
non-contiuous 'struct pages' as with the
On Thursday, 3 of February 2005 15:20, Pavel Machek wrote:
> Hi!
>
> > > > > > On Thu, Feb 03, 2005 at 11:41:26AM +0100, Pavel Machek wrote:
> > > > > > > Okay, you are right, restoring it unconditionaly would be bad
> > > > > > > idea. Still it would be nice to tell cpufreq governor "please
> >
Paul Davis wrote:
There are several kernel-side attributes that would make JACK better from
my perspective:
* better ways to acquire and release RT scheduling
I'm no expert on the topic but it would seem to me that the mechanisms
associated with the capable() function are intended to provide a
* Bill Huey <[EMAIL PROTECTED]> wrote:
> > but Jack is right in practical terms: the audio folks achieved pretty
> > good results with the current IRQ threading mechanism, partly due to the
> > fact that the audio stack doesnt use softirqs, so all the
> > latency-critical activities are in the
>(it would be cleaner to use POSIX semaphores for this, but you mentioned
>the requirement for the mechanism to work on 2.4 kernels too - pthread
>spinlocks will work inter-process on 2.4 too, and will schedule nicely.)
can't work. pthread interprocess spinlocks are hopelessly non-RT safe
in
* Paul Davis <[EMAIL PROTECTED]> wrote:
> however, i don't agree that futexes are conceptually superior. they
> don't express the intended operation nearly as accurately as
> yield_to(tid) would. the operation is "i have nothing else to do, and
> i want to run next". a futex says "this
* Paul Davis <[EMAIL PROTECTED]> wrote:
> Just a reminder: setuid root is precisely what we are attempting to
> avoid.
>
> >If you have the source code for the programs then they could be modified
> >to drop the root euid after they've changed policy. Or even do the
>
> This is
This patch makes the hw_random driver a little more informative when it is
starting up -
currently, there is no easy way to tell if the driver detected any hardware.
The AMD driver does mention that it found the chip - this adds the same for the
VIA
and Intel sections of the driver.
Tested
On Thu, Feb 03, 2005 at 06:28:27AM -0800, Pallipadi, Venkatesh wrote:
>
> Hi John, Andrew,
>
>
> Can you check whether only the following change makes the problem go
> away. If yes, then it looks like a hardware issue.
>
> > hpet_writel(hpet_tick, HPET_T0_CMP);
> >+
> Basically I am thinking of something like this will be a good generic solution
> in place of simple two writes.
>
> for (i = 0 ; i ; i++) {
> hpet_writel(hpet_tick, HPET_T0_CMP);
> if (hpet_tick == hpet_readl(hpet_tick, HPET_T0_CMP))
> break;
> }
Makes sense. There
As requested by Andrew:
In the 2.6.11 development cycle function calls have been added to lots
of hot vm paths to do accounting. I think these should not go into the
final 2.6.1 release because these statistics can be collected in a different
way that does not require the updating of counters
Hi,
ChangeLog:
* sync with linux-2.6 tree
* merge "next bunch of IDE fixes (on the way to the driver-model)" serie
* merge via82cxxx resume fix
BK users:
bk pull bk://bart.bkbits.net/ide-dev-2.6
This will update the following files:
drivers/ide/Kconfig|8 -
Hi,
I think that many of us in this mailing list use strace
(http://www.liacs.nl/~wichert/strace/) for studying, debugging and
I am writing a paper about Strace under Linux version 2.4.22-1.2197.nptl
using the strace's man page as my principal reading source. Does anybody
heres knows others
Followup to: <[EMAIL PROTECTED]>
By author:Herbert Xu <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Have you looked at using initramfs and running the DHCP client in
> user space? You'll get a lot more freedom that way.
>
Note that the klibc distribution already contains a working
>> yield_to(tid) should not be too hard to implement. Ingo? What do you
>> think?
>
>i dont really like it - it's really the wrong interface to use. Futexes
>are a much better locking/signalling interface. yield_to() would not be
i agree in principle, and i was suprised to see Con express this
Pavel Roskin wrote:
All I want to do is to have a module that would create subdirectories
for some network interfaces under /sys/class/net/*/, which would contain
additional parameters for those interfaces. I'm not creating a new
subsystem or anything like that. sysctl is not good because the
* Eugeny S. Mints <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> >i have released the -V0.7.37-02 Real-Time Preemption patch, which can be
> >downloaded from the usual place:
> >
> > http://redhat.com/~mingo/realtime-preempt/
> Minor fix for deadlock tracer: "...acquired at XXX" may print
On Saturday 15 January 2005 11:03, Andrew Morton wrote:
> David Howells <[EMAIL PROTECTED]> wrote:
[]
> I'm not sure that we even use errno any more. The only syscall trap which
> the kernel internally takes now is execve(). Everything else is (or should
> be) just calling the sys_foo()
* Con Kolivas <[EMAIL PROTECTED]> wrote:
> > * real inter-process handoff. i am thinking of something like
> > sched_yield(), but it would take a TID as the target
> > of the yield. this would avoid all the crap we have to
> > go through to drive the graph of clients
Ingo Molnar wrote:
i have released the -V0.7.37-02 Real-Time Preemption patch, which can be
downloaded from the usual place:
http://redhat.com/~mingo/realtime-preempt/
Minor fix for deadlock tracer: "...acquired at XXX" may print caller's
of an up() eip instead of eip of caller of a down() in
On Fri, Feb 04, 2005 at 01:27:05AM +1100, Anton Blanchard wrote:
>
> Architectures should guarantee that any of the atomics and bitops that
> return values order in both directions. So you dont need the
> smp_mb__before_atomic_dec here.
I wasn't aware of this requirement before. However, if
Sorry for the delay.
On Mon, 17 Jan 2005 09:25:30 +, David Woodhouse <[EMAIL PROTECTED]> wrote:
> On resume from sleep, via_set_speed() doesn't reinstate the correct DMA
> mode, because it thinks the drive is already configured correctly. This
> one-line hack is sufficient to make it refrain
Paul Davis wrote:
* real inter-process handoff. i am thinking of something like
sched_yield(), but it would take a TID as the target
of the yield. this would avoid all the crap we have to
go through to drive the graph of clients with FIFO's and
write(2) and poll(2). Futexes
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > dl_make_stack_executable() will nicely return into user_input
> > > (at which time the stack has already become executable).
> >
> > wrong, _dl_make_stack_executable() will not return into user_input() in
> > your scenario, and your exploit
> As Peter said, once every 6 hours is fine. Or even more often, what
> the heck, as I said in a previous post I don't think an incremental
> export is that much costly. It could be done at the same time as
> the -bkX patches...
I'll see what I can do.
> Speaking from the out-BK point of view,
Greg KH wrote:
On Wed, Feb 02, 2005 at 04:48:39PM +, Linux Kernel Mailing List wrote:
ChangeSet 1.1992.2.74, 2005/02/02 08:48:39-08:00, [EMAIL PROTECTED]
[PATCH] Devices.txt, update with LANANA
Attached is diff for bringing devices.txt uptodate with lanana.
On Thu, Feb 03, 2005 at 11:30:56AM -0800, john stultz wrote:
> On Thu, 2005-02-03 at 06:28 -0800, Pallipadi, Venkatesh wrote:
> > Can you check whether only the following change makes the problem go
> > away. If yes, then it looks like a hardware issue.
> >
> > > hpet_writel(hpet_tick,
On Thu, Feb 03, 2005 at 11:51:27AM -0800, Stephen Hemminger wrote:
> Recent 2.6 does a more advanced form of port randomization already
> using address hash at connect time. tcp_v4_get_port is only used for
> the case of applications that explicitly bind to port zero to find a
> free port.
Is
On Wednesday 02 February 2005 12:55, you wrote:
> Pekka Enberg wrote:
> > On Tue, 1 Feb 2005 03:28:31 +, [EMAIL PROTECTED]
> >
> > <[EMAIL PROTECTED]> wrote:
> >>diff -buprN -X dontdiff
> >> vanilla-2.6.11-rc2-bk9/arch/um/os-Linux/drivers/tuntap_user.c
> >>
On Wed, 02 Feb 2005 18:38:37 +0100
Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> wrote:
> El mié, 02-02-2005 a las 17:17 +, [EMAIL PROTECTED] escribió:
> > There *are* things in OpenBSD, like randomized port assignment (as opposed
> > to the linear scan in tcp_v4_get_port()) that would
Terje Fåberg <[EMAIL PROTECTED]> skrev:
> The kernel is compiling right now, but I cannot
> reboot this machine until six or seven o'clock
> tonight (CET). I will report then.
Well, well, I rebooted the same kernel, now with
MAGIC-SYSRQ enabled. At first the kswapd-effect
wouldn't show up,
On Thursday 03 February 2005 21:56, Jeff Dike wrote:
> This fixes UML's sys_call_table to delete some entries for system calls
> which have not yet made it into mainline from -mm.
>
> I also delete UML's __pud_alloc implementation since the memory.c one is
> now enabled.
Ok, thanks might you
From: Michael S. Tsirkin <[EMAIL PROTECTED]>
Fix unbalanced QP reference count decrement (introduced with QP lock
optimization patch)
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-bk.orig/drivers/infiniband/hw/mthca/mthca_cq.c
On Wednesday, February 02, 2005 5:43 PM, James wrote:
> > + .sdev_attrs = megaraid_device_attrs,
> > + .shost_attrs= megaraid_class_device_attrs,
>
> These are, perhaps, slightly confusing names. The terms device and
> class_device have well defined
>I did a patch which switched loop to use the file_operations.read/write
>about a year ago. Forget what happened to it. It always seemed the
right
>thing to do..
This is unquestionably the right thing to do (at least compared to what we
have now). The loop device driver has no business
Hi, Alexey.
--
Alexey Dobriyan wrote:
On Wednesday 02 February 2005 19:26, Mark A. Greer wrote:
How's this (a complete replacement for previous patch)?
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
+ If you say yes to this option, support will be included
ChangeSet 1.2046, 2005/02/03 00:42:00-08:00, [EMAIL PROTECTED]
[PATCH] PCI: change sysfs representation of PCI-E devices
Before changes:
The patch makes the parent of the device pointing to the pci_dev
structure. The parents portX devices are in /sys/devices which
should be removed based on
On Wed, Feb 02, 2005 at 07:34:59PM -0800, Larry McVoy wrote:
> (Thanks for the forward, Peter, I would have missed this).
Sorry, I should have cc'ed you directly but I thought you would
never miss a subject containing $(random scm tool) :)
> As Peter said, we do exports from Linus' tree every
Hello,
I am having the same kind of troubles (can't tune and mt_set_frequency
-121 errors) since 2.6.10 (it was working in 2.6.9) on amd64.
this patch did not help sadely.
log files attached if you have time to look at them :) (the non-working
one being 2.6.11-rc3+your patch)
Cheers,
Mik
Gerd
On Wed, 2 Feb 2005 12:15:59 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote:
> > 25_ide_taskfile_cmd.patch
> >
> > All in-kernel REQ_DRIVE_CMD users except for ide_cmd_ioctl()
> > converted to use REQ_DRIVE_TASKFILE.
>
> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
>
> Index:
On Thu, 2005-02-03 at 06:28 -0800, Pallipadi, Venkatesh wrote:
> Can you check whether only the following change makes the problem go
> away. If yes, then it looks like a hardware issue.
>
> > hpet_writel(hpet_tick, HPET_T0_CMP);
> >+hpet_writel(hpet_tick, HPET_T0_CMP); /* AK: why twice?
>> > > And for the vmscan->writepage() side of things I wonder if it would
be
>> > > possible to overload the mapping's ->nopage handler. If the target
page
>> > > lies in a hole, go off and allocate all the necessary pagecache
pages, zero
>> > > them, mark them dirty?
>> >
>> > I guess it
Hi,
Here are a few I2C bugfixes 2.6.11-rc3. All of these patches have been
in the past few -mm releases.
Please pull from:
bk://kernel.bkbits.net/gregkh/linux/2.6.11-rc3/i2c
Patches will be posted to linux-kernel and sensors as a follow-up thread
for those who want to see them.
On Thu, Feb 03, 2005 at 12:08:05PM -0700, Bjorn Helgaas wrote:
> Convert pci_raw_ops to use unsigned segment (aka domain),
> bus, and devfn. With the previous code, various ia64 config
> accesses fail due to segment sign-extension problems.
>
> ia64:
> - With a signed seg >= 0x8, unwanted
Convert pci_raw_ops to use unsigned segment (aka domain),
bus, and devfn. With the previous code, various ia64 config
accesses fail due to segment sign-extension problems.
ia64:
- With a signed seg >= 0x8, unwanted sign-extension occurs when
"seg << 28" is cast to u64 in
ChangeSet 1.2041, 2005/02/03 00:39:41-08:00, [EMAIL PROTECTED]
[PATCH] PCI: typo in pci_scan_bus_parented
From: Olaf Hering <[EMAIL PROTECTED]>
printk format string misses a x
Signed-off-by: Olaf Hering <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Greg
ChangeSet 1.2042, 2005/02/03 00:40:09-08:00, [EMAIL PROTECTED]
[PATCH] pci: Add Citrine quirk
The IBM Citrine chipset has a feature that if PCI config register
0xA0 is read while DMAs are being performed to it, there is the possiblity
that the parity will be wrong on the PCI bus, causing a
Ian Godin wrote:
[...]
Definitely have been able to repeat that here, so the SG driver
definitely appears to be broken. At least I'm glad I am not going
insane, I was starting to wonder :)
I'll run some more tests with O_DIRECT and such things, see if I can
figure out what the REAL max
This updates the FAT attributes as well as (hopefully) corrects the
handling of VFAT ctime. The FAT attributes are implemented as a 32-bit
ioctl, per the previous discussions.
-hpa
Signed-Off-By: H. Peter Anvin <[EMAIL PROTECTED]>
Index: linux-2.5/fs/fat/dir.c
ChangeSet 1.2042, 2005/02/03 00:29:01-08:00, [EMAIL PROTECTED]
[PATCH] I2C: Resolve resource conflict between i2c-viapro and via686a
Here comes the finalized version of our patch solving the PCI device
resource conflict between the i2c-viapro bus driver and and the via686a
chip driver. It is
> "JH" == Jack Howarth <[EMAIL PROTECTED]> writes:
JH> Alan, I had mentioned a couple weeks back that with kernel 2.6.10,
JH> the ability to hotplug usb keys in Fedora Core 2 and 3 has been
JH> broken.
The true issue is a little more complicated than that. The kernel
issue here is that
Hi,
Here are a few PCI and PCI Hotplug bugfixes 2.6.11-rc3. All of these
patches have been in the past few -mm releases.
Please pull from:
bk://kernel.bkbits.net/gregkh/linux/2.6.11-rc3/pci
Patches will be posted to linux-kernel and linux-pci as a follow-up
thread for those who want to
On Thu, Feb 03, 2005 at 10:07:15AM -0600, Makhlis, Lev wrote:
> Nishanth Aravamudan <[EMAIL PROTECTED]> wrote:
>
> > +static inline unsigned long usecs_to_jiffies(const unsigned int u)
> > +{
> > + if (u > jiffies_to_usecs(MAX_JIFFY_OFFSET))
> > + return MAX_JIFFY_OFFSET;
> > +#if HZ
cpufreq core is printing out messages at KERN_WARNING level that the
core recovers from without intervention, and that the system
administrator can do nothing about. Patch below reduces the severity
of these messages to debug.
Signed-off-by: Matt Domsch <[EMAIL PROTECTED]>
--
Matt Domsch
ChangeSet 1.2047, 2005/02/03 00:31:16-08:00, [EMAIL PROTECTED]
[PATCH] I2C: Prevent buffer overflow on SMBus block read in
Hi Greg, Linus, all,
I just hit a buffer overflow while playing around with i2cdump and
i2c-viapro through i2c-dev. This is caused by a missing length check on
a buffer
This fixes UML's sys_call_table to delete some entries for system calls
which have not yet made it into mainline from -mm.
I also delete UML's __pud_alloc implementation since the memory.c one is
now enabled.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
Index:
On Wed, 2 Feb 2005 12:06:03 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote:
> > 21_ide_do_taskfile.patch
> >
> > Merged do_rw_taskfile() and flagged_taskfile() into
> > do_taskfile(). During the merge, the following changes took
> > place.
> > 1. flagged taskfile now honors
On Wed, Feb 02, 2005 at 04:48:39PM +, Linux Kernel Mailing List wrote:
> ChangeSet 1.1992.2.74, 2005/02/02 08:48:39-08:00, [EMAIL PROTECTED]
>
> [PATCH] Devices.txt, update with LANANA
>
> Attached is diff for bringing devices.txt uptodate with lanana.
>
>
ChangeSet 1.2044, 2005/02/03 00:29:54-08:00, [EMAIL PROTECTED]
[PATCH] I2C: Reduce it87 i2c address range
IT87xxF chips were never seen at any other I2C address than the default
(0x2d) so I think that we could safely reduce the range of addresses the
it87 drivers accepts. Currently it accepts
Alan Cox <[EMAIL PROTECTED]> wrote:
>
> On Llu, 2005-01-31 at 08:48, Andrew Morton wrote:
> > > The tty layer cannot fix this for now, and I don't intend to fix it. Fix
> > > the serial driver: the fix is quite simple since you can keep a field in
> > > the driver for now to detect recursive
Hi Ernie,
On Wed, Feb 02, 2005 at 09:19:54PM -0500, Ernie Petrides wrote:
> Hi, Marcelo. A fairly nasty memory corruption potential exists when
> /proc/kcore is accessed and there are at least 62 vmalloc'd areas.
>
> The problem is that get_kcore_size() does not properly account for
> the
ChangeSet 1.2046, 2005/02/03 00:30:49-08:00, [EMAIL PROTECTED]
[PATCH] I2C: Do not show disabled pc87360 fans
The pc87360 driver create sysfs files even for disabled fans. Since data
won't ever be updated, it doesn't make much sense. The following patch
adds some tests to only create the
On Fri, 4 Feb 2005 01:27:05 +1100
Anton Blanchard <[EMAIL PROTECTED]> wrote:
> Architectures should guarantee that any of the atomics and bitops that
> return values order in both directions. So you dont need the
> smp_mb__before_atomic_dec here.
>
> It is, however, required on the atomics and
Hi,
Here are a few usb bugfixes 2.6.11-rc3. All of these patches have been
in the past few -mm releases.
Please pull from:
bk://kernel.bkbits.net/gregkh/linux/2.6.11-rc3/usb
Patches will be posted to linux-usb-devel as a follow-up thread for
those who want to see them.
thanks,
greg
Ian Godin wrote:
I am trying to get very fast disk drive performance and I am seeing
some interesting bottlenecks. We are trying to get 800 MB/sec or more
(yes, that is megabytes per second). We are currently using PCI-Express
with a 16 drive raid card (SATA drives). We have achieved that
101 - 200 of 705 matches
Mail list logo
