Re: After last ATAPI update system doesn't boot if modules loaded by /boot/loader.
In message [EMAIL PROTECTED] Soren Schmidt writes: : Busspace is a joke, I'm perfectly fine with calling those macros : in[bwl]/out[bwl] like they should be :) You wouldn't say that if you've had to deal with all the oddities of a mips box. : Busdma, hmm, well I dont see that helping here either Or that either Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: After last ATAPI update system doesn't boot if modules loaded by /boot/loader.
I'd hazard a guess that the presence of modules is causing the kernel linker to run and pull all the sysctl hooks for modules it's finding. I'm probably wrong, just a guess. ... I'll go look up cold usage, and see if it necessarily has to be done that early. I'll also investigate that sysctl possibility. Oops. I meant sysinit, not sysctl. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: After last ATAPI update system doesn't boot if modules loaded by /boot/loader.
It seems Mike Smith wrote: Forgive me if I'm beating a dead horse... I'm still having the following problem if I load any modules from /boot/loader.conf: I've reproduced this here, and narrowed it down to Soren's ATA megacommit on the 18th. Unfortunately, the newbus patches (tested) and the other gunk (untested) ended up lumped in together, and I'm not having a lot of luck working out what exactly might be causing this. That megapatch was only newbus patches and cosmetics around that, one new item was cmd646 support but that is hardly the problem here. Soren - this is somewhat of a showstopper. Can you reproduce it there? Nope, I've tried several machines here, no problems, even with tons of modules.. The only thing I can come up with is that _something_ makes the delayed probe be called _before_ interrupts are up and running. That will make it fail like this. Quuestion is is something else messing with those hooks ? We've seen this before, but back then no solution was found either, it dissaperead all by itself... ata0-slave: WARNING: WAIT_INTR active=ATA_WAIT_INTR ata0-slave: ata_command: timeout waiting for intr ata0-slave: identify failed -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: After last ATAPI update system doesn't boot if modules loaded by /boot/loader.
Forgive me if I'm beating a dead horse... I'm still having the following problem if I load any modules from /boot/loader.conf: I've reproduced this here, and narrowed it down to Soren's ATA megacommit on the 18th. Unfortunately, the newbus patches (tested) and the other gunk (untested) ended up lumped in together, and I'm not having a lot of luck working out what exactly might be causing this. Soren - this is somewhat of a showstopper. Can you reproduce it there? ata0-slave: WARNING: WAIT_INTR active=ATA_WAIT_INTR ata0-slave: ata_command: timeout waiting for intr ata0-slave: identify failed no devsw (majdev=0 bootdev=0xa040) Mounting root from ufs:/dev/ad0s3a no such device 'ad' setrootbyname failed ffs_mountroot: can't find rootvp Root mount failed: 6 If at the boot prompt I: unload load kernel boot there's no problem. Also there's no problem if loading modules from /boot/loader.conf with a kernel suped and built on Feb. 17th with today's buildworld. Mike Smith wrote: it does : I've tried loading miibus alone : works fine loading miibus, then if_xl : loops in loading miibus Ok. We know that hurts, don't do that. 8) From the above remark should I conclude that it's a known problem and we should refrain from loading modules from the boot loader until it works? Or would it help send boot_verbose output from my kernel as well? -- Yarema To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: After last ATAPI update system doesn't boot if modules loaded by /boot/loader.
I'm also experiencing this under current since the Mega Patch, I'm running on Celeron 500. Asus P99B Board (2 IDE, 128MB Ram, 4.3 GB Hard Disk). But if I don't load any modules, it works fine.
Re: After last ATAPI update system doesn't boot if modules loaded by /boot/loader.
Soren Schmidt wrote: It seems Mike Smith wrote: Forgive me if I'm beating a dead horse... I'm still having the following problem if I load any modules from /boot/loader.conf: I've reproduced this here, and narrowed it down to Soren's ATA megacommit on the 18th. Unfortunately, the newbus patches (tested) and the other gunk (untested) ended up lumped in together, and I'm not having a lot of luck working out what exactly might be causing this. That megapatch was only newbus patches and cosmetics around that, one new item was cmd646 support but that is hardly the problem here. Soren - this is somewhat of a showstopper. Can you reproduce it there? Nope, I've tried several machines here, no problems, even with tons of modules.. The only thing I can come up with is that _something_ makes the delayed probe be called _before_ interrupts are up and running. That will make it fail like this. Quuestion is is something else messing with those hooks ? We've seen this before, but back then no solution was found either, it dissaperead all by itself... -Søren Perhaps this will help. Attached is a copy of a boot_verbose dmesg when my box DOES boot. When it does NOT boot the screen shows something like this: ... Device configuration finished. bpf: lo0 attached IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to accept, logging limited to 100 packets/entry by default Linux-ELF exec handler installed IP Filter: initialized. Default = pass all, Logging = enabled IP Filter: v3.3.8 ata0-slave: WARNING: WAIT_INTR active=ATA_WAIT_INTR ata0-slave: ata_command: timeout waiting for intr ata0-slave: identify failed no devsw (majdev=0 bootdev=0xa020) Mounting root from ufs:/dev/ad0s1a no such device 'ad' setrootbyname failed ffs_mountroot: can't find rootvp Root mount failed: 6 ... Seems like it craps out right after the linux module kicks in at 'Linux-ELF exec handler installed'. The platform in this case is a Celleron 466/ASUS MES-N/SiS® 620 AGPset. http://www.asus.com.tw/products/motherboard/pentiumpro/mes-n/index.html http://www.sis.com.tw/products/pentium2/620.htm Hope this helps. Incidentally ata(4) states: The currently supported controllers with their maximum speed include: ... SiS 5591 Ultra DMA 33 (UDMA2), 33 MB/sec ... yet the above URL claims: The IDE controller is ATA-3 compliant, supporting PIO mode 0/1/2/3/4, DMA multiword 0/1/2 and Ultra DMA 33/66 operations. The two IDE channels are fully independent with dedicated 16 double-word FIFO built-in. I understand there's little (if any) perfrmance difference between UDMA33 and UDMA66. Just wondering why UDMA66 was not supported for this controller. -- Yarema Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #1: Wed Feb 23 11:03:02 EST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/ASUSMESN Calibrating clock(s) ... TSC clock: 466827092 Hz, i8254 clock: 1193128 Hz Timecounter "i8254" frequency 1193128 Hz Timecounter "TSC" frequency 466827092 Hz CPU: Pentium II/Pentium II Xeon/Celeron (466.83-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x665 Stepping = 5 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 266326016 (260084K bytes) Physical memory chunk(s): 0x1000 - 0x0009, 651264 bytes (159 pages) 0x00369000 - 0x0fdf4fff, 262717440 bytes (64140 pages) avail memory = 254541824 (248576K bytes) bios32: Found BIOS32 Service Directory header at 0xc00f99d0 bios32: Entry = 0xf04c0 (c00f04c0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0x4f0 pnpbios: Found PnP BIOS data at 0xc00fca10 pnpbios: Entry = f:ca40 Rev = 1.0 pnpbios: OEM ID cd041 Other BIOS signatures found: ACPI: 000f54a0 Preloaded elf kernel "kernel" at 0xc035. VESA: information block 56 45 53 41 00 02 00 01 00 01 04 00 00 00 22 00 00 01 20 00 00 01 14 01 00 01 36 01 00 01 40 01 00 01 00 01 01 01 03 01 05 01 07 01 21 01 80 01 81 01 82 01 89 01 8d 01 0d 01 10 01 13 01 16 01 VESA: 35 mode(s) found VESA: v2.0, 2048k memory, flags:0x4, mode table:0xc02f0ea2 (122) VESA: SiS VESA: Silicon Integrated Systems Corp. 6306 0A Pentium Pro MTRR support enabled md0: Malloc disk Creating DISK md0 pci_open(1):mode 1 addr port (0x0cf8) is 0x80010010 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=80] is there (id=06201039) devclass_alloc_unit: pcib0 already exists, using next available unit number npx0: math processor on motherboard npx0: INT 16 interface pci_open(1):mode 1 addr port (0x0cf8) is 0x pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=80] is there (id=06201039) pcib0: Host to PCI bridge on motherboard found- vendor=0x1039, dev=0x0620,
Re: After last ATAPI update system doesn't boot if modules loaded by /boot/loader.
It seems Mike Smith wrote: Forgive me if I'm beating a dead horse... I'm still having the following problem if I load any modules from /boot/loader.conf: I've reproduced this here, and narrowed it down to Soren's ATA megacommit on the 18th. Unfortunately, the newbus patches (tested) and the other gunk (untested) ended up lumped in together, and I'm not having a lot of luck working out what exactly might be causing this. That megapatch was only newbus patches and cosmetics around that, one new item was cmd646 support but that is hardly the problem here. You didn't mention the 0xa5 test, and I forgot to tell you that I backed it out as well (no change). Soren - this is somewhat of a showstopper. Can you reproduce it there? Nope, I've tried several machines here, no problems, even with tons of modules.. Try a network interface module, if you haven't already. I was loading if_wi. The only thing I can come up with is that _something_ makes the delayed probe be called _before_ interrupts are up and running. That will make it fail like this. Quuestion is is something else messing with those hooks ? That's possible; it may be that the kernel linker is calling something before you expect it to be called. Also, I note that you've only partially newbussed the code; I don't see any busspace/busdma stuff in there. Is there another megapatch coming? -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: After last ATAPI update system doesn't boot if modules loaded by /boot/loader.
It seems Mike Smith wrote: That megapatch was only newbus patches and cosmetics around that, one new item was cmd646 support but that is hardly the problem here. You didn't mention the 0xa5 test, and I forgot to tell you that I backed it out as well (no change). yeah, cosmetics :) Soren - this is somewhat of a showstopper. Can you reproduce it there? Nope, I've tried several machines here, no problems, even with tons of modules.. Try a network interface module, if you haven't already. I was loading if_wi. Still no problems... The only thing I can come up with is that _something_ makes the delayed probe be called _before_ interrupts are up and running. That will make it fail like this. Quuestion is is something else messing with those hooks ? That's possible; it may be that the kernel linker is calling something before you expect it to be called. Well, its rather that the delayed probe rutine I register with config_intrhook_establish() is called before interrupts are actually working, that would explain why it times out on the probe... This didn't happen before, so thats probably why it breaks... It should break SCSI systems too, ass they do the same... Also, I note that you've only partially newbussed the code; I don't see any busspace/busdma stuff in there. Is there another megapatch coming? Busspace is a joke, I'm perfectly fine with calling those macros in[bwl]/out[bwl] like they should be :) Busdma, hmm, well I dont see that helping here either And no, no more mega patches before 4.0, this should probably have waited too, but there has been pushed very stronly for this... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: After last ATAPI update system doesn't boot if modules loaded by /boot/loader.
Forgive me if I'm beating a dead horse... I'm still having the following problem if I load any modules from /boot/loader.conf: ata0-slave: WARNING: WAIT_INTR active=ATA_WAIT_INTR ata0-slave: ata_command: timeout waiting for intr ata0-slave: identify failed no devsw (majdev=0 bootdev=0xa040) Mounting root from ufs:/dev/ad0s3a no such device 'ad' setrootbyname failed ffs_mountroot: can't find rootvp Root mount failed: 6 If at the boot prompt I: unload load kernel boot there's no problem. Also there's no problem if loading modules from /boot/loader.conf with a kernel suped and built on Feb. 17th with today's buildworld. Mike Smith wrote: it does : I've tried loading miibus alone : works fine loading miibus, then if_xl : loops in loading miibus Ok. We know that hurts, don't do that. 8) From the above remark should I conclude that it's a known problem and we should refrain from loading modules from the boot loader until it works? Or would it help send boot_verbose output from my kernel as well? -- Yarema To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: After last ATAPI update system doesn't boot if modules loaded by /boot/loader.
Mike Smith wrote: I've yesterday sent a post on this list (from my work email) about the impossibility of loading the if_xl and miibus modules with the loader (it works well with kldload, afterwards) This is a known problem with modules that have dependancies; if you load the miibus module first it shouldn't happen (I haven't tested this). it does : I've tried loading miibus alone : works fine loading miibus, then if_xl : loops in loading miibus Ok. We know that hurts, don't do that. 8) fine, could there be a note in /boot/loader.conf, so that l^Husers don't get burn trying to load things which won't work (no code change : just a word of caution) TfH -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: After last ATAPI update system doesn't boot if modules loaded by /boot/loader.
I've yesterday sent a post on this list (from my work email) about the impossibility of loading the if_xl and miibus modules with the loader (it works well with kldload, afterwards) This is a known problem with modules that have dependancies; if you load the miibus module first it shouldn't happen (I haven't tested this). it does : I've tried loading miibus alone : works fine loading miibus, then if_xl : loops in loading miibus Ok. We know that hurts, don't do that. 8) fine, could there be a note in /boot/loader.conf, so that l^Husers don't get burn trying to load things which won't work (no code change : just a word of caution) Actually, I think that turning off dependancy handling in the loader is the right way to do it. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: After last ATAPI update system doesn't boot if modules loaded by /boot/loader.
Vladimir Kushnir wrote: Hello, I dont't know if this is some HW problem, but after the last update system became unbootable if I load modules by /boot/loader rather them kldload. That seems to be a bug -- I'd just load the modules via /etc/rc.conf for now. Other people have reported problems when loading modules via the boot loader. My advice would be to just load them via /etc/rc.conf This is entirely incorrect, and if you're having trouble loading modules with the loader there's something wrong that needs to be fixed. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: After last ATAPI update system doesn't boot if modules loaded by /boot/loader.
Hello, I've yesterday sent a post on this list (from my work email) about the impossibility of loading the if_xl and miibus modules with the loader (it works well with kldload, afterwards) This is with 4.0 - RC1. TfH (The loader loops trying to load the miibus module) Mike Smith wrote: Vladimir Kushnir wrote: Hello, I dont't know if this is some HW problem, but after the last update system became unbootable if I load modules by /boot/loader rather them kldload. That seems to be a bug -- I'd just load the modules via /etc/rc.conf for now. Other people have reported problems when loading modules via the boot loader. My advice would be to just load them via /etc/rc.conf This is entirely incorrect, and if you're having trouble loading modules with the loader there's something wrong that needs to be fixed. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: After last ATAPI update system doesn't boot if modules loaded by /boot/loader.
Hello, I've yesterday sent a post on this list (from my work email) about the impossibility of loading the if_xl and miibus modules with the loader (it works well with kldload, afterwards) This is a known problem with modules that have dependancies; if you load the miibus module first it shouldn't happen (I haven't tested this). We tried to get some code to fix this into 4.x, but were thwarted by the freeze. Other modules should, however, work fine. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: After last ATAPI update system doesn't boot if modules loaded by /boot/loader.
Mike Smith wrote: Hello, I've yesterday sent a post on this list (from my work email) about the impossibility of loading the if_xl and miibus modules with the loader (it works well with kldload, afterwards) This is a known problem with modules that have dependancies; if you load the miibus module first it shouldn't happen (I haven't tested this). it does : I've tried loading miibus alone : works fine loading miibus, then if_xl : loops in loading miibus Strange ! TfH We tried to get some code to fix this into 4.x, but were thwarted by the freeze. Other modules should, however, work fine. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: After last ATAPI update system doesn't boot if modules loaded by /boot/loader.
I've yesterday sent a post on this list (from my work email) about the impossibility of loading the if_xl and miibus modules with the loader (it works well with kldload, afterwards) This is a known problem with modules that have dependancies; if you load the miibus module first it shouldn't happen (I haven't tested this). it does : I've tried loading miibus alone : works fine loading miibus, then if_xl : loops in loading miibus Ok. We know that hurts, don't do that. 8) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: After last ATAPI update system doesn't boot if modules loaded by /boot/loader.
Vladimir Kushnir wrote: Hello, I dont't know if this is some HW problem, but after the last update system became unbootable if I load modules by /boot/loader rather them kldload. That seems to be a bug -- I'd just load the modules via /etc/rc.conf for now. Other people have reported problems when loading modules via the boot loader. My advice would be to just load them via /etc/rc.conf - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
