* mkinitrd: binary operator expacted
From: plachninka @ 2002-12-17 8:52 UTC (permalink / raw)
To: linux-kernel
Hi
Can anyone tell me what means following message:
[root@tilda plachnina]# /sbin/mkinitrd initrd-2.4.18-18.7.xsmp.img
2.4.18-18.7.xsmp
/sbin/mkinitrd: [:
/lib/modules/2.4.18-18.7.xsmp/./kernel/drivers/scsi/aic7xxx/aic7xxx.o:
binary operator expected
I fight with aic7xxx module since 1 month...
regards
Mariusz Bozewicz
^ permalink raw reply
* SMIC and IPMI (was: [ACPI] Metolious hardware-sensors-using-ACPI specs)
From: Jirka Kosina @ 2002-12-17 8:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Grover, Andrew
In-Reply-To: <EDC461A30AC4D511ADE10002A5072CAD04C7A5AB@orsmsx119.jf.intel.com>
On Mon, 16 Dec 2002, Grover, Andrew wrote:
> The machines that care about manageability (servers) appear to be entirely
> disjoint from the ones that have thermal zones (and, servers use IPMI),
Talking about IPMI - is there anyone working on SMIC interface to IPMI
driver written by Corey Minyard? (http://home.attbi.com/~minyard). He
isn't working on it personally as he told me, because he doesn't have such
HW.
I've just downloaded specification from intel and can start working on it
after I finish my other projects, but I am asking firstly, to avoid
implementing it if someone is currently doing it.
--
JiKos.
^ permalink raw reply
* Re: Problems with CONFIG_PREEMPT
From: Colin.Helliwell @ 2002-12-17 8:27 UTC (permalink / raw)
To: Jun Sun; +Cc: linux-mips
NEW_TIME_C is set. URL to the patch is:
http://www.kernel.org/pub/linux/kernel/people/rml/preempt-kernel/v2.4/preempt-kernel-rml-2.4.19-2.patch
We ultimately want to add in real-time support, such as Ingo's O(1)
scheduler - if this is 'complete' for MIPS. I don't know if it would be
better just to go for this in one hit, or if we'd need the preemption
sorted out anyway first. Or should we just go to a 2.5.x kernel instead?
Colin
Jun Sun
<jsun@mvista.com> To: Colin.Helliwell@Zarlink.Com
cc: linux-mips@linux-mips.org, jsun@mvista.com
16-Dec-2002 08:45 Subject: Re: Problems with CONFIG_PREEMPT
PM
Several possibilities:
1) Not all MIPS boards can run pre-k. At minimum, you need to use
NEW_TIME_C, Or else you have to take a lot of stuff youself.
2) Not sure if all MIPS patches are in RML's patch. If you pass the URL
pointer, I can take a look.
3) Even with all above taken care of, there are still unsolved issues
(such as math emul not pre-k safe, some cache operations, etc).
However, these problems usually are much harder to show up. You won't
see them unless you delibrately want to. :-)
Jun
^ permalink raw reply
* [U-Boot-Users] booting linux from u-boot - help!
From: Wolfgang Denk @ 2002-12-17 8:25 UTC (permalink / raw)
To: u-boot
In-Reply-To: <sdff7591.075@au.thalesgroup.com>
In message <sdff7591.075@au.thalesgroup.com> you wrote:
> I used smc1 because i was unable to get ppcboot running with smc2. our
This is something you should investigate. U-Boot is working fine on
all MC and SCC ports. If it doesn't work for you this means there is
some problem on your board and/or with your configuration. Ignoring
such problems in the early phases whiletrying to go on and "make some
progress" might seem to be useful for some demonstration with upper
management, but will have to be paied for double and triple later,
when you run into the same problem again without knowing and
expecting it. -- Just my $ 0.02. [I must live with a very primitive
mind - I tend to solve problems one by one, step by step. But then,
this is working not too bad for me ;-) ]
> where r25 is the pattern I want to write into address 0x81000000. I've
As Murray already pointed out: under Linux you cannot simply write to
any physical address you like. Linux sets up a virtual address
mapping, and each part of your physical address space you want to
access must be explicitely mapped into this virtual memory.
> any other ideas would be muchly appreciated,
Well, standard recommendation applies again: get yourself a BDI2000.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
On our campus the UNIX system has proved to be not only an effective
software tool, but an agent of technical and social change within the
University. - John Lions (U. of Toronto (?))
^ permalink raw reply
* Re: [parisc-linux] Re: YA pb with PCI IDE (my merge 2.4.21-pre1)
From: jsoe0708 @ 2002-12-17 8:22 UTC (permalink / raw)
To: Matthew Wilcox, Alan Cox; +Cc: parisc-linux
In-Reply-To: <20021216172906.B9994@parcelfarce.linux.theplanet.co.uk>
Hi Willy,
>
>You mean the "IDE but no disks" patch:
>http://www.uwsg.iu.edu/hypermail/linux/kernel/0212.2/0105.html ?
I apply it (by hand) and it works:
"...
Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=3D=
xx
NS87415: IDE controller at PCI slot 00:0e.0
NS87415: chipset revision 3
NS87415: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x0900-0x0907, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0x0908-0x090f, BIOS settings: hdc:pio, hdd:pio
hda: LTN485S, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 103
hda: ATAPI 48X CD-ROM drive, 120kB Cache
Uniform CD-ROM driver Revision: 3.12
...
palx2000:~# uname -a
Linux palx2000 2.4.21-pre1-pa14 #2 Tue Dec 17 08:44:14 CET 2002 parisc un=
known
unknown GNU/Linux"
Thanks all,
Joel
*************************************************************************=
*******
Controlez mieux votre consommation Internet...surfez Tiscali Complete...h=
ttp://tiscali.complete.be
^ permalink raw reply
* Re: 2.5.52-mm1 kernel BUG at mm/page_walk.c:430!
From: Helge Hafting @ 2002-12-17 8:19 UTC (permalink / raw)
To: Andrew Morton; +Cc: lkml
In-Reply-To: <3DFD908D.14D7F6E7@digeo.com>
X suddenly died, and was restarted. I found this in dmesg:
kernel BUG at mm/page_walk.c:430!
invalid operand: 0000
CPU: 0
EIP: 0060:[<c013beeb>] Not tainted
EFLAGS: 00013246
EIP is at make_pages_present+0x77/0xbc
eax: d0efa344 ebx: 6b6b6b6b ecx: 000000a0 edx: c1604954
esi: 6b6b6b6b edi: 00009000 ebp: d0efa344 esp: de555ef8
ds: 0068 es: 0068 ss: 0068
Process XFree86 (pid: 246, threadinfo=de554000 task=dfc00d80)
Stack: 00000000 de9c35cc 00000001 d0efa344 6b6b6b6b d0efa344 de555f00
dfc00d80
c1604954 00009000 c013be64 00000000 c0136d78 6b6b6b6b 6b6b6b6b
d0efa344
de554000 000a0000 00009000 d0efa344 00000000 d0efa344 c1604954
d0efa344
Call Trace:
[<c013be64>] gup_mk_present+0x0/0x10
[<c0136d78>] move_vma+0x3d4/0x404
[<c01370c8>] do_mremap+0x320/0x34c
[<c0137142>] sys_mremap+0x4e/0x6f
[<c0108973>] syscall_call+0x7/0xb
Code: 0f 0b ae 01 af 48 2d c0 3b 70 08 76 08 0f 0b af 01 af 48 2d
This is a UP kernel with preempt, compiled for pentium 4.
Helge Hafting
^ permalink raw reply
* Re: FTP and connection tracking
From: Haitao Yu @ 2002-12-17 8:09 UTC (permalink / raw)
To: Hans Jorgensen, netfilter-devel
As I think, ftp nat's expected function is called twice when the first expected packet is in PREROUTING chain and POSTROUTING chain.
>Dear list
>
>I am currently developing an application which is using DNAT and
>masquerading. First an incoming packet is DNAT'ed to have as specific dest.
>ip. The it is masquerading when it is leaving the decided interface.
>
>This works fine, but when I use FTP, the following shows up in the kernel
>log:
>
><4>ip_conntrack_in: related packet for c3a22310
><4>nat_expected: We have a connection!
><4>nat_expected: PASV cmd. 192.168.1.254->192.168.4.1
><4>nat_expected: IP to 192.168.4.1
><4>Found best for tuple c3d69db8: 6 10.0.0.8:1026 -> 192.168.4.1:11697
><4>nat_expected: We have a connection!
><4>nat_expected: PASV cmd. 192.168.1.254->192.168.4.1
><4>nat_expected: IP to 192.168.1.254
><4>Found best for tuple c3d69cf0: 6 192.168.1.254:1026 -> 192.168.4.1:11697
><4>Altering reply tuple of c3a22310 to tuple c3d69cd0: 6 192.168.4.1:11697
>-> 192.168.1.254:1026
><4>Mangling c3ad4140: SRC to 192.168.1.254 1026
><4>Confirming conntrack c3a22310
>
>My question is:
>Why does: "We have a connection!" and the following lines show up two times?
>Is the connection data traversing the same chain twice?
>
>Does anybody know where I can find more information on how the code in
>connection tracking and NAT works?
>
>Thanks in advance.
>
>/Hans
>
>
>_________________________________________________________________
>STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
>http://join.msn.com/?page=features/junkmail
= = = = = = = = = = = = = = = = = = = =
Haitao Yu
yuht@th-dascom.com.cn
2002-12-17
^ permalink raw reply
* Fwd: Re: [U-Boot-Users] booting linux from u-boot - help!
From: My-Hong Vuong @ 2002-12-17 8:05 UTC (permalink / raw)
To: u-boot
An embedded message was scrubbed...
From: "My-Hong Vuong" <My-Hong.Vuong@au.thalesgroup.com>
Subject: Re: [U-Boot-Users] booting linux from u-boot - help!
Date: Tue, 17 Dec 2002 14:17:50 +1100
Size: 2851
Url: http://lists.denx.de/pipermail/u-boot/attachments/20021217/6c6e53c0/attachment.eml
^ permalink raw reply
* [U-Boot-Users] booting linux from u-boot - help!
From: My-Hong Vuong @ 2002-12-17 8:04 UTC (permalink / raw)
To: u-boot
I used smc1 because i was unable to get ppcboot running with smc2. our
smc1 is at 9600.
with the cache, i've disabled MSR_DR in head_8xx.S which then seems to
get to start_here fine. but inserting the same code just before
early_init doesn't seem to work...
the assembly I'm using is :
lis r25, 0xaaaa
ori r25, r25, 0xaaaa
lis r26, 0x8100
ori r26,r26,0x0000
stw r25, 0(r26)
where r25 is the pattern I want to write into address 0x81000000. I've
used r25 and r26 because I can't see them being used anywhere in the
code... I'm not sure how do do it otherwise (i.e. restoring the original
register values)
any other ideas would be muchly appreciated,
My Hong Vuong
>>> Murray Jensen <Murray.Jensen@csiro.au> 12/17/02 04:24pm >>>
On Tue, 17 Dec 2002 14:17:50 +1100, My-Hong Vuong
<My-Hong.Vuong@au.thalesgroup.com> writes:
>Thanks for the prompt response.
My pleasure.
>The board I'm working with does not utilise SDRAM, rather SRAM -
Samsung
>K1S321615M, which does not utilise burst access - our ORx has Burst
>Inhibit turned on - it does not support burst accesses. This
shouldn't
>pose a problem then, should it?
No you are correct, you simply won't do burst transfers on the bus
which
means it can't be the problem.
>We have CPU6 turned off as we're using an MPC860T Rev.D.4.
OK
>Switching
>the Copyback on and off seem to have no effect.
OK
>also, for the console, we have it set at SMC1, standard/generic
>serial...
SMC1 - therefore no modem control (this was going to be my next
guess).
By the way, don't try to set the baud rate too high - it won't work on
and SMC. A nice easy 9600 is good to use.
>i'm unclear as to what you mean by:
>you must have a virtual memory mapping set up once the mmu is turned
on
>- the head.S file sets one up for the IMMR and the first 8M of RAM
until
>the kernel takes over.
>
>Do you mean that BRx and ORx need to be set up again? (btw, i'm a
newbie
>at this stuff)
No, a virtual memory mapping in the MMU. Linux takes care of this
stuff, but
if you are going to be poking values into a hardware device, you need
to set
up a virtual to physical address mapping and use the virtual address
when the
MMU is turned on, and the physical address when it is turned off. The
mapping
also needs to be non-cached.
For example, something like:
volatile phys_addr_t phys_addr = (phys_addr_t)0xXXXXXXXX;
volatile void *virt_addr;
volatile led_struct *led_ptr;
virt_addr = ioremap(phys_addr, size);
/* if MMU is off */
led_ptr = (led_struct *)phys_addr;
led_ptr->...
/* if MMU is on */
led_ptr = (led_struct *)virt_addr;
led_ptr->...
Don't take this literally - its just quick notes to give you an idea.
Note the
BRx/ORx stuff sets the "physical" address of devices, while the MMU
mappings
set the "virtual" address (you don't need a mapping to access the IMMRs
- this
is done for you). Also, most places in Linux have the MMU on, except
for
certain routines in the startup, and the exception handlers (in
assembly).
Cheers!
Murray...
--
Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3
9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3
9662 7853
Internet: Murray.Jensen at csiro.au
Hymod project: http://www.msa.cmst.csiro.au/projects/Hymod/
To the extent permitted by law, CSIRO does not represent, warrant
and/or
guarantee that the integrity of this communication has been maintained
or
that the communication is free of errors, virus, interception or
interference.
The information contained in this e-mail may be confidential or
privileged.
Any unauthorised use or disclosure is prohibited. If you have received
this
e-mail in error, please delete it immediately and notify Murray Jensen
on
+61 3 9662 7763. Thank you.
^ permalink raw reply
* 2.5.52-mjb1 (scalability / NUMA patchset)
From: Martin J. Bligh @ 2002-12-17 8:10 UTC (permalink / raw)
To: linux-kernel; +Cc: gh
In-Reply-To: <32230000.1039502522@titus>
The patchset contains mainly scalability and NUMA stuff, and
anything else that stops things from irritating me. It's meant
to be pretty stable, not so much a testing ground for new stuff.
I'd be very interested in feedback from other people running
large SMP or NUMA boxes.
http://www.aracnet.com/~fletch/linux/2.5.52/patch-2.5.52-mjb1.bz2
Since 2.5.50-mjb2
+ thread_info_cleanup (4K stacks pt 1) Dave Hansen / Ben LaHaise
+ interrupt_stacks (4K stacks pt 2) Dave Hansen / Ben LaHaise
+ stack_usage_check (4K stacks pt 3) Dave Hansen / Ben LaHaise
+ 4k_stack (4K stacks pt 4) Dave Hansen
+ numameminfo Martin Bligh / Keith Mannthey
Returned from the dead:
+ numaq_makefile Martin Bligh
+ numaq_apic James Cleverdon / Martin Bligh
+ numaq_mpparse1 James Cleverdon / Martin Bligh
+ numaq_mpparse2 James Cleverdon / Martin Bligh
Merged:
- devclass_panic Bill Irwin
Pending:
Speed up page init on boot (Bill Irwin)
Notsc automatic enablement
Move more of NUMA-Q to subarch (James C / Martin / John)
Full Summit support (James C / John)
RCU routecache (?)
scheduler callers profiling (Anton)
PPC64 NUMA patches (Anton)
Scheduler tunables (rml)
kgdb Various People
The older version of kgdb, not the shiny new stuff in Andrew's tree.
Yes, I'm boring and slow.
noframeptr Martin Bligh
Disable -fomit_frame_pointer
i386_topo Matt Dobson
Some i386 topology cleanups to make it cache the data.
use_generic_topo Matt Dobson
Something to do with tolopology that I forget.
numasched1 Erich Focht
Numa scheduler general foundation work + pooling
numasched2 Michael Hohnbaum
Numa scheduler lightweight initial load balancing.
local_pgdat Bill Irwin
Move the pgdat structure into the remapped space with lmem_map
early_printk Dave Hansen et al.
Allow printk before console_init
confighz Dave Hansen
Make HZ a config option
config_page_offset Dave Hansen / Andrea
Make PAGE_OFFSET a config option
vmalloc_stats Dave Hansen
Expose useful vmalloc statistics
shpte Dave McCracken
Shared pagetables (as a config option)
subarch reorg John Stultz
Move the header files for subarch under include/asm-i386
numaq_makefile James Cleverdon / Martin Bligh
Numa-Q subarch splitup
numaq_apic James Cleverdon / Martin Bligh
Numa-Q subarch splitup
numaq_mpparse1 James Cleverdon / Martin Bligh
Numa-Q subarch splitup
numaq_mpparse2 James Cleverdon / Martin Bligh
Numa-Q subarch splitup
dcache_rcu Dipankar / Maneesh
Use RCU type locking for the dentry cache.
thread_info_cleanup (4K stacks pt 1) Dave Hansen / Ben LaHaise
Prep work to reduce kernel stacks to 4K
interrupt_stacks (4K stacks pt 2) Dave Hansen / Ben LaHaise
Create a per-cpu interrupt stack.
stack_usage_check (4K stacks pt 3) Dave Hansen / Ben LaHaise
Check for kernel stack overflows.
4k_stack (4K stacks pt 4) Dave Hansen
Config option to reduce kernel stacks to 4K
notsc Martin Bligh
Enable notsc option for NUMA-Q (new version for new config system)
numameminfo Martin Bligh / Keith Mannthey
Expose NUMA meminfo information under /proc/meminfo.numa
mjb1 Martin Bligh
Add a tag to the makefile
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Helge Hafting @ 2002-12-17 8:02 UTC (permalink / raw)
To: Mark Mielke, linux-kernel
In-Reply-To: <20021216175432.GA5094@mark.mielke.cc>
Mark Mielke wrote:
>
> On Mon, Dec 16, 2002 at 12:17:59PM +0100, Pavel Machek wrote:
> > > Sure it's dirty. It's also fast, with the only overhead being
> > > a few NOPs that could get skipped on syscall return anyway.
> > > Patching overhead is negligible, since it only happens when a
> > > page is brought in fresh from the disk.
> > Yes but "read only" code changing under you... Should better be
> > avoided.
>
> Programs that self verify their own CRC may get a little confused (are
> there any of these left?), but other than that, 'goto is better avoided'
> as well, but sometimes 'goto' is the best answer.
And then there's programs that store constants as parts of the code,
so that their constant-ness is enforced byt the mmu.
This can be taken further - the compiler can save space by looking
through the generated code and use an address in the code as the
constant if it happens to have the right value. With some
bad luck it chooses the syscall sequence that it really don't expect
to be modified.
Helge Hafting
^ permalink raw reply
* Re: [drm:drm_init] *ERROR* Cannot initialize the agpgart module.
From: Paul P Komkoff Jr @ 2002-12-17 8:06 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <200212162049.16039.tomlins@cam.org>
Replying to Ed Tomlinson:
> I am getting the above message in 2.5.51, 52, and 52+bk current.
> Pci info follows:
> What else would help to debug this? The drm error above is all I find in the logs...
If you mount devfs somewhere you also don't find misc/agpgart inside ?
:)))
And nothing about agp aperture in dmesg?
--
Paul P 'Stingray' Komkoff 'Greatest' Jr /// (icq)23200764 /// (http)stingr.net
When you're invisible, the only one really watching you is you (my keychain)
^ permalink raw reply
* Re: Linux 2.4.21-pre1
From: Ralf Hildebrandt @ 2002-12-17 8:02 UTC (permalink / raw)
To: lkml
In-Reply-To: <20021211090829.GD8741@charite.de>
* Ralf Hildebrandt <Ralf.Hildebrandt@charite.de>:
> And, alas, I do have problems with exactly that code. Background:
>
> I've been trying the -ac kernels for quite some time now, but on my
> new Toshiba Satellite Pro 6100 they all fail miserably.
>
> I made three screenshots which illuminate the problem:
> http://www.stahl.bau.tu-bs.de/~hildeb/kernel/
Alan's patch in the Message with "Subject: IDE but no disks" fixes the
problem.
--
Ralf Hildebrandt (Im Auftrag des Referat V a) Ralf.Hildebrandt@charite.de
Charite Campus Mitte Tel. +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
Real programmers never work 9 to 5. If any real programmers are around
at 9 am, it's because they were up all night.
^ permalink raw reply
* Re: MSN helper module
From: Patrick Schaaf @ 2002-12-17 7:54 UTC (permalink / raw)
To: Carlos Fernandez Sanz; +Cc: netfilter-devel
In-Reply-To: <006d01c2a55e$e7a08200$152ea8c0@maincomp>
On Tue, Dec 17, 2002 at 12:57:35AM +0100, Carlos Fernandez Sanz wrote:
>
> Is there a helper module for MSN? If not, is it being developed and can I
> join the effort?
>
> If nothing is being done I'll just write the module myself before not having
> full MSN support becomes a serious issue and starts going up...
Ahem - what would such a helper module have to do? As far as I know,
MSN is an Internet Service Provider, and there is no network protocol
called MSN. Did that change? Do they do the AOL, 10 years later?
I sure hope so, it would be their final death.
Sorry for off-topic; my first question, above, is what should be discussed.
best regards
Patrick
^ permalink raw reply
* Re: IDE but no disks
From: Ralf Hildebrandt @ 2002-12-17 7:59 UTC (permalink / raw)
To: Linux Kernel Mailing List
In-Reply-To: <1040055392.13910.52.camel@irongate.swansea.linux.org.uk>
* Alan Cox <alan@lxorguk.ukuu.org.uk>:
> People seeing IDE controllers detected but no disks can you try the
> following backport of Ivan's 2.5 PCI fix
This fixes my IDE problem with -ac2 as described in my posting with
Message-ID: <20021211090829.GD8741@charite.de>
--
Ralf Hildebrandt (Im Auftrag des Referat V a) Ralf.Hildebrandt@charite.de
Charite Campus Mitte Tel. +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
"Does your computer ever crash?"
"Oh definitely, believe me. We want to make a tool that we can use ourselves
and we know from our own use we can make it a lot better and a lot more
reliable." -- Bill Gates in a BBC interview
^ permalink raw reply
* Data-loss bug stings Linux
From: arun4linux @ 2002-12-17 7:38 UTC (permalink / raw)
To: linux-kernel
Hello,
I got an e-mail like this.
Just want to get clarified as I'm using RedHat 8.0 (kernel 2.4.18-14)
----------
Programmers have found a bug in newer versions of the Linux operating system that, under unusual circumstances, could cause systems to drop data
The data-loss bug afflicts the newest 2.4.20 version of the heart, or kernel, of Linux. The new kernel was released Nov. 28 in Linux companies' updates but is not yet a part of their packaged products.
Although the bug was reported while the 2.4.20 version was still in testing, it wasn't fixed until early Friday morning, two weeks after final release.
To counteract such tracking problems in the future, Linux programmers have begun using more formal bug-tracking tools. Bugs and security problems are big issues today because of the ever-wider use of computer networks and the increasing importance of corporate data. Microsoft, Sun Microsystems, Linux fans and others all are keenly aware of the publicity benefits of crash-proof code, and the perils of problems.
Data-loss problems are dire--companies devote much of their computing budgets to keeping their information from vanishing into the ether.
However, the risks of the recent Linux data-loss bug are reduced because it only appears in a particular circumstance: First, an administrator has to select an unusual mode for Linux's ext3 file system software, which controls how data is stored on hard drives; then the administrator must disconnect the file system where the data is saved. In that case, all data that should have been saved on the hard drive in the previous 30 seconds could be lost.
The data-loss problem is "not very severe," said programmer Andrew Morton in an e-mail interview. It was Morton who pointed out Sunday that the bug hadn't been fixed and who posted a patch Friday.
Morton added that the bug is contingent on using ext3 in "a specialized mode, which in practice is rather slow. It doesn't offer any realistic advantages over the default...mode, and nobody uses it much. This is why the bug lay dormant for three months."
Red Hat, the top Linux seller, said its customers are only affected by the bug if they downloaded Red Hat updates that incorporate version 2.4.18-17 or later of the Linux kernel. The company made those updates available for versions 7.1, 7.2, 7.3 and 8.0 of Red Hat Linux. Its Advanced Server product isn't affected.
The most recent updates from No. 2 Linux seller SuSE also are affected, the SuSE said. However, SuSE by default uses a different file system, ReiserFS, that isn't affected.
The data-loss problem was originally found by programmer Nick Piggin, who said it may have affected all 2.4.19 kernels in addition to version 2.4.20. Morton, however, believes Piggin's first bug report in July for preliminary versions of 2.4.19 is likely a different--but related--bug that's harder to trigger.
Buttoning up Tux patches
Though this bug slipped through the cracks for a time, Linux programmers are working to create a less freewheeling process for tracking and fixing problems in their code. The Linux community, a self-directed group of programmers who collectively develop the Unix clone, doesn't have a suit-and-tie dress code, but it is becoming more formal.
For example, in November the Open Source Development Lab--a collaboration of IBM, Intel, Hewlett-Packard and others working to improve Linux for high-end systems--began an effort to track bugs more carefully. It announced the Kernel Bug Tracker in a posting to the Linux kernel mailing list, and several programmers signed up to supervise various parts of the project.
Red Hat already has its own bug-tracking site; it and the new OSDL site both use the open-source Bugzilla bug-tracking software.
In addition, Linux programmers have begun to adopt the BitKeeper collaborative programming tool for managing their code. These more formal processes please companies such as IBM that have bet heavily on Linux.
In a related development, the open-source world has become more tightly tied to the existing bug-tracking industry, fitting into established security mechanisms such as Mitre's Common Vulnerabilities and Exposures database. Conversely, security organizations are learning how to accommodate open-source groups.
------
Warm Regards
Arun
Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy the best in Movies at http://www.videos.indiatimes.com
Now bid just 7 Days in Advance and get Huge Discounts on Indian Airlines Flights. So log on to http://indianairlines.indiatimes.com and Bid Now!
^ permalink raw reply
* [parisc-linux] Dropping ide controler in 'Native' mode?
From: jsoe0708 @ 2002-12-17 7:22 UTC (permalink / raw)
To: parisc-linux
In-Reply-To: <1040061866.13786.74.camel@irongate.swansea.linux.org.uk>
>
>On Mon, 2002-12-16 at 17:06, jsoe0708@tiscali.be wrote:
>> Hi Alan,
>>
>> Worried about ext3 pb, I try to merge parisc kernel 2.4.20-pa14 with
2.4.21-pre1.
>> This merge seems to works fine on a b180l+ (without pci devices).
>> But still boot twice (??) and crash on a b2k with an ide cdrom.
>
>I've sent the PCI fixup patch to linux-kernel. Depending upon how the
>PA-RISC system interfaces to the IDE controller you may also need
>platform specific fixups or to drop the chip into Native mode.
>
Can somebody tell me if it is possible (if yes how)?
Thanks in advance,
Joel
*************************************************************************=
*******
Controlez mieux votre consommation Internet...surfez Tiscali Complete...h=
ttp://tiscali.complete.be
^ permalink raw reply
* [Linux-ia64] Re: ia64 cache flushing?
From: Richard Henderson @ 2002-12-17 7:20 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805582@msgid-missing>
On Mon, Dec 16, 2002 at 07:50:53PM -0800, David Mosberger wrote:
> I assume you do early binding of the PLTs for kernel modules, right?
Yes.
> If so, patching the PLT code stub is trivial.
No it isn't. Find me the address of the stub.
r~
^ permalink raw reply
* Re: [parisc-linux] quad tulip now not functional in 2.4.20
From: jsoe0708 @ 2002-12-17 7:12 UTC (permalink / raw)
To: grundler, Ed Schaller; +Cc: parisc-linux
In-Reply-To: <20021216231132.GC854@dsl2.external.hp.com>
[-- Attachment #1: Type: text/plain, Size: 6008 bytes --]
>
>I suspect it's a tulip driver bug.
>I haven't had a chance to diff the 2.4.19 vs 2.4.20 tulip driver.
>One idea might be to "forward port" the 2.4.19 drivers/net/tulip code
>into 2.4.20.
>
Just to avoid you loose time here is a diff:
diff -NaurX dontdiff linux-2.4.19-pa24/drivers/net/tulip/ChangeLog linux-2.4.20-pa14/drivers/net/tulip/ChangeLog
--- linux-2.4.19-pa24/drivers/net/tulip/ChangeLog 2002-08-03 02:39:44.000000000
+0200
+++ linux-2.4.20-pa14/drivers/net/tulip/ChangeLog 2002-11-18 09:09:41.000000000
+0100
@@ -1,3 +1,14 @@
+2002-09-18 Ryan Bradetich <rbradetich@uswest.net>
+
+ tulip hppa support:
+ * eeprom.c (tulip_build_fake_mediatable): new function
+ (tulip_parse_eeprom): call it, when no media table
+ * interrupt.c (phy_interrupt): new function
+ (tulip_interrupt): call it, before checking for no-irq-work
+ * tulip.c: add HAS_PHY_IRQ chip feature flag.
+ add csr12_shadow to tulip_private struct, only for hppa currently.
+ * tulip_core (tulip_init_one): support hppa wonky eeproms
+
2002-05-11 Juan Quintela <quintela@mandrakesoft.com>
* 21142.c (t21142_lnk_change): Revert earlier patch
diff -NaurX dontdiff linux-2.4.19-pa24/drivers/net/tulip/eeprom.c linux-2.4.20-pa14/drivers/net/tulip/eeprom.c
--- linux-2.4.19-pa24/drivers/net/tulip/eeprom.c 2002-11-28 12:41:36.000000000
+0100
+++ linux-2.4.20-pa14/drivers/net/tulip/eeprom.c 2002-11-18 09:09:41.000000000
+0100
@@ -190,7 +190,7 @@
}
subsequent_board:
- if (ee_data[27] == 0) { /* No valid media table. */
+ if (ee_data[27] == 0 || ee_data[ee_data[27]] == 0) { /* No valid media
table. */
tulip_build_fake_mediatable(tp);
} else if (tp->chip_id == DC21041) {
unsigned char *p = (void *)ee_data + ee_data[27 + controller_index*3];
diff -NaurX dontdiff linux-2.4.19-pa24/drivers/net/tulip/tulip.h linux-2.4.20-pa14/drivers/net/tulip/tulip.h
--- linux-2.4.19-pa24/drivers/net/tulip/tulip.h 2002-11-28 12:41:36.000000000
+0100
+++ linux-2.4.20-pa14/drivers/net/tulip/tulip.h 2002-11-18 09:09:41.000000000
+0100
@@ -63,7 +63,7 @@
HAS_8023X = 0x0400,
COMET_MAC_ADDR = 0x0800,
HAS_PCI_MWI = 0x1000,
- HAS_PHY_IRQ = 0x2000,
+ HAS_PHY_IRQ = 0x2000,
};
@@ -85,6 +85,7 @@
COMPEX9881,
I21145,
DM910X,
+ CONEXANT,
};
diff -NaurX dontdiff linux-2.4.19-pa24/drivers/net/tulip/tulip_core.c linux-2.4.20-pa14/drivers/net/tulip/tulip_core.c
--- linux-2.4.19-pa24/drivers/net/tulip/tulip_core.c 2002-11-28 12:41:36.000000000
+0100
+++ linux-2.4.20-pa14/drivers/net/tulip/tulip_core.c 2002-11-18 09:09:41.000000000
+0100
@@ -15,8 +15,8 @@
*/
#define DRV_NAME "tulip"
-#define DRV_VERSION "0.9.15-pre11"
-#define DRV_RELDATE "May 11, 2002"
+#define DRV_VERSION "0.9.15-pre12"
+#define DRV_RELDATE "Aug 9, 2002"
#include <linux/config.h>
#include <linux/module.h>
@@ -191,6 +191,10 @@
{ "Davicom DM9102/DM9102A", 128, 0x0001ebef,
HAS_MII | HAS_MEDIA_TABLE | CSR12_IN_SROM | HAS_ACPI,
tulip_timer },
+
+ /* CONEXANT */
+ { "Conexant LANfinity", 256, 0x0001ebef,
+ HAS_MII, tulip_timer },
};
@@ -214,6 +218,7 @@
{ 0x13D1, 0xAB08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
{ 0x104A, 0x0981, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
{ 0x104A, 0x2774, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
+ { 0x1259, 0xa120, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
{ 0x11F6, 0x9881, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMPEX9881 },
{ 0x8086, 0x0039, PCI_ANY_ID, PCI_ANY_ID, 0, 0, I21145 },
{ 0x1282, 0x9100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
@@ -221,6 +226,10 @@
{ 0x1113, 0x1216, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
{ 0x1113, 0x1217, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MX98715 },
{ 0x1113, 0x9511, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
+ { 0x1186, 0x1561, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
+ { 0x1626, 0x8410, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
+ { 0x1737, 0xAB09, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
+ { 0x14f1, 0x1803, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CONEXANT },
{ } /* terminate list */
};
MODULE_DEVICE_TABLE(pci, tulip_pci_tbl);
@@ -453,7 +462,7 @@
tp->csr6 = 0x01a80200;
outl(0x0f370000 | inw(ioaddr + 0x80), ioaddr + 0x80);
outl(0x11000 | inw(ioaddr + 0xa0), ioaddr + 0xa0);
- } else if (tp->chip_id == COMET) {
+ } else if (tp->chip_id == COMET || tp->chip_id == CONEXANT) {
/* Enable automatic Tx underrun recovery. */
outl(inl(ioaddr + 0x88) | 1, ioaddr + 0x88);
dev->if_port = tp->mii_cnt ? 11 : 0;
@@ -1474,7 +1483,6 @@
tp->timer.function = tulip_tbl[tp->chip_id].media_timer;
dev->base_addr = ioaddr;
- dev->irq = irq;
#ifdef CONFIG_TULIP_MWI
if (!force_csr0 && (tp->flags & HAS_PCI_MWI))
@@ -1548,7 +1556,13 @@
for (i = 0; i < 8; i ++)
if (ee_data[i] != ee_data[16+i])
sa_offset = 20;
- if (ee_data[0] == 0xff && ee_data[1] == 0xff && ee_data[2] == 0) {
+ if (chip_idx == CONEXANT) {
+ /* Check that the tuple type and length is correct. */
+ if (ee_data[0x198] == 0x04 && ee_data[0x199] == 6)
+ sa_offset = 0x19A;
+ }
+ if (ee_data[0] == 0xff && ee_data[1] == 0xff &&
+ ee_data[2] == 0) {
sa_offset = 2; /* Grrr, damn Matrox boards. */
multiport_cnt = 4;
}
@@ -1641,6 +1655,7 @@
for (i = 0; i < 6; i++)
last_phys_addr[i] = dev->dev_addr[i];http://webmail.tiscali.be/mail/MessageReplyAll?sid=DBE10C1646FA3872D205B9CC28640282AD467BC4&userid=jsoe0708@tiscali.be&seq=C&auth=01RVNMIUMKQMZQKW&srcfolder=INBOX&uid=3182&style=frans&abcompose=0
:: options avancées
last_irq = irq;
+ dev->irq = irq;
/* The lower four bits are the media type. */
if (board_idx >= 0 && board_idx < MAX_UNITS) {
(I have well a second interface on my b2k but never use it. I will try and
try to revert this diff.)
hph,
Joel
********************************************************************************
Controlez mieux votre consommation Internet...surfez Tiscali Complete...http://tiscali.complete.be
[-- Attachment #2: Tulip_2.4.19-2.4.20.diff --]
[-- Type: application/octet-stream, Size: 5103 bytes --]
diff -NaurX dontdiff linux-2.4.19-pa24/drivers/net/tulip/ChangeLog linux-2.4.20-pa14/drivers/net/tulip/ChangeLog
--- linux-2.4.19-pa24/drivers/net/tulip/ChangeLog 2002-08-03 02:39:44.000000000 +0200
+++ linux-2.4.20-pa14/drivers/net/tulip/ChangeLog 2002-11-18 09:09:41.000000000 +0100
@@ -1,3 +1,14 @@
+2002-09-18 Ryan Bradetich <rbradetich@uswest.net>
+
+ tulip hppa support:
+ * eeprom.c (tulip_build_fake_mediatable): new function
+ (tulip_parse_eeprom): call it, when no media table
+ * interrupt.c (phy_interrupt): new function
+ (tulip_interrupt): call it, before checking for no-irq-work
+ * tulip.c: add HAS_PHY_IRQ chip feature flag.
+ add csr12_shadow to tulip_private struct, only for hppa currently.
+ * tulip_core (tulip_init_one): support hppa wonky eeproms
+
2002-05-11 Juan Quintela <quintela@mandrakesoft.com>
* 21142.c (t21142_lnk_change): Revert earlier patch
diff -NaurX dontdiff linux-2.4.19-pa24/drivers/net/tulip/eeprom.c linux-2.4.20-pa14/drivers/net/tulip/eeprom.c
--- linux-2.4.19-pa24/drivers/net/tulip/eeprom.c 2002-11-28 12:41:36.000000000 +0100
+++ linux-2.4.20-pa14/drivers/net/tulip/eeprom.c 2002-11-18 09:09:41.000000000 +0100
@@ -190,7 +190,7 @@
}
subsequent_board:
- if (ee_data[27] == 0) { /* No valid media table. */
+ if (ee_data[27] == 0 || ee_data[ee_data[27]] == 0) { /* No valid media table. */
tulip_build_fake_mediatable(tp);
} else if (tp->chip_id == DC21041) {
unsigned char *p = (void *)ee_data + ee_data[27 + controller_index*3];
diff -NaurX dontdiff linux-2.4.19-pa24/drivers/net/tulip/tulip.h linux-2.4.20-pa14/drivers/net/tulip/tulip.h
--- linux-2.4.19-pa24/drivers/net/tulip/tulip.h 2002-11-28 12:41:36.000000000 +0100
+++ linux-2.4.20-pa14/drivers/net/tulip/tulip.h 2002-11-18 09:09:41.000000000 +0100
@@ -63,7 +63,7 @@
HAS_8023X = 0x0400,
COMET_MAC_ADDR = 0x0800,
HAS_PCI_MWI = 0x1000,
- HAS_PHY_IRQ = 0x2000,
+ HAS_PHY_IRQ = 0x2000,
};
@@ -85,6 +85,7 @@
COMPEX9881,
I21145,
DM910X,
+ CONEXANT,
};
diff -NaurX dontdiff linux-2.4.19-pa24/drivers/net/tulip/tulip_core.c linux-2.4.20-pa14/drivers/net/tulip/tulip_core.c
--- linux-2.4.19-pa24/drivers/net/tulip/tulip_core.c 2002-11-28 12:41:36.000000000 +0100
+++ linux-2.4.20-pa14/drivers/net/tulip/tulip_core.c 2002-11-18 09:09:41.000000000 +0100
@@ -15,8 +15,8 @@
*/
#define DRV_NAME "tulip"
-#define DRV_VERSION "0.9.15-pre11"
-#define DRV_RELDATE "May 11, 2002"
+#define DRV_VERSION "0.9.15-pre12"
+#define DRV_RELDATE "Aug 9, 2002"
#include <linux/config.h>
#include <linux/module.h>
@@ -191,6 +191,10 @@
{ "Davicom DM9102/DM9102A", 128, 0x0001ebef,
HAS_MII | HAS_MEDIA_TABLE | CSR12_IN_SROM | HAS_ACPI,
tulip_timer },
+
+ /* CONEXANT */
+ { "Conexant LANfinity", 256, 0x0001ebef,
+ HAS_MII, tulip_timer },
};
@@ -214,6 +218,7 @@
{ 0x13D1, 0xAB08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
{ 0x104A, 0x0981, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
{ 0x104A, 0x2774, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
+ { 0x1259, 0xa120, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
{ 0x11F6, 0x9881, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMPEX9881 },
{ 0x8086, 0x0039, PCI_ANY_ID, PCI_ANY_ID, 0, 0, I21145 },
{ 0x1282, 0x9100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
@@ -221,6 +226,10 @@
{ 0x1113, 0x1216, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
{ 0x1113, 0x1217, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MX98715 },
{ 0x1113, 0x9511, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
+ { 0x1186, 0x1561, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
+ { 0x1626, 0x8410, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
+ { 0x1737, 0xAB09, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
+ { 0x14f1, 0x1803, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CONEXANT },
{ } /* terminate list */
};
MODULE_DEVICE_TABLE(pci, tulip_pci_tbl);
@@ -453,7 +462,7 @@
tp->csr6 = 0x01a80200;
outl(0x0f370000 | inw(ioaddr + 0x80), ioaddr + 0x80);
outl(0x11000 | inw(ioaddr + 0xa0), ioaddr + 0xa0);
- } else if (tp->chip_id == COMET) {
+ } else if (tp->chip_id == COMET || tp->chip_id == CONEXANT) {
/* Enable automatic Tx underrun recovery. */
outl(inl(ioaddr + 0x88) | 1, ioaddr + 0x88);
dev->if_port = tp->mii_cnt ? 11 : 0;
@@ -1474,7 +1483,6 @@
tp->timer.function = tulip_tbl[tp->chip_id].media_timer;
dev->base_addr = ioaddr;
- dev->irq = irq;
#ifdef CONFIG_TULIP_MWI
if (!force_csr0 && (tp->flags & HAS_PCI_MWI))
@@ -1548,7 +1556,13 @@
for (i = 0; i < 8; i ++)
if (ee_data[i] != ee_data[16+i])
sa_offset = 20;
- if (ee_data[0] == 0xff && ee_data[1] == 0xff && ee_data[2] == 0) {
+ if (chip_idx == CONEXANT) {
+ /* Check that the tuple type and length is correct. */
+ if (ee_data[0x198] == 0x04 && ee_data[0x199] == 6)
+ sa_offset = 0x19A;
+ }
+ if (ee_data[0] == 0xff && ee_data[1] == 0xff &&
+ ee_data[2] == 0) {
sa_offset = 2; /* Grrr, damn Matrox boards. */
multiport_cnt = 4;
}
@@ -1641,6 +1655,7 @@
for (i = 0; i < 6; i++)
last_phys_addr[i] = dev->dev_addr[i];
last_irq = irq;
+ dev->irq = irq;
/* The lower four bits are the media type. */
if (board_idx >= 0 && board_idx < MAX_UNITS) {
^ permalink raw reply
* RE: [BUG] module-init-tools 0.9.3, rmmod modules with '-'
From: Osamu Tomita @ 2002-12-17 6:55 UTC (permalink / raw)
To: 'Rusty Russell '; +Cc: 'lkml '
-----Original Message-----
From: Rusty Russell
To: Zwane Mwaikambo
Cc: vamsi@in.ibm.com; lkml
Sent: 2002/12/17 9:17
Subject: Re: [BUG] module-init-tools 0.9.3, rmmod modules with '-'
> Yes, the filenames are unchanged. But if you modprobe snd-mixer-oss,
> you'll see snd_mixer_oss in /proc/modules. But rmmod "snd-mixer-oss"
> works as expected. Basically, the kernel and tools see them as
> equivalent: anything else is a bug, please report.
I have another problem related this one.
"options snd-cs4232 port=0xf44 ..." in modprobe.conf is ignored.
This is created by modprobe.conf2modprobe.conf in module-init-
tools 0.9.3.
When I rewite it to "options snd_cs4232 port=0xf44 ..." by hand,
it works fine.
Regards,
Osamu
^ permalink raw reply
* Re: i845PE chipset and 20276 Promise Controller boot failure with 2.4.20-ac2
From: Denis Vlasenko @ 2002-12-17 11:35 UTC (permalink / raw)
To: edward.kuns, linux-kernel; +Cc: edward.kuns
In-Reply-To: <OF4D4BDDD2.8FD534AB-ON86256C91.007B9286-86256C91.007EE995@rockwellfirstpoint.com>
On 16 December 2002 21:09, edward.kuns@rockwellfirstpoint.com wrote:
> acted exactly the same. So then I added a bunch of printk's to see
> if I could localize where it was hanging and it died immediately
> after displaying info about the PIIX driver.
Way to go man! This will save tons of time for IDE folks if everyone
who has problems go that far in debugging.
If you'll play with printk a bit more, you will find it.
--
vda
^ permalink raw reply
* RE: big load
From: Joseph D. Wagner @ 2002-12-17 6:50 UTC (permalink / raw)
To: 'Milan Roubal', linux-kernel
In-Reply-To: <0a6501c2a4a6$1a23b7b0$551b71c3@krlis>
I remember an error like this from a few months ago. Are you encountering
large I/O access? Lots of swapping? Lots of buffer input? Lots of buffer
output? This would show up on vmstats.
Joseph Wagner
-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Milan Roubal
Sent: Sunday, December 15, 2002 7:55 PM
To: linux-kernel@vger.kernel.org
Subject: big load
Hi,
I have got server runnig 5 days and now its doing this:
2:48am up 5 days, 11:23, 2 users, load average: 19.97, 15.70, 10.63
61 processes: 60 sleeping, 1 running, 0 zombie, 0 stopped
CPU0 states: 0.0% user, 8.1% system, 0.0% nice, 91.4% idle
CPU1 states: 0.0% user, 0.1% system, 0.0% nice, 99.4% idle
I can't understand where I can got so big load
processor is idle all the time, but load is going higher and higher.
2:50am up 5 days, 11:24, 2 users, load average: 21.45, 17.45, 11.80
62 processes: 61 sleeping, 1 running, 0 zombie, 0 stopped
CPU0 states: 0.0% user, 0.0% system, 0.0% nice, 100.0% idle
CPU1 states: 0.0% user, 0.1% system, 0.0% nice, 99.4% idle
my process:
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
13782 root 13 0 892 892 696 R 0.2 0.0 0:00 top
1 root 20 0 84 84 52 S 0.0 0.0 0:11 init
2 root 20 0 0 0 0 SW 0.0 0.0 0:00 keventd
3 root 20 19 0 0 0 SWN 0.0 0.0 0:03 ksoftirqd_CPU0
4 root 20 19 0 0 0 SWN 0.0 0.0 0:00 ksoftirqd_CPU1
5 root 20 0 0 0 0 SW 0.0 0.0 17:22 kswapd
6 root 0 0 0 0 0 SW 0.0 0.0 1:45 bdflush
7 root 20 0 0 0 0 SW 0.0 0.0 33:48 kupdated
8 root 20 0 0 0 0 SW 0.0 0.0 0:00 kinoded
11 root 0 -20 0 0 0 SW< 0.0 0.0 0:00 mdrecoveryd
14 root 20 0 0 0 0 SW 0.0 0.0 0:03 kreiserfsd
51 root 20 -20 0 0 0 SW< 0.0 0.0 11:20 raid5d
245 root 20 0 0 0 0 DW 0.0 0.0 0:09 pagebuf_daemon
388 root 20 0 316 316 208 S 0.0 0.0 0:00 syslogd
391 root 20 0 440 440 216 S 0.0 0.0 0:00 klogd
427 root 20 0 0 0 0 SW 0.0 0.0 0:00 khubd
What could be wrong?
In log is only this message:
Dec 16 02:32:37 fileserver kernel: lease timed out
# /usr/local/samba/bin/smbd -V
Version 2.2.6
System is 2.4.18-3 from SuSE,
SuSE 8.1 distribution.
Filesystem XFS on 1TB RAID5 array
Thanx
Milan Roubal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* 2.5.52-mm1 DCU_MISS_OUTSTANDING + IFU_FETCH_MISS
From: William Lee Irwin III @ 2002-12-17 6:49 UTC (permalink / raw)
To: linux-kernel
Here are the oprofile stats for DCU_MISS_OUTSTANDING and IFU_IFETCH_MISS
during a repetitive kernel compile on 2.5.52-mm1.
Tested on a 16x NUMA-Q with 16GB of RAM. I don't really have a baseline
to compare against atm, but can wander about various kernels and compare.
Let me know if there are other perf. counters you're interested in
(or perhaps even workloads... might be pressed for io though)
Thanks,
Bill
DCU_MISS_OUTSTANDING:
c015d35c 286073 0.579215 path_lookup
c01131f0 299991 0.607394 mark_offset_tsc
c0150b50 408260 0.826608 get_empty_filp
c0135b38 496238 1.00474 __get_page_state
c01359a0 586828 1.18816 nr_free_pages
c013f030 589705 1.19398 zap_pte_range
c01406b8 627686 1.27088 do_wp_page
c01416f0 627890 1.27129 do_no_page
c0139028 645393 1.30673 kmem_cache_free
c013e234 674702 1.36608 pte_unshare
c01377d4 726418 1.47079 check_poison_obj
c0142900 922420 1.86763 vm_enough_memory
c0138e28 1052271 2.13054 kmem_cache_alloc
c013233c 1066434 2.15922 find_get_page
c01b2ee0 1098288 2.22371 __copy_user_intel
c01661fc 1102636 2.23252 d_lookup
c01b3088 1155982 2.34053 __copy_from_user
c0116ba8 1343484 2.72016 x86_profile_hook
c01fc75c 1377869 2.78978 sync_buffer
c0115620 1527197 3.09213 smp_apic_timer_interrupt
c01463f0 1660647 3.36233 page_add_rmap
c013d6c4 2082730 4.21692 __blk_queue_bounce
c011a9b0 3001602 6.07737 scheduler_tick
c01b3020 4047364 8.19473 __copy_to_user
c01465ec 5508580 11.1533 page_remove_rmap
c011a4f8 7613873 15.4159 load_balance
IFU_IFETCH_MISS:
c015d97c 7 0.876095 open_namei
c01b1d74 7 0.876095 radix_tree_lookup
c01b3240 7 0.876095 atomic_dec_and_lock
c0108f2c 8 1.00125 system_call
c0109abc 8 1.00125 page_fault
c0116ba8 8 1.00125 x86_profile_hook
c0132688 8 1.00125 do_generic_mapping_read
c0143d40 8 1.00125 do_brk
c01469b8 8 1.00125 increment_rss
c011ae98 9 1.12641 do_schedule
c0135468 9 1.12641 buffered_rmqueue
c01359a0 9 1.12641 nr_free_pages
c0139028 9 1.12641 kmem_cache_free
c0142900 9 1.12641 vm_enough_memory
c01355a4 10 1.25156 __alloc_pages
c011a9b0 12 1.50188 scheduler_tick
c013233c 13 1.62703 find_get_page
c0116b00 14 1.75219 pfn_to_nid
c0119c14 14 1.75219 kmap_atomic
c013e7e0 15 1.87735 pte_try_to_share
c01463f0 19 2.37797 page_add_rmap
c01412d0 20 2.50313 do_anonymous_page
c0141aa0 22 2.75344 handle_mm_fault
c01416f0 24 3.00375 do_no_page
c015c904 25 3.12891 link_path_walk
c0117350 27 3.37922 do_page_fault
^ permalink raw reply
* Re: Dual P3 550 Katmai Bug
From: Denis Vlasenko @ 2002-12-17 11:29 UTC (permalink / raw)
To: Xavier LaRue, linux-kernel
In-Reply-To: <20021216182724.30ba0aa6.paxl@videotron.ca>
On 16 December 2002 21:27, Xavier LaRue wrote:
> Hi all,
> As I asked later this day.. my L2 cache is'nt detected on my dual p3
> 550. But I have another fuzy problem,
That's not a big loss. Undetected cache works as good as detected ;)
> all application take more cpu power in smp ( like xmms who was taking
> .3% take around 3% under and SMP kernel ( I use ps axuf to say this )
SMP operation incur locking overhead.
> .. I think the bug came from the kernel(2.4.18) since I build the
> smp kernel before adding my second processor and it was using as much
> cpu .. and another fuzzy problem, Sometime ( read one time at each 15
> min ) the cpu0 OR cpu1 get more and more loaded till it get 100% of
> cpu load and then it reget back to 0%.
Can you look which app does this? I see similar thing on SMP kernel
running on single Duron. xmms does this. xmms bug?
> My question is .. do update my kernel to a 2.4.20 ( or another
> version ) should fix my problem, also could upgrading to another
> kernel should debug my cache problem ?? BTW, I'm not using an Debian
> stock kernel.. I build it yesterday from real scratch.. (make clean
> dep; make bzImage;... )
Try newer kernel, cache detection was discussed here recently.
Or search archives...
--
vda
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: dean gaudet @ 2002-12-17 6:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dave Jones, Ingo Molnar, linux-kernel, hpa
In-Reply-To: <Pine.LNX.4.44.0212162204300.1800-100000@home.transmeta.com>
On Mon, 16 Dec 2002, Linus Torvalds wrote:
> It's not as good as a pure user-mode solution using tsc could be, but
> we've seen the kinds of complexities that has with multi-CPU systems, and
> they are so painful that I suspect the sysenter approach is a lot more
> palatable even if it doesn't allow for the absolute best theoretical
> numbers.
don't many of the multi-CPU problems with tsc go away because you've got a
per-cpu physical page for the vsyscall?
i.e. per-cpu tsc epoch and scaling can be set on that page.
the only trouble i know of is what happens when an interrupt occurs and
the task is rescheduled on another cpu... in theory you could test %eip
against 0xfffffxxx and "rollback" (or complete) any incomplete
gettimeofday call prior to saving a task's state. but i bet that test is
undesirable on all interrupt paths.
-dean
^ 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.