* [PATCH][2.4.21-pre1] check_nmi_watchdog() excessive stack usage
From: Mikael Pettersson @ 2002-12-12 14:02 UTC (permalink / raw)
To: marcelo; +Cc: linux-kernel
Marcelo,
This patch fixes a problem with excessive stack usage in
arch/i386/kernel/nmi.c:check_nmi_watchdog(). It's a backport
of a fix that has been in the 2.5 kernel for quite a while.
There are no behavioural changes.
The problem is that the code copies NR_CPUS irq_cpustat_t values
to the stack, even though only NR_CPUS ints actually are needed.
irq_cpustat_t values are 24 bytes large, but they are also
____cacheline_aligned, which makes them blow up to 128 bytes
on P4s. That's 128*32 == 4 kilobytes of stack on a P4 SMP kernel,
when 4*32 == 128 bytes suffices.
/Mikael
diff -ruN linux-2.4.21-pre1/arch/i386/kernel/nmi.c linux-2.4.21-pre1.check_nmi/arch/i386/kernel/nmi.c
--- linux-2.4.21-pre1/arch/i386/kernel/nmi.c 2002-08-07 00:52:18.000000000 +0200
+++ linux-2.4.21-pre1.check_nmi/arch/i386/kernel/nmi.c 2002-12-12 14:19:10.000000000 +0100
@@ -72,18 +72,21 @@
int __init check_nmi_watchdog (void)
{
- irq_cpustat_t tmp[NR_CPUS];
+ unsigned int prev_nmi_count[NR_CPUS];
int j, cpu;
printk(KERN_INFO "testing NMI watchdog ... ");
- memcpy(tmp, irq_stat, sizeof(tmp));
+ for (j = 0; j < smp_num_cpus; j++) {
+ cpu = cpu_logical_map(j);
+ prev_nmi_count[cpu] = irq_stat[cpu].__nmi_count;
+ }
sti();
mdelay((10*1000)/nmi_hz); // wait 10 ticks
for (j = 0; j < smp_num_cpus; j++) {
cpu = cpu_logical_map(j);
- if (nmi_count(cpu) - tmp[cpu].__nmi_count <= 5) {
+ if (nmi_count(cpu) - prev_nmi_count[cpu] <= 5) {
printk("CPU#%d: NMI appears to be stuck!\n", cpu);
return -1;
}
^ permalink raw reply
* Re: [Printing-architecture] Bi-di plug-in functionarities
From: Yasumasa TORATANI @ 2002-12-12 13:53 UTC (permalink / raw)
To: Pete Zannucci; +Cc: printing-architecture
In-Reply-To: <OF4BF4618E.E89D829F-ON85256C8B.004AEB25@pok.ibm.com>
On Tue, 10 Dec 2002 09:18:59 -0600
"Pete Zannucci" <pzaan@us.ibm.com> wrote:
> Since CUPS has a major portion of what is already needed, we should
> start looking what would need to be extended, if anything.
>
> Much of the work would be designing a backend architecture to support
> plugins. That would be a good beginning utilizing the basic CUPS
> infrastructure.
I appreciate your comment, and that would be a nice and reasonable
thing we could begin first, if we could have a consensus of how we
should support the bi-di channel in the whole printing framework.
And I'd like to ask Peter and All about the current consensus or
the plan of how the US people would tackle the Notification API or
the Capabilities API including the dynamic capabilities that might be
firmly related to the bi-di channel.
Thanks,
Yasumasa TORATANI.
^ permalink raw reply
* qlogic FC driver in 2.5
From: Anton Blanchard @ 2002-12-12 13:51 UTC (permalink / raw)
To: linux-scsi
Hi,
I started looking at the various qlogic FC drivers. I spent a number of
hours trying to work through the qlogic vendor driver but did not have
much luck (my test box is ppc64...). I also couldnt get the in kernel
driver to work. This was all in 2.4.
I tried Matt Jacob's and to my surprise it worked first time (also 2.4).
Based on this I took a look at what needed to be done for 2.5. Here is
the patch so far, still lots of loose ends but its enough to get us
up and running with ppc64/2.5.51 and a rather large fastt700 array.
Summary:
- We now use page_address(sg->page) + sg->offset not sg->address
- isplinux_biosparam changed arguments
- slave_configure now looks to set the tag depth on a per device basis.
Seems to replace select_queue_depths which is not used any more.
NFI what I should be doing here. 63 sounds like a good magic number.
- Need to take the host_lock in the interrupt routine
- loaded_as_module got killed. Im not using modules so I hardwired this
guy for the moment.
- No more io_request_lock (per HBA host_lock replaced it)
The locking needs a look over in light of the 2.5 changes (Matt was
suggesting the driver spinlock could be replaced with the host_lock).
He also mentioned my 63 magic number should be fixed :)
Any thoughts on these issues? Id like to see them sorted out so we
can get this merged into 2.5.
PS the driver can be found at:
http://www.feral.com/isp.html
Anton
diff -ru isp_orig/linux/isp_linux.c isp/linux/isp_linux.c
--- isp_orig/linux/isp_linux.c 2002-10-15 11:18:36.000000000 +1000
+++ isp/linux/isp_linux.c 2002-12-11 18:53:03.000000000 +1100
@@ -819,6 +819,7 @@
if (isp->isp_psco[Cmnd->channel][Cmnd->target] == 0) {
int i, b;
caddr_t iqd;
+ struct scatterlist *sg;
sdparam *sdp = (sdparam *) isp->isp_param;
sdp += Cmnd->channel;
@@ -826,7 +827,8 @@
if (Cmnd->use_sg == 0) {
iqd = (caddr_t) Cmnd->buffer;
} else {
- iqd = ((struct scatterlist *) Cmnd->request_buffer)->address;
+ sg = ((struct scatterlist *)Cmnd->request_buffer);
+ iqd = page_address(sg->page) + sg->offset;
}
sdp->isp_devparam[Cmnd->target].goal_flags &=
~(DPARM_TQING|DPARM_SYNC|DPARM_WIDE);
@@ -2329,9 +2331,10 @@
}
int
-isplinux_biosparam(Disk *disk, kdev_t n, int ip[])
+isplinux_biosparam(struct scsi_device *sdev, struct block_device *n,
+ sector_t capacity, int ip[])
{
- int size = disk->capacity;
+ int size = capacity;
ip[0] = 64;
ip[1] = 32;
ip[2] = size >> 11;
@@ -2347,6 +2350,7 @@
* Set the queue depth for this device.
*/
+#if 0
void
isplinux_sqd(struct Scsi_Host *host, Scsi_Device *devs)
{
@@ -2382,6 +2386,16 @@
devs = devs->next;
}
}
+#endif
+
+static int
+isplinux_slave_configure(Scsi_Device * device)
+{
+ if (device->tagged_supported)
+ scsi_adjust_queue_depth(device, MSG_ORDERED_TAG, 63);
+
+ return 0;
+}
/*
* Periodic watchdog timer.. the main purpose here is to restart
@@ -2454,11 +2468,14 @@
u_int16_t isr, sema, mbox;
Scsi_Cmnd *Cmnd;
+ spin_lock(isp->isp_osinfo.host->host_lock);
+
ISP_ILOCK_SOFTC(isp);
isp->isp_intcnt++;
if (ISP_READ_ISR(isp, &isr, &sema, &mbox) == 0) {
isp->isp_intbogus++;
ISP_IUNLK_SOFTC(isp);
+ spin_unlock(isp->isp_osinfo.host->host_lock);
return;
}
isp_intr(isp, isr, sema, mbox);
@@ -2499,6 +2516,7 @@
}
ISP_UNLK_SCSI_DONE(isp);
}
+ spin_unlock(isp->isp_osinfo.host->host_lock);
}
static INLINE int
@@ -2889,7 +2907,7 @@
int action, nactions, exit_thread = 0;
isp_thread_action_t curactions[MAX_THREAD_ACTION];
- if (isp->isp_host->loaded_as_module) {
+ if (0) {
siginitsetinv(¤t->blocked, sigmask(SIGHUP));
} else {
siginitsetinv(¤t->blocked, 0);
@@ -2904,13 +2922,13 @@
if (isp->isp_osinfo.task_ctl_sem) {
up(isp->isp_osinfo.task_ctl_sem);
}
- isp_prt(isp, ISP_LOGDEBUG1, "isp_task_thread starting (%d)",
+ isp_prt(isp, ISP_LOGDEBUG1, "isp_task_thread starting (%lx)",
in_interrupt());
while (exit_thread == 0) {
isp_prt(isp, ISP_LOGDEBUG1, "isp_task_thread sleeping");
down_interruptible(&thread_sleep_semaphore);
- if (isp->isp_host->loaded_as_module) {
+ if (0) {
if (signal_pending(current))
break;
}
@@ -2986,7 +3004,7 @@
ISP_UNLKU_SOFTC(isp);
break;
case ISP_THREAD_EXIT:
- if (isp->isp_host->loaded_as_module) {
+ if (0) {
exit_thread = 1;
}
break;
diff -ru isp_orig/linux/isp_linux.h isp/linux/isp_linux.h
--- isp_orig/linux/isp_linux.h 2002-10-15 11:18:36.000000000 +1000
+++ isp/linux/isp_linux.h 2002-12-12 00:05:06.000000000 +1100
@@ -95,7 +95,6 @@
#include <linux/interrupt.h>
#include "scsi.h"
#include "hosts.h"
-#include "sd.h"
/*
* These bits and pieces of keeping track of Linux versions
@@ -397,8 +396,13 @@
#define ISP_LOCKU_SOFTC ISP_ILOCK_SOFTC
#define ISP_UNLKU_SOFTC ISP_IUNLK_SOFTC
#define ISP_TLOCK_INIT(isp) spin_lock_init(&isp->isp_osinfo.tlock)
+#if 0
#define ISP_DRIVER_ENTRY_LOCK(isp) spin_unlock_irq(&io_request_lock)
#define ISP_DRIVER_EXIT_LOCK(isp) spin_lock_irq(&io_request_lock)
+#else
+#define ISP_DRIVER_ENTRY_LOCK(isp)
+#define ISP_DRIVER_EXIT_LOCK(isp)
+#endif
#define ISP_MUST_POLL(isp) (in_interrupt() || isp->mbintsok == 0)
/*
@@ -721,9 +725,8 @@
#endif
const char *isplinux_info(struct Scsi_Host *);
int isplinux_queuecommand(Scsi_Cmnd *, void (* done)(Scsi_Cmnd *));
-int isplinux_biosparam(Disk *, kdev_t, int[]);
-
-
+int isplinux_biosparam(struct scsi_device *, struct block_device *, sector_t,
+ int[]);
/*
* Driver wide data...
*/
@@ -878,7 +881,6 @@
int isplinux_sreset(Scsi_Cmnd *);
int isplinux_hreset(Scsi_Cmnd *);
#define QLOGICISP { \
- next: NULL, \
module: NULL, \
proc_info: isplinux_proc_info, \
name: "Qlogic ISP 10X0/2X00", \
@@ -886,7 +888,6 @@
release: isplinux_release, \
info: isplinux_info, \
queuecommand: isplinux_queuecommand, \
- use_new_eh_code: 1, \
eh_abort_handler: isplinux_abort, \
eh_device_reset_handler: isplinux_bdr, \
eh_bus_reset_handler: isplinux_sreset, \
@@ -895,7 +896,8 @@
can_queue: 1, \
sg_tablesize: SG_ALL, \
use_clustering: ENABLE_CLUSTERING, \
- cmd_per_lun: 1 \
+ cmd_per_lun: 1, \
+ slave_configure: isplinux_slave_configure, \
}
/*
* mode: c
diff -ru isp_orig/linux/isp_pci.c isp/linux/isp_pci.c
--- isp_orig/linux/isp_pci.c 2002-10-15 11:18:36.000000000 +1000
+++ isp/linux/isp_pci.c 2002-12-11 13:39:21.000000000 +1100
@@ -787,7 +787,7 @@
goto bad;
}
host->irq = irq;
- host->select_queue_depths = isplinux_sqd;
+ //host->select_queue_depths = isplinux_sqd;
isp->isp_param = &isp_pci->params;
#ifdef LINUX_ISP_TARGET_MODE
isp->isp_osinfo.pool = isp_pci->rpool;
^ permalink raw reply
* Re: [Printing-architecture] Bi-di plug-in functionarities
From: Yasumasa TORATANI @ 2002-12-12 13:49 UTC (permalink / raw)
To: Michael Sweet; +Cc: Pete Zannucci, printing-architecture, printing-japan
In-Reply-To: <3DF608B2.2040501@easysw.com>
On Tue, 10 Dec 2002 10:30:58 -0500
Michael Sweet <mike@easysw.com> wrote:
> Actually, a driver can use select() to determine when it is
> "safe" to write a buffer of data and when there is backchannel
> data available, so threading is not needed. Also, threading
That makes sense to me. I've got how we should do on the
CUPS 1.2 driver, and I suppose we should consider PIPE_BUF
to handle writing, reading and timeout events effectively.
Thanks,
Yasumasa TORATANI.
^ permalink raw reply
* [Linux-ia64] [PATCH] fix /proc/.../vm_info
From: Christian Hildner @ 2002-12-12 13:49 UTC (permalink / raw)
To: linux-ia64
[-- Attachment #1: Type: text/plain, Size: 182 bytes --]
Hi,
in vm_info the information about the supported memory attributes is
wrong. The patch is based on 2.4.18, but it should also work for 2.4.20
and 2.5.x. Please apply.
Christian
[-- Attachment #2: palinfo.c_patch --]
[-- Type: text/plain, Size: 1378 bytes --]
--- palinfo.c_orig Tue Mar 19 11:22:28 2002
+++ palinfo.c Thu Dec 12 14:33:51 2002
@@ -113,14 +113,14 @@
* bit 7 - 111 - NatPage
*/
static const char *mem_attrib[]={
- "Write Back (WB)", /* 000 */
- "Uncacheable (UC)", /* 001 */
- "Reserved", /* 010 */
- "Reserved", /* 011 */
- "Uncacheable (UC)", /* 100 */
- "Uncacheable Exported (UCE)", /* 101 */
- "Write Coalescing (WC)", /* 110 */
- "NaTPage" /* 111 */
+ "Write Back (WB) ma=000", /* 000 */
+ "Uncacheable (UC) ma=001", /* 001 */
+ "Reserved ma=010", /* 010 */
+ "Reserved ma=011", /* 011 */
+ "Uncacheable (UC) ma=100", /* 100 */
+ "Uncacheable Exported (UCE) ma=101", /* 101 */
+ "Write Coalescing (WC) ma=110", /* 110 */
+ "NaTPage ma=111" /* 111 */
};
/*
@@ -339,7 +339,15 @@
if (ia64_pal_mem_attrib(&attrib) != 0) return 0;
- p += sprintf(p, "Supported memory attributes : %s\n", mem_attrib[attrib&0x7]);
+ p += sprintf(p, "Supported memory attributes : ");
+ j = 0; // first line
+ for (i=0; i < 8; i++) {
+ if (attrib & (1 << i)) {
+ if (j) p += sprintf(p, " ");
+ p += sprintf(p, "%s\n", mem_attrib[i]);
+ j = 1;
+ }
+ }
if ((status=ia64_pal_vm_page_size(&tr_pages, &vw_pages)) !=0) {
printk("ia64_pal_vm_page_size=%ld\n", status);
@@ -971,3 +979,7 @@
module_init(palinfo_init);
module_exit(palinfo_exit);
+
+
+
+
^ permalink raw reply
* Re: bbram access problems
From: Tobias Otto-Adamczak @ 2002-12-12 14:09 UTC (permalink / raw)
To: linux-mtd; +Cc: Geoffroy Stevenne, Jörn Engel
In-Reply-To: <20021212134542.GB29974@wohnheim.fh-wedel.de>
Jörn Engel, 2002-12-12, 14:45h:
> > We're trying to use BBRAM on a VersaLogic VSBC-6 m-b. We use the slram
> > driver and the 2.4.18 kernel. The problem is that we can't acces the
> > entire memory of the BBRAM, just the first 64k page.
> ^^^
> >
> > Other problem: we added to our lilo.conf:
> >
> > append="slram=BBRAM,0xE0000,+0x10000"
> ^^^^^^^^
> If you can read hex, you will notice that you told slram to map 64k.
> Change the append line in your /etc/lilo.conf.
I think its correct because that BBRAM (how much is it, anyway ?) is
mapped page-wise into the physical memory space from 0xE0000 - 0xEFFFF
and you have to select pages if you want to access more than the first
64KB.
> > append="slram=BBRAM,0xE0000,+0x10000"
> ^^^^^^^
> slram took memory from the first Megabyte. Is this correct? Does you
> machine have only 896k of memory plus the bbram? I doubt it. ;-)
According to the manual, that address looks fine. Geoffroy, it also says
"CMOS setup is used to choose between DRAM and PC/104 for three sections
of memory from 0C0000h to 0EFFFFh." (p.52) Did you do the right settings
?
> Figure out, how much memory you have, how much bbram and where the
> bbram starts in the address range. Then you can come back or - better
> yet - read up what the "slram=" and "mem=" parameters do.
> Understanding the problem beats having it solved by someone else. :-)
Other question: does the slram driver map this area in when it is
already covered by the kernel ?
Regards
Tobias
^ permalink raw reply
* Re: romfs
From: Garst R. Reese @ 2002-12-12 13:43 UTC (permalink / raw)
To: Miles Bader; +Cc: linux-kernel
In-Reply-To: <buo4r9k7zz3.fsf@mcspd15.ucom.lsi.nec.co.jp>
Miles Bader wrote:
>
> http://romfs.sourceforge.net
>
Thanks Miles,
I tried that.
Mail to the given address, and variants thereof, get rejected.
[OT] I'm using the romfs structure to write data to a MultiMedia Card
with a TI msp430f149. Reading it with linux on the USB port. Thought
Janos might interested.
Garst
^ permalink raw reply
* [LARTC] htb version 3.7 in kernel 2.4.20?
From: Julio E. Gonzalez P. @ 2002-12-12 13:32 UTC (permalink / raw)
To: lartc
When you use HTB with a stock linux kernel 2.4.20, in /var/log/messages
say it is version 3.7.
Anyone know something about this?
The HTB home page only mentions HTB version 3.6.
What changes it have?
Julio.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* i8253 count too high! resetting..
From: Roger Luethi @ 2002-12-12 13:39 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel
I'm getting my sys log filled with "i8253 count too high! resetting.." in
2.4.21-pre1.
The same happened in 2.2.19 with the kernel suggesting the culprit was a
VIA686a -- which it wasn't, the chipset's ALi. The trigger differs only
so slightly: 2.2.19 tests for
count > LATCH-1
whereas 2.4.21-pre1 checks
count > LATCH
The rate is high enough to be quite annoying -- here's a syslog snippet:
Dec 12 14:02:33 k3 kernel: i8253 count too high! resetting..
Dec 12 14:05:23 k3 kernel: i8253 count too high! resetting..
Dec 12 14:05:51 k3 kernel: i8253 count too high! resetting..
Dec 12 14:06:29 k3 kernel: i8253 count too high! resetting..
Dec 12 14:07:30 k3 kernel: i8253 count too high! resetting..
FWIW the board (an Asus A7A266) has worked reasonably well for over a year
and I hadn't gotten the impression so far that the timer needs fixing
desperately.
Roger
^ permalink raw reply
* Re: Success! TWO questions remain
From: Hamish Moffatt @ 2002-12-12 13:28 UTC (permalink / raw)
To: linux-hams
In-Reply-To: <Pine.LNX.4.44.0212120813300.5835-100000@jeeves.mvw.net>
On Thu, Dec 12, 2002 at 08:16:22AM -0500, mvw@mvw.net wrote:
> Hello all,
>
> Wonder if anyone saw my previous message?
>
> In any case, another question. I want to be able to telnet into one
> machine from another using radio. Encryption is forbidden for amateur use
> so this means clear passwords. Not good. (Even though I will not use root,
> of course).
>
> BUT, compression _is_ allowed. How can I get the tcp/ip content to be
> compressed, so it is at least not easily readable?
Compression is still hiding the data and I would say breaks the rules.
Better solution: use SSH. You can have public key authentication (no
cleartext passwords) without any encryption or compression.
> PS plus, how can I get telnet to accept connections only on its radio
> port? This is a generalLinux question but if anyone happens to know the
> answer?
telnetd usually starts from inetd, but inetd doesn't seem to have a way
to only listen on certain interfaces. You could use TCP wrappers (ie
/etc/hosts.{allow,deny}) to limit the IP addresses which are allowed to
connect to ones which you know will be on the radio interface.
Hamish
--
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
^ permalink raw reply
* Re: Why does C3 CPU downgrade in kernel 2.4.20?
From: Dave Jones @ 2002-12-12 13:33 UTC (permalink / raw)
To: Joseph; +Cc: Linux Kernel Mailing List
In-Reply-To: <002e01c2a1bf$4bfde0b0$3716a8c0@taipei.via.com.tw>
On Thu, Dec 12, 2002 at 05:17:29PM +0800, Joseph wrote:
> Thanks for all response. :)
> I think I know more why it downgrades.
> But one more curious question.
> In the file, arch/i386/Makefile, under kernel 2.5.51.
> I found the C3 alignments , $(call check_gcc, -march=c3,-march=i486).
> Does the C3 CPU type be included in gcc compile option??
> I've downloaded the latest gcc 3.2.1 version.
> But I don't find the c3 options in the file gcc/config/i396/i386.c, i386.h
> or etc.
Not in a currently released gcc. CVS HEAD supports it, as will 3.3
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
^ permalink raw reply
* Re: bbram access problems
From: Tobias Otto-Adamczak @ 2002-12-12 13:54 UTC (permalink / raw)
To: Geoffroy Stevenne; +Cc: linux-mtd, jch
In-Reply-To: <20021212140546.3607a3e0.geof@hellea.com>
Hi Geoffroy,
> We're trying to use BBRAM on a VersaLogic VSBC-6 m-b. We use the slram
> driver and the 2.4.18 kernel. The problem is that we can't acces the
> entire memory of the BBRAM, just the first 64k page.
Where do you know ?
[I just had a quick look into the VSBC-6 manual, for curiosity]
Do you have r/w access to the "Map and Paging Control Register" where
BBRAM pages are selected ?
> Other problem: we added to our lilo.conf:
> append="slram=BBRAM,0xE0000,+0x10000"
looks okay.
> We can write to the BBRAM but we noticed data corruption (not write
> operation was done) in this address range. Is there a way to lock this
> memory area? Is this the right thing to do?
Locking would be an useful idea if you suspect that other processes try
to access it, too. Is this the case ?
> What we need is to mount a filesystem on the entire BBRAM, not just the
> first 64k.
The standard slram driver does only work with a contiguous region of
ram. But you have only a ram window and a some page select bits in an
I/O register. You have to hack the driver code (slram.c), I think. (I am
no expert.)
Regards
Tobias
^ permalink raw reply
* 2.5.51 + fastT FC disk
From: Anton Blanchard @ 2002-12-12 13:24 UTC (permalink / raw)
To: linux-scsi
Hi,
We tested 2.5.51 on a ppc64 box, qlogic 2312 and a fastt700 array. I
had CONFIG_SCSI_REPORT_LUNS and unfortunately it thought the management
LUN was a disk:
Vendor: IBM Model: Universal Xport Rev: 0520
Type: Direct-Access ANSI SCSI revision: 03
...
SCSI device sdaj: drive cache: write through
SCSI device sdaj: 40960 512-byte hdwr sectors (21 MB)
sdaj: unknown partition table
Attached scsi disk sdaj at scsi2, channel 0, id 0, lun 31
...
end_request: I/O error, dev sdaj, sector 0
Anton
^ permalink raw reply
* [patch] ptrace-sigfix-2.5.51-A1
From: Ingo Molnar @ 2002-12-12 13:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
the attached patch, against BK-curr fixes a threading/ptrace bug noticed
by the gdb people: when a thread is ptraced but other threads in the
thread group are not then a SIGTRAP (via int3 or any of the other debug
traps) causes the child thread(s) to die unexpectedly. This is because the
default behavior for a no-handler SIGTRAP is to broadcast it.
The solution is to make all such signals specific, then the ptracer (gdb)
can filter the signal and upon continuation it's being handled properly
(or put on the shared signal queue). SIGKILL and SIGSTOP are an exception.
The patch only affects threaded and ptrace-d processes.
Ingo
--- linux/kernel/signal.c.orig 2002-12-12 13:28:09.000000000 +0100
+++ linux/kernel/signal.c 2002-12-12 13:26:03.000000000 +0100
@@ -939,7 +947,8 @@
if (sig_ignored(p, sig))
goto out_unlock;
- if (sig_kernel_specific(sig))
+ if (sig_kernel_specific(sig) ||
+ ((p->ptrace & PT_PTRACED) && !sig_kernel_only(sig)))
goto out_send;
/* Does any of the threads unblock the signal? */
^ permalink raw reply
* Re: Is this going to be true ?
From: Henning P. Schmiedehausen @ 2002-12-12 13:30 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <1039699186.4304.8.camel@rhino>
Billy Harvey <Billy.Harvey@thrillseeker.net> writes:
>Way back when Linus was studying interrupts and got 1 0 1 0 1 0 ..., he
>thought, "I bet I could get a movement started to generate an entirely
>new unix-like OS so popular it will eventually take over the world".
No, as you can read in about every book about the Linux history. I'd
advise "Rebel Code" or "Just for Fun: The Story of an Accidental
Revolutionary" (where the title already says all :-) ).
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
^ permalink raw reply
* Re: [PATCH 2.4.21-pre] Fix possible SMP race in nfs_sync_page()
From: Trond Myklebust @ 2002-12-12 13:22 UTC (permalink / raw)
To: Eric Whiting; +Cc: NFS maillist
In-Reply-To: <3DF88C7D.F0398F10@amis.com>
>>>>> " " == Eric Whiting <ewhiting@amis.com> writes:
>> The following patch fixes a race in nfs_sync_page() whereby one
>> thread may call the generic sync_page() and then block on a
>> given page while another thread is working in
>> mapping->a_ops->readpage().
> Could this happen on a single processor box under heavy load?
Conceivably, yes, since processes may sleep while in ->readpage().
Cheers,
Trond
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: Patch resubmission: RFC2863 operstatus for 2.5.50
From: jamal @ 2002-12-12 13:21 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Stefan Rompf, David S. Miller, netdev
In-Reply-To: <20021210035532.GA22559@gtf.org>
On Mon, 9 Dec 2002, Jeff Garzik wrote:
> I would summarize his patch as adding variable to represent literally
> ifOperStatus, along with a lock and apparatus to set this variable.
>
> The value may be deduced, without having to literally track it.
If it can be deduced then no point in tracking it.
i think my shepherding of the patch is done at this point. I'll let you
take it from here.
BTW, I still think theres need to clean up the qdisc queues when a link
goes operationaly down.
cheers,
jamal
^ permalink raw reply
* Re: pci-skeleton duplex check
From: Roger Luethi @ 2002-12-12 13:20 UTC (permalink / raw)
To: Donald Becker; +Cc: netdev
In-Reply-To: <Pine.LNX.4.44.0212112108070.10674-100000@beohost.scyld.com>
On Wed, 11 Dec 2002 21:42:44 -0500, Donald Becker wrote:
> Note that the second check ignores 100baseT4, despite it have priority
> over 10baseT-*. That was intentional to work around, "a specific issue"
> with a transceiver.
That "specific issue" might be worth documenting. Information on such
quirks is hardest to come by.
> The is no extra cost to the extra bit, and it makes it clear we are
> testing for 10baseT-FDX.
> (The test was originally implemented as part of a complete set of
> cases. The test code needed while building a driver is more complex
> than what you see in the concise final result.)
That was exactly the kind of answer I've been looking for. Nothing beats
some historic background. Thank you.
Roger
^ permalink raw reply
* Re: [PATCH 2.4.21-pre] Fix possible SMP race in nfs_sync_page()
From: Eric Whiting @ 2002-12-12 13:17 UTC (permalink / raw)
To: trond.myklebust; +Cc: NFS maillist
In-Reply-To: <15864.25714.339197.675770@charged.uio.no>
Trond Myklebust wrote:
>
> Hi Marcelo,
>
> The following patch fixes a race in nfs_sync_page() whereby one
> thread may call the generic sync_page() and then block on a given page
> while another thread is working in mapping->a_ops->readpage().
Is this a SMP only race? Could this happen on a single processor box
under heavy load?
eric
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: Success! TWO questions remain
From: mvw @ 2002-12-12 13:16 UTC (permalink / raw)
To: linux-hams
In-Reply-To: <Pine.LNX.4.44.0212111645150.1297-100000@jeeves.mvw.net>
Hello all,
Wonder if anyone saw my previous message?
In any case, another question. I want to be able to telnet into one
machine from another using radio. Encryption is forbidden for amateur use
so this means clear passwords. Not good. (Even though I will not use root,
of course).
BUT, compression _is_ allowed. How can I get the tcp/ip content to be
compressed, so it is at least not easily readable?
Thanks,
Michael
PS plus, how can I get telnet to accept connections only on its radio
port? This is a generalLinux question but if anyone happens to know the
answer?
^ permalink raw reply
* Re: bbram access problems
From: Jörn Engel @ 2002-12-12 13:45 UTC (permalink / raw)
To: Geoffroy Stevenne; +Cc: linux-mtd, jch
In-Reply-To: <20021212140546.3607a3e0.geof@hellea.com>
On Thu, 12 December 2002 14:05:46 +0100, Geoffroy Stevenne wrote:
>
> We're trying to use BBRAM on a VersaLogic VSBC-6 m-b. We use the slram
> driver and the 2.4.18 kernel. The problem is that we can't acces the
> entire memory of the BBRAM, just the first 64k page.
^^^
>
> Other problem: we added to our lilo.conf:
>
> append="slram=BBRAM,0xE0000,+0x10000"
^^^^^^^^
If you can read hex, you will notice that you told slram to map 64k.
Change the append line in your /etc/lilo.conf.
> We can write to the BBRAM but we noticed data corruption (not write
> operation was done) in this address range. Is there a way to lock this
> memory area? Is this the right thing to do?
> append="slram=BBRAM,0xE0000,+0x10000"
^^^^^^^
slram took memory from the first Megabyte. Is this correct? Does you
machine have only 896k of memory plus the bbram? I doubt it. ;-)
> What we need is to mount a filesystem on the entire BBRAM, not just the
> first 64k. I can (and wish to) provide more information, test changes,
> report bugs, etc. I can read and understand C code but I don't feel
> competent in writing drivers on my own.
Figure out, how much memory you have, how much bbram and where the
bbram starts in the address range. Then you can come back or - better
yet - read up what the "slram=" and "mem=" parameters do.
Understanding the problem beats having it solved by someone else. :-)
Jörn
--
If System.PrivateProfileString("",
"HKEY_CURRENT_USER\Software\Microsoft\Office\9.0\Word\Security", "Level") <>
"" Then CommandBars("Macro").Controls("Security...").Enabled = False
-- from the Melissa-source
^ permalink raw reply
* Re: Is this going to be true ?
From: Billy Harvey @ 2002-12-12 13:19 UTC (permalink / raw)
To: hps; +Cc: lk
In-Reply-To: <at9qvf$ds4$1@forge.intermeta.de>
> If you define "OS" at the syscall layer you end up with what we
> started. Two threads printing 1 0 1 0 1 0 on your screen.
>
> Regards
> henning
Way back when I was in college and studying interrupts, etc., I wrote a
program to interrupt some little routine and reenable interrupts to
interrupt a routine, etc. I was enthralled and thought to myself, "I
bet I could write a space game ..."
Way back when Linus was studying interrupts and got 1 0 1 0 1 0 ..., he
thought, "I bet I could get a movement started to generate an entirely
new unix-like OS so popular it will eventually take over the world".
Dream big.
--
Billy
^ permalink raw reply
* Re: [PATCH] dm.c - device-mapper I/O path fixes
From: Kevin Corry @ 2002-12-12 12:30 UTC (permalink / raw)
To: Paul Mackerras
Cc: Denis Vlasenko, Joe Thornber, Kernel Mailing List, lvm-devel
In-Reply-To: <15863.43576.467511.255317@argo.ozlabs.ibm.com>
On Wednesday 11 December 2002 15:12, Paul Mackerras wrote:
> Kevin Corry writes:
> > Storing an int is *not* atomic unless it is declared as atomic_t and you
> > use the appropriate macros (see include/asm-*/atomic.h). Remember, we are
> > talking about a field in a data structure that can be accessed from
> > multiple threads on multiple CPUs.
>
> As a practical matter, I believe that storing an int to an int-aligned
> address _is_ actually atomic on any CPU that can run Linux. The
> PowerPC architecture spec requires that single-word (i.e. 32-bit)
> aligned stores are atomic, for instance, and I think that would be the
> case on any other sane architecture as well.
Given the constraints of having properly aligned data on an SMP machine with
the correct cache-coherency hardware, then yes, I will agree that such stores
should be atomic. However, it has been my understanding that these conditions
cannot be guaranteed on every architecture. Thus we're stuck with atomic_t's
so everyone can play nicely together.
--
Kevin Corry
corryk@us.ibm.com
http://evms.sourceforge.net/
^ permalink raw reply
* Re: grub and 2.5.50
From: Alex Tomas @ 2002-12-12 13:09 UTC (permalink / raw)
To: Stefan Reinauer; +Cc: Matt Young, Linux Kernel Mailing List
In-Reply-To: <20021211134322.GA23761@suse.de>
>>>>> Stefan Reinauer (SR) writes:
SR> * Matt Young <wz6b@arrl.net> [021210 01:40]:
>> These grub commands work with SUSE 2.4.19-4GB:
>>
>> kernel (hd0,0)/bzImage root=/dev/hda3 vga=791 initrd
>> (hd0,0)/initrd
>>
>> But with 2.5.50 the kernel panics after Freeing the initrd memory
>> with "Unable te mount root FS, please correct the root= cammand
>> line"
>> I have compiled with the required file systems
>> (EXT2,EXT3,REISERFS).
SR> Did you also compile in support for the root device itself
SR> (i.e. ide or scsi driver). These are loaded via the initrd
SR> normally on SuSE, which will not work, if you did not install
SR> newer modutils..
First of all, 2.5.10 has sysfs-related bug. try to replace root=/dev/hda3
by root=303
^ permalink raw reply
* Timeout in do_write_oneword()
From: Marius Groeger @ 2002-12-12 13:36 UTC (permalink / raw)
To: linux-mtd
Hello,
we ran into a problem with the current CVS version of
drivers/mtd/chips/cfi_cmdset_0002.c::do_write_oneword(), line 514. We
think the following is broken on most platform, where HZ is 100 and
results in a 10ms jiffy resolution:
timeo = jiffies + (HZ/1000); /* setting timeout to 1ms for now */
Wouldn't this be better:
/* setting timeout to 1ms for now, but wait a least one system tick */
timeo = jiffies + (HZ/1000) ? (HZ/1000) : 1;
Regards,
Marius
-----------------------------------------------------------------------------
Marius Groeger SYSGO Real-Time Solutions AG mgroeger@sysgo.de
Software Engineering Embedded and Real-Time Software www.sysgo.de
Voice: +49-6136-9948-0 Am Pfaffenstein 14 www.osek.de
FAX: +49-6136-9948-10 55270 Klein-Winternheim, Germany www.elinos.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.