Re: Background to the argument about CML2 design philosophy
> derive MVME147_SCSI from MVME147 & SCSI It seems that the preferred semantics would be: default MVME147_SCSI from MVME147 & SCSI That way the platform defines sane defaults, but no flexibility has been taken away. Presumably many of these defaulted options would also be ones that would be configured not to be changeable in novice mode. The novice gets the vanilla platform defaults without being bothered by detailed options, and can switch to expert mode if they need more control. The experts get all the options presented, but also get to benefit from the smart platform defaults. Ben - 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: Background to the argument about CML2 design philosophy
derive MVME147_SCSI from MVME147 SCSI It seems that the preferred semantics would be: default MVME147_SCSI from MVME147 SCSI That way the platform defines sane defaults, but no flexibility has been taken away. Presumably many of these defaulted options would also be ones that would be configured not to be changeable in novice mode. The novice gets the vanilla platform defaults without being bothered by detailed options, and can switch to expert mode if they need more control. The experts get all the options presented, but also get to benefit from the smart platform defaults. Ben - 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: Brown-paper-bag bug in m68k, sparc, and sparc64 config files
Miles Lane wrote: > > On 19 May 2001 21:06:51 -0400, Benedict Bridgwater wrote: > > > This bug unconditionally disables a configuration question -- and it's > > > so old that it has propagated across three port files, without either > > > of the people who did the cut and paste for the latter two noticing it. > > > > > > This sort of thing would never ship in CML2, because the compiler > > > would throw an undefined-symbol warning on BLK_DEV_ST. The temptation > > > to engage in sarcastic commentary at the expense of people who still > > > think CML2 is an unnecessary pain in the butt is great. But I will > > > restrain myself. This time. > > > > So a shortcoming of the CML1 tools justifies the CML2 language? > > > > I guess the next bug found in the Python2 interpreter will justify > > writing CML3 in FORTRAN. > > IIRC, Eric floated the CML2 idea over a year ago, provided some > rudimentary code and requested feedback. There has seemed, for a long > time, to be agreement amoungst most kernel developers that there were > serious problems with CML1 and that it needed to be junked. There are > many things that CML1 was not going to allow us to do that will be > possible with CML2 (subsetting of the code tree, etc). I don't think > Eric's statement about this particular brown-paper-bag bug means that he > thinks that this alone justifies migrating to CML2. There are a lot of > good reasons for the migration. It isn't, perhaps, a perfect solution, > but it is one that Eric has implemented with a year's worth of effort, > with full knowledge of the kernel development community and with an open > invitation for contributions and feedback. To rag on it now seems > belated and unhelpful. It would be more useful if you helped Eric > improve CML2, since there appears to be agreement that it will be used > in 2.5. Well if Eric is so concerned about his target audience then he certainly doesn't show it through his arrogant comments. CML2 itself may be well justified (although not on grounds of a diagnostic that CML1 tools could be changed to generate!), but there's no reason the tools utilizing the CML2 based rules shouldn't present a *superset* of the existing functionality. To present a dumbed down UI targeted for "Aunt Millie" or whoever against the protests of the mainstream kernel tool audience makes zero sense to me, as don't Eric's repeated antagonistic comments. Ben - 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: Brown-paper-bag bug in m68k, sparc, and sparc64 config files
Miles Lane wrote: On 19 May 2001 21:06:51 -0400, Benedict Bridgwater wrote: This bug unconditionally disables a configuration question -- and it's so old that it has propagated across three port files, without either of the people who did the cut and paste for the latter two noticing it. This sort of thing would never ship in CML2, because the compiler would throw an undefined-symbol warning on BLK_DEV_ST. The temptation to engage in sarcastic commentary at the expense of people who still think CML2 is an unnecessary pain in the butt is great. But I will restrain myself. This time. So a shortcoming of the CML1 tools justifies the CML2 language? I guess the next bug found in the Python2 interpreter will justify writing CML3 in FORTRAN. IIRC, Eric floated the CML2 idea over a year ago, provided some rudimentary code and requested feedback. There has seemed, for a long time, to be agreement amoungst most kernel developers that there were serious problems with CML1 and that it needed to be junked. There are many things that CML1 was not going to allow us to do that will be possible with CML2 (subsetting of the code tree, etc). I don't think Eric's statement about this particular brown-paper-bag bug means that he thinks that this alone justifies migrating to CML2. There are a lot of good reasons for the migration. It isn't, perhaps, a perfect solution, but it is one that Eric has implemented with a year's worth of effort, with full knowledge of the kernel development community and with an open invitation for contributions and feedback. To rag on it now seems belated and unhelpful. It would be more useful if you helped Eric improve CML2, since there appears to be agreement that it will be used in 2.5. Well if Eric is so concerned about his target audience then he certainly doesn't show it through his arrogant comments. CML2 itself may be well justified (although not on grounds of a diagnostic that CML1 tools could be changed to generate!), but there's no reason the tools utilizing the CML2 based rules shouldn't present a *superset* of the existing functionality. To present a dumbed down UI targeted for Aunt Millie or whoever against the protests of the mainstream kernel tool audience makes zero sense to me, as don't Eric's repeated antagonistic comments. Ben - 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: 2.4.4-ac5 aic7xxx causes hang on my machine
Ben Bridgwater wrote: > Jeff Garzik wrote: > > > > > Setting DEBUG to 1 in arch/i386/kernel/pci-i386.h gives you lots of > > info, including PIRQ debug data. > > I can try this tonite with 2.4.4 if this is going to be useful. > Well, I don't know how useful this is going to be, since the kernel booted successfully This is a plain 2.4.4 tarball, compiled with gcc 2.95.3 The relevant parts of the kernel configuration are: - no SMP - no UP APIC - new aic7 - aic7xxx built into kernel (not a module) It was late so I didn't run any real tests on it, but at least it booted and the aic7xxx/hard drive seemed happy. I didn't test the SCSI CD, which I'll do tonite, as well as trying some other options to try to reproduce the Mandrake 8.0 install and boot problems. The boot here isn't totally clean since I was booting with a 2.2 root and old modultils so it couldn't find my modules (just sound and bttv). If this is a PCI bug (whether PIRQ table or kernel) then should old/new aic7xxx make a difference? I'll try the old one tonite. Any suggestions as to what might be worth trying to reproduce it? Ben May 10 01:34:15 localhost syslog: syslogd startup succeeded May 10 01:34:15 localhost kernel: klogd 1.3-3, log source = /proc/kmsg started. May 10 01:34:15 localhost kernel: Inspecting /boot/System.map-2.4.4-pci-debug May 10 01:34:15 localhost syslog: klogd startup succeeded May 10 01:34:15 localhost identd[361]: started May 10 01:34:15 localhost identd: identd startup succeeded May 10 01:34:15 localhost kernel: Loaded 15341 symbols from /boot/System.map-2.4.4-pci-debug. May 10 01:34:15 localhost kernel: Symbols match kernel version 2.4.4. May 10 01:34:15 localhost kernel: No module symbols loaded. May 10 01:34:15 localhost kernel: Linux version 2.4.4-pci-debug ([EMAIL PROTECTED]) (gcc version 2.95.3 19991030 (prerelease)) #1 Thu May 10 00:39:34 EDT 2001 May 10 01:34:15 localhost kernel: BIOS-provided physical RAM map: May 10 01:34:15 localhost kernel: BIOS-e820: - 0009fc00 (usable) May 10 01:34:15 localhost kernel: BIOS-e820: 0010 - 0400 (usable) May 10 01:34:15 localhost kernel: BIOS-e820: fff8 - 0001 (reserved) May 10 01:34:15 localhost kernel: On node 0 totalpages: 16384 May 10 01:34:15 localhost kernel: zone(0): 4096 pages. May 10 01:34:15 localhost kernel: zone(1): 12288 pages. May 10 01:34:15 localhost kernel: zone(2): 0 pages. May 10 01:34:15 localhost kernel: Kernel command line: mem=65536K root=/dev/sdb5 May 10 01:34:16 localhost kernel: Initializing CPU#0 May 10 01:34:16 localhost kernel: Detected 265.913 MHz processor. May 10 01:34:16 localhost kernel: Console: colour VGA+ 80x25 May 10 01:34:16 localhost kernel: Calibrating delay loop... 530.84 BogoMIPS May 10 01:34:16 localhost kernel: Memory: 61896k/65536k available (1251k kernel code, 3252k reserved, 498k data, 180k init, 0k highmem) May 10 01:34:16 localhost atd: atd startup succeeded May 10 01:34:16 localhost kernel: Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes) May 10 01:34:16 localhost kernel: Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) May 10 01:34:16 localhost kernel: Page-cache hash table entries: 16384 (order: 4, 65536 bytes) May 10 01:34:16 localhost kernel: Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) May 10 01:34:16 localhost kernel: CPU: Before vendor init, caps: 0080f9ff , vendor = 0 May 10 01:34:16 localhost kernel: CPU: L1 I cache: 16K, L1 D cache: 16K May 10 01:34:16 localhost kernel: CPU: L2 cache: 512K May 10 01:34:16 localhost kernel: Intel machine check architecture supported. May 10 01:34:16 localhost kernel: Intel machine check reporting enabled on CPU#0. May 10 01:34:16 localhost kernel: CPU: After vendor init, caps: 0080f9ff May 10 01:34:16 localhost kernel: CPU: After generic, caps: 0080f9ff May 10 01:34:16 localhost kernel: CPU: Common caps: 0080f9ff May 10 01:34:16 localhost kernel: CPU: Intel Pentium II (Klamath) stepping 03 May 10 01:34:16 localhost kernel: Checking 'hlt' instruction... OK. May 10 01:33:28 localhost rc.sysinit: Mounting proc filesystem succeeded May 10 01:34:16 localhost kernel: POSIX conformance testing by UNIFIX May 10 01:33:28 localhost sysctl: error: 'net.ipv4.ip_always_defrag' is an unknown key May 10 01:34:16 localhost kernel: mtrr: v1.40 (20010327) Richard Gooch ([EMAIL PROTECTED]) May 10 01:33:28 localhost sysctl: error: 'kernel.sysrq' is an unknown key May 10 01:34:16 localhost kernel: mtrr: detected mtrr type: Intel May 10 01:33:28 localhost sysctl: error: 'net.ipv4.tcp_timestamp' is an unknown key May 10 01:34:16 localhost kernel: PCI: BIOS32 Service Directory structure at 0xc00fd9e0 May 10 01:33:28 localhost sysctl: error: 'net.ipv4.tcp_syncookies' is an unknown key May 10 01:34:16 localhost kernel: PCI: BIOS32 Service Directory
Re: 2.4.4-ac5 aic7xxx causes hang on my machine
Ben Bridgwater wrote: Jeff Garzik wrote: Setting DEBUG to 1 in arch/i386/kernel/pci-i386.h gives you lots of info, including PIRQ debug data. I can try this tonite with 2.4.4 if this is going to be useful. Well, I don't know how useful this is going to be, since the kernel booted successfully This is a plain 2.4.4 tarball, compiled with gcc 2.95.3 The relevant parts of the kernel configuration are: - no SMP - no UP APIC - new aic7 - aic7xxx built into kernel (not a module) It was late so I didn't run any real tests on it, but at least it booted and the aic7xxx/hard drive seemed happy. I didn't test the SCSI CD, which I'll do tonite, as well as trying some other options to try to reproduce the Mandrake 8.0 install and boot problems. The boot here isn't totally clean since I was booting with a 2.2 root and old modultils so it couldn't find my modules (just sound and bttv). If this is a PCI bug (whether PIRQ table or kernel) then should old/new aic7xxx make a difference? I'll try the old one tonite. Any suggestions as to what might be worth trying to reproduce it? Ben May 10 01:34:15 localhost syslog: syslogd startup succeeded May 10 01:34:15 localhost kernel: klogd 1.3-3, log source = /proc/kmsg started. May 10 01:34:15 localhost kernel: Inspecting /boot/System.map-2.4.4-pci-debug May 10 01:34:15 localhost syslog: klogd startup succeeded May 10 01:34:15 localhost identd[361]: started May 10 01:34:15 localhost identd: identd startup succeeded May 10 01:34:15 localhost kernel: Loaded 15341 symbols from /boot/System.map-2.4.4-pci-debug. May 10 01:34:15 localhost kernel: Symbols match kernel version 2.4.4. May 10 01:34:15 localhost kernel: No module symbols loaded. May 10 01:34:15 localhost kernel: Linux version 2.4.4-pci-debug ([EMAIL PROTECTED]) (gcc version 2.95.3 19991030 (prerelease)) #1 Thu May 10 00:39:34 EDT 2001 May 10 01:34:15 localhost kernel: BIOS-provided physical RAM map: May 10 01:34:15 localhost kernel: BIOS-e820: - 0009fc00 (usable) May 10 01:34:15 localhost kernel: BIOS-e820: 0010 - 0400 (usable) May 10 01:34:15 localhost kernel: BIOS-e820: fff8 - 0001 (reserved) May 10 01:34:15 localhost kernel: On node 0 totalpages: 16384 May 10 01:34:15 localhost kernel: zone(0): 4096 pages. May 10 01:34:15 localhost kernel: zone(1): 12288 pages. May 10 01:34:15 localhost kernel: zone(2): 0 pages. May 10 01:34:15 localhost kernel: Kernel command line: mem=65536K root=/dev/sdb5 May 10 01:34:16 localhost kernel: Initializing CPU#0 May 10 01:34:16 localhost kernel: Detected 265.913 MHz processor. May 10 01:34:16 localhost kernel: Console: colour VGA+ 80x25 May 10 01:34:16 localhost kernel: Calibrating delay loop... 530.84 BogoMIPS May 10 01:34:16 localhost kernel: Memory: 61896k/65536k available (1251k kernel code, 3252k reserved, 498k data, 180k init, 0k highmem) May 10 01:34:16 localhost atd: atd startup succeeded May 10 01:34:16 localhost kernel: Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes) May 10 01:34:16 localhost kernel: Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) May 10 01:34:16 localhost kernel: Page-cache hash table entries: 16384 (order: 4, 65536 bytes) May 10 01:34:16 localhost kernel: Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) May 10 01:34:16 localhost kernel: CPU: Before vendor init, caps: 0080f9ff , vendor = 0 May 10 01:34:16 localhost kernel: CPU: L1 I cache: 16K, L1 D cache: 16K May 10 01:34:16 localhost kernel: CPU: L2 cache: 512K May 10 01:34:16 localhost kernel: Intel machine check architecture supported. May 10 01:34:16 localhost kernel: Intel machine check reporting enabled on CPU#0. May 10 01:34:16 localhost kernel: CPU: After vendor init, caps: 0080f9ff May 10 01:34:16 localhost kernel: CPU: After generic, caps: 0080f9ff May 10 01:34:16 localhost kernel: CPU: Common caps: 0080f9ff May 10 01:34:16 localhost kernel: CPU: Intel Pentium II (Klamath) stepping 03 May 10 01:34:16 localhost kernel: Checking 'hlt' instruction... OK. May 10 01:33:28 localhost rc.sysinit: Mounting proc filesystem succeeded May 10 01:34:16 localhost kernel: POSIX conformance testing by UNIFIX May 10 01:33:28 localhost sysctl: error: 'net.ipv4.ip_always_defrag' is an unknown key May 10 01:34:16 localhost kernel: mtrr: v1.40 (20010327) Richard Gooch ([EMAIL PROTECTED]) May 10 01:33:28 localhost sysctl: error: 'kernel.sysrq' is an unknown key May 10 01:34:16 localhost kernel: mtrr: detected mtrr type: Intel May 10 01:33:28 localhost sysctl: error: 'net.ipv4.tcp_timestamp' is an unknown key May 10 01:34:16 localhost kernel: PCI: BIOS32 Service Directory structure at 0xc00fd9e0 May 10 01:33:28 localhost sysctl: error: 'net.ipv4.tcp_syncookies' is an unknown key May 10 01:34:16 localhost kernel: PCI: BIOS32 Service Directory entry at 0xfd9f0 May 10 01:33:28 localhost
