* Bug: sunrpc
From: Vincent ROQUETA @ 2004-01-28 8:56 UTC (permalink / raw)
To: nfs
kernel : 2.6.1
patch :
http://www.citi.umich.edu/projects/nfsv4/linux/kernel-patches/kernel-patches-2.6.1-1/linux-2.6.1-CITI_NFS4_ALL.patch
-> Compilation: really hard to compil, many problems with ACL
kernel config:
# Network File Systems
#
# CONFIG_NFS_FS is not set
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_V4_ACL=y
CONFIG_EXPORTFS=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=m
CONFIG_RPCSEC_GSS_KRB5=m
(I can't compil if SUNRPC_GSS and RPCSEC_GSS_KRB5 are buit-in)
modprobe:
modprobe auth_rpcgss OK
modprobe rpcsec_gss_krb5 OK
mount --bind /home/tests /export/tests OK
exportfs -i -ofsid=0 *:/export -> bug
Jan 27 20:40:01 fastreboot kernel: kmem_cache_create: duplicate cache
rpc_inode_cache
Jan 27 20:40:01 fastreboot kernel: ------------[ cut here ]------------
Jan 27 20:40:01 fastreboot kernel: kernel BUG at mm/slab.c:1269!
Jan 27 20:40:01 fastreboot kernel: invalid operand: 0000 [#1]
Jan 27 20:40:01 fastreboot kernel: CPU: 0
Jan 27 20:40:01 fastreboot kernel: EIP: 0060:[<c0141b77>] Not tainted
Jan 27 20:40:01 fastreboot kernel: EFLAGS: 00010202
Jan 27 20:40:01 fastreboot kernel: EIP is at kmem_cache_create+0x447/0x530
Jan 27 20:40:01 fastreboot kernel: eax: 00000033 ebx: f7df0878 ecx:
c043a96c edx: c0371bdc
Jan 27 20:40:01 fastreboot kernel: esi: c0357b21 edi: f89ba988 ebp:
f7df0614 esp: f7257f4c
Jan 27 20:40:01 fastreboot kernel: ds: 007b es: 007b ss: 0068
Jan 27 20:40:01 fastreboot kernel: Process modprobe (pid: 933,
threadinfo=f7256000 task=f7318710)
Jan 27 20:40:01 fastreboot kernel: Stack: c032d300 f89ba978 00022000 f7257f68
f7df0654 c0000000 ffffffe0 000000c0
Jan 27 20:40:01 fastreboot kernel: c03731b0 c0373194 f89c9240 f7256000
f89b9417 f89ba978 000001e0 00000020
Jan 27 20:40:01 fastreboot kernel: 00022000 f89b9300 00000000 f890e00c
c0373194 c03731b0 c0138467 c043a884
Jan 27 20:40:01 fastreboot kernel: Call Trace:
Jan 27 20:40:01 fastreboot kernel: [<f89b9417>] register_rpc_pipefs+0x37/0x60
[sunrpc]
Jan 27 20:40:01 fastreboot kernel: [<f89b9300>] init_once+0x0/0xe0 [sunrpc]
Jan 27 20:40:01 fastreboot kernel: [<f890e00c>] init_sunrpc+0xc/0x54 [sunrpc]
Jan 27 20:40:01 fastreboot kernel: [<c0138467>] sys_init_module+0x127/0x230
Jan 27 20:40:01 fastreboot kernel: [<c010922d>] sysenter_past_esp+0x52/0x71
Jan 27 20:40:01 fastreboot kernel:
Jan 27 20:40:01 fastreboot kernel: Code: 0f 0b f5 04 df ca 32 c0 8b 0b e9 74
ff ff ff 8b 47 38 c7 04
-------------------------------------------------------
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
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* [PATCH 2.4] Added PCI device ID for it8181fb
From: Yoichi Yuasa @ 2004-01-28 8:56 UTC (permalink / raw)
To: marcelo.tosatti; +Cc: yuasa, linux-kernel
Hi,
The following patch is required in order to compile it8181fb.
This patch adds PCI device ID for it8181fb.
Please apply this patch.
Yoichi
diff -Nru a/drivers/pci/pci.ids b/drivers/pci/pci.ids
--- a/drivers/pci/pci.ids Wed Jan 28 17:46:58 2004
+++ b/drivers/pci/pci.ids Wed Jan 28 17:46:58 2004
@@ -4511,6 +4511,7 @@
9132 Ethernet 100/10 MBit
1283 Integrated Technology Express, Inc.
673a IT8330G
+ 8181 IT8181E/F LCD/VGA Controller
8330 IT8330G
8888 IT8888F PCI to ISA Bridge with SMB
8889 IT8889F PCI to ISA Bridge
diff -Nru a/include/linux/pci_ids.h b/include/linux/pci_ids.h
--- a/include/linux/pci_ids.h Wed Jan 28 17:46:58 2004
+++ b/include/linux/pci_ids.h Wed Jan 28 17:46:58 2004
@@ -1438,6 +1438,7 @@
#define PCI_VENDOR_ID_ITE 0x1283
#define PCI_DEVICE_ID_ITE_IT8172G 0x8172
#define PCI_DEVICE_ID_ITE_IT8172G_AUDIO 0x0801
+#define PCI_DEVICE_ID_ITE_IT8181 0x8181
#define PCI_DEVICE_ID_ITE_8872 0x8872
#define PCI_DEVICE_ID_ITE_IT8330G_0 0xe886
^ permalink raw reply
* Re: [RFC/PATCH, 2/4] readX_check() performance evaluation
From: Russell King @ 2004-01-28 8:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Hironobu Ishii, linux-kernel, linux-ia64
In-Reply-To: <Pine.LNX.4.58.0401271847440.10794@home.osdl.org>
On Tue, Jan 27, 2004 at 06:55:17PM -0800, Linus Torvalds wrote:
> Does anybody see any downsides to something like this?
What if the failing PCI access happened in an interrupt routine?
(I'm thinking of the situation where you may need to read the PCI
status registers to find out whether an error occurred.)
Also, for that matter, what if a network device receives an abort
while performing BM-DMA?
Do we even care about either of these two scenarios?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
^ permalink raw reply
* Re: NAT before IPsec with 2.6
From: Harald Welte @ 2004-01-28 8:58 UTC (permalink / raw)
To: Andreas Jellinghaus; +Cc: netfilter-devel, netdev
In-Reply-To: <pan.2004.01.27.21.13.32.754125@dungeon.inka.de>
[-- Attachment #1: Type: text/plain, Size: 4125 bytes --]
Cc'ing netdev, since this is now a very clear proposal and not some
internal netfilter rambling.
On Tue, Jan 27, 2004 at 10:13:33PM +0100, Andreas Jellinghaus wrote:
> > This is what happens with incoming packets: they hit INPUT twice.
>
> yes, but once before and once after decryption. use either fwmark
> or an ipip tunnel interface to destinguish between already decrypted
> and was-never-encrypted packets.
yes, and this is desired. However, the packets also hit PREROUTING
twice, which is exactly what we want (and get it for free, since
xfrm4_input.c calls netif_rx() again).
However, it doesn't reset the skb->nfct pointer, so connection tracking
sees both encapsulated and decapsulated packet as belonging to the same
connection. This is wrong, and dangerous (application helpers might be
called for the encapsulated traffic, which now has a completely
different layer 4 protocol.
So with stock 2.6.x you have
- no working connection tracking in any kind of ipsec scenario
- conntrack and NAT helpers trying to find readable application data
within already-encrypted packets
- no working DNAT/SNAT, mainly because of not-working connection
tracking
> > On output, however, things are not so transparant. A packet hits OUTPUT,
> > then gets encrypted. A totally different packet hits POSTROUTING. This makes
> > no sense.
>
> use an interface, and you will see the packet twice, plus the interface
> does the route lookup on the encrypted packet. so no ugly hacks in the
> routing table are necessary.
Did anybody propose ugly hacks in the routing table?
> [symetry]
>
> that does not work:
> netfilter wants NAT to be the first thing for incoming packets
> and the last thing for outgoing packets. thats symetry.
yes, it is symmetric. As is the symmetry between prerouting/postrouting
and input/output hooks. As well as the symmetry between SNAT and DNAt,
...
> but you want ipsec encryption and decryption as soon as possible:
> both before looking at the routing table.
Yes, that's why what IPsec is doing for incoming ESP/AH packets the
right thing: go through PRE_ROUTING, route to LOCAL_IN, decapsulate,
and start over again.
However, for outgoing ESP/AH packets (locally-encapsulated), it doesn't
show the symmetric behaviour of what it does on the input side: go
through FORWARD, encapsulate, route, POST_ROUTING. No starting over.
So we absolutely _need_ a symmetric-to-incoming behaviour like:
a) for locally-originated packets
LOCAL_OUT, POST_ROUTING, encapsulate, LOCAL_OUT, POST_ROUTING.
b) for forwarded, locally-encapsulated packets
PRE_ROUTING, FORWARD, POST_ROUTING, encapsulate, LOCAL_OUT, POST_ROUTING.
No, we don't achieve this by manipulating the routing code, but by
placing the respective hooks in ah{4,6}.c and esp{4,6}.c
{ah,esp}_output() function respectively. We also need to (again) reset
the skb->nfct and drop the conntrack reference again.
This way we
1) make connection tracking work again
2) do not change any routing of the current implementation
3) enable users to
a) filter unencapsulated, encapsulated and decapsulated
packeets at their 'expected' place
b) do DNAT on the incoming decapsulated packets
(which doesn't work right now, but should)
c) do SNAT on the outgoing/forwarded to-be-encapsualated
packets (which doesn't work right now, but should)
> mixing those two will never result in symetry. if you try it
> (routing before encapsulation), the result has problems.
I'm not proposing to route before encapsulating. I just propose of
calling the same netfilter functions that we usually call before/after
routing at different places :)
> Andreas
--
- Harald Welte <laforge@netfilter.org> http://www.netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: ip_conntrack CLOSE_WAIT issue.
From: Harald Welte @ 2004-01-28 9:01 UTC (permalink / raw)
To: Dirk Morris; +Cc: netfilter-devel
In-Reply-To: <4016DA5E.5020505@metavize.com>
[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]
On Tue, Jan 27, 2004 at 01:38:38PM -0800, Dirk Morris wrote:
> My apologies,
>
> I believe this is related to an experimental patch that I am using, and
> is not conntrack related.
> Conntrack nevers sees the first FIN, which would explain this behavior.
It has to be. ip_conntrack_proto_tcp uses:
unsigned long ip_ct_tcp_timeout_fin_wait = 2 MINS;
unsigned long ip_ct_tcp_timeout_close_wait = 60 SECS;
unsigned long ip_ct_tcp_timeout_last_ack = 30 SECS;
unsigned long ip_ct_tcp_timeout_time_wait = 2 MINS;
unsigned long ip_ct_tcp_timeout_close = 10 SECS;
So I see no way you could end up with this:
> >tcp 6 257147 CLOSE_WAIT src=10.0.0.44 dst=10.0.0.187 sport=43035
> >dport=7000 src=10.0.0.187 dst=10.0.0.44 sport=7000 dport=43035
> >[ASSURED] use=1
--
- Harald Welte <laforge@netfilter.org> http://www.netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Can't boot 2.6.1-mm4 or -mm5
From: "Andrey Borzenkov" @ 2004-01-28 9:09 UTC (permalink / raw)
To: "Andrew Morton" ; +Cc: linux-kernel
In-Reply-To: <20040120111554.723145eb.akpm@osdl.org>
-----Original Message-----
>
> Andrey Borzenkov <arvidjaar@mail.ru> wrote:
> >
> > I can't boot either of them. 2.6.1-mm3 was OK; compiling and booting -mm4 or
> > -mm5 with the same config as before (since 2.5.69 actually). Compiling and
> > booting with VESA framebuffer and vga=788 gives empty screen; booting with
> > vga=normal or compiling without framebuffer support goes as far as
> >
> > Uncompressing kernel ... booting
> >
> > and that is all. No disk activity either so it seems to have just stopped.
>
> Don't know, sorry. Does anyone have a slightly-sane early printk patch
> handy?
>
this was -funit-at-a-time. Removing it (with all other conditions
equal) fixes boot problem. I informed Mandrake.
See also
<http://marc.theaimsgroup.com/?t=107492024800001&r=1&w=2>
and
<http://marc.theaimsgroup.com/?t=107505102400001&r=1&w=2&n=50>
regards
-andrey
> >
> > {pts/0}% gcc --version
> > gcc-3.3.1 (GCC) 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk)
> > Copyright (C) 2003 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions. There is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> >
> > system is ASUS CUSL2, i815 chipset, GeForce2 MX videocard. lspci on 2.6.0
> > follows; config for -mm5 is attached. It was produced by using config from
> > -mm3, running make oldconfig and answering N to most new questions. It is
> > possible that there is problem with new CPU selection but I alaways compiled
> > with PentiumIII only before.
>
> I'd try enabling more CPU types, see what that does. You have SMP enabled,
> but that should be OK.
>
>
^ permalink raw reply
* [U-Boot-Users] Internal Loopback testing
From: Wolfgang Denk @ 2004-01-28 9:13 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20040128105657.1165088876.neelakantan@isofttech.com>
In message <20040128105657.1165088876.neelakantan@isofttech.com> you wrote:
>
>
> I want to verify if the networking capabilities in u-boot is working properly.So i want todo loopback testing.
Please use shorter lines, some 70 charatcers per line or so.
> Have any of u done internal loopback testing,if so could anyone pls let me know the steps involved in doing it.
Implement the featrue in the netowrk driver, and enable it in the
board configuration.
> OR Is there any code available in the web for internal loopback testing?.
The web is HUGE. Everything is available "in the web".
> I saw some code for loopback testing in cpu/mpc8260/ether_fcc.c,but in that it is given that it is an external loopback test.
"post/ether.c" contains code.
> I also tried in the net to get some information about the loopback testing,but i was not able to.
Did you try using a search engine?
> ****************************************
> Confidentiality Notice
Please don't add such silly stuff when posting to public mailing lists.
> --Pachymail_boundary_1075267617955_Part_1
> Content-Type: text/html
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
And please NEVER post HTML!!!
Best regards,
Wolfgang Denk
--
See us @ Embedded World, Nuremberg, Feb 17 - 19, Hall 12.0 Booth 440
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
Q: What's a light-year?
A: One-third less calories than a regular year.
^ permalink raw reply
* Re: Problem with i2c-algo-ibm_ocp driver on ppc405 board
From: Wolfgang Denk @ 2004-01-28 9:14 UTC (permalink / raw)
To: Matteo Bortolin; +Cc: linuxppc-embedded, llandre
In-Reply-To: <6.0.1.1.1.20040128085052.01b12d40@192.168.2.1>
Dear Matteo,
in message <6.0.1.1.1.20040128085052.01b12d40@192.168.2.1> you wrote:
>
> This would mean that a kernel that use i2c-algo-ibm_ocp.c and a i2c
> RTC-driver cannot work properly
> with CONFIG_RTC_11_MINUTE_MODE!!!
>
> Is this correct?
This is correct. This is exactly the reason why we added the
CONFIG_RTC_11_MINUTE_MODE config option in our kernel tree - with the
official kernels you will ALWAYS crash, as there is no such option.
> If yes, how can I solve my problem?
Do not enable CONFIG_RTC_11_MINUTE_MODE?
Do you understand what 11 minute mode means? And do you really,
really want such a behaviour? In almost all cases I've seen the
accuracy of the external RTC was much better than that of the system
clock. In such a case you may either just set the system time from
the RTC at boot time (and then let the system time drift out of
sync), or run NTPD to keep the system time synced with the RTC (the
RTC being the normal). I have been told that there are installations
where the 11 minute mode is being used (and believed to be useful),
but I don't know any. Especially not in embedded systems.
Best regards,
Wolfgang Denk
--
See us @ Embedded World, Nuremberg, Feb 17 - 19, Hall 12.0 Booth 440
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
The light at the end of the tunnel is usually a "No Exit" sign.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Trouble rejecting connections
From: Ben @ 2004-01-28 9:19 UTC (permalink / raw)
To: netfilter
Hello all,
I'm having trouble rejecting connections using iptables. I am using cPanel
/ WHM on a RedHat 7.3 a machine and iptables installed from
iptables-1.2.8-8.72.3.i386.rpm . I am using a script for my policy, it
looks like this.
//Start script
IPTABLES="/sbin/iptables"
#Flush everything, start from scratch
$IPTABLES -F
#Set default policies to DROP
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
#Allow all lo traffic
$IPTABLES -A INPUT -i lo -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT
#Allow all related and established connections
$IPTABLES -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
#Set default OUTPUT policy to ACCEPT
$IPTABLES -P OUTPUT ACCEPT
# Open ports for server/services
$IPTABLES -A INPUT -p tcp --dport 20 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 21 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 22 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 25 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 37 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 43 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 53 -j ACCEPT
$IPTABLES -A INPUT -p udp --dport 53 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 80 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 110 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 113 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 143 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 443 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 465 -j ACCEPT
$IPTABLES -A INPUT -p udp --dport 465 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 873 -j ACCEPT
$IPTABLES -A INPUT -p udp --dport 873 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 993 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 995 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 2082 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 2083 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 2086 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 2087 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 2089 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 2095 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 3306 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 6666 -j ACCEPT
#Enable Blogger support (non-standards compliant piece of dogshit that it
is)
$IPTABLES -A INPUT -s 66.102.15.83 -j ACCEPT
$IPTABLES -A INPUT -s 216.34.7.186 -j ACCEPT
#Add passive-mode people here
#$IPTABLES -A INPUT -s xxx.xxx.xxx.xxx -j ACCEPT
#Add DENY people here
#$IPTABLES -A INPUT -s 000.000.000.000 -j DROP
$IPTABLES -A INPUT -s blocked.ip.address.here -j DROP
#Logging
$IPTABLES -A INPUT -j LOG --log-prefix "INPUTDEFAULT: "
#Save rules
iptables-save > /etc/sysconfig/iptables
#Restart for rules to take effect
service iptables restart
//End script
The problem is that I can still connect from blocked.ip.address.here. What
did I miss?
Ben Prince
Cyber Pixels
Systems Administrator
ben@cyberpixels.com
^ permalink raw reply
* Re: 2.6.1 dual xeon
From: Helge Hafting @ 2004-01-28 9:32 UTC (permalink / raw)
To: Alexander Nyberg; +Cc: LKML
In-Reply-To: <1075223587.1173.5.camel@llhosts>
Alexander Nyberg wrote:
> But I can't see a reason for not dividing the different interrupt on
> different cpu's and letting them stay put.
You want to spread the load, but that is hard to do without knowing
which interrupt sources are heavy and which are light.
Dividing them once might end up with keyboard & mouse interrupts
on one cpu and network+disk on another. This is clearly imbalanced.
An irq balancing utility will fix this, by balancing based
on interrupt count.
> Maybe if you keep all
> interrupts on the same cpu the cache on the other ones will not have to
> be flushed often, which would be a good thing.
>
> How would it be to maybe remove all interrupts from a cpu (except
> between cpu's) and have a few cpu's merely working with data and one "in
> control". Bad idea I guess as I haven't seen any such work.
Makes sense only if the amounts of interrupt work and other work matches
the division you make.
Helge Hafting
^ permalink raw reply
* [U-Boot-Users] questions regarding support for new command (getspr/setspr)
From: Wolfgang Denk @ 2004-01-28 9:20 UTC (permalink / raw)
To: u-boot
In-Reply-To: <D8A54727-5154-11D8-A361-000393DBC2E8@motorola.com>
In message <D8A54727-5154-11D8-A361-000393DBC2E8@motorola.com> you wrote:
> I was wondering if it was considered useful to extend the
> CFG_CMD_SETGETDCR done by Erik Theisen for DCR registers on the 4xx
> family to all PowerPC products for SPRs (CFG_CMD_SETGETSPR).
That would be useful.
> 1. Is it ok that the command does not do any checking on the SPR
> number. This is quick difficult and would have to be done per
> processor since what SPRs exists is implementation specific. If the
> user gives the commands an SPR that does not exist the result is going
> to be some exception (is this ok)
IMHO only valid SPRs should be accepted. Yes, this requires processor
specific code.
> 2. What numerical format should the spr number for the command be taken
> in? My think is decimal
The format should be string (i. e. register NAME). For SPRs without a
name and/or alternatively a decimal number is ok. Without a register
name/number the "get" command should print all known SPR's on that
processor.
> 3. For setspr what numerical format should the spr value be taken in?
> My thinking is hex
Hex like all standard input data in U-Boot.
> 4. For getspr what numerical format should the spr be printed in? My
> thinking is hex
The register name should be string plus decimal number; the value
should be hex.
> If so, I will fixup my working patch and submit it once I get answers
> to the questions.
Thanks in advance.
Best regards,
Wolfgang Denk
--
See us @ Embedded World, Nuremberg, Feb 17 - 19, Hall 12.0 Booth 440
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
Ernest asks Frank how long he has been working for the company.
"Ever since they threatened to fire me."
^ permalink raw reply
* Re: [Jfs-discussion] md raid + jfs + jfs_fsck
From: venom @ 2004-01-28 9:24 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Dave Kleikamp, Florian Huber, JFS Discussion, linux-kernel
In-Reply-To: <20040127205324.A19913@infradead.org>
On Tue, 27 Jan 2004, Christoph Hellwig wrote:
>
> Yes, it does. But JFS should get the right size from the gendisk anyway.
> Or did you create the raid with the filesystem already existant? While that
> appears to work for a non-full ext2/ext3 filesystem it's not something you
> should do because it makes the filesystem internal bookkeeping wrong and
> you'll run into trouble with any filesystem sooner or later.
>
In most situation to create a new FS on a RAID1 MD is not an option.
It happens that you have to mirror a partition, maybe alarge one, and it
already had a filesystem on top of it. Then what should you do?
backup, mirror and then restore? Sometimes it is not possible this too.
Then you accept to deal with the possible problems...
Luigi
^ permalink raw reply
* Re: [PATCH]Re: NAT before IPsec with 2.6
From: Patrick McHardy @ 2004-01-28 9:37 UTC (permalink / raw)
To: Harald Welte
Cc: Henrik Nordstrom, Willy Tarreau, Tom Eastep, Michal Ludvig,
netfilter-devel
In-Reply-To: <401777B4.9020000@trash.net>
Patrick McHardy wrote:
>I see two problems with this approach. The dummy devices don't have
>
>
>any ip config, so f.e. REDIRECT will fail. The bigger problem is
>
>
>hooking in output routines that return NET_XMIT_BYPASS. dst_output
>
>
>loops until the return code of skb->dst->output != NET_XMIT_BYPASS.
>
>
>These output routines replace skb->dst when finished by calling dst_pop.
>
>
>If we pass the packet through netfilter in between, the dst_entry
>
>
>might get replaced in ip_route_me_harder or elsewhere and not all
>
>
>transformations will be applied. If NAT is used,
>
>
>ip_route_{input,output} might even return a different policy bundle.
>
Bad news, I've tested the hook part (using skb->dev instead of ah4/esp4
devices), this is how the traces look:
IN= OUT=eth0 SRC=172.20.0.3 DST=192.168.0.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=28443 SEQ=1
IN= OUT= SRC=172.20.0.3 DST=192.168.0.1 LEN=152 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ESP SPI=0xb9f7900
IN= OUT= SRC=172.20.0.3 DST=192.168.0.1 LEN=176 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=AH SPI=0xc46e27
After applying a MARK rule to the first packet (causing rerouting):
IN= OUT=eth0 SRC=172.20.0.3 DST=192.168.0.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=51484 SEQ=1
Sniffing in between shows the unencrypted packet.
>Regards,
>
>
>Patrick
>
>
>
>
>
^ permalink raw reply
* Machine check exception event
From: Raphael Jacquot @ 2004-01-28 9:36 UTC (permalink / raw)
To: linux-kernel
Hi,
this morning when I got to work, I had :
Message from syslogd@raph at Wed Jan 28 01:41:32 2004 ...
raph kernel: Bank 1: 9000000000000171
Message from syslogd@raph at Wed Jan 28 01:41:32 2004 ...
raph kernel: MCE: The hardware reports a non fatal, correctable incident
occurred on CPU 0.
using the
http://www.kernel.org/pub/linux/kernel/people/davej/tools/parsemce.c
program, I got the following :
[sxpert@raph compile]$ ./parsemce -e 9000000000000171
Status: (9000000000000171) Restart IP valid.
what does that mean ?
running kernel 2.6.1 on a duron 1100, Leadtek K7NCR18G PRO mother board
(Nforce2)
sincerely
Raphael
^ permalink raw reply
* Re: [Jfs-discussion] md raid + jfs + jfs_fsck
From: Christoph Hellwig @ 2004-01-28 9:38 UTC (permalink / raw)
To: venom; +Cc: Dave Kleikamp, Florian Huber, JFS Discussion, linux-kernel
In-Reply-To: <Pine.LNX.4.43.0401281021030.31225-100000@cibs9.sns.it>
On Wed, Jan 28, 2004 at 10:24:14AM +0100, venom@sns.it wrote:
> In most situation to create a new FS on a RAID1 MD is not an option.
> It happens that you have to mirror a partition, maybe alarge one, and it
> already had a filesystem on top of it. Then what should you do?
> backup, mirror and then restore? Sometimes it is not possible this too.
> Then you accept to deal with the possible problems...
Then you need to shrink the filesystem. As long as the space isn't used
yet it's rather trivial for most ondisk formats, but you absolutely need
to do it to be safe.
^ permalink raw reply
* RE: [patch] PCI Express Enhanced Config Patch - 2.6.0-test11
From: Durairaj, Sundarapandian @ 2004-01-28 9:38 UTC (permalink / raw)
To: linux-kernel, linux-pci
Cc: torvalds, alan, greg, Andi Kleen, akpm, mj, Kondratiev, Vladimir,
Seshadri, Harinarayanan, Nakajima, Jun, Durairaj, Sundarapandian
[-- Attachment #1: Type: text/plain, Size: 730 bytes --]
Hi All,
Thanks for your comments. I am posting this patch after incorporating
the review comments.
Please find the attached patch file. Please review this and send your
comments.
Thanks,
Sundar
Note:
This is the patch on PCI Express Enhanced configuration for 2.6.0 test11
kernel following up to the Vladimir (Vladimir.Kondratiev@intel.com) and
Harinarayanan (Harinarayanan.Seshadri@intel.com) and my previous
patches .
I tested it on our i386 platform.
This patch also implements a mechanism for the kernel to find the
chipset specific mmcfg base address. The kernel will detect the base
address of the chipset through the ACPI table entry and based on that
the PCI subsystem will be initialized.
[-- Attachment #2: mcfg_2.6.lkml.patch --]
[-- Type: application/octet-stream, Size: 15758 bytes --]
diff -Naur linux-2.6.0/arch/i386/Kconfig linux_pciexpress/arch/i386/Kconfig
--- linux-2.6.0/arch/i386/Kconfig 2003-12-18 08:28:16.000000000 +0530
+++ linux_pciexpress/arch/i386/Kconfig 2004-01-28 12:04:20.000000000 +0530
@@ -959,7 +959,7 @@
endmenu
-menu "Bus options (PCI, PCMCIA, EISA, MCA, ISA)"
+menu "Bus options (PCI, PCMCIA, EISA, MCA, ISA, PCI_EXPRESS)"
config X86_VISWS_APIC
bool
@@ -976,6 +976,18 @@
depends on SMP && !(X86_VISWS || X86_VOYAGER)
default y
+config PCI_EXPRESS
+ bool "PCI_EXPRESS (EXPERIMENTAL)"
+ depends on EXPERIMENTAL && ACPI_BOOT
+ help
+ PCI Express extends the configuration space from 256 bytes to
+ 4k bytes. It also defines an enhanced configuration mechanism
+ to access the extended configuration space. With this option,
+ you can specify that Linux will first attempt to access the
+ PCI configuration space through enhanced config access
+ mechanism (will work only on PCI Express based system)
+ otherwise other standard PCI access mechanism will be used.
+
config PCI
bool "PCI support" if !X86_VISWS
depends on !X86_VOYAGER
diff -Naur linux-2.6.0/arch/i386/kernel/acpi/boot.c linux_pciexpress/arch/i386/kernel/acpi/boot.c
--- linux-2.6.0/arch/i386/kernel/acpi/boot.c 2003-12-18 08:29:29.000000000 +0530
+++ linux_pciexpress/arch/i386/kernel/acpi/boot.c 2004-01-28 11:43:28.000000000 +0530
@@ -93,6 +93,27 @@
return ((unsigned char *) base + offset);
}
+#ifdef CONFIG_PCI_EXPRESS
+static int __init acpi_parse_mcfg
+ (unsigned long phys_addr, unsigned long size)
+{
+ struct acpi_table_mcfg *mcfg = NULL;
+
+ if (!phys_addr || !size)
+ return -EINVAL;
+
+ mcfg = (struct acpi_table_mcfg *) __acpi_map_table
+ (phys_addr, size);
+ if (!mcfg) {
+ printk(KERN_WARNING PREFIX "Unable to map MCFG\n");
+ return -ENODEV;
+ }
+ if (mcfg->base_address)
+ mmcfg_base_address = mcfg->base_address;
+
+ return 0;
+}
+#endif /* CONFIG_PCI_EXPRESS */
#ifdef CONFIG_X86_LOCAL_APIC
@@ -508,6 +529,22 @@
#endif /* CONFIG_X86_IO_APIC && CONFIG_ACPI_INTERPRETER */
+#ifdef CONFIG_PCI_EXPRESS
+ result = acpi_table_parse(ACPI_MCFG, acpi_parse_mcfg);
+ if (!result) {
+ printk(KERN_WARNING PREFIX "MCFG not present\n");
+ return 0;
+ }
+ else if (result < 0) {
+ printk(KERN_ERR PREFIX "Error parsing MCFG\n");
+ return result;
+ }
+ else if (result > 1) {
+ printk(KERN_WARNING PREFIX
+ "Multiple MCFG tables exist\n");
+ }
+#endif /* CONFIG_PCI_EXPRESS */
+
#ifdef CONFIG_X86_LOCAL_APIC
if (acpi_lapic && acpi_ioapic) {
smp_found_config = 1;
diff -Naur linux-2.6.0/arch/i386/pci/common.c linux_pciexpress/arch/i386/pci/common.c
--- linux-2.6.0/arch/i386/pci/common.c 2003-12-18 08:28:46.000000000 +0530
+++ linux_pciexpress/arch/i386/pci/common.c 2004-01-28 11:51:38.000000000 +0530
@@ -19,7 +19,8 @@
extern void pcibios_sort(void);
#endif
-unsigned int pci_probe = PCI_PROBE_BIOS | PCI_PROBE_CONF1 | PCI_PROBE_CONF2;
+unsigned int pci_probe = PCI_PROBE_BIOS | PCI_PROBE_CONF1 | PCI_PROBE_CONF2
+ | PCI_PROBE_ENHANCED;
int pcibios_last_bus = -1;
struct pci_bus *pci_root_bus = NULL;
@@ -197,6 +198,12 @@
return NULL;
}
#endif
+#ifdef CONFIG_PCI_EXPRESS
+ else if (!strcmp(str, "nopciexpress")) {
+ pci_probe &= ~PCI_PROBE_ENHANCED;
+ return NULL;
+ }
+#endif
#ifdef CONFIG_ACPI_PCI
else if (!strcmp(str, "noacpi")) {
pci_probe |= PCI_NO_ACPI_ROUTING;
diff -Naur linux-2.6.0/arch/i386/pci/direct.c linux_pciexpress/arch/i386/pci/direct.c
--- linux-2.6.0/arch/i386/pci/direct.c 2003-12-18 08:28:28.000000000 +0530
+++ linux_pciexpress/arch/i386/pci/direct.c 2004-01-28 11:27:07.000000000 +0530
@@ -167,6 +167,73 @@
};
+#ifdef CONFIG_PCI_EXPRESS
+/*
+ * We map full Page size on each PCI Express request. Incidentally that's
+ * the size we have for config space too in PCI Express devices.
+ * On PCI Express capable platform, at the time of kernel initialization
+ * the OS would have scanned for MCFG table and set this variable to
+ * appropriate value. If PCI Express not supported the variable will
+ * have 0 value
+ */
+u32 mmcfg_base_address;
+
+/*
+ * Variable used to store the virtual address of fixed PTE
+ */
+char *mmcfg_virt_addr;
+
+/*
+ * Variable used to store the base address of the last PCI Express device
+ * accessed.
+ */
+u32 pcie_last_accessed_device;
+
+static int pci_express_conf_read(int seg, int bus,
+ int devfn, int reg, int len, u32 *value)
+{
+ if (!value || (bus > 255) || (devfn > 255) || (reg > 4095)) {
+ printk(KERN_ERR "pci_express_conf_read: "
+ "Invalid Parameter\n");
+ return -EINVAL;
+ }
+
+ /* Shoot misaligned transaction now */
+ if (reg & (len-1)) {
+ printk(KERN_ERR "pci_express_conf_read: "
+ "misaligned transaction\n");
+ return -EINVAL;
+ }
+ pci_express_read(bus, devfn, reg, len, value);
+
+ return 0;
+}
+
+static int pci_express_conf_write(int seg, int bus,
+ int devfn, int reg, int len, u32 value)
+{
+ if ((bus > 255) || (devfn > 255) || (reg > 4095)) {
+ printk(KERN_ERR "pci_express_conf_write: "
+ "Invalid Parameter\n");
+ return -EINVAL;
+ }
+
+ /* Shoot misaligned transaction now */
+ if (reg & (len-1)) {
+ printk(KERN_ERR "pci_express_conf_write: "
+ "misaligned transaction\n");
+ return -EINVAL;
+ }
+ pci_express_write(bus, devfn, reg, len, value);
+ return 0;
+}
+
+static struct pci_raw_ops pci_express_conf = {
+ .read = pci_express_conf_read,
+ .write = pci_express_conf_write,
+};
+#endif /* CONFIG_PCI_EXPRESS */
+
/*
* Before we decide to use direct hardware access mechanisms, we try to do some
* trivial checks to ensure it at least _seems_ to be working -- we just test
@@ -244,7 +311,30 @@
static int __init pci_direct_init(void)
{
struct resource *region, *region2;
+
+#ifdef CONFIG_PCI_EXPRESS
+ if ((pci_probe & PCI_PROBE_ENHANCED) == 0)
+ goto type1;
+ /*
+ * Check if platform we are running is PCI Express capable
+ */
+ if (mmcfg_base_address == 0) {
+ printk(KERN_INFO
+ "MCFG table entry is not found in ACPI tables....\n"
+ "Not enabling Enhanced Configuration....\n");
+ goto type1;
+ }
+ /* Calculate the virtual address of the PTE */
+ mmcfg_virt_addr = (char *)fix_to_virt(FIX_PCIE_MCFG);
+
+ if (pci_sanity_check(&pci_express_conf)) {
+ printk(KERN_INFO "PCI: Using config type PCIExp\n");
+ raw_pci_ops = &pci_express_conf;
+ return 0;
+ }
+type1:
+#endif /* CONFIG_PCI_EXPRESS */
if ((pci_probe & PCI_PROBE_CONF1) == 0)
goto type2;
region = request_region(0xCF8, 8, "PCI conf1");
diff -Naur linux-2.6.0/arch/i386/pci/Makefile linux_pciexpress/arch/i386/pci/Makefile
--- linux-2.6.0/arch/i386/pci/Makefile 2003-12-18 08:28:57.000000000 +0530
+++ linux_pciexpress/arch/i386/pci/Makefile 2004-01-26 13:32:28.000000000 +0530
@@ -2,6 +2,7 @@
obj-$(CONFIG_PCI_BIOS) += pcbios.o
obj-$(CONFIG_PCI_DIRECT) += direct.o
+obj-$(CONFIG_PCI_EXPRESS) += direct.o
pci-y := fixup.o
pci-$(CONFIG_ACPI_PCI) += acpi.o
diff -Naur linux-2.6.0/arch/i386/pci/pci.h linux_pciexpress/arch/i386/pci/pci.h
--- linux-2.6.0/arch/i386/pci/pci.h 2003-12-18 08:28:57.000000000 +0530
+++ linux_pciexpress/arch/i386/pci/pci.h 2004-01-26 13:32:28.000000000 +0530
@@ -15,6 +15,11 @@
#define PCI_PROBE_BIOS 0x0001
#define PCI_PROBE_CONF1 0x0002
#define PCI_PROBE_CONF2 0x0004
+#ifdef CONFIG_PCI_EXPRESS
+#define PCI_PROBE_ENHANCED 0x0008
+#else
+#define PCI_PROBE_ENHANCED 0x0
+#endif
#define PCI_NO_SORT 0x0100
#define PCI_BIOS_SORT 0x0200
#define PCI_NO_CHECKS 0x0400
diff -Naur linux-2.6.0/drivers/acpi/tables.c linux_pciexpress/drivers/acpi/tables.c
--- linux-2.6.0/drivers/acpi/tables.c 2003-12-18 08:28:46.000000000 +0530
+++ linux_pciexpress/drivers/acpi/tables.c 2004-01-26 13:31:51.000000000 +0530
@@ -58,6 +58,7 @@
[ACPI_SSDT] = "SSDT",
[ACPI_SPMI] = "SPMI",
[ACPI_HPET] = "HPET",
+ [ACPI_MCFG] = "MCFG",
};
/* System Description Table (RSDT/XSDT) */
diff -Naur linux-2.6.0/drivers/pci/pci.c linux_pciexpress/drivers/pci/pci.c
--- linux-2.6.0/drivers/pci/pci.c 2003-12-18 08:28:38.000000000 +0530
+++ linux_pciexpress/drivers/pci/pci.c 2004-01-26 13:31:40.000000000 +0530
@@ -90,6 +90,8 @@
* %PCI_CAP_ID_CHSWP CompactPCI HotSwap
*
* %PCI_CAP_ID_PCIX PCI-X
+ * %PCI_CAP_ID_EXP PCI-EXP
+
*/
int
pci_find_capability(struct pci_dev *dev, int cap)
diff -Naur linux-2.6.0/drivers/pci/probe.c linux_pciexpress/drivers/pci/probe.c
--- linux-2.6.0/drivers/pci/probe.c 2003-12-18 08:29:06.000000000 +0530
+++ linux_pciexpress/drivers/pci/probe.c 2004-01-28 12:06:39.000000000 +0530
@@ -17,6 +17,8 @@
#define CARDBUS_LATENCY_TIMER 176 /* secondary latency timer */
#define CARDBUS_RESERVE_BUSNR 3
+#define PCI_CFG_SPACE_SIZE 256
+#define PCI_CFG_SPACE_EXP_SIZE 4096
/* Ugh. Need to stop exporting this to modules. */
LIST_HEAD(pci_root_buses);
@@ -479,6 +481,22 @@
kfree(pci_dev);
}
+/*
+ * pci_cfg_space_size - get the configuration space size of the PCI device
+ */
+static int pci_cfg_space_size(struct pci_dev *dev)
+{
+#ifdef CONFIG_PCI_EXPRESS
+ /* Find whether the device is PCI Express device */
+ int is_pci_express_dev =
+ pci_find_capability(dev, PCI_CAP_ID_EXP);
+ if (is_pci_express_dev)
+ return PCI_CFG_SPACE_EXP_SIZE;
+ else
+#endif
+ return PCI_CFG_SPACE_SIZE;
+}
+
/*
* Read the config data for a PCI device, sanity-check it
* and fill in the dev structure...
@@ -515,6 +533,7 @@
dev->multifunction = !!(hdr_type & 0x80);
dev->vendor = l & 0xffff;
dev->device = (l >> 16) & 0xffff;
+ dev->cfg_size = pci_cfg_space_size(dev);
/* Assume 32-bit PCI; let 64-bit PCI cards (which are far rarer)
set this higher, assuming the system even supports it. */
diff -Naur linux-2.6.0/drivers/pci/proc.c linux_pciexpress/drivers/pci/proc.c
--- linux-2.6.0/drivers/pci/proc.c 2003-12-18 08:28:57.000000000 +0530
+++ linux_pciexpress/drivers/pci/proc.c 2004-01-26 15:45:34.000000000 +0530
@@ -16,14 +16,15 @@
#include <asm/uaccess.h>
#include <asm/byteorder.h>
-#define PCI_CFG_SPACE_SIZE 256
-
static int proc_initialized; /* = 0 */
static loff_t
proc_bus_pci_lseek(struct file *file, loff_t off, int whence)
{
loff_t new = -1;
+ const struct inode *ino = file->f_dentry->d_inode;
+ const struct proc_dir_entry *dp = PDE(ino);
+ struct pci_dev *dev = dp->data;
lock_kernel();
switch (whence) {
@@ -34,11 +35,11 @@
new = file->f_pos + off;
break;
case 2:
- new = PCI_CFG_SPACE_SIZE + off;
+ new = dev->cfg_size + off;
break;
}
unlock_kernel();
- if (new < 0 || new > PCI_CFG_SPACE_SIZE)
+ if (new < 0 || new > dev->cfg_size)
return -EINVAL;
return (file->f_pos = new);
}
@@ -59,7 +60,7 @@
*/
if (capable(CAP_SYS_ADMIN))
- size = PCI_CFG_SPACE_SIZE;
+ size = dev->cfg_size;
else if (dev->hdr_type == PCI_HEADER_TYPE_CARDBUS)
size = 128;
else
@@ -133,13 +134,14 @@
struct pci_dev *dev = dp->data;
int pos = *ppos;
int cnt;
+ int size = dev->cfg_size;
- if (pos >= PCI_CFG_SPACE_SIZE)
+ if (pos >= size)
return 0;
- if (nbytes >= PCI_CFG_SPACE_SIZE)
- nbytes = PCI_CFG_SPACE_SIZE;
- if (pos + nbytes > PCI_CFG_SPACE_SIZE)
- nbytes = PCI_CFG_SPACE_SIZE - pos;
+ if (nbytes >= size)
+ nbytes = size;
+ if (pos + nbytes > size)
+ nbytes = size - pos;
cnt = nbytes;
if (!access_ok(VERIFY_READ, buf, cnt))
@@ -401,7 +403,7 @@
return -ENOMEM;
e->proc_fops = &proc_bus_pci_operations;
e->data = dev;
- e->size = PCI_CFG_SPACE_SIZE;
+ e->size = dev->cfg_size;
return 0;
}
diff -Naur linux-2.6.0/include/asm-i386/fixmap.h linux_pciexpress/include/asm-i386/fixmap.h
--- linux-2.6.0/include/asm-i386/fixmap.h 2003-12-18 08:28:06.000000000 +0530
+++ linux_pciexpress/include/asm-i386/fixmap.h 2004-01-26 13:33:49.000000000 +0530
@@ -67,6 +67,9 @@
FIX_KMAP_BEGIN, /* reserved pte's for temporary kernel mappings */
FIX_KMAP_END = FIX_KMAP_BEGIN+(KM_TYPE_NR*NR_CPUS)-1,
#endif
+#ifdef CONFIG_PCI_EXPRESS
+ FIX_PCIE_MCFG,
+#endif
#ifdef CONFIG_ACPI_BOOT
FIX_ACPI_BEGIN,
FIX_ACPI_END = FIX_ACPI_BEGIN + FIX_ACPI_PAGES - 1,
diff -Naur linux-2.6.0/include/asm-i386/pci.h linux_pciexpress/include/asm-i386/pci.h
--- linux-2.6.0/include/asm-i386/pci.h 2003-12-18 08:28:47.000000000 +0530
+++ linux_pciexpress/include/asm-i386/pci.h 2004-01-28 11:33:51.000000000 +0530
@@ -96,4 +96,76 @@
/* generic pci stuff */
#include <asm-generic/pci.h>
+#ifdef CONFIG_PCI_EXPRESS
+extern spinlock_t pci_config_lock;
+
+/*
+ * Variable used to store the base address of the last PCI Express device
+ * accessed.
+ */
+extern u32 pcie_last_accessed_device;
+
+/*
+ * Variable used to store the base address of the chipset
+ */
+extern u32 mmcfg_base_address;
+
+/*
+ * Variable used to store the virtual address of fixed PTE
+ */
+extern char *mmcfg_virt_addr;
+
+static inline void pci_exp_set_dev_base(int bus, int devfn)
+{
+ u32 dev_base =
+ mmcfg_base_address | (bus << 20) | (devfn << 12);
+ if (dev_base != pcie_last_accessed_device) {
+ pcie_last_accessed_device = dev_base;
+ set_fixmap(FIX_PCIE_MCFG, dev_base);
+ }
+}
+
+static inline void pci_express_read(int bus, int devfn, int reg,
+ int len, u32 *value)
+{
+ unsigned long flags;
+ spin_lock_irqsave(&pci_config_lock, flags);
+ pci_exp_set_dev_base(bus, devfn);
+ switch (len) {
+ case 1:
+ *value = (u8)readb(mmcfg_virt_addr + reg);
+ break;
+ case 2:
+ *value = (u16)readw(mmcfg_virt_addr + reg);
+ break;
+ case 4:
+ *value = (u32)readl(mmcfg_virt_addr + reg);
+ break;
+ }
+ spin_unlock_irqrestore(&pci_config_lock, flags);
+}
+
+static inline void pci_express_write(int bus, int devfn, int reg,
+ int len, u32 value)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&pci_config_lock, flags);
+ pci_exp_set_dev_base(bus, devfn);
+ switch (len) {
+ case 1:
+ writeb(value, mmcfg_virt_addr + reg);
+ break;
+ case 2:
+ writew(value, mmcfg_virt_addr + reg);
+ break;
+ case 4:
+ writel(value, mmcfg_virt_addr + reg);
+ break;
+ }
+ /* Dummy read to flush PCI write */
+ readl(mmcfg_virt_addr);
+ spin_unlock_irqrestore(&pci_config_lock, flags);
+}
+#endif /* CONFIG_PCI_EXPRESS */
#endif /* __i386_PCI_H */
diff -Naur linux-2.6.0/include/linux/acpi.h linux_pciexpress/include/linux/acpi.h
--- linux-2.6.0/include/linux/acpi.h 2003-12-18 08:27:58.000000000 +0530
+++ linux_pciexpress/include/linux/acpi.h 2004-01-26 13:33:09.000000000 +0530
@@ -317,6 +317,13 @@
char ec_id[0];
} __attribute__ ((packed));
+struct acpi_table_mcfg {
+ struct acpi_table_header header;
+ u8 reserved[8];
+ u32 base_address;
+ u32 base_reserved;
+} __attribute__ ((packed));
+
/* Table Handlers */
enum acpi_table_id {
@@ -338,6 +345,7 @@
ACPI_SSDT,
ACPI_SPMI,
ACPI_HPET,
+ ACPI_MCFG,
ACPI_TABLE_COUNT
};
@@ -437,4 +445,7 @@
#endif /*!CONFIG_ACPI_INTERPRETER*/
+#ifdef CONFIG_PCI_EXPRESS
+extern u32 mmcfg_base_address;
+#endif
#endif /*_LINUX_ACPI_H*/
diff -Naur linux-2.6.0/include/linux/pci.h linux_pciexpress/include/linux/pci.h
--- linux-2.6.0/include/linux/pci.h 2003-12-18 08:28:49.000000000 +0530
+++ linux_pciexpress/include/linux/pci.h 2004-01-26 15:47:23.000000000 +0530
@@ -198,6 +198,7 @@
#define PCI_CAP_ID_MSI 0x05 /* Message Signalled Interrupts */
#define PCI_CAP_ID_CHSWP 0x06 /* CompactPCI HotSwap */
#define PCI_CAP_ID_PCIX 0x07 /* PCI-X */
+#define PCI_CAP_ID_EXP 0x10 /* PCI-Express */
#define PCI_CAP_LIST_NEXT 1 /* Next capability in the list */
#define PCI_CAP_FLAGS 2 /* Capability defined flags (16 bits) */
#define PCI_CAP_SIZEOF 4
@@ -424,6 +425,7 @@
#define PCI_NAME_HALF __stringify(20) /* less than half to handle slop */
char pretty_name[PCI_NAME_SIZE]; /* pretty name for users to see */
#endif
+ int cfg_size;
};
#define pci_dev_g(n) list_entry(n, struct pci_dev, global_list)
^ permalink raw reply
* Re: 2.6.2-rc2-mm1
From: Christoph Hellwig @ 2004-01-28 9:41 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm, netdev
In-Reply-To: <20040127233402.6f5d3497.akpm@osdl.org>
On Tue, Jan 27, 2004 at 11:34:02PM -0800, Andrew Morton wrote:
> Jeff's tree: netdev.patch
Any plan when we'll get the damn netdev lifetime rule fixes merged?
They're real life problems and have been around for a long time..
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply
* Re: 2.6.2-rc2-mm1
From: Christoph Hellwig @ 2004-01-28 9:41 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm, netdev
In-Reply-To: <20040127233402.6f5d3497.akpm@osdl.org>
On Tue, Jan 27, 2004 at 11:34:02PM -0800, Andrew Morton wrote:
> Jeff's tree: netdev.patch
Any plan when we'll get the damn netdev lifetime rule fixes merged?
They're real life problems and have been around for a long time..
^ permalink raw reply
* libselinux/getpeercon/compiler warning on 64bit Archs
From: Thorsten Kukuk @ 2004-01-28 9:41 UTC (permalink / raw)
To: selinux
Hi,
On 64bit architectures, I get the follwoing compiler warnings:
getpeercon.c:26: warning: passing arg 5 of `getsockopt' from incompatible pointer type
getpeercon.c:36: warning: passing arg 5 of `getsockopt' from incompatible pointer type
The fix is simple, the variable "size" in getpeercon() should be from
type "socklen_t", not "ssize_t".
Thorsten
--
Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de
SuSE Linux AG Maxfeldstr. 5 D-90409 Nuernberg
--------------------------------------------------------------------
Key fingerprint = A368 676B 5E1B 3E46 CFCE 2D97 F8FD 4E23 56C6 FB4B
--
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
* Rejected no-local
From: REJECT-DAEMON-XoJDOot2J3yELgA04lAiVw @ 2004-01-28 9:45 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3567 bytes --]
--------------------------------------------------
.. "nmr" unknown here in this Domain..
.. letter returned to "acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org" ..
--------------------------------------------------
Return-Path: <acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
From: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Received: by iis.fhg.de with ESMTP; Wed, 28 Jan 2004 10:45:23 +0100 (MET) from mailgwb1.fraunhofer.de
Received: from mailgwb1.fraunhofer.de (localhost [127.0.0.1])
by mailgwb1.fraunhofer.de (8.12.10/8.12.10) with ESMTP id i0S9caZu020141
for <nmr-XoJDOot2J3yELgA04lAiVw@public.gmane.org>; Wed, 28 Jan 2004 10:38:36 +0100 (MET)
Received: from lists.sourceforge.net ([218.18.203.176])
by mailgwb1.fraunhofer.de (8.12.10/8.12.10) with ESMTP id i0S9cT45020053
for <nmr-XoJDOot2J3yELgA04lAiVw@public.gmane.org>; Wed, 28 Jan 2004 10:38:31 +0100 (MET)
Message-Id: <200401280938.i0S9cT45020053-K7LqVtaqouYPualYiKnuABbt6QYYyz1t@public.gmane.org>
To: nmr-XoJDOot2J3yELgA04lAiVw@public.gmane.org
Subject: test
Date: Wed, 28 Jan 2004 17:44:06 +0800
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0003_7A70B1A1.AAFDABAB"
X-Priority: 3
X-MSMail-Priority: Normal
X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on
spamd1.fraunhofer.de
X-Spam-Level: **
X-Spam-Status: No, hits=2.4 required=5.0 tests=MICROSOFT_EXECUTABLE,
MISSING_MIMEOLE,NO_REAL_NAME,PRIORITY_NO_NAME,UPPERCASE_25_50
autolearn=no version=2.61
X-Spamd-Host: spamd1.fraunhofer.de
This is a multi-part message in MIME format.
------=_NextPart_000_0003_7A70B1A1.AAFDABAB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
------------------ Virus-Warnung/virus alert (mailgateway mailgwb1)
Found virus WORM_MIMAIL.R in file file.scr
The file file.scr is moved to /etc/iscan/virus/virMKAOwaymx.
Bei Fragen wenden Sie sich bitte an NOC-Helpdesk-BQS24JF/HUMP3drIcvDWNA@public.gmane.org you have questions, please contact NOC-Helpdesk@fhg.de.
---------------------------------------------------------
------=_NextPart_000_0003_7A70B1A1.AAFDABAB
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: 7bit
•
†â†¬˜útô/÷YRá4ùícÕ}GÄ2êàð0‚ª`“%˸8‘«%]õºû·"sÖÄÊUc’F?/13ª4ï¥åˆ„‹´±l¶-t?«MBN^“{æøÌrÀƒ`l®äOÏ#±xk°jÞ¢lª>a6¸•öNów?¥9øZºöÍßZÁIÁTbgv)•ÑU£Þc>œAëÑŒ• æÁÊœ7V;-$Mp_õRQm”–-ÜdUò"-ü8›öþþøçö¨Z-LÖÓYŠ#nøhMcâט¬™ßH΃Aî£|pªKÆö96"6;×lsÄ
zü«Öõ
êr%3‰‡U‡éõÂûýk¼ð‚PÄšMæTh…ŒíåR¥Ó\Áõ¼îQfF:¹¹ŒÍð|ÂÐéI\T9¦”Û4T›ª*fèkãS:¨–Z¡<^ŽÂJƒ`ÌŒÜhÚ1ŸûµÁµàÇ`v#™¹"Æ#°!žMá$;Q—¥If×zë˜:Ò·dú¼ëɳˆäÍçO¦÷{jYÕ9øÈvO[âîͺ;×(~ŠÍ»Ö*ïC5›b`Ò
ƾ¬7ãWniÌg/hÁz¯Ox&xø°å×Þ§“aŸ¢òj[½ö/Ë*ߪâ
™ž $<õ.ú7ƒz–'Sq\Ùâ‡feçM«íé¸37Eþ½ÅâTVªåqŒ¢Ít2‹ ^Þéæ•kd*avG~qâÆÅwÓ2WçÛØ|ñle¨‹õø!Ýx¢„ÄìBPUOŠ¯¸ñc¤LÔÂmÍsmAÕ{Q[Iá„N¼àƒÏUˆÚ/<\¸Ù55oÖþÕU‰¾pÖ$%¤!pY³¿ç8¶5ÜôݤêǪdäOq¾aͤmhyÄöŸaLô½84#;ðDqLå¡aUV¡á
󀱧D
Ì_u–󒾯^õIdø±*«ÑüTaGfùÜAÔölTkZT¶1wã£9xLänë·aõ¹ndÁÒ§U4Ç‹ôçŒÕU‘§•ˆjâtæ©
------=_NextPart_000_0003_7A70B1A1.AAFDABAB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
------------------ Virus-Warnung/virus alert (mailgateway mailgwb1)
file.scr is removed from here because it contains a virus.
---------------------------------------------------------
------=_NextPart_000_0003_7A70B1A1.AAFDABAB--
-------------------------------------------------------
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: Trouble rejecting connections
From: Klemen Kecman @ 2004-01-28 9:48 UTC (permalink / raw)
To: netfilter; +Cc: Ben
In-Reply-To: <E1Allqr-0002Mv-LJ@aphex.cyberpixels.com>
Place log target above all rules or create LOG chain.
Why use double drop?
If the default policy is set to DROP, there is no need for aditional drop
rules.
Allso fix the lo line .. it can be writen much simpler like
$IPT -A INPUT -p ALL -i $IF_LO -j ACCEPT
$IPT -A OUTPUT -p ALL -o $IF_LO -j ACCEPT
----- Original Message -----
From: "Ben" <nigma@nigma.info>
To: <netfilter@lists.netfilter.org>
Sent: Wednesday, January 28, 2004 10:19 AM
Subject: Trouble rejecting connections
> Hello all,
>
> I'm having trouble rejecting connections using iptables. I am using
cPanel
> / WHM on a RedHat 7.3 a machine and iptables installed from
> iptables-1.2.8-8.72.3.i386.rpm . I am using a script for my policy, it
> looks like this.
>
>
> //Start script
> IPTABLES="/sbin/iptables"
>
> #Flush everything, start from scratch
> $IPTABLES -F
>
> #Set default policies to DROP
> $IPTABLES -P INPUT DROP
> $IPTABLES -P FORWARD DROP
>
> #Allow all lo traffic
> $IPTABLES -A INPUT -i lo -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT
>
> #Allow all related and established connections
> $IPTABLES -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
>
> #Set default OUTPUT policy to ACCEPT
> $IPTABLES -P OUTPUT ACCEPT
>
> # Open ports for server/services
> $IPTABLES -A INPUT -p tcp --dport 20 -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 21 -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 22 -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 25 -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 37 -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 43 -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 53 -j ACCEPT
> $IPTABLES -A INPUT -p udp --dport 53 -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 80 -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 110 -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 113 -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 143 -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 443 -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 465 -j ACCEPT
> $IPTABLES -A INPUT -p udp --dport 465 -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 873 -j ACCEPT
> $IPTABLES -A INPUT -p udp --dport 873 -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 993 -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 995 -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 2082 -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 2083 -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 2086 -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 2087 -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 2089 -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 2095 -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 3306 -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 6666 -j ACCEPT
>
> #Enable Blogger support (non-standards compliant piece of dogshit that it
> is)
> $IPTABLES -A INPUT -s 66.102.15.83 -j ACCEPT
> $IPTABLES -A INPUT -s 216.34.7.186 -j ACCEPT
>
> #Add passive-mode people here
> #$IPTABLES -A INPUT -s xxx.xxx.xxx.xxx -j ACCEPT
>
> #Add DENY people here
> #$IPTABLES -A INPUT -s 000.000.000.000 -j DROP
> $IPTABLES -A INPUT -s blocked.ip.address.here -j DROP
>
> #Logging
> $IPTABLES -A INPUT -j LOG --log-prefix "INPUTDEFAULT: "
>
> #Save rules
> iptables-save > /etc/sysconfig/iptables
>
> #Restart for rules to take effect
> service iptables restart
> //End script
>
> The problem is that I can still connect from blocked.ip.address.here.
What
> did I miss?
>
> Ben Prince
> Cyber Pixels
> Systems Administrator
> ben@cyberpixels.com
>
>
^ permalink raw reply
* Re: BitKeeper repo for KGDB
From: Dave Jones @ 2004-01-28 9:50 UTC (permalink / raw)
To: Tom Rini
Cc: Chris Wright, akpm, george, amitkale, Andi Kleen, jim.houston,
Kernel Mailing List
In-Reply-To: <20040127210246.GK32525@stop.crashing.org>
On Tue, Jan 27, 2004 at 02:02:47PM -0700, Tom Rini wrote:
> > seems I missed where the repo is.
> Der, whoops.
>
> bk://ppc.bkbits.net/linux-2.6-kgdb
daily diffs vs mainline generated at..
http://www.codemonkey.org.uk/projects/bitkeeper/kgdb
Dave
^ permalink raw reply
* [LARTC] Problems with multipath routing.
From: Raúl Alexis Betancort Santana @ 2004-01-28 10:01 UTC (permalink / raw)
To: lartc
Hi all, I have setup two multipath route tables on my system for doing
failover routing, What I want it's that if GW at route1 of the MP is dead,
traffic goes by route2, for doing that I have created the multipath routes as
follows:
ip route add table mail.traffic proto static nexthop via ${GW1} dev eth1
weight 1 nexthop via ${GW2} dev eth1 weight 250
But it does not run as I espected, I want that most (all if posible) the
traffic goes by GW1, and if it is down (DgD patches are applied) traffic must
goes by GW2, the kernel it's not taking into account the weight parameter or
maybe I'm doing it wrong.
Any hit will be apreciated ...
Best regards
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* [U-Boot-Users] NFS Server problem
From: Cam @ 2004-01-28 10:02 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20040127222133.4C5D3C108D@atlas.denx.de>
sudhakar,
>>=======================================
>>nfs: server not responding, still trying
>>=======================================
>>
>>Sometimes, the board continues after printing,
>>=======================================
>>nfs: server OK
>>=======================================
>>but sometimes the board just hangs. Earlier I have
What kernel are you using to support the 8280, and what patches have you
applied if any (to u-boot and to the kernel)?
I am working with an mpc8270.
Contact me off list if you like - this is slightly off topic for the
u-boot list.
-Cam
--
camilo at mesias.co.uk <--
^ permalink raw reply
* Re: mantis - our bugtracking system
From: Andreas Kuckartz @ 2004-01-28 10:08 UTC (permalink / raw)
To: Jaroslav Kysela; +Cc: ALSA development
In-Reply-To: <Pine.LNX.4.58.0401271443180.3133@pnote.perex-int.cz>
Immediately after receiving your mail I have registered two times for mantis
accounts using two different account names (andreas and andreas2). I have
not yet received the mails with the passwords.
It would be good if everybody could look at the bugs without first
registering or logging in.
Cheers,
Andreas
----- Original Message -----
From: "Jaroslav Kysela" <perex@suse.cz>
To: "ALSA development" <alsa-devel@alsa-project.org>
Sent: Tuesday, January 27, 2004 2:51 PM
Subject: [Alsa-devel] mantis - our bugtracking system
> Hello,
>
> I have configured Mantis - our bugtracking system. You'll find
> the link on the ALSA main page (Bug reporting or tracker).
> Developers - please, register and send me a private mail with
> your maintaned drivers, so I can assign you as developer and as the
> default maintainer for given driver.
> Note that all bugs will go though this mailing list, so anybody
> can comment / take care.
> Everything else will be in the bug-tracker "news".
>
> Have fun,
> Jaroslav
>
> P.S. And report bugs, of course :-)
>
> -----
> Jaroslav Kysela <perex@suse.cz>
> Linux Kernel Sound Maintainer
> ALSA Project, SuSE Labs
>
>
> -------------------------------------------------------
> 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
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-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
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.