* RE: Invalid PBLK length
From: Grover, Andrew @ 2002-12-18 21:28 UTC (permalink / raw)
To: 'Matthew Wilcox', Adachi, Kenichi
Cc: haug-X6ztD3ggwzuBAmxm6OvjtTjhTm2NLCe8,
acpi-devel-pyega4qmqnRoyOMFzWx49A
> From: Matthew Wilcox [mailto:willy-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org]
> you're right. Andy, could we add something like this?
> +#define ACPI_ADR_SPACE_FIXED_HARDWARE (ACPI_ADR_SPACE_TYPE) 127
Yes, thanks.
Regards -- Andy
PS about the iasl glibc thing - you do know you can compile your own from
the acpica-unix source release, right?
-------------------------------------------------------
This SF.NET email is sponsored by: Order your Holiday Geek Presents Now!
Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap,
MP3 Players, XBox Games, Flying Saucers, WebCams, Smart Putty.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* Re: [PATCH]: fix compiler warnings in the math-emulator
From: Greg Lindahl @ 2002-12-18 21:27 UTC (permalink / raw)
To: linux mips mailing list
In-Reply-To: <Pine.GSO.3.96.1021218220828.14826A-100000@delta.ds2.pg.gda.pl>
> > Sometimes you don't care whether you do only "half" a macro instruction
> > if the branch is taken. Usually though, the warning is a good thing - I
> > remember having spent many hours finding bugs like this with assemblers
> > that don't issue warnings.
>
> This is exactly what ".set nomacro" is for -- I can't see any reason for
> such warnings when ".set macro" is active.
While in general I like playing with sharp knives (you should see my
cluster admin toolkit), and I like my kernel to run fast, and the only
thing that gets trashed is usually at, I still think I'd prefer to
have nops in those delay slots in the kernel. Hand-written assembly is
unlikely to use ".set nomacro" properly.
-- greg
^ permalink raw reply
* Re: [parisc-linux] still problems with PCI IDE controller
From: Grant Grundler @ 2002-12-18 21:24 UTC (permalink / raw)
To: Joerg Steindlberger; +Cc: parisc-linux
In-Reply-To: <courier.3E00E3ED.000010DA@server01>
On Wed, Dec 18, 2002 at 10:08:34PM +0100, Joerg Steindlberger wrote:
> Dino f2000000: IRQ base 96, stuck IRQ lines? 0x2
The loop that reads and deMuxes the IRQ lines for Dino exits after
a few times in order to avoid monopolizing the CPU.
What that msg tells me is we are in the interrupt handler long
enough that the next eth0 interrupt is outstanding again.
I would guess this is because IDE is handling IO on the interrupt
stack (reading block data via PIO).
IDE in PIO Mode (ie not using DMA) does not play well with the
rest of the system.
You can usually ignore this msg.
> Seems that there is still nobody else who tried to use cheap IDE disks with a
> parisc machine :-(
Nope. IDE is EEEeevil ;^)
grant
^ permalink raw reply
* RE: gettimeofday() moving backwards
From: Grover, Andrew @ 2002-12-18 21:23 UTC (permalink / raw)
To: 'Paul Richards',
acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
> From: Paul Richards [mailto:p.a.richards-Y3tGgqFSo3OFxr2TtlUqVg@public.gmane.org]
> I am using linux kernel v2.4.20 with ACPI patch dated 2002-12-05.
>
> I have noticed that if my processor changes state (800Mhz up
> to 1200Mhz say)
> then gettimeofday() behaves weirdly. It runs smoothly but
> every now and again
> (on the order of 10 times a second) it makes a correction.
> If I have gone from
> 800Mhz to 1200Mhz then the correction is backwards, otherwise
> it makes a forward
> jump..
Hmm, can you mention this on the cpufreq mailing list?
cpufreq-1walMZg8u8rXmaaqVzeoHQ@public.gmane.org .
Thanks -- Regards -- Andy
-------------------------------------------------------
This SF.NET email is sponsored by: Order your Holiday Geek Presents Now!
Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap,
MP3 Players, XBox Games, Flying Saucers, WebCams, Smart Putty.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* RE: flashing a different bios-- is it safe?
From: Grover, Andrew @ 2002-12-18 21:21 UTC (permalink / raw)
To: 'James D Strandboge',
Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
> From: James D Strandboge [mailto:jstrand1-aYIB8uWIUb2Vn7q6wjsIow@public.gmane.org]
> I have a dell inspiron 8200, which has a bios that sort of works with
> acpi, but will sometimes crash (see previous emails). I have
> looked at
> my dsdt, and it is extraordinarily cryptic.
>
> Today, I was googling for information about all of this, and
> came across
> somebody flashing their insprion 8200 bios with the bios for the dell
> latitude c840. This person was doing this to be able to use the port
> replicator properly, and was running windows. He reported success and
> no problems. This seems like a crazy thing to do-- is it safe? I
> figured I may have to flash back to the old bios, but was worried that
> this might break something permanently?
You could very well break something permanently, yes. In fact, I'd consider
it likely.
-- Andy
-------------------------------------------------------
This SF.NET email is sponsored by: Order your Holiday Geek Presents Now!
Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap,
MP3 Players, XBox Games, Flying Saucers, WebCams, Smart Putty.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* [BENCHMARK] 2.5.52-mm1 with contest
From: Con Kolivas @ 2002-12-18 21:25 UTC (permalink / raw)
To: linux kernel mailing list; +Cc: Andrew Morton
Here are contest benchmarks for 2.5.52-mm1 for SMP only:
noload:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.50 [5] 39.3 180 0 0 1.09
2.5.50-mm1 [6] 39.4 181 0 0 1.09
2.5.51 [3] 39.6 180 0 0 1.09
2.5.51-mm1 [3] 39.5 181 0 0 1.09
2.5.51-mm2 [3] 39.1 182 0 0 1.08
2.5.52 [7] 39.3 181 0 0 1.09
2.5.52-mm1 [8] 39.7 180 0 0 1.10
cacherun:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.50 [5] 36.5 194 0 0 1.01
2.5.50-mm1 [6] 36.6 194 0 0 1.01
2.5.51 [3] 36.5 195 0 0 1.01
2.5.51-mm1 [2] 36.8 194 0 0 1.02
2.5.51-mm2 [3] 36.4 195 0 0 1.01
2.5.52 [7] 36.5 194 0 0 1.01
2.5.52-mm1 [7] 36.9 194 0 0 1.02
process_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.50 [5] 47.8 148 10 46 1.32
2.5.50-mm1 [5] 47.6 150 8 43 1.31
2.5.51 [3] 50.5 139 12 54 1.39
2.5.51-mm1 [2] 51.0 138 13 56 1.41
2.5.51-mm2 [3] 48.3 145 11 49 1.33
2.5.52 [7] 48.7 144 10 49 1.34
2.5.52-mm1 [7] 49.0 144 10 50 1.35
ctar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.50 [5] 54.6 157 1 10 1.51
2.5.50-mm1 [5] 51.3 155 0 4 1.42
2.5.51 [7] 58.2 158 1 10 1.61
2.5.51-mm2 [7] 55.1 158 1 11 1.52
2.5.52 [7] 56.1 161 1 10 1.55
2.5.52-mm1 [7] 55.5 156 1 10 1.53
xtar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.50 [5] 116.2 103 2 10 3.21
2.5.50-mm1 [5] 83.9 111 1 9 2.32
2.5.51 [7] 104.8 124 2 10 2.89
2.5.51-mm2 [7] 100.2 112 1 10 2.77
2.5.52 [7] 83.1 138 1 9 2.29
2.5.52-mm1 [7] 77.4 122 1 8 2.14
io_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.50 [5] 87.6 102 14 22 2.42
2.5.50-mm1 [5] 99.0 92 14 21 2.73
2.5.51 [7] 84.6 102 13 21 2.34
2.5.51-mm2 [7] 86.4 101 12 21 2.39
2.5.52 [7] 73.1 111 10 19 2.02
2.5.52-mm1 [7] 80.5 108 10 19 2.22
io_other:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.50 [5] 59.3 139 7 18 1.64
2.5.50-mm1 [5] 70.5 125 10 22 1.95
2.5.51 [7] 64.5 134 7 18 1.78
2.5.51-mm2 [7] 64.1 133 7 20 1.77
2.5.52 [7] 75.1 120 10 21 2.07
2.5.52-mm1 [7] 60.1 131 7 18 1.66
read_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.50 [5] 49.3 151 5 7 1.36
2.5.50-mm1 [5] 52.1 142 2 3 1.44
2.5.51 [3] 48.5 154 5 7 1.34
2.5.51-mm2 [2] 49.4 151 6 7 1.36
2.5.52 [7] 49.4 151 5 7 1.36
2.5.52-mm1 [7] 49.9 149 5 6 1.38
list_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.50 [5] 43.4 167 0 8 1.20
2.5.50-mm1 [5] 44.0 167 0 7 1.22
2.5.51 [3] 43.5 167 0 8 1.20
2.5.51-mm2 [2] 43.3 168 0 8 1.20
2.5.52 [7] 43.2 167 0 9 1.19
2.5.52-mm1 [7] 43.8 167 0 9 1.21
mem_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.50 [5] 63.3 141 36 3 1.75
2.5.50-mm1 [5] 67.1 126 39 3 1.85
2.5.51 [7] 62.6 148 38 3 1.73
2.5.51-mm2 [7] 63.0 144 38 3 1.74
2.5.52 [7] 63.5 148 38 3 1.75
2.5.52-mm1 [7] 71.1 123 36 2 1.96
Shorter times on the io writing loads (io load, io other, xtar load).
Slightly longer time on mem_load without any increase in the amount of loads
performed.
I can't offer meaningful Uniprocessor results because unfortunately doing a make
clean, mrproper, config, dep in that testbed tree seems to invalidate previous
results even with the same .config. Why the same config can take longer or
shorter to compile after cleaning up the tree makes no sense to me but since
I've observed it I'll mention it and not post the results.
Further details and archived results can be found here:
http://www.osdl.org/projects/ctdevel/results/
Regards,
Con
^ permalink raw reply
* Re: 405LP RTC reset
From: David Gibson @ 2002-12-18 21:15 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: embedded list, Todd Poynor
In-Reply-To: <1040225939.29647.11.camel@granite.austin.ibm.com>
On Wed, Dec 18, 2002 at 09:38:53AM -0600, Hollis Blanchard wrote:
>
> On Tue, 2002-12-17 at 18:55, David Gibson wrote:
> >
> > On Tue, Dec 17, 2002 at 12:43:32PM -0600, Hollis Blanchard wrote:
> > > Here's the updated 405LP RTC reset diff (after David's move of the RTC
> > > functions to ibm405lp.c). This patch
> > > a) does a full RTC reset as specified in the docs
> > > b) sets the RTC clock speed in RTC "Register A" DV bits, i.e. it does
> > > not assume the firmware has done this correctly.
> >
> > One query though (I didn't think of this earlier) - is it such a great
> > idea to go setting the reference clock frequency? Unlike most other
> > drivers, we can't just take over the RTC and do what we like with it
> > once the kernel boots, because it has to keep running at the same rate
> > even when the device is rebooting or (mostly) off.
>
> The only issue I can think of here is the firmware setting it
> incorrectly or not at all. In that case, a few seconds will be expanded
> or compressed, but that's better than time running too fast or slow
> forever, right?
That's true. Still, I think it might be worth testing what the rate
is set to when we come in, and printing a warning if it's not what we
expect before we adjust it. If it just silently corrects it I could
imagine it being pretty nasty to track down why the device is
losing/gaining time each boot.
> Of course the rate settings must be battery-backed along with the time,
> so you only need to set it once per RTC power loss. That includes
> rebooting time and power off time.
>
> -Hollis
--
David Gibson | For every complex problem there is a
david@gibson.dropbear.id.au | solution which is simple, neat and
| wrong.
http://www.ozlabs.org/people/dgibson
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: 2.4.19, don't "hdparm -I /dev/hde" if hde is on a Asus A7V133 Promise ctrlr, or...
From: Ross Biro @ 2002-12-18 21:19 UTC (permalink / raw)
To: Andre Hedrick; +Cc: D.A.M. Revok, linux-kernel
In-Reply-To: <Pine.LNX.4.10.10212181308340.8350-100000@master.linux-ide.org>
Andre Hedrick wrote:
>And this is the drive hack job that Promise did to it in 2.4.19.
>This is not my driver version and you need to nail Marcelo for this issue.
>Wait, move to 2.4.20 and it may go away. Better yet go back to 2.4.18 and
>it should be clean.
>
I'm not sure if the problem code is in the patch from Promise, but I can
say we have applied the promise supplied patch to 2.4.18 and as a whole
it is a nightmare. I don't recomend it if you don't need it.
Ross
^ permalink raw reply
* [LARTC] Am I correct?
From: LARTC @ 2002-12-18 21:12 UTC (permalink / raw)
To: lartc
I've got some customers that have lots of bandwidth that are uploading and
downloading files to our https:// help desk and are using up all of my T-1
at times. This leaves other customers sucking wind. I've taken a look at the
'15.10. Example of a full nat solution with QoS' section. Would it work for
me if I change the section that says eth0 to my internet adapter Serial0? If
I can do that, will that allow fair sharing between all my customers of the
https:// help desk?
My setup:
////////// ///////////////// ///////
https:// |-- |eth0 * Serial0 |-- |INET |
////////// ///////////////// ///////
My proposed script:
CEIL\x1020 # actual is 1024Kbit
IFACE=Serial0
tc qdisc add dev $IFACE root handle 1: htb default 15
tc class add dev $IFACE parent 1: classid 1:1 htb rate ${CEIL}kbit ceil
${CEIL}kbit
tc class add dev $IFACE parent 1:1 classid 1:10 htb rate 170kbit ceil
170kbit prio 0
tc class add dev $IFACE parent 1:1 classid 1:11 htb rate 170kbit ceil
${CEIL}kbit prio 1
tc class add dev $IFACE parent 1:1 classid 1:12 htb rate 170kbit ceil
${CEIL}kbit prio 2
tc class add dev $IFACE parent 1:1 classid 1:13 htb rate 170kbit ceil
${CEIL}kbit prio 2
tc class add dev $IFACE parent 1:1 classid 1:14 htb rate 170kbit ceil
${CEIL}kbit prio 3
tc class add dev $IFACE parent 1:1 classid 1:15 htb rate 170kbit ceil
${CEIL}kbit prio 3
tc qdisc add dev $IFACE parent 1:12 handle 120: sfq perturb 10
tc qdisc add dev $IFACE parent 1:13 handle 130: sfq perturb 10
tc qdisc add dev $IFACE parent 1:14 handle 140: sfq perturb 10
tc qdisc add dev $IFACE parent 1:15 handle 150: sfq perturb 10
tc filter add dev $IFACE parent 1:0 protocol ip prio 1 handle 1 fw classid
1:10
tc filter add dev $IFACE parent 1:0 protocol ip prio 2 handle 2 fw classid
1:11
tc filter add dev $IFACE parent 1:0 protocol ip prio 3 handle 3 fw classid
1:12
tc filter add dev $IFACE parent 1:0 protocol ip prio 4 handle 4 fw classid
1:13
tc filter add dev $IFACE parent 1:0 protocol ip prio 5 handle 5 fw classid
1:14
tc filter add dev $IFACE parent 1:0 protocol ip prio 6 handle 6 fw classid
1:15
iptables -t mangle -I PREROUTING -p icmp -j MARK --set-mark 0x1
iptables -t mangle -I PREROUTING -p icmp -j RETURN
iptables -t mangle -I PREROUTING -p tcp -m tcp --sport ssh -j
MARK --set-mark 0x1
iptables -t mangle -I PREROUTING -p tcp -m tcp --sport ssh -j RETURN
iptables -t mangle -I PREROUTING -p tcp -m tcp --tcp-flags SYN,RST,ACK
SYN -j MARK --set-mark 0x1
iptables -t mangle -I PREROUTING -p tcp -m tcp --tcp-flags SYN,RST,ACK
SYN -j RETURN
iptables -t mangle -I PREROUTING -p tcp -m tcp --sport https -j
MARK --set-mark 0x3
iptables -t mangle -I PREROUTING -p tcp -m tcp --sport https -j RETURN
iptables -t mangle -I PREROUTING -m tos --tos Minimize-Delay -j
MARK --set-mark 0x1
iptables -t mangle -I PREROUTING -m tos --tos Minimize-Delay -j RETURN
iptables -t mangle -I PREROUTING -m tos --tos Minimize-Cost -j
MARK --set-mark 0x5
iptables -t mangle -I PREROUTING -m tos --tos Minimize-Cost -j RETURN
iptables -t mangle -I PREROUTING -m tos --tos Maximize-Throughput -j
MARK --set-mark 0x6
iptables -t mangle -I PREROUTING -m tos --tos Maximize-Throughput -j RETURN
Thanks in advance for any suggestions
Bernard
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: [PATCH]: fix compiler warnings in the math-emulator
From: Maciej W. Rozycki @ 2002-12-18 21:09 UTC (permalink / raw)
To: Hartvig Ekner; +Cc: linux mips mailing list
In-Reply-To: <200212181950.gBIJo4B11893@coplin09.mips.com>
On Wed, 18 Dec 2002, Hartvig Ekner wrote:
> Sometimes you don't care whether you do only "half" a macro instruction
> if the branch is taken. Usually though, the warning is a good thing - I
> remember having spent many hours finding bugs like this with assemblers
> that don't issue warnings.
This is exactly what ".set nomacro" is for -- I can't see any reason for
such warnings when ".set macro" is active.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re: [parisc-linux] still problems with PCI IDE controller
From: Joerg Steindlberger @ 2002-12-18 21:08 UTC (permalink / raw)
To: parisc-linux
In-Reply-To: <courier.3E005801.0000711F@server01>
Hi all!
I still do have problems with using my IDE controller with parisc-linux. =
I=20
get the following message onto my console when generation large traffic t=
o /=20
from my IDE disks:
hp-c240:~# dd if=3D/dev/ide/host0/bus0/target0/lun0/disc of=3D/dev/null
Dino f2000000: IRQ base 96, stuck IRQ lines? 0x2
Dino f2000000: IRQ base 96, stuck IRQ lines? 0x2
Dino f2000000: IRQ base 96, stuck IRQ lines? 0x2
[...]
The device using the IRQ 96 is the internal ethernet controller (not the =
IDE=20
controller!):
hp-c240:~# cat /proc/interrupts | grep 96
96: 17424 Dino eth0
Seems that there is still nobody else who tried to use cheap IDE disks wi=
th a=20
parisc machine :-(
For those who are interrested anyway: The reason that causes the kernel c=
rash=20
is the multimode option. You can either select it for native IDE support=20
(CONFIG_IDEDISK_MULTI_MODE=3Dy) or it is automatically selected with the=20
special drivers for i.e. Promise controllers.
Regards
Joerg
> hp-c240:~# modprobe -k ide-mod
> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebu=
s=3Dxx
> PDC20268: IDE controller on PCI bus 00 dev 08
> PDC20268: chipset revision 2
> PDC20268: not 100% native mode: will probe irqs later
> ide0: BM-DMA at 0xfd00-0xfd07, BIOS settings: hda:pio, hdb:pio
> ide1: BM-DMA at 0xfd08-0xfd0f, BIOS settings: hdc:pio, hdd:pio
> hp-c240:~# modprobe -k ide-probe-mod
> hdd: IBM-DTTA-351680, ATA DISK drive
> ide1 at 0xfb00-0xfb07,0xfc02 on irq 97
> hp-c240:~# modprobe -k ide-disk
> hdd: 33022080 sectors (16907 MB) w/462KiB Cache, CHS=3D32760/16/63
> /dev/ide/host0/bus1/target1/lun0: [PTBL] [2055/255/63] p1
> hp-c240:~# mount /dev/ide/host0/bus1/target1/lun0/part1 /mnt/tmp
> (works with and without devfs)
^ permalink raw reply
* Re: 2.4.19, don't "hdparm -I /dev/hde" if hde is on a Asus A7V133 Promise ctrlr, or...
From: Andre Hedrick @ 2002-12-18 21:10 UTC (permalink / raw)
To: Ross Biro; +Cc: D.A.M. Revok, linux-kernel
In-Reply-To: <3E00BBC0.6020807@google.com>
On Wed, 18 Dec 2002, Ross Biro wrote:
>
> There is a bug in the Promise driver that clears an important PIO bit
> when switching into DMA mode. When you do an hdparm -I, it issues a
> drive command that attempts to transfer data in PIO mode, but since the
> PIO mode timing registers are hosed, the machine locks up. It's easy to
> reproduce and applies to all drive commands that return data including
> SMART commands.
>
> The bit in particular is bit 4 of PCI config register 0x61+4*channel
> number (PB bit 4 in Promise terms.) I've got a very unclean fix that I
> will attempt to clean up once I can put a few more important issues to bed.
>
> For the time being, you can try to do a work around by putting the drive
> into PIO mode with hdparm -X 12 before issuing any drive commands.
>
> Ross
>
> D.A.M. Revok wrote:
>
> >( that's a capital-aye in the hdparm line )
> >
> >not even the Magic SysReq key will work.
> >
> >also, don't
> >
> >"cd /proc/ide/hde ; cat identify"
> >
> >... same thing
> >drive-light comes on, but have to use the power-switch to get the machine
> >back, ( lost stuff again, fuck )
> >
> >
> >proc says it's pdc202xx
> >
> >Promise Ultra series driver Ver 1.20.0.7 2002-05-23
> >Adapter: Ultra100 on M/B
And this is the drive hack job that Promise did to it in 2.4.19.
This is not my driver version and you need to nail Marcelo for this issue.
Wait, move to 2.4.20 and it may go away. Better yet go back to 2.4.18 and
it should be clean.
Regards,
Andre Hedrick
LAD Storage Consulting Group
^ permalink raw reply
* Re: Horrible drive performance under concurrent i/o jobs (dlh problem?)
From: Con Kolivas @ 2002-12-18 21:10 UTC (permalink / raw)
To: kernel; +Cc: linux kernel mailing list
>So copied everything away to a software raid and tried all the disk
>tuning stuff (min-, max-readahead, bdflush, elvtune). Nothing helped.
>Last Sunday I then found a hint about a bug introduced in kernel
>2.4.19-pre6 which could be fixed using a "dlh", disk latency hack - or
>going back to 2.4.18. Last is what I did ( from 2.4.20 )
I made the dlh (disk latency hack) and it is related to a problem of system
response under heavy IO load, NOT the actual IO throughput so this sounds
unrelated. However, I have seen what you describe with reiserFS and ide raid at
least and had it fixed by applying AA's stuck in D fix, which ReiserFS is more
prone to for some complicated reason. Give that a go.
In
http://www.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.20aa1/
it is patch 9980_fix-pausing-2
Regards,
Con
^ permalink raw reply
* Re: mdadm -D shows incorrect working devices ?
From: raid @ 2002-12-18 20:57 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <Pine.LNX.4.50.0212172214130.25725-100000@ddx.a2000.nu>
Today rebuiled raid5 (8/8 disks)
mdadm -D is still showing incorrect info
(9 devices total/8 active/7 working/2 failed)
can someone explain this ?
]# cat /proc/mdstat
Personalities : [raid0] [raid5]
read_ahead 1024 sectors
md0 : active raid5 sdg1[7] sdb1[0] sdi1[6] sdh1[5] sdf1[4] sde1[3] sdd1[2]
sdc1[1]
820527232 blocks level 5, 64k chunk, algorithm 0 [8/8] [UUUUUUUU]
unused devices: <none>
]# mdadm -D /dev/md0
/dev/md0:
Version : 00.90.00
Creation Time : Fri Oct 18 23:11:09 2002
Raid Level : raid5
Array Size : 820527232 (782.51 GiB 840.21 GB)
Device Size : 117218176 (111.78 GiB 120.03 GB)
Raid Devices : 8
Total Devices : 9
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Wed Dec 18 21:50:43 2002
State : dirty, no-errors
Active Devices : 8
Working Devices : 7
Failed Devices : 2
Spare Devices : 0
Layout : left-asymmetric
Chunk Size : 64K
Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
1 8 33 1 active sync /dev/sdc1
2 8 49 2 active sync /dev/sdd1
3 8 65 3 active sync /dev/sde1
4 8 81 4 active sync /dev/sdf1
5 8 113 5 active sync /dev/sdh1
6 8 129 6 active sync /dev/sdi1
7 8 97 7 active sync /dev/sdg1
UUID : 316793d2:5e51db22:3607b944:6aeb5e01
^ permalink raw reply
* Re: [BUG] 2.5.47 - Assertion failed in fs/jbd/journal.c:415
From: Robert Macaulay @ 2002-12-18 20:55 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
In-Reply-To: <3E00DC07.7729E6A2@digeo.com>
On Wed, 18 Dec 2002, Andrew Morton wrote:
> I can't immediately see what would cause this. There is code in
> __journal_file_buffer which could have triggered this, but we should
> have exclusion from that via both lock_kernel() and lock_journal().
>
> I'll see if Stephen can spot it. I shall assume you were using
> the data-ordered journalling mode.
>
Correct, I also had them mounted with noatime as well if that matters.
^ permalink raw reply
* [LARTC] VoIP and CBQ
From: James Ma @ 2002-12-18 20:51 UTC (permalink / raw)
To: lartc
[-- Attachment #1: Type: text/plain, Size: 1993 bytes --]
Hi, All,
I did some work on QoS with CBQ. Basically, I wanted to separate VoIP traffic from other traffics and give it guarantied bandwidth. I used the following scripts to do the work,
#!/bin/sh
OPTION="allot 1514 maxburst 20 avpkt 1000"
tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 10: cbq bandwidth 10mbit avpkt 1000
tc class add dev eth0 parent 10: classid 10:2 cbq bandwidth 10mbit rate 34kbit $OPTION prio 3 bounded
tc class add dev eth0 parent 10:2 classid 10:10 cbq bandwidth 10mbit rate 30kbit $OPTION prio 3
tc class add dev eth0 parent 10:2 classid 10:20 cbq bandwidth 10mbit rate 4kbit $OPTION prio3
tc filter add dev eth0 parent 10: protocol ip prio 3 u32 match ip tos 0x20 0xf0 flowid 10:2
tc filter add dev eth0 parent 10: protocol ip prio 3 u32 match ip dst 0/0 flowid 10:2
tc filter add dev eth0 parent 10:2 protocol ip prio 3 u32 match ip tos 0x20 0xf0 flowid 10:10
tc filter add dev eth0 parent 10:2 protocol ip prio 3 u32 match ip dst 0/0 flowid 10:20
It seemed working -- when there was no VoIP traffic, a ftp link was using all 34kbit rate. When there was VoIP traffic, the ftp rate dropped to 17kbit (which was correct because the voice traffic was using 17kbit). Unfortunately, the voice quality was not good. Even if without ftp traffic, there were packets loss for voice traffic (if you count from 1 to 20 with one handset, you miss certain figures on the other end, they are 4, 5, 8, 9, 12, 13 etc).
Any one had the same problem before? Any one can explain it? Any parameter I should adjust to better suit this application?
Another thing I noticed was, when I changed the parameters for "allot" (ex 300) and "avpkt" (ex 500) in order to seek better setting for this application, the CBQ stopped doing anything, so the rate was the NIC rate instead of 34kbit. I could change "maxburst" but it didn't improve the voice quality. Could any one tell me how to use these parameters?
Thanks,
James
[-- Attachment #2: Type: text/html, Size: 3423 bytes --]
^ permalink raw reply
* nf_debug.c version 0.2
From: Ranjeet Shetye @ 2002-12-18 20:49 UTC (permalink / raw)
To: netfilter-devel
In-Reply-To: <20021217230706.GB25448@oknodo.bof.de>
[-- Attachment #1: Type: text/plain, Size: 523 bytes --]
This code is more complete and works well enough for me. Let me know if
you run into any problems.
If the interconnection complexity of the various NAT structs intimidates
you, this code should help clear up the internal organization. As
before, use it absolutely SPARINGLY.
Thanks to everyone for pointing out mistakes / corrections /
improvements and helping me.
Ranjeet Shetye
Senior Software Engineer
Zultys Technologies
771 Vaqueros Avenue
Sunnyvale CA 94085
USA
Ranjeet.Shetye@Zultys.com
http://www.zultys.com/
[-- Attachment #2: nf_debug.h --]
[-- Type: application/octet-stream, Size: 2128 bytes --]
#ifndef _NF_DEBUG_H_
#define _NF_DEBUG_H_
/* Written by Ranjeet dot Shetye at Zultys dot com */
#include <linux/types.h>
#include <linux/init.h>
#include <linux/netfilter.h>
#include <linux/ip.h>
#include <linux/tcp.h>
#include <linux/if.h>
#include <linux/netfilter_ipv4/ip_nat.h>
#include <linux/netfilter_ipv4/ip_nat_rule.h>
#include <linux/netfilter_ipv4/ip_nat_protocol.h>
void my_print_ip_nat_hash (const struct ip_nat_hash * hash);
void my_print_ip_nat_helper (const struct ip_nat_helper * helper);
void my_print_ip_conntrack_dir (const enum ip_conntrack_dir * dir);
void my_print_ip_nat_info_manip (const struct ip_nat_info_manip * manip);
void my_print_ip_nat_seq (const struct ip_nat_seq * seq);
void my_print_tcp_conntrack_state (const enum tcp_conntrack * state);
void my_print_ip_ct_tcp (const struct ip_ct_tcp * tcp);
void my_print_ip_ct_ftp (const struct ip_ct_ftp * ftp);
void my_print_ip_ct_irc (const struct ip_ct_irc * irc);
void my_print_atomic_t (const atomic_t * atom);
void my_print_ip_ct_icmp (const struct ip_ct_icmp * icmp);
void my_print_timer_list (const struct timer_list * timerlist);
void my_print_ip_conntrack_tuple_hash (const struct ip_conntrack_tuple_hash * hash);
void my_print_ip_conntrack_manip_proto (const union ip_conntrack_manip_proto * manip_proto);
void my_print_ip_nat_range (const struct ip_nat_range * range);
void my_print_nf_conntrack (const struct nf_conntrack * nfc_ptr);
void my_print_list_head (const struct list_head * list);
void my_print_ip_conntrack_expect (const struct ip_conntrack_expect * expect);
void my_print_ip_conntrack_helper (const struct ip_conntrack_helper * helper);
void my_print_nf_ct_info (const struct nf_ct_info * info);
void my_print_ip_nat_info (const struct ip_nat_info * info);
void my_print_ip_conntrack (const struct ip_conntrack *conntrack);
void my_print_ip_conntrack_tuple (const struct ip_conntrack_tuple *tuple);
void my_print_ip_nat_manip_type (const enum ip_nat_manip_type * maniptype);
void my_print_ip_conntrack_manip (const struct ip_conntrack_manip * manip);
#endif /* _NF_DEBUG_H_ */
[-- Attachment #3: nf_debug.c --]
[-- Type: application/octet-stream, Size: 17723 bytes --]
/* Written by Ranjeet dot Shetye at Zultys dot com */
#include <linux/types.h>
#include <linux/init.h>
#include <linux/netfilter.h>
#include <linux/ip.h>
#include <linux/tcp.h>
#include <linux/if.h>
#include <linux/netfilter_ipv4/ip_nat.h>
#include <linux/netfilter_ipv4/ip_nat_rule.h>
#include <linux/netfilter_ipv4/ip_nat_protocol.h>
#include "nf_debug.h"
atomic_t nf_debug_indent = { 0 };
#if 0
/* printk ("%s () at %s:%d ", __FUNCTION__, __FILE__, __LINE__); */\
#endif /* 0 */
unsigned char tabs[] = "\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t";
#define NF_DPF(format, args...) \
{\
printk ("%.*s", nf_debug_indent.counter, tabs);\
printk (format,##args);\
}
void my_print_ip_nat_hash (const struct ip_nat_hash * hash)
{
atomic_inc (&nf_debug_indent);
if (hash == NULL)
{
NF_DPF ("pointer to ip_nat_hash:: is NULL\n");
atomic_dec (&nf_debug_indent);
return;
}
NF_DPF ("ip_nat_hash::list is of type struct list_head\n");
my_print_list_head (&(hash->list));
NF_DPF ("ip_nat_hash::conntrack is of type struct ip_conntrack\n");
my_print_ip_conntrack (hash->conntrack);
atomic_dec (&nf_debug_indent);
return;
}
void my_print_ip_nat_helper (const struct ip_nat_helper * helper)
{
atomic_inc (&nf_debug_indent);
if (helper == NULL)
{
NF_DPF ("pointer to ip_nat_helper:: is NULL\n");
atomic_dec (&nf_debug_indent);
return;
}
NF_DPF ("ip_nat_helper::list is of type struct list_head [helper TBD]\n");
/* my_print_list_head (&(helper->list)); */
NF_DPF ("ip_nat_helper::mask is of type struct ip_conntrack_tuple [helper TBD]\n");
/* my_print_ip_conntrack_tuple (&(helper->mask)); */
NF_DPF ("ip_nat_helper::tuple is of type struct ip_conntrack_tuple [helper TBD]\n");
/* my_print_ip_conntrack_tuple (&(helper->tuple)); */
NF_DPF ("ip_nat_helper::name [helper TBD]\n");
/* NF_DPF ("ip_nat_helper::name = %s\n", helper->name); */
NF_DPF ("ip_nat_helper::(*help) [helper TBD]\n");
/* NF_DPF ("ip_nat_helper::(*help) = %p\n", helper->help); */
atomic_dec (&nf_debug_indent);
return;
}
void my_print_ip_conntrack_dir (const enum ip_conntrack_dir * dir)
{
atomic_inc (&nf_debug_indent);
if (dir == NULL)
{
NF_DPF ("pointer to ip_conntrack_dir:: is NULL\n");
atomic_dec (&nf_debug_indent);
return;
}
switch (*dir)
{
case IP_CT_DIR_MAX:
NF_DPF ("ip_conntrack_dir::IP_CT_DIR_MAX\n");
break;
case IP_CT_DIR_ORIGINAL:
NF_DPF ("ip_conntrack_dir::IP_CT_DIR_ORIGINAL\n");
break;
case IP_CT_DIR_REPLY:
NF_DPF ("ip_conntrack_dir::IP_CT_DIR_REPLY\n");
break;
default:
NF_DPF ("ip_conntrack_dir::%d (Unknown)\n", *dir);
break;
}
atomic_dec (&nf_debug_indent);
return;
}
void my_print_ip_nat_info_manip (const struct ip_nat_info_manip * manip)
{
atomic_inc (&nf_debug_indent);
if (manip == NULL)
{
NF_DPF ("pointer to ip_nat_info_manip:: is NULL\n");
atomic_dec (&nf_debug_indent);
return;
}
NF_DPF ("ip_nat_info_manip::direction is of type u_int8_t\n");
my_print_ip_conntrack_dir ((enum ip_conntrack_dir *) &(manip->direction));
NF_DPF ("ip_nat_info_manip::hooknum = %u\n", manip->hooknum);
NF_DPF ("ip_nat_info_manip::maniptype is of type u_int8_t\n");
my_print_ip_nat_manip_type ((enum ip_nat_manip_type *) &(manip->maniptype));
NF_DPF ("ip_nat_info_manip::manip is of type struct ip_conntrack_manip\n");
my_print_ip_conntrack_manip (&(manip->manip));
atomic_dec (&nf_debug_indent);
return;
}
void my_print_ip_nat_seq (const struct ip_nat_seq * seq)
{
atomic_inc (&nf_debug_indent);
if (seq == NULL)
{
NF_DPF ("pointer to ip_nat_seq:: is NULL\n");
atomic_dec (&nf_debug_indent);
return;
}
NF_DPF ("ip_nat_seq::correction_pos = %u\n", seq->correction_pos);
NF_DPF ("ip_nat_seq::offset_before = %d\n", seq->offset_before);
NF_DPF ("ip_nat_seq::offset_after = %d\n", seq->offset_after);
atomic_dec (&nf_debug_indent);
return;
}
void my_print_tcp_conntrack_state (const enum tcp_conntrack * state)
{
atomic_inc (&nf_debug_indent);
if (state == NULL)
{
NF_DPF ("pointer to enum tcp_conntrack:: is NULL\n");
atomic_dec (&nf_debug_indent);
return;
}
switch (*state)
{
case TCP_CONNTRACK_NONE:
NF_DPF ("tcp_conntrack::TCP_CONNTRACK_NONE\n");
break;
case TCP_CONNTRACK_ESTABLISHED:
NF_DPF ("tcp_conntrack::TCP_CONNTRACK_ESTABLISHED\n");
break;
case TCP_CONNTRACK_SYN_SENT:
NF_DPF ("tcp_conntrack::TCP_CONNTRACK_SYN_SENT\n");
break;
case TCP_CONNTRACK_SYN_RECV:
NF_DPF ("tcp_conntrack::TCP_CONNTRACK_SYN_RECV\n");
break;
case TCP_CONNTRACK_FIN_WAIT:
NF_DPF ("tcp_conntrack::TCP_CONNTRACK_FIN_WAIT\n");
break;
case TCP_CONNTRACK_TIME_WAIT:
NF_DPF ("tcp_conntrack::TCP_CONNTRACK_TIME_WAIT\n");
break;
case TCP_CONNTRACK_CLOSE:
NF_DPF ("tcp_conntrack::TCP_CONNTRACK_CLOSE\n");
break;
case TCP_CONNTRACK_CLOSE_WAIT:
NF_DPF ("tcp_conntrack::TCP_CONNTRACK_CLOSE_WAIT\n");
break;
case TCP_CONNTRACK_LAST_ACK:
NF_DPF ("tcp_conntrack::TCP_CONNTRACK_LAST_ACK\n");
break;
case TCP_CONNTRACK_LISTEN:
NF_DPF ("tcp_conntrack::TCP_CONNTRACK_LISTEN\n");
break;
case TCP_CONNTRACK_MAX:
NF_DPF ("tcp_conntrack::TCP_CONNTRACK_MAX\n");
break;
default:
NF_DPF ("tcp_conntrack::%d (Unknown)\n", *state);
break;
}
atomic_dec (&nf_debug_indent);
return;
}
void my_print_ip_ct_tcp (const struct ip_ct_tcp * tcp)
{
atomic_inc (&nf_debug_indent);
if (tcp == NULL)
{
NF_DPF ("pointer to ip_ct_tcp:: is NULL\n");
atomic_dec (&nf_debug_indent);
return;
}
NF_DPF ("ip_ct_tcp::handshake_ack = %u\n", tcp->handshake_ack);
NF_DPF ("ip_ct_tcp::state is of type enum tcp_conntrack\n");
my_print_tcp_conntrack_state (&(tcp->state));
atomic_dec (&nf_debug_indent);
return;
}
void my_print_ip_ct_ftp (const struct ip_ct_ftp * ftp)
{
atomic_inc (&nf_debug_indent);
if (ftp == NULL)
{
NF_DPF ("pointer to ip_ct_ftp:: is NULL\n");
atomic_dec (&nf_debug_indent);
return;
}
NF_DPF ("ip_ct_ftp:: [TBD]\n");
atomic_dec (&nf_debug_indent);
return;
}
void my_print_ip_ct_irc (const struct ip_ct_irc * irc)
{
atomic_inc (&nf_debug_indent);
if (irc == NULL)
{
NF_DPF ("pointer to ip_ct_irc:: is NULL\n");
atomic_dec (&nf_debug_indent);
return;
}
NF_DPF ("ip_ct_irc:: [TBD]\n");
atomic_dec (&nf_debug_indent);
return;
}
void my_print_atomic_t (const atomic_t * atom)
{
atomic_inc (&nf_debug_indent);
if (atom == NULL)
{
NF_DPF ("pointer to atomic_t:: is NULL\n");
atomic_dec (&nf_debug_indent);
return;
}
NF_DPF ("atomic_t::counter = %d\n", atom->counter);
atomic_dec (&nf_debug_indent);
return;
}
void my_print_ip_ct_icmp (const struct ip_ct_icmp * icmp)
{
atomic_inc (&nf_debug_indent);
if (icmp == NULL)
{
NF_DPF ("pointer to ip_ct_icmp:: is NULL\n");
atomic_dec (&nf_debug_indent);
return;
}
NF_DPF ("ip_ct_icmp::count is of type atomic_t\n");
my_print_atomic_t (&(icmp->count));
atomic_dec (&nf_debug_indent);
return;
}
void my_print_timer_list (const struct timer_list * timerlist)
{
atomic_inc (&nf_debug_indent);
if (timerlist == NULL)
{
NF_DPF ("pointer to timer_list:: is NULL\n");
atomic_dec (&nf_debug_indent);
return;
}
NF_DPF ("timer_list::data = %lu\n", timerlist->data);
NF_DPF ("timer_list::expires = %lu\n", timerlist->expires);
NF_DPF ("timer_list::(*function) = %p\n", timerlist->function);
NF_DPF ("timer_list::list is of type struct list_head\n");
my_print_list_head (&(timerlist->list));
atomic_dec (&nf_debug_indent);
return;
}
void my_print_ip_conntrack_tuple_hash (const struct ip_conntrack_tuple_hash * hash)
{
atomic_inc (&nf_debug_indent);
if (hash == NULL)
{
NF_DPF ("pointer to ip_conntrack_tuple_hash:: is NULL\n");
atomic_dec (&nf_debug_indent);
return;
}
NF_DPF ("ip_conntrack_tuple_hash::list is of type struct list_head\n");
my_print_list_head (&(hash->list));
NF_DPF ("ip_conntrack_tuple_hash::tuple is of type struct ip_conntrack_tuple\n");
my_print_ip_conntrack_tuple (&(hash->tuple));
NF_DPF ("ip_conntrack_tuple_hash::ctrack is of type struct ip_conntrack * (pointer back to parent)\n");
/* my_print_ip_conntrack (hash->ctrack); */
atomic_dec (&nf_debug_indent);
return;
}
void my_print_ip_conntrack_manip_proto (const union ip_conntrack_manip_proto * manip_proto)
{
atomic_inc (&nf_debug_indent);
if (manip_proto == NULL)
{
NF_DPF ("pointer to ip_conntrack_manip_proto:: is NULL\n");
atomic_dec (&nf_debug_indent);
return;
}
NF_DPF ("ip_conntrack_manip_proto::Union of all, icmp.id, tcp.port, "
"udp.port = %d\n", manip_proto->all);
atomic_dec (&nf_debug_indent);
return;
}
void my_print_ip_nat_range (const struct ip_nat_range * range)
{
atomic_inc (&nf_debug_indent);
if (range == NULL)
{
NF_DPF ("pointer to ip_nat_range:: is NULL\n");
atomic_dec (&nf_debug_indent);
return;
}
NF_DPF ("ip_nat_range::flags = %d\n", range->flags);
NF_DPF ("ip_nat_range::min_ip = 0x%08X\n", range->min_ip);
NF_DPF ("ip_nat_range::max_ip = 0x%08X\n", range->max_ip);
NF_DPF ("ip_nat_range::min is of type union ip_conntrack_manip_proto\n");
my_print_ip_conntrack_manip_proto (&(range->min));
NF_DPF ("ip_nat_range::max is of type union ip_conntrack_manip_proto\n");
my_print_ip_conntrack_manip_proto (&(range->max));
atomic_dec (&nf_debug_indent);
return;
}
void my_print_nf_conntrack (const struct nf_conntrack * nfc_ptr)
{
atomic_inc (&nf_debug_indent);
if (nfc_ptr == NULL)
{
NF_DPF ("pointer to nf_conntrack:: is NULL\n");
atomic_dec (&nf_debug_indent);
return;
}
NF_DPF ("nf_conntrack::use.counter = %d\n", nfc_ptr->use.counter);
NF_DPF ("nf_conntrack::(*destroy) = %p\n", nfc_ptr->destroy);
atomic_dec (&nf_debug_indent);
return;
}
void my_print_list_head (const struct list_head * list)
{
atomic_inc (&nf_debug_indent);
if (list == NULL)
{
NF_DPF ("list_head:: is NULL\n");
atomic_dec (&nf_debug_indent);
return;
}
NF_DPF ("list_head::next is of type struct list_head\n");
my_print_list_head (list->next);
NF_DPF ("list_head::prev is of type struct list_head\n");
my_print_list_head (list->prev);
atomic_dec (&nf_debug_indent);
return;
}
void my_print_ip_conntrack_expect (const struct ip_conntrack_expect * expect)
{
atomic_inc (&nf_debug_indent);
if (expect == NULL)
{
NF_DPF ("pointer to ip_conntrack_expect:: is NULL\n");
atomic_dec (&nf_debug_indent);
return;
}
NF_DPF ("ip_conntrack_expect::expectant is of type struct ip_conntrack\n");
my_print_ip_conntrack (expect->expectant);
NF_DPF ("ip_conntrack_expect::list is of type struct list_head\n");
my_print_list_head (&(expect->list));
NF_DPF ("ip_conntrack_expect::mask is of type struct ip_conntrack_tuple\n");
my_print_ip_conntrack_tuple (&(expect->mask));
NF_DPF ("ip_conntrack_expect::tuple is of type struct ip_conntrack_tuple\n");
my_print_ip_conntrack_tuple (&(expect->tuple));
atomic_dec (&nf_debug_indent);
return;
}
void my_print_ip_conntrack_helper (const struct ip_conntrack_helper * helper)
{
atomic_inc (&nf_debug_indent);
if (helper == NULL)
{
NF_DPF ("ip_conntrack_helper:: is NULL\n");
atomic_dec (&nf_debug_indent);
return;
}
NF_DPF ("ip_conntrack_helper::list is of type struct list_head [helper TBD]\n");
/* my_print_list_head (helper->list); */
NF_DPF ("ip_conntrack_helper::mask is of type struct ip_conntrack_tuple [helper TBD]\n");
/* my_print_ip_conntrack_tuple (&(helper->mask)); */
NF_DPF ("ip_conntrack_helper::tuple is of type struct ip_conntrack_tuple [helper TBD]\n");
/* my_print_ip_conntrack_tuple (&(helper->tuple)); */
atomic_dec (&nf_debug_indent);
return;
}
void my_print_nf_ct_info (const struct nf_ct_info * info)
{
atomic_inc (&nf_debug_indent);
if (info == NULL)
{
NF_DPF ("pointer to nf_nt_info:: is NULL\n");
atomic_dec (&nf_debug_indent);
return;
}
NF_DPF ("nf_ct_info::master is of type struct nf_conntrack *\n");
my_print_nf_conntrack (info->master);
atomic_dec (&nf_debug_indent);
return;
}
void my_print_ip_nat_info (const struct ip_nat_info * info)
{
int i = 0;
atomic_inc (&nf_debug_indent);
if (info == NULL)
{
NF_DPF ("pointer to ip_nat_info:: is NULL\n");
atomic_dec (&nf_debug_indent);
return;
}
NF_DPF ("ip_nat_info::byipsproto is of type struct ip_nat_hash\n");
my_print_ip_nat_hash (&(info->byipsproto));
NF_DPF ("ip_nat_info::bysource is of type struct ip_nat_hash\n");
my_print_ip_nat_hash (&(info->bysource));
NF_DPF ("ip_nat_info::helper is of type struct ip_nat_helper *\n");
my_print_ip_nat_helper (info->helper);
NF_DPF ("ip_nat_info::initialized = %d\n", info->initialized);
NF_DPF ("ip_nat_info::manips[IP_NAT_MAX_MANIPS] is an array of type struct ip_nat_info_manip\n");
for (i = 0; i < IP_NAT_MAX_MANIPS; i++)
{
NF_DPF ("ip_nat_info::manips[%d]\n", i);
my_print_ip_nat_info_manip (&(info->manips[i]));
}
NF_DPF ("ip_nat_info::mtype is of type struct ip_nat_mapping_type * (deprecated)\n");
NF_DPF ("ip_nat_info::num_manips = %d\n", info->num_manips);
NF_DPF ("ip_nat_info::seq[IP_CT_DIR_MAX] is an array of type struct ip_nat_seq\n");
for (i = 0; i < IP_CT_DIR_MAX; i++)
{
NF_DPF ("ip_nat_info::seq[%d]\n", i);
my_print_ip_nat_seq (&(info->seq[i]));
}
atomic_dec (&nf_debug_indent);
return;
}
void my_print_ip_conntrack (const struct ip_conntrack *conntrack)
{
int i = 0;
atomic_inc (&nf_debug_indent);
if (conntrack == NULL)
{
NF_DPF ("pointer to ip_conntrack:: is NULL\n");
atomic_dec (&nf_debug_indent);
return;
}
NF_DPF ("ip_conntrack::ct_general is of type struct nf_conntrack\n");
my_print_nf_conntrack (&(conntrack->ct_general));
NF_DPF ("ip_conntrack::expected is of type struct ip_conntrack_expect\n");
my_print_ip_conntrack_expect (&(conntrack->expected));
NF_DPF ("ip_conntrack::help.ct_ftp_info is of type struct ip_ct_ftp\n");
my_print_ip_ct_ftp (&(conntrack->help.ct_ftp_info));
NF_DPF ("ip_conntrack::help.ct_irc_info is of type struct ip_ct_irc\n");
my_print_ip_ct_irc (&(conntrack->help.ct_irc_info));
NF_DPF ("ip_conntrack::helper is of type struct ip_conntrack_helper\n");
my_print_ip_conntrack_helper (conntrack->helper);
NF_DPF ("ip_conntrack::infos[IP_CT_NUMBER] is an array of type nf_ct_info\n");
for (i = 0; i < IP_CT_NUMBER; i++)
{
NF_DPF ("ip_conntrack::infos[%d]\n", i);
my_print_nf_ct_info (&(conntrack->infos[i]));
}
NF_DPF ("ip_conntrack::master is of type struct nf_ct_info\n");
my_print_nf_ct_info (&(conntrack->master));
NF_DPF ("ip_conntrack::nat is of type struct nat (anonymous)\n");
NF_DPF ("ip_conntrack::nat.masq_index=%d\n", conntrack->nat.masq_index);
NF_DPF ("ip_conntrack::nat.info is of type struct ip_nat_info\n");
my_print_ip_nat_info (&(conntrack->nat.info));
NF_DPF ("ip_conntrack::Union of tcp of type struct ip_ct_tcp, and icmp of type struct ip_ct_icmp\n");
my_print_ip_ct_tcp (&(conntrack->proto.tcp));
my_print_ip_ct_icmp (&(conntrack->proto.icmp));
NF_DPF ("ip_conntrack::status = %lu\n", conntrack->status);
NF_DPF ("ip_conntrack::timeout is of type struct timer_list\n");
my_print_timer_list (&(conntrack->timeout));
NF_DPF ("ip_conntrack::tuplehash[IP_CT_DIR_MAX] is an array of type struct ip_conntrack_tuple_hash\n");
for (i = 0; i < IP_CT_DIR_MAX; i++)
{
NF_DPF ("ip_conntrack::tuplehash[%d]\n", i);
my_print_ip_conntrack_tuple_hash (&(conntrack->tuplehash[i]));
}
atomic_dec (&nf_debug_indent);
return;
}
void my_print_ip_conntrack_tuple (const struct ip_conntrack_tuple *tuple)
{
atomic_inc (&nf_debug_indent);
if (tuple == NULL)
{
NF_DPF ("pointer to ip_conntrack_tuple:: is NULL\n");
atomic_dec (&nf_debug_indent);
return;
}
NF_DPF ("ip_conntrack_tuple::dst.ip = 0x%08X\n", tuple->dst.ip);
NF_DPF ("ip_conntrack_tuple::dst.protonum = %d\n", tuple->dst.protonum);
NF_DPF ("ip_conntrack_tuple::Union of dst.u.all, dst.u.icmp.type & dst.u.icmp.port, dst.u.tcp.port, "
"dst.u.udp.port = %d\n", tuple->dst.u.all);
NF_DPF ("ip_conntrack_tuple::src is of type struct ip_conntrack_manip\n");
my_print_ip_conntrack_manip (&(tuple->src));
atomic_dec (&nf_debug_indent);
return;
}
void my_print_ip_nat_manip_type (const enum ip_nat_manip_type * maniptype)
{
atomic_inc (&nf_debug_indent);
if (maniptype == NULL)
{
NF_DPF ("pointer to enum ip_nat_manip_type:: is NULL\n");
atomic_dec (&nf_debug_indent);
return;
}
switch (*maniptype)
{
case IP_NAT_MANIP_SRC:
NF_DPF ("ip_nat_manip_type::IP_NAT_MANIP_SRC\n");
break;
case IP_NAT_MANIP_DST:
NF_DPF ("ip_nat_manip_type::IP_NAT_MANIP_DST\n");
break;
default:
NF_DPF ("ip_nat_manip_type::%d (Unknown)\n", *maniptype);
break;
}
atomic_dec (&nf_debug_indent);
return;
}
void my_print_ip_conntrack_manip (const struct ip_conntrack_manip * manip)
{
atomic_inc (&nf_debug_indent);
if (manip == NULL)
{
NF_DPF ("pointer to ip_conntrack_manip:: is NULL\n");
atomic_dec (&nf_debug_indent);
return;
}
NF_DPF ("ip_conntrack_manip::ip = 0x%08X\n", manip->ip);
NF_DPF ("ip_conntrack_manip::u is of type struct ip_conntrack_manip_proto\n");
my_print_ip_conntrack_manip_proto (&(manip->u));
atomic_dec (&nf_debug_indent);
return;
}
^ permalink raw reply
* Re: 2.5.52 PNP failure
From: Ruslan U. Zakirov @ 2002-12-18 20:49 UTC (permalink / raw)
To: Richard A Nelson; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.51.0212171730020.7058@nqynaqf.yrkvatgba.voz.pbz>
On Tue, 17 Dec 2002, Richard A Nelson wrote:
>
> Hand transcribed, so probably missing something important ...
>
> Oops: 0000
> Eip: 0060:[<c01cdbf3>] Not tainted
> EIP is at compare_pnp_id+0x4f/0x78
> Call Trace:
> [<c01cfa43>] pnp_name_device+0x23/0x58
> [<c01cd9af>] __pnp_add_device+0xf/0xc8
> [<c01cdab4>] pnp_add_device+0x4c/0x54
> [<c010509b>] init+0x33/0x188
> [<c0105068>] init+0x0/0x188
> [<c0109211>] kernel_thread_helper+0x5/0xc
>
> <0>Kernel panic: Attempted to kill init!
>
Try this small patch. I think it'll help.
--- drivers/pnp/driver.c~ 2002-12-20 02:15:30.000000000 +0300
+++ drivers/pnp/driver.c 2002-12-20 02:24:53.000000000 +0300
@@ -165,6 +165,7 @@
if (!dev)
return -EINVAL;
ptr = dev->id;
+ id->next = NULL;
while (ptr && ptr->next)
ptr = ptr->next;
if (ptr)
--
Ruslan.
^ permalink raw reply
* Re: A7M266-D problems with integrate sound device and USB 2.0 PCI card
From: marco mascherpa aka mush @ 2002-12-18 20:43 UTC (permalink / raw)
To: Steve Lee, linux-kernel
In-Reply-To: <000301c2a6d5$bc9bfee0$0201a8c0@pluto>
On Wednesday 18 December 2002 21:40, Steve Lee wrote:
> One of my systems uses the A7M266-D and I've never had any issues with
> the onboard sound or the usb 2.0 pci card. I'm wondering if something
> else in your system could be causing the conflict?
i can't imagine what could it be. here's my lspci in case you see something
unusual:
root@penelope mush # lspci
00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] System
Controller (rev 11)
00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] AGP
Bridge
00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] ISA (rev 05)
00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-768 [Opus] IDE (rev
04)
00:07.3 Bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] ACPI (rev 03)
00:09.0 SCSI storage controller: Adaptec AIC-7892A U160/m (rev 02)
00:10.0 PCI bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] PCI (rev 05)
01:05.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 04)
02:00.0 USB Controller: Advanced Micro Devices [AMD] AMD-768 [Opus] USB (rev
07)
02:04.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10)
02:05.0 Ethernet controller: VIA Technologies, Inc. VT86C100A [Rhine] (rev 06)
02:08.0 USB Controller: NEC Corporation USB (rev 41)
02:08.1 USB Controller: NEC Corporation USB (rev 41)
02:08.2 USB Controller: NEC Corporation USB 2.0 (rev 02)
^ permalink raw reply
* RE: A7M266-D problems with integrate sound device and USB 2.0 PCI card
From: Steve Lee @ 2002-12-18 20:40 UTC (permalink / raw)
To: mush, linux-kernel
In-Reply-To: <200212182057.33880.mush@monrif.net>
One of my systems uses the A7M266-D and I've never had any issues with
the onboard sound or the usb 2.0 pci card. I'm wondering if something
else in your system could be causing the conflict?
Steve
-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of marco mascherpa
aka mush (by way of marcomascherpa aka mush <mush@monrif.net>)
Sent: Wednesday, December 18, 2002 1:58 PM
To: linux-kernel@vger.kernel.org
Subject: A7M266-D problems with integrate sound device and USB 2.0 PCI
card
hi,
i have got a dueal athlon MP system with asus' A7M266-D motherboard wich
has
an integrated soundcard and is provided with a pci usb 2.0 expansion
card.
the problem is that my kernel 2.4.19 can't assign the right IRQ to the
soundcard and to the usb ports. to be more clear i append the dmsg. i
tried
to use some kernel parameters to tweak the configuration (like pirq, pci
and
noapic) but i couldn't resolve anything. how can my devices be assigned
a
valid irq and work correctly?
Please Cc: me. I am not subscribed to the list.
dmesg:
Common caps: 0383fbf7 c1cbfbff 00000000 00000000
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
CPU: Before vendor init, caps: 0383fbff c1cbfbff 00000000, vendor = 2
Advanced speculative caching feature present
Disabling advanced speculative caching
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0383fbf7 c1cbfbff 00000000 00000000
Intel machine check reporting enabled on CPU#0.
CPU: After generic, caps: 0383fbf7 c1cbfbff 00000000 00000000
CPU: Common caps: 0383fbf7 c1cbfbff 00000000 00000000
CPU0: AMD Athlon(TM) MP 1800+ stepping 02
per-CPU timeslice cutoff: 731.53 usecs.
task migration cache decay timeout: 10 msecs.
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Booting processor 1/1 eip 2000
Initializing CPU#1
masked ExtINT on CPU#1
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Calibrating delay loop... 3086.74 BogoMIPS
CPU: Before vendor init, caps: 0383fbff c1cbfbff 00000000, vendor = 2
Advanced speculative caching feature present
Disabling advanced speculative caching
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0383fbf7 c1cbfbff 00000000 00000000
Intel machine check reporting enabled on CPU#1.
CPU: After generic, caps: 0383fbf7 c1cbfbff 00000000 00000000
CPU: Common caps: 0383fbf7 c1cbfbff 00000000 00000000
CPU1: AMD Athlon(TM) MP 1800+ stepping 02
Total of 2 processors activated (6173.49 BogoMIPS).
ENABLING IO-APIC IRQs
Setting 2 in the phys_id_present_map
...changing IO-APIC physical APIC ID to 2 ... ok.
init IO_APIC IRQs
IO-APIC (apicid-pin) 2-0, 2-5, 2-9, 2-10, 2-11, 2-20, 2-21, 2-22, 2-23
not
connected.
..TIMER: vector=0x31 pin1=2 pin2=0
number of MP IRQ sources: 16.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................
IO APIC #2......
.... register #00: 02000000
....... : physical APIC id: 02
.... register #01: 00170011
....... : max redirection entries: 0017
....... : PRQ implemented: 0
....... : IO APIC version: 0011
.... register #02: 00000000
....... : arbitration: 00
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 000 00 1 0 0 0 0 0 0 00
01 003 03 0 0 0 0 0 1 1 39
02 003 03 0 0 0 0 0 1 1 31
03 003 03 0 0 0 0 0 1 1 41
04 003 03 0 0 0 0 0 1 1 49
05 000 00 1 0 0 0 0 0 0 00
06 003 03 0 0 0 0 0 1 1 51
07 003 03 0 0 0 0 0 1 1 59
08 003 03 0 0 0 0 0 1 1 61
09 000 00 1 0 0 0 0 0 0 00
0a 000 00 1 0 0 0 0 0 0 00
0b 000 00 1 0 0 0 0 0 0 00
0c 003 03 0 0 0 0 0 1 1 69
0d 003 03 0 0 0 0 0 1 1 71
0e 003 03 0 0 0 0 0 1 1 79
0f 003 03 0 0 0 0 0 1 1 81
10 003 03 1 1 0 1 0 1 1 89
11 003 03 1 1 0 1 0 1 1 91
12 003 03 1 1 0 1 0 1 1 99
13 003 03 1 1 0 1 0 1 1 A1
14 000 00 1 0 0 0 0 0 0 00
15 000 00 1 0 0 0 0 0 0 00
16 000 00 1 0 0 0 0 0 0 00
17 000 00 1 0 0 0 0 0 0 00
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
IRQ16 -> 0:16
IRQ17 -> 0:17
IRQ18 -> 0:18
IRQ19 -> 0:19
.................................... done.
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 1545.9771 MHz.
..... host bus clock speed is 268.8660 MHz.
cpu: 0, clocks: 2688660, slice: 896220
CPU0<T0:2688656,T1:1792432,D:4,S:896220,C:2688660>
cpu: 1, clocks: 2688660, slice: 896220
CPU1<T0:2688656,T1:896208,D:8,S:896220,C:2688660>
checking TSC synchronization across CPUs: passed.
migration_task 0 on cpu=0
migration_task 1 on cpu=1
mtrr: your CPUs had inconsistent fixed MTRR settings
mtrr: probably your BIOS does not setup all CPUs
PCI: PCI BIOS revision 2.10 entry at 0xf1f20, last bus=2
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 0: assuming transparent
PCI: Using IRQ router AMD768 [1022/7443] at 00:07.3
PCI->APIC IRQ transform: (B0,I9,P0) -> 17
PCI->APIC IRQ transform: (B1,I5,P0) -> 16
PCI->APIC IRQ transform: (B2,I0,P3) -> 19
PCI->APIC IRQ transform: (B2,I5,P0) -> 18
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
VFS: Diskquotas version dquot_6.4.0 initialized
devfs: v1.12a (20020514) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x0
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
udf: registering filesystem
ACPI: Core Subsystem version [20011018]
ACPI: Subsystem enabled
ACPI: System firmware supports S0 S1 S4 S5
Processor[0]: C0 C1
Processor[1]: C0 C1
ACPI: Power Button (FF) found
ACPI: Multiple power buttons detected, ignoring fixed-feature
ACPI: Power Button (CM) found
ACPI: Sleep Button (FF) found
parport0: PC-style at 0x378 (0x778) [PCSPP(,...)]
parport0: irq 7 detected
matroxfb: Matrox Millennium G400 MAX (AGP) detected
matroxfb: MTRR's turned on
matroxfb: 640x480x8bpp (virtual: 640x26208)
matroxfb: framebuffer at 0xF8000000, mapped to 0xe0825000, size 33554432
Console: switching to colour frame buffer device 80x30
fb0: MATROX VGA frame buffer device
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
SERIAL_PCI
enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
lp0: using parport0 (polling).
lp0: console ready
Real Time Clock Driver v1.10e
Non-volatile memory driver v1.1
amd768_rng: AMD768 system management I/O registers at 0xE400.
amd768_rng hardware driver 0.1.0 loaded
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
AMD7441: IDE controller on PCI bus 00 dev 39
AMD7441: chipset revision 4
AMD7441: not 100% native mode: will probe irqs later
AMD7441: disabling single-word DMA support (revision < C4)
ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:pio, hdd:DMA
hda: SHUTTLE, ATAPI CD/DVD-ROM drive
hdd: Pioneer DVD-ROM ATAPIModel DVD-105S 011, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: ATAPI 32X CD-ROM CD-R/RW drive, 2048kB Cache, DMA
Uniform CD-ROM driver Revision: 3.12
hdd: ATAPI DVD-ROM drive, 512kB Cache, UDMA(33)
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
via-rhine.c:v1.10-LK1.1.14 May-3-2002 Written by Donald Becker
http://www.scyld.com/network/via-rhine.html
eth0: VIA VT86C100A Rhine at 0xc400, 00:50:ba:c8:9f:e8, IRQ 18.
eth0: MII PHY found at address 8, status 0x782d advertising 05e1 Link
41e1.
Linux video capture interface: v1.00
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 439M
agpgart: Detected AMD 760MP chipset
agpgart: AGP aperture is 32M @ 0xfc000000
[drm] AGP 0.99 on AMD Irongate @ 0xfc000000 32MB
[drm] Initialized mga 3.0.2 20010321 on minor 0
SCSI subsystem driver Revision: 1.00
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.8
<Adaptec 29160 Ultra160 SCSI adapter>
aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
Vendor: IBM Model: IC35L036UWD210-0 Rev: S5BS
Type: Direct-Access ANSI SCSI revision: 03
Vendor: IBM Model: IC35L036UWD210-0 Rev: S5BS
Type: Direct-Access ANSI SCSI revision: 03
scsi0:A:0:0: Tagged Queuing enabled. Depth 253
scsi0:A:1:0: Tagged Queuing enabled. Depth 253
scsi1 : SCSI host adapter emulation for IDE ATAPI devices
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0
(scsi0:A:0): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
SCSI device sda: 71687340 512-byte hdwr sectors (36704 MB)
Partition check:
/dev/scsi/host0/bus0/target0/lun0: p1 p2 p3 p4 < p5 p6 >
(scsi0:A:1): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
SCSI device sdb: 71687340 512-byte hdwr sectors (36704 MB)
/dev/scsi/host0/bus0/target1/lun0: p1 p2 p3 p4 < p5 p6 >
cmpci: version $Revision: 5.64 $ time 17:50:35 Dec 18 2002
PCI: Enabling device 02:04.0 (0084 -> 0085)
PCI: No IRQ known for interrupt pin A of device 02:04.0. Probably buggy
MP
table.
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
hcd/ehci-hcd.c: 2002-May-07 USB 2.0 'Enhanced' Host Controller (EHCI)
Driver
hcd/ehci-hcd.c: block sizes: qh 96 qtd 96 itd 128 sitd 64
PCI: Enabling device 02:08.2 (0014 -> 0016)
PCI: No IRQ known for interrupt pin C of device 02:08.2. Probably buggy
MP
table.
hcd.c: Found HC with no IRQ. Check BIOS/PCI 02:08.2 setup!
usb-ohci.c: USB OHCI at membase 0xe2845000, IRQ 19
usb-ohci.c: usb-02:00.0, Advanced Micro Devices [AMD] AMD-768 [Opus] USB
usb.c: new USB bus registered, assigned bus number 1
usb.c: kmalloc IF c16d28c0, numif 1
usb.c: new device strings: Mfr=0, Product=2, SerialNumber=1
usb.c: USB device number 1 default language ID 0x0
Product: USB OHCI Root Hub
SerialNumber: e2845000
hub.c: USB hub found
hub.c: 4 ports detected
hub.c: standalone hub
hub.c: ganged power switching
hub.c: global over-current protection
hub.c: Port indicators are not supported
hub.c: power on to power good time: 2ms
hub.c: hub controller current requirement: 0mA
hub.c: port removable status: RRRR
hub.c: local power source is good
hub.c: no over-current condition exists
hub.c: enabling power on all ports
usb.c: hub driver claimed interface c16d28c0
usb.c: kusbd: /sbin/hotplug add 1
usb.c: kusbd policy returned 0xfffffffe
PCI: Enabling device 02:08.0 (0014 -> 0016)
PCI: No IRQ known for interrupt pin A of device 02:08.0. Probably buggy
MP
table.
usb-ohci.c: found OHCI device with no IRQ assigned. check BIOS settings!
PCI: Enabling device 02:08.1 (0014 -> 0016)
PCI: No IRQ known for interrupt pin B of device 02:08.1. Probably buggy
MP
table.
usb-ohci.c: found OHCI device with no IRQ assigned. check BIOS settings!
usb.c: registered new driver hiddev
usb.c: registered new driver hid
hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
hid-core.c: USB HID support drivers
Initializing USB Mass Storage driver...
usb.c: registered new driver usb-storage
USB Mass Storage support registered.
mice: PS/2 mouse device common for all mice
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 32768 bind 32768)
IPv4 over IPv4 tunneling driver
GRE over IPv4 tunneling driver
Linux IP multicast router 0.06 plus PIM-SM
klips_info:ipsec_init: KLIPS startup, FreeS/WAN IPSec version: 1.98b
ip_conntrack version 2.1 (4095 buckets, 32760 max) - 304 bytes per
conntrack
ip_tables: (C) 2000-2002 Netfilter core team
ipt_random match loaded
netfilter PSD loaded - (c) astaro AG
ipt_nth match loaded
ipt_ipv4options loading
ipt_IPV4OPTSSTRIP loaded
arp_tables: (C) 2002 David S. Miller
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
IPv6 v0.8 for NET4.0
IPv6 over IPv4 tunneling driver
ip6_tables: (C) 2000-2002 Netfilter core team
registering ipv6 mark target
cryptoapi: loaded
cryptoloop: loaded
cryptoapi: Registered aes-ecb (0)
cryptoapi: Registered aes-cbc (65536)
cryptoapi: Registered aes-cfb (262144)
cryptoapi: Registered blowfish-ecb (0)
cryptoapi: Registered blowfish-cbc (65536)
cryptoapi: Registered blowfish-cfb (262144)
cryptoapi: Registered cast5-ecb (0)
cryptoapi: Registered cast5-cbc (65536)
cryptoapi: Registered cast5-cfb (262144)
cryptoapi: Registered des-ecb (0)
cryptoapi: Registered des-cbc (65536)
cryptoapi: Registered des-cfb (262144)
cryptoapi: Registered des_ede3-ecb (0)
cryptoapi: Registered des_ede3-cbc (65536)
cryptoapi: Registered des_ede3-cfb (262144)
cryptoapi: Registered dfc-ecb (0)
cryptoapi: Registered dfc-cbc (65536)
cryptoapi: Registered dfc-cfb (262144)
cryptoapi: Registered idea-ecb (0)
cryptoapi: Registered idea-cbc (65536)
cryptoapi: Registered idea-cfb (262144)
cryptoapi: Registered mars-ecb (0)
cryptoapi: Registered mars-cbc (65536)
cryptoapi: Registered mars-cfb (262144)
cryptoapi: Registered rc5-ecb (0)
cryptoapi: Registered rc5-cbc (65536)
cryptoapi: Registered rc6-ecb (0)
cryptoapi: Registered rc6-cbc (65536)
cryptoapi: Registered rc6-cfb (262144)
cryptoapi: Registered serpent-ecb (0)
cryptoapi: Registered serpent-cbc (65536)
cryptoapi: Registered serpent-cfb (262144)
cryptoapi: Registered twofish-ecb (0)
cryptoapi: Registered twofish-cbc (65536)
cryptoapi: Registered twofish-cfb (262144)
MD5 Message Digest Algorithm (c) RSA Systems, Inc
cryptoapi: Registered md5 (0)
cryptoapi: Registered sha1 (0)
cramfs: wrong magic
FAT: bogus logical sector size 0
UMSDOS: msdos_read_super failed, mount aborted.
FAT: bogus logical sector size 0
FAT: bogus logical sector size 0
UDF-fs DEBUG lowlevel.c:65:udf_get_last_session: CDROMMULTISESSION not
supported: rc=-22
UDF-fs DEBUG super.c:1421:udf_read_super: Multi-session=0
UDF-fs DEBUG super.c:410:udf_vrs: Starting at sector 16 (2048 byte
sectors)
UDF-fs DEBUG super.c:1157:udf_check_valid: Failed to read byte 32768.
Assuming open disc. Skipping validity check
UDF-fs DEBUG misc.c:285:udf_read_tagged: location mismatch block 256,
tag
195051 != 256
UDF-fs DEBUG super.c:1211:udf_load_partition: No Anchor block found
UDF-fs: No partition found (1)
reiserfs: checking transaction log (device 08:03) ...
Warning, log replay starting on readonly filesystem
reiserfs: replayed 2 transactions in 1 seconds
Using r5 hash to sort names
ReiserFS version 3.6.25
VFS: Mounted root (reiserfs filesystem) readonly.
Freeing unused kernel memory: 136k freed
Adding Swap: 514072k swap-space (priority -1)
Adding Swap: 514072k swap-space (priority -2)
reiserfs: checking transaction log (device 08:13) ...
reiserfs: replayed 3 transactions in 0 seconds
Using r5 hash to sort names
ReiserFS version 3.6.25
reiserfs: checking transaction log (device 08:15) ...
reiserfs: replayed 3 transactions in 1 seconds
Using r5 hash to sort names
ReiserFS version 3.6.25
reiserfs: checking transaction log (device 08:16) ...
reiserfs: replayed 3 transactions in 1 seconds
Using r5 hash to sort names
ReiserFS version 3.6.25
reiserfs: checking transaction log (device 08:05) ...
Using r5 hash to sort names
ReiserFS version 3.6.25
reiserfs: checking transaction log (device 08:06) ...
Using r5 hash to sort names
ReiserFS version 3.6.25
eth0: Setting full-duplex based on MII #8 link partner capability of
41e1.
eth0: no IPv6 routers present
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [parisc-linux] quad tulip now not functional in 2.4.20
From: Ed Schaller @ 2002-12-18 20:27 UTC (permalink / raw)
To: Grant Grundler; +Cc: jsoe0708, Ed Schaller, parisc-linux
In-Reply-To: <20021218165813.GA17944@dsl2.external.hp.com>
[-- Attachment #1: Type: text/plain, Size: 427 bytes --]
> Like I suspected, backing out this change made add-on boards work again.
> I've reverted that change in 2.4.20-pa15 along with a traps.c change.
> Please apply by hand and try the 4-port again.
Seems to work fine. Thanks for all the help!
>>>------>
--
+-------------+-----------------------+---------------+
| Ed Schaller | Dark Mist Networking | psuedoshroom |
+-------------+-----------------------+---------------+
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [BUG] 2.5.47 - Assertion failed in fs/jbd/journal.c:415
From: Andrew Morton @ 2002-12-18 20:35 UTC (permalink / raw)
To: Robert Macaulay; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.44.0212181301480.15962-100000@ping.us.dell.com>
Robert Macaulay wrote:
>
> We were performing an IO performance test on 2.5.47. The storage we were
> writing to was a Fibre Channel array(dell 650f) via qlogic 2200 cards
> using the qlogicfc driver in the Linux kernel. There were 8 separate LUNS
> on the FC array, each of which has an ext3 filesystem on them. There are
> no partition tables on the disks(one of the disks would not accept one,
> separate issue). The ext3 filesystem was created directly on the block
> devices, /dev/sdf /dev/sdg etc. The server is a Dell Poweredge 6650, 4
> procs, 8Gig RAM. More detailed system information is appended at the
> bottom.
>
> For now, the test was 100% writing to all 8 filesystems in parallel. The
> following BUG was reported halfway through the 4th run of this test. I'm
> not sure how reproducible this is.
>
> The machine is still running. IO in progress at the time of the BUG has
> stopped in D state, New IO is stil possible though to the disks. I will
> leave the system up and running if there is any more info needed for a few
> days.
>
> I will be trying a more recent version in a few days. 2.5.47 was the
> latest kernel I could compile at the time. I've looked through the
> archives, but could not find any mention of this particular bug, so I do
> not know if it has been addressed or not. Thanks
>
> Assertion failure in journal_write_metadata_buffer() at fs/jbd/journal.c:415: "buffer_jdirty(jh2bh(jh_in))"
I can't immediately see what would cause this. There is code in
__journal_file_buffer which could have triggered this, but we should
have exclusion from that via both lock_kernel() and lock_journal().
I'll see if Stephen can spot it. I shall assume you were using
the data-ordered journalling mode.
^ permalink raw reply
* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: John Bradford @ 2002-12-18 20:39 UTC (permalink / raw)
To: Larry McVoy; +Cc: alan, lm, torvalds, davej, vonbrand, linux-kernel, akpm
In-Reply-To: <20021218114512.J7976@work.bitmover.com>
> On Wed, Dec 18, 2002 at 02:42:51PM -0500, Alan Cox wrote:
> > > On Wed, Dec 18, 2002 at 02:30:48PM -0500, Alan Cox wrote:
> > > > We've got one - its called linux-kernel.
> > >
> > > Huh? That's like saying "we don't need a bug database, we have a mailing
> > > list". That's patently wrong and so is your statement. If you want
> > > reviews you need some place to store them. A mailing list isn't storage.
> > >
> > > You'll do it however you want of course, but you are being
> > > stupid about it.
> > > Why is that?
> >
> > We've got a bug database (bugzilla), we've got a system for seeing
> > what opinion appears to be -kernel-list
>
> And exactly how is your statement different than
>
> "we have a system for seeing what bugs appear to be -kernel-list"
>
> ?
This forthcoming BK-related flamewar falls in to category 1, I.E. is
not a 2.6 feature :-)
John.
^ permalink raw reply
* Re: [Fwd: [Bug 136] New: FSID returned from statvfs always 0]
From: H. Peter Anvin @ 2002-12-18 20:18 UTC (permalink / raw)
To: Bryan Henderson; +Cc: Andrew Morton, Andries Brouwer, linux-fsdevel
In-Reply-To: <OF58D9AD29.61FD1057-ON87256C93.005990BD-88256C93.005A2605@us.ibm.com>
Bryan Henderson wrote:
>
> To have _any_ value would be an overstatement. Today's FSID (always zero)
> has no value. An FSID that works only in machines where the disks never
> move would have more value than that.
>
> But as long as we're talking about designs that solve the entire problem,
> don't forget this aspect too: A perfect FSID must be stable as the
> filesystem is moved from one disk to another while the disks stay put.
> And, more importantly, must change when you replace the contents of a disk
> with a new or different filesystem.
>
I.e. it's the UUID of the filesystem (if one exists.)
-hpa
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: H. Peter Anvin @ 2002-12-18 20:26 UTC (permalink / raw)
To: root
Cc: Terje Eggestad, Linus Torvalds, Ulrich Drepper, Matti Aarnio,
Hugh Dickins, Dave Jones, Ingo Molnar, linux-kernel
In-Reply-To: <Pine.LNX.3.95.1021218152425.806A-101000@chaos.analogic.com>
Richard B. Johnson wrote:
> The number of CPU clocks necessary to make the 'far' or
> full-pointer call by pushing the segment register, the offset,
> then issuing a 'lret' is 33 clocks on a Pentium II.
>
> longcall clocks = 46
> call clocks = 13
> actual full-pointer call clocks = 33
That's not a call, that's a jump. Comparing it to a call instruction is
meaningless.
-hpa
^ 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.