* async structure for serial.c
From: Jim Deas @ 2002-10-26 21:59 UTC (permalink / raw)
To: linux-serial
I have just upgraded my kernel from 2.4.7 to 2.4.18
After the upgrade I started having problems with
my "signal_handler_IO".
In the old version, this seemed to trigger only when
bytes were waiting on the serial port. It now seems
to trigger on send as well as receive increasing my
overhead.
I saw where TTY_DO_WRITE_WAKEUP was
added to kernel/serial.c.
Was this to create the action I am seeing? If so,
is there a way that only received characters can
trigger SIGIO and not a Tx ready or Tx send?
Regards,
J. Deas
^ permalink raw reply
* Re: expect
From: Chris Albert @ 2002-10-26 21:32 UTC (permalink / raw)
To: Russell Coker; +Cc: selinux
In-Reply-To: <200210262252.30567.russell@coker.com.au>
Russell Coker wrote:
>I want to run an expect script as:
>script program param1 param2 ...
>
>Then have the script spawn "program param1 param2" (sort of like "$@" in a
>bash script). How do I do this? Expect wants to combine all the parameters
>into a single parameter that contains spaces. How can I solve this?
>
>Also I want to do it for a varying number of parameters (so having an entry
>for each parameter isn't going to work).
>
>The aim of this is to provide the open_init_pty functionality. The version I
>posted to the list before will work for the basic SE functionality (IE
>Slackware type support). But for Debian support (and for full RPM support
>when someone implements it) we need to have open_init_pty run dpkg to install
>packages (and we can install multiple packages at the same time).
>
>
>
Russel,
Is is as you woud ex... imagine-- argv.
$expect script param1 param2 ... paramn
All the parameters are found in the list 'argv' , so if in script
...
set argc [llength $argv]
for (set i 0) {$i < $argc} {incr i} {
puts "arg $i: [lindex $argv $i]"
}
...
Then the script will spit out:
...
arg 0: param1
arg 1: param2
...
arg n: paramn
...
As in D.Libes' "Exploring Expect" (Oreilly)
Chris
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: PATCH: Support PCI device sorting (Re: PCI device order problem)
From: H. J. Lu @ 2002-10-26 21:44 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Alan Cox, Linux Kernel Mailing List
In-Reply-To: <3DBB0A81.6060909@pobox.com>
On Sat, Oct 26, 2002 at 05:34:57PM -0400, Jeff Garzik wrote:
> H. J. Lu wrote:
>
> >On Sat, Oct 26, 2002 at 05:12:51PM -0400, Jeff Garzik wrote:
> >
> >
> >>Well, WRT your implementation, the function you add is dead code if your
> >>new config variable is not set, which is not desireable at all.
> >>
> >>
> >
> >I am not sure if I understand what you were trying to say. If
> >CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC is not set, you should be able to
> >pass "pci=bussort" to kernel to sort the PCI device by bus, slot and
> >function. Did I miss something?
> >
> >
> The sorting function you add should be covered by the ifdef you add.
Have you tried? If I did that, the kernel wouldn't even compile. As I
said, when CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC isn't defined, my sorting
function is still available, just not called by default.
>
> >>WRT the overall idea, I would prefer to see what Linus and Martin Mares
> >>(and Ivan K) thought about it, before merging it. The x86 PCI code is
> >>very touchy, and your patch has the potential to change driver probe
> >>order for little gain.
> >>
> >>
> >>
> >
> >The whole purpose of my patch is to change PCI driver probe order in
> >such a way that is BIOS independent.
> >
> >
>
> The purpose is irrelevant to the effect on existing drivers and systems
> -- which is unknown. Making the probe order independent of BIOS
> ordering may very well break drivers and systems that are dependent on
> BIOS ordering. IOW what looks nice on your system could _likely_ suck
> for others. That's what I meant by "x86 PCI code is very touchy."
That is why CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC is off by default and
even if it is on, you can still override it by passing "pci=nosort"
or "pci=nobussort" to kernel.
H.J.
^ permalink raw reply
* Re: PATCH: Support PCI device sorting (Re: PCI device order problem)
From: Jeff Garzik @ 2002-10-26 21:34 UTC (permalink / raw)
To: H. J. Lu; +Cc: Alan Cox, Linux Kernel Mailing List
In-Reply-To: <20021026142704.A13207@lucon.org>
H. J. Lu wrote:
>On Sat, Oct 26, 2002 at 05:12:51PM -0400, Jeff Garzik wrote:
>
>
>>Well, WRT your implementation, the function you add is dead code if your
>>new config variable is not set, which is not desireable at all.
>>
>>
>
>I am not sure if I understand what you were trying to say. If
>CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC is not set, you should be able to
>pass "pci=bussort" to kernel to sort the PCI device by bus, slot and
>function. Did I miss something?
>
>
The sorting function you add should be covered by the ifdef you add.
>>WRT the overall idea, I would prefer to see what Linus and Martin Mares
>>(and Ivan K) thought about it, before merging it. The x86 PCI code is
>>very touchy, and your patch has the potential to change driver probe
>>order for little gain.
>>
>>
>>
>
>The whole purpose of my patch is to change PCI driver probe order in
>such a way that is BIOS independent.
>
>
The purpose is irrelevant to the effect on existing drivers and systems
-- which is unknown. Making the probe order independent of BIOS
ordering may very well break drivers and systems that are dependent on
BIOS ordering. IOW what looks nice on your system could _likely_ suck
for others. That's what I meant by "x86 PCI code is very touchy."
Jeff
^ permalink raw reply
* Re: AX.25 in 2.5.43
From: romieu @ 2002-10-26 21:27 UTC (permalink / raw)
To: Trever L. Adams; +Cc: Linux Kernel Mailing List
In-Reply-To: <1035666228.1504.7.camel@aurora.localdomain>
Trever L. Adams <tadams-lists@myrealbox.com> :
> I haven't tried this in 2.5.44 yet. I am just beginning to play with
> this myself. Has this been fixed or should I dig into it?
[undeclared AX25_P_IP]
Fixed. No need to dig. Upgrade.
--
Ueimor
^ permalink raw reply
* Re: PATCH: Support PCI device sorting (Re: PCI device order problem)
From: H. J. Lu @ 2002-10-26 21:27 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Alan Cox, Linux Kernel Mailing List
In-Reply-To: <3DBB0553.5070805@pobox.com>
On Sat, Oct 26, 2002 at 05:12:51PM -0400, Jeff Garzik wrote:
> Well, WRT your implementation, the function you add is dead code if your
> new config variable is not set, which is not desireable at all.
I am not sure if I understand what you were trying to say. If
CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC is not set, you should be able to
pass "pci=bussort" to kernel to sort the PCI device by bus, slot and
function. Did I miss something?
>
> WRT the overall idea, I would prefer to see what Linus and Martin Mares
> (and Ivan K) thought about it, before merging it. The x86 PCI code is
> very touchy, and your patch has the potential to change driver probe
> order for little gain.
>
The whole purpose of my patch is to change PCI driver probe order in
such a way that is BIOS independent.
H.J.
^ permalink raw reply
* Re: [parisc-linux] Re: mkfs.xfs (xfsprogs-2.3.5) failled
From: Randolph Chung @ 2002-10-26 21:18 UTC (permalink / raw)
To: Joel Soete; +Cc: jsoe0708, Stefan Pfetzing, parisc-linux
In-Reply-To: <3DBAD364.9060301@freebel.net>
In reference to a message from Joel Soete, dated Oct 26:
> i386 declare: "extern void __get_user_bad(void);"
> ...
> but not define elsewhere? (is it there so that the build of the kernel
> failed if that case was requested to run properly?)
yes.
> PS: afaik on i386 only put_user_u64 is define why not pending get_user?
on first glance i haven't found any code that uses get_user with 64-bit
quantities. if you have a specific need for this, please let me know.
in the mean time, i've checked in support for put_user with 64-bit
values. This is in 2.4.19-pa24
Let me know if this works for you. i've tested it only lightly.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
^ permalink raw reply
* i use iptables for nat, and can connect with ping command but other ports can't connect
From: Irvan Adrian Kristiono @ 2002-10-26 21:16 UTC (permalink / raw)
To: netfilter
hi, i'am from Indonesian, i use mandrake 8.2 for my
gateway
server, which had iptables installed on it.. so i
decided
to use it, and remove ipchains and ipvsadm. and i use
iptables -t nat -A POSTROUTING -s 192.168.15.0/24 -o
eth0 -j SNAT
--to-source myinternetip
when i try to browse from my workstation which at
192.168.15.0/24
it cannot find any page.. so i try ping command to
yahoo.com
IP, and get the reply. i'm so confused, why other port
cannot pass to workstation, although the INPUT,OUTPUT,
FORWARD Policy is ACCEPT.. so there isn't firewall at
all.
why ip tables cannot pass the port beside 80. aren't
must
i declared it first, how ? help me !!
__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/
^ permalink raw reply
* Re: e100 doing bad things in 2.5.44.
From: Jeff Garzik @ 2002-10-26 21:17 UTC (permalink / raw)
To: Dave Jones; +Cc: linux.nics, linux-kernel, scott.feldman
In-Reply-To: <20021025185316.GA10278@suse.de>
Dave Jones wrote:
>Oct 25 18:38:12 tetrachloride kernel: Debug: sleeping function called from illegal context at mm/slab.c:1384
>Oct 25 18:38:12 tetrachloride kernel: Call Trace:
>Oct 25 18:38:12 tetrachloride kernel: [<c011dd94>] __might_sleep+0x54/0x58
>Oct 25 18:38:12 tetrachloride kernel: [<c01403ae>] kmalloc+0x5a/0x314
>Oct 25 18:38:12 tetrachloride kernel: [<c017e2da>] proc_create+0x76/0xcc
>Oct 25 18:38:12 tetrachloride kernel: [<c017e3fb>] proc_mkdir+0x17/0x40
>Oct 25 18:38:12 tetrachloride kernel: [<c010a4c3>] register_irq_proc+0x6b/0xb0
>Oct 25 18:38:12 tetrachloride kernel: [<c010a2ba>] setup_irq+0x166/0x174
>Oct 25 18:38:12 tetrachloride kernel: [<c02b9424>] e100intr+0x0/0x308
>Oct 25 18:38:12 tetrachloride kernel: [<c0109b48>] request_irq+0x88/0xa4
>Oct 25 18:38:12 tetrachloride kernel: [<c02b84fa>] e100_open+0x106/0x188
>
>
Well, it holds bdp->isolate_lock for an incredibly long time, so that
might trigger this. At least interrupts aren't disabled.
Another bug: e100_close doesn't get the lock.
>Another weirdo.. Check out the Speed..
>
>Oct 25 18:38:12 tetrachloride kernel: Intel(R) PRO/100 Network Driver - version 2.1.24-k1
>Oct 25 18:38:12 tetrachloride kernel: Copyright (c) 2002 Intel Corporation
>Oct 25 18:38:12 tetrachloride kernel:
>Oct 25 18:38:12 tetrachloride kernel: e100: selftest OK.
>Oct 25 18:38:12 tetrachloride kernel: e100: eth0: Intel(R) PRO/100 VE Network Connection
>Oct 25 18:38:12 tetrachloride kernel: Mem:0xfeafc000 IRQ:20 Speed:0 Mbps Dx:N/A
>Oct 25 18:38:12 tetrachloride kernel: Hardware receive checksums enabled
>
Cosmetic or real, that's indeed another bug...
Jeff
^ permalink raw reply
* Re: PATCH: Support PCI device sorting (Re: PCI device order problem)
From: Jeff Garzik @ 2002-10-26 21:12 UTC (permalink / raw)
To: H. J. Lu; +Cc: Alan Cox, Linux Kernel Mailing List
In-Reply-To: <20021025202600.A3293@lucon.org>
Well, WRT your implementation, the function you add is dead code if your
new config variable is not set, which is not desireable at all.
WRT the overall idea, I would prefer to see what Linus and Martin Mares
(and Ivan K) thought about it, before merging it. The x86 PCI code is
very touchy, and your patch has the potential to change driver probe
order for little gain.
Jeff
^ permalink raw reply
* AX.25 in 2.5.43
From: Trever L. Adams @ 2002-10-26 21:03 UTC (permalink / raw)
To: Linux Kernel Mailing List
I haven't tried this in 2.5.44 yet. I am just beginning to play with
this myself. Has this been fixed or should I dig into it?
net/ipv4/arp.c:104:22: net/ax25.h: No such file or directory
net/ipv4/arp.c: In function `arp_send':
net/ipv4/arp.c:551: `AX25_P_IP' undeclared (first use in this function)
net/ipv4/arp.c:551: (Each undeclared identifier is reported only once
net/ipv4/arp.c:551: for each function it appears in.)
net/ipv4/arp.c: In function `arp_process':
net/ipv4/arp.c:670: `AX25_P_IP' undeclared (first use in this function)
make[2]: *** [net/ipv4/arp.o] Error 1
make[1]: *** [net/ipv4] Error 2
^ permalink raw reply
* expect
From: Russell Coker @ 2002-10-26 20:52 UTC (permalink / raw)
To: selinux
I want to run an expect script as:
script program param1 param2 ...
Then have the script spawn "program param1 param2" (sort of like "$@" in a
bash script). How do I do this? Expect wants to combine all the parameters
into a single parameter that contains spaces. How can I solve this?
Also I want to do it for a varying number of parameters (so having an entry
for each parameter isn't going to work).
The aim of this is to provide the open_init_pty functionality. The version I
posted to the list before will work for the basic SE functionality (IE
Slackware type support). But for Debian support (and for full RPM support
when someone implements it) we need to have open_init_pty run dpkg to install
packages (and we can install multiple packages at the same time).
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
--
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
* fcron
From: Russell Coker @ 2002-10-26 20:44 UTC (permalink / raw)
To: selinux
I've put a package of fcron patched with SE support on my web site. It's got
the patch against the upstream source and a Debian package.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: (X and other) basics (was: A few more things...)
From: Brandon George @ 2002-10-26 20:43 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <5.1.0.14.1.20021020114245.02526a00@celine>
here is yet another link for quite a few basic interpreters/compilers.
http://www.thefreecountry.com/developercity/basic.shtml
----- Original Message -----
From: "Ray Olszewski" <ray@comarre.com>
To: "Jim Reimer" <wa5rrh@arrl.net>; <linux-newbie@vger.kernel.org>
Sent: Sunday, October 20, 2002 2:10 PM
Subject: Re: (X and other) basics (was: A few more things...)
> OK. Now that we're just talking about Basic (not VisualBasic, which was
> where this thread started), there are a ton of choices. I can't speak to
> quality, though ... just quantity. Some have already been suggested by
others.
>
> A quick search through the Debian package system turned up these two:
>
> yabasic - Yet Another BASIC interpreter
> bwbasic - Bywater BASIC Interpreter
>
> TUCOWS (http://linux.tucows.com/system/basic.html) lists 6, the above two
plus
>
> Chipmunk BASIC (I think this is the one that Slackware used to
> include)
> Cubix
> ScriptBasic
> STLBasic
>
> Others that Google turned up ("linux BASIC interpreter", then following
> links a few steps in) include
>
> X11-BASIC (http://sourceforge.net/projects/x11-basic)
> ABSCIC (http://students.bath.ac.uk/cs1ars/b21lin2.html)
> Blassic (http://www.xente.mundo-r.com/notfound/blassic/)
> htBasic (http://www.techsoft.de/htbasic/linux.htm)
> smallBasic (http://smallbasic.sourceforge.net/)
> wxBasic (http://wxbasic.sourceforge.net/)
> KBasic (http://www.kbasic.org/1/home.php3) - not released yet
> Gnome Basic (http://www.gnome.org/projects/gb/) - not released
yet
> gambas (http://gambas.sourceforge.net/)
> Mole Basic (http://www.xs4all.nl/~merty/mole/)
> Bas (http://www.moria.de/~michael/bas/)
> Brandy Basic V (http://www.argonet.co.uk/users/dave_daniels/)
> gnbasic (http://www.excamera.com/articles/12/gnbasic.html)
>
> I skipped the BASIC interpreters written in Java; theere are several of
> them as well.
>
> Most of the ones I listed are not gui-dependent; just from their names,
you
> can pretty much spot the few that are.
>
> At 01:39 PM 10/20/02 -0500, Jim Reimer wrote:
> >Elias Athanasopoulos wrote:
> >>On Sun, Oct 20, 2002 at 05:09:55PM +0000, Heimo Claasen wrote:
> >>
> >>>The dependence on a GUI is indeed a bad thing. I did mention XBasic
> >>>because that seems to be the _only_ Basic dialect to be found for the
> >>>Linux environment at all.
> >>
> >>No. There is a BASIC interpreter for Unix. Make some Google search.
> >>Actually it was part of the standard installation of Slackware 3.0
> >>system, but I can't recall the name.
> >
> >
> >bwbasic? Used to use that on a SCO Unix system.
>
>
>
>
> --
> -------------------------------------------"Never tell me the
odds!"--------
> Ray Olszewski -- Han Solo
> Palo Alto, California, USA ray@comarre.com
> --------------------------------------------------------------------------
-----
>
> -
> 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
>
-
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
* >2 AIC7xxx (29160) fails on PPC 2.4.20-preXX-ben0
From: Ethan @ 2002-10-26 20:49 UTC (permalink / raw)
To: linux-kernel
I recently attempted to add an additional adaptec-29160 card to my dual
G4 (rootfs boots off one already). It failed miserably to say the
least. Using an older card (adaptec 2940uw) instead does work however.
The kernels in question are: 2.4.20-pre11-ben0 and 2.4.20-pre7-ben0.
Here's what happens:
.....
ct 26 16:19:24 spicymeatball kernel: SCSI subsystem driver Revision: 1.00
Oct 26 16:19:24 spicymeatball kernel: PCI: Enabling bus mastering for
device 10:14.0
Oct 26 16:19:24 spicymeatball kernel: scsi0 : Adaptec AIC7XXX
EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.8
Oct 26 16:19:24 spicymeatball kernel: <Adaptec 29160 Ultra160
SCSI adapter>
Oct 26 16:19:24 spicymeatball kernel: aic7892: Ultra160 Wide
Channel A, SCSI Id=7, 32/253 SCBs
Oct 26 16:19:24 spicymeatball kernel:
Oct 26 16:19:24 spicymeatball kernel: scsi1 : Adaptec AIC7XXX
EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.8
Oct 26 16:19:24 spicymeatball kernel: <Adaptec 29160 Ultra160
SCSI adapter>
Oct 26 16:19:24 spicymeatball kernel: aic7892: Ultra160 Wide
Channel A, SCSI Id=7, 32/253 SCBs
Oct 26 16:19:24 spicymeatball kernel:
Oct 26 16:19:24 spicymeatball kernel: blk: queue c1770e18, I/O limit
4095Mb (mask 0xffffffff)
Oct 26 16:19:24 spicymeatball kernel: scsi0:0:6:0: Attempting to queue
an ABORT message
Oct 26 16:19:24 spicymeatball kernel: scsi0: Dumping Card State in
Command phase, at SEQADDR 0xbc
Oct 26 16:19:24 spicymeatball kernel: ACCUM = 0x80, SINDEX = 0xa0,
DINDEX = 0xe4, ARG_2 = 0x0
Oct 26 16:19:24 spicymeatball kernel: HCNT = 0x0 SCBPTR = 0x0
Oct 26 16:19:24 spicymeatball kernel: SCSISEQ = 0x12, SBLKCTL = 0xa
Oct 26 16:19:24 spicymeatball kernel: DFCNTRL = 0x4, DFSTATUS = 0x88
Oct 26 16:19:24 spicymeatball kernel: LASTPHASE = 0x80, SCSISIGI = 0x86,
SXFRCTL0 = 0x88
Oct 26 16:19:24 spicymeatball kernel: SSTAT0 = 0x7, SSTAT1 = 0x1
Oct 26 16:19:24 spicymeatball kernel: SCSIPHASE = 0x10
Oct 26 16:19:24 spicymeatball kernel: STACK == 0x0, 0x0, 0x175, 0x34
Oct 26 16:19:24 spicymeatball kernel: SCB count = 4
Oct 26 16:19:24 spicymeatball kernel: Kernel NEXTQSCB = 2
Oct 26 16:19:24 spicymeatball kernel: Card NEXTQSCB = 0
Oct 26 16:19:24 spicymeatball kernel: QINFIFO entries:
Oct 26 16:19:24 spicymeatball kernel: Waiting Queue entries:
Oct 26 16:19:24 spicymeatball kernel: Disconnected Queue entries:
Oct 26 16:19:24 spicymeatball kernel: QOUTFIFO entries:
Oct 26 16:19:24 spicymeatball kernel: Sequencer Free SCB List: 1 2 3 4 5
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Oct 26 16:19:24 spicymeatball kernel: Sequencer SCB Info: 0(c 0x40, s
0x67, l 0, t 0x3) 1(c 0x0, s 0xff, l 255, t 0xff) 2(c 0x0, s 0xff, l
255, t 0xff) 3(c 0x0, s 0xff, l 255, t 0xff) 4(c 0x0, s 0xff, l 255, t
0xff) 5(c 0x0, s 0xff, l 255, t 0xff) 6(c 0x0, s 0xff, l 255, t 0xff)
7(c 0x0, s 0xff, l 255, t 0xff) 8(c 0x0, s 0xff, l 255, t 0xff) 9(c 0x0,
s 0xff, l 255, t 0xff) 10(c 0x0, s 0xff, l 255, t 0xff) 11(c 0x0, s
0xff, l 255, t 0xff) 12(c 0x0, s 0xff, l 255, t 0xff) 13(c 0x0, s 0xff,
l 255, t 0xff) 14(c 0x0, s 0xff, l 255, t 0xff) 15(c 0x0, s 0xff, l 255,
t 0xff) 16(c 0x0, s 0xff, l 255, t 0xff) 17(c 0x0, s 0xff, l 255, t
0xff) 18(c 0x0, s 0xff, l 255, t 0xff) 19(c 0x0, s 0xff, l 255, t 0xff)
20(c 0x0, s 0xff, l 255, t 0xff) 21(c 0x0, s 0xff, l 255, t 0xff) 22(c
0x0, s 0xff, l 255, t 0xff) 23(c 0x0, s 0xff, l 255, t 0xff) 24(c 0x0, s
0xff, l 255, t 0xff) 25(c 0x0, s 0xff, l 255, t 0xff) 26(c 0x0, s 0xff,
l 255, t 0xff) 27(c 0x0, s 0xff, l 255, t 0xff) 28(c 0x0, s 0xff, l 255,
t 0xff) 29(c 0x0, s 0xff, l 255, t 0xf
Oct 26 16:19:24 spicymeatball kernel: ) 30(c 0x0, s 0xff, l 255, t 0xff)
31(c 0x0, s 0xff, l 255, t 0xff)
Oct 26 16:19:24 spicymeatball kernel: Pending list: 3(c 0x40, s 0x67, l 0)
Oct 26 16:19:24 spicymeatball kernel: Kernel Free SCB list: 1 0
Oct 26 16:19:24 spicymeatball kernel: Untagged Q(6): 3
Oct 26 16:19:24 spicymeatball kernel: DevQ(0:6:0): 0 waiting
Oct 26 16:19:24 spicymeatball kernel: scsi0:0:6:0: Device is active,
asserting ATN
Oct 26 16:19:24 spicymeatball kernel: Recovery code sleeping
Oct 26 16:19:24 spicymeatball kernel: Recovery code awake
Oct 26 16:19:24 spicymeatball kernel: Timer Expired
Oct 26 16:19:24 spicymeatball kernel: aic7xxx_abort returns 0x2003
Oct 26 16:19:24 spicymeatball kernel: scsi0:0:6:0: Attempting to queue a
TARGET RESET message
Oct 26 16:19:24 spicymeatball kernel: aic7xxx_dev_reset returns 0x2003
Oct 26 16:19:24 spicymeatball kernel: Recovery SCB completes
Oct 26 16:19:24 spicymeatball kernel: scsi0:0:6:0: Attempting to queue
an ABORT message
Oct 26 16:19:24 spicymeatball kernel: scsi0: Dumping Card State in
Command phase, at SEQADDR 0x36
Oct 26 16:19:24 spicymeatball kernel: ACCUM = 0x80, SINDEX = 0xa0,
DINDEX = 0xe4, ARG_2 = 0x0
Oct 26 16:19:24 spicymeatball kernel: HCNT = 0x0 SCBPTR = 0x0
Oct 26 16:19:24 spicymeatball kernel: SCSISEQ = 0x12, SBLKCTL = 0xa
Oct 26 16:19:24 spicymeatball kernel: DFCNTRL = 0x4, DFSTATUS = 0x88
Oct 26 16:19:24 spicymeatball kernel: LASTPHASE = 0x80, SCSISIGI = 0x86,
SXFRCTL0 = 0x88
Oct 26 16:19:24 spicymeatball kernel: SSTAT0 = 0x7, SSTAT1 = 0x1
Oct 26 16:19:24 spicymeatball kernel: SCSIPHASE = 0x10
Oct 26 16:19:24 spicymeatball kernel: STACK == 0x0, 0x0, 0x175, 0x34
Oct 26 16:19:24 spicymeatball kernel: SCB count = 4
Oct 26 16:19:24 spicymeatball kernel: Kernel NEXTQSCB = 3
Oct 26 16:19:24 spicymeatball kernel: Card NEXTQSCB = 0
Oct 26 16:19:24 spicymeatball kernel: QINFIFO entries:
Oct 26 16:19:24 spicymeatball kernel: Waiting Queue entries:
Oct 26 16:19:24 spicymeatball kernel: Disconnected Queue entries:
Oct 26 16:19:24 spicymeatball kernel: QOUTFIFO entries:
...
this continues for quite a few cycles until:
Oct 26 16:19:25 spicymeatball kernel: scsi: device set offline - not
ready or command retry failed after bus reset: host 0 channel 0 id 8 lun 0
And the system finally boots (without the second card available of
course). As I said earlier, using a 2940UW as the second card works,
but is unacceptable for this setup. Any ideas here? I'm baffled.
Please cc me any replies, as I don't subscribe to the list.
thanks,
Ethan Weinstein
^ permalink raw reply
* Re: [RFC] [PATCH] 2.5.44 bootloader fix
From: H. Peter Anvin @ 2002-10-26 20:46 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <m1pttxlebr.fsf@frodo.biederman.org>
Followup to: <m1pttxlebr.fsf@frodo.biederman.org>
By author: ebiederm@xmission.com (Eric W. Biederman)
In newsgroup: linux.dev.kernel
>
> What I am proposing is an interface change. The only known bootloader
> this does not fix is gujin and the fix of loading segments earlier is
> trivial, and fully backwards compatible. The advantage of this patch
> is that no future changes to the kernel's gdt will affect bootloaders.
>
Please detail how the interface changes. It is not at all clear from
the code.
> @@ -101,7 +96,8 @@
> popl %eax # hcount
> movl $0x100000,%edi
> cli # make sure we don't get interrupted
> - ljmp $(__KERNEL_CS), $0x1000 # and jump to the move routine
> + movl $0x1000, %ebp
> + jmpl *%ebp # and jump to the move routine
>
> /*
> * Routine (template) for moving the decompressed kernel in place,
Why are you avoiding to set __SETUP_CS here?
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com>
^ permalink raw reply
* Re: your mail
From: Greg Lindahl @ 2002-10-26 20:32 UTC (permalink / raw)
To: 'linux-mips@linux-mips.org'
In-Reply-To: <37A3C2F21006D611995100B0D0F9B73CBFE312@tnint11.telogy.design.ti.com>
On Sat, Oct 26, 2002 at 03:48:27PM -0400, Zajerko-McKee, Nick wrote:
> I'm porting some code from x86 to mips(32) and noticed that in
> include/asm-mips/siginfo.h differs from include/asm-i386/siginfo.h in the
> order of elements of the sigchld structure. Was this an oversight or a
> design decision? I would think that it would be desirable to be almost the
> same as the x86 for userland ease of portability...
User programs normally get recompiled, so anything using the proper
includes IS portable.
The issue only appears if you are using binary translation of x86
programs on mips. For example, this is one:
http://www.transitives.com/products.htm
For this, you need to write a system call translation layer which
rearranges things appropriately. An existing example is the o32 layer
in mips64, and soon the n32 layer in mips64.
-- greg
^ permalink raw reply
* Re: [PATCH]: linux-2.5.44uc1 (MMU-less support)
From: Sam Ravnborg @ 2002-10-26 20:18 UTC (permalink / raw)
To: Greg Ungerer; +Cc: linux-kernel
In-Reply-To: <3DBAC09A.4090104@snapgear.com>
On Sun, Oct 27, 2002 at 02:19:38AM +1000, Greg Ungerer wrote:
> - arch Makefiles rewritten
Took a look at them.
See comments below.
Sam
diff -Naur linux-2.5.44/arch/m68knommu/Makefile linux-2.5.44uc1/arch/m68knommu/Makefile
--- linux-2.5.44/arch/m68knommu/Makefile Thu Jan 1 10:00:00 1970
+++ linux-2.5.44uc1/arch/m68knommu/Makefile Sun Oct 27 02:09:09 2002
+PLATFORM = $(platform-y)
Use := no late evaluation required.
+MODEL = $(model-y)
See above.
+cpuclass-$(CONFIG_M68VZ328) := 68328
+CPUCLASS = $(cpuclass-y)
+CLASSDIR = arch/m68knommu/platform/$(cpuclass-y)/
ditto
+CLEAN_FILES += include/asm-$(ARCH)/asm-offsets.h.tmp \
+ include/asm-$(ARCH)/asm-offsets.h \
+ arch/$(ARCH)/kernel/asm-offsets.s
Use the new clean infrastrucute.
clean-files := include/asm-$(ARCH)/asm-offsets.h.tmp \
include/asm-$(ARCH)/asm-offsets.h \
arch/$(ARCH)/kernel/asm-offsets.s
+prepare: include/asm-$(ARCH)/asm-offsets.h
+archclean:
Add a call to clean boot - something like
$(call descend arch/$(ARCH)/boot, subdirclean)
+
+arch/$(ARCH)/kernel/asm-offsets.s: include/asm include/linux/version.h \
+ include/config/MARKER
+
+include/asm-$(ARCH)/asm-offsets.h.tmp: arch/$(ARCH)/kernel/asm-offsets.s
+ @$(generate-asm-offsets.h) < $< > $@
+
+include/asm-$(ARCH)/asm-offsets.h: include/asm-$(ARCH)/asm-offsets.h.tmp
+ @echo -n ' Generating $@'
+ @$(update-if-changed)
Combine it like this instead:
include/asm-$(ARCH)/asm-offsets.h: arch/$(ARCH)/kernel/asm-offsets.s \
include/asm include/linux/version.h \
include/config/MARKER
@echo -n ' Generating $@'
@$(generate-asm-offsets.h) < $< > $@
@$(update-if-changed)
Thats more readable, and follow te normal way of doing it.
diff -Naur linux-2.5.44/arch/m68knommu/boot/Makefile linux-2.5.44uc1/arch/m68knommu/boot/Makefile
--- linux-2.5.44/arch/m68knommu/boot/Makefile Thu Jan 1 10:00:00 1970
+++ linux-2.5.44uc1/arch/m68knommu/boot/Makefile Sun Oct 27 02:09:08 2002
@@ -0,0 +1,5 @@
+clean:
+ rm -f *.[oa]
+
+dep depend:
+ :
The above can safely be deleted.
General comment.
Use
EXTRA_TARGET :=
in replacement for
EXTRA_TARGETS =
Thas is required in many platform specific makefiles
diff -Naur linux-2.5.44/arch/m68knommu/platform/68328/Makefile linux-2.5.44uc1/arch/m68knommu/platform/68328/Makefile
+
+arch/m68knommu/platform/68328/$(BOARD)/bootlogo.rh: arch/m68knommu/platform/68328/bootlogo.h
+ perl arch/m68knommu/platform/68328/bootlogo.pl \
+ < arch/m68knommu/platform/68328/bootlogo.h \
+ > arch/m68knommu/platform/68328/$(BOARD)/bootlogo.rh
The following is more readable:
$obj)/$(BOARD)/bootlogo.rh: $(src)/bootlogo.h
$(PERL) $(src)/bootlogo.pl < $(src)/bootlogo.h
> $(obj)/$(BOARD)/bootlogo.rh
diff -Naur linux-2.5.44/arch/m68knommu/platform/68EZ328/Makefile linux-2.5.44uc1/arch/m68knommu/platform/68EZ328/Makefile
+
$(obj)/$(BOARD)/bootlogo.rh: $(src)/bootlogo.h
$(PERL) $(src)/bootlogo.pl < $(src)/bootlogo.h \
> $(obj)/$(BOARD)/bootlogo.rh
The same changes a listed above.
diff -Naur linux-2.5.44/arch/m68knommu/platform/68VZ328/Makefile linux-2.5.44uc1/arch/m68knommu/platform/68VZ328/Makefile
+arch/m68knommu/platform/68VZ328/$(BOARD)/bootlogo.rh: arch/m68knommu/platform/68EZ328/bootlogo.h
+ perl arch/m68knommu/platform/68328/bootlogo.pl \
+ < arch/m68knommu/platform/68EZ328/bootlogo.h \
+ > arch/m68knommu/platform/68VZ328/$(BOARD)/bootlogo.rh
Again - use $(obj) - $(src)
diff -Naur linux-2.5.44/arch/m68knommu/platform/Makefile linux-2.5.44uc1/arch/m68knommu/platform/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for the arch/m68knommu/platform.
+#
+
+include $(TOPDIR)/Rules.make
+
This makefile looks not at all usefull for me.
^ permalink raw reply
* Re: your mail
From: Daniel Jacobowitz @ 2002-10-26 20:08 UTC (permalink / raw)
To: Zajerko-McKee, Nick; +Cc: 'linux-mips@linux-mips.org'
In-Reply-To: <37A3C2F21006D611995100B0D0F9B73CBFE312@tnint11.telogy.design.ti.com>
On Sat, Oct 26, 2002 at 03:48:27PM -0400, Zajerko-McKee, Nick wrote:
> Hi,
>
> I'm porting some code from x86 to mips(32) and noticed that in
> include/asm-mips/siginfo.h differs from include/asm-i386/siginfo.h in the
> order of elements of the sigchld structure. Was this an oversight or a
> design decision? I would think that it would be desirable to be almost the
> same as the x86 for userland ease of portability...
It's probably for compatibility with that other MIPS operating system -
IRIX.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply
* (no subject)
From: Zajerko-McKee, Nick @ 2002-10-26 19:48 UTC (permalink / raw)
To: 'linux-mips@linux-mips.org'
Hi,
I'm porting some code from x86 to mips(32) and noticed that in
include/asm-mips/siginfo.h differs from include/asm-i386/siginfo.h in the
order of elements of the sigchld structure. Was this an oversight or a
design decision? I would think that it would be desirable to be almost the
same as the x86 for userland ease of portability...
^ permalink raw reply
* Re: [PATCH] hyper-threading information in /proc/cpuinfo
From: Rik van Riel @ 2002-10-26 19:48 UTC (permalink / raw)
To: J.A. Magallon
Cc: Nakajima, Jun, Robert Love, Alan Cox, 'Dave Jones',
'akpm@digeo.com', 'linux-kernel@vger.kernel.org',
'chrisl@vmware.com', 'Martin J. Bligh'
In-Reply-To: <20021026004320.GA1676@werewolf.able.es>
On Sat, 26 Oct 2002, J.A. Magallon wrote:
> Summary:
> - each package can handle several (someone said 128+ ;) ) processor cores.
> We really do not mind if they are really independent (power4) or not
> (xeon, ht)
Here is the big opinion of difference. Apparently people _do_
care, otherwise they would have never asked for HT evil twins
to be reported separately in /proc.
kind regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Current spamtrap: <a href=mailto:"october@surriel.com">october@surriel.com</a>
^ permalink raw reply
* Reiserfsck 3.6.4 --rebuild-tree statistics
From: Philippe Gramoullé @ 2002-10-26 19:42 UTC (permalink / raw)
To: reiserfs
Hi,
I just wanted to give these figures for those who might wonder how much time can
take a --rebuild-tree. Of course these figures should be taken with precaution and
may not reflect you particular environment.
Setup : ~500Go Raid volume ( DELL PowerVault 210S RAID5 (2x5 spanned disks + 2 hot spares)
filled with 170Go of quite deeply nested data & directories
Controller DELL 2450: PIII 1GHz SMP 1Go RAM
Time it took to make the --rebuild-tree: 8 hours 30 minutes.
Philippe.
0 transactions replayed
###########
reiserfsck --rebuild-tree started at Fri Oct 25 15:22:56 2002
###########
Pass 0:
Loading on-disk bitmap .. ok, 42809069 blocks marked used
Skipping 12578 blocks (super block, journal, bitmaps) 42796491 blocks will be read
0%....20%....40%....60%....80%....100%
"r5" hash is selected
Flushing..finished
Read blocks (but not data blocks) 42796491
Leaves among those 620311
- corrected leaves 1
- leaves all contents of which could not be saved and deleted 621
pointers in indirect items to wrong area 46 (zeroed)
Objectids found 3261439
Pass 1 (will try to insert 619690 leaves):
Looking for allocable blocks .. fininshed
0%....20%....40%....60%....80%....100%
Flushing..finished
619690 leaves read
616003 inserted
- pointers in indirect items pointing to metadata 9 (zeroed)
3687 not inserted
non-unique pointers in indirect items (zeroed) 1035
Pass 2:
0%....20%....40%....60%....80%....100%
Flushing..finished
Leaves inserted item by item 3687
Pass 3 (semantic):
Flushing..finished
Files found: 2410869
Directories found: 535225
Symlinks found: 12
Others: 157
Files with fixed size: 3
Names pointing to nowhere (removed): 22
Pass 3a (looking for lost dir/files):
Looking for lost directories:
Looking for lost files:
Flushing..finished
Objects without names 83728
Empty lost dirs removed 292596
Dirs linked to /lost+found: 8146
Dirs without stat data found 1
Files linked to /lost+found 56884
Objects having used objectids: 45
files fixed 5
Pass 4 - finished
Deleted unreachable items 870
Flushing..finished
Syncing..finished
###########
reiserfsck finished at Fri Oct 25 23:49:35 2002
###########
^ permalink raw reply
* [parisc-linux] A few questions
From: posix @ 2002-10-26 19:27 UTC (permalink / raw)
To: parisc-linux
[-- Attachment #1: Type: text/plain, Size: 198 bytes --]
Hi!
I was wondering if there is another way than what is descriped in the PA-RISC/linux-bootHOWTO to exit serial console and enter graphics console?
I would really appreciate an answer //Patrick
[-- Attachment #2: Type: text/html, Size: 609 bytes --]
^ permalink raw reply
* Re: Creating a Hybrid Connection to Balance Traffic
From: Oskar Andreasson @ 2002-10-26 19:25 UTC (permalink / raw)
To: Paul Aumer-Ryan; +Cc: netfilter
In-Reply-To: <20021026190433.24795.qmail@web40607.mail.yahoo.com>
Hi Paul,
Your story sounds like you are looking for assymetric routing, which
should be doable with policy routing. Check out
http://www.policyrouting.org where Matthew Marsh is currently working on
getting his excellent book "Policy Routing using Linux" online.
Note that it isn't fully up on the net yet, so if you need to find out how
it works quickly, you may want to buy the book.
Other resources that may be of interest is http://www.lartc.org,
http://www.netfilter.org and http://www.frozentux.net. The last two sites
contains information on iptables in linux kernel 2.4, which you may want
to upgrade to if you are still running kernel 2.2.
Hope this is of some help.
----
Oskar Andreasson
http://www.frozentux.net
mailto:blueflux@koffein.net
On Sat, 26 Oct 2002, Paul Aumer-Ryan wrote:
> I've got a peculiar situation that I hope you all
> would listen to and offer feedback on any possible
> implementations.
>
> So I've recently broke down and purchased a DSL
> connection for my home computer, and I've just
> discovered the joys of p2p file sharing (i.e., being
> able to download television shows that my local
> stations have stopped carrying, like Enterprise).
> Anyway, as you can guess, these video files are rather
> large, and other users also grab them from my computer
> as well, so my upload speeds are rather high. Since
> I've subscribed to DSL service through a local ISP,
> and since local ISPs are big on service but not on
> resources, I got a call from them recently asking me
> to tone down my upload bandwidth usage on the DSL
> line. I've pretty much got to listen or I will lose
> my service.
>
> My local setup consists of a linux box acting as a
> gateway for my home network of (gasp!) one computer
> and a laptop. The linux box currently uses ipchains
> to perform the necessary IP masquerading for the
> connection. Some quick stats:
>
> eth0: external network connection (to ISP)
> eth1: internal network
> ppp0: modem attached, but not currently used.
>
> So here comes the question: since I've got to reduce
> my upload usage, I'd like to try to use the linux box
> to do a special form of SNAT routing. I would like
> all outgoing data to leave through the attached ppp0
> interface (the modem which I can hook up to a dialup
> ISP) and all incoming data to come back in through the
> eth0 interface (the broadband connection to my local
> ISP). Basically, I need to do a form of SNAT routing
> that overwrites the source address of packets leaving
> on the ppp0 interface with the IP address of the eth0
> interface, so when their replies come back the will
> come on the faster broadband connection. This way the
> upload bandwidth usage on the DSL connection will be
> effectively zero, while I will still be able to enjoy
> the fast download speeds of the DSL line, satisfying
> both me and the ISP.
>
> My issues include the current usage of SNAT routing
> (masquerading) since my local network connects to the
> internet through the linux box's one IP address, and
> how to use ipchains, iptables, or ipnatctl (or others)
> to perform this extra set of SNAT routing. Does
> anyone have any ideas on how to implement this?
>
> Sorry for the long story, and I thank everyone in
> advance for their time. Have a good one,
> Paul
>
> __________________________________________________
> Do you Yahoo!?
> Y! Web Hosting - Let the expert host your web site
> http://webhosting.yahoo.com/
>
>
^ permalink raw reply
* [ANNOUNCE] Linux project funding
From: Randy.Dunlap @ 2002-10-26 19:24 UTC (permalink / raw)
To: linux-hotplug
Hi,
The Linux-USB project has some funds available to be used to
encourage or support Linux kernel or userspace open-source
development.
Information for qualifying projects and applications to this fund
can be found at "http://www.linux-usb.org/beanieForm.html".
Thanks,
~Randy
[apologies if you receive multiple copies of this announcement]
-------------------------------------------------------
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.