* Re: Cset 1.1490.4.201 - dasd naming
From: Martin Schwidefsky @ 2004-01-27 8:52 UTC (permalink / raw)
To: Pete Zaitcev; +Cc: laroche, linux-kernel, zaitcev
Hi Pete,
> In a recent changeset in Linus' tree, there's your diff which blows up
> the dasd naming scheme, with the comment:
> - Change dasd names from "dasdx" to "dasd_<busid>_".
We plan to do this for tape and other ccw devices as well (where applicable).
> This breaks mkinitrd, nash, and mount by label (not to mention every
> zipl.conf out there, because root= aliases to /sys/block/%s).
> Would you please explain what exactly you were thinking when you
> submitted that patch?
The reason for this change is the requirement to have persistent device
names. The /dev/dasdxyz naming schema heavily depends on the order in
which the device are added. Not good for persistent names. This change
affects four things: 1) the internal name, 2) the name of the sysfs
directory, 3) the root= parameter and 4) the hotplug events for dasd
devices.
blue skies,
Martin
Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH
Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247
E-Mail: schwidefsky@de.ibm.com
^ permalink raw reply
* Re: [PATCH] 2.6.2-rc2 - MPT Fusion driver 3.00.02 update
From: Douglas Gilbert @ 2004-01-27 8:48 UTC (permalink / raw)
To: James Bottomley; +Cc: Moore, Eric Dean, SCSI Mailing List, hch
In-Reply-To: <1075136727.2290.48.camel@mulgrave>
James Bottomley wrote:
> On Mon, 2004-01-26 at 11:01, Moore, Eric Dean wrote:
>
>>I will work on that.
>
>
> Thanks.
>
>
>>I had avoided it due the comments in the code
>>from sralston and pdelaney about sg interface
>>gererating wrong direction in some cases.
>
>
> If you find a problem, I'll fix the generic code...
James,
The newer sg_io_hdr based code (as used by the SG_IO ioctl)
requires that the user explicitly define the data direction
if any data transfer is involved. There is however a
SG_DXFER_UNKNOWN which maps to SCSI_DATA_UNKNOWN which
maps to DMA_BIDIRECTIONAL **.
The older sg_header based code (and the SCSI_IOCTL_SEND_COMMAND
ioctl) deduced the direction from various data buffer lengths
provided by the user. If those length implied both read and write
then the data direction is set as "FROM_DEVICE" (i.e. read
dominates).
So the sg (or SG_IO/SCSI_IOCTL_SEND_COMMAND ioctl) user controls
the data direction and they are free to get it wrong:-)
** The Object Storage Device (OSD) commands use bidirectional
data transfers so perhaps we should think about catering for
that.
Doug Gilbert
^ permalink raw reply
* Re: [LARTC] NEW imq driver
From: Andy Furniss @ 2004-01-27 8:42 UTC (permalink / raw)
To: lartc
In-Reply-To: <002a01c3e466$bb7f8700$030aa8c0@t>
Roy wrote:
> Seems I was to fast to declare success,
> my version is not much more stable than the original one,everything depends
> on dropped packets.
> This is even not imq fault afterall, can be prowed in other way also:
>
> atempts to police outgoing trafic it will be ok until you dont touch localy
> generated packets
> if you try to drop them you will be sorry, because kernel will resend then
> together with new ones
> of cource policer will drop them too, but linux kernel keeps resending then
> thus increasing rate progresively.
>
> I noticed that with my trafic counter. internal trafic grew to enormous
> levels 10X more than it can be. In reality there was almost no output at
> all.
> so DONT USE POLICERS ON EGRESS. on low trafic it is harmless but on 100mb/s
> it probably can kill computer (not tested).
>
> Seems imq have similar problem even if driver itself have no leaks kernel
> consumes all resousces on resnending droped packets so that computer stops
> responding
>
>
> for now I dont have good idea how to fix it so I will try to avoid localy
> generated trafic
> so it will me possible to shape ingress and forward, egress will be left for
> real device.
> maybe later I will find how fix that
Which queue do you use to drop the packets?
Andy.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* [parisc-linux] Using PAT_IO calls for PCI config space reads and writes.
From: Naresh Kumar @ 2004-01-27 8:39 UTC (permalink / raw)
To: parisc-linux
Hi all,
When I was trying to bring up PA-Linux-2.4 on some of the newer boxes, I
discovered that reads/writes from the PCI config space were failing (
system crashes and hangs during the boot). Currently, reads and writes
to the config space happen through memory loads and stores to PCI config
addresses directly (lba_cfg_[read|write]##size in lba_pci.c ). Grant
Grundler advised me to use PDC_PAT_IO calls instead, for PAT based
systems, since they are more reliable and take care of border cases on
newer systems. I have made the changes and tested them on an L-Class
system. I am posting the diff of the files I have changed. The changes
have been made to three files:
1. arch/parisc/kernel/firmware.c - Rev 1.47
2. arch/parisc/kernel/lba_pci.c - Rev 1.54
3. include/asm-parisc/pdc.h - Rev 1.48
Kindly let me know your comments:
--------------------START------------------------------------------------------------------------------
--- lba_pci.c.1.54 Fri Jan 23 15:47:41 2004
+++ lba_pci.c.modified Fri Jan 23 15:53:15 2004
@@ -504,6 +504,13 @@ lba_rd_cfg(struct lba_device *d, u32 tok
return(data);
}
+#ifdef __LP64__
+#define PAT_CFG_READ(a,b,c) pdc_pat_io_pci_cfg_read(a,b,c)
+#define PAT_CFG_WRITE(a,b,c) pdc_pat_io_pci_cfg_write(a,b,c)
+#else
+#define PAT_CFG_READ(a,b,c)
+#define PAT_CFG_WRITE(a,b,c)
+#endif
#define LBA_CFG_RD(size, mask) \
static int lba_cfg_read##size (struct pci_dev *dev, int pos, u##size
*data) \
@@ -512,6 +519,21 @@ static int lba_cfg_read##size (struct pc
u32 local_bus = (dev->bus->parent == NULL) ? 0 :
dev->bus->secondary; \
u32 tok = LBA_CFG_TOK(local_bus,dev->devfn); \
\
+ if (is_pdc_pat()) { \
+ int ret; \
+ tok = LBA_CFG_TOK(dev->bus->number,dev->devfn); \
+ ret = PAT_CFG_READ((tok | pos ), \
+ sizeof(u##size), (u##size *)
data); \
+ if ( ret == 0 ) { \
+ DBG_CFG("%s(%s+%2x) -> 0x%x (c)\n",
__FUNCTION__, dev->slot_name, pos, *data
); \
+ return(*data == (u##size) -1); \
+ } else { \
+ DBG_CFG("LBA: CFG read failed: ret = %d,
d->hba.base_addr = 0x%lx\n", \
+ ret, d->hba.base_addr );
\
+ return (1); \
+ } \
+ } \
+ \
/* FIXME: B2K/C3600 workaround is always use old method... */ \
/* if (!LBA_TR4PLUS(d) && !LBA_SKIP_PROBE(d)) */ { \
/* original - Generate config cycle on broken elroy \
@@ -611,6 +633,11 @@ static int lba_cfg_write##size (struct p
} \
\
DBG_CFG("%s(%s+%2x) = 0x%x (c)\n", __FUNCTION__, dev->slot_name,
pos, data); \
+ if (is_pdc_pat()) { \
+ tok = LBA_CFG_TOK(dev->bus->number,dev->devfn); \
+ PAT_CFG_WRITE((tok | pos ), sizeof(u##size), (u##size
*)&data); \
+ return 0; \
+ } \
/* Basic Algorithm */ \
LBA_CFG_TR4_ADDR_SETUP(d, tok | pos); \
WRITE_REG##size(data, d->hba.base_addr + LBA_PCI_CFG_DATA + (pos
& mask)); \
-------------------------------------END---------------------------------------------------------------
------------------------------------START-------------------------------------------------------------
--- firmware.c.1.47 Fri Jan 23 16:57:51 2004
+++ firmware.c.modified Tue Jan 27 12:32:43 2004
@@ -1035,6 +1035,46 @@ int pdc_pat_pd_get_addr_map(unsigned lon
return retval;
}
+
+/**
+ * pdc_pat_io_pci_cfg_read - Read PCI configuration space.
+ * @pci_addr: PCI configuration space address for which the read
request is being made.
+ * @pci_size: Size of read in bytes. Valid values are 1, 2, and 4.
+ * @mem_addr: Pointer to return memory buffer.
+ *
+ */
+int pdc_pat_io_pci_cfg_read(unsigned long pci_addr, int pci_size, void
*mem_addr)
+{
+ int retval;
+ spin_lock_irq(&pdc_lock);
+ retval = mem_pdc_call(PDC_PAT_IO, PDC_PAT_IO_PCI_CONFIG_READ,
__pa(pdc_result),
+ pci_addr, pci_size);
+ memcpy((char *)mem_addr, (char *) ((char *)pdc_result +
(sizeof(unsigned long) - pci_size))
, pci_size);
+ spin_unlock_irq(&pdc_lock);
+
+ return retval;
+}
+
+/**
+ * pdc_pat_io_pci_cfg_write - Retrieve information about memory address
ranges.
+ * @pci_addr: PCI configuration space address for which the write
request is being made.
+ * @pci_size: Size of write in bytes. Valid values are 1, 2, and 4.
+ * @value: Pointer to 1, 2, or 4 byte value in low order end of
argument to be
+ * written to PCI Config space.
+ *
+ */
+int pdc_pat_io_pci_cfg_write(unsigned long pci_addr, int pci_size, void
*value)
+{
+ int retval;
+ unsigned long *val_ptr;
+ spin_lock_irq(&pdc_lock);
+ memcpy((char *)((char *)val_ptr + (sizeof(unsigned long) -
pci_size)), (char *)value, pci_si
ze);
+ retval = mem_pdc_call(PDC_PAT_IO, PDC_PAT_IO_PCI_CONFIG_WRITE,
pci_addr,
+ pci_size, *val_ptr);
+ spin_unlock_irq(&pdc_lock);
+
+ return retval;
+}
#endif /* __LP64__ */
-------------------------------------END---------------------------------------------------------------
------------------------------------START-------------------------------------------------------------
--- pdc.h.1.48 Fri Jan 23 16:57:52 2004
+++ pdc.h.modified Fri Jan 23 12:21:46 2004
@@ -972,6 +972,8 @@ int pdc_pat_get_irt_size(unsigned long *
int pdc_pat_get_irt(void *r_addr, unsigned long cell_num);
int pdc_pat_pd_get_addr_map(unsigned long *actual_len, void *mem_addr,
unsigned long count, unsigned long offset);
+int pdc_pat_io_pci_cfg_read(unsigned long pci_addr, int pci_size, void
*mem_addr);
+int pdc_pat_io_pci_cfg_write(unsigned long pci_addr, int pci_size, void
*value);
/******************************************************************** *
*PDC_PAT_CELL[Return Cell Module] memaddr[0] conf_base_addr
-------------------------------------END---------------------------------------------------------------
A couple of questions:
1. In the definition of 'pdc_pat_io_pci_cfg_read( )' and
'pdc_pat_io_pci_cfg_write( )' above, can I use 'cpu_to_le64( )' kind of
function instead of ordering the bytes manually in the 'memcpy( )'?
2. Can these changes be propagated to 2.6 also?
Thanks,
Naresh.
^ permalink raw reply
* Re: atkbd.c: Unknown key released
From: Vojtech Pavlik @ 2004-01-27 8:33 UTC (permalink / raw)
To: Voluspa; +Cc: linux-kernel
In-Reply-To: <200401270716.i0R7Gxw21819@d1o408.telia.com>
On Tue, Jan 27, 2004 at 08:16:59AM +0100, Voluspa wrote:
> > > I keep getting the following in my syslog whenever I startx:
>
> In fact, it is preemptively written even _before_ I start X :-)
> I'm using an ancient IBM PS2 swedish keyboard, and this 0x7a crap began
> showing somewhere at 2.6.1 (then without blaming X). Now it is - and the
> blame on X came with 2.6.2-rc2:
>
> Booting:
>
> Jan 26 16:29:10 loke kernel: atkbd.c: Unknown key released (translated
> set 2, code 0x7a on isa0060/serio0).
> Jan 26 16:29:10 loke kernel: atkbd.c: This is an XFree86 bug. It
> shouldn't access hardware directly.
> Jan 26 16:29:11 loke kernel: atkbd.c: Unknown key released (translated
> set 2, code 0x7a on isa0060/serio0).
> Jan 26 16:29:11 loke kernel: atkbd.c: This is an XFree86 bug. It
> shouldn't access hardware directly.
Do you use 'kbdrate' in your bootup scripts? That's another one touching
the keyboard controller directly, when there are ioctls for that.
I guess I should modify to make the message not point not directly to X,
but 'some application'.
> Starting X:
>
> Jan 26 16:33:50 loke kernel: atkbd.c: Unknown key released (translated
> set 2, code 0x7a on isa0060/serio0).
> Jan 26 16:33:50 loke kernel: atkbd.c: This is an XFree86 bug. It
> shouldn't access hardware directly.
> Jan 26 16:33:50 loke kernel: atkbd.c: Unknown key released (translated
> set 2, code 0x7a on isa0060/serio0).
> Jan 26 16:33:50 loke kernel: atkbd.c: This is an XFree86 bug. It
> shouldn't access hardware directly.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
^ permalink raw reply
* [LARTC] R2q Setting
From: Mihai Vlad @ 2004-01-27 8:28 UTC (permalink / raw)
To: lartc
[-- Attachment #1: Type: text/plain, Size: 321 bytes --]
Hello again,
I need to change the R2Q for my script, as setting the quantum manually for
each class is painful. Can you tell me exactly where to set R2Q = x?
I get syntax errors all the time. Should it be specified for each class? I
do not know where to place this setting...
Thanks in advance,
Vlad Mihai
[-- Attachment #2: Type: text/html, Size: 2708 bytes --]
^ permalink raw reply
* Re: IMQ Replacement
From: Andy Furniss @ 2004-01-27 8:24 UTC (permalink / raw)
Cc: Netfilter Mailing List
In-Reply-To: <4015AE11.1090607@dsl.pipex.com>
Andy Furniss wrote:
> Andy Furniss wrote:
>
>> There is also discussion on the LARTC list at the moment - someone
>> called roy has rewritten IMQ but still sees crashes. He thinks they
>> are related to locally generated traffic, so IMQ for ingress should be
>> OK.
>
>
> He just posted this, thought it may be of interest.
>
>
> Finaly I made imq driver stable it did not crashed for all 5 hours under
> high load, soo looks stable.
> (old one was crashing after 1-5 min for me)
>
> no need to patch anything just compile and insmod, should work with any
> kernel probably must be > than 2.4.20
>
> This is completely diferent code than old imq.
> you can find it on my server http://pupa.da.ru
> please tell how it works for you and how stable it is.
He has since posted that it crashes on locally generated traffic,
apparently the kernel resends what gets dropped and at 100mbs this uses
too many resources.
Andy.
^ permalink raw reply
* Re: [patch] 2.6.1-mm5 compile do not use shared extable code for ia64
From: Jes Sorensen @ 2004-01-27 8:11 UTC (permalink / raw)
To: davidm; +Cc: Paul Mackerras, Andrew Morton, linux-kernel, linux-ia64
In-Reply-To: <16405.41953.344071.456754@napali.hpl.hp.com>
>>>>> "David" == David Mosberger <davidm@napali.hpl.hp.com> writes:
David,
I am just nitpicking here, but wouldn't it be better to stick to the
convention of all upper case defines for the #ifdef check?
Maybe use something like?
#define ARCH_EXTABLE_COMPARE_ENTRIES ia64_extable_compare_entries
Cheers,
Jes
@@ -18,7 +18,25 @@
extern struct exception_table_entry __start___ex_table[];
extern struct exception_table_entry __stop___ex_table[];
-#ifndef ARCH_HAS_SORT_EXTABLE
+#ifndef extable_compare_entries
+
+/*
+ * Compare exception-table entries L and R and return <0 if L is smaller, 0 if L and R are
+ * equal and >0 if L is bigger.
+ */
^ permalink raw reply
* Re: IMQ Replacement
From: Remus @ 2004-01-27 8:13 UTC (permalink / raw)
To: Andre Correa; +Cc: netfilter
In-Reply-To: <40150537.4040501@pobox.com>
Hi Andre,
I'm already using this IMQ port and it seems to be very stable for ingres.
> Hi guys, Andy F. pointed out that Alexander Clouter and other guys
> ported IMQ to 2.6. The URL to their port is:
>
> http://www.digriz.org.uk/jdg-qos-script/#qos-2.6
>
> I had no time or resources to test it so far...
>
Regards
Remus
^ permalink raw reply
* Re: virus warning
From: Cedric Blancher @ 2004-01-27 8:12 UTC (permalink / raw)
To: Info; +Cc: Netfilter Mailing List (E-mail)
In-Reply-To: <001101c3e4a8$800f4970$88e118d2@dw1>
Le mar 27/01/2004 à 08:38, Info a écrit :
> ClamAV has detected it. Stopping more than 30 emails since this morning
Full Disclosure was affected and other mailing lists too... Well, maybe
it's time to get rid of sender's notifications...
--
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!
^ permalink raw reply
* Re: [patch] 2.6.1-mm5 compile do not use shared extable code for ia64
From: Jes Sorensen @ 2004-01-27 8:11 UTC (permalink / raw)
To: davidm; +Cc: Paul Mackerras, Andrew Morton, linux-kernel, linux-ia64
In-Reply-To: <16405.41953.344071.456754@napali.hpl.hp.com>
>>>>> "David" = David Mosberger <davidm@napali.hpl.hp.com> writes:
David,
I am just nitpicking here, but wouldn't it be better to stick to the
convention of all upper case defines for the #ifdef check?
Maybe use something like?
#define ARCH_EXTABLE_COMPARE_ENTRIES ia64_extable_compare_entries
Cheers,
Jes
@@ -18,7 +18,25 @@
extern struct exception_table_entry __start___ex_table[];
extern struct exception_table_entry __stop___ex_table[];
-#ifndef ARCH_HAS_SORT_EXTABLE
+#ifndef extable_compare_entries
+
+/*
+ * Compare exception-table entries L and R and return <0 if L is smaller, 0 if L and R are
+ * equal and >0 if L is bigger.
+ */
^ permalink raw reply
* Re: vga16fb mode change.
From: Geert Uytterhoeven @ 2004-01-27 8:06 UTC (permalink / raw)
To: Dave Jones; +Cc: Linux Frame Buffer Device Development
In-Reply-To: <20040123153354.GB19002@redhat.com>
On Fri, 23 Jan 2004, Dave Jones wrote:
> How come the 2.6 vga16fb driver doesn't change the display
> to the framebuffer when it's modprobe'd any more like the 2.4
> used to ?
>
> Is this an intentional change, or a regression?
I think this was intentional, to allow both vgacon and vga16fb to co-exist.
James can tell you more about that.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: C99 doesn't allow local scope variables?
From: wwp @ 2004-01-27 8:05 UTC (permalink / raw)
To: linux-c-programming
In-Reply-To: <200401262130.35636.tabris@tabris.net>
Hello tabris,
On Mon, 26 Jan 2004 21:30:30 -0500 tabris <tabris@tabris.net> wrote:
[snip]
> [tabris@tabriel tmp]$ gcc test.c -o test
> test.c: In function `main':
> test.c:6: error: `for' loop initial declaration used outside C99 mode
>
> What does that mean, and why am I not allowed to make a local scope variable
>
> for a for{;;} loop?
>
> works fine if i declare the variable outside the loop. But I swear I used to
>
> do this with gcc 2.95.
ANSI C89 requires int i; to be declared outside from the for(), only ANSI C99
and C++ allow this, IIRC.
Regards,
--
wwp
^ permalink raw reply
* Re: Root Drive Mirroring and LVM.
From: Atro Tossavainen @ 2004-01-27 8:01 UTC (permalink / raw)
To: linuxppc-dev, linux-raid; +Cc: tas
In-Reply-To: <868055F9-5045-11D8-8066-00039382032A@mindspring.com>
Sorry about the crossposting.
I wrote on the Yellow Dog Linux list when somebody asked about software
RAID on YDL about my experiences with it:
>> The one really big gotcha is that the Macintosh partitioning scheme
>> can't tell the Linux kernel that certain partitions are to be
>> considered "Linux RAID autodetect" (as in x86 using the DOS partition
>> table type 0xfd). This means that you can't boot a Mac Linux system
>> directly from RAID because the kernel won't be able to autostart the
>> RAID devices. You have to work around this by creating an initial RAM
>> disk that uses the raidstart command to start your metadevices, then
>> swaps the initrd out of the way and proceeds to start the real system.
to which Tim Seufert replied on the same list:
> Hmmm. That would seem to be a lack in the Linux RAID code, since the
> Macintosh partition table has a vastly more flexible partition type
> field than DOS: instead of a single byte it's a string. It would mean
> breaking from the convention of using the "Apple_SVR2_UNIX" type for
> Linux partitions, but that really is just a convention as far as I know.
Perhaps the PPC Linux developers and the Linux RAID developers should
get together on this and make some decisions so as to make it happen.
--
Atro Tossavainen (Mr.) / The Institute of Biotechnology at
Systems Analyst, Techno-Amish & / the University of Helsinki, Finland,
+358-9-19158939 UNIX Dinosaur / employs me, but my opinions are my own.
< URL : http : / / www . helsinki . fi / %7E atossava / > NO FILE ATTACHMENTS
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: pmdisk working on ppc (WAS: Help port swsusp to ppc)
From: Pavel Machek @ 2004-01-27 7:53 UTC (permalink / raw)
To: Nigel Cunningham
Cc: Benjamin Herrenschmidt, Hugang, Patrick Mochel,
Linux Kernel Mailing List, linuxppc-dev list
In-Reply-To: <1075162365.18808.4.camel@laptop-linux>
Hi!
> > Notice that swsusp needs half of physical memory free by design. That
> > means that we need _some_ freeing. Nigel's swsusp2 works around that
> > at cost of more complicated implementation.
>
> Yes, my method is a bit more complicated.
>
> Yours doesn't always need some freeing though - you only need to free
> memory until that 1/2 limitation is met. Last time I looked at it, it
> freed memory until it could free no more. Is that still true?
Yes. [It could be changed, but at that point I'd have to figure out
how much memory I really do need for write buffers, bio allocation,
etc.]
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
^ permalink raw reply
* Re: Is this project under control, or just 'suck it and see' ?
From: Bartos-Elekes Zsolt @ 2004-01-27 7:51 UTC (permalink / raw)
To: linux-msdos
In-Reply-To: <S266308AbUAVRML/20040122171211Z+35803@vger.kernel.org>
>>See the -f parameter for dosemu.bin
> But where/how do I "See the -f parameter for dosemu.bin" ?
> Is there applicable documentation with the binary-only package ?
Did you try 'man dosemu.bin'? ;-) I compiled 1.1.5 from source, but I suppose
that the man pages are included in the binary packages too.
--
Zsolt
^ permalink raw reply
* semop() issues in 2.4 kernel
From: Goran Koruga @ 2004-01-27 7:44 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 4512 bytes --]
Hello all.
We have recently stumbled across an interesting problem with 2.4 kernel.
It seems to occur with SMP kernel and machines only - we haven't seen it
occur in non-SMP environments. The problem was first observed with
2.4.7-10smp RedHat 7.2's kernel, but I have lately been able to reproduce
it with 2.4.23 as well. I haven't tested 2.4.24 because there are no
changes in this area, but this can easily be arranged if needed. All data
reported here is from the same machine running RedHat 7.2 (but the choice
of distribution and its version should have no effect here in my
opinion - we also know it occurs on RedHat 8).
The problem is related to semop() system call which seems to "hang" the
application in certain situations. I have first looked at what glibc
does with it, but it merely issues a system call, so the problem is not
there. I will describe how our application works. The application is
multi-threaded, and most important are threads 1 and 3. Thread 1 (I will
refer to it as main thread from now on) is also a signal handler, while
all other threads block signals. Thread 3 runs in a loop, waiting for
semaphore to be released to "process" the signal. After it is notified,
it calls a function which takes care of needed things (think of this
function as a signal handler which is called indirectly). When a signal
is caught, generic signal handler in main thread updates some internal
data and uses semop() to signal it to thread 3. So main thread calls
semop() with sem_op set to 1, while thread 3 calls semop() with sem_op
set to -1 (and consequently waits until semaphore is released).
This scenario leads to hanging main thread in certain cases, which
should not happen - even the man page for semop(2) says :
----------------------------------------------------------------------
If sem_op is a positive integer, the operation adds this
value to semval. Furthermore, if SEM_UNDO is asserted for
this operation, the system updates the process undo count
for this semaphore. The operation always goes through, so
no process sleeping can happen. The calling process must
have alter permissions on the semaphore set.
----------------------------------------------------------------------
I have added some debugging to the kernel functions responsible for
semop() operations, namely the following :
sys_semtimedop()
try_atomic_semop()
sys_semtimedop() was introduced somewhat recently, it was all happening
in sys_semop() previously (which is now just a wrapper for
sys_semtimedop()). I have used the most naive approach to track the
problem down by simply adding prinkt()-s to the code to find out where it
happens and possibly why. Note that I have no experience in kernel
development, so this is as far as I could go. The only thing that we have
concluded from looking at this data is that the hang always occurs if
semop() issued in main thread starts executing and is then interrupted
by semop() issued in thread 3. If this occurs, main thread never wakes up
after schedule() is called. I don't know if this conclusion makes sense,
but looking at many kernel logfiles we have always noticed this pattern
before the hang. There's one very interesting thing related to this - if
one uses strace on main thread, it wakes up and continues its work
normally. The same is true if gdb is used - process wakes up and
continues to work fine when gdb detaches from it. If someone has any
ideas, suggestions etc., please let me know.
I have attached a set of files to this mail, containing the following
(sorry for a rather large post because of this) :
1. stacktrace of the hanging process
2. kernel log with my extra printk()-s
3. kernel config
4. modified sem.c file with extra printk()-s, based on 2.4.23 kernel
5. /proc/cpuinfo
Some more things for easier understanding of attached files :
messages3: main thread is 367, thread 3 is 375
There are also logs of semop() operations in many other processes -
these are from the same application since semaphores are also used for
parent/child synchronisation when forking (using a totally unrelated
semaphore obviously - which is always retrieved using semget() before
the fork and then removed). I also have a few more kernel logfiles and
process' stacktraces, but they are not attached due to size constraints
when posting to the list.
Regards,
Goran
P.S. I am not subscribed to the list, please Cc: me on any
communication. I will also try to check the replies via gmane.
[-- Attachment #2: semop.tar.bz2 --]
[-- Type: application/octet-stream, Size: 15994 bytes --]
^ permalink raw reply
* Quick ad-hoc question?
From: Zoran Stojsavljevic @ 2004-01-27 7:41 UTC (permalink / raw)
To: linux-atm-general, linuxppc-embedded
In-Reply-To: <1075117282.1504.17.camel@zambia.cambridgebroadband.com>
Hi to everyone,
On our ADSL project we are using GlobeSpan Octane chipset. If anybody
uses Octane, did you ever try to set up some loopback inside Octane's DSP?
If yes, the question is how to do this (via GS APIs, but which)?
Looking for quick answers...
Best Regards,
Zoran Stojsavljevic
DKTS Pupin Telecom
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [Linux-fbdev-devel] Re: monochrome display fix.
From: Thiemo Seufer @ 2004-01-27 7:40 UTC (permalink / raw)
To: Linus Torvalds
Cc: James Simmons, Linux Fbdev development list,
Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.58.0401261446560.2313@home.osdl.org>
Linus Torvalds wrote:
>
>
> On Mon, 26 Jan 2004, James Simmons wrote:
> >
> > [CONSOLE] Don't let a monochrome display stomp all over the console color
> > values.
>
> Why is this ugly patch required? If something can't do color, why does it
> care about "color" in the first place?
Because it stores some text attributes in that place.
> We've never needed this patch
> before, it looks like something broke somewhere _else_ that causes this
> to be relevant.
It was always broken. This went unnoticed, apparently nobody tried to use
a kernel which supports mono and colour framebuffers at the same time.
Thiemo
^ permalink raw reply
* Re: [LARTC] I can't get TCNG to compile!!!
From: lartc @ 2004-01-27 7:39 UTC (permalink / raw)
To: lartc
In-Reply-To: <D4F6F05E3A22D41194EE0090276CE81901601B00@dlserver.nwt>
hi,
i have had the same problem ...
after running ./configure, edit the "config" file and change the line
with
KFULLVERSION=2.4.21-9
to just
KFULLVERSION=2.4.21
without the "-" or "smp" -- these symbols cause problems.
make and enjoy
cheers
charles
On Mon, 2004-01-26 at 23:39, jradke@canbytel.com wrote:
> Help! I can't get TCNG to compile!!! It did this on 2 different
> machines! Here are the errors:
>
> --------------------------------------------
> Kernel: 2.4.22
> [root@localhost tcng]# uname -a
> Linux localhost.localdomain 2.4.22-1.2149.nptl #1 Wed Jan 7 13:08:26
> EST
>
> #if KFULLVERSIONNUM >= 0x20416 /* gratuitous interface change in
> 2.4.22 :-(
> */
> ERROR:
> ake -f Makefile.unclean tcsim
> make[2]: Entering directory `/home/jradke/tcng/tcsim'
> cc -E -g -Wall -Wstrict-prototypes -Wmissing-prototypes
> -Wmissing-declarations -I../shared -Iklib -Iklib/include
> -Iulib/iproute2/include -I. -DVERSION=\"`cat ../VERSION`\"
> -DTOPDIR=\"/home/jradke/tcng\" -DTCC_CMD=\"/home/jradke/tcng/bin/tcc\"
> -DKFULLVERSION=\"2.4.22-1.2149.nptlcustom\" -DKFULLVERSIONNUM=`printf
> "0x%02x%02x%02x" 2 4 22`-1.2149.nptlcustom -DIVERSION=\"010824\" -I.
> -M *.c >.depend || \
>
> { rm -f .depend; exit 1; }
> trace.c:41:5: too many decimal points in number
> make[2]: *** [.depend] Error 1
> make[2]: Leaving directory `/home/jradke/tcng/tcsim'
> make[1]: *** [tcsim] Error 2
> make[1]: Leaving directory `/home/jradke/tcng/tcsim'
> make: *** [all] Error 1
>
>
> --------------------------------------------
> Kernel: 2.6.1
> ERROR:
>
> klib/include/linux/errno.h:4:31: asm-generic/errno.h: No such file or
> directory
> make[2]: *** [.depend] Error 1
> make[2]: Leaving directory `/home/jradke/tcng/tcsim'
> make[1]: *** [tcsim] Error 2
> make[1]: Leaving directory `/home/jradke/tcng/tcsim'
> make: *** [all] Error 1
>
>
>
>
>
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: 2.6.1 dual xeon
From: Sander @ 2004-01-27 7:38 UTC (permalink / raw)
To: Wakko Warner; +Cc: Robert Love, linux-kernel
In-Reply-To: <20040125083712.A9318@animx.eu.org>
Wakko Warner wrote (ao):
> > > I recently aquired a dual xeon system. HT is enabled which shows
> > > up as 4 cpus. I noticed that all interrupts are on CPU0. Can
> > > anyone tell me why this is?
> >
> > The APIC needs to be programmed to deliver interrupts to certain
> > processors.
> >
> > In 2.6, this is done in user-space via a program called irqbalance:
>
> Thanks, working great. (Debian by the way)
Ehm, IIRC the "all interrupts are on CPU0" is how it is supposed to work
with a 2.6 kernel? The interrupts should spread if you have _a_lot_ of
them. This gives better performance than spreading the interrupts. Did I
read this on the list, or am I completely wrong here?
--
Humilis IT Services and Solutions
http://www.humilis.net
^ permalink raw reply
* Re: virus warning
From: Info @ 2004-01-27 7:38 UTC (permalink / raw)
To: Netfilter Mailing List (E-mail)
In-Reply-To: <200401270145.12799.Alistair Tonner <>
ClamAV has detected it. Stopping more than 30 emails since this morning
----- Original Message -----
From: <Alistair Tonner>
To: "Netfilter Mailing List (E-mail)" <netfilter@lists.netfilter.org>
Sent: Tuesday, January 27, 2004 2:45 PM
Subject: Re: virus warning
>
> Obviously this is a really new one ... F-prot didn't catch it .. and mines
up to date ...
> However ... since kmail and linux don't much like 7 bit mime ... *grin*
>
> I'm handing this one up to the folks at F-Prot to see why they didn't
catch it...
>
>
> Alistair.
>
> On January 27, 2004 12:44 am, Fritz Mesedilla wrote:
> > friends,
> >
> > we got a virus in our list.
> > clamav warned me about it.
> > it's now spreading like fire even on other lists.
> >
> > thought you might like to be warned.
> >
> >
> > Cheers,
> >
> > fritz <www.mesedilla.com>
> > ---
> > + Basta Ikaw Lord
> >
> >
> >
> >
> > ----------------------------------------------------------------------
> > This email and any files transmitted with it are confidential and
> > intended solely for the use of the individual or entity to whom they
> > are addressed. If you have received this email in error please notify
> > the sender immediately by e-mail and delete this e-mail from your
> > system. Please note that any views or opinions presented in this
> > email are solely those of the author and do not necessarily represent
> > those of the company. Finally, the recipient should check this email
> > and any attachments for the presence of viruses. The company accepts
> > no liability for any damage caused by any virus transmitted by this
> > email.
> >
> > Overture Media, Inc.
> > Direct Line: (632) 635-4785
> > Trunkline: (632) 631-8971 Local 146
> > Fax: (632) 637-2206
> > Level 1 Summit Media Offices, Robinsons Galleria EDSA Cor. Ortigas Ave.,
> > Quezon City 1100
>
>
^ permalink raw reply
* Re: [Qemu-devel] Reactos not booting
From: Jens Arm @ 2004-01-27 7:33 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <1075128561.4720.5.camel@localhost>
> > I have to use the newest VGA- and normal BIOS that freeloader boots.
> > The BIOSes which are in the qemu-CVS do not boot with reactos.
>
> You mean those included in CVS, don't you? That's what I meant with
> current CVS. :)
I meant that if you want to boot ros you have to use the BIOSes from the
bochs CVS.
Jens
^ permalink raw reply
* RE: virus warning
From: Fritz Mesedilla @ 2004-01-27 7:30 UTC (permalink / raw)
To: Netfilter Mailing List (E-mail)
I forgot to send the details.
W32.Novarg.A@mm is a mass-mailing worm. The worm will arrive as an attachment with a file extension of .bat, .cmd, .exe, .pif, .scr, or .zip.
When the machine gets infected, the worm will set up a backdoor into the system by opening TCP ports 3127 thru 3198. This will potentially allow a hacker to connect to the machine and utilize it as a proxy to gain access to it's network resources. In addition, the backdoor has the ability to download and execute arbitrary files.
The worm will perform a DoS starting on February 1, 2004. On February 12, 2004 the worm has a trigger date to stop spreading.
http://securityresponse.symantec.com/avcenter/venc/data/w32.novarg.a@mm.html
Cheers,
fritz <www.mesedilla.com>
---
+ Basta Ikaw Lord
-----Original Message-----
From:
Sent: Tuesday, January 27, 2004 2:45 PM
To: Netfilter Mailing List (E-mail)
Subject: Re: virus warning
Obviously this is a really new one ... F-prot didn't catch it .. and mines up to date ...
However ... since kmail and linux don't much like 7 bit mime ... *grin*
I'm handing this one up to the folks at F-Prot to see why they didn't catch it...
Alistair.
On January 27, 2004 12:44 am, Fritz Mesedilla wrote:
> friends,
>
> we got a virus in our list.
> clamav warned me about it.
> it's now spreading like fire even on other lists.
>
> thought you might like to be warned.
>
>
> Cheers,
>
> fritz <www.mesedilla.com>
> ---
> + Basta Ikaw Lord
>
>
>
>
> ----------------------------------------------------------------------
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the sender immediately by e-mail and delete this e-mail from your
> system. Please note that any views or opinions presented in this
> email are solely those of the author and do not necessarily represent
> those of the company. Finally, the recipient should check this email
> and any attachments for the presence of viruses. The company accepts
> no liability for any damage caused by any virus transmitted by this
> email.
>
> Overture Media, Inc.
> Direct Line: (632) 635-4785
> Trunkline: (632) 631-8971 Local 146
> Fax: (632) 637-2206
> Level 1 Summit Media Offices, Robinsons Galleria EDSA Cor. Ortigas Ave.,
> Quezon City 1100
----------------------------------------------------------------------
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the sender immediately by e-mail and delete this e-mail from your
system. Please note that any views or opinions presented in this
email are solely those of the author and do not necessarily represent
those of the company. Finally, the recipient should check this email
and any attachments for the presence of viruses. The company accepts
no liability for any damage caused by any virus transmitted by this
email.
Overture Media, Inc.
Direct Line: (632) 635-4785
Trunkline: (632) 631-8971 Local 146
Fax: (632) 637-2206
Level 1 Summit Media Offices, Robinsons Galleria EDSA Cor. Ortigas Ave., Quezon City 1100
^ permalink raw reply
* Re: New NUMA scheduler and hotplug CPU
From: Martin J. Bligh @ 2004-01-27 7:19 UTC (permalink / raw)
To: Nick Piggin, Rusty Russell; +Cc: linux-kernel
In-Reply-To: <4015F9A8.6000801@cyberone.com.au>
> Well lets not worry too much about this for now. We could use
> static arrays and cpu_possible for now until we get a feel
> for what specific architectures want.
>
> To be honest I haven't seen the hotplug CPU code and I don't
> know about what architectures want to be doing with it, so
> this is my preferred direction just out of ignorance.
>
> An easy next step toward a dynamic scheme would be just to
> re-init the entire sched domain topology (the generic init uses
> the generic NUMA topology info which will have to be handled
> by these architectures anyway). Modulo a small locking problem.
>
> There aren't any fundamental design issues (with sched domains)
> that I can see preventing a more dynamic system so we can keep
> that in mind.
Yeah, I talked it over with Rusty some on IRC. I have more of a feeling
why he's trying to do it that way now. However, one other thought occurs
to me ... it'd be good to use the same infrastructure (sched domains)
for the workload management stuff as well (where the domains would be
defined from userspace). That'd also necessitate them being dynamic,
if you think that'd work out as a usage model.
The cpu_possible stuff might work for a first cut at hotplug I guess.
I still think it's ugly though ;-)
M.
^ 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.