Re: Specialix SX cards not detected in kernels >=2.6.20
Jiri Slaby <[EMAIL PROTECTED]> writes: > In switched ids. Could you try the patch below? Thanks. That fixed the problem - the card works again now. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Specialix SX cards not detected in kernels =2.6.20
Jiri Slaby [EMAIL PROTECTED] writes: In switched ids. Could you try the patch below? Thanks. That fixed the problem - the card works again now. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Specialix SX cards not detected in kernels >=2.6.20
There were multiple changes to the char/sx.c driver in kernel 2.6.20. In kernels 2.6.19 and earlier, the SX multiport serial card works OK, but in 2.6.20 and later the driver does not seemt to detect the presence of the card. I have enabled sx_debug=-1 and added some printk statements to try and detect why the card is not detected. These show that sx_init is entered and within that function the call to pci_register_driver returns 0. I do not see any other routines in the driver being entered either at startup (when the module is loaded, which indicates that the system recognises the PCI ID) or when running 'modprobe sx'. In particular, sx_pci_probe() is never entered. lspci -vv for the card 10:01.0 Communication controller: Specialix Research Ltd. PCI_9050 Subsystem: Specialix Research Ltd. Unknown device 0300 Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Specialix SX cards not detected in kernels =2.6.20
There were multiple changes to the char/sx.c driver in kernel 2.6.20. In kernels 2.6.19 and earlier, the SX multiport serial card works OK, but in 2.6.20 and later the driver does not seemt to detect the presence of the card. I have enabled sx_debug=-1 and added some printk statements to try and detect why the card is not detected. These show that sx_init is entered and within that function the call to pci_register_driver returns 0. I do not see any other routines in the driver being entered either at startup (when the module is loaded, which indicates that the system recognises the PCI ID) or when running 'modprobe sx'. In particular, sx_pci_probe() is never entered. lspci -vv for the card 10:01.0 Communication controller: Specialix Research Ltd. PCI_9050 Subsystem: Specialix Research Ltd. Unknown device 0300 Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Interrupt: pin A routed to IRQ 11 Region 0: Memory at df2ffc00 (32-bit, non-prefetchable) [size=128] Region 1: I/O ports at 9c80 [size=128] Region 2: Memory at df20 (32-bit, non-prefetchable) [size=512K] Region 3: Memory at df28 (32-bit, non-prefetchable) [size=256K] I have enabled CONFIG_PCI_DEBUG and see the following:- PCI: Probing PCI hardware (bus 00) ... PCI: Scanning bus :10 PCI: Found :10:01.0 [11cb/2000] 000780 00 PCI: Calling quirk c0362041 for :10:01.0 ... PCI: Calling quirk c027a199 for :10:01.0 PCI: Calling quirk c033cb9e for :10:01.0 Where should I look for and how should I obtain further debug to determine where the problem lies? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Daniel Hazelton <[EMAIL PROTECTED]> writes: > The second: > I buy a DSL modem. Until I want to actually connect to the internet it can > have whatever settings I want it to have. The second I want to connect to the > internet it has to be configured the way that the ISP wants. But only those configurations which enable it to work, such as the modulation type, PPPOE/PPPOA, VPI/VCI, PPP username and password etc. You still have control over the rest of the configuration such as NAT/No NAT, LAN IP address(es), firewall, MTU, QoS, etc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Daniel Hazelton [EMAIL PROTECTED] writes: The second: I buy a DSL modem. Until I want to actually connect to the internet it can have whatever settings I want it to have. The second I want to connect to the internet it has to be configured the way that the ISP wants. But only those configurations which enable it to work, such as the modulation type, PPPOE/PPPOA, VPI/VCI, PPP username and password etc. You still have control over the rest of the configuration such as NAT/No NAT, LAN IP address(es), firewall, MTU, QoS, etc. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Versioning file system
"Jeffrey V. Merkey" <[EMAIL PROTECTED]> writes: > This already exists -- it just not open sourced, and you could spend > years trying to create it. Trust me, once you start dealing with the > distributed issues with this, its gets very complex. I am not meaning > to discourage you, but there are patents already filed on this on > Linux.So you need to consider these as well, and there are several > folks who are already doing this or have done it. If it goes into > Microsoft endorsed cross licensed Linuxes It may be ok (Vertias sold > this capability to Microsoft already, about 12 patents there to worry > over). There's also another patent filed as well. It's a noble > effort to do a free version, but be aware there's some big guns with > patents out there already, not to mention doing this is complex beyond > belief. Would such patents still be valid? He does not seem to be describing anything that the ICL VME/B operating system did not do in the 1970s, so any applicable patents should have eithe expired by now or be invalidated by prior art. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Versioning file system
Jeffrey V. Merkey [EMAIL PROTECTED] writes: This already exists -- it just not open sourced, and you could spend years trying to create it. Trust me, once you start dealing with the distributed issues with this, its gets very complex. I am not meaning to discourage you, but there are patents already filed on this on Linux.So you need to consider these as well, and there are several folks who are already doing this or have done it. If it goes into Microsoft endorsed cross licensed Linuxes It may be ok (Vertias sold this capability to Microsoft already, about 12 patents there to worry over). There's also another patent filed as well. It's a noble effort to do a free version, but be aware there's some big guns with patents out there already, not to mention doing this is complex beyond belief. Would such patents still be valid? He does not seem to be describing anything that the ICL VME/B operating system did not do in the 1970s, so any applicable patents should have eithe expired by now or be invalidated by prior art. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Uncle Sam Wants YOU!
"Jim Roland" <[EMAIL PROTECTED]> writes: > What some people don't realize is that Microsoft *DID* do Unix a long time > ago, they were even into OS/2 Development. :-) And they annoyed not just a few application vendors when just a few months after giving the message "Go with OS/2, it is the way forward", they abandoned it in favour of NT. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Uncle Sam Wants YOU!
Jim Roland [EMAIL PROTECTED] writes: What some people don't realize is that Microsoft *DID* do Unix a long time ago, they were even into OS/2 Development. :-) And they annoyed not just a few application vendors when just a few months after giving the message Go with OS/2, it is the way forward, they abandoned it in favour of NT. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ECN is on!
Matti Aarnio <[EMAIL PROTECTED]> writes: > ... and immediately I have been able to verify a bunch of > domains/servers which won't get thru when incoming connection > has ECN. As a matter of interest, are you also noting how many actually negotiate ECN rather than simply responding with a "plain" SYN ACK? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ECN is on!
Matti Aarnio [EMAIL PROTECTED] writes: ... and immediately I have been able to verify a bunch of domains/servers which won't get thru when incoming connection has ECN. As a matter of interest, are you also noting how many actually negotiate ECN rather than simply responding with a plain SYN ACK? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: traceroute breaks with 2.4.4
"Mohammad A. Haque" <[EMAIL PROTECTED]> writes: > Traceroute is working fine here. You sure you didn't inadvertantly turn > on ECN w/o knowing it? Will ECN have any effect on Traceroute? Does ECN not only affect TCP connections? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: traceroute breaks with 2.4.4
Mohammad A. Haque [EMAIL PROTECTED] writes: Traceroute is working fine here. You sure you didn't inadvertantly turn on ECN w/o knowing it? Will ECN have any effect on Traceroute? Does ECN not only affect TCP connections? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: goodbye
Matti Aarnio <[EMAIL PROTECTED]> writes: > I just verified this particular aspect of VGER's MTA > configurations. It has been unmodified since 21-Mar-2000, > that is, over a year... On the subject of vger configuration, the FAQ states that vger "will" start using ECN as of 22 Feb 2001. This does not seem to have happened yet. Has this change been cancelled or merely postponed? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: goodbye
Matti Aarnio [EMAIL PROTECTED] writes: I just verified this particular aspect of VGER's MTA configurations. It has been unmodified since 21-Mar-2000, that is, over a year... On the subject of vger configuration, the FAQ states that vger "will" start using ECN as of 22 Feb 2001. This does not seem to have happened yet. Has this change been cancelled or merely postponed? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft begining to open source Windows 2000?
"Mohammad A. Haque" <[EMAIL PROTECTED]> writes: > making a patch means you've modfied the source which you are not allowed > to do. The most you can do is report the bug through normal channels > (you dont even have priority in reporting bugs since you have the code). Does making a patch necessarily require modifying the source code? Back in my days as a mainframe systems programmer (ICL VME/B), most OS patches were made to the binary image, either in the file or to the loaded virtual memory image. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft begining to open source Windows 2000?
"Mohammad A. Haque" [EMAIL PROTECTED] writes: making a patch means you've modfied the source which you are not allowed to do. The most you can do is report the bug through normal channels (you dont even have priority in reporting bugs since you have the code). Does making a patch necessarily require modifying the source code? Back in my days as a mainframe systems programmer (ICL VME/B), most OS patches were made to the binary image, either in the file or to the loaded virtual memory image. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ECN for servers ?
"H. Peter Anvin" <[EMAIL PROTECTED]> writes: > Con: people behind broken firewalls can't connect. Are you sure that is correct? "Servers" normally listen for incoming connections from clients rather than establish them[1]. So, if the server implements ECN then it will respond appropriately to incoming SYN packets irrespective of whether the ECN bits are set. People, who use ECN, who are behind a broken firewall will have problems connecting irrespective of whether or not the server implements ECN. [1] Passive FTP being an exception. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ECN for servers ?
"H. Peter Anvin" [EMAIL PROTECTED] writes: Con: people behind broken firewalls can't connect. Are you sure that is correct? "Servers" normally listen for incoming connections from clients rather than establish them[1]. So, if the server implements ECN then it will respond appropriately to incoming SYN packets irrespective of whether the ECN bits are set. People, who use ECN, who are behind a broken firewall will have problems connecting irrespective of whether or not the server implements ECN. [1] Passive FTP being an exception. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
Keith Owens <[EMAIL PROTECTED]> writes: > This has all been thrashed out before. Read the threads > > http://www.mail-archive.com/linux-kernel@vger.rutgers.edu/2000-month-07/msg04096.html > http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg18256.html I don't think that these address my question. I was asking about when building (upgrading) glibc from source. I believe that the glibc headers are "derived" from the kernel against which it is built. So, irrespective of what the glibc maintainers do, would it be advisable for the user to remove the symlinks and copy the directories from the kernel tree and into /usr/include? - 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/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
Keith Owens <[EMAIL PROTECTED]> writes: > Basically, that symlink should not be a symlink. It's a symlink for > historical reasons, none of them very good any more (and haven't been > for a long time), and it's a disaster unless you want to be a C > library developer. Which not very many people want to be. > > The fact is, that the header files should match the library you link > against, not the kernel you run on." So what is your advice? Would the "correct" action be to take a snapshot of the appropriate kernel directories against which glibc is built? (ie to copy the directories (or those files needed) to /usr/include/asm and /usr/include/linux) On the other hand, if you are building "system level" tools (eg which communicate with device drivers directly using IOCTLs) you may need to use the kernel header files, in which case I suppose you should include them from the kernel source tree not /usr/include. In both case, I think the problem is not so much in code which you write yourself (where you control include paths etc) but in building 3rd party applications which may not have used the "correct" include paths and therefore will not build "out of the box". - 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/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
Keith Owens [EMAIL PROTECTED] writes: Basically, that symlink should not be a symlink. It's a symlink for historical reasons, none of them very good any more (and haven't been for a long time), and it's a disaster unless you want to be a C library developer. Which not very many people want to be. The fact is, that the header files should match the library you link against, not the kernel you run on." So what is your advice? Would the "correct" action be to take a snapshot of the appropriate kernel directories against which glibc is built? (ie to copy the directories (or those files needed) to /usr/include/asm and /usr/include/linux) On the other hand, if you are building "system level" tools (eg which communicate with device drivers directly using IOCTLs) you may need to use the kernel header files, in which case I suppose you should include them from the kernel source tree not /usr/include. In both case, I think the problem is not so much in code which you write yourself (where you control include paths etc) but in building 3rd party applications which may not have used the "correct" include paths and therefore will not build "out of the box". - 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/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
Keith Owens [EMAIL PROTECTED] writes: This has all been thrashed out before. Read the threads http://www.mail-archive.com/linux-kernel@vger.rutgers.edu/2000-month-07/msg04096.html http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg18256.html I don't think that these address my question. I was asking about when building (upgrading) glibc from source. I believe that the glibc headers are "derived" from the kernel against which it is built. So, irrespective of what the glibc maintainers do, would it be advisable for the user to remove the symlinks and copy the directories from the kernel tree and into /usr/include? - 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/
Re: ECN: Clearing the air (fwd)
[EMAIL PROTECTED] (Rogier Wolff) writes: > If the firewall operator is sufficiently paranoid, they can say: "We > don't trust the ECN implementation on our hosts behind the firewall, > so we want to disable it.". In which case would the "correct" action not be to zero the ECN bits of packets passing through the firewall? This would have the effect of informing the ECN aware hosts (both within and outside the firewall) that ECN is not available for that connection. This would not prevent ECN aware systems from connecting. - 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/
Re: ECN: Clearing the air (fwd)
[EMAIL PROTECTED] (Rogier Wolff) writes: If the firewall operator is sufficiently paranoid, they can say: "We don't trust the ECN implementation on our hosts behind the firewall, so we want to disable it.". In which case would the "correct" action not be to zero the ECN bits of packets passing through the firewall? This would have the effect of informing the ECN aware hosts (both within and outside the firewall) that ECN is not available for that connection. This would not prevent ECN aware systems from connecting. - 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/
Re: hotmail not dealing with ECN
"Adam J. Richter" <[EMAIL PROTECTED]> writes: > I am surprised that anyone is seriously considering denying > service to sites that do not implement an _experimental_ facility > and have firewalls that try to play things safe by dropping packets > which have 1's in bit positions that in the RFC "must be zero." Nobody is suggesting requiring other sites to *implement* ECN. If these sites either ignore the ECN bits or set them to 0, then there is no problem - an ECN capable system will still interwork fine. The problem is that they do not tolerate the fact that we are using the experimental facility and block connections when we indicate our willingness to use this facility. The RFC does *not* say that these bits must be checked for zero. What it states (as least as I read it) is that the bits are reserved for a use not defined at the time the RFC (793) was written and that until such time as the usage of these bits is defined (which ECN now has) implementations must *set* the bits to zero so as not to confuse which do use these bits (for the at the time unknown, but now defined, purpose). Therefore the instruction is "until such time as these bits are defined, they must be set to zero in outgoing packets". - 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/
Re: hotmail not dealing with ECN
"Adam J. Richter" [EMAIL PROTECTED] writes: I am surprised that anyone is seriously considering denying service to sites that do not implement an _experimental_ facility and have firewalls that try to play things safe by dropping packets which have 1's in bit positions that in the RFC "must be zero." Nobody is suggesting requiring other sites to *implement* ECN. If these sites either ignore the ECN bits or set them to 0, then there is no problem - an ECN capable system will still interwork fine. The problem is that they do not tolerate the fact that we are using the experimental facility and block connections when we indicate our willingness to use this facility. The RFC does *not* say that these bits must be checked for zero. What it states (as least as I read it) is that the bits are reserved for a use not defined at the time the RFC (793) was written and that until such time as the usage of these bits is defined (which ECN now has) implementations must *set* the bits to zero so as not to confuse which do use these bits (for the at the time unknown, but now defined, purpose). Therefore the instruction is "until such time as these bits are defined, they must be set to zero in outgoing packets". - 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/
Re: kernel network problem ?
Mathieu Chouquet-Stringer <[EMAIL PROTECTED]> writes: > Note that, on the Internet, there are many broken firewalls which > refuse connections from ECN-enabled machines, and it may be a while > before these firewalls are fixed. Until then, to access a site behind > such a firewall (some of which are major sites, at the time of this > writing) you will have to disable this option, either by saying N now > or by using the sysctl. As well as this, it might be worthwhile to complain to these sites. Otherwise if everyone just turns off ECN then those sites which block it will probably not fix their problem and ECN will not gain "public" acceptance. It would be great pity if this were to happen as ECN has the potential (if widely supported) to greatly reduce network congestion and bandwidth "waste". Would it perhaps be possible to have ECN enabled but use something such as IPTables to unset it when connecting to those sites which reject ECN connections? So that you could define a rule something like iptables -A OUTPUT -p tcp --syn -d 1.2.3.4 -j unsetecn - 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/
Re: 2.4.0-prelease freezes on serial event
Keith Owens <[EMAIL PROTECTED]> writes:
> Boot the kdb enhanced kernel and cat /proc/interrupts to see if NMI is
> non-zero.
NMI is zero, so that did not help.
However, I think I have solved the problem. During boot, I saw a
message about ACPI failing to initialise so I removed ACPI from the
configuration and rebuilt. Now the system again survives both power
cycling the modem and incoming voice calls.
Here is the output of dmesg which shows the boot (for the current
working configuration, not the one which failed).
BIOS-provided physical RAM map:
BIOS-e820: 0009fc00 @ (usable)
BIOS-e820: 0400 @ 0009fc00 (reserved)
BIOS-e820: 0001 @ 000f (reserved)
BIOS-e820: 07efc000 @ 0010 (usable)
BIOS-e820: 3000 @ 07ffc000 (ACPI data)
BIOS-e820: 1000 @ 07fff000 (ACPI NVS)
BIOS-e820: 0001 @ (reserved)
Scan SMP from c000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f for 65536 bytes.
Scan SMP from c009fc00 for 4096 bytes.
On node 0 totalpages: 32764
zone(0): 4096 pages.
zone(1): 28668 pages.
zone(2): 0 pages.
mapped APIC to e000 (fee0)
Kernel command line: BOOT_IMAGE=Linux ro root=301
Initializing CPU#0
Detected 605.678 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1209.13 BogoMIPS
Memory: 126620k/131056k available (1375k kernel code, 4048k reserved, 87k data, 188k
init, 0k highmem)
Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
CPU: Before vendor init, caps: 0387f9ff , vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After vendor init, caps: 0387f9ff
CPU serial number disabled.
CPU: After generic, caps: 0383f9ff
CPU: Common caps: 0383f9ff
CPU: Intel Pentium III (Coppermine) stepping 01
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
Local APIC disabled by BIOS -- reenabling...
leaving PIC mode, enabling symmetric IO mode.
enabled ExtINT on CPU#0
ESR value before enabling vector: 0040
ESR value after enabling vector:
calibrating APIC timer ...
. CPU clock speed is 605.6275 MHz.
. host bus clock speed is 100.9377 MHz.
cpu: 0, clocks: 1009377, slice: 504688
CPU0
mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED])
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xf06d0, last bus=2
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 1: assuming transparent
Unknown bridge resource 2: assuming transparent
PCI: Using IRQ router PIIX [8086/2410] at 00:1f.0
isapnp: Scanning for Pnp cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
DMI 2.3 present.
46 structures occupying 1330 bytes.
DMI table at 0x000F1D80.
BIOS Vendor: Award Software, Inc.
BIOS Version: ASUS CUC2000 ACPI BIOS Revision 1011
BIOS Release: 01/21/2000
System Vendor: System Manufacturer.
Product Name: System Name.
Version System Version.
Serial Number SYS-1234567890.
Board Vendor: ASUSTeK Computer INC..
Board Name: CUC2000.
Board Version: REV 1.xx.
Asset Tag: Asset-1234567890.
Starting kswapd v1.8
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 f9
PIIX4: chipset revision 2
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xa800-0xa807, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xa808-0xa80f, BIOS settings: hdc:DMA, hdd:DMA
hda: ST315323A, ATA DISK drive
hdb: ST33221A, ATA DISK drive
hdc: OnStream DI-30, ATAPI TAPE drive
hdd: FX240S, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 30008475 sectors (15364 MB) w/512KiB Cache, CHS=1867/255/63, UDMA(66)
hdb: 6303024 sectors (3227 MB) w/128KiB Cache, CHS=6253/16/63, UDMA(33)
hdd: ATAPI 24X CD-ROM drive, 256kB Cache, DMA
Uniform CD-ROM driver Revision: 3.12
ide-tape: hdc <-> ht0: OnStream DI-30 rev 1.05
ide-tape: hdc <-> ht0: 990KBps, 64*32kB buffer, 10208kB pipeline, 60ms tDSC, DMA
Partition check:
hda: hda1 hda2 hda3 hda4
hdb:hdb: set_multmode: status=0x51 { DriveReady SeekComplete Error }
hdb: set_multmode: error=0x04 { DriveStatusError }
hdb1 hdb2 < hdb5 hdb6 hdb7 >
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
udf: registering filesystem
Re: 2.4.0-prelease freezes on serial event
Keith Owens [EMAIL PROTECTED] writes:
Boot the kdb enhanced kernel and cat /proc/interrupts to see if NMI is
non-zero.
NMI is zero, so that did not help.
However, I think I have solved the problem. During boot, I saw a
message about ACPI failing to initialise so I removed ACPI from the
configuration and rebuilt. Now the system again survives both power
cycling the modem and incoming voice calls.
Here is the output of dmesg which shows the boot (for the current
working configuration, not the one which failed).
BIOS-provided physical RAM map:
BIOS-e820: 0009fc00 @ (usable)
BIOS-e820: 0400 @ 0009fc00 (reserved)
BIOS-e820: 0001 @ 000f (reserved)
BIOS-e820: 07efc000 @ 0010 (usable)
BIOS-e820: 3000 @ 07ffc000 (ACPI data)
BIOS-e820: 1000 @ 07fff000 (ACPI NVS)
BIOS-e820: 0001 @ (reserved)
Scan SMP from c000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f for 65536 bytes.
Scan SMP from c009fc00 for 4096 bytes.
On node 0 totalpages: 32764
zone(0): 4096 pages.
zone(1): 28668 pages.
zone(2): 0 pages.
mapped APIC to e000 (fee0)
Kernel command line: BOOT_IMAGE=Linux ro root=301
Initializing CPU#0
Detected 605.678 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1209.13 BogoMIPS
Memory: 126620k/131056k available (1375k kernel code, 4048k reserved, 87k data, 188k
init, 0k highmem)
Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
CPU: Before vendor init, caps: 0387f9ff , vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After vendor init, caps: 0387f9ff
CPU serial number disabled.
CPU: After generic, caps: 0383f9ff
CPU: Common caps: 0383f9ff
CPU: Intel Pentium III (Coppermine) stepping 01
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
Local APIC disabled by BIOS -- reenabling...
leaving PIC mode, enabling symmetric IO mode.
enabled ExtINT on CPU#0
ESR value before enabling vector: 0040
ESR value after enabling vector:
calibrating APIC timer ...
. CPU clock speed is 605.6275 MHz.
. host bus clock speed is 100.9377 MHz.
cpu: 0, clocks: 1009377, slice: 504688
CPU0T0:1009376,T1:504688,D:0,S:504688,C:1009377
mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED])
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xf06d0, last bus=2
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 1: assuming transparent
Unknown bridge resource 2: assuming transparent
PCI: Using IRQ router PIIX [8086/2410] at 00:1f.0
isapnp: Scanning for Pnp cards...
isapnp: No Plug Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
DMI 2.3 present.
46 structures occupying 1330 bytes.
DMI table at 0x000F1D80.
BIOS Vendor: Award Software, Inc.
BIOS Version: ASUS CUC2000 ACPI BIOS Revision 1011
BIOS Release: 01/21/2000
System Vendor: System Manufacturer.
Product Name: System Name.
Version System Version.
Serial Number SYS-1234567890.
Board Vendor: ASUSTeK Computer INC..
Board Name: CUC2000.
Board Version: REV 1.xx.
Asset Tag: Asset-1234567890.
Starting kswapd v1.8
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 f9
PIIX4: chipset revision 2
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xa800-0xa807, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xa808-0xa80f, BIOS settings: hdc:DMA, hdd:DMA
hda: ST315323A, ATA DISK drive
hdb: ST33221A, ATA DISK drive
hdc: OnStream DI-30, ATAPI TAPE drive
hdd: FX240S, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 30008475 sectors (15364 MB) w/512KiB Cache, CHS=1867/255/63, UDMA(66)
hdb: 6303024 sectors (3227 MB) w/128KiB Cache, CHS=6253/16/63, UDMA(33)
hdd: ATAPI 24X CD-ROM drive, 256kB Cache, DMA
Uniform CD-ROM driver Revision: 3.12
ide-tape: hdc - ht0: OnStream DI-30 rev 1.05
ide-tape: hdc - ht0: 990KBps, 64*32kB buffer, 10208kB pipeline, 60ms tDSC, DMA
Partition check:
hda: hda1 hda2 hda3 hda4
hdb:hdb: set_multmode: status=0x51 { DriveReady SeekComplete Error }
hdb: set_multmode: error=0x04 { DriveStatusError }
hdb1 hdb2 hdb5 hdb6 hdb7
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991
2.4.0-prelease freezes on serial event
My 2.4.0-prerelease freezes solid on certain serial port events. The ones I have seen (and are both repeatable) are when powering off the modem and powering it on causes the system to hang solid. Also if an incoming call is received on the telephone, the system hangs ( I assume that this is when the modem sends 'RING' and asserts the RI hardware signal.) The serial port is used only for outgoing connections and there is NO getty process listening on it. I would suspect a hardware problem, except that I have never seen this before and on reverting to 2.4.0-test12 these actions do not cause any problems. - 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/
Re: test13-pre6 (Fork Bug with Athlons? Temporary Fix)
Byron Stanoszek <[EMAIL PROTECTED]> writes: > I narrowed the problem down to a subset of patches from the MM set in > test13-pre2. Reversing the attached 'context.patch' fixes the problem (only for > i386), but I'm not yet sure why. test13-pre2 and up work without any problems > on an Intel cpu (Pentium 180 & P3 800 tested). [Snip] > root 351 0.0 1.2 9292 1576 ?S21:42 0:00 named > root 361 0.0 0.0 00 ?Z21:42 0:00 [named ] > root 363 0.0 1.2 9292 1576 ?S21:42 0:00 named > root 364 0.0 1.2 9292 1576 ?S21:42 0:00 named > root 365 0.0 0.7 2064 936 ?S21:42 0:00 /usr/sbin/sshd > ..etc > (Note PID 361) I am seeing the same thing with the [named ] on a PIII 600, so it is not Athlon specific. I haven't yet tried test13-pre6 but it happens with pre3,4,5. So I am still running on test12. I will try running pre6 then, if it still fails will try with your context.patch and see if that fixes it. - 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/
Re: test13-pre6 (Fork Bug with Athlons? Temporary Fix)
Byron Stanoszek [EMAIL PROTECTED] writes: I narrowed the problem down to a subset of patches from the MM set in test13-pre2. Reversing the attached 'context.patch' fixes the problem (only for i386), but I'm not yet sure why. test13-pre2 and up work without any problems on an Intel cpu (Pentium 180 P3 800 tested). [Snip] root 351 0.0 1.2 9292 1576 ?S21:42 0:00 named root 361 0.0 0.0 00 ?Z21:42 0:00 [named defunct] root 363 0.0 1.2 9292 1576 ?S21:42 0:00 named root 364 0.0 1.2 9292 1576 ?S21:42 0:00 named root 365 0.0 0.7 2064 936 ?S21:42 0:00 /usr/sbin/sshd ..etc (Note PID 361) I am seeing the same thing with the [named defunct] on a PIII 600, so it is not Athlon specific. I haven't yet tried test13-pre6 but it happens with pre3,4,5. So I am still running on test12. I will try running pre6 then, if it still fails will try with your context.patch and see if that fixes it. - 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/
Re: Enviromental Monitoring
Peter Samuelson <[EMAIL PROTECTED]> writes: > [Andrew Stubbs] > > Has anyone implemented a /proc device or user program to interrogate > > the enviromental attirbutes (temp, voltage etc) that many > > motherboards provide via their bios's ? > > Do a search on 'lm_sensors'. Does this work with the latest 2.4.0-testxx kernels. It stopped working for me quite a few kernel tests ago. - 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/
Re: Enviromental Monitoring
Peter Samuelson [EMAIL PROTECTED] writes: [Andrew Stubbs] Has anyone implemented a /proc device or user program to interrogate the enviromental attirbutes (temp, voltage etc) that many motherboards provide via their bios's ? Do a search on 'lm_sensors'. Does this work with the latest 2.4.0-testxx kernels. It stopped working for me quite a few kernel tests ago. - 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/
2.4.0-test9 i810_rng compilation failure
i810_rng.c does not compile when not a module. It fails at line 384, which looks as though it should only be included when being built as a module. - 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/
2.4.0-test9 i810_rng compilation failure
i810_rng.c does not compile when not a module. It fails at line 384, which looks as though it should only be included when being built as a module. - 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/
netstat -s on 2.4.0-test[78]
Using net-tools 1.57 (which I think is the latest) and kernel 2.4.0-test7/8 (I think it was OK with -test6) 'netstat -s' displays the message "error parsing /proc/net/snmp: Success" rather than displaying the counters. I notice that kernel/Documentation/Changes no longer lists the version of net-tools to be used. - 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/
netstat -s on 2.4.0-test[78]
Using net-tools 1.57 (which I think is the latest) and kernel 2.4.0-test7/8 (I think it was OK with -test6) 'netstat -s' displays the message "error parsing /proc/net/snmp: Success" rather than displaying the counters. I notice that kernel/Documentation/Changes no longer lists the version of net-tools to be used. - 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/
Re: ECN & cisco firewall
"David S. Miller" <[EMAIL PROTECTED]> writes: > The authors of rfc793 probably, in all honesty, really meant > "must be set to zero by current implementations". I agree, to me it seems obvious that the reason is so that these bits could be used at some time in the future for some, then unknown, purpose. Now that RFC 2481 has defined the bits, only implementations which grok and support ECN should be setting these bits, older implementations will (following RFC793) set them to zero and thus old and new implementations should correctly interwork. - 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/
Re: ECN cisco firewall
"David S. Miller" [EMAIL PROTECTED] writes: The authors of rfc793 probably, in all honesty, really meant "must be set to zero by current implementations". I agree, to me it seems obvious that the reason is so that these bits could be used at some time in the future for some, then unknown, purpose. Now that RFC 2481 has defined the bits, only implementations which grok and support ECN should be setting these bits, older implementations will (following RFC793) set them to zero and thus old and new implementations should correctly interwork. - 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/
Re: www.crucial.com won't talk to 2.4.0-test7 system
David Ford <[EMAIL PROTECTED]> writes: > There are a -lot- of large sites that give us issues like this. What is the best way to handle sites which block connections using ECN? Is it best for everyone who detects this to write individually to each site which they find can be accessed with "echo 0 > /proc/sys/net/ipv4/tcp_ecn" but not (in the default state) of tcp_ecn = 1? Or is there some better way to spread the word more "officially"? So far I have written to every site which I have been unable to access with ECN enabled, but the only response (apart from auto-responders acknowledging the receipt of the email) I have had has said that the matter has been forwarded to the site's IT department. - 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/
Re: www.crucial.com won't talk to 2.4.0-test7 system
David Ford [EMAIL PROTECTED] writes: There are a -lot- of large sites that give us issues like this. What is the best way to handle sites which block connections using ECN? Is it best for everyone who detects this to write individually to each site which they find can be accessed with "echo 0 /proc/sys/net/ipv4/tcp_ecn" but not (in the default state) of tcp_ecn = 1? Or is there some better way to spread the word more "officially"? So far I have written to every site which I have been unable to access with ECN enabled, but the only response (apart from auto-responders acknowledging the receipt of the email) I have had has said that the matter has been forwarded to the site's IT department. - 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/
