* Re: r8169, 2.6.2-rc2, Sager 4780 laptop
From: bhartin @ 2004-01-27 6:51 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
In-Reply-To: <20040126235559.A3832@electric-eye.fr.zoreil.com>
Okay, I patched using only the patches listed below. These are actually
applied against 2.6.2-rc2, since I don't have 2.6.2-rc1 on hand at the
moment, and your patches still apply cleanly.
acpi=off
- RX - Pushed about a gig, averaging 8.2MB/sec. Appeared to work ok.
- TX - Once I hit 642MB transfered (avg 8.9MB/sec), the system locked up
hard.
SMP off, acpi on
- TX - Hard lock at 307MB.
SMP off, acpi off
- TX - Hard lock at 345MB.
I'll try to investigate further tomorrow. I have to go out of town
starting Thursday, and was hoping to have everything working by then.
Unfortunately, I have other problems to deal with as well (ati-drivers,
slmodem, etc).
Thanks
On Mon, 26 Jan 2004, Francois Romieu wrote:
> bhartin@straus-frank.com <bhartin@straus-frank.com> :
> [...]
> > Attached is a tar.gz containing the outputs you request in your README,
> > plus 'lspci -v' output and my .config for the kernel. This data was
> > collected from a fresh 2.6.2-rc2 bootup, using your full set of 2.6.2-rc1
> > patches, manually doing a 'modprobe r8169' once booted up. The system is
> > running a P4 with HT enabled, with an SMP kernel.
>
> There has been report of non-regression on non-SMP kernel with the following
> patches applied (2.6.2-rc1 serie):
> r8169-tx-index-overflow.patch
> r8169-dma-api-tx.patch
> r8169-dma-api-rx-buffers.patch
> r8169-dma-api-tx-buffers.patch
> r8169-rx_copybreak.patch
> r8169-mac-phy-version.patch
> r8169-init_one.patch
> r8169-timer.patch
> r8169-hw_start.patch
> r8169-intr_mask.patch
> r8169-suspend.patch
> r8169-endianness.patch
> r8169-getstats.patch
>
> Can you confirm that the driver behaves the same as the standard driver
> with a non-SMP enabled kernel ?
>
> Does it make a difference if you give an 'acpi=off' option at boot time ?
>
> r8169-addr-high.patch is not doing its job on amd64 so it is not suggested
> to use it at all.
>
> There is something broken wrt SMP and the r8169 patches: do not use both at
> the same time. I still have to find what happens here.
>
> --
> Ueimor
>
Bradley Hartin - bhartin@straus-frank.com
Communications and Network Administrator
Straus-Frank Company
^ permalink raw reply
* ALERT - GroupShield ticket number OA454_1075186111_DEATCSSTRMSX0 3_3 was generated
From: GroupShield for Exchange (DEATCSSTRMSX03) @ 2004-01-27 6:49 UTC (permalink / raw)
To: 'linux1394-devel@lists.sourceforge.net', 'LKML'
Action Taken:
The attachment was quarantined from the message and replaced with a text
file informing the recipient of the action taken.
To:
linux1394-devel@lists.sourceforge.net
<linux1394-devel@lists.sourceforge.net>; LKML <linux-kernel@vger.kernel.org>
From:
Jean Delvare <khali@linux-fr.org>
Sent:
-1232340736,29615265
Subject:
Message about PCILynx in kernel config
Attachment Details:-
Attachment Name: message.scr
File: message.scr
Infected? No
Repaired? No
Blocked? Yes
Deleted? No
Virus Name:
^ permalink raw reply
* Re: virus warning
From: Unknown, Alistair Tonner @ 2004-01-27 6:45 UTC (permalink / raw)
To: Netfilter Mailing List (E-mail)
In-Reply-To: <F22386C3FEB012449238672E38ED61E71642A9@overlord.overturemedia.com>
Obviously this is a really new one ... F-prot didn't catch it .. and mines up to date ...
However ... since kmail and linux don't much like 7 bit mime ... *grin*
I'm handing this one up to the folks at F-Prot to see why they didn't catch it...
Alistair.
On January 27, 2004 12:44 am, Fritz Mesedilla wrote:
> friends,
>
> we got a virus in our list.
> clamav warned me about it.
> it's now spreading like fire even on other lists.
>
> thought you might like to be warned.
>
>
> Cheers,
>
> fritz <www.mesedilla.com>
> ---
> + Basta Ikaw Lord
>
>
>
>
> ----------------------------------------------------------------------
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the sender immediately by e-mail and delete this e-mail from your
> system. Please note that any views or opinions presented in this
> email are solely those of the author and do not necessarily represent
> those of the company. Finally, the recipient should check this email
> and any attachments for the presence of viruses. The company accepts
> no liability for any damage caused by any virus transmitted by this
> email.
>
> Overture Media, Inc.
> Direct Line: (632) 635-4785
> Trunkline: (632) 631-8971 Local 146
> Fax: (632) 637-2206
> Level 1 Summit Media Offices, Robinsons Galleria EDSA Cor. Ortigas Ave.,
> Quezon City 1100
^ permalink raw reply
* Re: [patch] Re: Kernels > 2.6.1-mm3 do not boot. - SOLVED
From: Eric @ 2004-01-27 6:37 UTC (permalink / raw)
To: Andrew Morton; +Cc: stoffel, ak, Valdis.Kletnieks, bunk, cova, linux-kernel
In-Reply-To: <20040126215056.4e891086.akpm@osdl.org>
On Monday 26 January 2004 23:50, Andrew Morton wrote:
> Eric <eric@cisu.net> wrote:
> > YES. I finally have a working 2.6.2-rc1-mm3 booted kernel.
> > Lets review folks---
> > reverted -funit-at-a-time
> > patched test_wp_bit so exception tables are sorted sooner
> > reverted md-partition patch
>
> The latter two are understood, but the `-funit-at-a-time' problem is not.
>
> Can you plesae confirm that restoring only -funit-at-a-time again produces
> a crashy kernel? And that you are using a flavour of gcc-3.3? If so, I
> guess we'll need to only enable it for gcc-3.4 and later.
>
Yes, confirmed. My version of gcc, I just sent you adding the
-funit-at-a-time hung after uncompressing the kernel. I booted a secondary
kernel, recompiled without it and all was fine again. Confirmed non-boot for
2.6.2-rc1-mm3 but without a doubt for all kernels previous where
-funit-at-a-time is active in the makefile.
-------------------------
Eric Bambach
Eric at cisu dot net
-------------------------
^ permalink raw reply
* Re: RE: preparing toshiba_acpi driver release
From: Tod Morrison @ 2004-01-27 6:33 UTC (permalink / raw)
To: Karol Kozimor
Cc: Brown, Len, Ducrot Bruno, John Belmonte,
acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20040127031247.GA28233-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org>
I have a Dell Inspiron 8500, I'd be happy to play tester with when you're
looking for a generalized solution. I did have one thought (quite beyond
me to implement though), I was looking at the ACPI VID extensions and
wondered if LCD._DSS could be used to our advantage. It appears that it's
designed to allow the OS to handle video output switching, i.e.
turn off LCD -> turn on CRT
What I thought was that I don't see a reason we couldn't just turn off
LCD output, i.e. call
LCD._DSS(0);
to turn off output, and
LCD._DSS(80000001L);
to turn it back on. Anyway, I'm really unqualified to say whether this
make any sense, it was just a thought.
Tod Morrison <tmorriso-o2OswTf4RFv//ikEAC0814dd74u8MsAO@public.gmane.org>
http://math.cudenver.edu/~tmorriso
"Everyone thinks of changing the world,
but no one thinks of changing himself."
- Leo Tolstoy
On Tue, 27 Jan 2004, Karol Kozimor wrote:
> Thus wrote Brown, Len:
> > I was thinking about ergonomics rather than power-savings -- though
> > probably brightness control has some power savings benefits too -- maybe
> > somebody on the list has numbers for screen power consumption?
>
> Last time I checked it was about 6 W for my 15" display (100% brightness,
> power consumption goes down linearly).
>
> What I consider more important, is the ability to switch the LCD on / off
> by demand -- unfortunately, DPMS is mostly unsupported on modern machines
> and a generic approach (provided it works) could make a difference here.
>
> Once I update the acpi4asus driver, I'll take a look on how those generic
> methods to manipulate video work here and see where it gets me.
>
> Best regards,
>
> --
> Karol 'sziwan' Kozimor
> sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
>
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: 2.6.2-rc1-mm1 oops with X
From: Glenn Johnson @ 2004-01-27 4:47 UTC (permalink / raw)
To: Andrew Morton, linux-kernel
In-Reply-To: <20040127040446.GA2445@srv-lnx2600.matchmail.com>
On Mon, Jan 26, 2004 at 08:04:46PM -0800, Mike Fedyk wrote:
> On Fri, Jan 23, 2004 at 10:33:27PM -0600, Glenn Johnson wrote:
>
> > On Fri, Jan 23, 2004 at 01:56:24PM -0800, Mike Fedyk wrote:
> >
> > > How far does it get through, and at what point in X startup does
> > > the kernel oops?
> >
> > I would say fairly early on but I do not know how to quantify that.
>
> Post your log file, and show where in the log the oops occours...
Okay, below is the XFree log file. It is truncated at the point where
the oops occurs. I sent an e-mail to Andrew confirming that backing out
sysfs-class-10-vc.patch fixes the problem for me.
---begin X log for kernel oops---
XFree86 Version 4.3.0
Release Date: 27 February 2003
X Protocol Version 11, Revision 0, Release 6.6
Build Operating System: Linux 2.6.1-mm5 i686 [ELF]
Build Date: 20 January 2004
Before reporting problems, check http://www.XFree86.Org/
to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/XFree86.0.log", Time: Mon Jan 26 22:33:10 2004
(==) Using config file: "/etc/X11/XF86Config"
(==) ServerLayout "XFree86 Configured"
(**) |-->Screen "Screen0" (0)
(**) | |-->Monitor "Monitor0"
(**) | |-->Device "Card0"
(**) |-->Input Device "Mouse0"
(**) |-->Input Device "Keyboard0"
(==) Keyboard: CustomKeycode disabled
(**) FontPath set to "unix/:-1"
(**) RgbPath set to "/usr/X11R6/lib/X11/rgb"
(**) ModulePath set to "/usr/X11R6/lib/modules"
(++) using VT number 8
---end X log for kernel oops
The VT number it tries to use jumps around. Sometimes it is VT10, VT11,
etc. It should be using VT7 however.
Cheers,
Glenn
^ permalink raw reply
* Re: ax25 support in aprsd
From: John Williams @ 2004-01-27 6:30 UTC (permalink / raw)
To: Adi Linden, linux-hams
In-Reply-To: <Pine.LNX.4.44.0401262346000.11381-100000@mobile.adis.ca>
I am not sure if you can.
Might be a question for the aprsd list.
If the aprs server remembers the last setting then you could setup the filter with an aprs client.
Otherwise try to locate a Canadian aprs server with preset filters, like we have in Australia.
Cheers
John
VK5ZTY
On 26 Jan 2004 at 23:47, Adi Linden wrote:
> Things are beginning to make a lot of sense now. If I want to connect to
> port 14580 with aprsd, how do I get aprsd to send the filter string?
>
> 73,
> Adi
> va3adi
>
>
^ permalink raw reply
* Re: [LARTC] 1000's of classes and filters
From: jayesh rathod @ 2004-01-27 6:20 UTC (permalink / raw)
To: lartc
In-Reply-To: <1074950866.401272d23b136@smwp01.maa.sify.net>
Hi ,
Let me rephrase my problem with more details and some history.
We are running an application on a system which does NAT'ting and shaping. TC and iptable rules are added and deleted at runtime.
A TC rule will be,
tc class add dev eth1 parent 1:1 classid 1:5001 htb rate 256kbit ceil 256kbit
tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip src 10.1.1.1 match ip flowid 1:5001
At peak some 700 to 800 such rules will be present.
Same rules for the other inteface. Deleting a rule is flush out all the rules and reapply :) ( handler could have been used to delete a particular rule, but we have not yet upgraded )
We had ext3 filesystem installed at he beginning. But regularly the box would go down with a kernel panic. The stack trace when this occured is attached.
We then moved to resiserfs filesystem. This time although there was no kernel panic, the box hanged
with junk messages printed in all our application logs. The box doesnt even respond on the console. Hard reboot is the only thing we can do.
Pls find all the details given below. Any suggestions/solutions are welcome.
Regards
Jayesh
System details :
Kernel version : 2.4.23
HTB init, kernel part version 3.13
SCSI Adaptec storage controllers
1 GB RAM
lspci
-----------
00:00.0 Host bridge: Intel Corp.: Unknown device 254c (rev 01)
00:02.0 PCI bridge: Intel Corp. e7500 HI_B Virtual PCI-to-PCI Bridge (F0) (rev 01)
00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub (rev 02)
00:1e.0 PCI bridge: Intel Corp. 82801BA/CA PCI Bridge (rev 42)
00:1f.0 ISA bridge: Intel Corp. 82801CA ISA Bridge (LPC) (rev 02)
00:1f.1 IDE interface: Intel Corp. 82801CA IDE U100 (rev 02)
00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus (rev 02)
01:02.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
02:1c.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 04)
02:1d.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 04)
02:1e.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 04)
02:1f.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 04)
03:01.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08)
03:02.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08)
04:01.0 Ethernet controller: Intel Corp.: Unknown device 100f (rev 01)
04:04.0 SCSI storage controller: Adaptec: Unknown device 801f (rev 03)
04:04.1 SCSI storage controller: Adaptec: Unknown device 801f (rev 03)
Ksymoops output with ext3 filesystem
-----------------------------
Dec 21 06:57:02 theseus kernel: kernel BUG at checkpoint.c:587!
Dec 21 06:57:02 theseus kernel: invalid operand: 0000
Dec 21 06:57:02 theseus kernel: CPU: 0
Dec 21 06:57:02 theseus kernel: EIP: 0010:[<c01662ec>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
Dec 21 06:57:02 theseus kernel: EFLAGS: 00010292
Dec 21 06:57:02 theseus kernel: eax: 00000069 ebx: f6c46660 ecx: fffffffe edx: 00000000
Dec 21 06:57:02 theseus kernel: esi: f7ecc660 edi: f6c46660 ebp: e03fdc10 esp: f7de9e1c
Dec 21 06:57:02 theseus kernel: ds: 0018 es: 0018 ss: 0018
Dec 21 06:57:02 theseus kernel: Process kjournald (pid: 11, stackpage÷de9000)
Dec 21 06:57:02 theseus kernel: Stack: c0257500 c02558c6 c025583d 0000024b c02558a9 f6c46660 c0166173 f7ecc660
Dec 21 06:57:02 theseus kernel: f6c46660 cd59ce60 e03fdc10 c0165b6f e03fdc10 e03fdc10 c01660fb e03fdc10
Dec 21 06:57:02 theseus kernel: 00000012 f19f0540 f19f0540 f19f0d40 f7ecc660 00000000 f7ecc660 c01643ef
Dec 21 06:57:02 theseus kernel: Call Trace: [<c0166173>] [<c0165b6f>] [<c01660fb>] [<c01643ef>] [<c020036c>]
Dec 21 06:57:02 theseus kernel: [<c0109cea>] [<c011a94b>] [<c0109e9c>] [<c01142c3>] [<c0166e26>] [<c0166d00>]
Dec 21 06:57:02 theseus kernel: [<c0107136>] [<c0166d20>]
Dec 21 06:57:02 theseus kernel: Code: 0f 0b 4b 02 3d 58 25 c0 83 c4 14 8b 53 1c 85 d2 74 29 68 a0
>>EIP; c01662ec <__journal_drop_transaction+5c/282> <==Trace; c0166173 <__journal_remove_checkpoint+53/80>
Trace; c0165b6f <__try_to_free_cp_buf+1f/40>
Trace; c01660fb <__journal_clean_checkpoint_list+5b/80>
Trace; c01643ef <journal_commit_transaction+19f/fd4>
Trace; c020036c <net_rx_action+6c/100>
Trace; c0109cea <handle_IRQ_event+3a/70>
Trace; c011a94b <do_softirq+4b/90>
Trace; c0109e9c <do_IRQ+9c/b0>
Trace; c01142c3 <schedule+2e3/310>
Trace; c0166e26 <kjournald+106/1b0>
Trace; c0166d00 <commit_timeout+0/10>
Trace; c0107136 <arch_kernel_thread+26/30>
Trace; c0166d20 <kjournald+0/1b0>
Code; c01662ec <__journal_drop_transaction+5c/282>
00000000 <_EIP>:
Code; c01662ec <__journal_drop_transaction+5c/282> <== 0: 0f 0b ud2a <==Code; c01662ee <__journal_drop_transaction+5e/282>
2: 4b dec %ebx
Code; c01662ef <__journal_drop_transaction+5f/282>
3: 02 3d 58 25 c0 83 add 0x83c02558,%bh
Code; c01662f5 <__journal_drop_transaction+65/282>
9: c4 14 8b les (%ebx,%ecx,4),%edx
Code; c01662f8 <__journal_drop_transaction+68/282>
c: 53 push %ebx
Code; c01662f9 <__journal_drop_transaction+69/282>
d: 1c 85 sbb $0x85,%al
Code; c01662fb <__journal_drop_transaction+6b/282>
f: d2 (bad)
Code; c01662fc <__journal_drop_transaction+6c/282>
10: 74 29 je 3b <_EIP+0x3b> c0166327 <__journal_drop_transaction+97/282>
Code; c01662fe <__journal_drop_transaction+6e/282>
12: 68 a0 00 00 00 push $0xa0
-------------------------------------------------
Still single? Click here to find the perfect match.
http://www.bharatmatrimony.com/cgi-bin/bmclicks1.cgi?141
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* RE: Submission for S2io 10GbE driver
From: Leonid Grossman @ 2004-01-27 6:19 UTC (permalink / raw)
To: 'Jeff Garzik'
Cc: 'Stephen Hemminger', 'Andi Kleen', netdev,
raghavendra.koushik
In-Reply-To: <40160060.4010709@pobox.com>
>
> The ethtool diag stuff is more of a quick sanity test than anything
> exhaustive.
>
> I definitely want to discourage tons of test code in drivers, as its
> code that users will almost-never run, it bloats the driver,
> and can be
> done with a special diag-only driver or diag program (or a
> combination
> of both).
>
> A lot of the 10/100 drivers originated from Donald Becker,
> who typically
> creates a userland (i.e. separate) diag program for each
> driver he writes.
I see the point; we'll go ahead and get rid of the loopback.
We actually have pretty extensive standalone diag tool that is based on
diag driver.
Thanks, Leonid
>
> Jeff
>
>
>
^ permalink raw reply
* Re: [PATCH] 2.6.2-rc2 - MPT Fusion driver 3.00.02 update
From: Jeremy Higdon @ 2004-01-27 6:18 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: James Bottomley, Moore, Eric Dean, SCSI Mailing List
In-Reply-To: <20040126193413.A3302@infradead.org>
On Mon, Jan 26, 2004 at 07:34:13PM +0000, Christoph Hellwig wrote:
> On Mon, Jan 26, 2004 at 11:05:26AM -0600, James Bottomley wrote:
> > > I had avoided it due the comments in the code
> > > from sralston and pdelaney about sg interface
> > > gererating wrong direction in some cases.
> >
> > If you find a problem, I'll fix the generic code...
>
> I think it's just very old comments. We had such a problem in early 2.4
> kernels, but it has been fixed for ages. If it wasn't most of the scsi
> drivers would have a big problem.
Aren't there three interfaces for sg, or did the early ones go away
in 2.6? I recall that we ran into trouble with sg setting the
direction incorrectly in 2.4 kernels when using older interface,
I think.
jeremy
^ permalink raw reply
* Is gcc 3.2.2 suitable for kernel builds?
From: John Heil @ 2004-01-27 6:15 UTC (permalink / raw)
To: linux-kernel
It seems that some gcc 3.2.2 optimizations are generating
bogus code sequences.
Has anyone else had compiler issues w gcc 3.2.2?
Thanks much,
johnh
-
-----------------------------------------------------------------
John Heil
South Coast Software
Custom systems software for UNIX and IBM MVS mainframes
1-714-774-6952
johnhscs@sc-software.com
http://www.sc-software.com
-----------------------------------------------------------------
^ permalink raw reply
* Re: [uPATCH] refuse plain ufs mount
From: Linus Torvalds @ 2004-01-27 6:15 UTC (permalink / raw)
To: Andries.Brouwer; +Cc: akpm, gotom, linux-kernel
In-Reply-To: <UTC200401270407.i0R47oi29367.aeb@smtp.cwi.nl>
On Tue, 27 Jan 2004 Andries.Brouwer@cwi.nl wrote:
>
> Funny how we alternate - when I choose the pure, theoretical point of view
> you prefer practice, when I prefer practice you become pure.
Heh.
I'm actually usually very easy to predict:
- when it comes to "core technology" bugs, I'd much rather fix them
_right_. To the point where I prefer to not fix them at all if the fix
is only hiding the real bug. Then I'd rather leave it as a known bug
and hope the _real_ fix comes in.
- but when it comes to things that are more about "usability", I tend to
try to take the very practical approach. So we'll disagree on things
like "should the kernel autodetect", because I think that's a usability
issue, and consider that it should be as easy for users as possible.
The reiserfs/ufs issue to me is about "usability", not "core technology".
As such, to me it falls under the "practical" heading, and the solution
should be the pragmatic trivial "just test reiserfs first" kind of silly
thing.
Linus
^ permalink raw reply
* Re: [uPATCH] ufs.txt update
From: Frédéric L. W. Meunier @ 2004-01-27 6:13 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <81ektm9dvh.wl@omega.webmasters.gr.jp>
On Tue, 27 Jan 2004, GOTO Masanori wrote:
> At Sun, 25 Jan 2004 09:26:21 +0100,
> Jochen Hein wrote:
> > Andries.Brouwer@cwi.nl writes:
> >
> > > old old format of ufs
> > > - default value, supported os read-only
> > > + supported os read-only
> >
> > s/os/as/ ?
> >
> > > 44bsd used in FreeBSD, NetBSD, OpenBSD
> > > supported os read-write
> >
> > s/os/as/ ?
>
> Exactly. In addition I think removing "default value" from "old"
> entry is no effectiveness, so I revive this sentence.
>
> This patch updates typos and HP-UX description in
> Documentation/filesystems/ufs.txt, suggested by Andries.Brouwer@cwi.nl
> and Jochen Hein <jochen@jochen.org>.
Someone could also add some notes to ufs.txt and the Configure
entry for 2.4 and 2.6 about the lack of UFS2 support, which is
the default since FreeBSD 5.1.
--
http://www.pervalidus.net/contact.html
^ permalink raw reply
* Re: atkbd.c: Unknown key released
From: yoann @ 2004-01-27 6:09 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20040127052507.GF18411@charite.de>
>>I keep getting the following in my syslog whenever I startx:
>
> Which hardware?
>
>>Jan 26 13:43:56 debian kernel: atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
>>Jan 26 13:43:56 debian kernel: atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.
>>Jan 26 13:43:57 debian kernel: atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
>>Jan 26 13:43:57 debian kernel: atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.
>>
>>I don't get the error with the 2.4.24 kernel.
>
> Same here.
same here with a 2.6.2-rc1-mm2
Xfree86 Version: 4.2.1-15 (debian sid)
Yoann
^ permalink raw reply
* Re: Submission for S2io 10GbE driver
From: Jeff Garzik @ 2004-01-27 6:08 UTC (permalink / raw)
To: Leonid Grossman
Cc: 'Stephen Hemminger', 'Andi Kleen', netdev,
raghavendra.koushik
In-Reply-To: <001801c3e497$010671a0$0400a8c0@S2IOtech.com>
Leonid Grossman wrote:
> The loopback test is there as a part of the ethtool's diagnostic option.
>
>
> There are pros and cons of having the test in there I guess, anyone else
> has an opinion on this?
>
> Do other net drivers normally support loopback and other diag tests as a
> part of the ethtool support,
> or they provide little/no support for the option and ship a standalone
> diag program instead?
The ethtool diag stuff is more of a quick sanity test than anything
exhaustive.
I definitely want to discourage tons of test code in drivers, as its
code that users will almost-never run, it bloats the driver, and can be
done with a special diag-only driver or diag program (or a combination
of both).
A lot of the 10/100 drivers originated from Donald Becker, who typically
creates a userland (i.e. separate) diag program for each driver he writes.
Jeff
^ permalink raw reply
* feeding a script from standard input
From: Jeffrey Holle @ 2004-01-27 6:04 UTC (permalink / raw)
To: linux-console
I have a script, call it genpyste that looks like this:
#!/bin/sh
pyste --out=. --multiple --module=mymodule Parameter.pyste
The problem with it is that this is just a start of it.
When I'm done, there will need to be about 30 parameters like
Parameter.pyste.
I'm wondering if I can do something like this from the command line:
ls *.pyste | ./genpyste
What, if anything, can be done to the genpyste script to work like this?
^ permalink raw reply
* [BKPATCH] ACPI for 2.6
From: Len Brown @ 2004-01-27 6:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: ACPI Developers, linux-kernel@vger.kernel.org
Hi Linus, please do a
bk pull http://linux-acpi.bkbits.net/linux-acpi-release-2.6.2
Most all of these updates have been in both 2.4
and the 2.6-mm tree for some time.
thanks,
-Len
ps. a plain patch is also available here:
ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.2/acpi-20040116-2.6.2.diff.gz
This will update the following files:
Documentation/kernel-parameters.txt | 17 ++
arch/i386/boot/setup.S | 2
arch/i386/kernel/acpi/boot.c | 68 ++++++--
arch/i386/kernel/cpu/cpufreq/acpi.c | 71 +++++++--
arch/i386/kernel/dmi_scan.c | 10 -
arch/i386/kernel/io_apic.c | 10 -
arch/i386/kernel/mpparse.c | 19 ++
arch/i386/kernel/setup.c | 9 -
arch/i386/mach-es7000/es7000.c | 2
arch/i386/pci/acpi.c | 13 -
arch/i386/pci/common.c | 5
arch/i386/pci/pci.h | 1
arch/x86_64/kernel/acpi/boot.c | 71 +++++++--
arch/x86_64/kernel/io_apic.c | 8 -
arch/x86_64/kernel/mpparse.c | 2
arch/x86_64/kernel/setup.c | 8 -
drivers/acpi/ac.c | 2
drivers/acpi/asus_acpi.c | 8 -
drivers/acpi/battery.c | 2
drivers/acpi/bus.c | 4
drivers/acpi/button.c | 2
drivers/acpi/dispatcher/dsfield.c | 2
drivers/acpi/dispatcher/dsinit.c | 6
drivers/acpi/dispatcher/dsmethod.c | 6
drivers/acpi/dispatcher/dsmthdat.c | 48 ++++--
drivers/acpi/dispatcher/dsobject.c | 2
drivers/acpi/dispatcher/dsopcode.c | 24 +--
drivers/acpi/dispatcher/dsutils.c | 2
drivers/acpi/dispatcher/dswexec.c | 24 ++-
drivers/acpi/dispatcher/dswload.c | 10 -
drivers/acpi/dispatcher/dswscope.c | 10 -
drivers/acpi/dispatcher/dswstate.c | 2
drivers/acpi/ec.c | 2
drivers/acpi/events/evevent.c | 2
drivers/acpi/events/evgpe.c | 63 ++++----
drivers/acpi/events/evgpeblk.c | 7
drivers/acpi/events/evmisc.c | 5
drivers/acpi/events/evregion.c | 141 ++++++++++++------
drivers/acpi/events/evrgnini.c | 34 +++-
drivers/acpi/events/evsci.c | 2
drivers/acpi/events/evxface.c | 2
drivers/acpi/events/evxfevnt.c | 2
drivers/acpi/events/evxfregn.c | 26 ++-
drivers/acpi/executer/exconfig.c | 2
drivers/acpi/executer/exconvrt.c | 2
drivers/acpi/executer/excreate.c | 2
drivers/acpi/executer/exdump.c | 52 +++---
drivers/acpi/executer/exfield.c | 2
drivers/acpi/executer/exfldio.c | 186 ++++++++++++------------
drivers/acpi/executer/exmisc.c | 8 -
drivers/acpi/executer/exmutex.c | 14 -
drivers/acpi/executer/exnames.c | 2
drivers/acpi/executer/exoparg1.c | 5
drivers/acpi/executer/exoparg2.c | 2
drivers/acpi/executer/exoparg3.c | 7
drivers/acpi/executer/exoparg6.c | 2
drivers/acpi/executer/exprep.c | 6
drivers/acpi/executer/exregion.c | 12 -
drivers/acpi/executer/exresnte.c | 2
drivers/acpi/executer/exresolv.c | 8 -
drivers/acpi/executer/exresop.c | 6
drivers/acpi/executer/exstore.c | 5
drivers/acpi/executer/exstoren.c | 2
drivers/acpi/executer/exstorob.c | 2
drivers/acpi/executer/exsystem.c | 23 ++
drivers/acpi/executer/exutils.c | 2
drivers/acpi/fan.c | 2
drivers/acpi/hardware/hwacpi.c | 15 -
drivers/acpi/hardware/hwgpe.c | 16 --
drivers/acpi/hardware/hwregs.c | 14 -
drivers/acpi/hardware/hwsleep.c | 167 +++++++++++++++------
drivers/acpi/hardware/hwtimer.c | 2
drivers/acpi/namespace/nsaccess.c | 10 -
drivers/acpi/namespace/nsalloc.c | 9 -
drivers/acpi/namespace/nsdump.c | 39 ++---
drivers/acpi/namespace/nsdumpdv.c | 4
drivers/acpi/namespace/nseval.c | 2
drivers/acpi/namespace/nsinit.c | 65 ++++----
drivers/acpi/namespace/nsload.c | 2
drivers/acpi/namespace/nsnames.c | 2
drivers/acpi/namespace/nsobject.c | 9 -
drivers/acpi/namespace/nsparse.c | 2
drivers/acpi/namespace/nssearch.c | 6
drivers/acpi/namespace/nsutils.c | 8 -
drivers/acpi/namespace/nswalk.c | 2
drivers/acpi/namespace/nsxfeval.c | 2
drivers/acpi/namespace/nsxfname.c | 4
drivers/acpi/namespace/nsxfobj.c | 2
drivers/acpi/osl.c | 13 -
drivers/acpi/parser/psargs.c | 6
drivers/acpi/parser/psopcode.c | 2
drivers/acpi/parser/psparse.c | 6
drivers/acpi/parser/psscope.c | 2
drivers/acpi/parser/pstree.c | 2
drivers/acpi/parser/psutils.c | 2
drivers/acpi/parser/pswalk.c | 2
drivers/acpi/parser/psxface.c | 36 +++-
drivers/acpi/pci_link.c | 180 +++++++++++++++++++----
drivers/acpi/pci_root.c | 95 ------------
drivers/acpi/power.c | 2
drivers/acpi/processor.c | 2
drivers/acpi/resources/rsaddr.c | 2
drivers/acpi/resources/rscalc.c | 6
drivers/acpi/resources/rscreate.c | 4
drivers/acpi/resources/rsdump.c | 20 --
drivers/acpi/resources/rsio.c | 2
drivers/acpi/resources/rsirq.c | 40 ++---
drivers/acpi/resources/rslist.c | 6
drivers/acpi/resources/rsmemory.c | 2
drivers/acpi/resources/rsmisc.c | 2
drivers/acpi/resources/rsutils.c | 2
drivers/acpi/resources/rsxface.c | 2
drivers/acpi/scan.c | 11 -
drivers/acpi/sleep/proc.c | 3
drivers/acpi/tables.c | 43 ++++-
drivers/acpi/tables/tbconvrt.c | 10 -
drivers/acpi/tables/tbget.c | 12 -
drivers/acpi/tables/tbgetall.c | 5
drivers/acpi/tables/tbinstal.c | 2
drivers/acpi/tables/tbrsdt.c | 16 +-
drivers/acpi/tables/tbutils.c | 2
drivers/acpi/tables/tbxface.c | 4
drivers/acpi/tables/tbxfroot.c | 9 -
drivers/acpi/thermal.c | 5
drivers/acpi/toshiba_acpi.c | 2
drivers/acpi/utilities/utalloc.c | 57 +------
drivers/acpi/utilities/utcopy.c | 2
drivers/acpi/utilities/utdebug.c | 4
drivers/acpi/utilities/utdelete.c | 6
drivers/acpi/utilities/uteval.c | 6
drivers/acpi/utilities/utglobal.c | 101 ++++++++++++-
drivers/acpi/utilities/utinit.c | 2
drivers/acpi/utilities/utmath.c | 2
drivers/acpi/utilities/utmisc.c | 14 +
drivers/acpi/utilities/utobject.c | 30 ---
drivers/acpi/utilities/utxface.c | 2
include/acpi/acconfig.h | 8 -
include/acpi/acdebug.h | 2
include/acpi/acdisasm.h | 2
include/acpi/acdispat.h | 2
include/acpi/acevents.h | 13 +
include/acpi/acexcep.h | 2
include/acpi/acglobal.h | 5
include/acpi/achware.h | 2
include/acpi/acinterp.h | 2
include/acpi/aclocal.h | 2
include/acpi/acmacros.h | 29 +--
include/acpi/acnamesp.h | 2
include/acpi/acobject.h | 37 ++--
include/acpi/acoutput.h | 2
include/acpi/acparser.h | 2
include/acpi/acpi.h | 2
include/acpi/acpi_drivers.h | 4
include/acpi/acpiosxf.h | 2
include/acpi/acpixf.h | 2
include/acpi/acresrc.h | 2
include/acpi/acstruct.h | 2
include/acpi/actables.h | 2
include/acpi/actbl.h | 9 -
include/acpi/actbl1.h | 2
include/acpi/actbl2.h | 2
include/acpi/actypes.h | 2
include/acpi/acutils.h | 10 +
include/acpi/amlcode.h | 2
include/acpi/amlresrc.h | 2
include/acpi/platform/acenv.h | 2
include/acpi/platform/acgcc.h | 2
include/acpi/platform/aclinux.h | 2
include/acpi/processor.h | 2
include/asm-i386/acpi.h | 10 +
include/asm-i386/system.h | 1
include/asm-x86_64/acpi.h | 27 +--
172 files changed, 1493 insertions(+), 992 deletions(-)
through these ChangeSets:
<len.brown@intel.com> (04/01/26 1.1491.1.7)
[ACPI] handle system with NULL DSDT and valid XDSDT
from ia64 via Alex Williamson
<len.brown@intel.com> (04/01/26 1.1491.1.6)
[ACPI] move zero initialized data to .bss
from Jes Sorensen
<len.brown@intel.com> (04/01/26 1.1491.1.5)
[ACPI] on SCI allocation failure, don't mistakenly free IRQ0
from Jes Sorensen
<len.brown@intel.com> (04/01/26 1.1491.1.4)
[ACPI] fix ACPI spec URL in comment - from Randy Dunlap
<len.brown@intel.com> (04/01/23 1.1491.1.3)
[ACPI] acpi_bus_add() ignored _STA's return value
from Bjorn Helgaas
<len.brown@intel.com> (04/01/17 1.1491.1.2)
[ACPI] ACPICA 20040116 from Bob Moore
The purpose of this release is primarily to update the copyright
years
in each module, thus causing a huge number of diffs. There are a few
small functional changes, however.
Improved error messages when there is a problem finding one or more
of
the required base ACPI tables
Reintroduced the definition of APIC_HEADER in actbl.h
Changed definition of MADT_ADDRESS_OVERRIDE to 64 bits (actbl.h)
Removed extraneous reference to NewObj in dsmthdat.c
<len.brown@intel.com> (04/01/15 1.1491.1.1)
[ACPI] change hard-coded IO width to programmable width
http://bugzilla.kernel.org/show_bug.cgi?id=1349
from David Shaohua Li and Venatesh Pallipadi
<len.brown@intel.com> (03/12/16 1.1489)
[ACPI] set acpi_disabled=1 on failure for clean /proc
http://bugzilla.kernel.org/show_bug.cgi?id=991
<len.brown@intel.com> (03/12/16 1.1488)
[ACPI] /proc/acpi files appear in /proc if acpi=off (Shaohua David
Li)
<len.brown@intel.com> (03/12/15 1.1487)
[ACPI] delete old _TRA code formerly used just by IA64. (Bjorn
Helgaas)
The current approach is to walk the _CRS in pcibios_scan_root()
using acpi_walk_resources().
<len.brown@intel.com> (03/12/11 1.1486)
[ACPI] Update Linux to ACPICA 20031203 (Bob Moore)
Changed the initialization of Operation Regions during subsystem init
to
perform two entire walks of the ACPI namespace; The first to
initialize
the regions themselves, the second to execute the _REG methods. This
fixed some interdependencies across _REG methods found on some
machines.
Fixed a problem where a Store(Local0, Local1) could simply update the
object reference count, and not create a new copy of the object if
the
Local1 is uninitialized.
Implemented support for the _SST reserved method during sleep
transitions.
Implemented support to clear the SLP_TYP and SLP_EN bits when waking
up,
this is apparently required by some machines.
When sleeping, clear the wake status only if SleepState is not S5.
Fixed a problem in AcpiRsExtendedIrqResource() where an incorrect
pointer arithmetic advanced a string pointer too far.
Fixed a problem in AcpiTbGetTablePtr() where a garbage pointer could
be
returned if the requested table has not been loaded.
Within the support for IRQ resources, restructured the handling of
the
active and edge/level bits.
Fixed a few problems in AcpiPsxExecute() where memory could be leaked
under certain error conditions.
Improved error messages for the cases where the ACPI mode could not
be
entered.
<len.brown@intel.com> (03/12/11 1.1485)
[ACPI] update Linux to ACPICA 20031029 (Bob Moore)
Fixed a problem where a level-triggered GPE with an associated _Lxx
control method was incorrectly cleared twice.
Fixed a problem with the Field support code where an access can occur
beyond the end-of-region if the field is non-aligned but extends to
the
very end of the parent region (resulted in an AE_AML_REGION_LIMIT
exception.)
Fixed a problem with ACPI Fixed Events where an RT Clock handler
would
not get invoked on an RTC event. The RTC event bitmasks for the PM1
registers were not being initialized properly.
Implemented support for executing _STA and _INI methods for Processor
objects. Although this is currently not part of the ACPI
specification,
there is existing ASL code that depends on the init-time execution of
these methods.
Implemented and deployed a GetDescriptorName function to decode the
various types of internal descriptors. Guards against null
descriptors
during debug output also.
Implemented and deployed a GetNodeName function to extract the
4-character namespace node name. This function simplifies the debug
and
error output, as well as guarding against null pointers during
output.
Implemented and deployed the ACPI_FORMAT_UINT64 helper macro to
simplify
the debug and error output of 64-bit integers. This macro replaces
the
HIDWORD and LODWORD macros for dumping these integers.
Updated the implementation of the Stall() operator to only call
AcpiOsStall(), and also return an error if the operand is larger than
255. This preserves the required behavior of not relinquishing the
processor, as would happen if AcpiOsSleep() was called for "long
stalls".
Constructs of the form "Store(LocalX,LocalX)" where LocalX is not
initialized are now treated as NOOPs.
Cleaned up a handful of warnings during 64-bit generation.
Fixed a reported error where and incorrect GPE number was passed to
the
GPE dispatch handler. This value is only used for error output,
however. Used this opportunity to clean up and streamline the GPE
dispatch code.
<len.brown@intel.com> (03/12/11 1.1484)
[ACPI] revert two fixes in preparation for ACPICA merge
<len.brown@intel.com> (03/12/11 1.1483)
[ACPI] replace multiple flags with acpi_noirq -- ala 2.4
<len.brown@intel.com> (03/12/10 1.1481)
[ACPI] set APIC ACPI SCI OVR default to level/low
http://bugzilla.kernel.org/show_bug.cgi?id=1351
<len.brown@intel.com> (03/12/02 1.1480)
[ACPI] add warning to thermal shutdown (Pavel Machek)
<len.brown@intel.com> (03/11/30 1.1479)
[ACPI] sync with 2.4.23
Re-enable IRQ balacning if IOAPIC mode
http://bugzilla.kernel.org/show_bug.cgi?id=1440
Also allow IRQ balancing in PIC mode if "acpi_irq_balance"
http://bugzilla.kernel.org/show_bug.cgi?id=1391
<len.brown@intel.com> (03/11/21 1.1477)
[ACPI] prevent ES7000 tweak from breaking i386 IOAPIC (Andrew de
Quincey)
<len.brown@intel.com> (03/11/20 1.1476)
[ACPI] fix compiler warning (Andrew Morton)
<len.brown@intel.com> (03/11/18 1.1450.2.3)
[ACPI] "acpi_pic_sci=edge" in case platform requires Edge Triggered
SCI
http://bugzilla.kernel.org/show_bug.cgi?id=1390
<len.brown@intel.com> (03/11/18 1.1450.2.2)
[ACPI] print_IO_APIC() only after it is programmed
http://bugzilla.kernel.org/show_bug.cgi?id=1177
<len.brown@intel.com> (03/11/07 1.1414.1.7)
[ACPI] In ACPI mode, delay print_IO_APIC() to make its output valid.
http://bugzilla.kernel.org/show_bug.cgi?id=1177
<len.brown@intel.com> (03/11/07 1.1414.1.6)
[ACPI] If ACPI is disabled by DMI BIOS date, then
turn it off completely, including table parsing for HT.
This avoids a crash due to ancient garbled tables.
acpi=force is available to over-ride this default.
http://bugzilla.kernel.org/show_bug.cgi?id=1434
^ permalink raw reply
* [BKPATCH] ACPI for 2.6
From: Len Brown @ 2004-01-27 6:03 UTC (permalink / raw)
To: Linus Torvalds
Cc: ACPI Developers,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Hi Linus, please do a
bk pull http://linux-acpi.bkbits.net/linux-acpi-release-2.6.2
Most all of these updates have been in both 2.4
and the 2.6-mm tree for some time.
thanks,
-Len
ps. a plain patch is also available here:
ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.2/acpi-20040116-2.6.2.diff.gz
This will update the following files:
Documentation/kernel-parameters.txt | 17 ++
arch/i386/boot/setup.S | 2
arch/i386/kernel/acpi/boot.c | 68 ++++++--
arch/i386/kernel/cpu/cpufreq/acpi.c | 71 +++++++--
arch/i386/kernel/dmi_scan.c | 10 -
arch/i386/kernel/io_apic.c | 10 -
arch/i386/kernel/mpparse.c | 19 ++
arch/i386/kernel/setup.c | 9 -
arch/i386/mach-es7000/es7000.c | 2
arch/i386/pci/acpi.c | 13 -
arch/i386/pci/common.c | 5
arch/i386/pci/pci.h | 1
arch/x86_64/kernel/acpi/boot.c | 71 +++++++--
arch/x86_64/kernel/io_apic.c | 8 -
arch/x86_64/kernel/mpparse.c | 2
arch/x86_64/kernel/setup.c | 8 -
drivers/acpi/ac.c | 2
drivers/acpi/asus_acpi.c | 8 -
drivers/acpi/battery.c | 2
drivers/acpi/bus.c | 4
drivers/acpi/button.c | 2
drivers/acpi/dispatcher/dsfield.c | 2
drivers/acpi/dispatcher/dsinit.c | 6
drivers/acpi/dispatcher/dsmethod.c | 6
drivers/acpi/dispatcher/dsmthdat.c | 48 ++++--
drivers/acpi/dispatcher/dsobject.c | 2
drivers/acpi/dispatcher/dsopcode.c | 24 +--
drivers/acpi/dispatcher/dsutils.c | 2
drivers/acpi/dispatcher/dswexec.c | 24 ++-
drivers/acpi/dispatcher/dswload.c | 10 -
drivers/acpi/dispatcher/dswscope.c | 10 -
drivers/acpi/dispatcher/dswstate.c | 2
drivers/acpi/ec.c | 2
drivers/acpi/events/evevent.c | 2
drivers/acpi/events/evgpe.c | 63 ++++----
drivers/acpi/events/evgpeblk.c | 7
drivers/acpi/events/evmisc.c | 5
drivers/acpi/events/evregion.c | 141 ++++++++++++------
drivers/acpi/events/evrgnini.c | 34 +++-
drivers/acpi/events/evsci.c | 2
drivers/acpi/events/evxface.c | 2
drivers/acpi/events/evxfevnt.c | 2
drivers/acpi/events/evxfregn.c | 26 ++-
drivers/acpi/executer/exconfig.c | 2
drivers/acpi/executer/exconvrt.c | 2
drivers/acpi/executer/excreate.c | 2
drivers/acpi/executer/exdump.c | 52 +++---
drivers/acpi/executer/exfield.c | 2
drivers/acpi/executer/exfldio.c | 186 ++++++++++++------------
drivers/acpi/executer/exmisc.c | 8 -
drivers/acpi/executer/exmutex.c | 14 -
drivers/acpi/executer/exnames.c | 2
drivers/acpi/executer/exoparg1.c | 5
drivers/acpi/executer/exoparg2.c | 2
drivers/acpi/executer/exoparg3.c | 7
drivers/acpi/executer/exoparg6.c | 2
drivers/acpi/executer/exprep.c | 6
drivers/acpi/executer/exregion.c | 12 -
drivers/acpi/executer/exresnte.c | 2
drivers/acpi/executer/exresolv.c | 8 -
drivers/acpi/executer/exresop.c | 6
drivers/acpi/executer/exstore.c | 5
drivers/acpi/executer/exstoren.c | 2
drivers/acpi/executer/exstorob.c | 2
drivers/acpi/executer/exsystem.c | 23 ++
drivers/acpi/executer/exutils.c | 2
drivers/acpi/fan.c | 2
drivers/acpi/hardware/hwacpi.c | 15 -
drivers/acpi/hardware/hwgpe.c | 16 --
drivers/acpi/hardware/hwregs.c | 14 -
drivers/acpi/hardware/hwsleep.c | 167 +++++++++++++++------
drivers/acpi/hardware/hwtimer.c | 2
drivers/acpi/namespace/nsaccess.c | 10 -
drivers/acpi/namespace/nsalloc.c | 9 -
drivers/acpi/namespace/nsdump.c | 39 ++---
drivers/acpi/namespace/nsdumpdv.c | 4
drivers/acpi/namespace/nseval.c | 2
drivers/acpi/namespace/nsinit.c | 65 ++++----
drivers/acpi/namespace/nsload.c | 2
drivers/acpi/namespace/nsnames.c | 2
drivers/acpi/namespace/nsobject.c | 9 -
drivers/acpi/namespace/nsparse.c | 2
drivers/acpi/namespace/nssearch.c | 6
drivers/acpi/namespace/nsutils.c | 8 -
drivers/acpi/namespace/nswalk.c | 2
drivers/acpi/namespace/nsxfeval.c | 2
drivers/acpi/namespace/nsxfname.c | 4
drivers/acpi/namespace/nsxfobj.c | 2
drivers/acpi/osl.c | 13 -
drivers/acpi/parser/psargs.c | 6
drivers/acpi/parser/psopcode.c | 2
drivers/acpi/parser/psparse.c | 6
drivers/acpi/parser/psscope.c | 2
drivers/acpi/parser/pstree.c | 2
drivers/acpi/parser/psutils.c | 2
drivers/acpi/parser/pswalk.c | 2
drivers/acpi/parser/psxface.c | 36 +++-
drivers/acpi/pci_link.c | 180 +++++++++++++++++++----
drivers/acpi/pci_root.c | 95 ------------
drivers/acpi/power.c | 2
drivers/acpi/processor.c | 2
drivers/acpi/resources/rsaddr.c | 2
drivers/acpi/resources/rscalc.c | 6
drivers/acpi/resources/rscreate.c | 4
drivers/acpi/resources/rsdump.c | 20 --
drivers/acpi/resources/rsio.c | 2
drivers/acpi/resources/rsirq.c | 40 ++---
drivers/acpi/resources/rslist.c | 6
drivers/acpi/resources/rsmemory.c | 2
drivers/acpi/resources/rsmisc.c | 2
drivers/acpi/resources/rsutils.c | 2
drivers/acpi/resources/rsxface.c | 2
drivers/acpi/scan.c | 11 -
drivers/acpi/sleep/proc.c | 3
drivers/acpi/tables.c | 43 ++++-
drivers/acpi/tables/tbconvrt.c | 10 -
drivers/acpi/tables/tbget.c | 12 -
drivers/acpi/tables/tbgetall.c | 5
drivers/acpi/tables/tbinstal.c | 2
drivers/acpi/tables/tbrsdt.c | 16 +-
drivers/acpi/tables/tbutils.c | 2
drivers/acpi/tables/tbxface.c | 4
drivers/acpi/tables/tbxfroot.c | 9 -
drivers/acpi/thermal.c | 5
drivers/acpi/toshiba_acpi.c | 2
drivers/acpi/utilities/utalloc.c | 57 +------
drivers/acpi/utilities/utcopy.c | 2
drivers/acpi/utilities/utdebug.c | 4
drivers/acpi/utilities/utdelete.c | 6
drivers/acpi/utilities/uteval.c | 6
drivers/acpi/utilities/utglobal.c | 101 ++++++++++++-
drivers/acpi/utilities/utinit.c | 2
drivers/acpi/utilities/utmath.c | 2
drivers/acpi/utilities/utmisc.c | 14 +
drivers/acpi/utilities/utobject.c | 30 ---
drivers/acpi/utilities/utxface.c | 2
include/acpi/acconfig.h | 8 -
include/acpi/acdebug.h | 2
include/acpi/acdisasm.h | 2
include/acpi/acdispat.h | 2
include/acpi/acevents.h | 13 +
include/acpi/acexcep.h | 2
include/acpi/acglobal.h | 5
include/acpi/achware.h | 2
include/acpi/acinterp.h | 2
include/acpi/aclocal.h | 2
include/acpi/acmacros.h | 29 +--
include/acpi/acnamesp.h | 2
include/acpi/acobject.h | 37 ++--
include/acpi/acoutput.h | 2
include/acpi/acparser.h | 2
include/acpi/acpi.h | 2
include/acpi/acpi_drivers.h | 4
include/acpi/acpiosxf.h | 2
include/acpi/acpixf.h | 2
include/acpi/acresrc.h | 2
include/acpi/acstruct.h | 2
include/acpi/actables.h | 2
include/acpi/actbl.h | 9 -
include/acpi/actbl1.h | 2
include/acpi/actbl2.h | 2
include/acpi/actypes.h | 2
include/acpi/acutils.h | 10 +
include/acpi/amlcode.h | 2
include/acpi/amlresrc.h | 2
include/acpi/platform/acenv.h | 2
include/acpi/platform/acgcc.h | 2
include/acpi/platform/aclinux.h | 2
include/acpi/processor.h | 2
include/asm-i386/acpi.h | 10 +
include/asm-i386/system.h | 1
include/asm-x86_64/acpi.h | 27 +--
172 files changed, 1493 insertions(+), 992 deletions(-)
through these ChangeSets:
<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (04/01/26 1.1491.1.7)
[ACPI] handle system with NULL DSDT and valid XDSDT
from ia64 via Alex Williamson
<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (04/01/26 1.1491.1.6)
[ACPI] move zero initialized data to .bss
from Jes Sorensen
<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (04/01/26 1.1491.1.5)
[ACPI] on SCI allocation failure, don't mistakenly free IRQ0
from Jes Sorensen
<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (04/01/26 1.1491.1.4)
[ACPI] fix ACPI spec URL in comment - from Randy Dunlap
<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (04/01/23 1.1491.1.3)
[ACPI] acpi_bus_add() ignored _STA's return value
from Bjorn Helgaas
<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (04/01/17 1.1491.1.2)
[ACPI] ACPICA 20040116 from Bob Moore
The purpose of this release is primarily to update the copyright
years
in each module, thus causing a huge number of diffs. There are a few
small functional changes, however.
Improved error messages when there is a problem finding one or more
of
the required base ACPI tables
Reintroduced the definition of APIC_HEADER in actbl.h
Changed definition of MADT_ADDRESS_OVERRIDE to 64 bits (actbl.h)
Removed extraneous reference to NewObj in dsmthdat.c
<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (04/01/15 1.1491.1.1)
[ACPI] change hard-coded IO width to programmable width
http://bugzilla.kernel.org/show_bug.cgi?id=1349
from David Shaohua Li and Venatesh Pallipadi
<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/12/16 1.1489)
[ACPI] set acpi_disabled=1 on failure for clean /proc
http://bugzilla.kernel.org/show_bug.cgi?id=991
<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/12/16 1.1488)
[ACPI] /proc/acpi files appear in /proc if acpi=off (Shaohua David
Li)
<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/12/15 1.1487)
[ACPI] delete old _TRA code formerly used just by IA64. (Bjorn
Helgaas)
The current approach is to walk the _CRS in pcibios_scan_root()
using acpi_walk_resources().
<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/12/11 1.1486)
[ACPI] Update Linux to ACPICA 20031203 (Bob Moore)
Changed the initialization of Operation Regions during subsystem init
to
perform two entire walks of the ACPI namespace; The first to
initialize
the regions themselves, the second to execute the _REG methods. This
fixed some interdependencies across _REG methods found on some
machines.
Fixed a problem where a Store(Local0, Local1) could simply update the
object reference count, and not create a new copy of the object if
the
Local1 is uninitialized.
Implemented support for the _SST reserved method during sleep
transitions.
Implemented support to clear the SLP_TYP and SLP_EN bits when waking
up,
this is apparently required by some machines.
When sleeping, clear the wake status only if SleepState is not S5.
Fixed a problem in AcpiRsExtendedIrqResource() where an incorrect
pointer arithmetic advanced a string pointer too far.
Fixed a problem in AcpiTbGetTablePtr() where a garbage pointer could
be
returned if the requested table has not been loaded.
Within the support for IRQ resources, restructured the handling of
the
active and edge/level bits.
Fixed a few problems in AcpiPsxExecute() where memory could be leaked
under certain error conditions.
Improved error messages for the cases where the ACPI mode could not
be
entered.
<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/12/11 1.1485)
[ACPI] update Linux to ACPICA 20031029 (Bob Moore)
Fixed a problem where a level-triggered GPE with an associated _Lxx
control method was incorrectly cleared twice.
Fixed a problem with the Field support code where an access can occur
beyond the end-of-region if the field is non-aligned but extends to
the
very end of the parent region (resulted in an AE_AML_REGION_LIMIT
exception.)
Fixed a problem with ACPI Fixed Events where an RT Clock handler
would
not get invoked on an RTC event. The RTC event bitmasks for the PM1
registers were not being initialized properly.
Implemented support for executing _STA and _INI methods for Processor
objects. Although this is currently not part of the ACPI
specification,
there is existing ASL code that depends on the init-time execution of
these methods.
Implemented and deployed a GetDescriptorName function to decode the
various types of internal descriptors. Guards against null
descriptors
during debug output also.
Implemented and deployed a GetNodeName function to extract the
4-character namespace node name. This function simplifies the debug
and
error output, as well as guarding against null pointers during
output.
Implemented and deployed the ACPI_FORMAT_UINT64 helper macro to
simplify
the debug and error output of 64-bit integers. This macro replaces
the
HIDWORD and LODWORD macros for dumping these integers.
Updated the implementation of the Stall() operator to only call
AcpiOsStall(), and also return an error if the operand is larger than
255. This preserves the required behavior of not relinquishing the
processor, as would happen if AcpiOsSleep() was called for "long
stalls".
Constructs of the form "Store(LocalX,LocalX)" where LocalX is not
initialized are now treated as NOOPs.
Cleaned up a handful of warnings during 64-bit generation.
Fixed a reported error where and incorrect GPE number was passed to
the
GPE dispatch handler. This value is only used for error output,
however. Used this opportunity to clean up and streamline the GPE
dispatch code.
<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/12/11 1.1484)
[ACPI] revert two fixes in preparation for ACPICA merge
<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/12/11 1.1483)
[ACPI] replace multiple flags with acpi_noirq -- ala 2.4
<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/12/10 1.1481)
[ACPI] set APIC ACPI SCI OVR default to level/low
http://bugzilla.kernel.org/show_bug.cgi?id=1351
<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/12/02 1.1480)
[ACPI] add warning to thermal shutdown (Pavel Machek)
<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/11/30 1.1479)
[ACPI] sync with 2.4.23
Re-enable IRQ balacning if IOAPIC mode
http://bugzilla.kernel.org/show_bug.cgi?id=1440
Also allow IRQ balancing in PIC mode if "acpi_irq_balance"
http://bugzilla.kernel.org/show_bug.cgi?id=1391
<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/11/21 1.1477)
[ACPI] prevent ES7000 tweak from breaking i386 IOAPIC (Andrew de
Quincey)
<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/11/20 1.1476)
[ACPI] fix compiler warning (Andrew Morton)
<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/11/18 1.1450.2.3)
[ACPI] "acpi_pic_sci=edge" in case platform requires Edge Triggered
SCI
http://bugzilla.kernel.org/show_bug.cgi?id=1390
<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/11/18 1.1450.2.2)
[ACPI] print_IO_APIC() only after it is programmed
http://bugzilla.kernel.org/show_bug.cgi?id=1177
<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/11/07 1.1414.1.7)
[ACPI] In ACPI mode, delay print_IO_APIC() to make its output valid.
http://bugzilla.kernel.org/show_bug.cgi?id=1177
<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/11/07 1.1414.1.6)
[ACPI] If ACPI is disabled by DMI BIOS date, then
turn it off completely, including table parsing for HT.
This avoids a crash due to ancient garbled tables.
acpi=force is available to over-ride this default.
http://bugzilla.kernel.org/show_bug.cgi?id=1434
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: [BKPATCH] ACPI for 2.4
From: Nate Lawson @ 2004-01-27 6:01 UTC (permalink / raw)
To: Len Brown; +Cc: ACPI Developers
In-Reply-To: <1075182740.2489.40.camel-D2Zvc0uNKG8@public.gmane.org>
On Mon, 27 Jan 2004, Len Brown wrote:
> Hi Marcelo, please do a
>
> bk pull http://linux-acpi.bkbits.net/linux-acpi-release-2.4.25
>
> thanks,
> -Len
>
> ps. a plain patch is also available here:
> ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.4.25/acpi-20040116-2.4.25.diff.gz
>
> Reintroduced the definition of APIC_HEADER in actbl.h
>
> Changed definition of MADT_ADDRESS_OVERRIDE to 64 bits (actbl.h)
>
> Removed extraneous reference to NewObj in dsmthdat.c
The above submitted by Nate Lawson.
-Nate
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: [patch] Re: Kernels > 2.6.1-mm3 do not boot. - SOLVED
From: Eric @ 2004-01-27 5:57 UTC (permalink / raw)
To: Andrew Morton; +Cc: stoffel, ak, Valdis.Kletnieks, bunk, cova, linux-kernel
In-Reply-To: <20040126215056.4e891086.akpm@osdl.org>
On Monday 26 January 2004 23:50, Andrew Morton wrote:
> Eric <eric@cisu.net> wrote:
> > YES. I finally have a working 2.6.2-rc1-mm3 booted kernel.
> > Lets review folks---
> > reverted -funit-at-a-time
> > patched test_wp_bit so exception tables are sorted sooner
> > reverted md-partition patch
>
> The latter two are understood, but the `-funit-at-a-time' problem is not.
>
> Can you plesae confirm that restoring only -funit-at-a-time again produces
> a crashy kernel? And that you are using a flavour of gcc-3.3? If so, I
> guess we'll need to only enable it for gcc-3.4 and later.
Yea ill try it right now. Ill get back to you in about half hour, probably
less. Would you like me to send you a complied kernel or some files that my
compiler has generated if its still crashy?
I remember reading somewhere on lkml about another problem that hung RIGHT on
boot and it was related to GCC producing an invalid instruction for that
particular processor. This smells of badly generated code. Heres a recap of
my GCC:
SuSE Linux 8.2
eric:/usr/src/linux-2.6.2-rc1-mm3/linux-2.6.1 # gcc -v
Reading specs from /usr/lib/gcc-lib/i486-suse-linux/3.3/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib
--enable-languages=c,c++,f77,objc,java,ada --disable-checking --enable-libgcj
--with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib
--with-system-zlib --enable-shared --enable-__cxa_atexit i486-suse-linux
Thread model: posix
gcc version 3.3 20030226 (prerelease) (SuSE Linux)
-------------------------
Eric Bambach
Eric at cisu dot net
-------------------------
^ permalink raw reply
* Re: [patch] Re: Kernels > 2.6.1-mm3 do not boot. - SOLVED
From: Andrew Morton @ 2004-01-27 5:50 UTC (permalink / raw)
To: Eric; +Cc: stoffel, ak, Valdis.Kletnieks, bunk, cova, linux-kernel
In-Reply-To: <200401262343.35633.eric@cisu.net>
Eric <eric@cisu.net> wrote:
>
> YES. I finally have a working 2.6.2-rc1-mm3 booted kernel.
> Lets review folks---
> reverted -funit-at-a-time
> patched test_wp_bit so exception tables are sorted sooner
> reverted md-partition patch
The latter two are understood, but the `-funit-at-a-time' problem is not.
Can you plesae confirm that restoring only -funit-at-a-time again produces
a crashy kernel? And that you are using a flavour of gcc-3.3? If so, I
guess we'll need to only enable it for gcc-3.4 and later.
^ permalink raw reply
* Re: [ANNOUNCE] udev 015 release
From: Chris Friesen @ 2004-01-27 5:52 UTC (permalink / raw)
To: Greg KH; +Cc: linux-hotplug-devel, linux-kernel
In-Reply-To: <20040126215036.GA6906@kroah.com>
Greg KH wrote:
> I've released the 015 version of udev. It can be found at:
> kernel.org/pub/linux/utils/kernel/hotplug/udev-015.tar.gz
> Also in this release is the start of a udev daemon. It's really in 3
> pieces:
> udevsend - sends the hotplug message to the udev daemon
> udevd - the udev daemon, gets the hotplug messages, sorts them
> in proper order, and passes them off to the udev program
> to act apon them.
> udev - still the same.
I'm curious about the rationale behind breaking it up into multiple chunks.
udevsend being separate I assume is so that it can be easily called from
a script while still keeping something persistant?
I'm not sure I see what separating udev and udevd into different
binaries actually buys you. Wouldn't it be just as easy to make udev be
the daemon based on runtime options or something?
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com
^ permalink raw reply
* [BKPATCH] ACPI for 2.4
From: Len Brown @ 2004-01-27 5:52 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: ACPI Developers
Hi Marcelo, please do a
bk pull http://linux-acpi.bkbits.net/linux-acpi-release-2.4.25
thanks,
-Len
ps. a plain patch is also available here:
ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.4.25/acpi-20040116-2.4.25.diff.gz
This will update the following files:
drivers/acpi/ac.c | 2
drivers/acpi/asus_acpi.c | 8 +-
drivers/acpi/battery.c | 2
drivers/acpi/button.c | 2
drivers/acpi/dispatcher/dsfield.c | 2
drivers/acpi/dispatcher/dsinit.c | 2
drivers/acpi/dispatcher/dsmethod.c | 2
drivers/acpi/dispatcher/dsmthdat.c | 3
drivers/acpi/dispatcher/dsobject.c | 2
drivers/acpi/dispatcher/dsopcode.c | 2
drivers/acpi/dispatcher/dsutils.c | 2
drivers/acpi/dispatcher/dswexec.c | 2
drivers/acpi/dispatcher/dswload.c | 2
drivers/acpi/dispatcher/dswscope.c | 2
drivers/acpi/dispatcher/dswstate.c | 2
drivers/acpi/ec.c | 2
drivers/acpi/events/evevent.c | 2
drivers/acpi/events/evgpe.c | 2
drivers/acpi/events/evgpeblk.c | 2
drivers/acpi/events/evmisc.c | 2
drivers/acpi/events/evregion.c | 7 --
drivers/acpi/events/evrgnini.c | 2
drivers/acpi/events/evsci.c | 2
drivers/acpi/events/evxface.c | 2
drivers/acpi/events/evxfevnt.c | 2
drivers/acpi/events/evxfregn.c | 2
drivers/acpi/executer/exconfig.c | 2
drivers/acpi/executer/exconvrt.c | 2
drivers/acpi/executer/excreate.c | 2
drivers/acpi/executer/exdump.c | 2
drivers/acpi/executer/exfield.c | 2
drivers/acpi/executer/exfldio.c | 2
drivers/acpi/executer/exmisc.c | 2
drivers/acpi/executer/exmutex.c | 2
drivers/acpi/executer/exnames.c | 2
drivers/acpi/executer/exoparg1.c | 2
drivers/acpi/executer/exoparg2.c | 2
drivers/acpi/executer/exoparg3.c | 2
drivers/acpi/executer/exoparg6.c | 2
drivers/acpi/executer/exprep.c | 2
drivers/acpi/executer/exregion.c | 2
drivers/acpi/executer/exresnte.c | 2
drivers/acpi/executer/exresolv.c | 2
drivers/acpi/executer/exresop.c | 2
drivers/acpi/executer/exstore.c | 2
drivers/acpi/executer/exstoren.c | 2
drivers/acpi/executer/exstorob.c | 2
drivers/acpi/executer/exsystem.c | 2
drivers/acpi/executer/exutils.c | 2
drivers/acpi/fan.c | 2
drivers/acpi/hardware/hwacpi.c | 2
drivers/acpi/hardware/hwgpe.c | 16 +----
drivers/acpi/hardware/hwregs.c | 2
drivers/acpi/hardware/hwsleep.c | 78 +++++++++++++++++--------
drivers/acpi/hardware/hwtimer.c | 2
drivers/acpi/namespace/nsaccess.c | 2
drivers/acpi/namespace/nsalloc.c | 2
drivers/acpi/namespace/nsdump.c | 2
drivers/acpi/namespace/nsdumpdv.c | 2
drivers/acpi/namespace/nseval.c | 2
drivers/acpi/namespace/nsinit.c | 2
drivers/acpi/namespace/nsload.c | 2
drivers/acpi/namespace/nsnames.c | 2
drivers/acpi/namespace/nsobject.c | 2
drivers/acpi/namespace/nsparse.c | 2
drivers/acpi/namespace/nssearch.c | 2
drivers/acpi/namespace/nsutils.c | 2
drivers/acpi/namespace/nswalk.c | 2
drivers/acpi/namespace/nsxfeval.c | 2
drivers/acpi/namespace/nsxfname.c | 2
drivers/acpi/namespace/nsxfobj.c | 2
drivers/acpi/osl.c | 8 +-
drivers/acpi/parser/psargs.c | 2
drivers/acpi/parser/psopcode.c | 2
drivers/acpi/parser/psparse.c | 2
drivers/acpi/parser/psscope.c | 2
drivers/acpi/parser/pstree.c | 2
drivers/acpi/parser/psutils.c | 2
drivers/acpi/parser/pswalk.c | 2
drivers/acpi/parser/psxface.c | 2
drivers/acpi/power.c | 2
drivers/acpi/processor.c | 2
drivers/acpi/resources/rsaddr.c | 2
drivers/acpi/resources/rscalc.c | 2
drivers/acpi/resources/rscreate.c | 2
drivers/acpi/resources/rsdump.c | 2
drivers/acpi/resources/rsio.c | 2
drivers/acpi/resources/rsirq.c | 2
drivers/acpi/resources/rslist.c | 2
drivers/acpi/resources/rsmemory.c | 2
drivers/acpi/resources/rsmisc.c | 2
drivers/acpi/resources/rsutils.c | 2
drivers/acpi/resources/rsxface.c | 2
drivers/acpi/tables.c | 13 +++-
drivers/acpi/tables/tbconvrt.c | 10 +--
drivers/acpi/tables/tbget.c | 2
drivers/acpi/tables/tbgetall.c | 2
drivers/acpi/tables/tbinstal.c | 2
drivers/acpi/tables/tbrsdt.c | 13 +++-
drivers/acpi/tables/tbutils.c | 2
drivers/acpi/tables/tbxface.c | 2
drivers/acpi/tables/tbxfroot.c | 6 -
drivers/acpi/thermal.c | 4 -
drivers/acpi/toshiba_acpi.c | 2
drivers/acpi/utilities/utalloc.c | 2
drivers/acpi/utilities/utcopy.c | 2
drivers/acpi/utilities/utdebug.c | 2
drivers/acpi/utilities/utdelete.c | 2
drivers/acpi/utilities/uteval.c | 2
drivers/acpi/utilities/utglobal.c | 2
drivers/acpi/utilities/utinit.c | 2
drivers/acpi/utilities/utmath.c | 2
drivers/acpi/utilities/utmisc.c | 14 ++--
drivers/acpi/utilities/utobject.c | 2
drivers/acpi/utilities/utxface.c | 2
include/acpi/acconfig.h | 4 -
include/acpi/acdebug.h | 2
include/acpi/acdisasm.h | 2
include/acpi/acdispat.h | 2
include/acpi/acevents.h | 2
include/acpi/acexcep.h | 2
include/acpi/acglobal.h | 2
include/acpi/achware.h | 2
include/acpi/acinterp.h | 2
include/acpi/aclocal.h | 2
include/acpi/acmacros.h | 2
include/acpi/acnamesp.h | 2
include/acpi/acobject.h | 2
include/acpi/acoutput.h | 2
include/acpi/acparser.h | 2
include/acpi/acpi.h | 2
include/acpi/acpiosxf.h | 2
include/acpi/acpixf.h | 2
include/acpi/acresrc.h | 2
include/acpi/acstruct.h | 2
include/acpi/actables.h | 2
include/acpi/actbl.h | 9 ++
include/acpi/actbl1.h | 2
include/acpi/actbl2.h | 2
include/acpi/actypes.h | 2
include/acpi/acutils.h | 2
include/acpi/amlcode.h | 2
include/acpi/amlresrc.h | 2
include/acpi/platform/acenv.h | 2
include/acpi/platform/acgcc.h | 2
include/acpi/platform/aclinux.h | 2
146 files changed, 252 insertions(+), 205 deletions(-)
through these ChangeSets:
<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (04/01/26 1.1063.46.67)
[ACPI] handle system with NULL DSDT and valid XDSDT
from ia64 via Alex Williamson
<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (04/01/26 1.1063.46.66)
[ACPI] move zero initialized data to .bss
from Jes Sorensen
<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (04/01/17 1.1063.46.65)
[ACPI] ACPICA 20040116 from Bob Moore
The purpose of this release is primarily to update the copyright
years
in each module, thus causing a huge number of diffs. There are a few
small functional changes, however.
Improved error messages when there is a problem finding one or more
of
the required base ACPI tables
Reintroduced the definition of APIC_HEADER in actbl.h
Changed definition of MADT_ADDRESS_OVERRIDE to 64 bits (actbl.h)
Removed extraneous reference to NewObj in dsmthdat.c
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: [PATCH] ide-dma.c, ide.c, ide.h, kernel 2.4.24
From: Glenn Wurster @ 2004-01-27 5:52 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: Alan Cox, torvalds, linux-kernel, andre
In-Reply-To: <200401240045.56966.bzolnier@elka.pw.edu.pl>
> Glenn, your patch hides potential problems - these functions shouldn't be
> called if host doesn't support DMA. However there is one place when
> ->ide_dma_host_off() shouldn't be called unconditionally, here is a patch.
> It is not pretty but at least consistent - we check hwif->ide_dma_check
> to see if DMA is supported in other places too. Does it fix the problem?
Not quite. If we go forward with a patch like that, then it must be
updated to include at least two other places that I know of
immediately. The updated patch would be something similar to the one
at the bottom of this e-mail.
On a further note, how should hdparm -d behave on my controller, the
relivant lines from dmesg are:
SIS5513: IDE controller at PCI slot 00:01.1
SIS5513: chipset revision 8
SIS5513: not 100% native mode: will probe irqs later
SIS5513: SiS551x ATA 16 controller
ide0: BM-DMA at 0xf870-0xf877, BIOS settings: hda:pio, hdb:pio
SIS5513: simplex device: DMA disabled
ide1: SIS5513 Bus-Master DMA disabled (BIOS)
hda: WDC AC21000H, ATA DISK drive
hdc: Maxtor 6Y080L0, ATA DISK drive
"hdparm -d 1 /dev/hdc" returns an operation not permitted, but "hdparm
-d 1 /dev/hda" is successful and results in future calls to "hdparm -d
1 /dev/hdc" seemingly locking the computer.
> Are you sure that it doesn't happen on 2.6.1? Maybe you've used a bit
> different config (ie. compiled without DMA support)?
Oops, on further research it did exhibit the exact same problem.
Sorry about the misdiagnosis.
Let me know how I can continue to help.
Glenn.
[Sorry about my tardy response]
--- linux-2.4.24-orig/drivers/ide/ide-iops.c 2003-11-28 18:26:20.000000000 +0000
+++ linux-2.4.24/drivers/ide/ide-iops.c 2004-01-27 05:19:41.000000000 +0000
@@ -912,7 +912,8 @@
// ide_delay_50ms();
#if defined(CONFIG_BLK_DEV_IDEDMA) && !defined(CONFIG_DMA_NONPCI)
- hwif->ide_dma_host_off(drive);
+ if (hwif->ide_dma_check) /* Check if host supports DMA */
+ hwif->ide_dma_host_off(drive);
#endif /* (CONFIG_BLK_DEV_IDEDMA) && !(CONFIG_DMA_NONPCI) */
/*
@@ -980,10 +981,13 @@
drive->id->dma_1word &= ~0x0F00;
#if defined(CONFIG_BLK_DEV_IDEDMA) && !defined(CONFIG_DMA_NONPCI)
- if (speed >= XFER_SW_DMA_0)
- hwif->ide_dma_host_on(drive);
- else
- hwif->ide_dma_off_quietly(drive);
+ if (speed >= XFER_SW_DMA_0) {
+ if (hwif->ide_dma_check) /* Check if host supports DMA */
+ hwif->ide_dma_host_on(drive);
+ } else {
+ if (hwif->ide_dma_check) /* Check if host supports DMA */
+ hwif->ide_dma_off_quietly(drive);
+ }
#endif /* (CONFIG_BLK_DEV_IDEDMA) && !(CONFIG_DMA_NONPCI) */
switch(speed) {
^ permalink raw reply
* Re: [ANNOUNCE] udev 015 release
From: Chris Friesen @ 2004-01-27 5:52 UTC (permalink / raw)
To: Greg KH; +Cc: linux-hotplug-devel, linux-kernel
In-Reply-To: <20040126215036.GA6906@kroah.com>
Greg KH wrote:
> I've released the 015 version of udev. It can be found at:
> kernel.org/pub/linux/utils/kernel/hotplug/udev-015.tar.gz
> Also in this release is the start of a udev daemon. It's really in 3
> pieces:
> udevsend - sends the hotplug message to the udev daemon
> udevd - the udev daemon, gets the hotplug messages, sorts them
> in proper order, and passes them off to the udev program
> to act apon them.
> udev - still the same.
I'm curious about the rationale behind breaking it up into multiple chunks.
udevsend being separate I assume is so that it can be easily called from
a script while still keeping something persistant?
I'm not sure I see what separating udev and udevd into different
binaries actually buys you. Wouldn't it be just as easy to make udev be
the daemon based on runtime options or something?
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ 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.