Attempt to reduce stack usage in time.c (linux-2.6.12-rc1-mm3). Stack
usage was noted using checkstack.pl. Specifically:
Before patch
sys_adjtimex - 128
After patch
---
sys_adjtimex - none (register usage only)
Signed-off-by: Yum Rayan <[EMAIL PROTECTED]>
--- a/kernel/time.
RFC: This is a work-in-progress (WIP), not yet completed.
A few people dislike that the Networking Options menu is inside
the Device Drivers/Networking menu. This patch moves the
Networking Options menu to immediately before the Device Drivers menu,
renames it to "Networking options and protoco
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> could you check the -41-23 -RT kernel at the usual place:
>
>http://redhat.com/~mingo/realtime-preempt/
>
> i've added Trond's radix lookup code, plus the lockbreaker patch.
>
> (one thing that is not covered yet is nfs_scan_list() - that still sc
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> ok, find a new latency trace attached (1.6 msecs). I generated write
> loads, and the nfs_scan_list_dirty() latency is gone and indeed
> nfs_scan_list() generates the worst latency - while processing 8535
> pages in one critical section.
here's a mor
* Lee Revell <[EMAIL PROTECTED]> wrote:
> So there seems to be a bug in the latency tracer where the timer is
> not being reset on reschedule. [...]
update: i found a bug in the latency tracer that could explain some of
the artifacts you noticed, IRQs would reset the tracing timer under
certa
Hi,
Kprobes did an improper exit when a probe is inserted on an int3 instruction.
In case of normal execution of int3/breakpoint instruction, it oops!.
Probe on an int3 instruction was not handled properly by the kprobes, it
generated faults after oops! doing an improper exit with holding the loc
Natanael Copa napisał(a):
On Thu, 2005-03-31 at 01:46 +0200, Felipe Alfaro Solana wrote:
On Mon, 28 Mar 2005 19:28:20 +0200, Matthieu Castet
<[EMAIL PROTECTED]> wrote:
The memory limits aren't good enough either: if you set them low
enough that memory-forkbombs are unperilous for
RLIMIT_NPROC*RLIMI
Denis wrote:
> This reminds me on VIA northbridge problem when BIOS enabled
> a feature which was experimental and turned out to be buggy.
You were close!
I changed my Memory Timing from 1T to 2T, and now it is as solid as a
rock. It has been up 7 minutes as I type this, without a hiccup.
Notic
Hi,
Kprobes did an improper exit when a probe is inserted on an int3 instruction.
In case of normal execution of int3/breakpoint instruction, it oops!.
Probe on an int3 instruction was not handled properly by the kprobes, it
generated faults after oops! doing an improper exit with holding the loc
Yves Crespin wrote:
> Christian Bornträger wrote:
> >On Wednesday 30 March 2005 15:00, Yves Crespin wrote:
> >>1/ is-it possible to *really* be synchronize. I prefer to have a
> >> blocked write() than use cache and get swap!
> >Try to mount with the sync option.
> exactly async and noatime ?
No.
Yum Rayan wrote:
Attempt to reduce stack usage in time.c (linux-2.6.12-rc1-mm3). Stack
usage was noted using checkstack.pl. Specifically:
Before patch
sys_adjtimex - 128
After patch
---
sys_adjtimex - none (register usage only)
Signed-off-by: Yum Rayan <[EMAIL PROTECTED]>
--- a
Yum Rayan wrote:
Attempt to reduce stack usage in sys.c (linux-2.6.12-rc1-mm3). Stack
usage was noted using checkstack.pl. Specifically
Before patch
sys_reboot - 256
After patch
---
sys_reboot - none (register usage only)
Along the way, wrap code to 80 column width and cleanup
Andrew pointed out to me that the new driver core code spewes a lot of
stuff in the syslog for every device it tries to match up with a driver
(if you look closely, it seems that the if check in __device_attach()
will never not trigger...)
Everything still seems to work properly, but it's good if
Hi!
> > > > We currently freeze processes for suspend-to-ram, too. I guess that
> > > > disable_usermodehelper is probably better and that in_suspend() should
> > > > only be used for sanity checks... go with disable_usermodehelper and
> > > > sorry for the noise.
> > >
> > > Here's another possi
Sorry typo error. Please use this patch.
Thanks
Prasanna
Kprobes did an improper exit when a probe is inserted on an int3 instruction.
In case of normal execution of int3/breakpoint instruction, it oops!.
Probe on an int3 instruction was not handled properly by the kprobes, it
generated faults
Hi,
On Wednesday, 30 of March 2005 12:05, Rafael J. Wysocki wrote:
> On Wednesday, 30 of March 2005 07:53, Yu, Luming wrote:
> > On Tuesday 29 March 2005 17:56, Rafael J. Wysocki wrote:
> > > Hi,
> > >
> > > There is a problem on my box (Asus L5D, x86-64 kernel) with the ACPI
> > > battery driver
i have released the -V0.7.41-25 Real-Time Preemption patch, which can be
downloaded from the usual place:
http://redhat.com/~mingo/realtime-preempt/
this release tries to stabilize things some more. In particular i've
changed 'nocheck' semaphores to not be included in any PI or debugging
l
Hello,
Last night I saw an I/O error in a RAID device on a SuSE 9.0 system (with the
stock 2.4.21-99 kernel, not tainted). I don't know if it's useful for anyone
given that the kernel has changed much since then, but I report it just in
case the problem is still in there.
I find strange that t
Hello, James.
Hello, Jens.
This patchset is consisted of three parts
#01-#06: Misc updates. Except for #02, all patches are from the last
patchset. #05 has been updated.
#07-#10: Rewrite scsi_request_fn().
#11-#13: Consolidate requeue paths & cleanup scsi_cmd_retry() calls
01_scsi_no_REQ_SPECIAL_on_requeue.patch
blk_insert_request() has 'reinsert' argument, which, when set,
turns on REQ_SPECIAL and REQ_SOFTBARRIER and requeues the
request. SCSI midlayer was the only user of this feature and
all requeued requests become special reques
02_scsi_no_REQ_SPECIAL_on_sgtable_allocation_failure.patch
Don't turn on REQ_SPECIAL on sgtable allocation failure. This
was the last place where REQ_SPECIAL is turned on for normal
requests.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
scsi_lib.c |4 +---
1 files c
06_scsi_remove_serial_number_at_timeout.patch
scsi_cmnd->serial_number_at_timeout doesn't serve any purpose
anymore. All serial_number == serial_number_at_timeout tests
are always true in abort callbacks. Kill the field. Also, as
->pid always equals ->serial_numb
04_scsi_remove_volatile.patch
scsi_device->device_busy, Scsi_Host->host_busy and
->host_failed have volatile qualifiers, but the qualifiers
don't serve any purpose. Kill them. While at it, protect
->host_failed update in scsi_error for consistency and clarity.
Si
09_scsi_prep_fn_comment_update.patch
Remove bogus comments from scsi_prep_fn() and clean up a bit.
While at it, remove leading and tailing empty comment lines
for one or two liners to make the code more concise.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
scsi_lib.c |
11_scsi_make_requeue_command_public.patch
Add reprep argument to scsi_requeue_command(), remove
redundant q argument, add code to set cmd->state/owner, and
make the function public. This patch is preparation for
consolidating requeue paths.
Signed-off-by: Tejun He
07_scsi_consolidate_prep_fn_error_handling.patch
When scsi_init_io() returns BLKPREP_DEFER or BLKPREP_KILL,
it's supposed to free resources itself. This patch
consolidates defer and kill handling into scsi_prep_fn().
This fixes a queue stall bug which occurred when
13_scsi_consolidate_cmd_retry_calls_in_eh.patch
Replace all scsi_setup_cmd_retry() calls in scsi_error.c with
a call just above scsi_finish_command() in scsi_eh_flush_done_q().
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
scsi_error.c | 25 +
1 files ch
On Thursday 31 March 2005 11:26, Jeff Garzik wrote:
> Yum Rayan wrote:
> > Attempt to reduce stack usage in time.c (linux-2.6.12-rc1-mm3). Stack
> > usage was noted using checkstack.pl. Specifically:
> >
> > Before patch
> >
> > sys_adjtimex - 128
> >
> > After patch
> > ---
Paul Jackson wrote:
> Denis wrote:
>
>>This reminds me on VIA northbridge problem when BIOS enabled
>>a feature which was experimental and turned out to be buggy.
>
>
> You were close!
>
> I changed my Memory Timing from 1T to 2T, and now it is as solid as a
> rock. It has been up 7 minutes as
* Frank Rowand <[EMAIL PROTECTED]> wrote:
> < more stuff deleted >
>
> I'm working on the architecture support for realtime on PPC64 now. If
> the lock field of struct raw_rwlock_t is a long instead of int then
> /proc/meminfo shows MemFree decreasing from 485608 kB to 485352 kB.
>
> Do you h
* Lee Revell <[EMAIL PROTECTED]> wrote:
> Since 2.6.12-rc1-RT something I get this Oops on boot about 50% of the
> time. It's clearly some kind of race because if I just reboot again
> it works. Seems to happen shortly after ksoftirqd startup (maybe the
> first time we hit the timer softirq?
Hi Benoit,
I had the following BUG with 2.6.12-rc1-mm3:
remote host is running 2.6.12-rc1-mm1 with samba 3.0.13.
[23156.357178] smb_lookup: find musique/Pink_Floyd-Dark_Side_of_the_Moon
failed, error=-512
[23157.057501] BUG: atomic counter underflow at:
[23157.057508] [] dump_stack+0x17/0x20
[2315
On Mon, Mar 28, 2005 at 05:22:36PM +, Artem B. Bityuckiy wrote:
>
> I made the changes to deflate_decompr() because the old version doesn't
> work properly for me. There are 2 changes.
>
> 1. I've added the following code:
>
> -
10_scsi_request_fn_rewrite.patch
This patch rewrites scsi_request_fn(). scsi_dispatch_cmd() is
merged into scsi_request_fn(). Goals are
* Remove unnecessary operations (host_lock unlocking/locking,
recursing into scsi_run_queue(), ...)
* Consolidate def
On Wed, 2005-03-30 at 21:37 -0800, nobin matthew wrote:
> The Platform is Arcom Viper borad(with support for
> PC104), This is a Xscale, Little endian Platform.
If you contact Arcom technical support on either [EMAIL PROTECTED]
or [EMAIL PROTECTED] then they will be able to help you with any
probl
12_scsi_consolidate_requeue_paths.patch
Add scsi_device_unbusy() call to scsi_retry_command(), replace
scsi_queue_insert() with scsi_requeue_command(), make
scsi_softirq() use scsi_retry_command() for ADD_TO_MLQUEUE
case too (with explicit device blocking), and make
08_scsi_move_preps_to_prep_fn.patch
Move request preparations scattered in scsi_request_fn() and
scsi_dispatch_cmd() into scsi_prep_fn().
* CDB_SIZE check in scsi_dispatch_cmd()
* SCSI-2 LUN preparation in scsi_dispatch_cmd()
* scsi_init_cmd_errh() in scsi_
05_scsi_timer_cleanup.patch
scsi_queue_insert() has four callers. Three callers call with
timer disabled and one (the second invocation in
scsi_dispatch_cmd()) calls with timer activated.
scsi_queue_insert() used to always call scsi_delete_timer()
and ignor
03_scsi_remove_internal_timeout.patch
scsi_cmnd->internal_timeout field doesn't have any meaning
anymore. Kill the field.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
drivers/scsi/advansys.c |2 --
drivers/scsi/pci2000.c|4 ++--
drivers/scsi/scsi.c |1 -
On Wed, 2005-03-30 at 19:40 +0200, Jacek Łuczak wrote:
> Hi
>
> I made some tests and almost all Linux distros brings down while freebsd
> survive!Forkbombing is a big problem but i don't think that something like
>
> max_threads = mempages / (16 * THREAD_SIZE / PAGE_SIZE);
>
> is good solution
Your problem is almost certainly in the hardware area (cpu, bios,
memory, power, northbridge, motherboard, cooling or thereabouts).
> Imo memtest86 should not hang onless something screws up [its] memory area
There is nothing else running when memtest runs. You cannot assume
that your hardware i
> >That is what the assembler generates, and should have generated, for
> >"movw %ds,(%eax)" since Nov. 4, 2004.
>
> Could this be the reason for the reported slowdown in the last six months?
No.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mes
On Thu, Mar 31, 2005 at 06:07:55PM +0900, Tejun Heo wrote:
> 01_scsi_no_REQ_SPECIAL_on_requeue.patch
>
> blk_insert_request() has 'reinsert' argument, which, when set,
> turns on REQ_SPECIAL and REQ_SOFTBARRIER and requeues the
> request. SCSI midlayer was the only user of this
On Thu, Mar 31, 2005 at 06:08:10PM +0900, Tejun Heo wrote:
> struct list_headsiblings; /* list of all devices on this host */
> struct list_headsame_target_siblings; /* just the devices sharing
> same target id */
>
> - volatile unsigned short device_busy;/* command
> /* Queue the command and wait for it to complete */
> /* Abuse eh_timeout in the scsi_cmnd struct for our purposes */
> init_timer(&cmd->eh_timeout);
> + cmd->eh_timeout.function = NULL;
I'd rather not see aic7xxx poke even deeper into this i
> +/*
> + * Macro to determine the size of SCSI command. This macro takes vendor
> + * unique commands into account. SCSI commands in groups 6 and 7 are
> + * vendor unique and we will depend upon the command length being
> + * supplied correctly in cmd_len.
> + */
> +#define CDB_SIZE(cmd)(
> - /*
> - * This sets up the scatter-gather table (allocating if
> - * required).
> - */
> + /* This sets up the scatter-gather table (allocating if
> + * required). */
the old comment style is the preferred in linux, pl
> i have released the -V0.7.41-25 Real-Time Preemption patch,
> which can be
> downloaded from the usual place:
1. Does not compile without RT_DEADLOCK_DETECT:
kernel/rt.c: In function `change_owner':
kernel/rt.c:556: error: structure has no member named `debug'
kernel/rt.c: In function `pi_setp
On Wed, Mar 30, 2005 at 04:44:55PM -0500, Dave Jones wrote:
> [apologies to Andi for getting this twice, I goofed the l-k address
> the first time]
>
>
> I arrived at the office today to find my workstation had this spew
> in its dmesg buffer..
Looks like random memory corruption to me.
Can
On Wed, Mar 30, 2005 at 07:32:16PM +0200, [EMAIL PROTECTED] wrote:
>
> CC: Andi Kleen <[EMAIL PROTECTED]>
>
> Keeping this function does not makes sense because it's a copied (and buggy)
> copy of sys_time. The only difference is that now.tv_sec (which is a time_t,
> i.e. a 64-bit long) is copied
Hello Herbert,
> The GNU coding style is completely different from Linux.
Ok, NP.
> Please reformat it when you fix up the overhead calculation.
Sure.
> Good catch. I'll apply this one.
Only one small note: I've spotted this but didn't test. I didn't make
sure this is OK if we haven't ever used
> - * Arguments:q - queue to operate on
> - * cmd - command that may need to be requeued.
> + * Arguments:cmd - command that may need to be requeued.
> + * reprep - needs to prep the command again?
> *
> * Returns: Nothing
> *
> @@ -478,11 +
Hi Andrew,
The following patch adds a sysrq-trigger mechanism for kexec
based crashdumps. Alt-Sysrq-c triggers a kexec based
crashdump. Please include this along with the crashdumps
patches in the -mm tree.
Thanks and Regards, Hari
Signed-off-by: Hariprasad Nellitheertha <[EMAIL PROTECTED]>
-
Andrew Morton wrote:
...
make-sysrq-f-call-oom_kill.patch
make sysrq-F call oom_kill()
Glad to see it fixed. :)
-
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.htm
>>i'm doing project on TFTP n need the practical
scenario
>of implimentation.assist me in bringing out the best
>design.
regards,
kishore
__
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resourc
> > Ok. I will change it to a VMA.
>
> Thanks. (It's only the 32-bit emulation case I'm caring about,
I did the patch now and it works, but due to some technical problems I can only
upload it next week. Surprisingly the new code is actually shorter
than the old one and cleaner too.
> that poses
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> Well, here it finally is. There's still things I don't like about it.
> But it seems to work, and that's the important part.
>
> I had to reluctantly add two items to the task_struct. I was hoping
> to avoid that. But because of race conditions it
On Thu, 2005-03-31 at 02:47, Randy.Dunlap wrote:
> RFC: This is a work-in-progress (WIP), not yet completed.
>
> A few people dislike that the Networking Options menu is inside
> the Device Drivers/Networking menu. This patch moves the
> Networking Options menu to immediately before the Device D
> > The test system runs a 2.6.11 kernel (no SMP) on a Pentium3 500 MHz
> > embedded hardware.
>
> which probably has memory bandwidth of at most a couple hundred MB/s,
> which is really horrible by modern standards.
It's my job to find out if linux can be used for control systems
on this (and
On Thu, 31 Mar 2005 12:38:34 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> Nack. The generic sys_time still writes to int, not long.
> That is why x86-64 has a private one. Please keep that.
It writes to a time_t which is a __kernel_time_t which is a long on
x86-64, isn't it?
--
Cheers,
Stephe
Artem B. Bityuckiy <[EMAIL PROTECTED]> wrote:
>
>> Good catch. I'll apply this one.
> Only one small note: I've spotted this but didn't test. I didn't make
> sure this is OK if we haven't ever used the compression and remove the
> deflate module. (i.e, in this case we call zlib_[in|de]flateEnd()
On Thu, Mar 31, 2005 at 09:10:59PM +1000, Stephen Rothwell wrote:
> On Thu, 31 Mar 2005 12:38:34 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote:
> >
> > Nack. The generic sys_time still writes to int, not long.
> > That is why x86-64 has a private one. Please keep that.
>
> It writes to a time_t which
> The latencies are almost certainly caused by the USB host controller
> driver. I'm planning improvements to uhci-hcd which should
> help reduce
> the latency, but it will still be on the large side. And I
> won't have
> time to write the changes to the driver for several months.
Any numbe
the changes look good to me (although I haven't tested any of your patches
yet), but the code flow is rather confusing. What do you think about
the not even compile version of scsi_request_fn() below that should be
functionally identical to yours:
static void scsi_request_fn(struct request_queu
On Thu, 31 Mar 2005 13:12:35 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> On Thu, Mar 31, 2005 at 09:10:59PM +1000, Stephen Rothwell wrote:
> > On Thu, 31 Mar 2005 12:38:34 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote:
> > >
> > > Nack. The generic sys_time still writes to int, not long.
> > > Tha
* kus Kusche Klaus <[EMAIL PROTECTED]> wrote:
> > i have released the -V0.7.41-25 Real-Time Preemption patch,
> > which can be
> > downloaded from the usual place:
>
> 1. Does not compile without RT_DEADLOCK_DETECT:
> kernel/rt.c: In function `change_owner':
> kernel/rt.c:556: error: structure
If u search for usleep in google then first document says that usleep will
have max range of 1,000,000 microseconds as the max sleep delay and
after the delay time expires the actual execution may get delayed because
of high system activity.
If you are writing kernel modules, you may use schedule
> This patch fixes the above problem by doing a proper exit while avoiding
> recursion.
> Any pointers/suggestions on the above issues will be helpful.
Patch is fine for x86-64.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PRO
* kus Kusche Klaus <[EMAIL PROTECTED]> wrote:
> I've written a small test program which enables periodic RTC
> interrupts at 8192 Hz and then goes into a loop reading /dev/rtc and
> collecting timing statistics (using the rdtscl macro).
getting /dev/rtc handling right for latency measurement i
On Thu, Mar 31, 2005 at 09:25:16PM +1000, Stephen Rothwell wrote:
> On Thu, 31 Mar 2005 13:12:35 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote:
> >
> > On Thu, Mar 31, 2005 at 09:10:59PM +1000, Stephen Rothwell wrote:
> > > On Thu, 31 Mar 2005 12:38:34 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote:
> > >
On Wed, March 30, 2005 2:57 pm, linux-os said:
> Yes. And this would show that whomever did that already violated the
> intent of the GPL by adding restrictions to use. NotGood(tm).
Dick,
You are so full of shit. There are no additonal restrictions, just the
restrictions of the GPL; period. A
Paul Jackson writes:
> Yup - kills my x86_64 too. I can't stay up for half a minute.
...
> My mainboard is an MSI K8N Neo2 Platinum.
I've tested both versions of the test program on two Athlon64 boxes,
and neither has had any problems with them.
My two machines are both VIA K8T800-based (a des
Greg KH schrieb:
> On Wed, Mar 30, 2005 at 11:17:42PM -0500, Jeff Garzik wrote:
>
>>Should hopefully just be changing get-version.pl ...
>
>
> Nah, this simple patch to snapshot fixes it.
>
> I've also generated the 2.6.12-rc1-bk3 snapshot and fixed up the
> directory on kernel.org so it should
Hi Marc,
Using Dave Jones memset script to detect swapped arguments, I found two
such instances. Patch attached.
Thanks
Vinay
nubus/nubus.c |2 +-
usb/dabusb.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
=
* kus Kusche Klaus <[EMAIL PROTECTED]> wrote:
> I'm performing realtime latency tests (for details about the hardware
> and software, see my mail "[BUG] 2.6.11: Random SCSI/USB errors when
> reading from USB memory stick" erlier today).
>
> Even when the errors described in my previous mail do
Hello,
I have programmed a universal module to register/remove kprobes handlers
by interacting with /proc with simple commands.
The handlers must be in kernel and can be executed before or after
the function at which the breakpoints are placed. It works with 2.6.11.
No kernel tree modifications nee
to den 31.03.2005 Klokka 09:30 (+0200) skreiv Ingo Molnar:
> > And presumably that list-based code rarely hits the worst-case, else
> > it would have been changed by now.
>
> that was my other point in a previous mail: most write benchmarks do
> continuous append writes, and CPU overhead easily
On Thu, 31 Mar 2005, Ingo Molnar wrote:
>
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > Well, here it finally is. There's still things I don't like about it.
> > But it seems to work, and that's the important part.
> >
> > I had to reluctantly add two items to the task_struct. I was hop
> Latency is the subject of a separate email. Does this
> increase in latency
> occur only when you see the errors, or whenever you do a large data
> transfer? In fact, I would suspect the errors to _decrease_
> the latency
> with respect to a normal transfer.
I observe from <1 to 2 ms on s
> I couldn't find that previous email in the MARC archives.
>
> Regardless, you'd have to provide a small bit of information about
> your hardware configuration. What device speed: full or high?
> What controller: EHCI, OHCI, UHCI, something else? Which driver
> for the stick: usb-storage, or
On Thu, 2005-03-31 at 13:03 +0100, Esben Nielsen wrote:
> On Thu, 31 Mar 2005, Ingo Molnar wrote:
>
> >
> > * Steven Rostedt <[EMAIL PROTECTED]> wrote:
> >
> > > Well, here it finally is. There's still things I don't like about it.
> > > But it seems to work, and that's the important part.
> >
On Thu, 2005-03-31 at 13:03 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > Well, here it finally is. There's still things I don't like about it.
> > But it seems to work, and that's the important part.
> >
> > I had to reluctantly add two items to the task_struct.
On czwartek 31 marzec 2005 09:45, DervishD wrote:
> The fact is that, in the past, I've used kernel headers older
> than my running kernel for building glibc and my system worked
> seamlessly (although I don't use bleeding edge features, you know),
> but I don't want to take risks.
You risk no
Hi!
Attached one-liner should fix possible Oops on quotaoff - the code
does not expect quotafiles to have any dquots initialized but they
actually could have some in the following scenario:
turn on one quota type
write to the file with the other quota type (quota gets initialize)
turn on
to den 31.03.2005 Klokka 06:58 (-0500) skreiv Trond Myklebust:
>
> @@ -563,11 +566,14 @@ static int
> nfs_scan_commit(struct inode *inode, struct list_head *dst, unsigned long
> idx_start, unsigned int npages)
> {
> struct nfs_inode *nfsi = NFS_I(inode);
> - int res;
> - res
Sergio Chiesa wrote:
7.7.
Well, it seems that with the original onboard raid controller the bug
didn't trigger... the controller was swapped with the lsi logic by my
supplier because it fails badly with raid-5 arrays (hw/fw related issue)
I also tried the original broadcom driver version 7.3.5 with
On Thu, 2005-03-31 at 13:03 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> your patch looks good, i've added it to my tree and have uploaded the
> -26-00 patch. It boots fine on my testbox, except for some new messages:
>
> knodemgrd_0/902: BUG in __down_complete a
On Thu, 31 Mar 2005, Sean wrote:
On Wed, March 30, 2005 2:57 pm, linux-os said:
Yes. And this would show that whomever did that already violated the
intent of the GPL by adding restrictions to use. NotGood(tm).
Dick,
You are so full of shit. There are no additonal restrictions, just the
restrictio
On Thu, 2005-03-31 at 13:03 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
> knodemgrd_0/902: BUG in __down_complete at kernel/rt.c:1568
> [] dump_stack+0x23/0x25 (20)
> [] down_trylock+0x1fb/0x200 (48)
> [] nodemgr_host_thread+0xd0/0x17b (48)
> [] kernel_thread_h
James Bottomley <[EMAIL PROTECTED]> writes:
> > > > Would you consider to apply the following patch proposed by
> > > > Thierry Vignaud as a solution for the MandrakeSoft kernel in
> > > > the mainstream 2.6 kernel ?
> > >
> > > Well, to be considered you'd need to cc the megaraid maintainers
> >
On Thu, 2005-03-31 at 07:36 -0500, Steven Rostedt wrote:
> On Thu, 2005-03-31 at 13:03 +0200, Ingo Molnar wrote:
> > * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> Since this happened with the trylock, do you see anyway that a pending
> owner can cause problems? Maybe this has to do with is_loc
On Thu, 31 March 2005 12:26:58 +0300, Denis Vlasenko wrote:
>
> Is this a syscall?
> Is it ever called from some deeply nested kernel function?
Never showed up in any of my callchain-tests. I'd leave it as is.
Jörn
--
When I am working on a problem I never think about beauty. I think
only ho
> - tg3 and bcm5700 totally overlap
bcm5700 isn't in the tree.
> - the same for e100 and eepro100, e1000 and eepro1000
there's no eepro1000
> - sata drivers ahci and ata_piix used to overlap too on a cople of
> devices
> - b44 and bcm4400 totally overlap
bcm4000 isn't in the tree
-
To unsub
On Wed, 30 March 2005 23:44:38 -0800, Yum Rayan wrote:
>
> sys_reboot - 256
Also not part of any deep stack trace I found.
Jörn
--
There is no worse hell than that provided by the regrets
for wasted opportunities.
-- Andre-Louis Moreau in Scarabouche
-
To unsubscribe from this list
On Friday 25 March 2005 17:46, Borislav Petkov wrote:
> Hi Andrew,
>
> mm3 still not booting on my machine. Boot option 'nmi_watchdog=2' (my cpu
> is a dual core pentium 4 HT, 2.60 GHz) gets me a bit further in the boot
> process but it blocks there too.
>
> [output retyped from screen]:
> kernel:
Hi Jan,
I'm afraid that there is a bug in quota format v2 delete qentry.
(The root block shouldn't be put into free blk list even if there isn't
any entry in quota file, right?)
This one line patch may fix it.
Thanks.
- Niu
--- linux-2.6.7/fs/quota_v2.c 2005-01-21 16:47:34.0 +0800
+++ lin
Hi all,
one of our file servers (SuSE Linux 7.2, running "linux-2.4.29")
oopsed some days ago - here is the bug report:
[1.] One line summary of the problem:
Kernel "linux-2.4.29" oopses irregularly. The oopses seem to be
triggered by high I/O load on the SCSI subsystem.
[2.] Full descripti
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > I'll play around some more with this.
>
> Oops! Found a little bug. Ingo, see if this fixes it.
yeah, that was it. I've uploaded -42-02 with the fix included.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > I was going to say the opposit. I know that there are many more rt_locks
> > locks around and the fields thus will take more memory when put there but
> > I believe it is more logical to have the fields there.
>
> It seems logical to be there, but
> On Mon, Mar 28, 2005 at 07:57:52PM +0500, Ara Avanesyan wrote:
> > Hi,
> >
> > I need some help on solving this strange problem.
> > Here is what I have,
> > I have a loadable module (linux.2.4.20) which contains a 2 mb static
gloabal
> > array.
> > When I load it from linux booted via U-Boot the
1 - 100 of 351 matches
Mail list logo
