* Re: 2.5.34?
From: Brad Parker @ 2002-09-16 16:12 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Brad Parker, Gustavo Sverzut Barbieri,
acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20020916163335.J10583-+pPCBgu9SkPzIGdyhVEDUDl5KyyQGfY2kSSpQ9I8OhVaa/9Udqfwiw@public.gmane.org>
Matthew Wilcox wrote:
>
>but 2.5.35 is out, so there's no need any more ;-)
ok, I'll try 2.5.35; Is there a changelog for acpi? (other than the
kernel changelog)
S1 is working for me with 2.4.19, but even if I throttle back the cpu it
eats a lot of power (and generates a lot of heat!)
I've been fooling around with S3. It looks like the big recent
additions (in 2.5) are to try and set the video mode in the wakeup
callback. I keep sending email to the list but I have not heard from
anyone talk about the status of this code.
I want to ask "does the s3 wakeup code work for anyone?"; I suspect it
does since I've read reports that S4 is working for some and it uses
the same code path (for wakeup anyway).
Any suggestions how to debug this? I would hack in some code to spit
messages out the uart but my hp laptop doesn't have one :-) I may try
a pcmcia 16550 card and a kgdb hack...
S3 puts it to sleep fine but when I wake up it seem to be hung - no lcd,
no keyboard... It's pretty hard to say how far it gets.
-brad
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
^ permalink raw reply
* Re: [PATCH] Summit patch for 2.5.34
From: Alan Cox @ 2002-09-16 16:15 UTC (permalink / raw)
To: Dave Jones
Cc: James Cleverdon, linux-kernel, James.Bottomley, torvalds, alan,
mingo
In-Reply-To: <20020916175545.A21875@suse.de>
> - Is this the same summit code as is in 2.4-ac ?
> (Ie, the one that boots on non summit systems too)
Yes
> - I believe the way forward here is to work with James Bottomley,
> who has a nice abstraction of the areas your patch touches for
> his Voyager sub-architecture.
For 2.5 maybe not for 2.4. Until Linus takes the subarch stuff the
if if if bits will just get uglier. As well as voyager there are at least
two more pending NUMA x86 platforms other than IBM summit
^ permalink raw reply
* Re: bonding vs 802.3ad/Cisco EtherChannel link agregation
From: Ben Greear @ 2002-09-16 16:09 UTC (permalink / raw)
To: Chris Friesen; +Cc: Cacophonix, linux-net, netdev
In-Reply-To: <3D85DB3D.DC65A80B@nortelnetworks.com>
Chris Friesen wrote:
> Cacophonix wrote:
>
>>--- Chris Friesen <cfriesen@nortelnetworks.com> wrote:
>
>
>>>This has always confused me. Why doesn't the bonding driver try and spread
>>>all the traffic over all the links?
>>
>>Because then you risk heavy packet reordering within an individual flow,
>>which can be detrimental in some cases.
>>--karthik
>
>
> I can see how it could make the receiving host work more on reassembly, but if throughput is key,
> wouldn't you still end up better if you can push twice as many packets through the pipe?
>
> Chris
Also, I notice lots of out-of-order packets on a single gigE link when running at high
speeds (SMP machine), so the kernel is still having to reorder quite a few packets.
Has anyone done any tests to see how much worse it is with dual-port bonding?
NAPI helps my problem, but does not make it go away entirely.
Ben
>
--
Ben Greear <greearb@candelatech.com> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
^ permalink raw reply
* Re: [RFC] Raceless module interface
From: Daniel Phillips @ 2002-09-16 16:13 UTC (permalink / raw)
To: Rusty Russell, Roman Zippel; +Cc: Jamie Lokier, Alexander Viro, linux-kernel
In-Reply-To: <20020916120022.22FFC2C12A@lists.samba.org>
On Monday 16 September 2002 04:17, Rusty Russell wrote:
> You weighed into a debate without background, with a longwinded
> "original" suggestion which wasn't, and then you accuse *me* of not
> reading?
Yup. If you had actually read it, I apologize, but you showed every
sign of having not read it.
> You divided modules into counting and non-counting. This is overly
> simplistic. In fact, *interfaces* are divided into counting and
> non-counting: a module may use both.
Read closely and you will see I covered that. Sure, my [rfc] may have
been less consise than the perfect piece of prose you would have
submitted in my place, but other than that, it seems to have held up
rather well under attack.
> A module which only uses
> counting interfaces is trivially safe from unload races. The
> interesting problem is module which control their own reference
> counts, because they use one or more non-counting interfaces.
>
> Your "solution" does not work:
>
> > unregister_callpoints(...);
> > magic_wait_for_quiescence();
> > return cleanup_foo(...);
>
> In fact, it would look like:
>
> > unregister_callpoints(...);
> > synchronize_kernel();
> > if (atomic_read(&usecount) != 0) {
> > reregister_callpoints(...);
> > return -EBUSY;
> > }
> > cleanup_foo();
Ah no, I don't like the second one, it will introduce erratic behaviour
in LSM. You will have a state where some security calls are implemented
and others not, then you will return to a state where all are. Eep.
Granted, LSM will always have a state when the calls are partially
unplugged, but the next state after that should be complete removal.
The admin is going to be awfully surprised if something else happens.
So what I had in mind here (and did mention it) is to take the counter
into account in magic_wait_for_quiescence(), on the understanding that
this counter only counts possibly-sleeping states of module threads.
Anyway, how do you propose to handle this:
task in module:
inc count
sleep
synchronize_kernel:
schedule()
wake up on cpu 1
wake up on cpu 0
dec count
if (atomic_read(&usecount) != 0) /* false */
free_module(module);
BOOM!
> Now, think what happens if reregister_callpoints() fails. So we need
> "unuse_xxx" here then.
>
> Now, *think* for one moment, from the point of view of the author of
> one of these modules. Now, how are you going to explain the subtle
> requirements of your "two stage in one" interfaces? Bear in mind that
> the init races weren't even understood by anyone on linux-kernel until
> two years ago, and you're dealing with a newbie kernel programmer.
OK, *finally* we get to the core of your argument. You accused me of
being long-winded, but you have just taken several days to admit that
there is no inherent difference in capability between your proposal and
mine. Though to be sure, some of your commentary was informative and
useful, still, you should have taken the position you are now about to
take right from the beginning.
> Now do you see my preference for taking the weight off the shoulders
> of module authors? It's just not sane to ask them to deal with these
> fairly esoteric races, and expect them to get it right.
I feel no need to take any weight off the shoulders of the LSM authors,
they are big boys and they better know what they're doing. IMHO, they'd
appreciate maximum control at the insertion/removal stage.
But proc modules, device drivers, even filesystems: I strongly agree
we need a dumbed-down interface. However, please forgive me for not
immediately accepting the proposition that yours is the final word in
dumbed-down module interfaces. I'm thinking that a set of easy-to-use
library calls will be just as good and will win on the grounds of using
the simpler interface.
> We could simply ban modules from using non-counting interfaces.
No we can't. As I mentioned in my [rfc], there are some modules that
simply cannot use this technique, and I hope we've already rejected
the strategy of disallowing removal of such modules. (The Chinese
have a saying that covers this: "cut off toes to avoid worm coming".)
> Or we
> could introduce two-stage registration interfaces and then simply ban
> their unloading.
No, the complaining would never end.
> Or we can make their unloading a kernel hacking
> option. Or we can provide all the infrastructure, and allow the
> module authors to set their own comfort level.
This is a logical falacy, let's call it "trifurcation". You have
presented three alternatives as if they were the only alternatives.
Two were bogus anyway; by either measure this last qualifies as pure
rhetoric.
In summary, you have retreated from the position that my interface
is somehow less capable than yours, and you have dug in to defend
the position that your interface is better for newbie programmers,
which appears to be your only argument at the moment.
If you turn out to be right, then good and my hat off to you. If
you are wrong, and I can present an interface that is just as easy
for newbie programmers, than I am right and you should thank me
for sticking to my guns and insisting that we go with the simplest
inteface that will do the job.
--
Daniel
^ permalink raw reply
* Re: DMA problems w/ PIIX3 IDE, 2.4.20-pre4-ac2
From: Jan-Hinnerk Reichert @ 2002-09-16 16:13 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <1032187595.1285.13.camel@irongate.swansea.linux.org.uk>
Am Montag, 16. September 2002 16:46 schrieb Alan Cox:
> On Mon, 2002-09-16 at 15:26, Florian Hinzmann wrote:
> > On 16-Sep-2002 Alan Cox wrote:
> > > On Mon, 2002-09-16 at 12:17, Florian Hinzmann wrote:
> > >> kernel: hdb: read_intr: status=0x59 { DriveReady SeekComplete
> > >> DataRequest Error } kernel: hdb: read_intr: error=0x10 {
> > >> SectorIdNotFound }, LBAsect=97567071, high=5, lo kernel: hdb:
> > >> read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
> > >
> > > Which is the drive reporting a physical media error
> >
> > Which seems to exist only while using the named combinations of DMA
> > access and kernel versions. While using i.e. 2.4.19 without DMA I can
> > access the same data, dd the whole disk to /dev/null or run badblock
> > checks without finding any physical media errors.
> >
> > 2.4.19 should complain, too, if there is a physical error indeed, right?
>
> The "sectoridnotfound" return is from the drive. That makes it very hard
> to believe it isnt a physical error
Is the LBA sector number in the error coming from the drive?
Is the drive addressed with LBA or CHS?
Is it possible that this error occurs if the LBA (or CHS) is out of bound?
(e.g. 40GB drive shouldn't have sector 97567071)
^ permalink raw reply
* Re: Re: [alsa-cvslog] CVS: alsa-kernel/isa cmi8330.c,1.10,1.11
From: Takashi Iwai @ 2002-09-16 16:06 UTC (permalink / raw)
To: Thierry Vignaud; +Cc: Jaroslav Kysela, alsa-devel
In-Reply-To: <m265x59b65.fsf@vador.mandrakesoft.com>
At Mon, 16 Sep 2002 18:00:50 +0200,
Thierry Vignaud wrote:
>
> Takashi Iwai <tiwai@suse.de> writes:
>
> > > > cmi8330 works even without isapnp. hence CONFIG_ISAPNP should
> > > > not be added in config.in.
> > >
> > > for all models ?
> >
> > not sure...
> >
> > > i had once a cmi8330 (well something like four years ago) and at
> > > that time it would only works after playing with isapnptools.
> >
> > then CONFIG_ISAPNP should not be in the dependency list. the driver
> > wouldn't be compiled once if CONFIG_ISAPNP=n, even though you could
> > use the card with help of isapnptools.
>
> but alsa donation of isapnp to the core kernel made isapnptools
> obsoloted since.
yes but users can still choose not to build isapnp support into the
kernel. and with your patch (btw you forgot $ before CONFIG_ISAPNP),
the cmi8330 module will not be _built_ in such a case. that's the
problem.
Takashi
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
^ permalink raw reply
* unexpected IO-APIC reduced message
From: MIKE FOGARTY @ 2002-09-16 16:06 UTC (permalink / raw)
To: linux-smp
[-- Attachment #1: Type: text/plain, Size: 102 bytes --]
as requested i am sending reduced message
thanks
mike
[-- Attachment #2: apicmessage --]
[-- Type: text/plain, Size: 30576 bytes --]
Sep 11 18:46:07 dwgserver kernel: loop: loaded (max 8 devices)
Sep 11 19:00:21 dwgserver kernel: Kernel logging (proc) stopped.
Sep 11 19:00:21 dwgserver kernel: Kernel log daemon terminating.
S
Sep 11 19:03:35 dwgserver kernel: klogd 1.4.1, log source = /proc/kmsg started.
Sep 11 19:03:35 dwgserver kernel: Linux version 2.4.18-3smp (bhcompile@daffy.perf.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)) #1 SMP Thu Apr 18 07:27:31 EDT 2002
Sep 11 19:03:35 dwgserver kernel: BIOS-provided physical RAM map:
Sep 11 19:03:35 dwgserver kernel: BIOS-e820: 0000000000000000 - 000000000009e800 (usable)
Sep 11 19:03:35 dwgserver kernel: BIOS-e820: 000000000009e800 - 00000000000a0000 (reserved)
Sep 11 19:03:35 dwgserver kernel: BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
Sep 11 19:03:35 dwgserver kernel: BIOS-e820: 0000000000100000 - 000000003fef0000 (usable)
Sep 11 19:03:35 dwgserver kernel: BIOS-e820: 000000003fef0000 - 000000003feff000 (ACPI data)
Sep 11 19:03:35 dwgserver kernel: BIOS-e820: 000000003feff000 - 000000003ff00000 (ACPI NVS)
Sep 11 19:03:35 dwgserver kernel: BIOS-e820: 000000003ff00000 - 000000003ff80000 (usable)
Sep 11 19:03:35 dwgserver kernel: BIOS-e820: 000000003ff80000 - 0000000040000000 (reserved)
Sep 11 19:03:35 dwgserver kernel: BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
Sep 11 19:03:35 dwgserver kernel: BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
Sep 11 19:03:35 dwgserver kernel: BIOS-e820: 00000000ff800000 - 00000000ffc00000 (reserved)
Sep 11 19:03:35 dwgserver kernel: BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
Sep 11 19:03:35 dwgserver kernel: 127MB HIGHMEM available.
Sep 11 19:03:35 dwgserver kernel: found SMP MP-table at 000f66c0
Sep 11 19:03:35 dwgserver kernel: hm, page 000f6000 reserved twice.
Sep 11 19:03:35 dwgserver kernel: hm, page 000f7000 reserved twice.
Sep 11 19:03:35 dwgserver kernel: hm, page 0009e000 reserved twice.
Sep 11 19:03:35 dwgserver kernel: hm, page 0009f000 reserved twice.
Sep 11 19:03:35 dwgserver kernel: On node 0 totalpages: 262016
Sep 11 19:03:35 dwgserver kernel: zone(0): 4096 pages.
Sep 11 19:03:35 dwgserver kernel: zone(1): 225280 pages.
Sep 11 19:03:35 dwgserver kernel: zone(2): 32640 pages.
Sep 11 19:03:35 dwgserver kernel: ACPI: Searched entire block, no RSDP was found.
Sep 11 19:03:35 dwgserver kernel: ACPI: RSDP located at physical address c00f6700
Sep 11 19:03:35 dwgserver kernel: RSD PTR v0 [PTLTD ]
Sep 11 19:03:35 dwgserver kernel: __va_range(0x3fefbb93, 0x68): idx=8 mapped at ffff6000
Sep 11 19:03:35 dwgserver kernel: ACPI table found: RSDT v1 [PTLTD RSDT 1540.0]
Sep 11 19:03:35 dwgserver kernel: __va_range(0x3fefee78, 0x24): idx=8 mapped at ffff6000
Sep 11 19:03:35 dwgserver kernel: __va_range(0x3fefee78, 0x74): idx=8 mapped at ffff6000
Sep 11 19:03:35 dwgserver kernel: ACPI table found: FACP v1 [Intel SE7500CW 1540.0]
Sep 11 19:03:36 dwgserver kernel: __va_range(0x3fefeeec, 0x24): idx=8 mapped at ffff6000
Sep 11 19:03:36 dwgserver kernel: __va_range(0x3fefeeec, 0x50): idx=8 mapped at ffff6000
Sep 11 19:03:36 dwgserver kernel: ACPI table found: SPCR v1 [PTLTD $UCRTBL$ 1540.0]
Sep 11 19:03:36 dwgserver kernel: __va_range(0x3fefef3c, 0x24): idx=8 mapped at ffff6000
Sep 11 19:03:36 dwgserver kernel: __va_range(0x3fefef3c, 0x9c): idx=8 mapped at ffff6000
Sep 11 19:03:36 dwgserver kernel: ACPI table found: APIC v1 [PTLTD APIC 1540.0]
Sep 11 19:03:36 dwgserver kernel: __va_range(0x3fefef3c, 0x9c): idx=8 mapped at ffff6000
Sep 11 19:03:36 dwgserver kernel: LAPIC (acpi_id[0x0000] id[0x0] enabled[1])
Sep 11 19:03:36 dwgserver kernel: CPU 0 (0x0000) enabledProcessor #0 Unknown CPU [15:2] APIC version 16
Sep 11 19:03:36 dwgserver kernel:
Sep 11 19:03:36 dwgserver kernel: LAPIC (acpi_id[0x0001] id[0x6] enabled[1])
Sep 11 19:03:37 dwgserver kernel: CPU 1 (0x0600) enabledProcessor #6 Unknown CPU [15:2] APIC version 16
Sep 11 19:03:37 dwgserver kernel:
Sep 11 19:03:37 dwgserver kernel: LAPIC (acpi_id[0x0002] id[0x1] enabled[1])
Sep 11 19:03:37 dwgserver kernel: CPU 2 (0x0100) enabledProcessor #1 Unknown CPU [15:2] APIC version 16
Sep 11 19:03:37 dwgserver kernel:
Sep 11 19:03:37 dwgserver kernel: LAPIC (acpi_id[0x0003] id[0x7] enabled[1])
Sep 11 19:03:00 dwgserver sysctl: kernel.sysrq = 0
Sep 11 19:03:37 dwgserver kernel: CPU 3 (0x0700) enabledProcessor #7 Unknown CPU [15:2] APIC version 16
Sep 11 19:03:00 dwgserver sysctl: kernel.core_uses_pid = 1
Sep 11 19:03:37 dwgserver kernel:
Sep 11 19:03:00 dwgserver rc.sysinit: Configuring kernel parameters: succeeded
Sep 11 19:03:37 dwgserver kernel: IOAPIC (id[0x2] address[0xfec00000] global_irq_base[0x0])
Sep 11 19:03:00 dwgserver date: Wed Sep 11 19:02:52 EDT 2002
Sep 11 19:03:37 dwgserver kernel: IOAPIC (id[0x3] address[0xfec80000] global_irq_base[0x18])
Sep 11 19:03:37 dwgserver kernel: IOAPIC (id[0x4] address[0xfec80400] global_irq_base[0x30])
Sep 11 19:03:37 dwgserver kernel: INT_SRC_OVR (bus[0] irq[0x0] global_irq[0x2] polarity[0x1] trigger[0x1])
Sep 11 19:03:37 dwgserver kernel: INT_SRC_OVR (bus[0] irq[0x9] global_irq[0x9] polarity[0x1] trigger[0x3])
Sep 11 19:03:37 dwgserver kernel: LAPIC_NMI (acpi_id[0x0000] polarity[0x1] trigger[0x1] lint[0x1])
Sep 11 19:03:37 dwgserver kernel: LAPIC_NMI (acpi_id[0x0001] polarity[0x1] trigger[0x1] lint[0x1])
Sep 11 19:03:37 dwgserver kernel: LAPIC_NMI (acpi_id[0x0002] polarity[0x1] trigger[0x1] lint[0x1])
Sep 11 19:03:00 dwgserver rc.sysinit: Initializing USB controller (usb-uhci): succeeded
Sep 11 19:03:37 dwgserver kernel: LAPIC_NMI (acpi_id[0x0003] polarity[0x1] trigger[0x1] lint[0x1])
Sep 11 19:03:37 dwgserver kernel: 4 CPUs total
Sep 11 19:03:38 dwgserver kernel: Local APIC address fee00000
Sep 11 19:03:38 dwgserver kernel: __va_range(0x3fefefd8, 0x24): idx=8 mapped at ffff6000
S
Sep 11 19:03:38 dwgserver kernel: __va_range(0x3fefefd8, 0x28): idx=8 mapped at ffff6000
Sep 11 19:03:38 dwgserver kernel: ACPI table found: BOOT v1 [PTLTD $SBFTBL$ 1540.0]
Sep 11 19:03:38 dwgserver kernel: Enabling the CPU's according to the ACPI table
Sep 11 19:03:38 dwgserver kernel: Intel MultiProcessor Specification v1.4
Sep 11 19:03:38 dwgserver kernel: Virtual Wire compatibility mode.
Sep 11 19:03:39 dwgserver kernel: OEM ID: Product ID: SE7500CW2 APIC at: 0xFEE00000
Sep 11 19:03:39 dwgserver kernel: I/O APIC #2 Version 32 at 0xFEC00000.
Sep 11 19:03:39 dwgserver kernel: I/O APIC #3 Version 32 at 0xFEC80000.
Sep 11 19:03:39 dwgserver kernel: I/O APIC #4 Version 32 at 0xFEC80400.
Sep 11 19:03:39 dwgserver kernel: Processors: 4
d
Sep 11 19:03:39 dwgserver kernel: Kernel command line: auto BOOT_IMAGE=linux ro root=303 BOOT_FILE=/boot/vmlinuz-2.4.18-3smp hdc=ide-scsi
Sep 11 19:03:39 dwgserver kernel: ide_setup: hdc=ide-scsi
Sep 11 19:03:39 dwgserver kernel: Initializing CPU#0
Sep 11 19:03:31 dwgserver sysctl: kernel.sysrq = 0
Sep 11 19:03:39 dwgserver kernel: Detected 2192.948 MHz processor.
Sep 11 19:03:31 dwgserver sysctl: kernel.core_uses_pid = 1
Sep 11 19:03:39 dwgserver kernel: Console: colour VGA+ 80x25
Sep 11 19:03:40 dwgserver kernel: Calibrating delay loop... 4377.80 BogoMIPS
S
Sep 11 19:03:40 dwgserver kernel: Memory: 1030064k/1048064k available (1232k kernel code, 17544k reserved, 842k data, 304k init, 130496k highmem)
S
Sep 11 19:03:40 dwgserver kernel: Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
S
Sep 11 19:03:40 dwgserver kernel: Inode cache hash table entries: 65536 (order: 7, 524288 bytes)
Sep 11 19:03:40 dwgserver kernel: Mount-cache hash table entries: 16384 (order: 5, 131072 bytes)
Sep 11 19:03:40 dwgserver kernel: Buffer cache hash table entries: 65536 (order: 6, 262144 bytes)
Sep 11 19:03:40 dwgserver kernel: Page-cache hash table entries: 262144 (order: 8, 1048576 bytes)
Sep 11 19:03:40 dwgserver kernel: CPU: L1 I cache: 12K, L1 D cache: 8K
Sep 11 19:03:40 dwgserver kernel: CPU: L2 cache: 512K
Sep 11 19:03:40 dwgserver kernel: CPU: Physical Processor ID: 0
Sep 11 19:03:40 dwgserver kernel: Intel machine check architecture supported.
Sep 11 19:03:40 dwgserver kernel: Intel machine check reporting enabled on CPU#0.
Sep 11 19:03:40 dwgserver kernel: Enabling fast FPU save and restore... done.
Sep 11 19:03:40 dwgserver kernel: Enabling unmasked SIMD FPU exception support... done.
Sep 11 19:03:41 dwgserver kernel: Checking 'hlt' instruction... OK.
Sep 11 19:03:41 dwgserver kernel: POSIX conformance testing by UNIFIX
Sep 11 19:03:41 dwgserver kernel: mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
Sep 11 19:03:41 dwgserver kernel: mtrr: detected mtrr type: Intel
Sep 11 19:03:41 dwgserver kernel: CPU: L1 I cache: 12K, L1 D cache: 8K
Sep 11 19:03:41 dwgserver kernel: CPU: L2 cache: 512K
Sep 11 19:03:41 dwgserver kernel: CPU: Physical Processor ID: 0
Sep 11 19:03:41 dwgserver kernel: Intel machine check reporting enabled on CPU#0.
Sep 11 19:03:41 dwgserver kernel: CPU0: Intel(R) XEON(TM) CPU 2.20GHz stepping 04
Sep 11 19:03:41 dwgserver kernel: per-CPU timeslice cutoff: 1463.11 usecs.
Sep 11 19:03:41 dwgserver kernel: task migration cache decay timeout: 10 msecs.
Sep 11 19:03:41 dwgserver kernel: enabled ExtINT on CPU#0
Sep 11 19:03:41 dwgserver kernel: ESR value before enabling vector: 00000000
Sep 11 19:03:41 dwgserver kernel: ESR value after enabling vector: 00000000
Sep 11 19:03:41 dwgserver kernel: Booting processor 1/1 eip 2000
Sep 11 19:03:41 dwgserver kernel: Initializing CPU#1
Sep 11 19:03:41 dwgserver kernel: masked ExtINT on CPU#1
Sep 11 19:03:41 dwgserver kernel: ESR value before enabling vector: 00000000
Sep 11 19:03:41 dwgserver kernel: ESR value after enabling vector: 00000000
Sep 11 19:03:41 dwgserver kernel: Calibrating delay loop... 4377.80 BogoMIPS
Sep 11 19:03:41 dwgserver kernel: CPU: L1 I cache: 12K, L1 D cache: 8K
Sep 11 19:03:41 dwgserver kernel: CPU: L2 cache: 512K
Sep 11 19:03:41 dwgserver kernel: CPU: Physical Processor ID: 0
Sep 11 19:03:41 dwgserver kernel: Intel machine check reporting enabled on CPU#1.
Sep 11 19:03:41 dwgserver kernel: CPU1: Intel(R) XEON(TM) CPU 2.20GHz stepping 04
Sep 11 19:03:41 dwgserver kernel: Booting processor 2/6 eip 2000
Sep 11 19:03:41 dwgserver kernel: Initializing CPU#2
Sep 11 19:03:41 dwgserver kernel: masked ExtINT on CPU#2
Sep 11 19:03:41 dwgserver kernel: ESR value before enabling vector: 00000000
Sep 11 19:03:41 dwgserver kernel: ESR value after enabling vector: 00000000
Sep 11 19:03:41 dwgserver kernel: Calibrating delay loop... 4377.80 BogoMIPS
Sep 11 19:03:41 dwgserver kernel: CPU: L1 I cache: 12K, L1 D cache: 8K
Sep 11 19:03:41 dwgserver kernel: CPU: L2 cache: 512K
Sep 11 19:03:41 dwgserver kernel: CPU: Physical Processor ID: 3
Sep 11 19:03:42 dwgserver kernel: Intel machine check reporting enabled on CPU#2.
Sep 11 19:03:42 dwgserver kernel: CPU2: Intel(R) XEON(TM) CPU 2.20GHz stepping 04
Sep 11 19:03:42 dwgserver kernel: Booting processor 3/7 eip 2000
Sep 11 19:03:42 dwgserver kernel: Initializing CPU#3
Sep 11 19:03:42 dwgserver kernel: masked ExtINT on CPU#3
Sep 11 19:03:42 dwgserver kernel: ESR value before enabling vector: 00000000
Sep 11 19:03:42 dwgserver kernel: ESR value after enabling vector: 00000000
Sep 11 19:03:42 dwgserver kernel: Calibrating delay loop... 4377.80 BogoMIPS
Sep 11 19:03:42 dwgserver kernel: CPU: L1 I cache: 12K, L1 D cache: 8K
Sep 11 19:03:42 dwgserver kernel: CPU: L2 cache: 512K
Sep 11 19:03:42 dwgserver kernel: CPU: Physical Processor ID: 3
Sep 11 19:03:42 dwgserver kernel: Intel machine check reporting enabled on CPU#3.
Sep 11 19:03:42 dwgserver kernel: CPU3: Intel(R) XEON(TM) CPU 2.20GHz stepping 04
Sep 11 19:03:42 dwgserver kernel: Total of 4 processors activated (17511.21 BogoMIPS).
Sep 11 19:03:42 dwgserver kernel: cpu_sibling_map[0] = 1
Sep 11 19:03:42 dwgserver kernel: cpu_sibling_map[1] = 0
Sep 11 19:03:42 dwgserver kernel: cpu_sibling_map[2] = 3
Sep 11 19:03:42 dwgserver kernel: cpu_sibling_map[3] = 2
Sep 11 19:03:42 dwgserver kernel: ENABLING IO-APIC IRQs
Sep 11 19:03:42 dwgserver kernel: Setting 2 in the phys_id_present_map
Sep 11 19:03:42 dwgserver kernel: ...changing IO-APIC physical APIC ID to 2 ... ok.
Sep 11 19:03:42 dwgserver kernel: Setting 3 in the phys_id_present_map
Sep 11 19:03:42 dwgserver kernel: ...changing IO-APIC physical APIC ID to 3 ... ok.
Sep 11 19:03:42 dwgserver kernel: Setting 4 in the phys_id_present_map
Sep 11 19:03:42 dwgserver kernel: ...changing IO-APIC physical APIC ID to 4 ... ok.
Sep 11 19:03:42 dwgserver kernel: ..TIMER: vector=0x31 pin1=2 pin2=0
Sep 11 19:03:42 dwgserver kernel: testing the IO APIC.......................
Sep 11 19:03:42 dwgserver kernel:
Sep 11 19:03:42 dwgserver kernel: WARNING: unexpected IO-APIC, please mail
Sep 11 19:03:42 dwgserver kernel: to linux-smp@vger.kernel.org
Sep 11 19:03:42 dwgserver kernel:
Sep 11 19:03:42 dwgserver kernel:
Sep 11 19:03:42 dwgserver kernel: .................................... done.
Sep 11 19:03:42 dwgserver kernel: Using local APIC timer interrupts.
Sep 11 19:03:42 dwgserver kernel: calibrating APIC timer ...
Sep 11 19:03:42 dwgserver kernel: ..... CPU clock speed is 2192.8898 MHz.
Sep 11 19:03:42 dwgserver kernel: ..... host bus clock speed is 99.6766 MHz.
Sep 11 19:03:42 dwgserver kernel: cpu: 0, clocks: 996766, slice: 199353
Sep 11 19:03:42 dwgserver kernel: CPU0<T0:996752,T1:797392,D:7,S:199353,C:996766>
Sep 11 19:03:42 dwgserver kernel: cpu: 3, clocks: 996766, slice: 199353
Sep 11 19:03:42 dwgserver kernel: cpu: 1, clocks: 996766, slice: 199353
Sep 11 19:03:42 dwgserver kernel: cpu: 2, clocks: 996766, slice: 199353
Sep 11 19:03:42 dwgserver kernel: CPU1<T0:996752,T1:598032,D:14,S:199353,C:996766>
Sep 11 19:03:42 dwgserver kernel: CPU2<T0:996752,T1:398672,D:21,S:199353,C:996766>
Sep 11 19:03:42 dwgserver kernel: CPU3<T0:996752,T1:199328,D:12,S:199353,C:996766>
Sep 11 19:03:42 dwgserver kernel: checking TSC synchronization across CPUs: passed.
Sep 11 19:03:42 dwgserver kernel: PCI: PCI BIOS revision 2.10 entry at 0xfd921, last bus=4
Sep 11 19:03:42 dwgserver kernel: PCI: Using configuration type 1
Sep 11 19:03:42 dwgserver kernel: PCI: Probing PCI hardware
Sep 11 19:03:42 dwgserver kernel: Unknown bridge resource 0: assuming transparent
Sep 11 19:03:42 dwgserver kernel: Unknown bridge resource 2: assuming transparent
Sep 11 19:03:42 dwgserver kernel: Unknown bridge resource 0: assuming transparent
Sep 11 19:03:42 dwgserver kernel: Unknown bridge resource 1: assuming transparent
Sep 11 19:03:42 dwgserver kernel: Unknown bridge resource 2: assuming transparent
Sep 11 19:03:42 dwgserver kernel: Unknown bridge resource 0: assuming transparent
Sep 11 19:03:42 dwgserver kernel: Unknown bridge resource 1: assuming transparent
Sep 11 19:03:42 dwgserver kernel: Unknown bridge resource 2: assuming transparent
Sep 11 19:03:42 dwgserver kernel: Unknown bridge resource 2: assuming transparent
Sep 11 19:03:42 dwgserver kernel: PCI: Using IRQ router PIIX [8086/2480] at 00:1f.0
Sep 11 19:03:42 dwgserver kernel: PCI->APIC IRQ transform: (B0,I29,P0) -> 16
Sep 11 19:03:42 dwgserver kernel: PCI->APIC IRQ transform: (B0,I29,P1) -> 19
Sep 11 19:03:42 dwgserver kernel: PCI->APIC IRQ transform: (B0,I31,P0) -> 17
Sep 11 19:03:42 dwgserver kernel: PCI->APIC IRQ transform: (B0,I31,P1) -> 17
Sep 11 19:03:42 dwgserver kernel: PCI->APIC IRQ transform: (B4,I3,P0) -> 21
Sep 11 19:03:42 dwgserver kernel: PCI->APIC IRQ transform: (B4,I4,P0) -> 20
Sep 11 19:03:42 dwgserver kernel: PCI->APIC IRQ transform: (B4,I5,P0) -> 23
Sep 11 19:03:42 dwgserver kernel: isapnp: Scanning for PnP cards...
Sep 11 19:03:42 dwgserver kernel: isapnp: No Plug & Play device found
Sep 11 19:03:42 dwgserver kernel: Linux NET4.0 for Linux 2.4
Sep 11 19:03:42 dwgserver kernel: Based upon Swansea University Computer Society NET3.039
Sep 11 19:03:42 dwgserver kernel: Initializing RT netlink socket
Sep 11 19:03:42 dwgserver kernel: apm: BIOS not found.
Sep 11 19:03:42 dwgserver kernel: Starting kswapd
Sep 11 19:03:42 dwgserver kernel: allocated 64 pages and 64 bhs reserved for the highmem bounces
Sep 11 19:03:42 dwgserver kernel: VFS: Diskquotas version dquot_6.5.0 initialized
Sep 11 19:03:42 dwgserver kernel: pty: 2048 Unix98 ptys configured
Sep 11 19:03:42 dwgserver kernel: Serial driver version 5.05c (2001-07-08) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled
Sep 11 19:03:42 dwgserver kernel: ttyS00 at 0x03f8 (irq = 4) is a 16550A
Sep 11 19:03:42 dwgserver kernel: ttyS01 at 0x02f8 (irq = 3) is a 16550A
Sep 11 19:03:42 dwgserver kernel: Real Time Clock Driver v1.10e
Sep 11 19:03:42 dwgserver kernel: block: 1024 slots per queue, batch=256
Sep 11 19:03:42 dwgserver kernel: Uniform Multi-Platform E-IDE driver Revision: 6.31
Sep 11 19:03:42 dwgserver kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
Sep 11 19:03:42 dwgserver kernel: PIIX4: IDE controller on PCI bus 00 dev f9
Sep 11 19:03:42 dwgserver kernel: PCI: Device 00:1f.1 not available because of resource collisions
Sep 11 19:03:42 dwgserver kernel: PIIX4: (ide_setup_pci_device:) Could not enable device.
Sep 11 19:03:42 dwgserver kernel: hda: IC35L120AVVA07-0, ATA DISK drive
Sep 11 19:03:42 dwgserver kernel: hdb: IC35L120AVVA07-0, ATA DISK drive
Sep 11 19:03:42 dwgserver kernel: hdc: CR-48XATE, ATAPI CD/DVD-ROM drive
Sep 11 19:03:42 dwgserver kernel: hdd: IC35L120AVVA07-0, ATA DISK drive
Sep 11 19:03:42 dwgserver kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Sep 11 19:03:42 dwgserver kernel: ide1 at 0x170-0x177,0x376 on irq 15
Sep 11 19:03:42 dwgserver kernel: hda: 241254720 sectors (123522 MB) w/1863KiB Cache, CHS=239340/16/63
Sep 11 19:03:42 dwgserver kernel: hdb: 241254720 sectors (123522 MB) w/1863KiB Cache, CHS=239340/16/63
Sep 11 19:03:42 dwgserver kernel: hdd: 241254720 sectors (123522 MB) w/1863KiB Cache, CHS=239340/16/63
Sep 11 19:03:42 dwgserver kernel: ide-floppy driver 0.99.newide
Sep 11 19:03:42 dwgserver kernel: Partition check:
Sep 11 19:03:42 dwgserver kernel: hda: hda1 hda2 hda3
Sep 11 19:03:42 dwgserver kernel: hdb: hdb1
Sep 11 19:03:42 dwgserver kernel: hdd: hdd1
Sep 11 19:03:42 dwgserver kernel: Floppy drive(s): fd0 is 1.44M
Sep 11 19:03:42 dwgserver kernel: FDC 0 is a post-1991 82077
Sep 11 19:03:42 dwgserver kernel: RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Sep 11 19:03:42 dwgserver kernel: ide-floppy driver 0.99.newide
Sep 11 19:03:42 dwgserver kernel: md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
Sep 11 19:03:42 dwgserver kernel: md: Autodetecting RAID arrays.
Sep 11 19:03:42 dwgserver kernel: md: autorun ...
Sep 11 19:03:42 dwgserver kernel: md: ... autorun DONE.
Sep 11 19:03:42 dwgserver kernel: pci_hotplug: PCI Hot Plug PCI Core version: 0.4
Sep 11 19:03:42 dwgserver kernel: NET4: Linux TCP/IP 1.0 for NET4.0
Sep 11 19:03:42 dwgserver kernel: IP Protocols: ICMP, UDP, TCP, IGMP
Sep 11 19:03:42 dwgserver kernel: IP: routing cache hash table of 8192 buckets, 64Kbytes
Sep 11 19:03:42 dwgserver kernel: TCP: Hash tables configured (established 262144 bind 65536)
Sep 11 19:03:42 dwgserver kernel: Linux IP multicast router 0.06 plus PIM-SM
Sep 11 19:03:42 dwgserver kernel: NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Sep 11 19:03:42 dwgserver kernel: RAMDISK: Compressed image found at block 0
Sep 11 19:03:42 dwgserver kernel: Freeing initrd memory: 122k freed
Sep 11 19:03:42 dwgserver kernel: VFS: Mounted root (ext2 filesystem).
Sep 11 19:03:42 dwgserver kernel: Journalled Block Device driver loaded
Sep 11 19:03:42 dwgserver kernel: kjournald starting. Commit interval 5 seconds
Sep 11 19:03:42 dwgserver kernel: EXT3-fs: mounted filesystem with ordered data mode.
Sep 11 19:03:42 dwgserver kernel: Freeing unused kernel memory: 304k freed
Sep 11 19:03:42 dwgserver kernel: Adding Swap: 2047744k swap-space (priority -1)
Sep 11 19:03:42 dwgserver kernel: usb.c: registered new driver usbdevfs
Sep 11 19:03:42 dwgserver kernel: usb.c: registered new driver hub
Sep 11 19:03:42 dwgserver kernel: usb-uhci.c: $Revision: 1.275 $ time 07:32:55 Apr 18 2002
Sep 11 19:03:42 dwgserver kernel: usb-uhci.c: High bandwidth mode enabled
Sep 11 19:03:42 dwgserver kernel: PCI: Setting latency timer of device 00:1d.0 to 64
Sep 11 19:03:42 dwgserver kernel: usb-uhci.c: USB UHCI at I/O 0x6c00, IRQ 16
Sep 11 19:03:42 dwgserver kernel: usb-uhci.c: Detected 2 ports
Sep 11 19:03:42 dwgserver kernel: usb.c: new USB bus registered, assigned bus number 1
Sep 11 19:03:43 dwgserver kernel: hub.c: USB hub found
Sep 11 19:03:43 dwgserver kernel: hub.c: 2 ports detected
Sep 11 19:03:43 dwgserver kernel: PCI: Setting latency timer of device 00:1d.1 to 64
Sep 11 19:03:43 dwgserver kernel: usb-uhci.c: USB UHCI at I/O 0x6c20, IRQ 19
Sep 11 19:03:43 dwgserver kernel: usb-uhci.c: Detected 2 ports
Sep 11 19:03:43 dwgserver kernel: usb.c: new USB bus registered, assigned bus number 2
Sep 11 19:03:43 dwgserver kernel: hub.c: USB hub found
Sep 11 19:03:43 dwgserver kernel: hub.c: 2 ports detected
Sep 11 19:03:43 dwgserver kernel: usb-uhci.c: v1.275:USB Universal Host Controller Interface driver
Sep 11 19:03:43 dwgserver kernel: EXT3 FS 2.4-0.9.17, 10 Jan 2002 on ide0(3,3), internal journal
Sep 11 19:03:43 dwgserver kernel: kjournald starting. Commit interval 5 seconds
Sep 11 19:03:43 dwgserver kernel: EXT3 FS 2.4-0.9.17, 10 Jan 2002 on ide0(3,1), internal journal
Sep 11 19:03:43 dwgserver kernel: EXT3-fs: mounted filesystem with ordered data mode.
Sep 11 19:03:43 dwgserver kernel: kjournald starting. Commit interval 5 seconds
Sep 11 19:03:43 dwgserver kernel: EXT3 FS 2.4-0.9.17, 10 Jan 2002 on ide0(3,65), internal journal
Sep 11 19:03:43 dwgserver kernel: EXT3-fs: mounted filesystem with ordered data mode.
Sep 11 19:03:43 dwgserver kernel: kjournald starting. Commit interval 5 seconds
Sep 11 19:03:43 dwgserver kernel: EXT3 FS 2.4-0.9.17, 10 Jan 2002 on ide1(22,65), internal journal
Sep 11 19:03:43 dwgserver kernel: EXT3-fs: mounted filesystem with ordered data mode.
Sep 11 19:03:43 dwgserver kernel: SCSI subsystem driver Revision: 1.00
Sep 11 19:03:43 dwgserver kernel: scsi0 : SCSI host adapter emulation for IDE ATAPI devices
Sep 11 19:03:43 dwgserver kernel: Vendor: MITSUMI Model: CR-48XATE Rev: 1.0E
Sep 11 19:03:43 dwgserver kernel: Type: CD-ROM ANSI SCSI revision: 02
Sep 11 19:03:43 dwgserver kernel: parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,EPP]
Sep 11 19:03:43 dwgserver kernel: parport0: irq 7 detected
Sep 11 19:03:43 dwgserver kernel: eepro100.c:v1.09j-t 9/29/99 Donald Becker http://www.scyld.com/network/eepro100.html
Sep 11 19:03:43 dwgserver kernel: eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin <saw@saw.sw.com.sg> and others
Sep 11 19:03:43 dwgserver kernel: eth0: OEM i82557/i82558 10/100 Ethernet, 00:02:B3:B0:A4:BD, IRQ 20.
Sep 11 19:03:43 dwgserver kernel: Board assembly ffffff-255, Physical connectors present: RJ45
Sep 11 19:03:43 dwgserver kernel: Primary interface chip i82555 PHY #1.
Sep 11 19:03:43 dwgserver kernel: Secondary interface chip i82555.
Sep 11 19:03:43 dwgserver kernel: General self-test: passed.
Sep 11 19:03:43 dwgserver kernel: Serial sub-system self-test: passed.
Sep 11 19:03:43 dwgserver kernel: Internal registers self-test: passed.
Sep 11 19:03:43 dwgserver kernel: ROM checksum self-test: passed (0xb874c1d3).
Sep 11 19:03:43 dwgserver kernel: eth1: OEM i82557/i82558 10/100 Ethernet, 00:02:B3:B0:A5:9B, IRQ 23.
Sep 11 19:03:43 dwgserver kernel: Board assembly ffffff-255, Physical connectors present: RJ45
Sep 11 19:03:43 dwgserver kernel: Primary interface chip i82555 PHY #1.
Sep 11 19:03:43 dwgserver kernel: Secondary interface chip i82555.
Sep 11 19:03:43 dwgserver kernel: General self-test: passed.
Sep 11 19:03:43 dwgserver kernel: Serial sub-system self-test: passed.
Sep 11 19:03:43 dwgserver kernel: Internal registers self-test: passed.
Sep 11 19:03:43 dwgserver kernel: ROM checksum self-test: passed (0xb874c1d3).
isplay, exiting
Sep 11 19:04:36 dwgserver kernel: Attached scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
Sep 11 19:04:36 dwgserver kernel: sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray
Sep 11 19:04:36 dwgserver kernel: Uniform CD-ROM driver Revision: 3.12
Sep 11 19:04:39 dwgserver gconfd (root-1477): starting (version 1.0.9), pid 1477 user 'root'
Sep 11 22:01:15 dwgserver kernel:
Sep 11 22:01:15 dwgserver kernel: wait_on_irq, CPU 2:
Sep 11 22:01:15 dwgserver kernel: irq: 1 [ 2 0 0 0 ]
Sep 11 22:01:15 dwgserver kernel: bh: 1 [ 1 0 0 0 ]
Sep 11 22:01:15 dwgserver kernel: Stack dumps:
Sep 11 22:01:15 dwgserver kernel: CPU 0:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Sep 11 22:01:15 dwgserver kernel: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Sep 11 22:01:15 dwgserver kernel: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Sep 11 22:01:15 dwgserver kernel: Call Trace: [<c01190c9>] __wake_up [kernel] 0x39
Sep 11 22:01:15 dwgserver kernel: [<c017e7f0>] n_tty_receive_buf [kernel] 0xbb0
Sep 11 22:01:15 dwgserver kernel: [<c0119048>] schedule [kernel] 0x348
Sep 11 22:01:15 dwgserver kernel: [<c0129a10>] ____call_usermodehelper [kernel] 0x0
Sep 11 22:01:15 dwgserver kernel: [<c0119271>] wait_for_completion [kernel] 0x91
Sep 11 22:01:16 dwgserver kernel: [<c0124eb5>] update_process_times [kernel] 0x25
Sep 11 22:01:16 dwgserver kernel: [<c0116049>] smp_apic_timer_interrupt [kernel] 0xa9
Sep 11 22:01:16 dwgserver kernel: [<c01c37b2>] vgacon_cursor [kernel] 0x1b2
Sep 11 22:01:17 dwgserver kernel: [<c017cce3>] flush_to_ldisc [kernel] 0x113
Sep 11 22:01:17 dwgserver kernel: [<c0129e41>] context_thread [kernel] 0x131
Sep 11 22:01:17 dwgserver kernel: [<c0129d10>] context_thread [kernel] 0x0
Sep 11 22:01:17 dwgserver kernel: [<c0105000>] stext [kernel] 0x0
Sep 11 22:01:17 dwgserver kernel: [<c0107286>] kernel_thread [kernel] 0x26
Sep 11 22:01:17 dwgserver kernel: [<c0129d10>] context_thread [kernel] 0x0
Sep 11 22:01:18 dwgserver kernel:
Sep 11 22:01:18 dwgserver kernel:
Sep 11 22:01:18 dwgserver kernel: CPU 1:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Sep 11 22:01:18 dwgserver kernel: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Sep 11 22:01:18 dwgserver kernel: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Sep 11 22:01:18 dwgserver kernel: Call Trace:
Sep 11 22:01:18 dwgserver kernel:
Sep 11 22:01:18 dwgserver kernel: CPU 3:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Sep 11 22:01:18 dwgserver kernel: f68d4360 401b3000 401d6000 f7cf2a20 00000025 00000075 f5d52738 00000001
Sep 11 22:01:18 dwgserver kernel: f7cf2a38 f7cf2618 f7751b00 f7cf2a48 c02eff8c 00000000 f5b51a40 00000000
Sep 11 22:01:18 dwgserver kernel: Call Trace:
Sep 11 22:01:19 dwgserver kernel:
Sep 11 22:01:19 dwgserver kernel: CPU 2:f608df04 c02418e1 00000002 00000002 ffffffff 00000002 c010a372 c02418f6
Sep 11 22:01:19 dwgserver kernel: f773c8c0 00000001 f6082000 c018e509 f6082000 f6082000 f6082000 c017fff6
Sep 11 22:01:19 dwgserver kernel: f6082000 00000000 00000286 f6082000 00000002 f6082000 0000540b c017ca62
Sep 11 22:01:19 dwgserver kernel: Call Trace: [<c010a372>] __global_cli [kernel] 0xe2
Sep 11 22:01:19 dwgserver kernel: [<c018e509>] rs_flush_buffer [kernel] 0x19
Sep 11 22:01:19 dwgserver kernel: [<c017fff6>] n_tty_ioctl [kernel] 0x266
Sep 11 22:01:19 dwgserver kernel: [<c017ca62>] tty_ioctl [kernel] 0x352
Sep 11 22:01:19 dwgserver kernel: [<c0151b97>] sys_ioctl [kernel] 0x257
Sep 11 22:01:19 dwgserver kernel: [<c0108c6b>] system_call [kernel] 0x33
Sep 11 22:01:19 dwgserver kernel:
Sep 11 22:03:08 dwgserver last message repeated 2 times
Sep 11 22:03:08 dwgserver kernel: wait_on_irq, CPU 1:
Sep 11 22:03:08 dwgserver kernel: irq: 1 [ 2 0 0 0 ]
Sep 11 22:03:08 dwgserver kernel: bh: 1 [ 1 0 0 0 ]
Sep 11 22:03:08 dwgserver kernel: Stack dumps:
Sep 11 22:03:08 dwgserver kernel: CPU 0: <unknown>
Sep 11 22:03:08 dwgserver kernel: CPU 2:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Sep 11 22:03:08 dwgserver kernel: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Sep 11 22:03:08 dwgserver kernel: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Sep 11 22:03:14 dwgserver kernel: Call Trace: [<c0200f00>] tcp_data_queue [kernel] 0x9e0
Sep 11 22:03:14 dwgserver kernel:
Sep 11 22:03:14 dwgserver kernel:
Sep 11 22:03:14 dwgserver kernel: CPU 3:00000000 00000000 706d7564 00000000 00000000 00000000 00000000 00000000
Sep 11 22:03:15 dwgserver kernel: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Sep 11 22:03:15 dwgserver kernel: 00000000 25dac9fa 00000000 00000000 00000000 00000000 00000000 00000000
Sep 11 22:03:16 dwgserver kernel: Call Trace:
Sep 11 22:03:16 dwgserver kernel:
Sep 11 22:03:17 dwgserver kernel: CPU 1:f608de3c c02418e1 00000001 00000002 ffffffff 00000001 c010a372 c02418f6
Sep 11 22:03:17 dwgserver kernel: f6082000 00000000 f6917000 c018e3da 00000001 00000000 f6082000 f6082000
Sep 11 22:03:17 dwgserver kernel: f608de98 00000001 c017d7c0 f6082000 00000000 f608de98 00000001 00000246
Sep 11 22:03:17 dwgserver kernel: Call Trace: [<c010a372>] __global_cli [kernel] 0xe2
Sep 11 22:03:17 dwgserver kernel: [<c018e3da>] rs_write [kernel] 0x16a
Sep 11 22:03:17 dwgserver kernel: [<c017d7c0>] opost_block [kernel] 0x180
Sep 11 22:03:18 dwgserver kernel: [<c0139d92>] __alloc_pages [kernel] 0x72
Sep 11 22:03:18 dwgserver kernel: [<c0119048>] schedule [kernel] 0x348
Sep 11 22:03:18 dwgserver kernel: [<c017f3e5>] write_chan [kernel] 0x165
Sep 11 22:03:18 dwgserver kernel: [<c017b0b2>] tty_write [kernel] 0x202
Sep 11 22:03:18 dwgserver kernel: [<c017f280>] write_chan [kernel] 0x0
Sep 11 22:03:18 dwgserver kernel: [<c0141bf6>] sys_write [kernel] 0x96
Sep 11 22:03:18 dwgserver kernel: [<c01206f2>] sys_time [kernel] 0x12
Sep 11 22:03:18 dwgserver kernel: [<c0108c6b>] system_call [kernel] 0x33
Sep 11 22:03:18 dwgserver kernel:
Sep 11 22:03:18 dwgserver kernel:
Sep 12 10:22:02 dwgserver kernel: parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,EPP]
Sep 12 10:22:02 dwgserver kernel: parport0: irq 7 detected
Sep 12 10:22:38 dwgserver kernel: parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,EPP]
Sep 12 10:22:38 dwgserver kernel: parport0: irq 7 detected
^ permalink raw reply
* Re: Yaesu ft847/100 control
From: Luc Langehegermann @ 2002-09-16 16:01 UTC (permalink / raw)
To: n7bfs, linux-hams
In-Reply-To: <200209160808.22938.n7bfs@qwest.net>
Am Mo 16 Sep 2002 17:08 schrieb Douglas Cole:
> Been a lurker for quite a while now , and have been learning lots about
> packet , but was wondering if anyone has done a gui/X based control proggie
> for the above radio's?
>
> I don't seem to have the brains to be a programmer and so am at the mercy
> of you folks who have ;^}
>
> I desire a Linux based program , as that is all I run at home , and I am
> willing to pay money for it if it is stable and X based .
>
> tia
Hmm... you could try using grig. Grig uses hamlib, and as far as i know,
hamlib supports both, the ft847 and the ft100
Luc
^ permalink raw reply
* Re: [PATCH] Fix for ptrace breakage
From: Daniel Jacobowitz @ 2002-09-16 16:05 UTC (permalink / raw)
To: OGAWA Hirofumi; +Cc: Ingo Molnar, linux-kernel
In-Reply-To: <87fzwasz96.fsf@devron.myhome.or.jp>
On Tue, Sep 17, 2002 at 12:57:57AM +0900, OGAWA Hirofumi wrote:
> Daniel Jacobowitz <dan@debian.org> writes:
>
> > > > Some comments. First of all, you said you fixed a race on
> > > > current->ptrace and some other bugs - would you mind saying where they
> > > > were? It's definitely cleaner after your patch but I'd like to
> > > > understand where you found bugs, since I think you're introducing more.
> > >
> > > It's the following
> > >
> > > task_t *trace_task = p->parent;
> > > int ptrace_flag = p->ptrace;
> > > BUG_ON (ptrace_flag == 0);
> > >
> > > __ptrace_unlink(p);
> > > p->ptrace = ptrace_flag;
> > > __ptrace_link(p, trace_task);
> >
> > We have the tasklist lock. How can there be a race here? The parent
> > can't detach while we're holding the tasklist lock. If there is a race
> > with PTRACE_SETOPTIONS, then PTRACE_SETOPTIONS should take the lock.
>
> No. If the real parent don't change ->ptrace, it doesn't need
> lock.
I don't understand what you mean by that. Do you mean, "if it does
change ->ptrace, it doesn't need a lock"?
The locking requirements for tsk->ptrace are not documented anywhere
right now; we basically don't have any.
> > > > So you reparent children on the ptrace_list right here. But they still
> > > > need to go through zap_thread! You're right, the do_notify_parent in
> > > > zap_thread isn't necessary; it'll be taken care of in sys_wait4. The
> > > > orphaned pgrp check is still relevant though.
> > >
> > > ??? You forget tasklist_lock?
> >
> > Huh?
> >
> > The problem I am describing is when a child - which will become an
> > orphaned pgrp when ``father'' dies - is being ptraced at the moment of
> > ``father''s death. With your patch it will be moved to
> > reaper->ptrace_children (or child_reaper->ptrace_children) but never
> > orphaned properly. It'll miss a signal.
> >
> > > > If you're going to remove the if, you need to maintain its effect!
> > > > See:
> > > > > - if (p->parent != father) {
> > > > > - BUG_ON(p->parent != p->real_parent);
> > > > > - return;
> > > > > - }
> > > >
> > > > This is the case where we were tracing something. The ptrace_unlink
> > > > returned it to its original parent. It doesn't need the
> > > > remove_parent/add_parent (though they are harmless); it does need to
> > > > avoid the orphaned pgrp check. It may need the do_notify_parent check,
> > > > which was a bug in the previous code.
> > >
> > > What is the basis which you think it is bug?
> >
> > The death of a tracing process should not have any effect on the traced
> > process except to untrace it. It should not go through the orphaning
> > checks. The orphaning checks assume that the exiting process is the
> > real parent, and will orphan the pgrp if it is not in the same
> > session... as its tracer! That's a bug.
>
> Ah, ok. I think, it's longtime (odd) behavior. And you think, it's
> a bug. Right?
>
> And, both of your and old code has odd behavior. yes?
Before your patch, do_notify_parent didn't get called; I think that
perhaps it should be. I'll think about that. After your patch the
process group will be unexpectedly orphaned, which is not now the case.
Let me sit on this for a couple of hours. I'll send you an alternative
patch to look at.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply
* Re: 2.4.20pre5aa2
From: Dave Hansen @ 2002-09-16 16:03 UTC (permalink / raw)
To: Andrea Arcangeli
Cc: Samuel Flory, Stephen Lord, Austin Gonyou, Christian Guggenberger,
Linux Kernel, linux-xfs
In-Reply-To: <20020913125345.GO11605@dualathlon.random>
[-- Attachment #1.1: Type: text/plain, Size: 1448 bytes --]
Andrea Arcangeli wrote:
> On Thu, Sep 12, 2002 at 07:14:14PM -0700, Samuel Flory wrote:
>
>>Andrea Arcangeli wrote:
>>
>>>On Thu, Sep 12, 2002 at 07:47:48PM -0500, Stephen Lord wrote:
>>>
>>>>How much memory is in the machine by the way? And Andrea, is the
>>>>vmalloc space size reduced in the 3G user space configuration?
>>>
>>>it's not reduced, it's the usual 128m.
>>>
>>>BTW, I forgot to say that to really take advantage of CONFIG_2G one
>>>should increase __VMALLOC_RESERVE too, it's not directly in function of
>>>the CONFIG_2G.
>>>
>>
>>So how much do you recommend increasing it? Currently it's:
>>include/asm-i386/page.h:#define __VMALLOC_RESERVE (128 << 20)
>>include/asm/page.h:#define __VMALLOC_RESERVE (128 << 20)
>
>
> you can try to compile with CONFIG_3G and to set __VMALLOC_RESERVE to
> (512 << 20) and see if it helps. If it only happens a bit later then
> it's most probably an address space leak, should be easy to track down
> some debugging instrumentation.
I just produced this little patch for 2.5. It should provide a bit of the extra
information that you were looking for. It adds some entries to /proc/meminfo
that look like this:
VMalTotal: 92123 kB
VmalUsed: 1264 kB
VMalChunk: 80315 kB
Total available, total used, and largest chunk available.
It is simple enough that a backport shouldn't be any problem at all. Anybody
interested?
--
Dave Hansen
haveblue@us.ibm.com
[-- Attachment #1.2: vmalloc-stats-2.5.34-mm4-2.patch --]
[-- Type: text/plain, Size: 2430 bytes --]
diff -ur linux-2.5.34-mm4/fs/proc/proc_misc.c linux-2.5.34-mm4-vmalloc-stats/fs/proc/proc_misc.c
--- linux-2.5.34-mm4/fs/proc/proc_misc.c Sat Sep 14 21:23:54 2002
+++ linux-2.5.34-mm4-vmalloc-stats/fs/proc/proc_misc.c Sat Sep 14 22:38:12 2002
@@ -38,6 +38,7 @@
#include <linux/smp_lock.h>
#include <linux/seq_file.h>
#include <linux/times.h>
+#include <linux/vmalloc.h>
#include <asm/uaccess.h>
#include <asm/pgtable.h>
@@ -128,6 +129,40 @@
return proc_calc_metrics(page, start, off, count, eof, len);
}
+struct vmalloc_info {
+ unsigned long used;
+ unsigned long largest_chunk;
+};
+
+static struct vmalloc_info get_vmalloc_info(void)
+{
+ unsigned long prev_end = VMALLOC_START;
+ struct vm_struct* vma;
+ struct vmalloc_info vmi;
+ vmi.used = 0;
+
+ read_lock(&vmlist_lock);
+
+ if(!vmlist)
+ vmi.largest_chunk = (VMALLOC_END-VMALLOC_START);
+ else
+ vmi.largest_chunk = 0;
+
+ for (vma = vmlist; vma; vma = vma->next) {
+ unsigned long free_area_size =
+ (unsigned long)vma->addr - prev_end;
+ vmi.used += vma->size;
+ if (vmi.largest_chunk < free_area_size )
+ vmi.largest_chunk = free_area_size;
+ prev_end = vma->size + (unsigned long)vma->addr;
+ }
+ if(VMALLOC_END-prev_end > vmi.largest_chunk)
+ vmi.largest_chunk = VMALLOC_END-prev_end;
+
+ read_unlock(&vmlist_lock);
+ return vmi;
+}
+
extern atomic_t vm_committed_space;
static int meminfo_read_proc(char *page, char **start, off_t off,
@@ -138,6 +173,8 @@
struct page_state ps;
unsigned long inactive;
unsigned long active;
+ unsigned long vmtot;
+ struct vmalloc_info vmi;
get_page_state(&ps);
get_zone_counts(&active, &inactive);
@@ -150,6 +187,11 @@
si_swapinfo(&i);
committed = atomic_read(&vm_committed_space);
+ vmtot = (VMALLOC_END-VMALLOC_START)>>10;
+ vmi = get_vmalloc_info();
+ vmi.used >>= 10;
+ vmi.largest_chunk >>= 10;
+
/*
* Tagged format, for easy grepping and expansion.
*/
@@ -174,7 +216,10 @@
"Slab: %8lu kB\n"
"Committed_AS: %8u kB\n"
"PageTables: %8lu kB\n"
- "ReverseMaps: %8lu\n",
+ "ReverseMaps: %8lu\n"
+ "VmalTotal: %8lu kB\n"
+ "VmalUsed: %8lu kB\n"
+ "VmalChunk: %8lu kB\n",
K(i.totalram),
K(i.freeram),
K(i.sharedram),
@@ -195,7 +240,10 @@
K(ps.nr_slab),
K(committed),
K(ps.nr_page_table_pages),
- ps.nr_reverse_maps
+ ps.nr_reverse_maps,
+ vmtot,
+ vmi.used,
+ vmi.largest_chunk
);
#ifdef CONFIG_HUGETLB_PAGE
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* Re: Re: [alsa-cvslog] CVS: alsa-kernel/isa cmi8330.c,1.10,1.11
From: Thierry Vignaud @ 2002-09-16 16:00 UTC (permalink / raw)
To: Takashi Iwai; +Cc: Jaroslav Kysela, alsa-devel
In-Reply-To: <s5hznuiroht.wl@alsa2.suse.de>
Takashi Iwai <tiwai@suse.de> writes:
> > > cmi8330 works even without isapnp. hence CONFIG_ISAPNP should
> > > not be added in config.in.
> >
> > for all models ?
>
> not sure...
>
> > i had once a cmi8330 (well something like four years ago) and at
> > that time it would only works after playing with isapnptools.
>
> then CONFIG_ISAPNP should not be in the dependency list. the driver
> wouldn't be compiled once if CONFIG_ISAPNP=n, even though you could
> use the card with help of isapnptools.
but alsa donation of isapnp to the core kernel made isapnptools
obsoloted since.
anyway, i've no problem with the original patch if some cards works
without isapnp support.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
^ permalink raw reply
* Re: why can't I telnet
From: Maciej Soltysiak @ 2002-09-16 15:58 UTC (permalink / raw)
To: Antony Stone; +Cc: netfilter
In-Reply-To: <200209161511.g8GFBBv15493@vulcan.rissington.net>
> routed through this one, then I can't see the reason why it's not working; I
> suggest you add a LOGging rule after each of these rules to show you what
> packets are trying to get in or out of the machine and being blocked.
And it is good to learn to use tcpdump and use it with every problem you
encounter. Just to see the traffic.
Regards,
Maciej Soltysiak
^ permalink raw reply
* kernel debuggers was [Re: [linux-usb-devel] Re: [BK PATCH] USB changes for 2.5.34]
From: Soewono Effendi @ 2002-09-16 15:59 UTC (permalink / raw)
To: Daniel Phillips; +Cc: linux-kernel
In-Reply-To: <E17qxbC-0000JO-00@starship>
Hi all,
just my .02 $
what I mostly admire in linux and it's development till now,
is it's flexibility to adapt the dynamic complex changing requirements
from server to desktop even embedded system and real-time system.
>From high throughput to low latency, you just name it!
And still though no one feels disadvantaged,
since features not needed are "removable".
I'm just wondering "if it's worth the effort" to provide
"removable customizable kernel debugging tools (entry/break points)",
which one can replaces with tools of his/her choice.
I'm talking about some unified cleaver reasonable MACROS,
which one can easy insert/use them where needed.
It's still wrong to force development tools to be persist in running system
where they are not needed.
There are lots of "nice things" that can be implemented in kernel,
but are they essential?
Tools should not become burdens!
Best regards,
S. Effendi
^ permalink raw reply
* [ANNOUNCE] Journaled File System (JFS) release 1.0.22
From: Steve Best @ 2002-09-16 16:02 UTC (permalink / raw)
To: linux-kernel
Release 1.0.22 of JFS was made available today.
Drop 60 on September 16, 2002 (jfs-2.4-1.0.22.tar.gz
and jfsutils-1.0.22.tar.gz) includes fixes to the file
system and utilities.
There are two patches available to support ACLs, the first is
JFS extended attributes (jfs-2.4-1.0.22-xattr.patch)
the second is JFS ACLs (jfs-2.4-1.0.22-acl.patch).
Utilities changes
- add jfs_tune utility (see jfs_tune man page for details)
jfs_tune allows users to:
attach a JFS external journal to a JFS file system
set/change volume label, UUID of JFS file system and external log
devices
view superblock information of JFS file system and external log
devices
- add option '-J journal_device' to mkfs.jfs to create an external journal
only and optionally set its volume label (see mkfs.jfs man page)
- add option '-J device=' to mkfs.jfs to attach an existing JFS external
journal to the JFS file system that will be created
(see mkfs.jfs man page)
- fix mkfs.jfs to store 16 character volume labels properly
- code cleaup
- add extend support to JFS FSIM for EVMS
see http://sourceforge.net/projects/evms/
File System changes
- Use strtoul instead of strtoull
- Add write_super_lockfs & unlock_fs used for snapshot
- rework extent invalidation
- cosmetic changes to reduce the diff to the bitkeeper tree
- backport lmLogWait from 2.5
- Remove unused jfs_extendfs.h
- use buffer_heads to access the superblock
- ifdef out unused functions related to partial blocks
- sync the block device on umount or r/o remount
- remove superfluous includes
For more details about JFS, please see the patch instructions
or changelog.jfs files.
Steve
JFS for Linux http://oss.software.ibm.com/jfs
^ permalink raw reply
* Re: [PATCH] Fix for ptrace breakage
From: OGAWA Hirofumi @ 2002-09-16 15:57 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Ingo Molnar, Linus Torvalds, linux-kernel
In-Reply-To: <20020916144204.GA7991@nevyn.them.org>
Daniel Jacobowitz <dan@debian.org> writes:
> > > Some comments. First of all, you said you fixed a race on
> > > current->ptrace and some other bugs - would you mind saying where they
> > > were? It's definitely cleaner after your patch but I'd like to
> > > understand where you found bugs, since I think you're introducing more.
> >
> > It's the following
> >
> > task_t *trace_task = p->parent;
> > int ptrace_flag = p->ptrace;
> > BUG_ON (ptrace_flag == 0);
> >
> > __ptrace_unlink(p);
> > p->ptrace = ptrace_flag;
> > __ptrace_link(p, trace_task);
>
> We have the tasklist lock. How can there be a race here? The parent
> can't detach while we're holding the tasklist lock. If there is a race
> with PTRACE_SETOPTIONS, then PTRACE_SETOPTIONS should take the lock.
No. If the real parent don't change ->ptrace, it doesn't need
lock.
> > > So you reparent children on the ptrace_list right here. But they still
> > > need to go through zap_thread! You're right, the do_notify_parent in
> > > zap_thread isn't necessary; it'll be taken care of in sys_wait4. The
> > > orphaned pgrp check is still relevant though.
> >
> > ??? You forget tasklist_lock?
>
> Huh?
>
> The problem I am describing is when a child - which will become an
> orphaned pgrp when ``father'' dies - is being ptraced at the moment of
> ``father''s death. With your patch it will be moved to
> reaper->ptrace_children (or child_reaper->ptrace_children) but never
> orphaned properly. It'll miss a signal.
>
> > > If you're going to remove the if, you need to maintain its effect!
> > > See:
> > > > - if (p->parent != father) {
> > > > - BUG_ON(p->parent != p->real_parent);
> > > > - return;
> > > > - }
> > >
> > > This is the case where we were tracing something. The ptrace_unlink
> > > returned it to its original parent. It doesn't need the
> > > remove_parent/add_parent (though they are harmless); it does need to
> > > avoid the orphaned pgrp check. It may need the do_notify_parent check,
> > > which was a bug in the previous code.
> >
> > What is the basis which you think it is bug?
>
> The death of a tracing process should not have any effect on the traced
> process except to untrace it. It should not go through the orphaning
> checks. The orphaning checks assume that the exiting process is the
> real parent, and will orphan the pgrp if it is not in the same
> session... as its tracer! That's a bug.
Ah, ok. I think, it's longtime (odd) behavior. And you think, it's
a bug. Right?
And, both of your and old code has odd behavior. yes?
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
^ permalink raw reply
* Re: Hi is this critical??
From: venom @ 2002-09-16 15:57 UTC (permalink / raw)
To: Xavier Bestel; +Cc: Mark Veltzer, Linux Kernel Mailing List
In-Reply-To: <1032185694.7129.21.camel@bip>
If so, why not to use S.M.A.R.T with smartd and smartctl?
I think you will like them (loock on freshmeat for the link).
On 16 Sep 2002, Xavier Bestel wrote:
> Date: 16 Sep 2002 16:14:54 +0200
> From: Xavier Bestel <xavier.bestel@free.fr>
> To: Mark Veltzer <mark@veltzer.org>
> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Subject: Re: Hi is this critical??
>
> Le lun 16/09/2002 à 16:16, Mark Veltzer a écrit :
>
> > 2. The user who posted the question is under no circumstances a "looser"
> > (mind the oo instead of the u...). His question is very valid and the fact
> > that he read dmesg puts him way past any standard computer user.
>
> Well, actually I didn't want to depict *him* as a looser. I was talking
> about me :) I've already been confronted with message from the IDE
> drivers (and that's when I see them. I'm not always at the console or
> reading syslog) and I never remember if they are critical or harmless. I
> have to either dig through lkml archives to find what they mean, or ask
> lkml what do they mean (to the luser I am).
>
> IDE error/status message aren't visible enough. I'd like to know when my
> drive is near failing, without looking at syslog.
>
> Xav - luser
>
> -
> 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
* Re: [PATCH] Summit patch for 2.5.34
From: Dave Jones @ 2002-09-16 15:55 UTC (permalink / raw)
To: James Cleverdon; +Cc: linux-kernel, James.Bottomley, torvalds, alan, mingo
In-Reply-To: <200209122035.14678.jamesclv@us.ibm.com>
On Thu, Sep 12, 2002 at 08:35:14PM -0700, James Cleverdon wrote:
> Patch that allows IBM x440 boxes to on-line all CPUs and interrupt routing for
> x360s. Fixed x360 ID bug.
Couple questions/comments.
- Is this the same summit code as is in 2.4-ac ?
(Ie, the one that boots on non summit systems too)
- I believe the way forward here is to work with James Bottomley,
who has a nice abstraction of the areas your patch touches for
his Voyager sub-architecture.
Linus has however been completley silent on the x86-subarch idea
despite heavyweights like Alan and Ingo adding their support...
If you go this route, James' base needs to go in first
(converting just the in-kernel visws support). After which, adding
support for Voyager, Summit and any other wacky x86esque hardware
is a simple non-intrusive patch that touches subarch specific areas.
- Some of the code you've added looks along the lines of..
if (numaq)
foo();
else if (summit)
foo2();
else
foo3();
Would it be over-abstracting to have some form of APIC struct,
defining pointers to various routines instead of lots of ugly
if's/switches/fall-through's.
However, the last point may be completley pointless after adapting to
use what James B has come up with..
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* [PATCH,TRIVIAL] unused task_struct.shared_unblocked variable.
From: Oleg Nesterov @ 2002-09-16 16:00 UTC (permalink / raw)
To: linux-kernel; +Cc: Ingo Molnar
Hello.
The task_struct.shared_unblocked variable is unused.
The 'old_state' variable in try_to_wake_up() is unneeded.
The third recheck of rq->nr_running after load_balance()
in schedule() is unneeded. Compiler should optimize it,
but it looks slightly confusing (imho).
2.5.34 introduced this change in force_sig_info()
- return send_sig_info(sig, info, t);
+ return send_sig_info(sig, (void *)1, t);
I beleive, it is wrong, info can carry useful information
from do_page_fault, traps. And this (info *)1 does not
prevent send_signal() from allocation of siginfo struct.
Ingo, could you please clarify?
Oleg.
--- linux-2.5.35/include/linux/sched.h.orig Mon Sep 16 18:11:32 2002
+++ linux-2.5.35/include/linux/sched.h Mon Sep 16 18:12:21 2002
@@ -374,7 +374,7 @@
spinlock_t sigmask_lock; /* Protects signal and blocked */
struct signal_struct *sig;
- sigset_t blocked, real_blocked, shared_unblocked;
+ sigset_t blocked, real_blocked;
struct sigpending pending;
unsigned long sas_ss_sp;
--- linux-2.5.35/kernel/sched.c.orig Mon Sep 16 13:36:59 2002
+++ linux-2.5.35/kernel/sched.c Mon Sep 16 18:39:11 2002
@@ -401,12 +401,10 @@
{
unsigned long flags;
int success = 0;
- long old_state;
runqueue_t *rq;
repeat_lock_task:
rq = task_rq_lock(p, &flags);
- old_state = p->state;
if (!p->array) {
/*
* Fast-migrate the task if it's not running or runnable
@@ -420,7 +418,7 @@
task_rq_unlock(rq, &flags);
goto repeat_lock_task;
}
- if (old_state == TASK_UNINTERRUPTIBLE)
+ if (p->state == TASK_UNINTERRUPTIBLE)
rq->nr_uninterruptible--;
activate_task(p, rq);
@@ -977,12 +975,13 @@
if (unlikely(!rq->nr_running)) {
#if CONFIG_SMP
load_balance(rq, 1);
- if (rq->nr_running)
- goto pick_next_task;
+ if (!rq->nr_running)
#endif
- next = rq->idle;
- rq->expired_timestamp = 0;
- goto switch_tasks;
+ {
+ next = rq->idle;
+ rq->expired_timestamp = 0;
+ goto switch_tasks;
+ }
}
array = rq->active;
--- linux-2.5.35/kernel/signal.c.orig Mon Sep 16 19:31:23 2002
+++ linux-2.5.35/kernel/signal.c Mon Sep 16 19:32:53 2002
@@ -783,7 +783,7 @@
recalc_sigpending_tsk(t);
spin_unlock_irqrestore(&t->sigmask_lock, flags);
- return send_sig_info(sig, (void *)1, t);
+ return send_sig_info(sig, info, t);
}
static int
^ permalink raw reply
* Kernel Panic (2.4.19-release) at sched.c:566
From: Yaroslav Popovitch @ 2002-09-16 17:14 UTC (permalink / raw)
To: linux-kernel
I prepared boot kernel for cdboot image and got such error message.
Schelduling in interrupt
kernel BUG at sched.c:566!
invalid operand: 0000
CPU: 0
EIP: 0010:[<c0116f59>] Not tainted
EFLAGS: 00010296
eax: 00000018 ebx: c0106c70 ecx: 00000001 edx: 00000001
esi: 00000000 edi: c0242000 ebp: c0243fd4 esp: c0243fac
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, stackpage=c0243000)
Stack: c01fed7e 00098700 c0105000 c0242000 00000000 00000000 00000018
c0106c70
00098700 c0105000 0008e000 c0106d04 00000000 c0244687 c01f6f40
00003ffc
00003ffc 00003ffc 00003ffc c0264440 c01001c9
Call Trace: [<c0105000>] [<c0106c70>] [<c0105000>] [<c0106d04>]
Code: 0f 0b 36 02 76 ed 1f c0 5b e9 87 fb ff ff 0f 0b 2f 02 76 ed
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
--
Mr. Yaroslav Popovitch - tel. +372 6419975
SOT Finnish Software Engineering Ltd. - fax +372 6419876
Kreutzwaldi 7-4, 10124 TALLINN - http://www.sot.com/
ESTONIA - http://sotlinux.net/
^ permalink raw reply
* Re: Reserved Blocks
From: Russell Coker @ 2002-09-16 15:44 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: Sam Vilain, 'reiserfs-list'
In-Reply-To: <200209161535.g8GFZYM4004165@turing-police.cc.vt.edu>
On Mon, 16 Sep 2002 17:35, Valdis.Kletnieks@vt.edu wrote:
> On Mon, 16 Sep 2002 17:13:52 +0200, Russell Coker said:
> > Alternately use quotas, speaking of which, do Quotas work on ReiserFS
> > without additional patches yet? Quotas really are an essential feature.
>
> Quotas are a Good Thing - but note that quite often you get into the
> situation where you want to "overcommit" a partition (for instance, 2G of
> disk, and 10 users each of which have a 500M limit). It helps, but you're
> still open to attacks by collusion (intentional, accidental, or by
> hijacking 3 other userids to help).
Group quotas should help that. Put all the untrusted users in a group that
has a quota which is small enough to not allow any damage.
> Ahh, both are very nice, but alas, neither is part of the base kernel yet.
LSM will be part of the base kernel soon, the code merge has already
started... Whether SE Linux and OpenWall get included is still up for
discussion. But that's OK, once LSM is in the base kernel it'll be trivial
to add SE Linux (no more patch conflicts).
--
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page
^ permalink raw reply
* Re: 64-bit and N32 kernel interfaces
From: Ralf Baechle @ 2002-09-16 15:40 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <20020916150152.A1677@linux-mips.org>
On Mon, Sep 16, 2002 at 03:01:52PM +0200, Ralf Baechle wrote:
More chainswing ...
> > As first think I want to get rid of all the historic crap we have in
> > our syscall tables for the 64-bit syscalls. Let's start here:
> >
> > #define __NR_syscall (__NR_Linux + 0)
> >
> > Deprecated because can be implemented in userspace.
> >
> > #define __NR_ioperm (__NR_Linux + 101)
> > #define __NR_iopl (__NR_Linux + 110)
> > #define __NR_vm86 (__NR_Linux + 113)
> >
> > i386 braindamage we're never going to support. So why have it in our
> > syscall table?
> >
> > #define __NR_unused59 (__NR_Linux + 59)
> > #define __NR_reserved82 (__NR_Linux + 82)
> > #define __NR_unused109 (__NR_Linux + 109)
> > #define __NR_unused150 (__NR_Linux + 150)
> >
> > Unused entries. Why keep them ...
> >
> > #define __NR_break (__NR_Linux + 17)
> > #define __NR_stty (__NR_Linux + 31)
> > #define __NR_gtty (__NR_Linux + 32)
> > #define __NR_ftime (__NR_Linux + 35)
> > #define __NR_prof (__NR_Linux + 44)
> > #define __NR_signal (__NR_Linux + 48)
> > #define __NR_mpx (__NR_Linux + 56)
> > #define __NR_ulimit (__NR_Linux + 58)
> > #define __NR_readdir (__NR_Linux + 89)
> > #define __NR_profil (__NR_Linux + 98)
> > #define __NR_modify_ldt (__NR_Linux + 123)
>
> One more for the same cathegory:
>
> #define __NR_lock (__NR_Linux + 53)
>
> > Slots that data back to day one of UNIX way before Linux was born.
> >
> > #define __NR_socketcall (__NR_Linux + 102)
> >
> > Wrapper syscall, obsoleted since quite a while in the 32-bit kernel.
> >
> > #define __NR_idle (__NR_Linux + 112)
> >
> > Internal syscall, no longer used.
> >
> > #define __NR_ipc (__NR_Linux + 117)
>
> This implies eleven new entries for:
>
> __NR_semget
> __NR_semop
> __NR_semctl
> __NR_msgget
> __NR_msgsnd
> __NR_msgrcv
> __NR_msgctl
> __NR_shmget
> __NR_shmat
> __NR_shmdt
> __NR_shmctl
>
> > Yet another multiplexor syscall and imho another candidate for getting
> > rid of.
> >
> > #define __NR_oldstat (__NR_Linux + 18)
> > #define __NR_umount (__NR_Linux + 22)
> > #define __NR_oldfstat (__NR_Linux + 28)
> > #define __NR_oldlstat (__NR_Linux + 84)
> >
> > Superseeded by newer versions.
> >
> > #define __NR_uselib (__NR_Linux + 86)
> >
> > a.out support. Do we really want that.
> >
> > I probably missed a few. The primary purpose of this posting is to get a
> > discussion about the 64-bit syscall interface started. It's still not
> > cast into stone so we can modify it as we see fit. The entire syscall
> > interface is still open for changes, this includes all structures etc.
> > Along with a 64-bit ABI we'll also have to deciede about a N32 ABI.
llseek, pread64/pwrite64, getdent64 are no longer needed as their standard
counterparts are already 64 bit.
Modern libc doesn't use the old style signal calls __NR_sigaction,
__NR_sigsuspend, __NR_sigpending, __NR_sigprocmask. That means
__NR_sigreturn can also go.
__NR_sgetmask and __NR_ssetmask are only capable of dealing with signal masks
of at most bitsof(long) and thus have become useless and replaced by
sigprocmask(2).
__NR_waitpid can be implemented on top of wait(2).
__NR_stime can be implemented on top of settimeofday(2).
__NR_nice can be implemented on top of getpriority / setpriority and was
a stupid interface anyway.
__NR_recv can be implemented on recvfrom(2) and __NR_send using sendfrom(2).
Ralf
^ permalink raw reply
* Re: Oops in sched.c on PPro SMP
From: Andrea Arcangeli @ 2002-09-16 15:44 UTC (permalink / raw)
To: Alan Cox; +Cc: Peter Waechtler, linux-kernel, mingo
In-Reply-To: <1032187767.1191.16.camel@irongate.swansea.linux.org.uk>
On Mon, Sep 16, 2002 at 03:49:27PM +0100, Alan Cox wrote:
> Also does turning off the nmi watchdog junk make the box stable ?
good idea, I didn't though about this one since I only heard the nmi to
lockup hard boxes after hours of load, never to generate any
malfunction, but certainly the nmi handling isn't probably one of the
most exercised hardware paths in the cpus, so it's a good idea to
reproduce with it turned off (OTOH I guess you probably turned it on
explicitly only after you got these troubles, in order to debug them).
Andrea
^ permalink raw reply
* Re: Oops in sched.c on PPro SMP
From: Andrea Arcangeli @ 2002-09-16 15:42 UTC (permalink / raw)
To: Peter Waechtler; +Cc: linux-kernel, mingo
In-Reply-To: <174178B9-C980-11D6-8873-00039387C942@mac.com>
On Mon, Sep 16, 2002 at 04:25:03PM +0200, Peter Waechtler wrote:
> Process setiathome (pid: 2035, stackpage=c45d3000)
^^^^^^^^^^ stress the cpu
> 651: 81 f9 00 00 00 00 cmp $0x0,%ecx
^^^^^^^^^^^^^^^^^
> 657: 74 26 je 67f <schedule+0x26f>
> 659: bb 14 00 00 00 mov $0x14,%ebx
> 65e: 89 f6 mov %esi,%esi
> p->counter = (p->counter >> 1) + NICE_TO_TICKS(p->nice);
> 660: 8b 51 20 mov 0x20(%ecx),%edx <= CRASH
> 663: d1 fa sar %edx
> 665: 89 d8 mov %ebx,%eax
> 667: 2b 41 24 sub 0x24(%ecx),%eax
> 66a: c1 f8 02 sar $0x2,%eax
> 66d: 8d 54 10 01 lea 0x1(%eax,%edx,1),%edx
> 671: 89 51 20 mov %edx,0x20(%ecx)
> 674: 8b 49 48 mov 0x48(%ecx),%ecx
> 677: 81 f9 00 00 00 00 cmp $0x0,%ecx
^^^^^^^^^^^^^^^^
> 67d: 75 e1 jne 660 <schedule+0x250>
> read_unlock(&tasklist_lock);
> 67f: f0 ff 05 00 00 00 00 lock incl 0x0
> spin_lock_irq(&runqueue_lock);
> 686: fa cli
as you said apparently ecx cannot be zero. But I bet the 0x00 really is
waiting relocation at link time. that shouldn't be zero infact, it
should be the address of the init_task (&init_task).
Can you disassemble the .o object using objdump -Dr or can you disassemble such
piece of code from the vmlinux instead of compiling with the -S flag to
verify that to verify that? If it really checks against zero then it's a
miscompilation, it should check against &init_task as said above.
> First I thought the readlocks were broken by the compiler, due
> to syntax changes. But staring at the code I wondered how
> %ecx can become zero at 660: - from this code it's impossible!
> But wait: we allowed interrupts again...
>
> So my explanation is as follows: the scheduler is interrupted
> and entry.S calls:
interrupts cannot clobber %ecx or change the tasklist, if they clobber
%ecx or modify the tasklist that would be the real bug.
> So there are 2 possibilities: the spin_unlock_irq(&runqueue_lock)
> is wrong in the scheduler, but this should be noted by more SMP
> users then, or the CONFIG_X86_PPRO_FENCE does not work as expected.
the PPRO_FENCE is strictier than the non FENCE one. However here the
corruption you notice is in the tasklist, and the read/write locks are
not affected by the FENCE option, so FENCE isn't likely to explain it.
If something I would suspect something wrong in the read/write
spinlocks, to rule out such possibility you could for example try to
replace all the read_lock and write_lock around the tasklist with
spin_lock_irqsave/spin_lock_irqrestore. So that you would use the FENCE
xchg functionality around the tasklist too and you would also make sure
that no irq can happen in between, just to be 100% sure that if it
crashes it's because the memory is corrupted somehow. But really, the
read/write locks just use the lock on the bus when they modify the
spinlock value so I'd be *very* surprised if that doesn't work on ppro.
The non-FENCE case of recent cpus is used to skip the lock on the bus
during the unlock operation to exploit the release semantics of all
writes to memory in writeback cache mode of the recent x86 (that allows
unrelated speculative reads outside the critical section to enter
inside).
I really suspect an hardware fault here, if you could reproduce easily
you could try to drop a dimm of ram and retest, you can also try memtst
from cerberus testsuite or/and memtest86 from the lilo menu.
the tasklist walking very likely is triggering very quick cacheline
bouncing and lots of ram I/O, 99% of hardware bugs triggers while
walking lists because of the cpu-dcache trashing and the ram cannot cope
with it. Probably the O1 scheduler would hide the problem because it
drops such tight loop. Note that the 2.4.18 SuSE kernel scheduler
algorithm is O(N) where N is always the number of running tasks, never the
total number of tasks in the system, while in mainline the scheduler is
O(N) where N is the total number of tasks in the system, this mean
normally in mainline you can walk a list with 100/500 elements, while
with the SuSE kernel you'll walk a list of always around 2/3 elements,
depends on the workload of course. The O1 scheduler included in 8.1
reduces N to a constant 1. So if you cannot reproduce with the SuSE 8.0
kernel could be simply because you've lots of tasks in your system but
only a few of them runs at the same time. That's a dramatic optimization
in the SuSE kernel but it's not a bugfix, it only hides the corruption
in your case methinks, like the O1 scheduler in 8.1 will hide it even
better, even if you have lots of tasks running at the same time ;). It
is true to walk the runqueue we need the runqueue_lock that needs irq
disabled, but regardless irqs must not screwup anything in the tasklist.
So I would say, it's either an hardware issue, or random memory
corruption generated by some driver. Just some guesses. And if it's the
irq clobbering the %ecx or the tasklist then something is very wrong in
the irq code or in the hardware (I'd exclude such possibility, but you
can try adding _irq to the read_lock/read_unlock of the tasklist_lock to
disable irq and see if you can still reproduce). If %ecx is checked
against zero as well something is very wrong, but in the compiler, and
that would explain things too (you're recommended to use either 2.95 or
3.2).
Hope this helps,
Andrea
^ permalink raw reply
* Re: Reserved Blocks
From: Valdis.Kletnieks @ 2002-09-16 15:35 UTC (permalink / raw)
To: Russell Coker; +Cc: Sam Vilain, 'reiserfs-list'
In-Reply-To: <200209161713.52352.russell@coker.com.au>
[-- Attachment #1: Type: text/plain, Size: 1388 bytes --]
On Mon, 16 Sep 2002 17:13:52 +0200, Russell Coker said:
> Alternately use quotas, speaking of which, do Quotas work on ReiserFS without
> additional patches yet? Quotas really are an essential feature.
Quotas are a Good Thing - but note that quite often you get into the
situation where you want to "overcommit" a partition (for instance, 2G of
disk, and 10 users each of which have a 500M limit). It helps, but you're
still open to attacks by collusion (intentional, accidental, or by hijacking
3 other userids to help).
> Solar Designer's OpenWall kernel patch addresses this issue by prohibiting
....
> Also the LSM patch includes NSA Security enhanced Linux. In the default SE
> Linux policy a user in the default un-priviledged role (user_r) with the
> defalt security domain for that role (user_t) will not be allowed to even
Ahh, both are very nice, but alas, neither is part of the base kernel yet.
> A machine with an adequate security setup and with correctly configured quotas
> should be able to operate correctly with hostile local users even if it only
> has a single file system.
Granted. However, my point was that I've never seen a Unixoid system that was
safe to run with only one big partition without extensive kernel hacking to
make it safe. I'll be more than happy to change my stance as soon as SELinux
ships as part of the base system ;)
/Valdis
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Architecture Documentation
From: Chuck Winters @ 2002-09-16 15:34 UTC (permalink / raw)
To: alsa-devel
Is there any "big picture" architectural documentation on alsa?
Chuck
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
^ 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.