test13-pre1 changelog

test13-pre1 changelog

[David Riley]

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?"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre1 changelog

[Dr. Kelsey Hudson]

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                                           khudson@ctica.com 
 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre1 changelog

[Frank Davis]

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" 
<kernel@blackhole.compendium-tech.com> 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
>  khudson@ctica.com  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 majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre1 changelog

[Jeff Garzik]

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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre1 changelog

[Marty Pitts]

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre1 changelog

[Linus Torvalds]

In article <3A392852.B9B64C7F@the-rileys.net>,
David Riley  <oscar@the-rileys.net> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre1 changelog

[Stephen Frost]

[-- Attachment #1: Type: text/plain, Size: 682 bytes --]

* Linus Torvalds (torvalds@transmeta.com) 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

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: test13-pre1 changelog

[Alan Cox]

> 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. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre1 changelog

[Stephen Frost]

[-- Attachment #1: Type: text/plain, Size: 1408 bytes --]

* Alan Cox (alan@lxorguk.ukuu.org.uk) 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

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: test13-pre1 changelog

[Linus Torvalds]

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre1 changelog

[Stephen Frost]

[-- Attachment #1: Type: text/plain, Size: 669 bytes --]

* Linus Torvalds (torvalds@transmeta.com) 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

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: test13-pre1 changelog

[Linus Torvalds]

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre1 changelog

[Stephen Frost]

[-- Attachment #1: Type: text/plain, Size: 12739 bytes --]

* Linus Torvalds (torvalds@transmeta.com) 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

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: test13-pre1 changelog

[Linus Torvalds]

On Thu, 14 Dec 2000, Stephen Frost wrote:

> * Linus Torvalds (torvalds@transmeta.com) 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre1 changelog

[Oliver Xymoron]

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.."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre1 changelog

[Stephen Frost]

[-- Attachment #1: Type: text/plain, Size: 1315 bytes --]

* Oliver Xymoron (oxymoron@waste.org) 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

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: test13-pre1 changelog

[Oliver Xymoron]

On Fri, 15 Dec 2000, Stephen Frost wrote:

> * Oliver Xymoron (oxymoron@waste.org) 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.."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre1 changelog

[Pau]

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre1 changelog

[Tom Rini]

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/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre1 changelog

[Linus Torvalds]

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre1 changelog

[Alan Cox]

> 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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre1 changelog

[Linus Torvalds]

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre1 changelog

[Alexander Viro]

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre1 changelog

[Alan Cox]

> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/