* Re: 2.6.2-rc1-mm1 pppd: page allocation failure (fwd)
From: haiquy @ 2004-01-27 14:56 UTC (permalink / raw)
To: linux-kernel
Hi,
Sorry for the delay but I have still unable to reproduce the bug when
when compiling use standard CFLAGS in the kernel Makefile.
Best regard,
Steve Kieu
---------- Forwarded message ----------
Date: Sat, 24 Jan 2004 12:38:41 +0000 (UTC)
From: haiquy@yahoo.com
Reply-To: s_kieu@hotmail.com
To: linux-kernel@vger.kernel.org
Subject: 2.6.2-rc1-mm1 pppd: page allocation failure
Hi,
This did not happen with 2.6.1-mm4 . The system is still running fine
at the moment but I find several message in the dmesg output
pppd: page allocation failure. order:4, mode:0xd0
Call Trace: [<c01388f0>] [<c013895f>] [<c013b48c>] [<c013b79e>] [<c013bae4>] [<c01fc177>] [<c01f87b4>] [<c01f6bd1>] [<c014e742>] [<c015f299>] [<c02b2f67>]
pppd: page allocation failure. order:4, mode:0xd0
Call Trace: [<c01388f0>] [<c013895f>] [<c013b48c>] [<c013b79e>] [<c013bae4>] [<c01fc177>] [<c01f87b4>] [<c01f6bd1>] [<c014e742>] [<c015f299>] [<c02b2f67>]
pppd: page allocation failure. order:4, mode:0xd0
Call Trace: [<c01388f0>] [<c013895f>] [<c013b48c>] [<c013b79e>] [<c013bae4>] [<c01fc177>] [<c01f87b4>] [<c01f6bd1>] [<c014e742>] [<c015f299>] [<c02b2f67>]
If some one need further testing or information pls cc me.
Steve Kieu
^ permalink raw reply
* Re: PPTP - more connections from a NATed LAN to LAN behind PPTP Linux box doesn't work
From: Harald Welte @ 2004-01-27 1:54 UTC (permalink / raw)
To: Unzeitig Lumir; +Cc: netfilter
In-Reply-To: <0807917940AEF54F9A0C3096A0ED03AB40EDD0@gatc-ex1.gatc.com>
[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]
On Wed, Jan 21, 2004 at 03:47:25PM +0100, Unzeitig Lumir wrote:
> Hi,
> I applied the PPTP patch and it solved what I needed. (=more connections
> from NATed LAN behind Linux box to a PPTP server) - it's OK.
> But oposit direction (=more connections from NATed LAN behind a PPTP
> server to theLAN which is behind PPTP Linux box) works only for 1 PPTP
> client. It stays in verification process and ends by error.
Sorry, I have no idea what you are talking about. Please describe more
detailed what exactly you want to do. Please try to use more precise
terms (no idea what 'theLAN' and your 'pptp linux box' should mean).
> Thanks
> Lumir Unzeitig
--
- 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: Is source in CVS broken, or is it just me?
From: Justin Turner Arthur @ 2004-01-27 1:56 UTC (permalink / raw)
To: ALSA Development
In-Reply-To: <Pine.LNX.4.58.0401262010410.2959@pnote.perex-int.cz>
Jaroslav Kysela wrote:
>Use latest 2.6.2-rc kernels.
>
>
>
Thanks for the tip, Mr. Kysela. Upon patching to the 2.6.2rcX kernel,
and re-application of the ALSA cvs checkout, I'm up and running with a
working ice1712 driver and no compile errors. Hot-diggity!
Thanks again,
Justin Arthur
-------------------------------------------------------
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: two eth devices ...
From: Ray Olszewski @ 2004-01-27 1:53 UTC (permalink / raw)
To: rgomez, linux-newbie
In-Reply-To: <4011C87400000C1A@mail-bcm02.alestra.net.mx>
At 06:46 PM 1/26/2004 -0600, rgomez@bancomer.com wrote:
>I have 2 interfaces, but i don't know what to do with
First, let's keep this discussion on the list, not private. So I've added
the list back in with this reply.
Second, as I look at the interface data, the packet counts make it clear
that both are being used ... about equally for incoming traffic, but
heavily favoring eth0 for outgoing packets. A look at your routing table
("netstat -nr" is one way to view it) will probably explain the TX imbalance.
Without knowing more about your setup ... for example, why the two
interfaces are on different Ip networks (do they connect to the same or to
different physical networks?), what services the host is running, what mix
of LAN and Internet services the host accesses and how (what the routing
table looks like is most of the "how" part) ... it is hard to recommend
anything.
Really, from the standpoint of Linux, the system seems to be working. If
you want to disable an interface temporarily, you *probably* want to use
the command
ifdown eth0
or
ifdown eth1
But the question of *whether* you should be running one or two interfaces
really is better posed to the sysadmin at your site ... it is not
particularly a Linux question. If his or her answer poses any issues that
seem specific to Linux, then that would be a good time to come back here.
For example, I think I saw another message from you, earlier today, asking
about controlling how the host accesses squid. It was too vague for me to
reply to, but now that I see you have interfaces on different networks, the
system's routing table should control which interface handles squid traffic
(assuming the squid server is local, on one or the other network).
># if config -a
>eth0 Link encap:Ethernet HWaddr 00:C0:4F:97:2D:8D
> inet addr:150.100.106.24 Bcast:150.100.106.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:301002 errors:3 dropped:0 overruns:0 frame:3
> TX packets:13656 errors:0 dropped:0 overruns:0 carrier:14
> collisions:791 txqueuelen:100
> RX bytes:97659433 (93.1 Mb) TX bytes:1976281 (1.8 Mb)
> Interrupt:11 Base address:0xec80
>
>eth1 Link encap:Ethernet HWaddr 00:A0:24:0B:56:3C
> inet
> addr:150.100.107.199 Bcast:150.100.107.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:290096 errors:3 dropped:0 overruns:0 frame:3
> TX packets:1163 errors:0 dropped:0 overruns:0 carrier:0
> collisions:62 txqueuelen:100
> RX bytes:94395209 (90.0 Mb) TX bytes:112613 (109.9 Kb)
> Interrupt:10 Base address:0x230
>
>lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> RX packets:297 errors:0 dropped:0 overruns:0 frame:0
> TX packets:297 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:32918 (32.1 Kb) TX bytes:32918 (32.1 Kb)
>
># ip link show
>1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
> link/ether 00:c0:4f:97:2d:8d brd ff:ff:ff:ff:ff:ff
>3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
> link/ether 00:a0:24:0b:56:3c brd ff:ff:ff:ff:ff:ff
>
># uname -a
>Linux naboo 2.4.20-8 #1 Thu Mar 13 16:42:56 EST 2003 i586 i586 i386 GNU/Linux
>
>::::::::::::::
>/etc/sysconfig/networking/profiles/default/ifcfg-eth0
>::::::::::::::
>DEVICE=eth0
>ONBOOT=yes
>BOOTPROTO=dhcp
>TYPE=Ethernet
>USERCTL=no
>PEERDNS=no
>::::::::::::::
>/etc/sysconfig/networking/profiles/default/ifcfg-eth1
>::::::::::::::
>DEVICE=eth1
>ONBOOT=yes
>BOOTPROTO=dhcp
>TYPE=Ethernet
>USERCTL=no
>PEERDNS=no
[old stuff deleted]
-
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: [PATCH] cpqarray update
From: Jeff Garzik @ 2004-01-27 1:51 UTC (permalink / raw)
To: Wiran, Francis; +Cc: Linux Kernel Mailing List
In-Reply-To: <CBD6B29E2DA6954FABAC137771769D6504E15965@cceexc19.americas.cpqcorp.net>
Wiran, Francis wrote:
>>You need to check the return value of pci_module_init() for errors.
>
> No, because the return value is determined from number of ctrls found,
> and not from function return.
>
> int __init cpqarray_init(void)
> {
> ...
> pci_module_init(&cpqarray_pci_driver);
> cpqarray_eisa_detect();
>
> for(i=0;i<MAX_CTLR;i++) {
> if(hba[i] != NULL)
> num_ctlrs_reg++
> }
>
> return (num_ctlrs_reg);
> }
>
> int __init cpqarray_init_module(void)
> {
> if (cpqarray_init() == 0)
> return -ENODEV;
> return 0;
> }
Nope, this needs to be turned inside out. The proper PCI driver looks like
static int __init cp_init (void)
{
return pci_module_init (&cp_driver);
}
static void __exit cp_exit (void)
{
pci_unregister_driver (&cp_driver);
}
We already handle the cases you describe. The cpqarray code -breaks-
the API design by doing it this way.
cpqarray does not fully support the pci_ids features and hotplug without
this.
Jeff
^ permalink raw reply
* Re: Problem using fwmarks as routing key: "MASQUERADE: Route sent us somewhere else."
From: Harald Welte @ 2004-01-27 1:51 UTC (permalink / raw)
To: Thhoep; +Cc: netfilter, netdev, Netfilter Development Mailinglist
In-Reply-To: <001c01c3e043$93583cd0$1684188d@Kiste>
[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]
On Wed, Jan 21, 2004 at 06:25:22PM +0100, Thhoep wrote:
> hi,
>
> my aim: to divide 100 hosts upon 6 masqueraded adsl connections to the
> internet using a linux router runnig a debian woody.
>
> the problem: really strange behaviour of the routing/masquerading combo,
> that changes with every tried kernel version. (described below)
>
> presumption: some version mismatch or a bug in the kernel routing code,
> which needs a bugfix that till now is unknown to me
Please read the recent archives of the netdev list with regard to
"Rusty's brain broke". Also see
https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=144
Alexey heavily argued against us reverting that change, however :(
--
- 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: iptables NAT with "policy routing?"
From: Harald Welte @ 2004-01-27 1:47 UTC (permalink / raw)
To: Brian Capouch; +Cc: netfilter
In-Reply-To: <400F7264.1080201@palaver.net>
[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]
On Thu, Jan 22, 2004 at 01:49:08AM -0500, Brian Capouch wrote:
> I have had to temporarily use a table-based route for one of my networks
> for administrative reasons, e.g.
this should work just fine.
> I suspect though, that this mode of routing (as opposed to using the
> "regular" table via "route add default") is somehow hosing my iptables NAT?
>
> At least sniffing the egress interface now shows the traffic heading out
> with its NATted address of 192.168.1.10.
did you try that with a connection that was established before you
inserted the new NAT rule (also, if you test with a ping, you need to
stop it to be recognized as new connection).
LARTC mailinglist might give you some better feedback.
> Thx.
> B.
--
- 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: [uPATCH] refuse plain ufs mount
From: GOTO Masanori @ 2004-01-27 1:43 UTC (permalink / raw)
To: Andries.Brouwer; +Cc: akpm, torvalds, linux-kernel
In-Reply-To: <UTC200401250017.i0P0Hlc09374.aeb@smtp.cwi.nl>
At Sun, 25 Jan 2004 01:17:47 +0100 (MET),
Andries.Brouwer@cwi.nl wrote:
> Installed some machine with a reiserfs rootfs.
> The boot messages contain a lot of garbage spouted by Intermezzo
> and ufs_read_super caused by the fact that the kernel tried lots
> of other filesystems before hitting on reiserfs.
>
> On the one hand this is solved by "rootfstype=reiserfs".
>
> But on the other hand, the kernel should not complain about the
> guessing it does itself. There is a parameter "silent" for this
> purpose, but in this case I think it cleaner just to remove the
> complaint and tighten the requirement.
I wonder this modification is really ok because user can't find why he
can't mount his ufs if he does not specify ufstype=. Putting only
one line is not acceptable for you?
Regards,
-- gotom
--- fs/ufs/super.c 2003-10-20 12:50:24.000000000 +0900
+++ fs/ufs/super.c.new 2004-01-27 10:18:22.000000000 +0900
@@ -517,11 +517,8 @@
goto failed;
}
if (!(sbi->s_mount_opt & UFS_MOUNT_UFSTYPE)) {
- 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"
- ">>>WARNING<<< Wrong ufstype may corrupt your filesystem, "
- "default is ufstype=old\n");
+ printk("to mount ufs, specify -o ufstype="
+ "sun|sunx86|44bsd|old(default)|hp|nextstep|netxstep-cd|openstep\n");
ufs_set_opt (sbi->s_mount_opt, UFSTYPE_OLD);
}
^ permalink raw reply
* Re: Encrypted Filesystem
From: Andy Isaacson @ 2004-01-27 1:42 UTC (permalink / raw)
To: Adam Sampson; +Cc: linux-kernel
In-Reply-To: <y2ar7xmkyqe.fsf@cartman.at.fivegeeks.net>
On Tue, Jan 27, 2004 at 12:43:21AM +0000, Adam Sampson wrote:
> Michael A Halcrow <mahalcro@us.ibm.com> writes:
> > - Userland filesystem-based (EncFS+FUSE, CryptoFS+LUFS)
>
> Going off on a tangent...
>
> There are all sorts of potentially-interesting things that could be
> done if Linux had a userspace filesystem mechanism included in the
> standard kernel -- as well as encryption, there's also network
> filesystems, various sorts of specialised caching (such as Zero
> Install), automounter-like systems, prototyping and so on.
>
> Is there a technical reason that none of the userspace filesystem
> layers have been included in the stock kernel, or is it just that
> nobody's submitted any of them for inclusion yet?
There are a lot of subtle and not-so-subtle problems in this space.
For example, I really liked the paging example given in section 3.1 of
[Mazi2001].
[Mazi2001] "A toolkit for user-level file systems", David Mazieres,
Proceedings of the 2001 USENIX Technical Conference
available at http://www.fs.net/sfswww/pubs.html
-andy
^ permalink raw reply
* Re: ip_nat_ftp module and freeswan IPSEC module don't work together?
From: Harald Welte @ 2004-01-27 1:41 UTC (permalink / raw)
To: Rodre Ghorashi-Zadeh; +Cc: netfilter
In-Reply-To: <BAY10-F42llTdrrcwv1000519cf@hotmail.com>
[-- Attachment #1: Type: text/plain, Size: 947 bytes --]
On Fri, Jan 23, 2004 at 02:41:46AM +0000, Rodre Ghorashi-Zadeh wrote:
> Hello,
> Any help regarding this matter would be greatly appreciated. Thanks in
> advance.
I have no idea how this could be caused. But it seems to me at the
first glance, that this is not a netfilter/iptables issue. It works
with a stock kernel... Maybe you should talk to the freeswan guys and
ask if somebody is able to come up with an explanation.
Also, please submit bug reports via bugzilla.netfilter.org instead of
posting to the mainlintlist, please.
thanks.
> ?odre
--
- 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
* Undelivered Mail Returned to Sender
From: Mail Delivery System @ 2004-01-27 1:40 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 563 bytes --]
This is the Postfix program at host miracle.advantest.co.jp.
I'm sorry to have to inform you that the message returned
below could not be delivered to one or more destinations.
For further assistance, please send mail to <postmaster>
If you do so, please include this problem report. You can
delete your own text from the message returned below.
The Postfix program
<sam-/dgdK3Mrev6N8HZe81QOs0v2NXO6HgA6@public.gmane.org>: host setech.mei7.advantest.co.jp[10.57.11.86]
said: 550 <sam-/dgdK3Mrev6N8HZe81QOs0v2NXO6HgA6@public.gmane.org>... User unknown
[-- Attachment #2: Delivery error report --]
[-- Type: message/delivery-status, Size: 365 bytes --]
[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 1725 bytes --]
[-- Attachment #3.1.1: Type: text/plain, Size: 83 bytes --]
The message contains Unicode characters and has been sent as a binary attachment.
[-- Attachment #3.1.2: Type: text/plain, Size: 193 bytes --]
------------------ Virus Warning Message (on miracle.advantest.co.jp)
message.pif is removed from here because it contains a virus.
---------------------------------------------------------
^ permalink raw reply
* Re: NVidia and 2.6.1
From: Christian Unger @ 2004-01-27 1:39 UTC (permalink / raw)
To: Max Valdez; +Cc: Linux Kernel List
In-Reply-To: <1075158281.4775.13.camel@garaged.homeip.net>
On Tuesday 27 January 2004 10:04, you wrote:
> Did you changed anything on your bios ??
>
No actually.
Dropped in the Slackware 9.1 CDs (official ones, last ones were of the net),
typed reboot,
typed setup,
formated the disk (mountpoints, swap etc)
told it to install everything,
hit ctrl+alt+delete,
extracted the kernel sources,
told it to use my previous (backed up) config file,
compiled and installed everything,
typed reboot,
made the nvidia drivers of the pre-patched stuff.
In there was some minor arguments with XFree86's config regarding my mouse.
but the drivers worked straight up this time.
--
with kind regards,
Christian Unger
- < > - < > - < > - < > - < > - < > - < > - < > -
Alt. Email: chakkerz_dev@optusnet.com.au
ICQ: 204184156
Mobile: 0402 268904
Web: http://naiv.sourceforge.net
^ permalink raw reply
* RE: [PATCH] cpqarray update
From: Wiran, Francis @ 2004-01-26 22:32 UTC (permalink / raw)
To: Jeff Garzik, Linux Kernel Mailing List
> You need to check the return value of pci_module_init() for errors.
No, because the return value is determined from number of ctrls found,
and not from function return.
int __init cpqarray_init(void)
{
...
pci_module_init(&cpqarray_pci_driver);
cpqarray_eisa_detect();
for(i=0;i<MAX_CTLR;i++) {
if(hba[i] != NULL)
num_ctlrs_reg++
}
return (num_ctlrs_reg);
}
int __init cpqarray_init_module(void)
{
if (cpqarray_init() == 0)
return -ENODEV;
return 0;
}
regards,
-francis-
> -----Original Message-----
> From: Jeff Garzik [mailto:jgarzik@pobox.com]
> Sent: Monday, January 26, 2004 2:15 PM
> To: Linux Kernel Mailing List; Wiran, Francis
> Subject: Re: [PATCH] cpqarray update
>
>
> Linux Kernel Mailing List wrote:
> > ChangeSet 1.1288, 2004/01/26 16:58:21-02:00, francis.wiran@hp.com
> >
> > [PATCH] cpqarray update
> >
> > Yes, we should. I usually ask Mike Miller in our group
> to send my
> > patches since he's been doing that and more known in
> the community, but
> > since you already got a hold of it ...yes, please :)
> >
> > CHANGELOG:
> >
> > * Fix for eisa card not detecting partitions properly
> > * Use pci_module_init instead of pci_register_device
> to handle hotplug
> > scenario and unregister if the driver can't find
> pci controller
> > * Add BLKSSZGET ioctl
> [...]
> > @@ -616,7 +623,7 @@
> >
> > /* detect controllers */
> > printk(DRIVER_NAME "\n");
> > - pci_register_driver(&cpqarray_pci_driver);
> > + pci_module_init(&cpqarray_pci_driver);
> > cpqarray_eisa_detect();
> >
> > for(i=0; i< MAX_CTLR; i++) {
>
> You need to check the return value of pci_module_init() for errors.
>
> Jeff
>
>
>
>
^ permalink raw reply
* Re: Translators of howto in french
From: Harald Welte @ 2004-01-27 1:37 UTC (permalink / raw)
To: Guillaume Audirac; +Cc: netfilter
In-Reply-To: <1074931376.1817.9.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]
On Sat, Jan 24, 2004 at 09:02:57AM +0100, Guillaume Audirac wrote:
> Hello,
>
> Some howtos in french (at www.netfilter.org) need revision and/or
> update. Previous translators don't seem to do this work.
> Thanks to tell me if you know some translations are already underway. If
> not, I could take some time to do so.
> For information, a french site (www.traduc.org) is well organized to
> follow general linux translations.
The old translations were done by Fabrice Marie, IIRC. Please contact
him and discuss how to proceed.
We'd certainly love ot have up-to-date translations.
> Bye.
> Guillaume
> guillaume(dot)audirac(at)netpratique(dot)fr
--
- 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
* bk pull on ia64 linux tree
From: David Mosberger @ 2004-01-27 1:37 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <Pine.LNX.4.58.0401121658240.14305@evo.osdl.org>
Hi Linus,
please do a
bk pull http://lia64.bkbits.net/to-linus-2.5
This will update the files shown below (only ia64-specific files are
touched).
Thanks!
--david
include/asm-ia64/machvec_sn1.h | 85 -----------------
arch/ia64/Kconfig | 149 +++++++++++++-----------------
arch/ia64/hp/common/sba_iommu.c | 17 +++
arch/ia64/kernel/entry.S | 53 ++++++++--
arch/ia64/kernel/ia64_ksyms.c | 8 +
arch/ia64/kernel/irq_lsapic.c | 5 -
arch/ia64/kernel/smpboot.c | 8 -
arch/ia64/kernel/time.c | 3
arch/ia64/sn/io/sn2/xbow.c | 2
arch/ia64/sn/kernel/sn2/Makefile | 2
arch/ia64/sn/kernel/sn2/sn2_smp.c | 5 -
arch/ia64/sn/kernel/sn2/timer_interrupt.c | 64 ++++++++++++
include/asm-ia64/a.out.h | 4
include/asm-ia64/bugs.h | 6 -
include/asm-ia64/byteorder.h | 4
include/asm-ia64/checksum.h | 4
include/asm-ia64/current.h | 4
include/asm-ia64/errno.h | 12 --
include/asm-ia64/fcntl.h | 6 -
include/asm-ia64/ioctl.h | 6 -
include/asm-ia64/ioctls.h | 6 -
include/asm-ia64/machvec.h | 7 +
include/asm-ia64/machvec_sn2.h | 2
include/asm-ia64/mman.h | 6 -
include/asm-ia64/namei.h | 4
include/asm-ia64/numa.h | 4
include/asm-ia64/param.h | 6 -
include/asm-ia64/poll.h | 6 -
include/asm-ia64/posix_types.h | 8 +
include/asm-ia64/processor.h | 6 -
include/asm-ia64/resource.h | 6 -
include/asm-ia64/scatterlist.h | 4
include/asm-ia64/siginfo.h | 6 -
include/asm-ia64/signal.h | 4
include/asm-ia64/socket.h | 8 +
include/asm-ia64/sockios.h | 9 +
include/asm-ia64/stat.h | 4
include/asm-ia64/statfs.h | 6 -
include/asm-ia64/termbits.h | 6 -
include/asm-ia64/termios.h | 4
include/asm-ia64/tlb.h | 4
include/asm-ia64/types.h | 6 -
include/asm-ia64/uaccess.h | 2
include/asm-ia64/unaligned.h | 5 -
include/asm-ia64/user.h | 4
45 files changed, 310 insertions(+), 270 deletions(-)
through these ChangeSets:
<eranian@hpl.hp.com> (04/01/26 1.1525)
[PATCH] ia64: fix icc compilation
<iod00d@hp.com> (04/01/26 1.1524)
[PATCH] ia64: enable PIOW/DMAR relaxed ordering on ZX1
<schwab@suse.de> (04/01/26 1.1523)
[PATCH] ia64: Fix xbow.c compilation
This fixes a conflicting declaration in xbow.c.
<matthewc@cse.unsw.edu.au> (04/01/26 1.1522)
ia64: Fix ptrace infrastructure some more so that strace'd sigreturn()
works without trashing any registers.
<mort@wildopensource.com> (04/01/23 1.1498.1.3)
ia64: remove old sn1 machvec header file
<davidm@tiger.hpl.hp.com> (04/01/23 1.1498.1.2)
ia64: Fix merge error: remove duplicate NR_CPUS.
<davidm@tiger.hpl.hp.com> (04/01/23 1.1474.119.11)
ia64: Patch by Jesse Barnes: remove unnecessary set_affinity handler.
<bjorn.helgaas@hp.com> (04/01/23 1.1474.119.10)
[PATCH] ia64: remove MCA (MicroChannel) cruft
MCA_bus is now referenced only when CONFIG_MCA is set,
so we should be able to remove the definition from ia64.
<mort@wildopensource.com> (04/01/23 1.1474.119.9)
[PATCH] ia64: add platform_timer_interrupt() hook
<davidm@tiger.hpl.hp.com> (04/01/23 1.1474.119.8)
ia64: Fix typo in comment in asm-ia64/posix_types.h.
<davidm@tiger.hpl.hp.com> (04/01/23 1.1474.119.7)
ia64: Drop copyright notices on header files which are either entirely trivial
or ended up being trivial variations of another file. Fix some
missing attributions and rephrase existing attributions for specifity.
<suresh.b.siddha@intel.com> (04/01/22 1.1474.119.6)
[PATCH] ia64: replace inline assembly in sn2 code
<akpm@osdl.org> (04/01/21 1.1474.119.5)
[PATCH] ia64: i2c config fix
ia64 needs to include i2c by hand
<bjorn_helgaas@hp.com> (04/01/21 1.1474.119.4)
[PATCH] ia64: Kconfig cleanup, part 1
<davidm@tiger.hpl.hp.com> (04/01/19 1.1474.119.3)
ia64: arch/ia64/Kconfig URL update: www.linux-on-laptops.com
<jbarnes@sgi.com> (04/01/16 1.1474.119.2)
[PATCH] ia64: kill some more warnings
Kills a warning and a false sense of safety by removing the volatile
qualifier on cpu_to_node_map[] and node_to_cpu_mask[]. Also fix the
printk for total processors since num_online_cpus() can return an int or
a long depending on the value of NR_CPUS.
<jbarnes@sgi.com> (04/01/16 1.1474.119.1)
[PATCH] ia64: fix cast in irq_lsapic.c
This patch just updates the cast in irq_lsapic.c to use the cpumask_t
type for the noop cast assignment to smp_affinity.
^ permalink raw reply
* Re: TFTP crashes the linux system...
From: Harald Welte @ 2004-01-27 1:35 UTC (permalink / raw)
To: Gautham Thavva; +Cc: netfilter
In-Reply-To: <BBKGNGAPNMGCAKAA@mailcity.com>
[-- Attachment #1: Type: text/plain, Size: 963 bytes --]
On Mon, Jan 26, 2004 at 06:20:20PM -0500, Gautham Thavva wrote:
>
> I have enforced a firewall, using iptables-1.2.6a, on a target board running TimeSys Linux Kernel(Kernel version is 2.4.7-10).
>
> I have applied the *tftp* patch available in the patch-o-matic.
i strongly doubt that you will get this wokring with such an incredibly
old kernel... You'd basically need to backport more than two years of
netfilter/iptables development on top of 2.4.7...
The patch-o-matic README doesn indicate that it only supports 2.4.18 and
later.
> With regards,
> Gautham Thavva
--
- 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: Writing CIS... ioctl?
From: Andries.Brouwer @ 2004-01-27 1:35 UTC (permalink / raw)
To: patearl, usb-storage; +Cc: linux-kernel
Hi. As a fun little project I'm considering adding userland support
for reading and writing the CIS block via the SDDR-09. Based on my
previous driver experience, I'd do it using an ioctl on the scsi
device it maps to. However, I'm unsure of how the SCSI/USB layering
occurs and if an ioctl would be the best way to allow access to the
CIS. Note that the CIS info itself is roughly 100 bytes, and that
information is duplicated in another location on the smartmedia card.
Any thoughts? Is an ioctl the way to do it?
Are there other ways that low level control data is written to storage
devices?
For any single project ioctl() is one of the easy ways of doing it.
There are other communication channels, like module parameters
or proc files.
But there are lots of such projects, and after doing a few hundred of them
we have interface mess. For the dev_t change last year I did an audit of
all ioctls, more than a thousand, with lots of different interfaces,
sometimes varying between architectures, not exactly a pleasure.
So, something else is needed, and we do not have it. Lots of ideas have been
suggested. Whatever one does the situation is messy, just because the type
of control needed varies a lot.
If for every device there also is a control device, then the control device
can be opened and ordinary read and write calls can be used. That is good.
But still there will be parsing on both sides, so the mess has only been
hidden a little, it is still there.
Sysfs tries to avoid the parsing problem by having a large number of files,
each with a simple ASCII value. Now one has to walk and parse messy trees.
People who like that will want a control filesystem instead of a control device
for each device.
But you do not want a long discussion, but a utility.
Give the driver a reading and a writing mode.
(Read normal 512-byte blocks, or 512+64-bytes blocks plus control,
or just the 64-byte control, possibly with a choice between 16-byte and
64-byte control, and similarly for write, where write also has the
writeCIS possibility.)
The getting and setting of reading and writing mode is separate from the
rest. While testing, it is probably easiest to use a module parameter.
If everything works, and you want to submit the result for inclusion in the
kernel, see whether Linus has requirements on the shape things should be in.
In case you learn things about the sddr09 hardware not yet documented,
I would like to hear about them.
Andries
[Non-sddr09 examples of control things one wants to do: setmax on a disk;
set a password on a disk; set a disk read-only or read-write (on the
media level or on the drive level or on the software level); eject;
reread partition table; set a ZIP drive to disk vs large floppy mode;
load a keymap; set unicode mode; load a compose table; assign keycodes
to scancode sequences; set keyboard repeat rate; set magic SysRq key.]
^ permalink raw reply
* [parisc-linux] parisc-linux Digest, Vol 2, Issue 33
From: parisc-linux-request @ 2004-01-26 19:00 UTC (permalink / raw)
To: parisc-linux
[-- Attachment #1: Type: text/plain, Size: 5957 bytes --]
Send parisc-linux mailing list submissions to
parisc-linux@lists.parisc-linux.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
or, via email, send a message with subject or body 'help' to
parisc-linux-request@lists.parisc-linux.org
You can reach the person managing the list at
parisc-linux-owner@lists.parisc-linux.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of parisc-linux digest..."
Today's Topics:
1. Re: A fix for B2k and CONFIG_PDC_CONSOLE pb (Matthew Wilcox)
2. Re: A fix for B2k and CONFIG_PDC_CONSOLE pb (Joel Soete)
3. Re: A fix for B2k and CONFIG_PDC_CONSOLE pb (Joel Soete)
----------------------------------------------------------------------
Message: 1
Date: Mon, 26 Jan 2004 17:25:05 +0000
From: Matthew Wilcox <willy@debian.org>
Subject: Re: [parisc-linux] A fix for B2k and CONFIG_PDC_CONSOLE pb
To: Joel Soete <soete.joel@tiscali.be>
Cc: Christoph Plattner <christoph.plattner@gmx.at>, Grant Grundler
<grundler@parisc-linux.org>,
parisc-linux@lists.parisc-linux.org
Message-ID: <20040126172505.GQ11844@parcelfarce.linux.theplanet.co.uk>
Content-Type: text/plain; charset=us-ascii
On Mon, Jan 26, 2004 at 06:00:53PM +0100, Joel Soete wrote:
>
> /* Bail if no console input device. */
> - if (!PAGE0->mem_kbd.iodc_io)
> + if ((PAGE0->mem_cons.cl_class != CL_DUPLEX) &&
!PAGE0->mem_kbd.iodc_io)
> return 0;
>
> /* wait for a keyboard (rs232)-input */
> spin_lock_irqsave(&pdc_lock, flags);
> - real32_call(PAGE0->mem_kbd.iodc_io,
> - (unsigned long)PAGE0->mem_kbd.hpa, ENTRY_IO_CIN,
> - PAGE0->mem_kbd.spa, __pa(PAGE0->mem_kbd.dp.layers),
> - __pa(iodc_retbuf), 0, __pa(iodc_dbuf), 1, 0);
> + if (PAGE0->mem_cons.cl_class == CL_DUPLEX)
This doesn't make sense. PAGE0->mem_cons.cl_class has to be CL_DUPLEX
otherwise the test above would have failed. Do you perhaps mean that &&
above to be an || ? If so, this would all read better as ...
/* wait for a keyboard (rs232)-input */
spin_lock_irqsave(&pdc_lock, flags);
if (PAGE0->mem_cons.cl_class == CL_DUPLEX) {
real32_call(PAGE0->mem_cons.iodc_io,
(unsigned long)PAGE0->mem_cons.hpa,
ENTRY_IO_CIN,
PAGE0->mem_cons.spa,
__pa(PAGE0->mem_cons.dp.layers),
__pa(iodc_retbuf), 0, __pa(iodc_dbuf), 1,
0);
} else if (PAGE0->mem_kbd.iodc_io) {
real32_call(PAGE0->mem_kbd.iodc_io,
(unsigned long)PAGE0->mem_kbd.hpa,
ENTRY_IO_CIN,
PAGE0->mem_kbd.spa,
__pa(PAGE0->mem_kbd.dp.layers),
__pa(iodc_retbuf), 0, __pa(iodc_dbuf), 1,
0);
} else {
spin_unlock_irqrestore(&pdc_lock, flags);
return 0;
}
Slightly ugly to have two unlocks for the same lock, but that's better
than duplicating the test. I haven't looked at the code, maybe we could
use a goto instead.
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and
refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain
------------------------------
Message: 2
Date: Mon, 26 Jan 2004 19:20:26 +0100
From: "Joel Soete" <soete.joel@tiscali.be>
Subject: Re: [parisc-linux] A fix for B2k and CONFIG_PDC_CONSOLE pb
To: "Matthew Wilcox" <willy@debian.org>
Cc: Christoph Plattner <christoph.plattner@gmx.at>, Grant Grundler
<grundler@parisc-linux.org>,
parisc-linux@lists.parisc-linux.org
Message-ID: <40153110000001C0@ocpmta2.freegates.net>
Content-Type: text/plain; charset="ISO-8859-1"
> + if ((PAGE0->mem_cons.cl_class != CL_DUPLEX) &&
!PAGE0->mem_kbd.iodc_io)
> return 0;
Right Matthew this case is nearly impossible (may be excepted if
disconected
the usb kbd during the boot), it would means that my pdc_console is not
a
serial one (ie graphic([01])) but no usb kdb found, so in that case pdc
would
switch console automaticaly to serial.
I would just still check the case when I have an usb kbd (I would have
to
recover one) but the pdc console is setup to serial port (eg no graphic
screen
available) just for an output screen without input kbd?
Thanks for your attention and remarks,
Joel
------------------------------------------------------------------------
-
Tiscali ADSL: 12 mois à 29,50 EUR/mois! L'Internet rapide, c'est pour
tout
le monde.
http://reg.tiscali.be/default.asp?lg=fr
------------------------------
Message: 3
Date: Mon, 26 Jan 2004 19:38:50 +0100
From: "Joel Soete" <soete.joel@tiscali.be>
Subject: Re: [parisc-linux] A fix for B2k and CONFIG_PDC_CONSOLE pb
To: "Matthew Wilcox" <willy@debian.org>
Cc: Christoph Plattner <christoph.plattner@gmx.at>, Grant Grundler
<grundler@parisc-linux.org>,
parisc-linux@lists.parisc-linux.org
Message-ID: <4015311000000204@ocpmta2.freegates.net>
Content-Type: text/plain; charset="ISO-8859-1"
Sorry for auto reply, but I just find back the right kdb and:
>I would just still check the case when I have an usb kbd (I would have
to
>recover one) but the pdc console is setup to serial port (e
>no graphic screen available) just for an output screen without input
kbd?
That case is also impossible, the console setup as serial_1 (eg) is
always
CL_DUPLEX :(
I will so review my patch.
Thanks for all,
Joel
------------------------------------------------------------------------
-
Tiscali ADSL: 12 mois à 29,50 EUR/mois! L'Internet rapide, c'est pour
tout
le monde.
http://reg.tiscali.be/default.asp?lg=fr
------------------------------
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
End of parisc-linux Digest, Vol 2, Issue 33
*******************************************
[-- Attachment #2: Type: text/html, Size: 12781 bytes --]
^ permalink raw reply
* Re: Total kernel freeze under 2.6.1
From: Christian Unger @ 2004-01-27 1:32 UTC (permalink / raw)
To: Neil Macvicar; +Cc: linux-kernel
In-Reply-To: <200401261258.39232.blackmogu@vfemail.net>
Forewarning ... i ain't "qualified" ... heck i couldn't get my gfx card to
work on 2.6 until yesterday (and i still don't know why that was).
ANYWAY
i got the same symptoms, and the reason it was doing it on my system was that
in the config i was using in several places it referenced the wrong chipset.
via instead of nforce2 type thing.
>From memory it did this all over the place with regards to sound, hdd and
memory.
Check
Device Drivers - ATA/ATAPI/MFM/RLL
Character Devices - AGP Support
- i2c Support
Sound
etc ...
I'm sorry if this is completely useless. But it was what was at fault here.
PS there could be others that i can't remember ... just check for the right
chipset.
--
with kind regards,
Christian Unger
- < > - < > - < > - < > - < > - < > - < > - < > -
Alt. Email: chakkerz_dev@optusnet.com.au
ICQ: 204184156
Mobile: 0402 268904
Web: http://naiv.sourceforge.net
^ permalink raw reply
* [parisc-linux] parisc-linux Digest, Vol 2, Issue 32
From: parisc-linux-request @ 2004-01-26 17:01 UTC (permalink / raw)
To: parisc-linux
[-- Attachment #1: Type: text/plain, Size: 13990 bytes --]
Send parisc-linux mailing list submissions to
parisc-linux@lists.parisc-linux.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
or, via email, send a message with subject or body 'help' to
parisc-linux-request@lists.parisc-linux.org
You can reach the person managing the list at
parisc-linux-owner@lists.parisc-linux.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of parisc-linux digest..."
Today's Topics:
1. Re: menu not available (Matthew Wilcox)
2. Re: Re: [parisc-linux] missing barrier in _raw_spin_lock?
(John David Anglin)
3. Re: kernel BUG at mm/shmem.c:585! (Carlos O'Donell)
4. Re: kernel BUG at mm/shmem.c:585! (John David Anglin)
5. installation failed on C240 (fx4) workstation
(Reinhold Flecke CCF)
6. help installation failed on C240 (fx4) workstation
(Reinhold Flecke CCF)
7. Re: kernel BUG at mm/shmem.c:585! (Grant Grundler)
8. Re: help installation failed on C240 (fx4) workstation
(Grant Grundler)
9. A fix for B2k and CONFIG_PDC_CONSOLE pb (Joel Soete)
----------------------------------------------------------------------
Message: 1
Date: Sun, 25 Jan 2004 22:40:40 +0000
From: Matthew Wilcox <willy@debian.org>
Subject: Re: [parisc-linux] menu not available
To: Grant Grundler <grundler@parisc-linux.org>
Cc: "Peralta, Joseph A" <jperalta@WPI.EDU>,
parisc-linux@lists.parisc-linux.org
Message-ID: <20040125224040.GG11844@parcelfarce.linux.theplanet.co.uk>
Content-Type: text/plain; charset=us-ascii
On Fri, Jan 23, 2004 at 03:11:49PM -0700, Grant Grundler wrote:
> On Fri, Jan 23, 2004 at 04:47:11PM -0500, Peralta, Joseph A wrote:
> > When I try to install certain X-window managers under Debian 3.0 I
get
> > "xxx depends on menu (>> 1.5)... menu is not available" How would I
fix
> > this?
>
> Dunno...menu is available for "sarge" (aka testing) and that
> works for me. Sounds like someone wants to backport to Woody.
menu is not available for woody because it's written in a language which
bears a passing resemblance to C++. someone rewrote it in C++ for
sarge.
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and
refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain
------------------------------
Message: 2
Date: Sun, 25 Jan 2004 19:13:47 -0500 (EST)
From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
Subject: Re: Re: [parisc-linux] missing barrier in _raw_spin_lock?
To: arndb@onlinehome.de
Cc: grundler@parisc-linux.org, arnd@arndb.de,
parisc-linux@parisc-linux.org
Message-ID: <200401260013.i0Q0Dltk013819@hiauly1.hia.nrc.ca>
Content-Type: text/plain; charset=US-ASCII
> > #define __ldcw(a) ({ \
> > unsigned int __ret;
\
> > __asm__ __volatile__("ldcw 0(%2),%0"
\
> > : "=r" (__ret), "=m" (*(a)) : "r" (a));
\
> > __ret;
\
> > })
> I suppose the memory operand specification is required here. Newer
> compilers (especially gcc-3.4) can optimize away local variables if
you
> only access the address but not the contents. I think even your
> pthreads version is not really correct, because it specifies (*(a)) as
> output only instead of inout.
I agree.
> No, putting the barrier into __ldcw is wrong because it would impact
all
> other uses of __ldcw that don't need the barrier. AFAICS, the
The only other uses for __ldcw are the SPIN_LOCK macro in atomic.h
and the _raw_spin_trylock in spinlock.h (i.e., it is only used
acquire locks). If all these need barriers, then it might as well
be in __ldcw.
Dave
--
J. David Anglin
dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX:
952-6602)
------------------------------
Message: 3
Date: Sun, 25 Jan 2004 21:15:09 -0500
From: Carlos O'Donell <carlos@baldric.uwo.ca>
Subject: Re: [parisc-linux] kernel BUG at mm/shmem.c:585!
To: John David Anglin <dave@hiauly1.hia.nrc.ca>
Cc: grundler@parisc-linux.org, parisc-linux@lists.parisc-linux.org
Message-ID: <20040126021508.GZ1060@baldric.uwo.ca>
Content-Type: text/plain; charset=us-ascii
On Fri, Jan 23, 2004 at 02:40:27PM -0500, John David Anglin wrote:
> > It appears non-fatal, and I want to blame the compiler :)
>
> I agree but the proof is in the pudding ;-)
I told Grant, that at my current schedule, it would be 2006
before I fixed this problem :)
It looks like a reordering issue, perhaps taking a look at the
respective .o objects produced by the two compilers might reveal the
issue. I think that's the way we did it when the tty layer broke and we
had to have that console.o compiled with 3.0.4 by hand? I think Randolph
and Grant worked on that together. I might have the wrong names, but
we've successfully debugged a problem like this before using similar
methods.
c.
------------------------------
Message: 4
Date: Sun, 25 Jan 2004 21:35:07 -0500 (EST)
From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
Subject: Re: [parisc-linux] kernel BUG at mm/shmem.c:585!
To: carlos@baldric.uwo.ca (Carlos O'Donell)
Cc: grundler@parisc-linux.org, parisc-linux@lists.parisc-linux.org
Message-ID: <200401260235.i0Q2Z783024373@hiauly1.hia.nrc.ca>
Content-Type: text/plain; charset=US-ASCII
> On Fri, Jan 23, 2004 at 02:40:27PM -0500, John David Anglin wrote:
> > > It appears non-fatal, and I want to blame the compiler :)
> >
> > I agree but the proof is in the pudding ;-)
>
> I told Grant, that at my current schedule, it would be 2006
> before I fixed this problem :)
My schedule isn't much better. I'm off to Tokyo at the end of the week
to waive the Canadian flag at the ISO LRG meetin next week. After that,
my brother's company would like me to work on more firmware for a new
project.
Is this on a SMP kernel (i.e., could this be a locking issue)?
Dave
--
J. David Anglin
dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX:
952-6602)
------------------------------
Message: 5
Date: Mon, 26 Jan 2004 11:54:13 +0100
From: "Reinhold Flecke CCF" <reinhold.flecke@ccf-consulting.de>
Subject: [parisc-linux] installation failed on C240 (fx4) workstation
To: <parisc-linux@lists.parisc-linux.org>
Message-ID:
<LBEMKLBEFDGDOGGAOGIKAEJPCCAA.reinhold.flecke@ccf-consulting.de>
Content-Type: text/plain; charset="iso-8859-1"
I downloaded the "debian-30r2-hppa-binary-1.iso" and burned it to CD.
If I start the installation on my C240 (fx4) workstation with the
command:
bo sescsi.2.0
it seems everything ok, until I get the message:
..If this is the last message you see, you may need to switch your
console.
This is a common sympton sarch the FAQ and mailing list at
parisc-linux.org
After this nothing happens anymore.
I searched the FAQ and mailing list but I could not find a solution.
Anyone who can help?
Thanks in advance.
Best Regards
Reinhold Flecke
Reinhold Flecke CCF
Fon: +49 (0)5292 930601 (Office)
+49 (0)700 93000093 (PR)
eMail: <mailto:Reinhold.Flecke@ccf-consulting.de>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 2008 bytes
Desc: not available
Url :
http://lists.parisc-linux.org/pipermail/parisc-linux/attachments/2004012
6/13277935/winmail-0001.bin
------------------------------
Message: 6
Date: Mon, 26 Jan 2004 12:13:22 +0100
From: "Reinhold Flecke CCF" <reinhold.flecke@ccf-consulting.de>
Subject: [parisc-linux] help installation failed on C240 (fx4)
workstation
To: <parisc-linux@lists.parisc-linux.org>
Message-ID:
<LBEMKLBEFDGDOGGAOGIKOEJPCCAA.reinhold.flecke@ccf-consulting.de>
Content-Type: text/plain; charset="iso-8859-1"
I downloaded the "debian-30r2-hppa-binary-1.iso" and burned it to CD.
If I start the installation on my C240 (fx4) workstation with the
command:
bo sescsi.2.0
it seems everything ok, until I get the message:
..If this is the last message you see, you may need to switch your
console.
This is a common sympton sarch the FAQ and mailing list at
parisc-linux.org
After this nothing happens anymore.
I searched the FAQ and mailing list but I could not find a solution.
Anyone who can help?
Thanks in advance.
Best Regards
Reinhold Flecke
Reinhold Flecke CCF
Auf dem Anger 18
33165 Lichtenau-Husen
Fon: +49 (0)5292 930601 (Office)
+49 (0)700 93000093 (PR)
eMail: <mailto:Reinhold.Flecke@ccf-consulting.de>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 2056 bytes
Desc: not available
Url :
http://lists.parisc-linux.org/pipermail/parisc-linux/attachments/2004012
6/902d4aa3/winmail-0001.bin
------------------------------
Message: 7
Date: Mon, 26 Jan 2004 08:53:56 -0700
From: Grant Grundler <grundler@parisc-linux.org>
Subject: Re: [parisc-linux] kernel BUG at mm/shmem.c:585!
To: John David Anglin <dave@hiauly1.hia.nrc.ca>
Cc: Carlos O'Donell <carlos@baldric.uwo.ca>,
parisc-linux@lists.parisc-linux.org
Message-ID: <20040126155356.GA12175@colo.lackof.org>
Content-Type: text/plain; charset=us-ascii
On Sun, Jan 25, 2004 at 09:35:07PM -0500, John David Anglin wrote:
> Is this on a SMP kernel (i.e., could this be a locking issue)?
no. I don't build or run SMP kernels on anything at the moment.
thanks,
grant
------------------------------
Message: 8
Date: Mon, 26 Jan 2004 09:13:16 -0700
From: Grant Grundler <grundler@parisc-linux.org>
Subject: Re: [parisc-linux] help installation failed on C240 (fx4)
workstation
To: Reinhold Flecke CCF <reinhold.flecke@ccf-consulting.de>
Cc: parisc-linux@lists.parisc-linux.org
Message-ID: <20040126161316.GC12175@colo.lackof.org>
Content-Type: text/plain; charset=us-ascii
On Mon, Jan 26, 2004 at 12:13:22PM +0100, Reinhold Flecke CCF wrote:
> I downloaded the "debian-30r2-hppa-binary-1.iso" and burned it to CD.
> If I start the installation on my C240 (fx4) workstation with the
command:
> bo sescsi.2.0
FX-4 graphics is not supported.
Either use serial console or replace the FX4 with PCI FX-E.
sorry,
grant
------------------------------
Message: 9
Date: Mon, 26 Jan 2004 18:00:53 +0100
From: "Joel Soete" <soete.joel@tiscali.be>
Subject: [parisc-linux] A fix for B2k and CONFIG_PDC_CONSOLE pb
To: "Grant Grundler" <grundler@parisc-linux.org>, "Christoph
Plattner"
<christoph.plattner@gmx.at>
Cc: parisc-linux@lists.parisc-linux.org
Message-ID: <400CB8A100004C60@ocpmta3.freegates.net>
Content-Type: text/plain; charset="iso-8859-1"
Hi Grant, Christoph,
I find a fix for this pb. I tested successfully (I reach to login with a
ttyB0 after replacing ttyS0 in inittab and telinit q :) ) on a 32bit 2.4
kernel on my b2k and a 64bit (up) [also 2.4] kernel on my N4k.
Here is its main part:
diff -NaurX dontdiff linux-2.4.24-pa0.orig/arch/parisc/kernel/firmware.c
linux-2.4.24-pa0/arch/parisc/kernel/firmware.c
--- linux-2.4.24-pa0.orig/arch/parisc/kernel/firmware.c 2003-10-02
07:30:55.000000000
+0200
+++ linux-2.4.24-pa0/arch/parisc/kernel/firmware.c 2004-01-26
16:48:23.000000000
+0100
@@ -871,15 +937,21 @@
int status;
/* Bail if no console input device. */
- if (!PAGE0->mem_kbd.iodc_io)
+ if ((PAGE0->mem_cons.cl_class != CL_DUPLEX) &&
!PAGE0->mem_kbd.iodc_io)
return 0;
/* wait for a keyboard (rs232)-input */
spin_lock_irqsave(&pdc_lock, flags);
- real32_call(PAGE0->mem_kbd.iodc_io,
- (unsigned long)PAGE0->mem_kbd.hpa, ENTRY_IO_CIN,
- PAGE0->mem_kbd.spa, __pa(PAGE0->mem_kbd.dp.layers),
- __pa(iodc_retbuf), 0, __pa(iodc_dbuf), 1, 0);
+ if (PAGE0->mem_cons.cl_class == CL_DUPLEX)
+ real32_call(PAGE0->mem_cons.iodc_io,
+ (unsigned long)PAGE0->mem_cons.hpa,
ENTRY_IO_CIN,
+ PAGE0->mem_cons.spa,
__pa(PAGE0->mem_cons.dp.layers),
+ __pa(iodc_retbuf), 0, __pa(iodc_dbuf), 1,
0);
+ else
+ real32_call(PAGE0->mem_kbd.iodc_io,
+ (unsigned long)PAGE0->mem_kbd.hpa,
ENTRY_IO_CIN,
+ PAGE0->mem_kbd.spa,
__pa(PAGE0->mem_kbd.dp.layers),
+ __pa(iodc_retbuf), 0, __pa(iodc_dbuf), 1,
0);
ch = *iodc_dbuf;
status = *iodc_retbuf;
diff -NaurX dontdiff linux-2.4.24-pa0.orig/arch/parisc/kernel/pdc_cons.c
linux-2.4.24-pa0/arch/parisc/kernel/pdc_cons.c
--- linux-2.4.24-pa0.orig/arch/parisc/kernel/pdc_cons.c 2004-01-19
07:25:46.000000000
+0100
+++ linux-2.4.24-pa0/arch/parisc/kernel/pdc_cons.c 2004-01-26
16:53:32.000000000
+0100
@@ -113,10 +112,6 @@
return;
++pdc_console_initialized;
- /* If the console is duplex then copy the COUT parameters to
CIN. */
- if (PAGE0->mem_cons.cl_class == CL_DUPLEX)
- memcpy(&PAGE0->mem_kbd, &PAGE0->mem_cons,
sizeof(PAGE0->mem_cons));
-
/* register the pdc console */
register_console(&pdc_cons);
}
==========><==========
Can somebody else could also test it on some other platform to be sure I
don't broken other stuff?
Thanks in advance,
Joel
PS: Grant I join the text file of the final backport of 2.6 work
included
this patch. Thanks in advance for your attention
------------------------------------------------------------------------
-
Tiscali ADSL: 12 mois à 29,50 EUR/mois! L'Internet rapide, c'est pour
tout
le monde.
http://reg.tiscali.be/default.asp?lg=fr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pdc_console-bp+patch.diff
Type: application/octet-stream
Size: 23324 bytes
Desc: not available
Url :
http://lists.parisc-linux.org/pipermail/parisc-linux/attachments/2004012
6/67438867/pdc_console-bppatch.obj
------------------------------
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
End of parisc-linux Digest, Vol 2, Issue 32
*******************************************
[-- Attachment #2: Type: text/html, Size: 29086 bytes --]
^ permalink raw reply
* Re: kernel 2.6.1 and cdrecord on ATAPI bus
From: Charles Shannon Hendrix @ 2004-01-27 0:59 UTC (permalink / raw)
To: Linux Kernel
In-Reply-To: <4014789F.2000202@tmr.com>
Sun, 25 Jan 2004 @ 21:17 -0500, Bill Davidsen said:
> I believe that you will find that you have to compile for 2.6 on a
> machine with /usr/src/linux pointing to the 2.6 kernel source. This is
> being discussed elsewhere, but is what got things working for me.
That should not matter any more.
For what it is worth, the problem appears to be fixed, and in the
wierdest way.
I booted kernel 2.4 without ide-scsi, and it failed to work. Then I
booted 2.4 with ide-scsi, and things were working again.
The burner could not read the last three CDs I burned, one CD/RW, and
the other CD/R's on kernel 2.6.1 and the other on a Windows machine.
Just for the hell of it, I blanked and burned the CD/RW.
Instantly, I could read all of the "problem" CDs.
I booted 2.4 without ide-scsi, and it worked.
I booted 2.6.1 without ide-scsi, and it worked.
It's as if doing that blank and burn operation "fixed" something about
the drive.
I'm hoping to try a few reboots to make sure this drive is working
before fully deciding things are OK, but it certainly looks that way.
--
shannon "AT" widomaker.com -- ["If you tell the truth, you don't have to
remember anything" -- Mark Twain]
^ permalink raw reply
* Re: 2.2 kernel and ext3 filesystems
From: Theodore Ts'o @ 2004-01-27 1:27 UTC (permalink / raw)
To: Andrew Morton; +Cc: campbell, linux-kernel
In-Reply-To: <20040126124141.6b6b84ba.akpm@osdl.org>
On Mon, Jan 26, 2004 at 12:41:41PM -0800, Andrew Morton wrote:
> ext3 was originally written for 2.2 but was never merged into the
> mainstream kernel. That happened in 2.4.15.
There were also some bug fixes that I'm pretty sure were never
backported into the 2.2 tree....
- Ted
^ permalink raw reply
* Re: Beginners Luck??
From: Christian Unger @ 2004-01-27 1:23 UTC (permalink / raw)
To: netfilter
In-Reply-To: <7C9884991ADAE0479C14F10C858BCDF567910C@alderaan.smgtec.com>
[-- Attachment #1: Type: text/plain, Size: 975 bytes --]
> It could be that you are blocking traffic to or from 'lo' or localhost.
> Make sure that you leave this alone. I know that java often uses ports
> for various mickel-muck. Anyways, also does port 6000 work correctly?
> Maybe if you described your base rules, I could tell you where you're
> problem is originating from.
That would make sense... as for 6000 not sure.
Forwarning this firewall is based on Robert L. Ziegler's book "Linux
Firewalls". The book is by and large good, but ... heck I haven't done this
before :).
Reason it is called stage2 is that i am planning to run a deny be default
script at startup ... thought that seems useless now that i've been thinking
about it, since i can just raise the firewall via if-up.
--
with kind regards,
Christian Unger
- < > - < > - < > - < > - < > - < > - < > - < > -
Alt. Email: chakkerz_dev@optusnet.com.au
ICQ: 204184156
Mobile: 0402 268904
Web: http://naiv.sourceforge.net
[-- Attachment #2: rc.firewall_stage2 --]
[-- Type: application/x-shellscript, Size: 22794 bytes --]
^ permalink raw reply
* Re: [PATCH] 2.6.2-rc2 - MPT Fusion driver 3.00.02 update
From: James Bottomley @ 2004-01-27 1:10 UTC (permalink / raw)
To: Moore, Eric Dean; +Cc: SCSI Mailing List, hch
In-Reply-To: <0E3FA95632D6D047BA649F95DAB60E5703D19D2F@exa-atlanta.se.lsil.com>
This causes a compile failure when CONFIG_PM isn't defined. I think the
attached is the fix.
James
===== drivers/message/fusion/mptbase.h 1.13 vs edited =====
--- 1.13/drivers/message/fusion/mptbase.h Mon Jan 26 11:56:15 2004
+++ edited/drivers/message/fusion/mptbase.h Mon Jan 26 17:25:05 2004
@@ -186,8 +186,8 @@
int (*suspend) (struct pci_dev *dev, u32 state);
#ifdef CONFIG_PM
int (*resume) (struct pci_dev *dev);
- void (*shutdown) (struct device * dev);
#endif
+ void (*shutdown) (struct device * dev);
};
/*
^ permalink raw reply
* Re: [Kernel-janitors] [PATCH] drivers/ide/ide-tape.c - handle kmalloc
From: Eugene Teo @ 2004-01-27 1:04 UTC (permalink / raw)
To: kernel-janitors
In-Reply-To: <20040122040839.GA2456@eugeneteo.net>
<quote sender="Randy.Dunlap">
> On Thu, 22 Jan 2004 12:08:39 +0800 Eugene Teo <eugene.teo@eugeneteo.net> wrote:
>
> | I have not compile nor test this patch. stage has to be checked for
> | null. No trailing spaces too :)
> |
> | 2902: static idetape_stage_t *__idetape_kmalloc_stage (..........)
> | [...]
> | 2909: if ((stage = (idetape_stage_t *) kmalloc (sizeof \
> | (idetape_stage_t),GFP_KERNEL)) = NULL)
> | 2910: return NULL;
> |
> | diff -Naur -X /home/amnesia/w/dontdiff 2.6.2-rc1-orig/drivers/ide/ide-tape.c 2.6.2-rc1-fix/drivers/ide/ide-tape.c
> | --- 2.6.2-rc1-orig/drivers/ide/ide-tape.c 2004-01-22 02:19:18.000000000 +0800
> | +++ 2.6.2-rc1-fix/drivers/ide/ide-tape.c 2004-01-22 12:01:56.000000000 +0800
> | @@ -3619,6 +3619,8 @@
> | printk(KERN_INFO "ide-tape: %s: reading back %d frames from the drive's internal buffer\n", tape->name, frames);
> | for (i = 0; i < frames; i++) {
> | stage = __idetape_kmalloc_stage(tape, 0, 0);
> | + if (!stage)
> | + return;
> | if (!first)
> | first = stage;
> | aux = stage->aux;
> |
>
> so... what makes it OK for void function "idetape_onstream_read_back_buffer"
> to just return at this point? It can't (or doesn't) return an error
> AFAICT, but the calling function expected certain work to be done...
this function is part of the write error recovery function that is
meant for the unrealiable pipelined mode. after recovering from the
internal buffer in an event of a write error, it will re-position the
tape.
Actually, I just spotted another thing that we need to fix. When we
are in the pipelined write mode, we can't inform the user about the
error codes (that is why it is a return void, not return error code),
until the next task. And the next possible place to inform the user,
is in the function "idetape_position_tape". If our read back buffer
fails because we are unable to allocate memory for a stage, then we
might not be able to position the tape (guess).
Sheese, idetape_discard_read_pipeline() should be tested to check
whether positioning can be done but it isn't for most of the calls
in ide-tape.c.
> I guess that it could panic(), although I hate adding panics.
I don't think it will panic, but it will be better if someone
can test this.
Eugene
> --
> ~Randy
> kernel-janitors project: http://janitor.kernelnewbies.org/
> _______________________________________________
> Kernel-janitors mailing list
> Kernel-janitors@lists.osdl.org
> http://lists.osdl.org/mailman/listinfo/kernel-janitors
>
--
Eugene TEO <eugeneteo at eugeneteo.net> <http://www.anomalistic.org/>
1024D/14A0DDE5 print D851 4574 E357 469C D308 A01E 7321 A38A 14A0 DDE5
main(i) { putchar(182623909 >> (i-1) * 5&31|!!(i<7)<<6) && main(++i); }
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ 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.