Hi,
I've just tried on ASUS 3800C laptop the new kernel and see:
tbxface-0099 [01] Acpi_load_tables : ACPI Tables successfully loaded
Parsing Methods:....................................................................................................
....................................................................................................................
......................................
254 Control Methods found and parsed (769 nodes total)
ACPI Namespace successfully loaded at root c0428e00
ACPI: Core Subsystem version [20011018]
evxfevnt-0081 [-25] Acpi_enable : Transition to ACPI mode successful
Executing device _INI methods:.......................evregion-0302 [-7] Ev_address_space_dispa: Region handler: AE_E
RROR [PCIConfig]
dswexec-0392 [-16] Ds_exec_end_op : [Store]: Could not resolve operands, AE_ERROR
Ps_execute: method failed - \_SB_.PCI0.PCI2.CB0_._INI (f7eaea28)
nsinit-0351 [-23] Ns_init_one_device : \ /_SB_PCI0PCI2CB0_._INI failed: AE_ERROR
.evregion-0302 [-7] Ev_address_space_dispa: Region handler: AE_ERROR [PCIConfig]
dswexec-0392 [-16] Ds_exec_end_op : [Store]: Could not resolve operands, AE_ERROR
Ps_execute: method failed - \_SB_.PCI0.PCI2.CB1_._INI (f7eaee28)
nsinit-0351 [-23] Ns_init_one_device : \ /_SB_PCI0PCI2CB1_._INI failed: AE_ERROR
....................................
60 Devices found: 60 _STA, 3 _INI
Completing Region and Field initialization:..................
18/26 Regions, 0/0 Fields initialized (769 nodes total)
ACPI: Subsystem enabled
Power Resource: found
EC: found, GPE 28
ACPI: System firmware supports S0 S1 S3 S4 S5
Processor[0]: C0 C1 C2, 8 throttling states
ectransx-0199 [01] ec_read : Unable to send 'read command' to EC.
evregion-0302 [-2] Ev_address_space_dispa: Region handler: AE_TIME [Embedded_control]
dswexec-0392 [-11] Ds_exec_end_op : [LAnd]: Could not resolve operands, AE_TIME
Ps_execute: method failed - \_SB_.BAT0._BIF (f7ebff28)
ACPI: AC Adapter found
ACPI: Power Button (FF) found
ACPI: Sleep Button (CM) found
ACPI: Lid Switch (CM) found
ACPI: Thermal Zone found
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,EPP]
parport0: irq 7 detected
tzpolicy-0255 [-20] tz_policy_active : Unable to turn ON cooling device [00].
PCI: Found IRQ 5 for device 01:00.0
PCI: Sharing IRQ 5 with 00:1d.0
PCI: Sharing IRQ 5 with 02:07.0
radeonfb: ref_clk=2700, ref_div=12, xclk=18300 from BIOS
[...]
Mounted devfs on /dev
Freeing unused kernel memory: 128k freed
eth0: Setting 100mbps full-duplex based on auto-negotiated partner ability 45e1.
hda: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }
hda: status timeout: status=0xd0 { Busy }
hda: DMA disabled
hda: drive not ready for command
hda: set_drive_speed_status: status=0x58 { DriveReady SeekComplete DataRequest }
hda: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
hda: set_drive_speed_status: error=0x04 { DriveStatusError }
ide0: reset: master: ECC circuitry error
# lspci -n -v
00:00.0 Class 0600: 8086:1a30 (rev 04)
Subsystem: 1043:1626
Flags: bus master, fast devsel, latency 0
Memory at e0000000 (32-bit, prefetchable) [size=256M]
Capabilities: [e4] #09 [d104]
Capabilities: [a0] AGP version 2.0
00:01.0 Class 0604: 8086:1a31 (rev 04)
Flags: bus master, 66Mhz, fast devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000d000-0000dfff
Memory behind bridge: d7000000-d7efffff
Prefetchable memory behind bridge: d7f00000-dfffffff
00:1d.0 Class 0c03: 8086:2482 (rev 02)
Subsystem: 1043:1628
Flags: bus master, medium devsel, latency 0, IRQ 5
I/O ports at b800 [size=32]
00:1d.1 Class 0c03: 8086:2484 (rev 02)
Subsystem: 1043:1628
Flags: bus master, medium devsel, latency 0, IRQ 9
I/O ports at b400 [size=32]
00:1e.0 Class 0604: 8086:2448 (rev 42)
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=02, subordinate=02, sec-latency=32
I/O behind bridge: 0000a000-0000afff
Memory behind bridge: d6000000-d6ffffff
00:1f.0 Class 0601: 8086:248c (rev 02)
Flags: bus master, medium devsel, latency 0
00:1f.1 Class 0101: 8086:248a (rev 02) (prog-if 8a [Master SecP PriP])
Subsystem: 1043:1628
Flags: bus master, medium devsel, latency 0, IRQ 9
I/O ports at <ignored>
I/O ports at <ignored>
I/O ports at <ignored>
I/O ports at <ignored>
I/O ports at 8400 [size=16]
Memory at d5800000 (32-bit, non-prefetchable) [size=1K]
00:1f.5 Class 0401: 8086:2485 (rev 02)
Subsystem: 1043:1583
Flags: bus master, medium devsel, latency 0, IRQ 11
I/O ports at e000 [size=256]
I/O ports at e100 [size=64]
00:1f.6 Class 0703: 8086:2486 (rev 02)
Subsystem: 1043:1496
Flags: bus master, medium devsel, latency 0, IRQ 11
I/O ports at e200 [size=256]
I/O ports at e300 [size=128]
01:00.0 Class 0300: 1002:4c57
Subsystem: 1043:1622
Flags: bus master, stepping, 66Mhz, medium devsel, latency 64, IRQ
5
Memory at d8000000 (32-bit, prefetchable) [size=128M]
I/O ports at d800 [size=256]
Memory at d7000000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at d7fe0000 [disabled] [size=128K]
Capabilities: [58] AGP version 2.0
Capabilities: [50] Power Management version 2
02:05.0 Class 0200: 10ec:8139 (rev 10)
Subsystem: 1043:1045
Flags: bus master, medium devsel, latency 32, IRQ 9
I/O ports at a800 [size=256]
Memory at d6800000 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2
02:07.0 Class 0607: 1180:0476 (rev a8)
Subsystem: 1043:1624
Flags: bus master, medium devsel, latency 168, IRQ 5
Memory at 40000000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=02, secondary=02, subordinate=03, sec-latency=176
Memory window 0: 40400000-407ff000 (prefetchable)
Memory window 1: 40800000-40bff000
I/O window 0: 00004000-000040ff
I/O window 1: 00004400-000044ff
16-bit legacy interface ports at 0001
02:07.1 Class 0607: 1180:0476 (rev a8)
Subsystem: 1043:1624
Flags: bus master, medium devsel, latency 168, IRQ 11
Memory at 40001000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=02, secondary=04, subordinate=07, sec-latency=176
Memory window 0: 40c00000-40fff000 (prefetchable)
Memory window 1: 41000000-413ff000
I/O window 0: 00004800-000048ff
I/O window 1: 00004c00-00004cff
16-bit legacy interface ports at 0001
02:07.2 Class 0c00: 1180:0552 (prog-if 10)
Subsystem: 1043:1627
Flags: bus master, medium devsel, latency 32, IRQ 9
Memory at d6000000 (32-bit, non-prefetchable) [size=2K]
Capabilities: [dc] Power Management version 2
# lspci
00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge
(rev 04)
00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge
(rev 04)
00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #1) (rev 02)
00:1d.1 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #2) (rev 02)
00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 42)
00:1f.0 ISA bridge: Intel Corp. 82801CAM ISA Bridge (LPC) (rev 02)
00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 02)
00:1f.5 Multimedia audio controller: Intel Corp. 82801CA/CAM AC'97 Audio
(rev 02)
00:1f.6 Modem: Intel Corp. 82801CA/CAM AC'97 Modem (rev 02)
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7
LW [Radeon Mobility 7500]
02:05.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
02:07.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev a8)
02:07.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev a8)
02:07.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller
#
I suspect there's something wrong compared to 2.4.21-rc2-ac2 which I used till now.
--
Martin Mokrejs <[email protected]>, <[email protected]>
PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs
MIPS / Institute for Bioinformatics <http://mips.gsf.de>
GSF - National Research Center for Environment and Health
Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany
tel.: +49-89-3187 3683 , fax:?+49-89-3187 3585
> From: Martin MOKREJ? [mailto:[email protected]]
> ACPI: Core Subsystem version [20011018]
Old ACPI code, get patch from http://sf.net/projects/acpi and report back if problems persist.
Regards -- Andy
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dnia ?ro 4. czerwca 2003 19:01, Grover, Andrew napisa?:
> > From: Martin MOKREJ? [mailto:[email protected]]
> > ACPI: Core Subsystem version [20011018]
>
> Old ACPI code, get patch from http://sf.net/projects/acpi and report back
> if problems persist.
Any chance to get patch against latest -rc7 ?
- --
Grzegorz Jaskiewicz
K4 Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE+3lYvqu082fCQYIgRAqmPAJwKUk2xPONAc/Pkbqe6jbGdYbpAugCdERr7
5z/0sgxwzrimHkArboSXlvk=
=SjgI
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 04 of June 2003 21:49, you wrote:
> > From: Grzegorz Jaskiewicz [mailto:[email protected]]
> >
> > > > ACPI: Core Subsystem version [20011018]
> > >
> > > Old ACPI code, get patch from http://sf.net/projects/acpi
> >
> > and report back
> >
> > > if problems persist.
> >
> > Any chance to get patch against latest -rc7 ?
>
> It's big, and deemed too risky. We are shooting for 2.4.22-pre1.
I am just recompliling at the moment :D
Anyway, ACPI is a one of projects that is not well synchronized in kernel.
Latest version 2001.... .. hmm 2 years :]
It will be good to have always newest one in kernel (at least in stable
release version)
- --
Grzegorz Jaskiewicz
K4 Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE+3lioqu082fCQYIgRAi0BAJ4tp4J1z90xDTTwHD89ZmcwxGNydACfehuB
6ccFu+5ngcwxHxICUUtVpOo=
=X2fo
-----END PGP SIGNATURE-----
> From: Grzegorz Jaskiewicz [mailto:[email protected]]
> > > ACPI: Core Subsystem version [20011018]
> >
> > Old ACPI code, get patch from http://sf.net/projects/acpi
> and report back
> > if problems persist.
> Any chance to get patch against latest -rc7 ?
It's big, and deemed too risky. We are shooting for 2.4.22-pre1.
Did it work for you?
Regards -- Andy
> From: Grzegorz Jaskiewicz [mailto:[email protected]]
> > > Any chance to get patch against latest -rc7 ?
> >
> > It's big, and deemed too risky. We are shooting for 2.4.22-pre1.
> I am just recompliling at the moment :D
> Anyway, ACPI is a one of projects that is not well
> synchronized in kernel.
> Latest version 2001.... .. hmm 2 years :]
> It will be good to have always newest one in kernel (at least
> in stable
> release version)
We're synched up in 2.5, FWIW.
-- Andy
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I know that latest acpi patch is against -rc3, but it aply to -rc7 just with
one problem in documentation, so i dont care. Anyway, recompilation if it
fails:
gcc -D__KERNEL__ -I/usr/src/linux-2.4.21-rc7/include -Wall -Wstrict-prototypes
- -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer
- -pipe -mpreferred-stack-boundary=2 -march=i686 -falign-functions=0
- -falign-jumps=0 -falign-loops=0 -nostdinc -iwithprefix include
- -DKBUILD_BASENAME=acpiphp_glue -c -o acpiphp_glue.o acpiphp_glue.c
acpiphp_glue.c: In function `find_host_bridge':
acpiphp_glue.c:815: warning: passing arg 2 of `acpi_get_object_info' from
incompatible pointer type
acpiphp_glue.c:821: error: subscripted value is neither array nor pointer
acpiphp_glue.c:826: error: incompatible type for argument 1 of `strcmp'
make[3]: *** [acpiphp_glue.o] Error 1
make[3]: Leaving directory `/usr/src/linux-2.4.21-rc7/drivers/hotplug'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux-2.4.21-rc7/drivers/hotplug'
make[1]: *** [_subdir_hotplug] Error 2
make[1]: Leaving directory `/usr/src/linux-2.4.21-rc7/drivers'
make: *** [_dir_drivers] Error 2
Any chance to get quick fix of that ?
Please CC me, i am not subscribed to acpi mailing list.
Thanks
> > > Old ACPI code, get patch from http://sf.net/projects/acpi
> > and report back
> > > if problems persist.
> > Any chance to get patch against latest -rc7 ?
> It's big, and deemed too risky. We are shooting for 2.4.22-pre1.
> Did it work for you?
- --
Grzegorz Jaskiewicz
K4 Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE+3mGiqu082fCQYIgRAsBBAJ991RPum0QFcwRVqI8d3KTZp2NI6QCfSjAT
0obQhDO93Od0EjTHArZjEB0=
=oJ9C
-----END PGP SIGNATURE-----
Dear all,
I've been struggeling for some time with a small driver doing zerocopy
network I/O. I can't seem to find the correct method of pinning down the
pages and releasing them again. I've tried get_user_pages directly and
also kiobufs. What I always seem to get into is :
1. the pinning doesn't stick through a fork() (COW). I somehow solved
this by setting the VM_RESERVED bit in the respective VMAs.
2 when the skb stack releases the data after transmit and _if_ the
application has decremented the page referenceces (exited or
munmapped), the page somehow get the LRU bit set, and __free_pages_ok
barfs at line 95 (2.4.20) :
if (PageLRU(page)) {
if (unlikely(in_interrupt()))
->> BUG();
lru_cache_del(page);
}
A typical Oops looks like this (this is a RH kernel so the line
number in page_alloc.c is different from plain 2.4.20) :
kernel BUG at page_alloc.c:97!
invalid operand: 0000
scadet nfs lockd sunrpc sg esm autofs tg3 iptable_filter ip_tables mousedev keybdev hid input usb-ohci usbcore ext3 jbd aic7xxx sd_mod scsi_mod
CPU: 0
EIP: 0010:[<c01439f4>] Tainted: PF
EFLAGS: 00010202
EIP is at __free_pages_ok [kernel] 0x364 (2.4.20-18.8smp)
eax: 00000001 ebx: c1d63518 ecx: 00000000 edx: 00000000
esi: f0c9f580 edi: 00000000 ebp: 00000000 esp: f7fa7f24
ds: 0018 es: 0018 ss: 0018
Process ksoftirqd_CPU0 (pid: 3, stackpage=f7fa7000)
Stack: 0000003e f3847c00 00000286 f10b9b80 f3847c00 c36b0018 f3840018 ffffff1c
c013dd49 00000010 00000002 f0c9f580 00000000 f10b9b80 c020421e f10b9b80
f0c9f580 f0c9f580 c0204257 f0c9f580 00000001 f0c9f580 f0c9f580 c02043c6
Call Trace: [<c013dd49>] kfree [kernel] 0x59 (0xf7fa7f44))
[<c020421e>] skb_release_data [kernel] 0x6e (0xf7fa7f5c))
[<c0204257>] kfree_skbmem [kernel] 0x17 (0xf7fa7f6c))
[<c02043c6>] __kfree_skb [kernel] 0x106 (0xf7fa7f80))
[<c0208fd7>] net_tx_action [kernel] 0x57 (0xf7fa7f94))
[<c0126129>] do_softirq [kernel] 0xd9 (0xf7fa7fb0))
[<c01266a5>] ksoftirqd [kernel] 0xe5 (0xf7fa7fcc))
[<c0105000>] stext [kernel] 0x0 (0xf7fa7fe8))
[<c010758e>] arch_kernel_thread [kernel] 0x2e (0xf7fa7ff0))
[<c01265c0>] ksoftirqd [kernel] 0x0 (0xf7fa7ff8))
I've also been looking at the implementation of mlock(), but I'm not
sure if it will handle the issues above.
I'll appreciate any hints you may have.
Regards,
Steffen Persvold
> From: Grzegorz Jaskiewicz [mailto:[email protected]]
> I know that latest acpi patch is against -rc3, but it aply to
> -rc7 just with
> one problem in documentation, so i dont care. Anyway,
> recompilation if it
> fails:
Fix already done, config acpi PHP out until that's merged -- Andy
On Mer, 2003-06-04 at 21:27, Grzegorz Jaskiewicz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dnia śro 4. czerwca 2003 19:01, Grover, Andrew napisał:
> > > From: Martin MOKREJŠ [mailto:[email protected]]
> > > ACPI: Core Subsystem version [20011018]
> >
> > Old ACPI code, get patch from http://sf.net/projects/acpi and report back
> > if problems persist.
> Any chance to get patch against latest -rc7 ?
2.4.27rc7-ac1 has the current ACPI + the relax patches
On Wed, 4 Jun 2003, Grover, Andrew wrote:
> > From: Grzegorz Jaskiewicz [mailto:[email protected]]
> > > > ACPI: Core Subsystem version [20011018]
> > >
> > > Old ACPI code, get patch from http://sf.net/projects/acpi
> > and report back
> > > if problems persist.
> > Any chance to get patch against latest -rc7 ?
>
> It's big, and deemed too risky. We are shooting for 2.4.22-pre1.
Just had a few thoughts about that and I want to have a fast 2.4.22
release (maximum two months). 2.4.21's development time was unnaceptable.
Lets do the ACPI merge in 2.4.23.
No, I need ACPI to soft boot.
This MUST be in the next release.
Margit
> From: Marcelo Tosatti [mailto:[email protected]]
> > > Any chance to get patch against latest -rc7 ?
> >
> > It's big, and deemed too risky. We are shooting for 2.4.22-pre1.
>
> Just had a few thoughts about that and I want to have a fast 2.4.22
> release (maximum two months). 2.4.21's development time was
> unnaceptable.
>
> Lets do the ACPI merge in 2.4.23.
I wouldn't have a problem with this, except that you've been deferring
the ACPI merge for over a year. We've been maintaining this patch
outside the mainline tree for EIGHTEEN MONTHS. Please stop leading me
along. Will you EVER merge it?
I am confident it will merge cleanly.
I am confident it will cause no problems when CONFIG_ACPI=off.
I am confident the total number of working machines will go up.
I am willing to bet $500 of MY OWN MONEY on this.
Talk to me, man. What would make you happy? A lot is riding on this.
Regards -- Andy
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Monday 09 of June 2003 22:21, you wrote:
> > From: Marcelo Tosatti [mailto:[email protected]]
> >
> > > > Any chance to get patch against latest -rc7 ?
> > >
> > > It's big, and deemed too risky. We are shooting for 2.4.22-pre1.
> >
> > Just had a few thoughts about that and I want to have a fast 2.4.22
> > release (maximum two months). 2.4.21's development time was
> > unnaceptable.
In this world there should be no rush :-)
> > Lets do the ACPI merge in 2.4.23.
>
> I wouldn't have a problem with this, except that you've been deferring
> the ACPI merge for over a year. We've been maintaining this patch
> outside the mainline tree for EIGHTEEN MONTHS. Please stop leading me
> along. Will you EVER merge it?
>
> I am confident it will merge cleanly.
> I am confident it will cause no problems when CONFIG_ACPI=off.
> I am confident the total number of working machines will go up.
> I am willing to bet $500 of MY OWN MONEY on this.
Well, Marcelo - i am happy with new ACPI, Alan does (otherwise it wouldn't be
included into ac tree). We will welcome it in 2.4.22-pre1 :]
Anyway, still ACPI does not work fully in my PCG-C1VE Sony Vaio. I don't know
if due to incompatibilities of this equipment ?
All other servers/desktops works perfectly fine for me :D
Thanks guys.
- --
Grzegorz Jaskiewicz
K4 Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE+5PsLqu082fCQYIgRAuaFAJ0RxLG8gj2/Lk2B+bxS7bxwcve4zgCghgzO
d7hfwJa81RyJ+ltxmBd+KIs=
=JkND
-----END PGP SIGNATURE-----
Yes , and not on?y ACPI, put Justin's SCSI in as well !
Margit
On Mon, 9 Jun 2003, Grover, Andrew wrote:
> > From: Marcelo Tosatti [mailto:[email protected]]
> > > > Any chance to get patch against latest -rc7 ?
> > >
> > > It's big, and deemed too risky. We are shooting for 2.4.22-pre1.
> >
> > Just had a few thoughts about that and I want to have a fast 2.4.22
> > release (maximum two months). 2.4.21's development time was
> > unnaceptable.
> >
> > Lets do the ACPI merge in 2.4.23.
>
> I wouldn't have a problem with this, except that you've been deferring
> the ACPI merge for over a year. We've been maintaining this patch
> outside the mainline tree for EIGHTEEN MONTHS.
The main reason I didnt want to merge it was due to its size. Its just too
big.
> Please stop leading me along. Will you EVER merge it?
Yes, I want to, and will merge it. In 2.4.23-pre.
> I am confident it will merge cleanly.
> I am confident it will cause no problems when CONFIG_ACPI=off.
> I am confident the total number of working machines will go up.
> I am willing to bet $500 of MY OWN MONEY on this.
>
> Talk to me, man. What would make you happy? A lot is riding on this.
Yes, we're fine. 2.4.23-pre.
2.4.22 will be a fast enough release to not piss you off on this, trust
me.
>Yes, we're fine.
>2.4.23-pre. 2.4.22 will be a fast enough release to not piss you off on
this, trust me.
-march=pentium(x) ?
Radeon 9K ?
> From: Marcelo Tosatti [mailto:[email protected]]
> The main reason I didnt want to merge it was due to its size.
> Its just too
> big.
Maybe it's just because I am so familiar with it, but while its size is
big, I don't view it as terribly big conceptually. The patch is big
because diff doesn't handle file renames well. Plus, the great majority
of changes are in drivers/acpi. I would think you could basically ignore
all that code, and focus your review on the other bits. I'd be happy to
split that out into a much smaller, easier-to-review patch if that would
help.
> 2.4.22 will be a fast enough release to not piss you off on
> this, trust
> me.
I'm looking forward to its swift arrival.
Regards -- Andy
On Tue, 10 Jun 2003, Margit Schubert-While wrote:
> >Yes, we're fine.
> >2.4.23-pre. 2.4.22 will be a fast enough release to not piss you off on
> this, trust me.
>
> -march=pentium(x) ?
>
> Radeon 9K ?
Huh ?
On Llu, 2003-06-09 at 23:03, Marcelo Tosatti wrote:
> Yes, I want to, and will merge it. In 2.4.23-pre.
>
> > I am confident it will merge cleanly.
> > I am confident it will cause no problems when CONFIG_ACPI=off.
> > I am confident the total number of working machines will go up.
> > I am willing to bet $500 of MY OWN MONEY on this.
> >
> > Talk to me, man. What would make you happy? A lot is riding on this.
>
> Yes, we're fine. 2.4.23-pre.
>
> 2.4.22 will be a fast enough release to not piss you off on this, trust
> me.
Its been in 2.4.21-ac for a while. I have exactly zero reports of it
causing problems in the acpi=n case, and a whole raft of "the first
Linux that runs on my toshiba/compaq/hp laptop"
Works well enough for me to have faith in it now.
On Llu, 2003-06-09 at 21:32, Marcelo Tosatti wrote:
> Just had a few thoughts about that and I want to have a fast 2.4.22
> release (maximum two months). 2.4.21's development time was unnaceptable.
>
> Lets do the ACPI merge in 2.4.23.
Seems to me the two critical patches for the next 2.4.2x are acpi and the aic7*
stuff, both of which will need a little time but not a lot to bed in
On Tue, Jun 10 2003, Alan Cox wrote:
> On Llu, 2003-06-09 at 23:03, Marcelo Tosatti wrote:
> > Yes, I want to, and will merge it. In 2.4.23-pre.
> >
> > > I am confident it will merge cleanly.
> > > I am confident it will cause no problems when CONFIG_ACPI=off.
> > > I am confident the total number of working machines will go up.
> > > I am willing to bet $500 of MY OWN MONEY on this.
> > >
> > > Talk to me, man. What would make you happy? A lot is riding on this.
> >
> > Yes, we're fine. 2.4.23-pre.
> >
> > 2.4.22 will be a fast enough release to not piss you off on this, trust
> > me.
>
> Its been in 2.4.21-ac for a while. I have exactly zero reports of it
> causing problems in the acpi=n case, and a whole raft of "the first
> Linux that runs on my toshiba/compaq/hp laptop"
>
> Works well enough for me to have faith in it now.
We need it as well to have proper ACPI support on the Hp/cpq laptops. Without
it one may get serious overheating problems.
We've been waiting for it for a long time now.
Thanks.
On 10 Jun 2003 01:44:59 +0100
Alan Cox <[email protected]> wrote:
> On Llu, 2003-06-09 at 23:03, Marcelo Tosatti wrote:
> > Yes, I want to, and will merge it. In 2.4.23-pre.
> >
> > > I am confident it will merge cleanly.
> > > I am confident it will cause no problems when CONFIG_ACPI=off.
> > > I am confident the total number of working machines will go up.
> > > I am willing to bet $500 of MY OWN MONEY on this.
> > >
> > > Talk to me, man. What would make you happy? A lot is riding on this.
> >
> > Yes, we're fine. 2.4.23-pre.
> >
> > 2.4.22 will be a fast enough release to not piss you off on this, trust
> > me.
>
> Its been in 2.4.21-ac for a while. I have exactly zero reports of it
> causing problems in the acpi=n case, and a whole raft of "the first
> Linux that runs on my toshiba/compaq/hp laptop"
>
> Works well enough for me to have faith in it now.
I can back that. In fact I have some SIS-based motherboards that do not run
without the acpi patch.
My personal opinion on the topic "what to put in 2.4.22-pre1?" is:
1) aic (because you can kick Justins' a** if it does not work out, and get rid
of any complaints for what you do yourself to the aic code)
2) acpi (because the code has already gone through some significant testing and
looks promising).
So I guess I would just do the opposite of your current statement. Remember, you
have a chance to win 500 bucks, don't let it go ;-)
Regards,
Stephan
Marcelo Tosati wrote:
>The main reason I didnt want to merge it was due to its size. Its just
>too big.
>> Please stop leading me along. Will you EVER merge it?
>Yes, I want to, and will merge it. In 2.4.23-pre.
This kind of mails and sentence makes you lost your credibility :
1) You said that ACPI will be merged in 2.4.22-pre,
2) For many people ACPI (and aic7xxx) is top priority for 2.4 kernel
(see various post including alan). The reason being that most laptop are
unusable nowadays without ACPI,
3) You do not explicitely says what you plan for 2.4.22...
So, for stupid people like me, could you take a little time to explains
the dummy's what are your views about what is top priority for kernel
and for what reasons?
I would personnally suggest that you classify the things using the
following filter :
a) Server (SMP, SCSI, RAID, journaling filesystems, ...),
b) laptop (ACPI, CPUFREQ, Software suspend, IDE power save,...),
c) desktop (File system efficiency, new hardware support,...),
d) all systems
Or maybe you simply think that software engineering is a kind of black
art that is too hard to understand for average people...
--
__
/ ` Eric Valette
/-- __ o _. 6 rue Paul Le Flem
(___, / (_(_(__ 35740 Pace
Tel: +33 (0)2 99 85 26 76 Fax: +33 (0)2 99 85 26 76
E-mail: [email protected]
On Wed, Jun 11, 2003 at 01:40:54AM +0200, Eric Valette wrote:
>...
> I would personnally suggest that you classify the things using the
> following filter :
> a) Server (SMP, SCSI, RAID, journaling filesystems, ...),
> b) laptop (ACPI, CPUFREQ, Software suspend, IDE power save,...),
> c) desktop (File system efficiency, new hardware support,...),
> d) all systems
>...
Why are journaling filesystems only for servers?
Is file system efficiency not relevant on servers?
The important sections are more likely (ordered by priority):
- bug fixes (e.g. aic7xxx)
- support for additional hardware (e.g. ACPI update)
- new features (e.g. XFS)
These groups are not mutual exclusive, e.g. the ACPI update also
includes new features.
The important thing is that this is inside a stable kernel series and an
update that makes things better for 100 people but makes things worse
for one person is IMHO bad since it's a regression for one person.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Adrian Bunk wrote:
> On Wed, Jun 11, 2003 at 01:40:54AM +0200, Eric Valette wrote:
>
>>...
>>I would personnally suggest that you classify the things using the
>>following filter :
>> a) Server (SMP, SCSI, RAID, journaling filesystems, ...),
>> b) laptop (ACPI, CPUFREQ, Software suspend, IDE power save,...),
>> c) desktop (File system efficiency, new hardware support,...),
>> d) all systems
>>...
>
>
> Why are journaling filesystems only for servers?
> Is file system efficiency not relevant on servers?
I was just making suggestions after a 30s thinking. Side comments,
readding this mailling list, I had the impression that journaling and
filesystem performance do not seem to mix well. Also on server, you have
probably extra backup hardware and means (e.g RAID, DAT, DLT, ...)
> The important sections are more likely (ordered by priority):
> - bug fixes (e.g. aic7xxx)
> - support for additional hardware (e.g. ACPI update)
> - new features (e.g. XFS)
Personnaly, I dislike this approach as it as resulted in 2.4 being non
usable for servers (SMP deadlocks, IO stalls, unresponsiveness for
several seconds, ...) and laptop (ACPI)...
> The important thing is that this is inside a stable kernel series and an
> update that makes things better for 100 people but makes things worse
> for one person is IMHO bad since it's a regression for one person.
If 2.4 kernel is not usable without patching, It is far worse for me...
--
__
/ ` Eric Valette
/-- __ o _. 6 rue Paul Le Flem
(___, / (_(_(__ 35740 Pace
Tel: +33 (0)2 99 85 26 76 Fax: +33 (0)2 99 85 26 76
E-mail: [email protected]
On Wed, 11 Jun 2003 23:15:06 +0200
Adrian Bunk <[email protected]> wrote:
> [...]
> The important thing is that this is inside a stable kernel series and an
> update that makes things better for 100 people but makes things worse
> for one person is IMHO bad since it's a regression for one person.
You cannot fulfill that in reality. Looking at the broad variety of software
out there you simply cannot know all the implications a simple bug fix may
have. There may well be boxes that rely on a broken code you just fixed. Only
god knows. So you sometimes simply have to do "the right thing"(tm) knowing
there will always be people who shoot you for it.
Regards,
Stephan
Stephan von Krawczynski wrote:
> On Wed, 11 Jun 2003 23:15:06 +0200
> Adrian Bunk <[email protected]> wrote:
>
>
>>[...]
>>The important thing is that this is inside a stable kernel series and an
>>update that makes things better for 100 people but makes things worse
>>for one person is IMHO bad since it's a regression for one person.
>
>
> You cannot fulfill that in reality. Looking at the broad variety of software
> out there you simply cannot know all the implications a simple bug fix may
> have. There may well be boxes that rely on a broken code you just fixed. Only
> god knows. So you sometimes simply have to do "the right thing"(tm) knowing
> there will always be people who shoot you for it.
Just to go a little bit more in that direction, I already have seen an
obvious one-line patch that caused a deadlock in another OS because due
to code location change and probably an additionnal cache miss on
specific part of the code, an existing synchronisation bug that was
never triggered started to effectively happen...
Besides, if you please 1000 users and cause problem to 2 of them because
they have broken hardware, I think you are going into the right direction.
>The important sections are more likely (ordered by priority):
> - bug fixes (e.g. aic7xxx)
> - support for additional hardware (e.g. ACPI update)
> - new features (e.g. XFS)
Bug fixes are meant to make the 2.4 kernel more useable right? So I do
not reallly see the utimate difference with other things in your
category. What I was asking is a rationnal way of chosing the
priorities. You gave me yours without real explanation.
The purpose of the original mail was to ask for discussion/clarification
on 2.4 development priorities (e.g something like the 2.6 todo list) and
a proposal to set up the priorities using generic targetted hardware
(server, laptop, desktop) as hint for requirement selection.
--
__
/ ` Eric Valette
/-- __ o _. 6 rue Paul Le Flem
(___, / (_(_(__ 35740 Pace
Tel: +33 (0)2 99 85 26 76 Fax: +33 (0)2 99 85 26 76
E-mail: [email protected]
On Wed, 4 Jun 2003, Grover, Andrew wrote:
> > From: Martin MOKREJ? [mailto:[email protected]]
> > ACPI: Core Subsystem version [20011018]
>
> Old ACPI code, get patch from http://sf.net/projects/acpi and report back if problems persist.
Hi,
so I retried the latest patch available from sourceforge site, but that
is for pre-2.4.21-rc3 candidate. Even worse, some parsed applied with
offset and in one or two cases got rejected! So I have to wait if patch for
-rc8 appears or for anything newer. Anyone successfully applied
acpi-20030523-2.4.21-rc3.diff.gz 7b9551e86393a58d8e6c2b3aeeea2f16
(md5sum)?
Thanks
--
Martin Mokrejs <[email protected]>, <[email protected]>
PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs
MIPS / Institute for Bioinformatics <http://mips.gsf.de>
GSF - National Research Center for Environment and Health
Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany
tel.: +49-89-3187 3683 , fax:?+49-89-3187 3585
* Martin MOKREJ? ([email protected]) wrote:
> Hi,
> so I retried the latest patch available from sourceforge site, but that
> is for pre-2.4.21-rc3 candidate. Even worse, some parsed applied with
> offset and in one or two cases got rejected! So I have to wait if patch for
> -rc8 appears or for anything newer. Anyone successfully applied
> acpi-20030523-2.4.21-rc3.diff.gz 7b9551e86393a58d8e6c2b3aeeea2f16
> (md5sum)?
the rc3 acpi patch should apply cleanly to everything upto and including
rc8 (it did for me, anyway. :D).
iain
--
wh33, y1p33 3tc.
"If sharing a thing in no way diminishes it, it is not rightly owned if it is
not shared." -St. Augustine
On Thu, 12 Jun 2003, iain d broadfoot wrote:
> * Martin MOKREJ? ([email protected]) wrote:
> > Hi,
> > so I retried the latest patch available from sourceforge site, but that
> > is for pre-2.4.21-rc3 candidate. Even worse, some parsed applied with
> > offset and in one or two cases got rejected! So I have to wait if patch for
> > -rc8 appears or for anything newer. Anyone successfully applied
> > acpi-20030523-2.4.21-rc3.diff.gz 7b9551e86393a58d8e6c2b3aeeea2f16
> > (md5sum)?
>
> the rc3 acpi patch should apply cleanly to everything upto and including
> rc8 (it did for me, anyway. :D).
Against -rc8 I got:
patching file Documentation/Configure.help
Hunk #1 succeeded at 18665 (offset 20 lines).
patching file Documentation/kernel-parameters.txt
but no rejects, that's true. The kernel 2.4.21-rc8-acpi-20050522 works
fine now. Thanks. I'm too lazy to repeat patching plain -rc3. :(
--
Martin Mokrejs <[email protected]>, <[email protected]>
PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs
MIPS / Institute for Bioinformatics <http://mips.gsf.de>
GSF - National Research Center for Environment and Health
Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany
tel.: +49-89-3187 3683 , fax:?+49-89-3187 3585
On Wed, 11 Jun 2003, Eric Valette wrote:
> Marcelo Tosati wrote:
>
> >The main reason I didnt want to merge it was due to its size. Its just
> >too big.
>
> >> Please stop leading me along. Will you EVER merge it?
>
> >Yes, I want to, and will merge it. In 2.4.23-pre.
>
> This kind of mails and sentence makes you lost your credibility :
> 1) You said that ACPI will be merged in 2.4.22-pre,
> 2) For many people ACPI (and aic7xxx) is top priority for 2.4 kernel
> (see various post including alan). The reason being that most laptop are
> unusable nowadays without ACPI,
> 3) You do not explicitely says what you plan for 2.4.22...
My plan for 2.4.22 is:
- Include the new aic7xxx driver.
- Include ACPI. (I now realized its importance). Already discussing with
Andrew the best way to do it.
- Fix the latency/interactivity problems (Chris, Nick and Andrea working
on that)
- Merge obviously correct -aa VM patches.
Those are the most important things that are needed now, I think.
On 06.18, Marcelo Tosatti wrote:
>
>
> On Wed, 11 Jun 2003, Eric Valette wrote:
>
> > Marcelo Tosati wrote:
> >
> > >The main reason I didnt want to merge it was due to its size. Its just
> > >too big.
> >
> > >> Please stop leading me along. Will you EVER merge it?
> >
> > >Yes, I want to, and will merge it. In 2.4.23-pre.
> >
> > This kind of mails and sentence makes you lost your credibility :
> > 1) You said that ACPI will be merged in 2.4.22-pre,
> > 2) For many people ACPI (and aic7xxx) is top priority for 2.4 kernel
> > (see various post including alan). The reason being that most laptop are
> > unusable nowadays without ACPI,
> > 3) You do not explicitely says what you plan for 2.4.22...
>
> My plan for 2.4.22 is:
>
> - Include the new aic7xxx driver.
> - Include ACPI. (I now realized its importance). Already discussing with
> Andrew the best way to do it.
> - Fix the latency/interactivity problems (Chris, Nick and Andrea working
> on that)
> - Merge obviously correct -aa VM patches.
>
> Those are the most important things that are needed now, I think.
>
Would you accept small canges like -march (gcc_check) for x86 ?
--
J.A. Magallon <[email protected]> \ Software is like sex:
werewolf.able.es \ It's better when it's free
Mandrake Linux release 9.2 (Cooker) for i586
Linux 2.4.21-jam1 (gcc 3.3 (Mandrake Linux 9.2 3.3-1mdk))
On Wed, 2003-06-18 at 00:25, Marcelo Tosatti wrote:
> My plan for 2.4.22 is:
>
> - Include the new aic7xxx driver.
> - Include ACPI. (I now realized its importance). Already discussing with
> Andrew the best way to do it.
> - Fix the latency/interactivity problems (Chris, Nick and Andrea working
> on that)
> - Merge obviously correct -aa VM patches.
>
> Those are the most important things that are needed now, I think.
How about the backported cpufreq patch from Bill Nottingham? Can that
one go in as well please? It is not a big patch as such and it is
working as far as I can tell. I have been running it since it was posted
on the list last week.
Regards,
--
Anders Karlsson <[email protected]>
Trudheim Technology Limited
Marcelo Tosatti wrote:
> My plan for 2.4.22 is:
>
> - Include the new aic7xxx driver.
> - Include ACPI. (I now realized its importance). Already discussing with
> Andrew the best way to do it.
> - Fix the latency/interactivity problems (Chris, Nick and Andrea working
> on that)
> - Merge obviously correct -aa VM patches.
>
> Those are the most important things that are needed now, I think.
I think many people on this list will be delighted to read this. I'm
looking for the 22-pre to help testing them (UP)... As alan said,
increasing the user test base may cause to find some remaining bugs but
as many people are already forced to patch their 2.4 kernel with aic7xxx
and ACPI just to make it useable most severe/obvious bugs have probably
already been found...
I think SMP server users will also be happy with the rest of proposed fixes.
Side comments just to try to make 2.4 even better : I think polling the
list to see the most annoying problems or most requested feature people
have/want is sometime a good idea. Of course you will always get mail
from people that what a patch to have support for their baroque hardware
but I think you may reach a consensus rapidly as in the previous (rude)
mail exchanges.
Hope you will manage to spend the needed time to make this in a timely
fashion.
--
__
/ ` Eric Valette
/-- __ o _. 6 rue Paul Le Flem
(___, / (_(_(__ 35740 Pace
Tel: +33 (0)2 99 85 26 76 Fax: +33 (0)2 99 85 26 76
E-mail: [email protected]
Anders Karlsson ([email protected]) said:
> How about the backported cpufreq patch from Bill Nottingham? Can that
> one go in as well please? It is not a big patch as such and it is
> working as far as I can tell. I have been running it since it was posted
> on the list last week.
It requires the more substantial generic cpufreq backport first. :)
Bill
On Wed, 18 Jun 2003, J.A. Magallon wrote:
>
> On 06.18, Marcelo Tosatti wrote:
> >
> >
> > On Wed, 11 Jun 2003, Eric Valette wrote:
> >
> > > Marcelo Tosati wrote:
> > >
> > > >The main reason I didnt want to merge it was due to its size. Its just
> > > >too big.
> > >
> > > >> Please stop leading me along. Will you EVER merge it?
> > >
> > > >Yes, I want to, and will merge it. In 2.4.23-pre.
> > >
> > > This kind of mails and sentence makes you lost your credibility :
> > > 1) You said that ACPI will be merged in 2.4.22-pre,
> > > 2) For many people ACPI (and aic7xxx) is top priority for 2.4 kernel
> > > (see various post including alan). The reason being that most laptop are
> > > unusable nowadays without ACPI,
> > > 3) You do not explicitely says what you plan for 2.4.22...
> >
> > My plan for 2.4.22 is:
> >
> > - Include the new aic7xxx driver.
> > - Include ACPI. (I now realized its importance). Already discussing with
> > Andrew the best way to do it.
> > - Fix the latency/interactivity problems (Chris, Nick and Andrea working
> > on that)
> > - Merge obviously correct -aa VM patches.
> >
> > Those are the most important things that are needed now, I think.
> >
>
> Would you accept small canges like -march (gcc_check) for x86 ?
I'm not aware of this patch. I might well accecpt it.
Please submit it with a good explanation and I will consider it.