* Cooperative Linux
From: beolach @ 2004-01-27 4:56 UTC (permalink / raw)
To: linux-newbie
There was a thread on this list recently on running Linux inside windows;
to which the general consensus was that it can't really be done. However
I was reading through the weekends articles on /. <http://slashdot.org>
and found this article about a program that does exactly that:
<http://developers.slashdot.org/article.pl?sid=04/01/25/2124237&mode=thread&tid=106&tid=185&tid=190&tid=201>
(Quote from /.):
"Posted by timothy on 15:03 Sunday 25 January 2004
from the it's-real-friendly-like dept.
evilmf writes "Well... I was on my daily "relaxing" read of the LKML when I've found an interesting announce about "Cooperative Linux", in this message from Dan Aloni. It allows you to run Linux on an unmodified Win2000/XP system, just launching another app. Dan says that Cooperative Linux is 'is stable enough (on some common hardware configurations) for running a fully functional KNOPPIX/Debian system on Windows,' and provides some screenshots in the project homepage.""
Related links:
Project Homepages:
<http://www.colinux.org/>
<http://sourceforge.net/projects/colinux>
Original LKML (Linux Kernel Mailing List) Post:
<http://lkml.org/lkml/2004/1/25/96>
Slashdot Article:
<http://developers.slashdot.org/article.pl?sid=04/01/25/2124237&mode=thread&tid=106&tid=185&tid=190&tid=201>
Just thought this was of interest,
Conway S. Smith
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: [uPATCH] refuse plain ufs mount
From: GOTO Masanori @ 2004-01-27 5:04 UTC (permalink / raw)
To: Andries.Brouwer; +Cc: torvalds, akpm, gotom, linux-kernel
In-Reply-To: <UTC200401270407.i0R47oi29367.aeb@smtp.cwi.nl>
At Tue, 27 Jan 2004 05:07:50 +0100 (MET),
Andries.Brouwer@cwi.nl wrote:
> From: Linus Torvalds <torvalds@osdl.org>
>
> > But you see, it wasn't the user at all, and it wasn't a ufs filesystem.
> > It is kernel probing that causes error messages. That is unwanted.
> > So, your version is wrong.
>
> Yes.
>
> However, I think the _real_ bug is that we have reiserfs near the tail of
> filesystems to try.
>
> Can you test that alternate patch instead?
>
> Funny how we alternate - when I choose the pure, theoretical point of view
> you prefer practice, when I prefer practice you become pure.
>
> This time you prefer practice: the list of filesystems is full of garbage
> and good filesystems should be near the top.
> I prefer theory: the kernel should not probe at all, so everybody who
> forgets rootfstype= gets what he deserves.
>
> Be that as it may - below a patch as I suppose you had in mind.
> I don't like it very much. Ordering constraints in makefiles are bad.
>From the user point of view, I think it's weilcome that "popular"
filesystems like reiserfs used for rootfs is moved upwards, because
boot up speed is accelerated. It's difficult to define what "popular"
is, but apparently hugetlbfs should be lower than reiserfs. So your
patch seems fine, I think.
> Have not compiled or tested.
> You can apply it I suppose, but after doing so my earlier patch is still
> meaningful. Maybe you should also apply that (and the Doc update).
I misunderstand what the real problem is.
The problem as you previously wrote was that UFS does not use
ufs_fill_super third argument "silent" value, so some warning messages
are scattered during boot up time. I agree that this is exactly just
a noise. Andries removed those warnings instead of using "silent",
but in fact such messages are important for users who want to mount
ufs filesystem to tell for kernel the proper UFS type. To be honest,
I sometimes forget to add "ufstype=" option to mount UFS, so this
warning is useful for me. I attached patch which uses "silent" value
for this problem. I checked this patch which removes all scattered
UFS messages from boot up screen. I think this one is acceptable for
even Andries instead of your UFS patch, is it OK?
Regards,
-- gotom
--- fs/ufs/super.c.org 2003-10-20 12:50:24.000000000 +0900
+++ fs/ufs/super.c 2004-01-27 13:26:05.000000000 +0900
@@ -516,7 +516,7 @@
printk("wrong mount options\n");
goto failed;
}
- if (!(sbi->s_mount_opt & UFS_MOUNT_UFSTYPE)) {
+ if (!(sbi->s_mount_opt & UFS_MOUNT_UFSTYPE) && !silent) {
printk("You didn't specify the type of your ufs filesystem\n\n"
"mount -t ufs -o ufstype="
"sun|sunx86|44bsd|old|hp|nextstep|netxstep-cd|openstep ...\n\n"
@@ -575,7 +575,7 @@
uspi->s_sbsize = super_block_size = 2048;
uspi->s_sbbase = 0;
flags |= UFS_DE_OLD | UFS_UID_OLD | UFS_ST_OLD | UFS_CG_OLD;
- if (!(sb->s_flags & MS_RDONLY)) {
+ if (!(sb->s_flags & MS_RDONLY) && !silent) {
printk(KERN_INFO "ufstype=old is supported read-only\n");
sb->s_flags |= MS_RDONLY;
}
@@ -589,7 +589,7 @@
uspi->s_sbsize = super_block_size = 2048;
uspi->s_sbbase = 0;
flags |= UFS_DE_OLD | UFS_UID_OLD | UFS_ST_OLD | UFS_CG_OLD;
- if (!(sb->s_flags & MS_RDONLY)) {
+ if (!(sb->s_flags & MS_RDONLY) && !silent) {
printk(KERN_INFO "ufstype=nextstep is supported read-only\n");
sb->s_flags |= MS_RDONLY;
}
@@ -603,7 +603,7 @@
uspi->s_sbsize = super_block_size = 2048;
uspi->s_sbbase = 0;
flags |= UFS_DE_OLD | UFS_UID_OLD | UFS_ST_OLD | UFS_CG_OLD;
- if (!(sb->s_flags & MS_RDONLY)) {
+ if (!(sb->s_flags & MS_RDONLY) && !silent) {
printk(KERN_INFO "ufstype=nextstep-cd is supported read-only\n");
sb->s_flags |= MS_RDONLY;
}
@@ -617,7 +617,7 @@
uspi->s_sbsize = super_block_size = 2048;
uspi->s_sbbase = 0;
flags |= UFS_DE_44BSD | UFS_UID_44BSD | UFS_ST_44BSD | UFS_CG_44BSD;
- if (!(sb->s_flags & MS_RDONLY)) {
+ if (!(sb->s_flags & MS_RDONLY) && !silent) {
printk(KERN_INFO "ufstype=openstep is supported read-only\n");
sb->s_flags |= MS_RDONLY;
}
@@ -631,13 +631,14 @@
uspi->s_sbsize = super_block_size = 2048;
uspi->s_sbbase = 0;
flags |= UFS_DE_OLD | UFS_UID_OLD | UFS_ST_OLD | UFS_CG_OLD;
- if (!(sb->s_flags & MS_RDONLY)) {
+ if (!(sb->s_flags & MS_RDONLY) && !silent) {
printk(KERN_INFO "ufstype=hp is supported read-only\n");
sb->s_flags |= MS_RDONLY;
}
break;
default:
- printk("unknown ufstype\n");
+ if (!silent)
+ printk("unknown ufstype\n");
goto failed;
}
@@ -687,7 +688,8 @@
uspi->s_sbbase += 8;
goto again;
}
- printk("ufs_read_super: bad magic number\n");
+ if (!silent)
+ printk("ufs_read_super: bad magic number\n");
goto failed;
magic_found:
^ permalink raw reply
* login roles
From: Timothy Wood @ 2004-01-27 5:07 UTC (permalink / raw)
To: SELinux Mail List
I set the pam_selinux module to multiple and now I'm seeing three roles
instead of the two defined in policy/users. The third context is
<username>:staff_r:system_chkpwd_t, is this normal? I diffed my current
policy against the 1.4 tarball from the NSA site and the only
differences are a couple of changes I've made for slackware. Of those
few changes none of them have anything to do with system_chkpwd_t.
Timothy,
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: [uPATCH] ufs.txt update
From: GOTO Masanori @ 2004-01-27 5:09 UTC (permalink / raw)
To: Jochen Hein; +Cc: Andries.Brouwer, linux-kernel, akpm, torvalds
In-Reply-To: <87u12ksac2.fsf@echidna.jochen.org>
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>.
Regards,
-- gotom
--- Documentation/filesystems/ufs.txt 2003-07-28 02:06:11.000000000 +0900
+++ Documentation/filesystems/ufs.txt.new 2004-01-27 12:47:08.000000000 +0900
@@ -15,10 +15,10 @@
ufs manually by mount option ufstype. Possible values are:
old old format of ufs
- default value, supported os read-only
+ default value, supported as read-only
44bsd used in FreeBSD, NetBSD, OpenBSD
- supported os read-write
+ supported as read-write
sun used in SunOS (Solaris)
supported as read-write
@@ -26,6 +26,9 @@
sunx86 used in SunOS for Intel (Solarisx86)
supported as read-write
+ hp used in HP-UX
+ supported as read-only
+
nextstep
used in NextStep
supported as read-only
^ permalink raw reply
* Re: Samba
From: beolach @ 2004-01-27 5:21 UTC (permalink / raw)
To: jlamb03; +Cc: linux-newbie
> Hello,
>
> I recently switched to linux because I was curious what else was out there
> and was very annoyed with windows's mismanaged multitasking. So I went and
> bought Slackware after trying knoppix for a short while. I know Slack is
> sometimes not recommended for newbies, but I think it is the best way to
> learn linux because it really forced me to learn new things.
>
My opinion exactly. I started the same way back Slackware 7.1.
> My question: Can you recommend any books that deal more with networking, I
> am having troubles trying to set up a Samba server? I also want to be able
> to set up Apache and BIND? OH, and one more, does anyone have a good text on
> using a good linux server to serve a lot of thin clients?
As has been pointed out, a lot of great info on just about every subject
is available in The Linux Documentation Project <http://tldp.org>. I also
want to point out that all of the HOWTOs & FAQs from TLDP are included in Slackware in /usr/doc/Linux-HOWTOs & /usr/doc/Linux-FAQs.
Also, the SAMBA package for Slackware includes a ton of documentation on
setup SAMBA, including the book "Using Samba, 2nd Edition". The easiest way
to get to this using SWAT (Samba Web Administration Tool), which is also the
best way to administer SAMBA. To enable SWAT, edit /etc/inetd.conf &
uncomment the line for swat. Then find inetd's PID with 'ps -A' & send it
SIGHUP with `kill -HUP <pid>`. Then open your preferred webbrowser & go to
<http://localhost:901>.
>
> thanks for your time
>
My pleasure, hope it helps.
Conway S. Smith
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: atkbd.c: Unknown key released
From: Ralf Hildebrandt @ 2004-01-27 5:25 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <200401261834.54450@sandersweb.net>
* David Sanders <linux@sandersweb.net>:
> 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.
--
Ralf Hildebrandt (Im Auftrag des Referat V a) Ralf.Hildebrandt@charite.de
Charite - Universitätsmedizin Berlin Tel. +49 (0)30-450 570-155
Gemeinsame Einrichtung von FU- und HU-Berlin Fax. +49 (0)30-450 570-916
Referat V a - Kommunikationsnetze - AIM. ralfpostfix
^ permalink raw reply
* RE: Submission for S2io 10GbE driver
From: Leonid Grossman @ 2004-01-27 5:32 UTC (permalink / raw)
To: 'Stephen Hemminger', 'Andi Kleen'
Cc: netdev, raghavendra.koushik
In-Reply-To: <20040123162134.79c67ed5.shemminger@osdl.org>
Hi Stephen,
Below are responses from our developer.
Thanks for the input, Leonid
> -----Original Message-----
> From: Stephen Hemminger [mailto:shemminger@osdl.org]
> Sent: Friday, January 23, 2004 4:22 PM
> To: Andi Kleen
> Cc: Leonid Grossman; netdev@oss.sgi.com
> Subject: Re: Submission for S2io 10GbE driver
>
>
> Noticed the setup loopback test seems to register for a
> packet type and then forget to unregister that type!
The packet type gets unregistered at the end of the test in the
'reset_loopback'
function through the system call 'dev_remove_pack()'
>
> Also nothing really restricts the packet type to only coming
> in on the expected interface; therefore if someone sends the
> same packet in over another interface, then sp->loop_pkt_cnt
> will end up incrementing some other drivers private data
> structure *bad*.
Correct, that's why in the s2io.c source where I define the
packet_type's protocol value
through the Macro 'ETH_LOOP_TEST_TYPE' there's a ToDo to obtain a
private protocol ID.
This way no app in the real world can ever pass a frame with that T/L
field in the packet.
Also, the problem can only happen during the 3 second duration when this
test is in progress.
>
> IMHO the whole loopback test frame stuff seems like something
> in a test bed driver, not production code.
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?
Thanks, Leonid
>
^ permalink raw reply
* RE: Apache:access_log - 408
From: Mark E. Donaldson @ 2004-01-27 5:34 UTC (permalink / raw)
To: 'ccddtt', netfilter
In-Reply-To: <20040126090010.1242A33DBF@smtp.263.net>
What makes you think you are being attacked? There is not enough
information here to make that determination. "408" is a "request Time-out
error" and does not mean you are being attacked. This appears to be an ACK
scan with spoofed IP addresses. Look at the IPID's and TTL values. They tell
me they are coming from the same machine. If you want to drop these packets,
create stateful rules for inbound connections to port 80, and they will be
dropped:
$IPT -t filter -A PORTSCAN_RULES --destination-port 80 -p tcp --tcp-flags
ALL ACK -m state --state NEW -j LOG --log-level $LOG_LEVEL --log-prefix
"PORTSCAN: ACK ON NEW: "
$IPT -t filter -A PORTSCAN_RULES --destination-port 80 -p tcp --tcp-flags
ALL ACK -m state --state NEW -j REJECT --reject-with icmp-host-unreachable
-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of ccddtt
Sent: Monday, January 26, 2004 1:00 AM
To: netfilter@lists.netfilter.org
Subject: Apache:access_log - 408
hi,all
please help me.
my linux server installed redhat 9 + apache 1.3.29. passing through some
attack.
in apache acc_log,like :
221.233.227.230 - - [17/Jan/2004:17:26:32 +0800] "-" 408 - 221.233.227.230 -
- [17/Jan/2004:17:26:32 +0800] "-" 408 - 221.233.227.230 - -
[17/Jan/2004:17:26:32 +0800] "-" 408 - 61.145.188.110 - -
[17/Jan/2004:17:26:32 +0800] "-" 408 -
210.38.179.145 - - [17/Jan/2004:17:26:32 +0800] "-" 408 - 221.233.227.230 -
- [17/Jan/2004:17:26:32 +0800] "-" 408 - but no err_log.
some packge like :
Jan 18 19:35:53 linux-sv1 kernel: IN=eth0 OUT=
MAC=00:07:e9:6c:4c:49:00:02:b3:03:e3:67:08:00 SRC=220.173.8.56
DST=61.135.xx.xx LEN=40 TOS=0x00 PREC=0x00 TTL=114 ID=42497 DF PROTO=TCP
SPT=60177 DPT=80 WINDOW=8280 RES=0x00 ACK URGP=0 Jan 18 19:35:53 linux-sv1
kernel: IN=eth0 OUT= MAC=00:07:e9:6c:4c:49:00:02:b3:03:e3:67:08:00
SRC=220.173.8.56 DST=61.135.xx.xx LEN=40 TOS=0x00 PREC=0x00 TTL=114 ID=42753
DF PROTO=TCP SPT=60177 DPT=80 WINDOW=8280 RES=0x00 ACK URGP=0 Jan 18
19:35:53 linux-sv1 kernel: IN=eth0 OUT=
MAC=00:07:e9:6c:4c:49:00:02:b3:03:e3:67:08:00 SRC=61.173.25.88
DST=61.135.xx.xx LEN=40 TOS=0x00 PREC=0x00 TTL=115 ID=53402 DF PROTO=TCP
SPT=63601 DPT=80 WINDOW=16560 RES=0x00 ACK URGP=0 Jan 18 19:35:53 linux-sv1
kernel: IN=eth0 OUT= MAC=00:07:e9:6c:4c:49:00:02:b3:03:e3:67:08:00
SRC=220.173.8.56 DST=61.135.xx.xx LEN=40 TOS=0x00 PREC=0x00 TTL=114 ID=43265
DF PROTO=TCP SPT=60182 DPT=80 WINDOW=8280 RES=0x00 ACK URGP=0
how to set this iptables rules?
what's this attack?
thanks your any help!
^ permalink raw reply
* [BK] Updated 2.6 typhoon driver for 3CR990 & 3CR990B cards
From: David Dillow @ 2004-01-27 5:35 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Netdev
[ I've not sent patches to the list, as the firmware update is too big. ]
Jeff, please do a
bk pull http://typhoon.bkbits.net/typhoon-2.5
This will update the following files:
drivers/net/typhoon-firmware.h | 6890 +++++++++++++++++++++--------------------
drivers/net/typhoon.c | 20
drivers/net/typhoon.h | 6
3 files changed, 3563 insertions(+), 3353 deletions(-)
through these ChangeSets:
<dave@thedillows.org> (03/12/15 1.1488)
Support the new 3CR990B cards that require authentication of the runtime
firmware image.
And the non-firmware part is:
diff -Nru a/drivers/net/typhoon.c b/drivers/net/typhoon.c
--- a/drivers/net/typhoon.c Mon Jan 26 22:58:36 2004
+++ b/drivers/net/typhoon.c Mon Jan 26 22:58:36 2004
@@ -85,8 +85,8 @@
#define PKT_BUF_SZ 1536
#define DRV_MODULE_NAME "typhoon"
-#define DRV_MODULE_VERSION "1.5.2"
-#define DRV_MODULE_RELDATE "03/11/25"
+#define DRV_MODULE_VERSION "1.5.3"
+#define DRV_MODULE_RELDATE "03/12/15"
#define PFX DRV_MODULE_NAME ": "
#define ERR_PFX KERN_ERR PFX
@@ -157,6 +157,7 @@
TYPHOON_TX = 0, TYPHOON_TX95, TYPHOON_TX97, TYPHOON_SVR,
TYPHOON_SVR95, TYPHOON_SVR97, TYPHOON_TXM, TYPHOON_BSVR,
TYPHOON_FX95, TYPHOON_FX97, TYPHOON_FX95SVR, TYPHOON_FX97SVR,
+ TYPHOON_FXM,
};
/* directly indexed by enum typhoon_cards, above */
@@ -185,6 +186,8 @@
TYPHOON_CRYPTO_DES | TYPHOON_FIBER},
{ "3Com Typhoon (3CR990-FX-97 Server)",
TYPHOON_CRYPTO_DES | TYPHOON_CRYPTO_3DES | TYPHOON_FIBER},
+ { "3Com Typhoon2 (3C990B-FX-97)",
+ TYPHOON_CRYPTO_VARIABLE | TYPHOON_FIBER},
};
/* Notes on the new subsystem numbering scheme:
@@ -203,6 +206,8 @@
{ PCI_VENDOR_ID_3COM, PCI_DEVICE_ID_3COM_3CR990B,
PCI_ANY_ID, 0x1000, 0, 0, TYPHOON_TXM },
{ PCI_VENDOR_ID_3COM, PCI_DEVICE_ID_3COM_3CR990B,
+ PCI_ANY_ID, 0x1102, 0, 0, TYPHOON_FXM },
+ { PCI_VENDOR_ID_3COM, PCI_DEVICE_ID_3COM_3CR990B,
PCI_ANY_ID, 0x2000, 0, 0, TYPHOON_BSVR },
{ PCI_VENDOR_ID_3COM, PCI_DEVICE_ID_3COM_3CR990_FX,
PCI_ANY_ID, 0x1101, 0, 0, TYPHOON_FX95 },
@@ -1363,6 +1368,7 @@
u32 section_len;
u32 len;
u32 load_addr;
+ u32 hmac;
int i;
int err;
@@ -1406,6 +1412,16 @@
writel(TYPHOON_INTR_BOOTCMD, ioaddr + TYPHOON_REG_INTR_STATUS);
writel(load_addr, ioaddr + TYPHOON_REG_DOWNLOAD_BOOT_ADDR);
+ hmac = le32_to_cpu(fHdr->hmacDigest[0]);
+ writel(hmac, ioaddr + TYPHOON_REG_DOWNLOAD_HMAC_0);
+ hmac = le32_to_cpu(fHdr->hmacDigest[1]);
+ writel(hmac, ioaddr + TYPHOON_REG_DOWNLOAD_HMAC_1);
+ hmac = le32_to_cpu(fHdr->hmacDigest[2]);
+ writel(hmac, ioaddr + TYPHOON_REG_DOWNLOAD_HMAC_2);
+ hmac = le32_to_cpu(fHdr->hmacDigest[3]);
+ writel(hmac, ioaddr + TYPHOON_REG_DOWNLOAD_HMAC_3);
+ hmac = le32_to_cpu(fHdr->hmacDigest[4]);
+ writel(hmac, ioaddr + TYPHOON_REG_DOWNLOAD_HMAC_4);
typhoon_post_pci_writes(ioaddr);
writel(TYPHOON_BOOTCMD_RUNTIME_IMAGE, ioaddr + TYPHOON_REG_COMMAND);
diff -Nru a/drivers/net/typhoon.h b/drivers/net/typhoon.h
--- a/drivers/net/typhoon.h Mon Jan 26 22:58:36 2004
+++ b/drivers/net/typhoon.h Mon Jan 26 22:58:36 2004
@@ -512,6 +512,7 @@
u32 version;
u32 numSections;
u32 startAddr;
+ u32 hmacDigest[5];
} __attribute__ ((packed));
struct typhoon_section_header {
@@ -548,6 +549,11 @@
#define TYPHOON_REG_BOOT_LENGTH TYPHOON_REG_HOST2ARM1
#define TYPHOON_REG_DOWNLOAD_BOOT_ADDR TYPHOON_REG_HOST2ARM1
+#define TYPHOON_REG_DOWNLOAD_HMAC_0 TYPHOON_REG_HOST2ARM2
+#define TYPHOON_REG_DOWNLOAD_HMAC_1 TYPHOON_REG_HOST2ARM3
+#define TYPHOON_REG_DOWNLOAD_HMAC_2 TYPHOON_REG_HOST2ARM4
+#define TYPHOON_REG_DOWNLOAD_HMAC_3 TYPHOON_REG_HOST2ARM5
+#define TYPHOON_REG_DOWNLOAD_HMAC_4 TYPHOON_REG_HOST2ARM6
#define TYPHOON_REG_BOOT_RECORD_ADDR_HI TYPHOON_REG_HOST2ARM2
#define TYPHOON_REG_BOOT_RECORD_ADDR_LO TYPHOON_REG_HOST2ARM1
^ permalink raw reply
* Re: New NUMA scheduler and hotplug CPU
From: Nick Piggin @ 2004-01-27 5:39 UTC (permalink / raw)
To: Martin J. Bligh, Rusty Russell; +Cc: linux-kernel
In-Reply-To: <356230000.1075178284@[10.10.2.4]>
Martin J. Bligh wrote:
>>No, actually, it wouldn't. Take it from someone who has actually
>>looked at the code with an eye to doing this.
>>
>>Replacing static structures by dynamic ones for an architecture which
>>doesn't yet exist is NOT a good idea.
>>
>
>Trying to force a dynamic infrastructure into the static bitmap arrays
>that we have is the bad idea, IMHO. Why on earth would you want offline
>CPUs in the scheduler domains? Just to make your coding easier? Sorry,
>but that just doesn't cut it for me.
>
>
>>Sure, if they were stupid they'd do it this way.
>>
>>If (when) an architecture has hotpluggable CPUs and NUMA
>>characteristics, they probably will have fixed CPU *slots*, and number
>>CPUs based on what slot they are in. Since the slots don't move, all
>>your fancy dynamic logic will be wasted.
>>
>>When someone really has dynamic hotplug CPU capability with variable
>>attributes, *they* can code up the dynamic hierarchy. Because *they*
>>can actually test it!
>>
>
>The cpu numbers are now dynamically allocated tags. I don't see why
>we should sacrifice that just to get cpu hotplug. Sure, it makes your
>coding a little harder, but ....
>
>
>>>Yup ... but you don't have to enumerate all possible positions that way.
>>>See Linus' arguement re dynamic device numbers and ISCSI disks, etc.
>>>Same thing applies.
>>>
>>Crap. When all the fixed per-cpu arrays have been removed from the
>>kernel, come back and talk about instantiation and location of
>>arbitrary CPUS.
>>
>>You're way overdesigning: have you been sharing food with the AIX guys?
>>
>
>A cheap shot. Please, I'd expect better flaming from you.
>
>Sorry if this makes your coding harder, but it seems clear to me that
>it's the right way to go. I guess the final decision is up to Andrew,
>but I really don't want to see this kind of stuff. You don't start
>kthreads for every possible cpu, do you?
>
>
Well lets not worry too much about this for now. We could use
static arrays and cpu_possible for now until we get a feel
for what specific architectures want.
To be honest I haven't seen the hotplug CPU code and I don't
know about what architectures want to be doing with it, so
this is my preferred direction just out of ignorance.
An easy next step toward a dynamic scheme would be just to
re-init the entire sched domain topology (the generic init uses
the generic NUMA topology info which will have to be handled
by these architectures anyway). Modulo a small locking problem.
There aren't any fundamental design issues (with sched domains)
that I can see preventing a more dynamic system so we can keep
that in mind.
^ permalink raw reply
* Re: [patch] Re: Kernels > 2.6.1-mm3 do not boot. - SOLVED
From: Eric @ 2004-01-27 5:43 UTC (permalink / raw)
To: Andrew Morton; +Cc: stoffel, ak, Valdis.Kletnieks, bunk, cova, linux-kernel
In-Reply-To: <20040126115614.351393f2.akpm@osdl.org>
On Monday 26 January 2004 13:56, Andrew Morton wrote:
> Eric <eric@cisu.net> wrote:
> > On Monday 26 January 2004 00:00, Andrew Morton wrote:
> > > "John Stoffel" <stoffel@lucent.com> wrote:
> > > > Sure, the darn thing wouldn't boot, it kept Oopsing with the
> > > > test_wp_bit oops (that I just posted more details about).
> > >
> > > Does this fix the test_wp_bit oops?
> >
> > Yes, it fixes my test_wp_bit oops. But NOW, when booting 2.6.2-rc1-mm3
> > (which i pathed removing -funit-at-a-time and the wp_but oops patch) I
> > get an oops derefrencing null pointer in blkdev_reread_part.
>
> It is likely that this can be fixed by reverting
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.2-rc1/2.
>6.2-rc1-mm3/broken-out/md-06-allow-partitioning.patch -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
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
Thank you very much for your help. I hope we all learned something today. I
definatly did.
-------------------------
Eric Bambach
Eric at cisu dot net
-------------------------
^ permalink raw reply
* virus warning
From: Fritz Mesedilla @ 2004-01-27 5:44 UTC (permalink / raw)
To: Netfilter Mailing List (E-mail)
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: ax25 support in aprsd
From: Adi Linden @ 2004-01-27 5:47 UTC (permalink / raw)
To: John Williams; +Cc: linux-hams
In-Reply-To: <40168DC7.3946.85C307@localhost>
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: [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
* 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
* [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: [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
* 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: [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: [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
* [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
* [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
* 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
* 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
* 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
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.