Did I miss a post from Linus on the list, or is there no posted
changelog for test13-pre1? Nothing's posted at kernel.org yet, either.
--
"Windows for Dummies? Isn't that redundant?"
On Thu, 14 Dec 2000, David Riley wrote:
> Did I miss a post from Linus on the list, or is there no posted
> changelog for test13-pre1? Nothing's posted at kernel.org yet, either.
>
I musta missed the post too... But then again I went back and looked for
it and couldnt find it so...
i'd like to know what changed, anyways :)
Kelsey Hudson [email protected]
Software Engineer
Compendium Technologies, Inc (619) 725-0771
---------------------------------------------------------------------------
Hello,
Linus didn't annnounce test13-pre1 as far as I am aware of.
Regards,
Frank
--On Thursday, December 14, 2000 12:11 PM -0800 "Dr. Kelsey Hudson"
<[email protected]> wrote:
> On Thu, 14 Dec 2000, David Riley wrote:
>
>> Did I miss a post from Linus on the list, or is there no posted
>> changelog for test13-pre1? Nothing's posted at kernel.org yet, either.
>>
>
> I musta missed the post too... But then again I went back and looked for
> it and couldnt find it so...
>
> i'd like to know what changed, anyways :)
>
> Kelsey Hudson
> [email protected] Software Engineer
> Compendium Technologies, Inc (619) 725-0771
> -------------------------------------------------------------------------
> --
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
The test13-pre1 changelog was something along the lines of "alright, I
am sick of this Makefile crap. I fixed some, clean up the rest."
;-)
--
Jeff Garzik |
Building 1024 | These are not the J's you're lookin' for.
MandrakeSoft | It's an old Jedi mind trick.
On Thu, 14 Dec 2000, Dr. Kelsey Hudson wrote:
> On Thu, 14 Dec 2000, David Riley wrote:
>
> > Did I miss a post from Linus on the list, or is there no posted
> > changelog for test13-pre1? Nothing's posted at kernel.org yet, either.
> >
>
> I musta missed the post too... But then again I went back and looked for
> it and couldnt find it so...
>
> i'd like to know what changed, anyways :)
>
Occasionally Linus will put out a 'pre' release that is not for 'public
consumption', as was the case in 2.4.0-test12pre1.
Subsequent 'pre' releases will show the the change log for test13pre1.
We just have to be patient. 8-)
--
Marty Pitts
Linux Today
http://linuxtoday.com
In article <[email protected]>,
David Riley <[email protected]> wrote:
>Did I miss a post from Linus on the list, or is there no posted
>changelog for test13-pre1? Nothing's posted at kernel.org yet, either.
The test13-pre1 changes are almost exclusively a radical Makefile
cleanup, and it's been discussed mainly on the kbuild mailing list. It
doesn't actually contain any actual _code_ changes apart from some very
minor details (one of which was the "swapoff()" fix, but I doubt
"swapoff()" not working is all that big of an issue)
I'm hoping that most of the fall-out from switching over exclusively to
the new-style Makefiles will be over in a day or two, at which point
I'll make a pre2 that is worth announcing.
Especially if we get that netfilter problem sorted out (see the other
thread about the IP fragmentation issues associated with that one), and
if we figure out why apparently some people have trouble with external
modules (at least one person has trouble with loading alsa modules).
Linus
* Linus Torvalds ([email protected]) wrote:
>
> Especially if we get that netfilter problem sorted out (see the other
> thread about the IP fragmentation issues associated with that one), and
> if we figure out why apparently some people have trouble with external
> modules (at least one person has trouble with loading alsa modules).
Any idea if these issues would cause a general slow-down of a
machine? For no apparent reason after 5 days running 2.4.0test12
everything going through my firewall (set up using iptables) I got about
100ms time added on to pings and traceroutes. I'll probably reboot the
machine tonight and see if that helps.
Stephen
> machine? For no apparent reason after 5 days running 2.4.0test12
> everything going through my firewall (set up using iptables) I got about
> 100ms time added on to pings and traceroutes. I'll probably reboot the
> machine tonight and see if that helps.
Before you do that can you see if ifconfig down, rmmod, insmod, ifconfig up
fixes it.
On Thu, 14 Dec 2000, Stephen Frost wrote:
>
> Any idea if these issues would cause a general slow-down of a
> machine? For no apparent reason after 5 days running 2.4.0test12
> everything going through my firewall (set up using iptables) I got about
> 100ms time added on to pings and traceroutes.
Probably not related to that particular bug - the netfilter issue has
apparently been around forever, and it was just some changes in IP
fragmentation that just made it show up as an oops.
A 100ms delay sounds like some interrupt shut up or similar (and then
timer handling makes it limp along).
Linus
* Alan Cox ([email protected]) wrote:
> > machine? For no apparent reason after 5 days running 2.4.0test12
> > everything going through my firewall (set up using iptables) I got about
> > 100ms time added on to pings and traceroutes. I'll probably reboot the
> > machine tonight and see if that helps.
>
> Before you do that can you see if ifconfig down, rmmod, insmod, ifconfig up
> fixes it.
This go around I compiled everything into the kernel, actually.
If it would be useful I can compile them as modules reboot and then see
what happens...
===# cat /proc/modules
ppp_deflate 39200 0 (autoclean)
bsd_comp 4160 0 (autoclean)
ppp_async 6512 1 (autoclean)
ppp_generic 15232 3 (autoclean) [ppp_deflate bsd_comp ppp_async]
slhc 4528 0 (autoclean) [ppp_generic]
===#
I can say that cleaning out all my firewall rules and adding them
back didn't change behaviour any. Also, I'm sure that this was not happening
until today or maybe yesterday. Earlier in the week the machine was doing
fine and I was getting reasonable response times. Now, out *every* interface,
I get something close to 100ms additional time. Also of note, traceroutes
appear to be more lagged than pings, for what that's worth (traceroute using
udp, ping using icmp, dunno if it makes a difference).
Stephen
On Thu, 14 Dec 2000, Stephen Frost wrote:
>
> This go around I compiled everything into the kernel, actually.
> If it would be useful I can compile them as modules reboot and then see
> what happens...
Even when compiled into the kernel, you might just ifdown/ifup the device.
That will re-initialize most of the driver state.
Is this ppp over serial.c, or what?
Linus
* Linus Torvalds ([email protected]) wrote:
>
>
> On Thu, 14 Dec 2000, Stephen Frost wrote:
> >
> > Any idea if these issues would cause a general slow-down of a
> > machine? For no apparent reason after 5 days running 2.4.0test12
> > everything going through my firewall (set up using iptables) I got about
> > 100ms time added on to pings and traceroutes.
>
> Probably not related to that particular bug - the netfilter issue has
> apparently been around forever, and it was just some changes in IP
> fragmentation that just made it show up as an oops.
>
> A 100ms delay sounds like some interrupt shut up or similar (and then
> timer handling makes it limp along).
Hmm, it's happening on all interfaces. No oops or anything in
the logs/dmesg. I can check console when I get home, but I doubt there's
anything of interest. All cards are 3com 3c905's.
Does this info help any?
===# cat /proc/interrupts
CPU0 CPU1
0: 29170703 23315160 IO-APIC-edge timer
1: 2 0 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
3: 258815 247131 IO-APIC-edge serial
4: 101 120 IO-APIC-edge serial
5: 1748096 1692143 IO-APIC-level usb-uhci, eth0
8: 1 0 IO-APIC-edge rtc
10: 1199227 1146776 IO-APIC-level eth2
12: 2367239 2389531 IO-APIC-level eth1
14: 210804 193050 IO-APIC-edge ide0
15: 7052 6391 IO-APIC-edge ide1
NMI: 52509191 52509191
LOC: 52472090 52472489
ERR: 0
===# sleep 10
===# cat /proc/interrupts
CPU0 CPU1
0: 29171536 23315741 IO-APIC-edge timer
1: 2 0 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
3: 258818 247134 IO-APIC-edge serial
4: 101 120 IO-APIC-edge serial
5: 1748295 1692372 IO-APIC-level usb-uhci, eth0
8: 1 0 IO-APIC-edge rtc
10: 1199230 1146777 IO-APIC-level eth2
12: 2367244 2389534 IO-APIC-level eth1
14: 210833 193050 IO-APIC-edge ide0
15: 7052 6391 IO-APIC-edge ide1
NMI: 52510605 52510605
LOC: 52473504 52473902
ERR: 0
===#
Boot log:
--------
Linux version 2.4.0-test12 (root@whitegryphon) (gcc version 2.95.2 20000220 (Debian GNU/Linux)) #1 SMP Wed Dec 6 01:53:29 EST 2000
BIOS-provided physical RAM map:
BIOS-e820: 00000000000a0000 @ 0000000000000000 (usable)
BIOS-e820: 0000000000010000 @ 00000000000f0000 (reserved)
BIOS-e820: 000000000fefd000 @ 0000000000100000 (usable)
BIOS-e820: 0000000000002000 @ 000000000fffd000 (ACPI data)
BIOS-e820: 0000000000001000 @ 000000000ffff000 (ACPI NVS)
BIOS-e820: 0000000000001000 @ 00000000fec00000 (reserved)
BIOS-e820: 0000000000001000 @ 00000000fee00000 (reserved)
BIOS-e820: 0000000000010000 @ 00000000ffff0000 (reserved)
Scan SMP from c0000000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f0000 for 65536 bytes.
found SMP MP-table at 000f6e80
hm, page 000f6000 reserved twice.
hm, page 000f7000 reserved twice.
hm, page 000f6000 reserved twice.
hm, page 000f7000 reserved twice.
On node 0 totalpages: 65533
zone(0): 4096 pages.
zone(1): 61437 pages.
zone(2): 0 pages.
Intel MultiProcessor Specification v1.1
Virtual Wire compatibility mode.
OEM ID: OEM00000 Product ID: PROD00000000 APIC at: 0xFEE00000
Processor #1 Pentium(tm) Pro APIC version 17
Floating point unit present.
Machine Exception supported.
64 bit compare & exchange supported.
Internal APIC present.
SEP present.
MTRR present.
PGE present.
MCA present.
CMOV present.
PAT present.
PSE present.
MMX present.
FXSR present.
Bootup CPU
Processor #0 Pentium(tm) Pro APIC version 17
Floating point unit present.
Machine Exception supported.
64 bit compare & exchange supported.
Internal APIC present.
SEP present.
MTRR present.
PGE present.
MCA present.
CMOV present.
PAT present.
PSE present.
MMX present.
FXSR present.
Bus #0 is PCI
Bus #1 is ISA
I/O APIC #2 Version 17 at 0xFEC00000.
Int: type 3, pol 0, trig 0, bus 1, IRQ 00, APIC ID 2, APIC INT 00
Int: type 0, pol 0, trig 0, bus 1, IRQ 01, APIC ID 2, APIC INT 01
Int: type 0, pol 0, trig 0, bus 1, IRQ 00, APIC ID 2, APIC INT 02
Int: type 0, pol 0, trig 0, bus 1, IRQ 03, APIC ID 2, APIC INT 03
Int: type 0, pol 0, trig 0, bus 1, IRQ 04, APIC ID 2, APIC INT 04
Int: type 0, pol 0, trig 0, bus 1, IRQ 06, APIC ID 2, APIC INT 06
Int: type 0, pol 0, trig 0, bus 1, IRQ 07, APIC ID 2, APIC INT 07
Int: type 0, pol 0, trig 0, bus 1, IRQ 08, APIC ID 2, APIC INT 08
Int: type 0, pol 0, trig 0, bus 1, IRQ 09, APIC ID 2, APIC INT 09
Int: type 0, pol 0, trig 0, bus 1, IRQ 0e, APIC ID 2, APIC INT 0e
Int: type 0, pol 0, trig 0, bus 1, IRQ 0f, APIC ID 2, APIC INT 0f
Int: type 0, pol 3, trig 3, bus 1, IRQ 0b, APIC ID 2, APIC INT 10
Int: type 0, pol 3, trig 3, bus 1, IRQ 0a, APIC ID 2, APIC INT 11
Int: type 0, pol 3, trig 3, bus 1, IRQ 0c, APIC ID 2, APIC INT 12
Int: type 0, pol 3, trig 3, bus 1, IRQ 05, APIC ID 2, APIC INT 13
Lint: type 3, pol 1, trig 1, bus 1, IRQ 00, APIC ID ff, APIC LINT 00
Lint: type 1, pol 1, trig 1, bus 1, IRQ 00, APIC ID ff, APIC LINT 01
Processors: 2
mapped APIC to ffffe000 (fee00000)
mapped IOAPIC to ffffd000 (fec00000)
Kernel command line: auto BOOT_IMAGE=Linux ro root=301 BOOT_FILE=/vmlinuz console=tty0 console=ttyS0
Initializing CPU#0
Detected 300.688 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 599.65 BogoMIPS
Memory: 255312k/262132k available (1468k kernel code, 6436k reserved, 96k data, 188k init, 0k highmem)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
CPU: Before vendor init, caps: 0183fbff 00000000 00000000, vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 128K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After vendor init, caps: 0183fbff 00000000 00000000 00000000
CPU: After generic, caps: 0183fbff 00000000 00000000 00000000
CPU: Common caps: 0183fbff 00000000 00000000 00000000
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
CPU: Before vendor init, caps: 0183fbff 00000000 00000000, vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 128K
Intel machine check reporting enabled on CPU#0.
CPU: After vendor init, caps: 0183fbff 00000000 00000000 00000000
CPU: After generic, caps: 0183fbff 00000000 00000000 00000000
CPU: Common caps: 0183fbff 00000000 00000000 00000000
CPU0: Intel Celeron (Mendocino) stepping 00
per-CPU timeslice cutoff: 365.75 usecs.
Getting VERSION: 40011
Getting VERSION: 40011
Getting ID: 1000000
Getting ID: e000000
Getting LVT0: 8700
Getting LVT1: 400
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
CPU present map: 3
Booting processor 1/0 eip 2000
Setting warm reset code and vector.
1.
2.
3.
Asserting INIT.
Waiting for send to finish...
+Deasserting INIT.
Waiting for send to finish...
+#startup loops: 2.
Sending STARTUP #1.
After apic_write.
Startup point 1.
Initializing CPU#1
Waiting for send to finish...
CPU#1 (phys ID: 0) waiting for CALLOUT
+Sending STARTUP #2.
After apic_write.
Startup point 1.
Waiting for send to finish...
+After Startup.
Before Callout 1.
After Callout 1.
CALLIN, before setup_local_APIC().
masked ExtINT on CPU#1
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Calibrating delay loop... 601.29 BogoMIPS
Stack at about cfff3fbc
CPU: Before vendor init, caps: 0183fbff 00000000 00000000, vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 128K
Intel machine check reporting enabled on CPU#1.
CPU: After vendor init, caps: 0183fbff 00000000 00000000 00000000
CPU: After generic, caps: 0183fbff 00000000 00000000 00000000
CPU: Common caps: 0183fbff 00000000 00000000 00000000
OK.
CPU1: Intel Celeron (Mendocino) stepping 00
CPU has booted.
Before bogomips.
Total of 2 processors activated (1200.95 BogoMIPS).
Before bogocount - setting activated=1.
Boot done.
ENABLING IO-APIC IRQs
...changing IO-APIC physical APIC ID to 2 ... ok.
Synchronizing Arb IDs.
..TIMER: vector=49 pin1=2 pin2=0
activating NMI Watchdog ... done.
testing the IO APIC.......................
.................................... done.
calibrating APIC timer ...
..... CPU clock speed is 300.7153 MHz.
..... host bus clock speed is 66.8254 MHz.
cpu: 0, clocks: 668254, slice: 222751
CPU0<T0:668240,T1:445488,D:1,S:222751,C:668254>
cpu: 1, clocks: 668254, slice: 222751
CPU1<T0:668240,T1:222736,D:2,S:222751,C:668254>
checking TSC synchronization across CPUs: passed.
Setting commenced=1, go go go
PCI: PCI BIOS revision 2.10 entry at 0xf0730, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 0: assuming transparent
Unknown bridge resource 1: assuming transparent
Unknown bridge resource 2: assuming transparent
PCI: Using IRQ router PIIX [8086/7110] at 00:04.0
Limiting direct PCI/PCI transfers.
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd v1.8
Detected PS/2 Mouse Port.
pty: 256 Unix98 ptys configured
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev 21
PIIX4: chipset revision 1
PIIX4: not 100%% native mode: will probe irqs later
ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:pio
hda: WDC AC24300L, ATA DISK drive
hdc: FUJITSU M1638TAU, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 8421840 sectors (4312 MB) w/256KiB Cache, CHS=524/255/63, (U)DMA
hdc: 5023680 sectors (2572 MB) w/128KiB Cache, CHS=4983/16/63, DMA
Partition check:
hda: hda1 hda2 hda3 hda4 < hda5 hda6 >
hdc: [PTBL] [622/128/63] hdc1 hdc2 hdc3 hdc4 < hdc5 hdc6 >
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
early initialization of device teql0 is deferred
Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
Real Time Clock Driver v1.10d
3c59x.c:LK1.1.11 13 Nov 2000 Donald Becker and others. http://www.scyld.com/network/vortex.html $Revision: 1.102.2.46 $
See Documentation/networking/vortex.txt
eth0: 3Com PCI 3c905 Boomerang 100baseTx at 0xd000, 00:60:97:7f:65:89, IRQ 5
8K word-wide RAM 3:5 Rx:Tx split, autoselect/MII interface.
MII transceiver found at address 24, status 786d.
Enabling bus-master transmits and whole-frame receives.
eth1: 3Com PCI 3c905 Boomerang 100baseTx at 0xb800, 00:60:97:80:75:bb, IRQ 12
8K word-wide RAM 3:5 Rx:Tx split, autoselect/MII interface.
MII transceiver found at address 24, status 786f.
Enabling bus-master transmits and whole-frame receives.
eth2: 3Com PCI 3c905B Cyclone 100baseTx at 0xb400, 00:10:5a:01:f6:ec, IRQ 10
8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface.
MII transceiver found at address 24, status 782d.
Enabling bus-master transmits and whole-frame receives.
Linux PCMCIA Card Services 3.1.22
options: [pci] [cardbus]
usb.c: registered new driver hub
uhci.c: USB UHCI at I/O 0xd400, IRQ 5
uhci.c: detected 2 ports
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
ip_conntrack (2047 buckets, 16376 max)
ip_tables: (c)2000 Netfilter core team
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
ds: no socket drivers loaded!
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 188k freed
Adding Swap: 128516k swap-space (priority -1)
eth0: first available media type: MII
eth1: first available media type: MII
eth2: using NWAY autonegotiation
--------
Stephen
* Linus Torvalds ([email protected]) wrote:
>
>
> On Thu, 14 Dec 2000, Stephen Frost wrote:
> >
> > This go around I compiled everything into the kernel, actually.
> > If it would be useful I can compile them as modules reboot and then see
> > what happens...
>
> Even when compiled into the kernel, you might just ifdown/ifup the device.
> That will re-initialize most of the driver state.
I'll give that a shot... ifdown -a/ifup -a, no change in behaviour.
> Is this ppp over serial.c, or what?
There is a ppp connection, but the slowdown is on *all* interfaces,
of which there are a total of 4; eth0, eth1, eth2, ppp0.
Stephen
On Thu, 14 Dec 2000, Stephen Frost wrote:
> * Linus Torvalds ([email protected]) wrote:
> >
> > A 100ms delay sounds like some interrupt shut up or similar (and then
> > timer handling makes it limp along).
>
> Hmm, it's happening on all interfaces.
Ok, never mind me then. It's not an interrupt getting masked, the
likelihood of three different interrupts having trouble is basically zero
(it would be even smaller if it wasn't for the fact that they are all the
same typ eof device and are all handled by the same driver - but there
shouldn't be any shared data even so).
> No oops or anything in
> the logs/dmesg. I can check console when I get home, but I doubt there's
> anything of interest.
If dmesg doesn't say anything, then the console will say even less.
Linus
On Thu, 14 Dec 2000, Linus Torvalds wrote:
> On Thu, 14 Dec 2000, Stephen Frost wrote:
> >
> > Any idea if these issues would cause a general slow-down of a
> > machine? For no apparent reason after 5 days running 2.4.0test12
> > everything going through my firewall (set up using iptables) I got about
> > 100ms time added on to pings and traceroutes.
>
> Probably not related to that particular bug - the netfilter issue has
> apparently been around forever, and it was just some changes in IP
> fragmentation that just made it show up as an oops.
>
> A 100ms delay sounds like some interrupt shut up or similar (and then
> timer handling makes it limp along).
Possibly related datapoint: after several days of uptime, my
2.4.0-test10pre? machine went into some sort of slow mode after coming
back from suspend (and doing an /etc/init.d/networking restart). Symptoms
seemed to be extra second or so setting up a TCP connection. Ping, etc.,
appeared to work just fine, no packet loss apparent, bandwidth looked good
too. Sadly I had to do actual work that required zippy web access, so I
rebooted rather than doing a thorough diagnostic. This is a VAIO with
compiled in eepro100, no special networking options.
Oh, and btw, test12-pre7 seems to have broken my USB camera, which worked
with the aforementioned kernel. My build of gphoto2 downloads images via
usbdevfs (ugh) and quietly created a bunch of .jpgs that were almost
entirely 0s..
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
On 14 Dec 2000, Linus Torvalds wrote:
> if we figure out why apparently some people have trouble with external
> modules (at least one person has trouble with loading alsa modules).
I cannot load the xircom_tulip_cb module using the latest modutils 2.3.22.
I think it's a modutils problem.
Pau
* Oliver Xymoron ([email protected]) wrote:
> On Thu, 14 Dec 2000, Linus Torvalds wrote:
>
> > A 100ms delay sounds like some interrupt shut up or similar (and then
> > timer handling makes it limp along).
>
> Possibly related datapoint: after several days of uptime, my
> 2.4.0-test10pre? machine went into some sort of slow mode after coming
> back from suspend (and doing an /etc/init.d/networking restart). Symptoms
> seemed to be extra second or so setting up a TCP connection. Ping, etc.,
> appeared to work just fine, no packet loss apparent, bandwidth looked good
> too. Sadly I had to do actual work that required zippy web access, so I
> rebooted rather than doing a thorough diagnostic. This is a VAIO with
> compiled in eepro100, no special networking options.
Actually, I figured out what it was and I feel kind of stupid, and
suprised. I knew I should have tried rebooting before complaining. It
turns out it actually was something in my firewall rules, it appears that
for every logged packet there is something along the lines of a 100ms
delay that gets added on.
Not sure if that is something that could be easily fixed or not, or
perhaps I'm doing something wrong, but that seems unlikely since all I
changed was if it jumped to the LOG chain or not.
Stephen
On Fri, 15 Dec 2000, Stephen Frost wrote:
> * Oliver Xymoron ([email protected]) wrote:
> > On Thu, 14 Dec 2000, Linus Torvalds wrote:
> >
> > > A 100ms delay sounds like some interrupt shut up or similar (and then
> > > timer handling makes it limp along).
> >
> > Possibly related datapoint: after several days of uptime, my
> > 2.4.0-test10pre? machine went into some sort of slow mode after coming
> > back from suspend (and doing an /etc/init.d/networking restart). Symptoms
> > seemed to be extra second or so setting up a TCP connection. Ping, etc.,
> > appeared to work just fine, no packet loss apparent, bandwidth looked good
> > too. Sadly I had to do actual work that required zippy web access, so I
> > rebooted rather than doing a thorough diagnostic. This is a VAIO with
> > compiled in eepro100, no special networking options.
>
> Actually, I figured out what it was and I feel kind of stupid, and
> suprised. I knew I should have tried rebooting before complaining. It
> turns out it actually was something in my firewall rules, it appears that
> for every logged packet there is something along the lines of a 100ms
> delay that gets added on.
Hmmm, that's seems rather extreme - does it have to wait for klogd to get
scheduled before it proceeds? I would expect the filtering to be down in
the noise except at fairly high loads.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
On Thu, Dec 14, 2000 at 03:31:54PM -0800, Linus Torvalds wrote:
> I'm hoping that most of the fall-out from switching over exclusively to
> the new-style Makefiles will be over in a day or two, at which point
> I'll make a pre2 that is worth announcing.
Does this mean other arches will have a chance to sync in 2.4.0-test13?
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
On Fri, 15 Dec 2000, Tom Rini wrote:
> On Thu, Dec 14, 2000 at 03:31:54PM -0800, Linus Torvalds wrote:
>
> > I'm hoping that most of the fall-out from switching over exclusively to
> > the new-style Makefiles will be over in a day or two, at which point
> > I'll make a pre2 that is worth announcing.
>
> Does this mean other arches will have a chance to sync in 2.4.0-test13?
Sparc is already sync'ed in my tree, and I'd love for other architectures
to synch up too (but if it takes a while it's not a major disaster - I
actually much prefer bugs that cause build failures over other kinds of
bugs ;).
Linus
> Sparc is already sync'ed in my tree, and I'd love for other architectures
> to synch up too (but if it takes a while it's not a major disaster - I
> actually much prefer bugs that cause build failures over other kinds of
> bugs ;).
So you want drivers/gsc again ? I assumed you dropped it as you didnt want
more port code.
On Fri, 15 Dec 2000, Alan Cox wrote:
> > Sparc is already sync'ed in my tree, and I'd love for other architectures
> > to synch up too (but if it takes a while it's not a major disaster - I
> > actually much prefer bugs that cause build failures over other kinds of
> > bugs ;).
>
> So you want drivers/gsc again ? I assumed you dropped it as you didnt want
> more port code.
I really dropped it because I was getting too many patches, and I don't
realistically think it's a 2.4.0 issue (neither do you, I bet), so I
decided that it's not worth it.
By "I'd love for other architectures to synch up" I really only meant the
Makefile issue - but the hppa thing is pretty much moot as not all of the
code has made it into the kernel yet, so even if the Makefiles were
updated it still wouldn't be "ready".
(Looking at the parisc makefiles the changes to update them to new-style
looks rather small. Not a big issue).
Linus
On Fri, 15 Dec 2000, Linus Torvalds wrote:
> I really dropped it because I was getting too many patches, and I don't
> realistically think it's a 2.4.0 issue (neither do you, I bet), so I
> decided that it's not worth it.
Umm... Linus, how about a bunch of fixes I've sent to you several times
during test12-pre? I can resend them, but I would really, really like to
hear explicit OK for such resend - if you already have a full mailbox
with 2-3 copies of that set sitting there... ;-/
Cheers,
Al
> I really dropped it because I was getting too many patches, and I don't
> realistically think it's a 2.4.0 issue (neither do you, I bet), so I
> decided that it's not worth it.
Ok. Not a problem. I'll leave it until post 2.4.0