* Re: [PATCH]: unaligned
From: Juan Quintela @ 2002-12-19 13:57 UTC (permalink / raw)
To: Ralf Baechle; +Cc: mipslist
In-Reply-To: <20021219143115.A24914@linux-mips.org>
>>>>> "ralf" == Ralf Baechle <ralf@linux-mips.org> writes:
ralf> On Thu, Dec 19, 2002 at 11:40:38AM +0100, Juan Quintela wrote:
>> - asm wants a unsigned long
>> - verify_area wants a void *
>> one of the two places need a cast.
ralf> Making emulate_load_store take a void * as the address argument was much
ralf> nicer instead.
I didn't wanted to touch asm() parts yet :)
>> Once there, ralf? forgot that emulate_load_store returns void, then
>> nuke the return 1 part.
ralf> Already did that.
nice.
Later, Juan.
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
^ permalink raw reply
* Re: raidtools-20010914
From: Derek Vadala @ 2002-12-19 13:51 UTC (permalink / raw)
To: linux-raid; +Cc: =?X-UNKNOWN?Q?Jarmo_J=E4rvenp=E4=E4?=
In-Reply-To: <3E01CBD8.6A18B88F@softers.net>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 784 bytes --]
On Thu, 19 Dec 2002, Jarmo [iso-8859-1] Järvenpää wrote:
> - 3 RAID 1 devices with each having 2 partitions mirrored together.
> - Kernel 2.4.20
There are some known issues with this release of raidtools. Avoid using
it. Either revert to the previous version, or move up to 1.0 (available as
a REdHat 8.0 rpm or source rpm). Does anyone know if the tar file for
raidtools-1.0 is floating around yet?
Don't use raidhotgenerateerror. Use raidsetfaulty to mark a disk as
failed.
Or, use mdadm.
--
Derek Vadala, derek@cynicism.com, http://www.cynicism.com/~derek
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 2.4.21-pre2 RESEND] CREDITS update
From: Stelian Pop @ 2002-12-19 13:59 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Marcelo Tosatti
Hi,
This patch updates my current CREDITS entry.
Marcelo, please apply.
Stelian.
===== CREDITS 1.63 vs edited =====
--- 1.63/CREDITS Mon Dec 16 07:22:25 2002
+++ edited/CREDITS Thu Dec 19 09:38:27 2002
@@ -2404,13 +2404,10 @@
D: CDROM driver "sonycd535" (Sony CDU-535/531)
N: Stelian Pop
-E: stelian.pop@fr.alcove.com
+E: stelian@popies.net
P: 1024D/EDBB6147 7B36 0E07 04BC 11DC A7A0 D3F7 7185 9E7A EDBB 6147
D: sonypi, meye drivers, mct_u232 usb serial hacks
-S: Alcôve
-S: 153, bd. Anatole France
-S: 93200 Saint Denis
-S: France
+S: Paris, France
N: Frederic Potter
E: fpotter@cirpack.com
--
Stelian Pop <stelian@popies.net>
^ permalink raw reply
* Re: [PATCH]: unaligned
From: Ralf Baechle @ 2002-12-19 13:53 UTC (permalink / raw)
To: Juan Quintela; +Cc: mipslist
In-Reply-To: <m27ke6jemo.fsf@demo.mitica>
On Thu, Dec 19, 2002 at 02:57:03PM +0100, Juan Quintela wrote:
> ralf> Making emulate_load_store take a void * as the address argument was much
> ralf> nicer instead.
>
> I didn't wanted to touch asm() parts yet :)
No need to touch them. My patch was just a two line change to unaligned.c.
Ralf
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Shuji YAMAMURA @ 2002-12-19 14:03 UTC (permalink / raw)
To: linux-kernel; +Cc: Linus Torvalds
In-Reply-To: <Pine.LNX.4.44.0212162211110.1810-100000@home.transmeta.com>
Hi,
We've measured gettimeofday() cost on both of Xeon and P3, too.
We also measured them on different kernels (UP and MP).
Xeon(2GHz) P3(1GHz)
=========================================
UP kernel 939[ns] 441[ns]
1878[cycles] 441[cycles]
-----------------------------------------
MP kernel 1054[ns] 485[ns]
2108[cycles] 485[cycles]
-----------------------------------------
(The kernel version is 2.4.18)
In this experiment, Xeon is two times slower than P3, despite that the
frequency of the Xeon is two times faster. More over, the performance
difference between UP and MP is very interesting in Xeon case. The
difference of Xeon (230 cycles) is five times larger than that of P3
(44 cycles).
We think that the instructions with lock prefix in the MP kernel
damage the Xeon performance which serialize operations in an execution
pipeline. On the P4/Xeon systems, these lock operations should be
avoided as possible as we can.
The following web page shows the details of this experiment.
http://www.labs.fujitsu.com/en/techinfo/linux/lse-0211/index.html
Regards
At Mon, 16 Dec 2002 22:18:27 -0800 (PST),
Linus wrote:
> On Mon, 16 Dec 2002, Linus Torvalds wrote:
> >
> > For gettimeofday(), the results on my P4 are:
> >
> > sysenter: 1280.425844 cycles
> > int/iret: 2415.698224 cycles
> > 1135.272380 cycles diff
> > factor 1.886637
> >
> > ie sysenter makes that system call almost twice as fast.
>
> Final comparison for the evening: a PIII looks very different, since the
> system call overhead is much smaller to begin with. On a PIII, the above
> ends up looking like
>
> gettimeofday() testing:
> sysenter: 561.697236 cycles
> int/iret: 686.170463 cycles
> 124.473227 cycles diff
> factor 1.221602
-----
Shuji Yamamura (yamamura@flab.fujitsu.co.jp)
Grid Computing & Bioinformatics Laboratory
Information Technology Core Laboratories
Fujitsu Laboratories LTD.
^ permalink raw reply
* Re: [PATCH] An O1, nonrecursive ID allocator for Posix timers
From: Joe Korty @ 2002-12-19 14:08 UTC (permalink / raw)
To: george anzinger; +Cc: Joe Korty, akpm, torvalds, jim.houston, linux-kernel
In-Reply-To: <3E00ED8A.B63B8A9D@mvista.com>
>> This is a drop-in replacement for the ID allocator that Jim Houston
>> wrote to support posix timers. [...]
>
> A few comments:
>
> I have found that the locking needs on lookup require that
> the object be locked before the id-look-up is unlocked.
> With out this it is possible to find an object and have it
> "removed" by another prior to getting it locked. This is
> why, in my version, the lock is exported.
Hi George,
Ouch. I completely missed this API flaw. Good catch.
Some ideas: rather than exporting the lock, we could replace
int id2ptr_lookup(...)
with a
int id2ptr_get(...)
void id2ptr_put(...)
pair. id2ptr_get() would do the old id2ptr_lookup semantics plus
bump a use-count on the ID. id2ptr_put() would decrement the
use-count and delete the ID if the use-count became zero.
id2ptr_new() and id2ptr_remove() would need similar use-count
adjustments.
Or, a callback capability could be added to the API. The callback
function would be registered by a new argument to id2ptr_init() and
called by id2ptr_lookup() before it dropped the lock. In this case,
we would change id2ptr_init to look like:
void id2ptr_init(struct id *id, int min_wrap, void (*func)(void *data));
where the callback function is defined to take one argument, the
(void *) value attached to the ID. You (&Jim) would use this
callback mechanism to provide a function that would lock down the
data structure represented by the (void *) passed-in argument.
> Another issue with locking is the irq required or not thing. Irq
> locking is VERY expensive and getting more so as cpu speeds go up and
> I/O speeds stay the same. If it is not needed, it is best not to use
> it. Again, exporting the locking to the caller seems the best answer.
IIRC, it is the spin_lock_* part that is expensive, not the *_irq part.
Interrupt locking is merely setting/clearing a bit in the EFLAGS
register, which (if the i386 follows the PowerPC pattern, the CPU I
am most familiar with), is slower than setting/clearing a bit in a
general purpose register but not that much slower.
On the other hand, the bus locking of spin_lock_* stops all other cpus
and dma traffic from accessing the bus for the interval of the lock,
this can be devastating on systems with large numbers of cpus and/or
high IO traffic. However, this is not a problem on all architectures.
The PowerPC, for one, provides a pair of instructions which one can
implement spin_lock without utilizing a bus lock. I look forward to
the day Intel adds a similiar pair of instructions to their ISA.
In any case, all of the ID user interfaces have exactly one lock and
one unlock along their most commonly executed patch. One can't get
any better than that without resorting to architecture tricks like
assuming reads and writes go out to memory in a certain order.
> I would much prefer to return memory on release. In my code
> I currently only return the leaf nodes, but I consider this
> something to be fixed rather than a feature.
I have an adjustment in mind which would allow the O(1) ID allocator
to return excess memory. Each ID block would do its own little free
list and those lists in turn would be chained together. That way it
would be easy to kfree() an ID block once it became completely full
of freed IDs.
> While the code is order 1 it does do a divide which, as I
> understand it, is rather expensive (risc machines do them
> with subroutines). It is rather easy to eliminate the
> recursion in an radix-tree AND avoid the div at the same
> time.
I will make this change. Thanks.
> I would consider moving the "ctr" member to the root of the
> tree and using the same one for all allocations. I may be
> wrong here, but I think it gives a better cycle time for the
> bits used.
A random value works just as well (actually a little better) than a
counter that is not unique to each ID data structure. I may go the
(pseudo) random route & eliminate the ctr altogether. Or I may be
able to find some unused bits in the ID data structure where I can
pack it in.
Thanks for your feedback,
Joe
^ permalink raw reply
* Re: Domain transition -- enabling user_r in eklogin
From: Jesse Pollard @ 2002-12-19 14:02 UTC (permalink / raw)
To: Russell Coker, Brian May; +Cc: SELinux
In-Reply-To: <200212191051.19213.russell@coker.com.au>
On Thursday 19 December 2002 03:51 am, Russell Coker wrote:
> On Wed, 18 Dec 2002 23:27, Brian May wrote:
> > On Wed, Dec 18, 2002 at 08:45:22AM +0100, Russell Coker wrote:
[-snip]
>
> One significant disadvantage is that a hacked sshd could run "newrole -r
> sysadm_r" and get that access (and this can be extended to other programs
> with a similar situation).
>
> Of course if you allow someone the ability to transition to a role with
> less capabilities than their default role, and then denied them the ability
> to run the newrole program while in that role it might have some potential.
>
> > > Also I think that in most situations where a user could be tricked into
> > > running newrole then it's game-over anyway.
> >
> > OK. I was thinking more of scripts, etc.
>
> It's the same thing. If I can trick you into running some arbitary
> commands with your main role then I can get your ssh identity key and your
> gpg secret key. These crypto keys are often worth more than the hardware
> that they are stored on...
Only if access is permitted to be over an unsecured channel.
The differentation between a local user and a remote user has to be provided.
Access to the secret key(s) probably should not be permitted from an
unsecured location/connection. This does require network labels to work.
Currently, as long as the Kerberos tickets have IP addresses embeded, the
TGT cannot be used on any system other than the host that generated them.
This restriction is frequently broken due to things like firwalls/NAT which do
not permit host IP identity to cross their boundary. I'm used to thinking of
these things with MLS, using multiple levels.. If the user connects over a
network, then the ticket cache should be labeled at the level of the
connection. Any lower level connection would not have access. If the user
then starts netscape, then netscape should be labeled at a lower access (or be
isolated via compartment) from the ticket cache. Any process that netscape
starts would also be created at that "lower" level. This includes things like
pgp keys. Only a trusted application should have access to them.
It does mean that the plugin for checking PGP signatures (at a minimum the
one for generating signatures) would have to be sufficiently separate from
the netscape process to be labeled separately. It could not use loadable
modules, for instance. It also means any scripts started should not have
access either.
This is not a 100% solution - If netscape is used to download an application,
then the user proceeds to configure/compile/run then all bets are off since
the users actions are overriding the labels. It should/could prevent a trojan
from passing the files out though - it would not be authorized access to the
secret key(s) or the Kerberos ticket cache. Only trusted utilities would have
that capability.
--
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Problems with pci or maybe io-apic... who knows...
From: Samuele Kaplun @ 2002-12-19 14:06 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
[-- Attachment #1: Type: text/plain, Size: 838 bytes --]
Hello everybody...
I patched my kernel with the latest patches set of Con Kolivas porting my acpi
subsystem to revision 20021122
With the new system of acpi I encounter some problems with my harddisk, which
eventually caused it to hang...
I think it's an irq problems but I don't know anything about this world... I
attach my dmesg report...
The lines which make me worry are:
[...]
ACPI-0511: *** Info: GPE Block0 defined as GPE0 to GPE15
[...]
PCI: No IRQ known for interrupt pin A of device 00:11.1 - using IRQ 255
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even
'acpi=off'
[...]
PCI: No IRQ known for interrupt pin A of device 00:11.1 - using IRQ 255
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even
'acpi=off'
[...]
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: dmesg.log --]
[-- Type: text/x-log; charset="us-ascii"; name="dmesg.log", Size: 14103 bytes --]
Linux version 2.4.20-ck2 (root@localhost) (gcc version 3.2.1) #1 Thu Dec 19 14:26:14 CET 2002
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000d0000 - 00000000000d6000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001fff0000 (usable)
BIOS-e820: 000000001fff0000 - 000000001fff8000 (ACPI data)
BIOS-e820: 000000001fff8000 - 0000000020000000 (ACPI NVS)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000fffc0000 - 0000000100000000 (reserved)
511MB LOWMEM available.
ACPI: have wakeup address 0xc0001000
found SMP MP-table at 000fb9e0
hm, page 000fb000 reserved twice.
hm, page 000fc000 reserved twice.
hm, page 000f6000 reserved twice.
hm, page 000f7000 reserved twice.
On node 0 totalpages: 131056
zone(0): 4096 pages.
zone(1): 126960 pages.
zone(2): 0 pages.
ACPI: RSDP (v000 AMI ) @ 0x000fa7b0
ACPI: RSDT (v001 AMIINT AMIINI09 00000.00016) @ 0x1fff0000
ACPI: FADT (v001 AMIINT AMIINI09 00000.00017) @ 0x1fff0030
ACPI: MADT (v001 AMIINT AMIINI09 00000.00017) @ 0x1fff00c0
ACPI: DSDT (v001 VIA VIA_K7 00000.04096) @ 0x00000000
ACPI: BIOS passes blacklist
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 Pentium(tm) Pro APIC version 16
ACPI: IOAPIC (id[0x02] address[0xfec00000] global_irq_base[0x0])
IOAPIC[0]: Assigned apic_id 2
IOAPIC[0]: apic_id 2, version 2, address 0xfec00000, IRQ 0-23
ACPI: INT_SRC_OVR (bus[0] irq[0x0] global_irq[0x2] polarity[0x0] trigger[0x0])
ACPI: INT_SRC_OVR (bus[0] irq[0x9] global_irq[0x9] polarity[0x3] trigger[0x3])
Using ACPI (MADT) for SMP configuration information
Kernel command line: BOOT_IMAGE=New ro root=306
Initializing CPU#0
Detected 1733.697 MHz processor.
Console: colour dummy device 80x25
Calibrating delay loop... 3416.06 BogoMIPS
Memory: 516140k/524224k available (1249k kernel code, 7696k reserved, 417k data, 116k init, 0k highmem)
Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
Inode cache hash table entries: 32768 (order: 6, 262144 bytes)
Mount-cache hash table entries: 8192 (order: 4, 65536 bytes)
Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes)
Page-cache hash table entries: 131072 (order: 7, 524288 bytes)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After generic, caps: 0383fbff c1c3fbff 00000000 00000000
CPU: Common caps: 0383fbff c1c3fbff 00000000 00000000
CPU: AMD Athlon(tm) XP 2100+ stepping 02
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000080
ESR value after enabling vector: 00000000
ENABLING IO-APIC IRQs
init IO_APIC IRQs
IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected.
..TIMER: vector=0x31 pin1=2 pin2=0
number of MP IRQ sources: 16.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................
IO APIC #2......
.... register #00: 02000000
....... : physical APIC id: 02
.... register #01: 00178002
....... : max redirection entries: 0017
....... : PRQ implemented: 1
....... : IO APIC version: 0002
WARNING: unexpected IO-APIC, please mail
to linux-smp-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 000 00 1 0 0 0 0 0 0 00
01 001 01 0 0 0 0 0 1 1 39
02 001 01 0 0 0 0 0 1 1 31
03 001 01 0 0 0 0 0 1 1 41
04 001 01 0 0 0 0 0 1 1 49
05 001 01 0 0 0 0 0 1 1 51
06 001 01 0 0 0 0 0 1 1 59
07 001 01 0 0 0 0 0 1 1 61
08 001 01 0 0 0 0 0 1 1 69
09 001 01 1 1 0 1 0 1 1 71
0a 001 01 0 0 0 0 0 1 1 79
0b 001 01 0 0 0 0 0 1 1 81
0c 001 01 0 0 0 0 0 1 1 89
0d 001 01 0 0 0 0 0 1 1 91
0e 001 01 0 0 0 0 0 1 1 99
0f 001 01 0 0 0 0 0 1 1 A1
10 000 00 1 0 0 0 0 0 0 00
11 000 00 1 0 0 0 0 0 0 00
12 000 00 1 0 0 0 0 0 0 00
13 000 00 1 0 0 0 0 0 0 00
14 000 00 1 0 0 0 0 0 0 00
15 000 00 1 0 0 0 0 0 0 00
16 000 00 1 0 0 0 0 0 0 00
17 000 00 1 0 0 0 0 0 0 00
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ5 -> 0:5
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ10 -> 0:10
IRQ11 -> 0:11
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
.................................... done.
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 1733.0103 MHz.
..... host bus clock speed is 266.0631 MHz.
cpu: 0, clocks: 266631, slice: 133315
CPU0<T0:266624,T1:133296,D:13,S:133315,C:266631>
mtrr: v1.40 (20010327) Richard Gooch (rgooch-r1x6VkxMR+00zabcByZE4g@public.gmane.org)
mtrr: detected mtrr type: Intel
ACPI: Subsystem revision 20021122
PCI: PCI BIOS revision 2.10 entry at 0xfdb31, last bus=1
PCI: Using configuration type 1
ACPI-0511: *** Info: GPE Block0 defined as GPE0 to GPE15
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: System [ACPI] (supports S0 S1 S4 S5)
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: Power Resource [URP1] (off)
ACPI: Power Resource [URP2] (off)
ACPI: Power Resource [FDDP] (off)
ACPI: Power Resource [LPTP] (off)
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *10 11 12 14 15)
PCI: Probing PCI hardware
IOAPIC[0]: Set PCI routing entry (2-16 -> 0xa9 -> IRQ 16)
00:00:01[A] -> 2-16 -> IRQ 16
IOAPIC[0]: Set PCI routing entry (2-17 -> 0xb1 -> IRQ 17)
00:00:01[B] -> 2-17 -> IRQ 17
IOAPIC[0]: Set PCI routing entry (2-22 -> 0xb9 -> IRQ 22)
00:00:11[C] -> 2-22 -> IRQ 22
IOAPIC[0]: Set PCI routing entry (2-21 -> 0xc1 -> IRQ 21)
00:00:11[D] -> 2-21 -> IRQ 21
Pin 2-17 already programmed
IOAPIC[0]: Set PCI routing entry (2-18 -> 0xc9 -> IRQ 18)
00:00:09[B] -> 2-18 -> IRQ 18
IOAPIC[0]: Set PCI routing entry (2-19 -> 0xd1 -> IRQ 19)
00:00:09[C] -> 2-19 -> IRQ 19
Pin 2-16 already programmed
Pin 2-18 already programmed
Pin 2-19 already programmed
Pin 2-16 already programmed
Pin 2-17 already programmed
Pin 2-19 already programmed
Pin 2-16 already programmed
Pin 2-17 already programmed
Pin 2-18 already programmed
Pin 2-16 already programmed
Pin 2-17 already programmed
Pin 2-18 already programmed
Pin 2-19 already programmed
Pin 2-17 already programmed
Pin 2-18 already programmed
Pin 2-19 already programmed
Pin 2-16 already programmed
Pin 2-17 already programmed
Pin 2-18 already programmed
Pin 2-16 already programmed
Pin 2-17 already programmed
Pin 2-18 already programmed
Pin 2-19 already programmed
Pin 2-16 already programmed
Pin 2-17 already programmed
Pin 2-18 already programmed
Pin 2-19 already programmed
PCI: No IRQ known for interrupt pin A of device 00:11.1 - using IRQ 255
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off'
PCI: Via IRQ fixup for 00:11.2, from 10 to 5
PCI: Via IRQ fixup for 00:11.3, from 10 to 5
PCI: Via IRQ fixup for 00:14.0, from 11 to 0
PCI: Via IRQ fixup for 00:14.1, from 10 to 1
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Compressed Cache: 0.24pre5
Compressed Cache: maximum size
Compressed Cache: 32764 pages = 262112KiB
Compressed Cache: hash table
Compressed Cache: fragment (1024 entries = 4096B)
Compressed Cache: free space (42 entries = 168B)
Compressed Cache: total free space (42 entries = 168B)
Compressed Cache: compression algorithm: LZO
Compressed Cache: adaptivity
Compressed Cache: clean page (4096 entries = 16384B)
Journalled Block Device driver loaded
devfs: v1.12c (20020818) Richard Gooch (rgooch-r1x6VkxMR+00zabcByZE4g@public.gmane.org)
devfs: boot_options: 0x1
vesafb: framebuffer at 0xd0000000, mapped to 0xe080b000, size 65536k
vesafb: mode is 1024x768x8, linelength=1024, pages=84
vesafb: protected mode interface info at c000:5584
vesafb: scrolling: redraw
Console: switching to colour frame buffer device 128x48
fb0: VESA VGA frame buffer device
pty: 256 Unix98 ptys configured
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 89
PCI: No IRQ known for interrupt pin A of device 00:11.1 - using IRQ 255
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt8233a (rev 00) IDE UDMA133 controller on pci00:11.1
ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:DMA, hdd:DMA
hda: MAXTOR 6L040J2, ATA DISK drive
hdc: _NEC DV-5800B, ATAPI CD/DVD-ROM drive
hdd: _NEC CD-RW NR-9100A, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
blk: queue c02edd04, I/O limit 4095Mb (mask 0xffffffff)
hda: 78177792 sectors (40027 MB) w/1818KiB Cache, CHS=4866/255/63, UDMA(133)
Partition check:
/dev/ide/host0/bus0/target0/lun0: p1 p2 < p5 p6 > p3
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 32768 bind 65536)
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Mounted devfs on /dev
Freeing unused kernel memory: 116k freed
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Adding Swap: 530104k swap-space (priority -1)
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,6), internal journal
SCSI subsystem driver Revision: 1.00
hdc: ATAPI 48X DVD-ROM drive, 512kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
hdd: ATAPI 40X CD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
inserting floppy driver for 2.4.20-ck2
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Real Time Clock Driver v1.10e
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
hcd.c: ehci-hcd @ 00:14.2, VIA Technologies, Inc. USB 2.0
hcd.c: irq 18, pci mem e48c1f00
usb.c: new USB bus registered, assigned bus number 1
ehci-hcd.c: USB 2.0 support enabled, EHCI rev 0.95
hub.c: USB hub found
hub.c: 4 ports detected
usb-uhci.c: $Revision: 1.275 $ time 14:34:21 Dec 19 2002
usb-uhci.c: High bandwidth mode enabled
usb-uhci.c: USB UHCI at I/O 0xe000, IRQ 21
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 2
hub.c: USB hub found
hub.c: 2 ports detected
usb-uhci.c: USB UHCI at I/O 0xdc00, IRQ 21
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 3
hub.c: USB hub found
hub.c: 2 ports detected
usb-uhci.c: USB UHCI at I/O 0xd800, IRQ 16
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 4
hub.c: USB hub found
hub.c: 2 ports detected
usb-uhci.c: USB UHCI at I/O 0xd400, IRQ 17
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 5
hub.c: USB hub found
hub.c: 2 ports detected
usb-uhci.c: v1.275:USB Universal Host Controller Interface driver
hub.c: new USB device 00:11.2-1, assigned address 2
usb.c: USB device 2 (vend/prod 0x46d/0xc00e) is not claimed by any active driver.
ip_tables: (C) 2000-2002 Netfilter core team
ip_conntrack version 2.1 (4095 buckets, 32760 max) - 292 bytes per conntrack
hub.c: new USB device 00:11.2-2, assigned address 3
usb.c: USB device 3 (vend/prod 0x5a9/0xa511) is not claimed by any active driver.
hub.c: new USB device 00:11.3-1, assigned address 2
usb.c: USB device 2 (vend/prod 0x4a9/0x220d) is not claimed by any active driver.
usb.c: registered new driver hiddev
usb.c: registered new driver hid
input0: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb2:2.0
hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech-AlSwsSmVLrQ@public.gmane.org>
hid-core.c: USB HID support drivers
mice: PS/2 mouse device common for all mice
Linux video capture interface: v1.00
usb.c: registered new driver ov511
ov511.c: USB OV511+ video device found
ov511.c: model: Generic Camera (no ID)
ov511.c: Sensor is an OV7620
ov511.c: Device registered on minor 0
ov511.c: v1.61 for Linux 2.4 : ov511 USB Camera Driver
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE]
parport0: irq 7 detected
lp0: using parport0 (polling).
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
Creative EMU10K1 PCI Audio Driver, version 0.20, 14:33:47 Dec 19 2002
emu10k1: EMU10K1 rev 7 model 0x8064 found, IO at 0xe800-0xe81f, IRQ 19
ac97_codec: AC97 Audio codec, id: ƒ„v8(SigmaTel STAC9708)
emu10k1: SBLive! 5.1 card detected
ISO 9660 Extensions: Microsoft Joliet Level 3
ISO 9660 Extensions: RRIP_1991A
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Jamie Lokier @ 2002-12-19 14:22 UTC (permalink / raw)
To: Dave Jones, bart, torvalds, hpa, terje.eggestad, drepper,
matti.aarnio, hugh, mingo, linux-kernel
In-Reply-To: <20021219133848.GB32524@suse.de>
Dave Jones wrote:
> > Static binaries can just directly jump/call into the magic page.
>
> .. and explode nicely when you try to run them on an older kernel
> without the new syscall magick. This is what Linus' first
> proof-of-concept code did.
<evil-grin>
No, because the static binary installs a SIGSEGV handler to emulate
the magic page on older kernels :)
</evil-grin>
-- Jamie
^ permalink raw reply
* difference between 8139D and 8139d(l)?
From: Samium Gromoff @ 2002-12-19 12:04 UTC (permalink / raw)
To: linux-kernel
Is there any major difference between both?
regards, Samium Gromoff
^ permalink raw reply
* Re: Horrible drive performance under concurrent i/o jobs (dlh problem?)
From: Torben Frey @ 2002-12-19 14:29 UTC (permalink / raw)
To: Andrew Morton; +Cc: Con Kolivas, linux kernel mailing list
Ok, so now I have set up a backup software Raid 0 formatted with
mke2fs -b 4096 -j -R stride=16
and mounted that device. After starting to backup stuff from the 3ware
controller to the software Raid I soon had complaints from my collegues
because the system load went up to 4 and they had the same bad
responsiveness as before. Of course I CTRL-C'ed my "cp -av" while
watching "vmstat 1" in another window - and this is what surprised me:
when I stopped the copy job, there were 22 more seconds when data was
still written to the backup software raid. Is this a hint where the
problem could be? I have the same "feature" when I write to my 3ware.
My kernel is 2.4.20 with Andrew's patch from last night.
Greetings,
Torben
0 1 3 25292 2188 72056 759644 0 0 4168 23732 1069 780 6 26 68
0 1 3 25292 2176 72056 759644 0 0 0 15728 523 147 1 10 89
2 0 4 25292 2292 72056 759548 0 0 30404 20084 820 1149 4 85 11
0 1 3 25292 2828 72048 759012 0 0 40716 23772 845 1307 2 62 36
0 1 2 25292 3208 72280 758372 0 0 0 16532 573 231 6 13 81
1 0 2 25292 3216 72276 758404 0 0 4880 23800 530 264 2 10 88
0 1 3 25292 2224 72224 759420 0 0 22596 15620 695 602 5 38 57
0 1 3 25292 3996 72204 757692 0 0 26704 23808 765 924 3 38 59
1 0 3 25292 3932 72208 757760 0 0 14380 23996 651 548 3 23 74
0 1 3 25292 2180 72296 759408 0 0 39024 15948 850 1089 3 56 41
1 0 3 25292 3180 72308 758416 0 0 39028 17568 957 1265 1 57 42
0 1 2 25292 3296 72260 758328 0 0 36976 24000 837 1194 5 47 49
1 0 2 25292 3212 72264 758428 0 0 6164 22000 594 330 2 15 83
0 1 3 25292 2212 72268 759412 0 0 44492 16116 878 1433 2 63 35
1 0 3 25292 2896 72056 758952 0 0 19180 24556 683 912 1 32 67
0 0 2 25292 3300 72068 758672 0 0 10564 24296 636 518 1 23 76
HERE WAS MY CTRL-C
1 0 2 25292 3292 72068 758672 0 0 0 15820 511 146 1 15 84
0 0 2 25292 3276 72068 758672 0 0 0 27720 607 341 0 46 54
0 0 2 25292 3276 72068 758672 0 0 0 15912 529 167 1 12 87
0 0 2 25292 3232 72112 758672 0 0 0 23880 537 199 5 7 88
0 0 2 25292 3232 72112 758672 0 0 0 15872 558 198 0 8 92
0 0 2 25292 3232 72112 758672 0 0 0 23740 517 168 4 6 90
0 0 2 25292 4620 72112 757320 0 0 0 23800 528 1044 8 12 80
0 0 2 25292 4620 72112 757320 0 0 0 16100 522 177 4 6 90
0 0 2 25292 4516 72216 757320 0 0 0 24268 558 192 2 5 93
0 0 2 25292 4516 72216 757320 0 0 0 23552 525 179 3 2 95
0 0 2 25292 4516 72216 757320 0 0 0 15872 521 137 0 9 91
0 0 2 25292 4516 72216 757320 0 0 0 31924 515 179 4 7 89
0 0 2 25292 4516 72216 757320 0 0 0 17368 526 144 2 2 96
0 0 1 25292 4488 72244 757320 0 0 0 25308 533 195 1 8 91
0 0 1 25292 4488 72244 757320 0 0 0 16368 504 145 3 12 85
0 0 1 25292 4488 72244 757320 0 0 0 25320 558 247 0 28 72
0 0 1 25292 4484 72244 757320 0 0 0 16376 529 187 3 6 91
0 0 1 25292 4484 72244 757320 0 0 0 24576 508 140 1 3 96
0 0 1 25292 4464 72264 757320 0 0 0 24356 523 197 4 5 91
0 0 1 25292 4464 72264 757320 0 0 0 16364 516 148 1 1 98
0 0 1 25292 4464 72264 757320 0 0 0 24552 507 138 2 1 97
0 0 1 25292 4464 72264 757320 0 0 0 21020 522 174 2 17 81
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
0 0 0 25292 4448 72280 757320 0 0 0 656 347 142 0 8 92
0 0 0 25292 4432 72296 757320 0 0 0 796 353 179 4 2 94
HERE THE WRITING OUT STOPPED, 22 seconds later!!!
0 0 0 25292 4432 72296 757320 0 0 0 0 176 141 1 1 98
0 0 0 25292 4432 72296 757320 0 0 0 0 194 184 2 1 97
0 0 0 25292 4432 72296 757320 0 0 0 0 176 137 1 1 98
0 0 0 25292 4432 72296 757320 0 0 0 0 179 175 2 1 97
0 0 0 25292 4292 72312 757328 116 0 124 32 188 165 1 1 98
0 0 0 25292 4292 72312 757328 0 0 0 0 248 310 2 12 86
0 0 0 25292 4292 72312 757328 0 0 0 0 178 148 1 2 97
0 0 0 25292 4292 72312 757328 0 0 0 0 184 144 0 1 99
0 0 0 25292 4292 72312 757328 0 0 0 0 193 185 2 3 95
0 0 0 25292 4272 72332 757328 0 0 0 640 360 200 1 2 97
^ permalink raw reply
* Re: [parisc-linux] quad tulip now not functional in 2.4.20
From: Ryan Bradetich @ 2002-12-19 14:27 UTC (permalink / raw)
To: jsoe0708; +Cc: grundler, Ed Schaller, parisc-linux
In-Reply-To: <3DED9A6600002207@ocpmta3.freegates.net>
Joel,
Just a heads up ... I will not even have a chance to look at this for
a week or two.
Thanks,
- Ryan
On Tue, 2002-12-17 at 23:30, jsoe0708@tiscali.be wrote:
> Hi Grant,
> >
> >On Tue, Dec 17, 2002 at 04:14:10PM +0100, jsoe0708@tiscali.be wrote:
> >> >I will try to revert tulip driver and advise you.
> >> Well I find some minutes to do this reverse and it works.
> >> Still have to find the bug ?
> >
> >Unfortunately yes.
> >But since the diff is small, it's alot easier.
> >
> >I'm most suspicious about the added checks for length field in eeprom.
> >But I'll review the diff again and tinker with it today or tomorrow.
> >I added that thinking that code only gets executed when there is no
> >phy table (eg built-in). But the add-on cards do have a phy table.
> >
> (well it seems I do mistake when sent following info)
> [also because diff is small]
> In eeprom.c I also suspect:
> line 193: if (ee_data[27] == 0 || ee_data[ee_data[27]] == 0) {
>
> which I only reverse into:
> if (ee_data[27] == 0) {
>
> and it works. Unforunately I do not have enough doc to actulay fix the pb.
> May be Ryan could still help us?
>
> Joel
>
> ********************************************************************************
> Controlez mieux votre consommation Internet...surfez Tiscali Complete...http://tiscali.complete.be
>
>
>
>
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: billyrose @ 2002-12-19 14:40 UTC (permalink / raw)
To: root; +Cc: linux-kernel
Richard B. Johnson wrote:
> The target, i.e., the label 'goto' would be the reserved page for the
> system call. The whole purpose was to minimize the number of CPU cycles
> necessary to call 0xfffff000 and return. The system call does not have
> issue a 'far' return, it can do anything it requires. The page at
> 0xfffff000 is mapped into every process and is in that process CS space
> already.
that being the case, why push %cs and reload it without reason as the
code is mapped into every process?
therefore, would it not suffice to use:
...
long_call(); //call to $0xfffff000 via near ret
//code at $0xfffff000 returns directly here when a ret is issued
...
long_call:
pushl $0xfffff000
ret
^ permalink raw reply
* ACPI with P4 mainboard
From: Margit Schubert-While @ 2002-12-19 14:33 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Hi,
MB = D845PESVL with 2.4Ghz P4 (Latest BIOS - Nov 1)
Below apply to both 2.4.20 + ACPI 20021205 and
2.5.52
1) Didn't think that a P4 < 3.06Ghz had HT :-)
<6>ACPI: Processor [CPU1] (supports C1, 8 throttling states)
<6>ACPI: Processor [CPU2] (supports C1, 8 throttling states)
2) There is nothing in "fan" and "thermal_zone". I suspect that the DSDT
lacks this info.
Andrew ?
Cheers
Margit
-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: bart @ 2002-12-19 14:57 UTC (permalink / raw)
To: billyrose; +Cc: root, linux-kernel
On 19 Dec, billyrose@billyrose.net wrote:
> long_call:
> pushl $0xfffff000
> ret
>
A ret(urn) to an address that wasn't put on the stack by a call
severly confuses the branch prediction on many processors.
--
Bart Hartgers - TUE Eindhoven
http://plasimo.phys.tue.nl/bart/contact.html
^ permalink raw reply
* pb compiling cross gcc, binutils, glibc and so on ...
From: BREUVART Jean-Charles @ 2002-12-19 14:52 UTC (permalink / raw)
To: 'linuxppc-embedded@lists.linuxppc.org'
Hello world !
I'm trying to create a cdk, the host is a PIII runnning RedHat 8.0 (kernel
2.4.18), and the target is GNU kernel 2.4.20 running on a PPC755B
proprietary board. I've read lots of HOWTOs but I haven't succeeded yet !!!
RedHat 8.0 comes with gcc 3.2, binutils 2.13.90.0.2, make 3.79.1, I don't
know how to get the libc version ...
One told me that gcc 3.2 wasn't a nice version to create a cross-compiler
(actually, I've tried and this seems to be true), so I've downloaded from
www.gnu.org the following :
- gcc-2.95.3.tar.gz and gcc-core-2.95.3.tar.gz
- binutils-2.13.90.0.4.tar.gz and binutils-2.12.90.0.7.tar.gz
- glibc-2.3.tar.gz and glibc-linuxthreads-2.3.tar.gz
- make-3.80.tar.gz
- linux-src-2.4.20.tar.gz
I' succeeded in building a native gcc 2.95.3 and make 3.8, and used them to
create the famous Hello world C program, actually all that stuff works. But
I still remain to encounter pb while creating the cdk !!!
here is what I did :
1. restrict $PATH to /sbin:/bin:/usr/sbin:/usr/bin
2. build a native gcc core 2.95.3 from scratch in /usr/src/gcc-2.95.3/ dir,
and install it in /usr/local/ (the default) :
- cd /usr/src/gcc-2.95.3/
- make clean
- make distclean
- ./configure --enable-languages=c,c++ ; this uses my RedHat
distribution's cc, which link to gcc
- make bootstrap
- make install
3 build make 3.80 in /usr/src/make-3.80/ dir, and install it in /usr/local/
(the default) :
- cd /usr/src/make-3.80/
- make clean
- make distclean
- CC=/usr/local/bin/gcc ./configure (I don't know if it's better to
use gcc 2.95.3 or gcc 3.2, however, this uses RedHat distribution's binutils
!)
- make
- make install
4. build binutils 2.12.90.0.7 for powerpc cross compile, and install it in
/opt/powerpc-linux/ :
- cd /usr/src/binutils
- make clean
- make distclean
- CC=/usr/local/bin/gcc ./configure --target=powerpc-linux
--enable-shared --with-newlib --prefix=/opt/powerpc-linux (I still don't
know if it's better to use gcc 2.95.3 or gcc 3.2)
- make
- make install
5. build gcc core 2.95.3 for powerpc cross compile, and install it in
/opt/powerpc-linux/ :
- cd /usr/src/gcc-2.95.3/
- make clean
- make distclean
- CC=/usr/local/bin/gcc ./configure --target=powerpc-linux
--enable-shared --enable-languages=c --with-newlib
--prefix=/opt/powerpc-linux
- add /opt/powerpc-linux at the end of $PATH, otherwise make doesn't
find powerpc-linux-as, powerpc-linux-ld and so on
- make
Here is the trouble :
choose-temp.c:29: stdio.h: Aucun fichier ou r?pertoire de ce type
choose-temp.c:30: sys/types.h: Aucun fichier ou r?pertoire de ce type
choose-temp.c:32: unistd.h: Aucun fichier ou r?pertoire de ce type
choose-temp.c:35: stdlib.h: Aucun fichier ou r?pertoire de ce type
choose-temp.c:38: sys/file.h: Aucun fichier ou r?pertoire de ce type
there aren't any of those in /opt/powerpc-linux/ or its subdirs
this the same trouble I had when I tried to build directly a cross gcc
2.95.2 for powerpc-linux with my RedHat distribution's gcc and binutils ...
So here are my questions :
- did anyone do that before ?
- does a pre-compiled version of such a cross dev toolsets already exists
for x86-pc-linux or sparc-sun ? I heard about "ELDK"
by Wolfgang Denk
- is what I did wrong ?
- where should the cross gcc build process search for those headers ? How
to indicate it ?
- must I use native binutils or cross binutils to build a cross gcc ?
- to build the bin utilities, including binutils, for the embedded linux
kernel's filesystem that will run on the PPC755B, I think I'll use the cross
gcc to build them from their source code ? I think that the one build in 4.
won't run, they only run on my host ?
if needed, I can change my host and use a Sun Workstation runnning SunOS
5.5.1 ...
So thanks in advance.
Regards,
Jean-Charles Breuvart
This e-mail is intended only for the above addressee. It may contain
privileged information. If you are not the addressee you must not copy,
distribute, disclose or use any of the information in it. If you have
received it in error please delete it and immediately notify the sender.
Security Notice: all e-mail, sent to or from this address, may be
accessed by someone other than the recipient, for system management and
security reasons. This access is controlled under Regulation of
Investigatory Powers Act 2000, Lawful Business Practises.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [PATCH 2.4] : donauboe IrDA driver (resend)
From: Dumitru Ciobarcianu @ 2002-12-19 15:05 UTC (permalink / raw)
To: jt; +Cc: Marcelo Tosatti, Linux kernel mailing list
In-Reply-To: <20021219024632.GB1746@bougret.hpl.hp.com>
[-- Attachment #1: Type: text/plain, Size: 4912 bytes --]
Hello,
This module does not load all the time for me.
If I do an "modprobe donauboe" it gives something like:
TX: (144,80) (144,84) (144,80) (144,84) (0,00) (0,00) (0,00) (0,00)
[9600]
RRTSRRT 4181
RX: (130,00) (130,00) (130,00) (130,00) (0,80) (0,80) (0,80) (0,80)
TX: (144,80) (144,84) (144,80) (144,84) (0,00) (0,00) (0,00) (0,00)
[115200]
RRTSRRT 4117
RX: (130,00) (130,00) (130,00) (130,00) (0,80) (0,80) (0,80) (0,80)
TX: (128,84) (128,90) (128,84) (128,b4) (0,00) (0,00) (0,00) (0,00)
[4000000]
TSRTSTR 3861
RX: (264,00) (264,20) (0,80) (0,80) (0,80) (0,80) (0,80) (0,80)
TX: (128,84) (128,90) (128,84) (128,b4) (0,00) (0,00) (0,00) (0,00)
[1152000]
TSTST<3>toshoboeprobe(1152000) failed filter test
toshoboe: Register dump:
Interrupts: Tx:203 Rx:0 TxUnder:0 RxOver:0 Sip:0
RX 00 TX 44 RingBase 0f355c00
RING_SIZE 11 IER ff ISR 07
CONFIG1 08 STATUS 00
CONFIG0 4ea0 ENABLE 937c
NEW_PCONFIG 0101 CURR_PCONFIG 0101
MAXLEN 0c04 RXCOUNT 0100
Ring at 0f355c00:
RX: (0,80) (0,80) (0,80) (0,80) (0,80) (0,80) (0,80) (0,80)
TX: (128,00) (128,00) (128,00) (128,00) (0,00) (0,00) (0,00) (0,00)
If I try a few more times it will finally load...
The kernel is 2.4.20.0.pp.9 (RH rawhide kernel - 2.4.20-ac1 based) +
acpi20021205 . I don't know why lspci shows "Toshiba Tecra 8100". The
machine is an Toshiba Satellite Pro 4320.
Output of lspci:
00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge
(rev 03)
Subsystem: Toshiba America Info Systems Toshiba Tecra 8100 Laptop
System Chipset
Flags: bus master, medium devsel, latency 64
Memory at d0000000 (32-bit, prefetchable) [size=256M]
Capabilities: <available only to root>
00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge
(rev 03) (prog-if 00 [Normal decode])
Flags: bus master, 66Mhz, medium devsel, latency 64
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
Memory behind bridge: f0000000-f7ffffff
00:05.0 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
Flags: bus master, medium devsel, latency 0
00:05.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01)
(prog-if 80 [Master])
Flags: bus master, medium devsel, latency 64
I/O ports at fff0 [size=16]
00:05.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01)
(prog-if 00 [UHCI])
Flags: bus master, medium devsel, latency 64, IRQ 11
I/O ports at ff80 [size=32]
00:05.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 03)
Flags: medium devsel, IRQ 9
00:07.0 Communication controller: Lucent Microelectronics 56k WinModem
(rev 01)
Subsystem: Toshiba America Info Systems Internal V.90 Modem
Flags: bus master, medium devsel, latency 0, IRQ 3
Memory at ffefff00 (32-bit, non-prefetchable) [size=256]
I/O ports at 02f8 [size=8]
I/O ports at 1c00 [size=256]
Capabilities: <available only to root>
00:09.0 IRDA controller: Toshiba America Info Systems FIR Port Type-DO
Subsystem: Toshiba America Info Systems FIR Port Type-DO
Flags: slow devsel, IRQ 11
I/O ports at ff60 [size=32]
Capabilities: <available only to root>
00:0b.0 CardBus bridge: Toshiba America Info Systems ToPIC95 (rev 07)
Subsystem: Toshiba America Info Systems: Unknown device 0001
Flags: bus master, slow devsel, latency 168, IRQ 11
Memory at 10000000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=14, subordinate=14, sec-latency=0
Memory window 0: 10400000-107ff000 (prefetchable)
Memory window 1: 10800000-10bff000
I/O window 0: 00004000-000040ff
I/O window 1: 00004400-000044ff
16-bit legacy interface ports at 0001
00:0b.1 CardBus bridge: Toshiba America Info Systems ToPIC95 (rev 07)
Subsystem: Toshiba America Info Systems: Unknown device 0001
Flags: bus master, slow devsel, latency 168, IRQ 11
Memory at 10001000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=15, subordinate=15, sec-latency=0
Memory window 0: 10c00000-10fff000 (prefetchable)
Memory window 1: 11000000-113ff000
I/O window 0: 00004800-000048ff
I/O window 1: 00004c00-00004cff
16-bit legacy interface ports at 0001
00:0c.0 Multimedia audio controller: Yamaha Corporation YMF-744B [DS-1S
Audio Controller] (rev 02)
Subsystem: Toshiba America Info Systems: Unknown device 0001
Flags: bus master, medium devsel, latency 64, IRQ 11
Memory at efff8000 (32-bit, non-prefetchable) [size=32K]
I/O ports at ff00 [size=64]
I/O ports at fefc [size=4]
Capabilities: <available only to root>
01:00.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV (rev
11) (prog-if 00 [VGA])
Subsystem: Toshiba America Info Systems: Unknown device 0001
Flags: bus master, 66Mhz, medium devsel, latency 248, IRQ 11
Memory at f0000000 (32-bit, non-prefetchable) [size=128M]
Expansion ROM at 000c0000 [disabled] [size=64K]
Capabilities: <available only to root>
--
Cioby
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: 823 Video Controller Driver - where ?
From: Wolfgang Denk @ 2002-12-19 14:55 UTC (permalink / raw)
To: Steven Blakeslee; +Cc: 'Embedded Linux PPC List'
In-Reply-To: <D73A25AA6E54D511AD74009027B1110F3C04F5@ORION>
In message <D73A25AA6E54D511AD74009027B1110F3C04F5@ORION> you wrote:
> Actually I found lcd823.c and lcdvideo.h in arch/ppc/8xx_io of your
> linux-2.4.4-2002-03-21 :)
But lcd823.c / lcdvideo.h is - as the name "lcd..." suggests - a
driver for the LCD controller of the MPC823 CPU; it does not support
the video controller - and this was what the OP asked for: a driver
for the _video_ controller.
I think there once was such a beast, probably in
ftp://ftp.mvista.com/pub/Area51/embedded-planet/video.tgz
Maybe you happen to know if this is still available somewhere?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
If A equals success, then the formula is A = X + Y + Z. X is work. Y
is play. Z is keep your mouth shut. - Albert Einstein
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* STB04500 - smart card readers support?
From: Honza Petrous @ 2002-12-19 14:55 UTC (permalink / raw)
To: Embedded Linux PPC List
Hi,
I'm pretty new in embeded environment, so sorry
if my question is rather stupid.
It seems that IBM provides development info
only for their customers and so I'm not able
to get some info how the STB04500's smart
card reader controllers should be programmed.
I would like to develop such driver if it
already doesn't exist. I tried to find some
info about support of STB04500 in kernel
tree but found only support for serial
ports and ethernet card.
Can somebody point me to right source
for some docs?
I must note, that I'm a freetime programmer,
so subscription is no way for me :(
With regards.
/Honza Petrous.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* RE: problem using jffs2 on DiskOnChip
From: Carl Wolff @ 2002-12-19 15:29 UTC (permalink / raw)
To: 'David Woodhouse', wolff; +Cc: linux-mtd, vanee
In-Reply-To: <12900.1040292850@passion.cambridge.redhat.com>
Hello David,
OK. Two questions:
1) Does JFFS2 actually work on a DiskOnChip?
2) Other alternatives? We need a powersafe filesystem on DiskOnChip.
Thanks, and happy newyear, I'm going on holiday now.
Carl.
> -----Original Message-----
> From: David Woodhouse [mailto:dwmw2@redhat.com]On Behalf Of David
> Woodhouse
> Sent: donderdag 19 december 2002 11:14
> To: wolff@turnkiek.nl
> Cc: linux-mtd@lists.infradead.org
> Subject: Re: problem using jffs2 on DiskOnChip
>
>
>
> wolff@turnkiek.nl said:
> > Short read: 0x10 bytes at 0x000001f0 instead of requested 44
>
> The DiskOnChip hardware driver hasn't been used much with
> anything other
> than NFTL. It appears not to do a full read if you ask it to
> read a range
> of data which crosses a page boundary. Fix it accordingly by
> putting an
> appropriate loop in instead of...
>
> /* Don't allow a single read to cross a 512-byte
> block boundary */
> if (from + len > ((from | 0x1ff) + 1))
> len = ((from | 0x1ff) + 1) - from;
>
> --
> dwmw2
>
>
>
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Richard B. Johnson @ 2002-12-19 15:11 UTC (permalink / raw)
To: billyrose; +Cc: linux-kernel
In-Reply-To: <1040308834.3e01da62a8761@209.51.155.18>
On Thu, 19 Dec 2002 billyrose@billyrose.net wrote:
> Richard B. Johnson wrote:
>
> > The target, i.e., the label 'goto' would be the reserved page for the
> > system call. The whole purpose was to minimize the number of CPU cycles
> > necessary to call 0xfffff000 and return. The system call does not have
> > issue a 'far' return, it can do anything it requires. The page at
> > 0xfffff000 is mapped into every process and is in that process CS space
> > already.
>
> that being the case, why push %cs and reload it without reason as the
> code is mapped into every process?
>
> therefore, would it not suffice to use:
>
> ...
> long_call(); //call to $0xfffff000 via near ret
> //code at $0xfffff000 returns directly here when a ret is issued
> ...
>
> long_call:
> pushl $0xfffff000
> ret
>
Because the number pushed onto the stack is a displacement, not
an address, i.e., -4095. To have the address act as an address,
you need to load a full-pointer, i.e. SEG:OFFSET (like the old
16-bit days). The offset is 32-bits and the segment is whatever
the kernel has set up for __USER_CS (0x23). All the 'near' calls
are calls to a signed displacement, same for jumps.
It would be nice if you could just do call $0xfffff000,
the problem is that the 'call' expects a displacement, usually
determined (fixed-up) by the linker. So, in this case, you
end up calling some code that exists 4095 bytes before the
call instruction NotGood(tm).
So the whole idea of this exercise is to do the same thing as
call far ptr 0x23:0xfffff000 (Intel syntax), without
reguiring a fixup, but minimizing the instructions and disruption
due to reloading a segment.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
^ permalink raw reply
* Re: Via KT400
From: BoehmeSilvio @ 2002-12-19 15:11 UTC (permalink / raw)
To: 'Dave Jones'; +Cc: linux-kernel
Hi Dave,
just to inform you:
I have requested the KT400 agp specs from VIA.
I'll receive the docs in 1-2 days.
As far as i have the docs, I can help you with on the VIA AGP 3 issue.
My state:
- found a 2.4.20-rc? patch for the Intel 7505 with agp 3 support.
- copied via_generic_setup to via_kt400_setup and modified it to
agp3
- waiting for the via specs
By
Silvio
-----Ursprüngliche Nachricht-----
Von: Dave Jones [mailto:davej@codemonkey.org.uk]
Gesendet: Donnerstag, 19. Dezember 2002 11:43
An: Courtney Grimland
Cc: Tupshin Harper; linux-kernel@vger.kernel.org
Betreff: Re: Via KT400
On Wed, Dec 18, 2002 at 11:26:53PM -0600, Courtney Grimland wrote:
> I have the 7VAXP. I only had problems with AGP and sound, and using
> 2.4.20-ac2 absolutely everything on this board works (finally -
> sound!). AGP worked in 2.4.20-ac1 as well as 2.4.21-pre1. I think
> the the IDE issue was resolved in 2.4.20.
The AGP only works if the chipset is in 2.0 compatability mode.
Luckily some BIOSen out there seem to do that if a 2.0 card is present.
If you have an AGP 3.0 card in there you're shit out of luck right now.
I'm working on it..
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
-
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
* PROBLEM: devfs related oops
From: dino klein @ 2002-12-19 15:09 UTC (permalink / raw)
To: linux-kernel
[1.] I got the following while fdisk was writing a new partition table, and
resyncing
[3.] devfs, kernel
[4.] I'm running 2.5.52bk3
[5.]===============================================
ksymoops 2.4.8 on i686 2.5.52bk3. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.5.52bk3/ (default)
-m /boot/System.map-2.5.52bk3 (specified)
Error (regular_file): read_ksyms stat /proc/ksyms failed
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
kernel BUG at fs/devfs/base.c:1630!
invalid operand: 0000
CPU: 1
EIP: 0060:[<c01a884b>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: 0000000d ebx: f7d6111c ecx: 00000000 edx: c02e5f00
esi: f7d5d95c edi: 00000001 ebp: ebda9f10 esp: ebda9ef8
ds: 0068 es: 0068 ss: 0068
Stack: c02950a0 c0295080 c02954e4 f7d6111c 5a5a5a5a f7d4e000 ebda9f20
c0180c26
f7d6111c f7d5d95c ebda9f58 c0180e8a f7da5cc4 00000001 f7d5d974
f7d5d95c
ec4cd6d0 ebda9f7c ebda9f7c 000c5445 00000000 ebda9f64 00000000
ebda9f7c
Call Trace:
[<c0180c26>] delete_partition+0x5e/0x6c
[<c0180e8a>] rescan_partitions+0x5e/0x138
[<c0209630>] blkdev_reread_part+0x5c/0x78
[<c0209a56>] blkdev_ioctl+0x26a/0x38b
[<c015c14d>] sys_ioctl+0x22d/0x298
[<c01090ff>] syscall_call+0x7/0xb
Code: 0f 0b 5e 06 ae 50 29 c0 83 c4 14 83 7b 28 00 74 57 f6 05 70
>>EIP; c01a884b <devfs_unregister+33/a0> <=====
>>edx; c02e5f00 <abi_table+e4/134>
Trace; c0180c26 <delete_partition+5e/6c>
Trace; c0180e8a <rescan_partitions+5e/138>
Trace; c0209630 <blkdev_reread_part+5c/78>
Trace; c0209a56 <blkdev_ioctl+26a/38b>
Trace; c015c14d <sys_ioctl+22d/298>
Trace; c01090ff <syscall_call+7/b>
Code; c01a884b <devfs_unregister+33/a0>
00000000 <_EIP>:
Code; c01a884b <devfs_unregister+33/a0> <=====
0: 0f 0b ud2a <=====
Code; c01a884d <devfs_unregister+35/a0>
2: 5e pop %esi
Code; c01a884e <devfs_unregister+36/a0>
3: 06 push %es
Code; c01a884f <devfs_unregister+37/a0>
4: ae scas %es:(%edi),%al
Code; c01a8850 <devfs_unregister+38/a0>
5: 50 push %eax
Code; c01a8851 <devfs_unregister+39/a0>
6: 29 c0 sub %eax,%eax
Code; c01a8853 <devfs_unregister+3b/a0>
8: 83 c4 14 add $0x14,%esp
Code; c01a8856 <devfs_unregister+3e/a0>
b: 83 7b 28 00 cmpl $0x0,0x28(%ebx)
Code; c01a885a <devfs_unregister+42/a0>
f: 74 57 je 68 <_EIP+0x68> c01a88b3
<devfs_unregister+9b/a0>
Code; c01a885c <devfs_unregister+44/a0>
11: f6 05 70 00 00 00 00 testb $0x0,0x70
1 error issued. Results may not be reliable.
==============================================
[7.1]==============================================
Linux debian 2.5.52bk3 #2 SMP Wed Dec 18 09:56:48 EST 2002 i686 unknown
Gnu C 2.95.4
Gnu make 3.79.1
util-linux 2.11n
mount 2.11n
modutils 2.4.15
e2fsprogs 1.27
PPP 2.4.1
Linux C Library 2.2.5
Dynamic linker (ldd) 2.2.5
Procps 2.0.7
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 2.0.11
Modules Loaded
=========================================
[7.7] bellow is the output of dmesg.
served)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
127MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 000f5700
hm, page 000f5000 reserved twice.
hm, page 000f6000 reserved twice.
hm, page 000f1000 reserved twice.
hm, page 000f2000 reserved twice.
On node 0 totalpages: 262128
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 225280 pages, LIFO batch:16
HighMem zone: 32752 pages, LIFO batch:7
ACPI: RSDP (v000 VIA694 ) @ 0x000f7050
ACPI: RSDT (v001 VIA694 AWRDACPI 16944.11825) @ 0x3fff3000
ACPI: FADT (v001 VIA694 AWRDACPI 16944.11825) @ 0x3fff3040
ACPI: MADT (v001 VIA694 00000.00000) @ 0x3fff5640
ACPI: DSDT (v001 VIA694 AWRDACPI 00000.04096) @ 0x00000000
ACPI: BIOS passes blacklist
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 6:8 APIC version 16
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1 6:8 APIC version 16
ACPI: IOAPIC (id[0x02] address[0xfec00000] global_irq_base[0x0])
IOAPIC[0]: Assigned apic_id 2
IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, IRQ 0-23
ACPI: INT_SRC_OVR (bus[0] irq[0x0] global_irq[0x2] polarity[0x0]
trigger[0x0])
ACPI: INT_SRC_OVR (bus[0] irq[0x9] global_irq[0x9] polarity[0x0]
trigger[0x0])
Using ACPI (MADT) for SMP configuration information
Building zonelist for node : 0
Kernel command line: BOOT_IMAGE=2552 ro root=1603
root=/dev/discs/disc2/part3
Initializing CPU#0
Detected 864.980 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1703.93 BogoMIPS
Memory: 1034456k/1048512k available (1499k kernel code, 13136k reserved,
675k data, 272k init, 131008k highmem)
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
-> /dev
-> /dev/console
-> /root
CPU: Before vendor init, caps: 0383fbff 00000000 00000000, vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU: After vendor init, caps: 0383fbff 00000000 00000000 00000000
CPU: After generic, caps: 0383fbff 00000000 00000000 00000000
CPU: Common caps: 0383fbff 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
Checking for popad bug... OK.
POSIX conformance testing by UNIFIX
CPU0: Intel Pentium III (Coppermine) stepping 06
per-CPU timeslice cutoff: 731.64 usecs.
task migration cache decay timeout: 1 msecs.
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Booting processor 1/1 eip 2000
Initializing CPU#1
masked ExtINT on CPU#1
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Calibrating delay loop... 1728.51 BogoMIPS
CPU: Before vendor init, caps: 0383fbff 00000000 00000000, vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU: After vendor init, caps: 0383fbff 00000000 00000000 00000000
CPU: After generic, caps: 0383fbff 00000000 00000000 00000000
CPU: Common caps: 0383fbff 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel Pentium III (Coppermine) stepping 06
Total of 2 processors activated (3432.44 BogoMIPS).
ENABLING IO-APIC IRQs
init IO_APIC IRQs
IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not
connected.
..TIMER: vector=0x31 pin1=2 pin2=0
number of MP IRQ sources: 16.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................
IO APIC #2......
.... register #00: 02000000
....... : physical APIC id: 02
....... : Delivery Type: 0
....... : LTS : 0
.... register #01: 00178011
....... : max redirection entries: 0017
....... : PRQ implemented: 1
....... : IO APIC version: 0011
.... register #02: 00000000
....... : arbitration: 00
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 000 00 1 0 0 0 0 0 0 00
01 001 01 0 0 0 0 0 1 1 39
02 001 01 0 0 0 0 0 1 1 31
03 001 01 0 0 0 0 0 1 1 41
04 001 01 0 0 0 0 0 1 1 49
05 001 01 0 0 0 0 0 1 1 51
06 001 01 0 0 0 0 0 1 1 59
07 001 01 0 0 0 0 0 1 1 61
08 001 01 0 0 0 0 0 1 1 69
09 001 01 0 0 0 0 0 1 1 71
0a 001 01 0 0 0 0 0 1 1 79
0b 001 01 0 0 0 0 0 1 1 81
0c 001 01 0 0 0 0 0 1 1 89
0d 001 01 0 0 0 0 0 1 1 91
0e 001 01 0 0 0 0 0 1 1 99
0f 001 01 0 0 0 0 0 1 1 A1
10 000 00 1 0 0 0 0 0 0 00
11 000 00 1 0 0 0 0 0 0 00
12 000 00 1 0 0 0 0 0 0 00
13 000 00 1 0 0 0 0 0 0 00
14 000 00 1 0 0 0 0 0 0 00
15 000 00 1 0 0 0 0 0 0 00
16 000 00 1 0 0 0 0 0 0 00
17 000 00 1 0 0 0 0 0 0 00
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ5 -> 0:5
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ10 -> 0:10
IRQ11 -> 0:11
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
.................................... done.
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 865.0114 MHz.
..... host bus clock speed is 133.0094 MHz.
checking TSC synchronization across 2 CPUs: passed.
Starting migration thread for cpu 0
Bringing up 1
CPU 1 IS NOW UP!
Starting migration thread for cpu 1
CPUS done 2
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
mtrr: v2.0 (20020519)
mtrr: your CPUs had inconsistent fixed MTRR settings
mtrr: your CPUs had inconsistent variable MTRR settings
mtrr: probably your BIOS does not setup all CPUs
device class 'cpu': registering
device class cpu: adding driver system:cpu
PCI: PCI BIOS revision 2.10 entry at 0xfb370, last bus=1
PCI: Using configuration type 1
device class cpu: adding device CPU 0
interfaces: adding device CPU 0
device class cpu: adding device CPU 1
interfaces: adding device CPU 1
BIO: pool of 256 setup, 15Kb (60 bytes/bio)
biovec pool[0]: 1 bvecs: 256 entries (12 bytes)
biovec pool[1]: 4 bvecs: 256 entries (48 bytes)
biovec pool[2]: 16 bvecs: 256 entries (192 bytes)
biovec pool[3]: 64 bvecs: 256 entries (768 bytes)
biovec pool[4]: 128 bvecs: 256 entries (1536 bytes)
biovec pool[5]: 256 bvecs: 256 entries (3072 bytes)
ACPI: Subsystem revision 20021217
tbxface-0098 [03] acpi_load_tables : ACPI Tables successfully acquired
Parsing all Control
Methods:......................................................................
Table [DSDT] - 303 Objects with 30 Devices 70 Methods 19 Regions
ACPI Namespace successfully loaded at root c039f9bc
evxfevnt-0073 [04] acpi_enable : Transition to ACPI mode
successful
evgpe-0262: *** Info: GPE Block0 defined as GPE0 to GPE15
Executing all Device _STA and_INI methods:..............................
30 Devices found containing: 30 _STA, 1 _INI methods
Completing Region/Field/Buffer/Package
initialization:........................................
Initialized 15/19 Regions 1/1 Fields 15/15 Buffers 9/9 Packages (303 nodes)
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
pci_bind-0191 [04] acpi_pci_bind : Device 00:00:07.05 not present in
PCI namespace
pci_bind-0191 [04] acpi_pci_bind : Device 00:00:07.06 not present in
PCI namespace
ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 11 *12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 *5 6 7 10 11 12 14 15)
Linux Plug and Play Support v0.93 (c) Adam Belay
pnp: the driver 'system' has been registered
pnp: Enabling Plug and Play Card Services.
block request queues:
128 requests per read queue
128 requests per write queue
8 requests per batch
enter congestion at 31
exit congestion at 33
IOAPIC[0]: Set PCI routing entry (2-16 -> 0xa9 -> IRQ 16)
00:00:09[A] -> 2-16 -> IRQ 16
IOAPIC[0]: Set PCI routing entry (2-17 -> 0xb1 -> IRQ 17)
00:00:09[B] -> 2-17 -> IRQ 17
IOAPIC[0]: Set PCI routing entry (2-18 -> 0xb9 -> IRQ 18)
00:00:09[C] -> 2-18 -> IRQ 18
IOAPIC[0]: Set PCI routing entry (2-19 -> 0xc1 -> IRQ 19)
00:00:09[D] -> 2-19 -> IRQ 19
Pin 2-17 already programmed
Pin 2-19 already programmed
Pin 2-18 already programmed
Pin 2-16 already programmed
Pin 2-17 already programmed
Pin 2-16 already programmed
Pin 2-19 already programmed
Pin 2-18 already programmed
Pin 2-19 already programmed
Pin 2-16 already programmed
Pin 2-17 already programmed
Pin 2-18 already programmed
Pin 2-18 already programmed
Pin 2-19 already programmed
Pin 2-16 already programmed
Pin 2-17 already programmed
Pin 2-18 already programmed
Pin 2-19 already programmed
Pin 2-16 already programmed
Pin 2-17 already programmed
Pin 2-16 already programmed
Pin 2-17 already programmed
Pin 2-18 already programmed
Pin 2-19 already programmed
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even
'acpi=off'
Enabling SEP on CPU 0
Enabling SEP on CPU 1
highmem bounce pool size: 64 pages
aio_setup: sizeof(struct page) = 40
VFS: Disk quotas vdquot_6.5.1
Journalled Block Device driver loaded
devfs: v1.22 (20021013) Richard Gooch (rgooch@atnf.csiro.au)
devfs: devfs_debug: 0x0
devfs: boot_options: 0x0
PCI: Enabling Via external APIC routing
ACPI: Power Button (FF) [PWRF]
ACPI: Processor [CPU] (supports C1)
ACPI: Processor [CPU1] (supports C1)
pty: 256 Unix98 ptys configured
Real Time Clock Driver v1.11
loop: loaded (max 8 devices)
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
00:0b.0: 3Com PCI 3c905C Tornado at 0xcc00. Vers LK1.1.18
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 00:07.1
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1
ide0: BM-DMA at 0xc000-0xc007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xc008-0xc00f, BIOS settings: hdc:DMA, hdd:DMA
hda: QUANTUM FIREBALLP AS40.0, ATA DISK drive
hdb: Maxtor 52049U4, ATA DISK drive
hda: DMA disabled
hdb: DMA disabled
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: WDC WD800BB-40BSA0, ATA DISK drive
hdd: IBM-DAQA-33240, ATA DISK drive
hdc: DMA disabled
hdd: DMA disabled
ide1 at 0x170-0x177,0x376 on irq 15
hda: host protected area => 1
hda: 80315072 sectors (41121 MB) w/1902KiB Cache, CHS=79677/16/63
/dev/ide/host0/bus0/target0/lun0: p1
hdb: host protected area => 1
hdb: 39882528 sectors (20420 MB) w/2048KiB Cache, CHS=39566/16/63
/dev/ide/host0/bus0/target1/lun0: p1 p2
hdc: host protected area => 1
hdc: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=155061/16/63
/dev/ide/host0/bus1/target0/lun0: p1 p2 p3 p4
hdd: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
hdd: task_no_data_intr: error=0x04 { DriveStatusError }
hdd: 6346368 sectors (3249 MB) w/96KiB Cache, CHS=6296/16/63
/dev/ide/host0/bus1/target1/lun0: p1 p2
device class 'input': registering
serio: i8042 AUX port at 0x60,0x64 irq 12
input: AT Set 2 keyboard on isa0060/serio0
serio: i8042 KBD port at 0x60,0x64 irq 1
NET4: Linux TCP/IP 1.0 for NET4.0
IP: routing cache hash table of 4096 buckets, 64Kbytes
TCP: Hash tables configured (established 131072 bind 43690)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
(fs/jbd/recovery.c, 253): journal_recover: JBD: recovery, exit status 0,
recovered transactions 5910 to 5928
(fs/jbd/recovery.c, 255): journal_recover: JBD: Replayed 1386 and revoked
0/0 blocks
kjournald starting. Commit interval 5 seconds
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with journal data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 272k freed
Adding 999928k swap on /dev/hdc4. Priority:-1 extents:1
EXT3 FS 2.4-0.9.16, 02 Dec 2001 on ide1(22,3), internal journal
(fs/jbd/recovery.c, 253): journal_recover: JBD: recovery, exit status 0,
recovered transactions 5074 to 5577
(fs/jbd/recovery.c, 255): journal_recover: JBD: Replayed 40710 and revoked
0/0 blocks
kjournald starting. Commit interval 5 seconds
EXT3 FS 2.4-0.9.16, 02 Dec 2001 on ide1(22,1), external journal on
ide1(22,2)
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with journal data mode.
blk: queue c03a8c20, I/O limit 4095Mb (mask 0xffffffff)
blk: queue c03a8e88, I/O limit 4095Mb (mask 0xffffffff)
/dev/ide/host0/bus1/target1/lun0: p1 p2
devfs_unregister(f7d6111c): bad magic value: 5a5a5a5a
Forcing Oops
------------[ cut here ]------------
kernel BUG at fs/devfs/base.c:1630!
invalid operand: 0000
CPU: 1
EIP: 0060:[<c01a884b>] Not tainted
EFLAGS: 00010286
EIP is at devfs_unregister+0x33/0xa0
eax: 0000000d ebx: f7d6111c ecx: 00000000 edx: c02e5f00
esi: f7d5d95c edi: 00000001 ebp: ebda9f10 esp: ebda9ef8
ds: 0068 es: 0068 ss: 0068
Process cfdisk (pid: 287, threadinfo=ebda8000 task=ec6152c0)
Stack: c02950a0 c0295080 c02954e4 f7d6111c 5a5a5a5a f7d4e000 ebda9f20
c0180c26
f7d6111c f7d5d95c ebda9f58 c0180e8a f7da5cc4 00000001 f7d5d974
f7d5d95c
ec4cd6d0 ebda9f7c ebda9f7c 000c5445 00000000 ebda9f64 00000000
ebda9f7c
Call Trace:
[<c0180c26>] delete_partition+0x5e/0x6c
[<c0180e8a>] rescan_partitions+0x5e/0x138
[<c0209630>] blkdev_reread_part+0x5c/0x78
[<c0209a56>] blkdev_ioctl+0x26a/0x38b
[<c015c14d>] sys_ioctl+0x22d/0x298
[<c01090ff>] syscall_call+0x7/0xb
Code: 0f 0b 5e 06 ae 50 29 c0 83 c4 14 83 7b 28 00 74 57 f6 05 70
------------[ cut here ]------------
kernel BUG at include/asm/spinlock.h:97!
invalid operand: 0000
CPU: 0
EIP: 0060:[<c011ca99>] Not tainted
EFLAGS: 00010002
EIP is at do_syslog+0x1a9/0x6c4
eax: 00003a01 ebx: c02e5f34 ecx: 00000000 edx: 00003a01
esi: 00000099 edi: 00000fff ebp: ec51ff64 esp: ec51ff34
ds: 0068 es: 0068 ss: 0068
Process klogd (pid: 173, threadinfo=ec51e000 task=ec614090)
Stack: 00000000 00000000 f6f8a914 ec51ff50 00000000 00000000 00000000
00000000
ec614090 c0118484 c02e5fb4 c02e5fb4 ec51ff78 c017ef44 00000002
0804dd39
00000fff ec51ff9c c014a727 f6f8a914 0804dca0 00000fff f6f8a934
f6f8a914
Call Trace:
[<c0118484>] default_wake_function+0x0/0x28
[<c017ef44>] kmsg_read+0x10/0x14
[<c014a727>] vfs_read+0xa7/0x144
[<c014a9dc>] sys_read+0x28/0x3c
[<c01090ff>] syscall_call+0x7/0xb
Code: 0f 0b 61 00 f8 14 28 c0 86 15 e4 5f 2e c0 fb 31 c0 8b 55 0c
_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8.
http://join.msn.com/?page=features/junkmail
^ permalink raw reply
* Re: AW: Re: [PATCH] S4bios for 2.5.52.
From: Lyle Seaman @ 2002-12-19 15:05 UTC (permalink / raw)
To: Herbert Nachtnebel; +Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <B900970C7DD9474C972986EB3EC7C58F0D404E-PWLG29+z7hEKeIAE67mlpo2P0GrZ+RbP@public.gmane.org>
> but that sounds like a unpluged block queue which get flushed every 5 seconds (or 30 seconds) by the bdflush daemon. There are two things which counters this, 1st: swsusp works on ide and there aren't such problems since aeons and 2nd Pavel knows that :-)
> Hence, apologies for this hip shot.
I'm not sure I understand what you're saying, Herbert.
There was something broken in yield() or schedule() back around 2.5.20 -
2.5.40 that made rw_swap_page_sync EXCRUTIATINGLY slow, but that's been fixed.
Still, writing pages synchronously, one at a time, is going to be slow no
matter what you do. *Especially* on slow laptop drives.
What I sent Nigel was a little patch to write them 20 at a time, which reduced
my suspend times from nearly 60 seconds to something around 2 seconds. I
stopped at 20 because going beyond that was chasing diminishing returns and I
didn't think that chewing up a huge chunk of stack was justified for a
one-second reduction in suspend times.
I didn't send it on to the rest of the list because I figure Nigel's other
changes will be coming along as well, and I didn't want to make merging too
difficult for everyone.
-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* latest acpi: new behavior of the UPBI method
From: Jacques GANGLOFF @ 2002-12-19 15:11 UTC (permalink / raw)
To: acpi-devel
Hi,
On my VAIO FX702, I have a recurrent problem
with the battery info:
* the time needed to dump /proc/acpi/battery/BAT1/info
is about 0.5s and during this time the box is frozen.
* the last entries in info are corrupted, i.e. model number,
serial number, battery type and OEM info.
As reported by another VAIO user on this list, my feeling is
that these problems are linked.
The interesting thing with the latest acpi patch (20021212), is that
the corruption in the last entries of info has changed. Now I get :
cat /proc/acpi/battery/BAT1/info
present: yes
design capacity: 44400 mWh
last full capacity: 44400 mWh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 400 mWh
design capacity low: 384 mWh
capacity granularity 1: 64 mWh
capacity granularity 2: 64 mWh
model number: 50 43 47 41 2D 42 50 37 31 41 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0A
serial number: 20 20 20 20 20 20 20 20 00
battery type: 4C 49 4F 4E 20 43 6F 72 70 2E 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04
OEM info: 53 6F 6E 79 20 43 6F 72 70 2E 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0A
This is a progress since if we translate all the hex numbers in ASCII
caracters we get :
model number: PCGA-BP71A
serial number:
battery type: LION Corp.
OEM info: Sony Corp.
which is rather close to what it should be (except for the "LION Corp."
???).
So why are these information given in hex dump format ? And why
is this dump so long ? My skill in AML programming is near from
beginner, so I need some help to go further.
Below is the dump that includes the faultly method (UPBI), I suppose it
should be a
good starting point.
Cheers,
Jacques
Device(BAT1) {
Name(_HID, 0x0a0cd041)
Name(_UID, 0x1)
Name(_PCL, Package(0x1) {
\_SB_,
})
Name(PBIF, Package(0xd) {
0x0,
0x5,
0x5,
0x1,
0x39d0,
0x0190,
0x0180,
0x40,
0x40,
"BAT1",
" ",
" ",
" ",
})
Name(PBST, Package(0x4) {
0x0,
0x5,
0x5,
0x2710,
})
Name(UBIF, 0x01e9)
Name(BP__, 0x1)
Method(_STA) {
If(\_SB_.PCI0.PIB_.EC0_.ECON) {
If(\_SB_.PCI0.PIB_.EC0_.ECOK) {
If(LNot(Acquire(\_SB_.PCI0.PIB_.EC0_.MUT0, 0x1400))) {
Store(0x8, \_SB_.PCI0.PIB_.DID_)
\_SB_.GSMI(0x8d)
Store(\_SB_.PCI0.PIB_.INF1, Local1)
And(Local1, 0x1, Local0)
If(Local0) {
Store(0x1, BP__)
}
Else {
Store(0x0, BP__)
}
Store(Local1, \_SB_.PCI0.PIB_.EC0_.BATO)
And(0xfffe, \_SB_.PCI0.PIB_.EC0_.BATF,
\_SB_.PCI0.PIB_.EC0_.BATF)
If(And(0xc0, \_SB_.PCI0.PIB_.EC0_.BATO, )) {
Or(\_SB_.PCI0.PIB_.EC0_.BATF, 0x1,
\_SB_.PCI0.PIB_.EC0_.BATF)
}
Release(\_SB_.PCI0.PIB_.EC0_.MUT0)
}
}
}
If(BP__) {
Return(0x1f)
}
Else {
Return(0xf)
}
}
Method(_BIF) {
If(\_SB_.PCI0.PIB_.EC0_.ECON) {
If(\_SB_.PCI0.PIB_.EC0_.ECOK) {
If(BP__) {
UPBI()
}
Else {
IVBI()
}
Store(0x01e9, UBIF)
}
}
Return(PBIF)
}
Method(_BST) {
If(\_SB_.PCI0.PIB_.EC0_.ECON) {
If(\_SB_.PCI0.PIB_.EC0_.ECOK) {
If(LNot(Acquire(\_SB_.PCI0.PIB_.EC0_.MUT0, 0x1400))) {
Store(0x8, \_SB_.PCI0.PIB_.DID_)
\_SB_.GSMI(0x8d)
Store(\_SB_.PCI0.PIB_.INF1, Local1)
And(Local1, 0x1, Local0)
Release(\_SB_.PCI0.PIB_.EC0_.MUT0)
}
If(Local0) {
UPBS()
}
Else {
IVBS()
}
}
}
Else {
IVBS()
}
Return(PBST)
}
Method(UPBI) {
Store(Zero, Local0)
If(LNot(Acquire(\_SB_.PCI0.PIB_.EC0_.MUT0, 0x1400))) {
Store(VTOB(Subtract(_UID, 0x1, )), Local1)
Or(ShiftLeft(Local1, 0xc, ), 0x0fff, Local2)
Store(Zero, Local3)
\_SB_.PCI0.PIB_.EC0_.SMWR(0x8, 0x14, 0x1, Local2)
\_SB_.PCI0.PIB_.EC0_.SMRD(0x9, 0x14, 0x1, RefOf(Local3))
Store(Zero, Local0)
Store(0xc, Local1)
Store(Buffer(0xd) {0x0, 0x18, 0x0, 0x0, 0x19, 0x0, 0x0,
0x0, 0x0, 0x21, 0x0, 0x22, 0x20 }, Local2)
While(LGreater(Local1, 0x8)) {
If(LNot(And(UBIF, VTOB(Local1), ))) {
GBFE(Local2, Local1, RefOf(Local3))
If(Local3) {
If(LNot(\_SB_.PCI0.PIB_.EC0_.SMRD(0xb, 0x16,
Local3, RefOf(Local4)))) {
GBFE(Local4, 0x20, RefOf(Local5))
PBFE(Local4, Local5, 0x20)
Increment(Local5)
PBFE(Local4, Local5, 0x0)
Store(Local4, Index(PBIF, Local1, ))
Or(UBIF, VTOB(Local1), UBIF)
Store(Ones, Local0)
}
}
}
Decrement(Local1)
}
While(LGreater(Local1, 0x0)) {
If(LNot(And(UBIF, VTOB(Local1), ))) {
GBFE(Local2, Local1, RefOf(Local3))
If(Local3) {
If(LNot(\_SB_.PCI0.PIB_.EC0_.SMRD(0x9, 0x16,
Local3, RefOf(Local5)))) {
Store(Local5, Index(PBIF, Local1, ))
Or(UBIF, VTOB(Local1), UBIF)
Store(Ones, Local0)
}
}
}
Decrement(Local1)
}
Store(0xa, Local1)
If(LNot(And(UBIF, VTOB(Local1), ))) {
If(LNot(\_SB_.PCI0.PIB_.EC0_.SMRD(0x9, 0x16, 0x1c,
RefOf(Local5)))) {
Store(ToBCD(Local5, ), Local0)
Store(ITOS(Local0), Index(PBIF, Local1, ))
Or(UBIF, VTOB(Local1), UBIF)
Store(Ones, Local0)
}
}
Store(\_SB_.PCI0.PIB_.EC0_.BANK, Local1)
Store(0x3, \_SB_.PCI0.PIB_.EC0_.BANK)
Store(\_SB_.PCI0.PIB_.EC0_.MFCP, Local2)
If(LEqual(Local2, 0x0)) {
Store(0x5, Index(PBIF, 0x2, ))
}
Else {
Multiply(Local2, 0xa, Local2)
Store(Local2, Index(PBIF, 0x2, ))
}
Store(Local1, \_SB_.PCI0.PIB_.EC0_.BANK)
Store(DerefOf(Index(PBIF, 0x1, )), Local2)
Multiply(Local2, 0xa, Local2)
Store(Local2, Index(PBIF, 0x1, ))
Release(\_SB_.PCI0.PIB_.EC0_.MUT0)
}
Return(Local0)
}
Method(UPBS) {
Store(Zero, Local0)
If(LNot(Acquire(\_SB_.PCI0.PIB_.EC0_.MUT0, 0x1388))) {
Store(0x2, \_SB_.PCI0.PIB_.DID_)
\_SB_.GSMI(0x8d)
Store(\_SB_.PCI0.PIB_.INF1, Local2)
If(And(Local2, 0x8000, )) {
Or(Local2, 0xffff0000, Local2)
Add(Not(Local2, ), 0x1, Local2)
}
Store(\_SB_.PCI0.PIB_.INF3, Local3)
Store(\_SB_.PCI0.PIB_.INF2, Local5)
If(LNot(LEqual(Local2, DerefOf(Index(PBST, 0x1, ))))) {
Multiply(Local2, 0xa, Local2)
Store(Local2, Index(PBST, 0x1, ))
Store(Ones, Local0)
}
If(LNot(LEqual(Local3, DerefOf(Index(PBST, 0x3, ))))) {
Multiply(Local3, 0x14, Local3)
Divide(Local3, 0x40, Local4, Local3)
Store(Local3, Index(PBST, 0x3, ))
Store(Ones, Local0)
}
If(LNot(LEqual(Local5, DerefOf(Index(PBST, 0x2, ))))) {
Multiply(Local5, 0xa, Local5)
Store(Local5, Index(PBST, 0x2, ))
Store(Ones, Local0)
}
Store(0x0, Local4)
Store(0x8, \_SB_.PCI0.PIB_.DID_)
\_SB_.GSMI(0x8d)
Store(\_SB_.PCI0.PIB_.INF1, Local7)
If(And(Local7, 0x0c00, )) {
If(And(Local7, 0x10, )) {
}
Else {
Or(0x2, Local4, Local4)
}
}
Else {
If(And(Local7, 0x0100, )) {
Or(0x1, Local4, Local4)
}
}
If(LNot(LEqual(Local4, DerefOf(Index(PBST, 0x0, ))))) {
Store(Local4, Index(PBST, 0x0, ))
Store(Ones, Local0)
}
Release(\_SB_.PCI0.PIB_.EC0_.MUT0)
}
Return(Local0)
}
Method(HVBI) {
Store(0x9650, Index(PBIF, 0x1, ))
Store(0x9650, Index(PBIF, 0x2, ))
Store(0x39d0, Index(PBIF, 0x4, ))
Store("PCGA-BP71", Index(PBIF, 0x9, ))
Store("LION", Index(PBIF, 0xb, ))
Store("Sony Corp.", Index(PBIF, 0xc, ))
}
Method(IVBI) {
Store(0x01e9, UBIF)
Store(0x5, Index(PBIF, 0x1, ))
Store(0x5, Index(PBIF, 0x2, ))
Store(0x5, Index(PBIF, 0x4, ))
Store("Bad", Index(PBIF, 0x9, ))
Store("Bad", Index(PBIF, 0xa, ))
Store("Bad", Index(PBIF, 0xb, ))
Store("Bad", Index(PBIF, 0xc, ))
}
Method(IVBS) {
Store(0x0, Index(PBST, 0x0, ))
Store(0x5, Index(PBST, 0x1, ))
Store(0x5, Index(PBST, 0x2, ))
Store(0x2710, Index(PBST, 0x3, ))
}
Method(CHBP, 1) {
Store(Zero, Local0)
Store(VTOB(Subtract(_UID, 0x1, )), Local1)
Or(ShiftLeft(Local1, 0xc, ), 0x0fff, Local2)
Store(Zero, Local3)
If(And(Arg0, Local1, )) {
If(BP__) {
UPBS()
}
Else {
If(LEqual(Local2, Or(Local3, 0x0fff, ))) {
UPBI()
}
UPBS()
Store(0x1, BP__)
Store(0x01e9, UBIF)
}
}
Else {
If(BP__) {
Store(0x0, BP__)
IVBI()
IVBS()
Or(0x4, Local0, Local0)
}
}
}
}
--
_________________________________
(
) Jacques GANGLOFF
( Associate Professor
) LSIIT / EAVR
( Bd Sebastien Brant
) 67400 Illkirch
( Tel : +33 (0)3 90 24 44 68
) Fax : +33 (0)3 90 24 44 80
( http://eavr.u-strasbg.fr
)_________________________________
-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.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.