On Wed, Jan 02, 2008 at 04:16:42PM +0100, Gabor Gombas wrote:
> Heh, it seems talking about a bug makes it trigger:
>
> Jan 2 16:05:45 twister kernel: Unable to handle kernel NULL pointer
> dereference at 00b8 RIP:
> Jan 2 16:05:45 twister kernel: [] mutex_lock+0x10/0x1d
> So
On Fri, Jan 04, 2008 at 09:30:49AM +0100, Ingo Molnar wrote:
>
> > > [ 1310.670986] =
> > > [ 1310.671690] [ INFO: possible recursive locking detected ]
> > > [ 1310.672097] 2.6.24-rc6 #1
> > > [ 1310.672421] -
On Tue, Jan 01, 2008 at 08:26:05PM +0100, Berthold Cogel wrote:
> Jan 1 17:34:39 wonderland kernel: BUG: unable to handle kernel paging
> request at virtual address 00100100
LIST_POISON1
> Jan 1 17:34:39 wonderland kernel: EIP is at evdev_disconnect+0x65/0x9e
and by the look of code, it's
Andi Kleen wrote:
> 64bit had it already
>
I'm unifying pgtable.h at the moment. Will post soon.
J
--
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
Ingo Molnar wrote:
> * Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
>
>> +#define WARN_ON(condition) do_warn_on((unsigned long)(condition), __FILE__,
>> \
>> + __LINE__, __FUNCTION__)
>>
>
> hm. This passes in 4 arguments to do_warn_on().
>
> i think
Arjan van de Ven wrote:
> This patch moves WARN_ON() out of line entirely. I've considered keeping
> the test inline and moving only the slowpath out of line, but I decided
> against that: an out of line test reduces the pressure on the CPUs
> branch predictor logic and gives smaller code, while a
On 2008.01.05 07:10:02 +0100, Björn Steinbrink wrote:
> - nv_probe sees 00:11:22:00:00:01
> - doesn't match the vendor stuff
> - becomes 01:00:00:22:11:00
>
> Oops, that's not quite the expected thing.
Haha, I just noticed that that even is a multicast address, so you'd get
a random MAC address
On 2008.01.04 23:43:52 +0100, Andreas Mohr wrote:
> On Fri, Jan 04, 2008 at 11:17:40AM +0100, Björn Steinbrink wrote:
> > On 2008.01.04 09:45:17 +0100, Andreas Mohr wrote:
> > > And then it needs these card I/O functions wrapped into two
> > > functions which interface with driver- and OS-related
On Fri, Jan 04, 2008 at 03:39:53PM +0100, Sam Ravnborg wrote:
> On Fri, Jan 04, 2008 at 09:23:16PM +0800, WANG Cong wrote:
> >
> > {snip}
> >
> > >TODO items (from my mailbox - I have plenty more)
> > >=
>...
> > >- i18n patch for mconf and friends
On Fri, Jan 04, 2008 at 09:12:28PM -0700, Andreas Dilger wrote:
> What's wrong with __FUNCTION__? I thought that was ANSI C?
__FUNCTION__ is a gccism of dubious taste - it pretends to be a macro
when it's something far out of scope of preprocessor. Think for a minute
and you'll see why - you
Arjan van de Ven пишет:
> Subject: move WARN_ON() out of line
> From: Arjan van de Ven <[EMAIL PROTECTED]>
> CC: Ingo Molnar <[EMAIL PROTECTED]>
> CC: Andrew Morton <[EMAIL PROTECTED]>
>
> A quick grep shows that there are currently 1145 instances of WARN_ON
> in the kernel. Currently, WARN_ON is
From: Deepak Colluru <[EMAIL PROTECTED]>
Subject: [PATCH] bsg : Add support for io vectors in bsg
Date: Fri, 4 Jan 2008 21:47:34 +0530 (IST)
> From: Deepak Colluru <[EMAIL PROTECTED]>
>
> Add support for io vectors in bsg.
>
> Signed-off-by: Deepak Colluru <[EMAIL PROTECTED]>
> ---
> bsg.c |
> On Fri 2008-01-04 14:09:01, Kent Yoder wrote:
> > On Jan 4, 2008 10:39 AM, Pavel Machek <[EMAIL PROTECTED]> wrote:
> > > On Thu 2008-01-03 21:44:15, Marcel Selhorst wrote:
> > > > Dear list,
> > > >
> > > > this patch fixes a bug, that prevents the TPM chip to resume
> > > > correctly from a
Andreas Dilger пишет:
> On Jan 04, 2008 14:41 +0100, Richard Knutsson wrote:
>>> @@ -54,6 +54,6 @@ int __ext4_journal_dirty_metadata(const char *where,
>>> {
>>> int err = jbd2_journal_dirty_metadata(handle, bh);
>>> if (err)
>>> - ext4_journal_abort_handle(where,
Andreas Dilger пишет:
> On Jan 04, 2008 14:41 +0100, Richard Knutsson wrote:
>>> @@ -54,6 +54,6 @@ int __ext4_journal_dirty_metadata(const char *where,
>>> {
>>> int err = jbd2_journal_dirty_metadata(handle, bh);
>>> if (err)
>>> - ext4_journal_abort_handle(where,
On Fri, Jan 04, 2008 at 07:13:53PM -0500, Gene Heskett wrote:
> Greetings;
>
> Is there a utility that can query the motherboard bios and get a list of the
> drives it can see?
>
> Likewise, for the bios extension contained on a pny sata card with a Silicon
> Image chipset on it?
>
> I'm
On Jan 04, 2008 14:41 +0100, Richard Knutsson wrote:
>> @@ -54,6 +54,6 @@ int __ext4_journal_dirty_metadata(const char *where,
>> {
>> int err = jbd2_journal_dirty_metadata(handle, bh);
>> if (err)
>> -ext4_journal_abort_handle(where, __FUNCTION__, bh, handle,err);
>> +
A question that comes to mind every time I go through the settings
for "Preemption Model" and "Preempt The Big Kernel Lock".
Do each of the combinations "make sense", or are some "no-ops"?
For model, we have 1) no forced (server), 2) Voluntary (Desktop)
3) preemptible (low-latency Desktop), and
On Fri, 4 Jan 2008, Rafael J. Wysocki wrote:
> I have rebased gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch
> on top of the $subject series, the result is appended. It has only been
> compilation tested for now, but I'll be testing it for the next couple of
> days.
>
> Please
Alan Cox wrote:
Unfortunately, it is not trivial to produce a mapping from EDD data to
real-life disks. Your best bet is if the disks have an MBR signature,
Untrue for all but the very earliest EDD. True for our kernel support
which wants improving some day
in which case the EDD code will
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
>> While we're here, I'll mention that dump_stack probably ought to take a
>> severity level argument.
>
> 125 files changed, 202 insertions(+), 199 deletions(-)
> just to get the api change done.
> I can hear akpm cringe from here...
You don't have
From: Anton Salikhmetov <[EMAIL PROTECTED]>
I would like to propose my solution for the bug #2645 from the kernel bug
tracker:
http://bugzilla.kernel.org/show_bug.cgi?id=2645
The Open Group defines the behavior of the mmap() function as follows.
The st_ctime and st_mtime fields of a file that
> Unfortunately, it is not trivial to produce a mapping from EDD data to
> real-life disks. Your best bet is if the disks have an MBR signature,
Untrue for all but the very earliest EDD. True for our kernel support
which wants improving some day
> in which case the EDD code will capture
Frederik Deweerdt wrote:
On Fri, Jan 04, 2008 at 09:01:38PM +, Phil Endecott wrote:
struct sockaddr_in client_addr;
socklen_t client_size=sizeof(client_addr);
int connfd = accept(fd,(struct sockaddr*)(_addr),_size);
if (connfd==-1) {
// [1]
.report error and terminate..
On Jan 04, 2008, at 15:54:06, Oliver Neukum wrote:
Am Donnerstag, 3. Januar 2008 23:06:07 schrieb Nigel Cunningham:
Hi.
a) mount fuse on /tmp/first
b) mount fuse on /tmp/second
Then the server task for (a) does "ls /tmp/second". So it will be
frozen, right? How do you then freeze (a)? And
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > > > The kernel process request that _all_ contributors run their
> > > > patches through checkpath.pl and fix the problems.
> > >
> > > That's new. When and by whom was that rule been introduced? And
> > > with what rationale?
> >
> >
On Fri, Jan 04, 2008 at 09:01:38PM +, Phil Endecott wrote:
> Dear Experts,
>
> I have some code like this:
>
> struct sockaddr_in client_addr;
> socklen_t client_size=sizeof(client_addr);
> int connfd = accept(fd,(struct sockaddr*)(_addr),_size);
> if (connfd==-1) {
> // [1]
>
On Jan 4, 2008 2:26 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > There are 2 pending issues, to which I have received insufficient feedback:
> >
> > 1. Andi would like to eliminate the trampoline in mce_thermal.c, but
> > no one has responded to my proposed disgusting hack on entry_64.S in
> >
On Fri, 4 Jan 2008, Arjan van de Ven wrote:
>
> this is the part I'm not very thrilled about... at least on first sight
> it looks like a user can now hold the read sem over system calls, and
> for as long as it wants.
No, you misunderstand how seq-files work.
The start/stop sequence is
Gene Heskett wrote:
Greetings;
Is there a utility that can query the motherboard bios and get a list of the
drives it can see?
Likewise, for the bios extension contained on a pny sata card with a Silicon
Image chipset on it?
I'm trying to cobble up a way for linux to boot from the drive
On Sat, Jan 05, 2008 at 01:12:44AM +0100, Paolo Ciarrocchi wrote:
> Isn't it a timing problem?
> I mean, I guess that codying style fixes are OK if there is a good
> coordination
> with the maintainer and patches are sent with the right timing in
> order to not cause
> problems in the process.
On Tue, 1 Jan 2008 17:23:28 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Theodore Tso <[EMAIL PROTECTED]> wrote:
>
> > [...] doesn't a patch to provide /proc/slabinfo for SLUB already
> > exist?
>
> yes, the complete (and tested) patch is below. It has been through a
> few thousand
On Jan 4, 2008 9:37 PM, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 04, 2008 at 06:52:09PM +0100, Paolo Ciarrocchi wrote:
> > Further fixes to profile.c, checkpatch.pl now reports:
> >
> > total: 0 errors, 2 warnings, 601 lines checked
> >
> > WARNING: EXPORT_SYMBOL(foo); should
Greetings;
Is there a utility that can query the motherboard bios and get a list of the
drives it can see?
Likewise, for the bios extension contained on a pny sata card with a Silicon
Image chipset on it?
I'm trying to cobble up a way for linux to boot from the drive on this sata
card, so
On Jan 4, 2008 11:33 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
[...]
> > I think that _one_ of the reasons that made a few people sent this kind of
> > patches to the list is because checkpatch.pl is far better then any other
> > kerneljanitor scripts/easy task and _seems_ to be an easy way to
On Fri, Jan 04, 2008 at 04:21:26PM +0100, Torsten Kaiser wrote:
> On Jan 4, 2008 2:30 PM, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
...
> I'm open for any suggestions and will try to answer any questions.
I'm very glad, thanks!
> The only thing that is sadly not practical is bisecting the
Hi Jiri,
Jiri Slaby wrote:
On 01/04/2008 10:01 PM, Phil Endecott wrote:
Dear Experts,
I have some code like this:
struct sockaddr_in client_addr;
socklen_t client_size=sizeof(client_addr);
int connfd = accept(fd,(struct sockaddr*)(_addr),_size);
if (connfd==-1) {
// [1]
.report error
On Fri 2008-01-04 14:09:01, Kent Yoder wrote:
> On Jan 4, 2008 10:39 AM, Pavel Machek <[EMAIL PROTECTED]> wrote:
> >
> > On Thu 2008-01-03 21:44:15, Marcel Selhorst wrote:
> > > Dear list,
> > >
> > > this patch fixes a bug, that prevents the TPM chip to resume correctly
> > > from a
> > >
Kent is right, the solution from David is way better. I wanted to be consistent
with the other functions in tpm.c, but it definitely makes more sense in Davids
way. So please consider my patch as reverted and his patch as
Signed-off-by: Marcel Selhorst <[EMAIL PROTECTED]>
Thanks,
Marcel
Kent
On Friday, 4 of January 2008, Rafael J. Wysocki wrote:
> On Wednesday, 2 of January 2008, Rafael J. Wysocki wrote:
> > On Wednesday, 2 of January 2008, Alan Stern wrote:
> > > On Wed, 2 Jan 2008, Rafael J. Wysocki wrote:
> > >
> > > > On Wednesday, 2 of January 2008, Rafael J. Wysocki wrote:
> >
H. Peter Anvin zytor.com> writes:
>
> Supposedly WinXP-32 doesn't use memory over 4 GB even if it is available
> (a market-segmentation decision of the part of Microsoft, to force
> people to buy WinServer 2003; WinXP SP2 does PAE so there is no
> technical reason.) This probably has
On 01/04/2008 10:01 PM, Phil Endecott wrote:
> Dear Experts,
>
> I have some code like this:
>
> struct sockaddr_in client_addr;
> socklen_t client_size=sizeof(client_addr);
> int connfd = accept(fd,(struct sockaddr*)(_addr),_size);
> if (connfd==-1) {
> // [1]
> .report error and
On Fri, Jan 04, 2008 at 11:13:14PM +0100, Andi Kleen wrote:
> On Friday 04 January 2008 19:47:33 Joe Perches wrote:
> > On Fri, 2008-01-04 at 19:06 +0100, Andi Kleen wrote:
> > > But the problem with your "rule" is that every of the hundreds
> > > of Linux kernel contributors will need to do the
On Fri, Jan 04, 2008 at 11:17:40AM +0100, Björn Steinbrink wrote:
> On 2008.01.04 09:45:17 +0100, Andreas Mohr wrote:
> > And then it needs these card I/O functions wrapped into two functions which
> > interface with driver- and OS-related MAC variables
> > (struct variables ALWAYS stored in usual
Hi,
Hmm, contrary to ide-cd.c case there doesn't seem to be a need currently for
moving code out of ide-floppy.c (and this patch series doesn't change that).
Besides it would be better to just remove some structs like it has been done
with i.e. struct atapi_capabilities_page in ide-cd.c case
Ok, there's a new patch.
This patch fixes a compilation warning in 'iwl-4965.c'.
"warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘long
unsigned int’"
Signed-off-by: Miguel Botón <[EMAIL PROTECTED]
diff --git a/drivers/net/wireless/iwlwifi/iwl-4965.c
On Fri, Jan 04, 2008 at 09:03:53PM +0100, Paolo Ciarrocchi wrote:
> On Jan 4, 2008 8:41 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> [...]
> > > I don't know, because people want to be able to say that they've
> > > contributed fixes to the Linux kernel?
> >
> > My pet theory is that it is similar
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Fri, 04 Jan 2008 14:13:12 -0800
> > - "radiotap head [%d]\n",
> > + "radiotap head [%ld]\n",
> > skb_headroom(skb), sizeof(*iwl4965_rt));
>
> Actually I think the correct
On Fri, 2008-01-04 at 13:36 -0800, Christoph Lameter wrote:
> Ok. So lets try a worst case scenario. If we do a 128 byte kmalloc
> then we
> can allocate the following number of object from one 4k slab
>
> SLUB 32 (all memory of the 4k page is used for 128 byte objects)
> SLAB 29/30
On Jan 4, 2008 9:09 PM, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
> On Jan 4 2008 20:43, Sam Ravnborg wrote:
> >On Thu, Jan 03, 2008 at 11:33:44PM +0100, Jan Engelhardt wrote:
> >>
> >> On Jan 3 2008 22:32, Sam Ravnborg wrote:
> >> >
> >> >On top of this I have my personal todo items such as:
>
For cards that initially have the MAC address stored in reverse order,
the forcedeth driver uses a flag to signal whether the address was
already corrected, so that it is not reversed again on a subsequent
probe.
Unfortunately this flag, which is stored in a register of the card,
seems to get
> As to the question of Athlon RevG, it turns out that it has the same
> thermal erratum as RevF. Therefore the fact that this code only works
> with Barcelona and up is not a defficiency.
Thanks.
>
> There are 2 pending issues, to which I have received insufficient feedback:
>
> 1. Andi
On Fri, 4 Jan 2008 23:05:54 +0100 Miguel Botón wrote:
> This patch fixes a compilation warning in 'iwl-4965.c'.
It would be helpful to have the warning message right here.<---
> Signed-off-by: Miguel Botón <[EMAIL PROTECTED]>
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-4965.c
>
On Friday 04 January 2008 23:05:54 Miguel Botón wrote:
> This patch fixes a compilation warning in 'iwl-4965.c'.
>
> Signed-off-by: Miguel Botón <[EMAIL PROTECTED]>
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-4965.c
> b/drivers/net/wireless/iwlwifi/iwl-4965.c
> index 74999af..92237cd
On Friday 04 January 2008 21:34:15 Thomas Gleixner wrote:
> On Fri, 4 Jan 2008, Andi Kleen wrote:
> > > The kernel process request that _all_ contributors run their patches
> > > through checkpath.pl and fix the problems.
> >
> > That's new. When and by whom was that rule been introduced? And
On Friday 04 January 2008 19:47:33 Joe Perches wrote:
> On Fri, 2008-01-04 at 19:06 +0100, Andi Kleen wrote:
> > But the problem with your "rule" is that every of the hundreds
> > of Linux kernel contributors will need to do the same. And that's just
> > ineffecient, waste of valuable human work
> - "radiotap head [%d]\n",
> + "radiotap head [%ld]\n",
> skb_headroom(skb), sizeof(*iwl4965_rt));
Actually I think the correct printf format for printing a size_t
(coming here from sizeof foo) is "%zd".
This patch fixes a compilation warning in 'iwl-4965.c'.
Signed-off-by: Miguel Botón <[EMAIL PROTECTED]>
diff --git a/drivers/net/wireless/iwlwifi/iwl-4965.c
b/drivers/net/wireless/iwlwifi/iwl-4965.c
index 74999af..92237cd 100644
--- a/drivers/net/wireless/iwlwifi/iwl-4965.c
+++
Before 'topology_32.h' and 'topology_64.h' were unified, topology defines in a
X86_64 kernel were declared if CONFIG_SMP was enabled.
Now, post unification, these same defines in a X86_64 kernel are only being
declared if CONFIG_NUMA and CONFIG_SMP are enabled.
This, for example, breaks
Dr. David Alan Gilbert wrote:
Now I can understand this explanation for 32-bit mode, but I'm running
in 64-bit mode. There should be a way to use the fourth gig under
Linux. Is there?
The chipset limitation applies to 64bit mode as well as to 32bit mode
(which actually does not have a 4GB
On Wednesday, 2 of January 2008, Rafael J. Wysocki wrote:
> On Wednesday, 2 of January 2008, Alan Stern wrote:
> > On Wed, 2 Jan 2008, Rafael J. Wysocki wrote:
> >
> > > On Wednesday, 2 of January 2008, Rafael J. Wysocki wrote:
> > > > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> > > >
> > > >
>-Original Message-
>From: Mark Lord [mailto:[EMAIL PROTECTED]
>Sent: Friday, January 04, 2008 1:53 PM
>To: Pallipadi, Venkatesh
>Cc: Arjan van de Ven; Andrew Morton; [EMAIL PROTECTED];
>[EMAIL PROTECTED]; Ingo Molnar; linux-kernel@vger.kernel.org;
>[EMAIL PROTECTED]; [EMAIL PROTECTED]
Hi,
kexec of 2.6.24-rc6-git11 fails for me with:
Close of /boot/kernel-2.6.24-rc6-git11 failed: : buffer error
kexec load failed, error = 1
2.6.24-rc6-git9 works as expected. git10 fails with root device
not found (for some reason). All have the same kernel config
(attached).
Any
Mark Lord wrote:
Venki Pallipadi wrote:
Reintroduce run time configurable max_cstate for !CPU_IDLE case.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Index: linux-2.6.24-rc/drivers/acpi/processor_idle.c
===
---
>From: Williams, Dan J
>
>The tx_set_src and tx_set_dest methods were originally
>implemented to allow
>an array of addresses to be passed down from async_xor to the dmaengine
>driver while minimizing stack overhead. Removing these methods allows
>drivers to have all transaction parameters
>From: Williams, Dan J
>
>Pass a full set of flags to drivers' per-operation 'prep' routines.
>Currently the only flag passed is DMA_PREP_INTERRUPT. The
>expectation is
>that arch-specific async_tx_find_channel() implementations can
>exploit this
>capability to find the best channel for an
They just keep coming out of the woodwork, sorry. This one's in the
SCSI over RDMA Protocol transport class, so it's causing SCSI over
infiniband installations to oops on shutdown. I'm told that their are
now nearly as many SCSI over IB users as their are voyager users, so,
since it's nearly
Dear Experts,
I have some code like this:
struct sockaddr_in client_addr;
socklen_t client_size=sizeof(client_addr);
int connfd = accept(fd,(struct sockaddr*)(_addr),_size);
if (connfd==-1) {
// [1]
.report error and terminate..
}
int rc = fcntl(connfd,F_SETFD,FD_CLOEXEC);
I
On Fri, 4 Jan 2008, Matt Mackall wrote:
> > needs to know the size. So it is not possible in SLOB to use
> > kmem_cache_alloc on an object and then free it using kfree?
>
> Indeed. Mismatching allocator and deallocator is bug, even if it happens
> to work for SLAB/SLUB.
Was the kernel audited
Il Wednesday 02 January 2008 00:19:55 Pavel Machek ha scritto:
> Hi!
>
> On kohjinsha, wakeup code does not seem to be reached at all. I tried
> looking around FACS, but it seems very empty:
>
> ...
The same on my laptop:
FACS @ 0x2fefafc0
: 46 41 43 53 40 00 00 00 62 12 00 00 00 00 00 00
Here's a new version of the patch. Since I didn't explain its purpose
very well in my previous submission, I'll do so here:
This patch adds thermal machine check event (MCE) support to AMD
Barcelona (and probably later, if new PCI IDs are added to
k8_northbridges[]), styled after the same in the
On Jan 4, 2008 4:21 PM, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> On Jan 4, 2008 2:30 PM, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> > - above git-nfsd and git-net tests should be probably repeated with
> > -rc6-mm1 git versions: so vanilla rc6 plus both these -mm patches
> > only, and if bug
* Factor out code for tuning devices from ide_probe_port()
to ide_port_tune_devices().
* Move ide_port_tune_devices() call from ide_probe_port()
to ide_device_add_all().
There should be no functionality changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL
* Add BUG_ON(hwif->present) at the start of ide_probe_port().
* Move hwif_register() call (along with setting hwif->present) from
ide_probe_port() to ide_device_add_all().
As a result the port will be registered with the device tree _after_:
- probing both devices (if both are present)
-
Reserve/release I/O resources in ide_device_add_all() instead of
ide_probe_port().
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ide-probe.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
Index: b/drivers/ide/ide-probe.c
Make probe_hwif() return an error value.
While at it:
* Remove comment about MAX_DRIVES == 2 limitation (it is not special to
probe_hwif(), it is a general assumption taken by a lot of IDE code).
* Rename probe_hwif() to ide_probe_port().
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL
There should be no functionality changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
-77 bytes
drivers/ide/ide-probe.c | 18 +-
drivers/ide/ide.c |2 +-
include/linux/ide.h |1 +
3 files changed, 3 insertions(+), 18
* BUG_ON() early if 'hwif->next == hwif' and there is a 'match' hwgroup.
* Remove printk() for impossible condition and add a BUG_ON(hwgroup->drive)
to match code in ide_unregister().
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
-52 bytes
drivers/ide/ide-probe.c |5
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ide.c | 65 +-
1 file changed, 36 insertions(+), 29 deletions(-)
Index: b/drivers/ide/ide.c
===
---
Release I/O resources after releasing DMA.
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ide.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
Index: b/drivers/ide/ide.c
===
---
Use the facts that:
* When ide_init() is called 'system_bus_speed' always equals zero.
* system_bus_clock() is never called before ide_init().
and:
* Move printk() from ide_system_bus_speed() to ide_init().
* Don't assign 'system_bus_speed' in ide_system_bus_speed().
* Don't call
Since kmalloc_node() is called with __GFP_ZERO flag there is no need to
explicitly zero hwgroup fields.
While at it:
* Use 'hwif' instead of 'hwif->drives[0].hwif' for kmalloc_node() call.
* Fix whitespace damage.
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
-27 bytes
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
include/linux/ide.h | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
Index: b/include/linux/ide.h
===
--- a/include/linux/ide.h
+++
* Remove 'if (hwif != hwif_prop.hwif)' check from plat_ide_remove()
(pdev->dev.driver_data and hwif_prop.hwif are set at the same time
in plat_ide_probe() and are identical).
* Use hwif->index for ide_unregister() in plat_ide_remove().
* Use local variables instead of
* Call hwif_init() only if hwif->present is set.
* If hwif_init() fails clear hwif->present.
* Remove hwif->present manipulations from hwif_init().
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
-24 bytes
drivers/ide/ide-probe.c | 18 ++
1 file changed, 6
* Move wait_hwif_ready() documentation before this function.
* Fix trailing whitespaces.
* s/wait-for-busy/wait-for-non-busy/
* Remove no longer valid comment about the current code behavior.
* Docbook-ize it.
* Rename wait_hwif_ready() to ide_port_wait_ready().
Signed-off-by: Bartlomiej
It could be that I/O resources are busy because some other host driver
has already claimed them so don't unregister the devices.
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
-94 bytes
drivers/ide/ide-probe.c | 13 +
1 file changed, 1 insertion(+), 12
This is a preparation for a more sophisticated changes.
diffstat:
drivers/ide/ide-iops.c|2
drivers/ide/ide-probe.c | 199 --
drivers/ide/ide.c | 109 ++--
drivers/ide/legacy/ide_platform.c | 34
On Fri, 2008-01-04 at 12:34 -0800, Christoph Lameter wrote:
> On Thu, 3 Jan 2008, Matt Mackall wrote:
>
> > > The advantage of SLOB is to be able to put objects of multiple sizes into
> > > the same slab page. That advantage goes away once we have more than a few
> > > objects per slab because
On Fri, Jan 04, 2008 at 07:06:50PM +0100, Andi Kleen wrote:
> > What is then considered "obvious style issues" are today implemented
> > as errors / warnings in checkpatch for the most part. Not everyone
>
> In my experience checkpatch has a lot of false positives. e.g. when
> I run it over my
On 01/04/2008 12:18 PM, john stultz wrote:
On Thu, 2008-01-03 at 15:52 -0800, Dan Hecht wrote:
Looking at pit_read() in arch/x86/kernel/i8253.c, it seems that the PIT
clocksource code assumes that the PIT CH0 is in periodic mode. With
clockevents, this assumption is no longer valid. There
Am Donnerstag, 3. Januar 2008 23:06:07 schrieb Nigel Cunningham:
> Hi.
>
> Oliver Neukum wrote:
> > Am Donnerstag, 3. Januar 2008 10:52:53 schrieb Nigel Cunningham:
> >> Hi.
> >>
> >> Oliver Neukum wrote:
> >>> Am Donnerstag 03 Januar 2008 schrieb Nigel Cunningham:
> On top of this, I made a
IDE doesn't need it.
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
include/linux/ide.h |1 -
1 file changed, 1 deletion(-)
Index: b/include/linux/ide.h
===
--- a/include/linux/ide.h
+++ b/include/linux/ide.h
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
include/linux/hdsmart.h |2 ++
1 file changed, 2 insertions(+)
Index: b/include/linux/hdsmart.h
===
--- a/include/linux/hdsmart.h
+++ b/include/linux/hdsmart.h
@@
On Fri, 4 Jan 2008, Peter Zijlstra wrote:
> I remember wli trying to work out a series that had minimal
> fragmentation. IIRC he was mixing a fibonaci series with the power of
> two series.
>
> Bill, do you remember getting anywhere?
I tried various approaches to reduce the overhead that power
On Fri, Jan 04, 2008 at 06:52:09PM +0100, Paolo Ciarrocchi wrote:
> Further fixes to profile.c, checkpatch.pl now reports:
>
> total: 0 errors, 2 warnings, 601 lines checked
>
> WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
> #410: FILE: profile.c:410:
>
On Thu, 3 Jan 2008, Matt Mackall wrote:
> > The advantage of SLOB is to be able to put objects of multiple sizes into
> > the same slab page. That advantage goes away once we have more than a few
> > objects per slab because SLUB can store object in a denser way than SLOB.
>
> Ugh, Christoph.
On Fri, 4 Jan 2008, Andi Kleen wrote:
> > The kernel process request that _all_ contributors run their patches
> > through checkpath.pl and fix the problems.
>
> That's new. When and by whom was that rule been introduced? And with what
> rationale?
Documentation/SubmitChecklist
> Even
On Fri, 04 Jan 2008 13:21:32 +0100, Manuel Reimer said:
> Is it really possible to get root privileges with this bug or are there
> people who just write "may be used to escalate privileges" near any bug
> which has something to do with "setuid" or "setgid"?
It looks like it really *is*
On Fri, 04 Jan 2008 17:22:57 +0100 Andi Kleen (AK) wrote:
AK> [EMAIL PROTECTED] writes:
AK>
AK> > I recently put 4 GB of memory in my Acer Travelmate 8210 series
AK> > notebook. The BIOS only detects 3 GB.
AK>
AK> Actually it will detect 4GB, but put the PCI hole over the last GB.
AK> One way
1 - 100 of 536 matches
Mail list logo
