December 2007 - Darwin-kernel

Re: [darwin-kernel] devfs_make_node mutilates pathname on Leopard?
by Terry Lambert 20 Dec '07

20 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Oi! That's my code you'd be ripping out! ;o) Terry, -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On Dec 19, 2007, at 7:47 PM, Sam Vaughan wrote: On 20/12/2007, at 2:34 PM, Terry Lambert wrote: On Dec 19, 2007, at 5:46 PM, Sam Vaughan wrote: On 19/12/2007, at 10:35 AM, Terry Lambert wrote: On Dec 13, 2007, at 8:41 PM, Sam Vaughan wrote: On 14/12/2007, at 7:05 AM, Terry Lambert <tlambert(a)apple.com> wrote: Given that subdirectories in /dev are not supported, and may be removed, if we end up needing to do that for some technical reason, it's probably better to just go that route on both 10.4 and 10.5 instead. This is probably the approach we will end up taking... just have to actually do it :) The reason for the subdirectories in the first place was to allow LUNs to be identified by the port and node WWNs on the host and RAID controller that uniquely described their path on the fibre channel network. The WWNs are too long to include in the one devfs node name, so the only option is to use a hierarchy. Subdirectories do not remove the node name length limit. I just got a chance to try devfs_make_node() again on Leopard and it still allows long path hierarchies just as it used to: $ find /dev/Curiosity -name Leopard -exec ls -l {} \; cr--r----- 1 root operator 17, 0 Dec 20 12:30 /dev/Curiosity/ got/the/better/of/me/so/I/dusted/off/some/old/code/to/try/a/deep/ dev/hierarchy/on/Leopard $ That's 104 characters. Try PATH_MAX (1024) characters instead. Why would I want to do that? It's the node name length of 32 that we were discussing. I guess you missed Nick Blievers posting about DEVMAXPATHSIZE (128)? I said at the time that I couldn't remember what the limit was. This email sent to site_archiver(a)lists.apple.com

1 0

Re: missing driver (AppleMacRiscPCI) at startup on G5
by Al Ciplickas 20 Dec '07

20 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=hfZwcGWS+Fita06VMMr0ZJQmZlPtD+05HHYNdgbFI7t1SvKswOg0heN91/G0MiwN; h=Received:In-Reply-To:References:Mime-Version:Content-Type:Message-Id:Cc:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; -Al- On Dec 19, 2007, at 7:38 PM, Terry Lambert wrote: The boot process is pretty well documented on developer.apple.com. -- Terry -Al- On Dec 19, 2007, at 1:31 PM, Terry Lambert wrote: -- Terry -Al- On Dec 18, 2007, at 2:38 PM, Terry Lambert wrote: You need to rebuild the KEXT cache, not the KEXT. man kextcache or http://developer.apple.com - Terry -Al- On Dec 18, 2007, at 1:25 PM, Terry Lambert wrote: Instead of removing the KEXT cache, rebuild it. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Thanks again, Terry. The reason I may be 'wasting' time on this issue is that this G5 10.4 system and applications have 3 years of saved mail, other applications and various folders of work. It does not seem easy to transfer all that to a new system partition. The evidence is that I reloaded the 10.4 (by upgrade) and it does not work. There seem to be no tools to move everything BUT system stuff to a new system partition. If there is, please let me know and I'll abandon this coarse. Otherwise, I'd have to do it by hand and risk missing things like licenses, activation numbers, serial numbers and other things that get stored in places I don't know. Although I'm curious by nature, I am not thrilled with the punishment that comes with 'climbing up a cliff'. I'll try to study the boot process in the Dev area you mentioned, but my previous exercises in those dimensions seemed to have Too much info and I got lost and confused before finding the essence of the matter (SCSI and USB being examples). I do appreciate your patience with guiding me in this annoying matter. Copying is not going to work for these files, since there are some very particular requirements for the date stamps on kernel, files, directories, and the cache file itself for the cache to be considered trustworthy. Is there a particular reason you are messing with this on an already booting system, if you are not building your own kernel, or is it just burning curiousity? If the latter, there's a huge amount of documentation on the boot process at <http://developer.apple.com>. On Dec 19, 2007, at 6:03 PM, Al Ciplickas wrote: I finally got the bootcache.plist file copied over and the Extensions.mkext file written. But alas, it still did not want to start up. Same message as in the first note. So there must be something still missing. Do know what other files I might need at start up? -or where to study about startup necessities? I can't believe I'm the only one that has had this problem, but maybe I am. Feeling a bit dumb at the moment. Thanks, This is the first time I have ever heard of it. I had assumed that your problem was that you were building your own kernel, so the KEXT cache was out of date relative to the kernel, and the driver could not be loaded by the boot loader from the cache (it didn't match the kernel), and without a PCI driver, you couldn't load the PCI driver off disk. On Dec 18, 2007, at 8:44 PM, Al Ciplickas wrote: Thanks again, Terry. I tried the rebuild and the complaint was that there was not a usr/../bootcache.plist (or something to that effect). Can't imagine how that could have happened, since I was not aware of that file. So I thought doing an 'upgrade' from an Install DVD would solve the problem. No way. The upgrade finished normally, but there was neither the bootcache.plist nor the kextentions.cache (sp?) files. This is confusing, as I expect a system upgrade to make all the necessary files to do a normal startup. I will locate an active bootcache.plist from an existing system partition and copy it to the usr/../ directory to see if it will help me do the kextcache rebuild. Do you think this is an anomaly for me or has this happened many times before and I should file a radar report? On Dec 18, 2007, at 2:09 PM, Al Ciplickas wrote: Thanks, Terry. I'll rebuild the KEXT. But forgot how at the moment. Any hints? On Dec 18, 2007, at 12:00 PM, Al Ciplickas wrote: This is a new one for me: G5 complains about 'com.apple.driver.AppleMacRiscPCI' missing in the startup from 'kld_load_from_memory()'. I got that using <cmd-V> at startup. I used another system partition to look it the file was there (in System/Library/Extensions/) and it was! So I took out the kextensions.cache and its partner and tried again: still got the same complaint. (By the way, it says there are 1310 buffer headers and 1310 cluster IO buffer header, if that matters.) Do anyone know of something else to try? This is under OSX 10.4.10 as well as 10.4.2 (which I reloaded in hopes of clearing up "lost" files). The error is indicating that it's unable to load it from the cache that was loaded into memory by the boot loader. It can't read it off the disk itself because it can't even talk to the PCI bus on which the disk controller lives without this KEXT loaded. -- Terry This email sent to site_archiver(a)lists.apple.com

1 0

Re: [darwin-kernel] devfs_make_node mutilates pathname on Leopard?
by Sam Vaughan 20 Dec '07

20 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Oi! That's my code you'd be ripping out! ;o) Terry, Sam _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com On 20/12/2007, at 2:34 PM, Terry Lambert wrote: On Dec 19, 2007, at 5:46 PM, Sam Vaughan wrote: On 19/12/2007, at 10:35 AM, Terry Lambert wrote: On Dec 13, 2007, at 8:41 PM, Sam Vaughan wrote: On 14/12/2007, at 7:05 AM, Terry Lambert <tlambert(a)apple.com> wrote: Given that subdirectories in /dev are not supported, and may be removed, if we end up needing to do that for some technical reason, it's probably better to just go that route on both 10.4 and 10.5 instead. This is probably the approach we will end up taking... just have to actually do it :) The reason for the subdirectories in the first place was to allow LUNs to be identified by the port and node WWNs on the host and RAID controller that uniquely described their path on the fibre channel network. The WWNs are too long to include in the one devfs node name, so the only option is to use a hierarchy. Subdirectories do not remove the node name length limit. I just got a chance to try devfs_make_node() again on Leopard and it still allows long path hierarchies just as it used to: $ find /dev/Curiosity -name Leopard -exec ls -l {} \; cr--r----- 1 root operator 17, 0 Dec 20 12:30 /dev/Curiosity/ got/the/better/of/me/so/I/dusted/off/some/old/code/to/try/a/deep/ dev/hierarchy/on/Leopard $ That's 104 characters. Try PATH_MAX (1024) characters instead. Why would I want to do that? It's the node name length of 32 that we were discussing. smime.p7s

1 0

Re: missing driver (AppleMacRiscPCI) at startup on G5
by Terry Lambert 20 Dec '07

20 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com The boot process is pretty well documented on developer.apple.com. -- Terry -Al- On Dec 19, 2007, at 1:31 PM, Terry Lambert wrote: -- Terry -Al- On Dec 18, 2007, at 2:38 PM, Terry Lambert wrote: You need to rebuild the KEXT cache, not the KEXT. man kextcache or http://developer.apple.com - Terry -Al- On Dec 18, 2007, at 1:25 PM, Terry Lambert wrote: Instead of removing the KEXT cache, rebuild it. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Copying is not going to work for these files, since there are some very particular requirements for the date stamps on kernel, files, directories, and the cache file itself for the cache to be considered trustworthy. Is there a particular reason you are messing with this on an already booting system, if you are not building your own kernel, or is it just burning curiousity? If the latter, there's a huge amount of documentation on the boot process at <http://developer.apple.com>. On Dec 19, 2007, at 6:03 PM, Al Ciplickas wrote: I finally got the bootcache.plist file copied over and the Extensions.mkext file written. But alas, it still did not want to start up. Same message as in the first note. So there must be something still missing. Do know what other files I might need at start up? -or where to study about startup necessities? I can't believe I'm the only one that has had this problem, but maybe I am. Feeling a bit dumb at the moment. Thanks, This is the first time I have ever heard of it. I had assumed that your problem was that you were building your own kernel, so the KEXT cache was out of date relative to the kernel, and the driver could not be loaded by the boot loader from the cache (it didn't match the kernel), and without a PCI driver, you couldn't load the PCI driver off disk. On Dec 18, 2007, at 8:44 PM, Al Ciplickas wrote: Thanks again, Terry. I tried the rebuild and the complaint was that there was not a usr/../bootcache.plist (or something to that effect). Can't imagine how that could have happened, since I was not aware of that file. So I thought doing an 'upgrade' from an Install DVD would solve the problem. No way. The upgrade finished normally, but there was neither the bootcache.plist nor the kextentions.cache (sp?) files. This is confusing, as I expect a system upgrade to make all the necessary files to do a normal startup. I will locate an active bootcache.plist from an existing system partition and copy it to the usr/../ directory to see if it will help me do the kextcache rebuild. Do you think this is an anomaly for me or has this happened many times before and I should file a radar report? On Dec 18, 2007, at 2:09 PM, Al Ciplickas wrote: Thanks, Terry. I'll rebuild the KEXT. But forgot how at the moment. Any hints? On Dec 18, 2007, at 12:00 PM, Al Ciplickas wrote: This is a new one for me: G5 complains about 'com.apple.driver.AppleMacRiscPCI' missing in the startup from 'kld_load_from_memory()'. I got that using <cmd-V> at startup. I used another system partition to look it the file was there (in System/Library/Extensions/) and it was! So I took out the kextensions.cache and its partner and tried again: still got the same complaint. (By the way, it says there are 1310 buffer headers and 1310 cluster IO buffer header, if that matters.) Do anyone know of something else to try? This is under OSX 10.4.10 as well as 10.4.2 (which I reloaded in hopes of clearing up "lost" files). The error is indicating that it's unable to load it from the cache that was loaded into memory by the boot loader. It can't read it off the disk itself because it can't even talk to the PCI bus on which the disk controller lives without this KEXT loaded. -- Terry This email sent to site_archiver(a)lists.apple.com

1 0

Re: [darwin-kernel] devfs_make_node mutilates pathname on Leopard?
by Terry Lambert 20 Dec '07

20 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com This is probably the approach we will end up taking... just have to actually do it :) Oi! That's my code you'd be ripping out! ;o) Terry, That's 104 characters. Try PATH_MAX (1024) characters instead. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On Dec 19, 2007, at 5:46 PM, Sam Vaughan wrote: On 19/12/2007, at 10:35 AM, Terry Lambert wrote: On Dec 13, 2007, at 8:41 PM, Sam Vaughan wrote: On 14/12/2007, at 7:05 AM, Terry Lambert <tlambert(a)apple.com> wrote: Given that subdirectories in /dev are not supported, and may be removed, if we end up needing to do that for some technical reason, it's probably better to just go that route on both 10.4 and 10.5 instead. The reason for the subdirectories in the first place was to allow LUNs to be identified by the port and node WWNs on the host and RAID controller that uniquely described their path on the fibre channel network. The WWNs are too long to include in the one devfs node name, so the only option is to use a hierarchy. Subdirectories do not remove the node name length limit. I just got a chance to try devfs_make_node() again on Leopard and it still allows long path hierarchies just as it used to: $ find /dev/Curiosity -name Leopard -exec ls -l {} \; cr--r----- 1 root operator 17, 0 Dec 20 12:30 /dev/Curiosity/ got/the/better/of/me/so/I/dusted/off/some/old/code/to/try/a/deep/dev/ hierarchy/on/Leopard $ This email sent to site_archiver(a)lists.apple.com

1 0

Re: missing driver (AppleMacRiscPCI) at startup on G5
by Al Ciplickas 20 Dec '07

20 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=m87w21fGAQgqPjigm/xeLQlK+VNGc37qsSTxL7GHRRjJnYk/1pPne8Q2I4aToIOD; h=Received:In-Reply-To:References:Mime-Version:Content-Type:Message-Id:Cc:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; -Al- On Dec 19, 2007, at 1:31 PM, Terry Lambert wrote: -- Terry -Al- On Dec 18, 2007, at 2:38 PM, Terry Lambert wrote: You need to rebuild the KEXT cache, not the KEXT. man kextcache or http://developer.apple.com - Terry -Al- On Dec 18, 2007, at 1:25 PM, Terry Lambert wrote: Instead of removing the KEXT cache, rebuild it. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… I finally got the bootcache.plist file copied over and the Extensions.mkext file written. But alas, it still did not want to start up. Same message as in the first note. So there must be something still missing. Do know what other files I might need at start up? -or where to study about startup necessities? I can't believe I'm the only one that has had this problem, but maybe I am. Feeling a bit dumb at the moment. Thanks, This is the first time I have ever heard of it. I had assumed that your problem was that you were building your own kernel, so the KEXT cache was out of date relative to the kernel, and the driver could not be loaded by the boot loader from the cache (it didn't match the kernel), and without a PCI driver, you couldn't load the PCI driver off disk. On Dec 18, 2007, at 8:44 PM, Al Ciplickas wrote: Thanks again, Terry. I tried the rebuild and the complaint was that there was not a usr/../bootcache.plist (or something to that effect). Can't imagine how that could have happened, since I was not aware of that file. So I thought doing an 'upgrade' from an Install DVD would solve the problem. No way. The upgrade finished normally, but there was neither the bootcache.plist nor the kextentions.cache (sp?) files. This is confusing, as I expect a system upgrade to make all the necessary files to do a normal startup. I will locate an active bootcache.plist from an existing system partition and copy it to the usr/../ directory to see if it will help me do the kextcache rebuild. Do you think this is an anomaly for me or has this happened many times before and I should file a radar report? On Dec 18, 2007, at 2:09 PM, Al Ciplickas wrote: Thanks, Terry. I'll rebuild the KEXT. But forgot how at the moment. Any hints? On Dec 18, 2007, at 12:00 PM, Al Ciplickas wrote: This is a new one for me: G5 complains about 'com.apple.driver.AppleMacRiscPCI' missing in the startup from 'kld_load_from_memory()'. I got that using <cmd-V> at startup. I used another system partition to look it the file was there (in System/Library/Extensions/) and it was! So I took out the kextensions.cache and its partner and tried again: still got the same complaint. (By the way, it says there are 1310 buffer headers and 1310 cluster IO buffer header, if that matters.) Do anyone know of something else to try? This is under OSX 10.4.10 as well as 10.4.2 (which I reloaded in hopes of clearing up "lost" files). The error is indicating that it's unable to load it from the cache that was loaded into memory by the boot loader. It can't read it off the disk itself because it can't even talk to the PCI bus on which the disk controller lives without this KEXT loaded. -- Terry This email sent to site_archiver(a)lists.apple.com

1 0

Re: [darwin-kernel] devfs_make_node mutilates pathname on Leopard?
by Sam Vaughan 20 Dec '07

20 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On 19/12/2007, at 10:35 AM, Terry Lambert wrote: Given that subdirectories in /dev are not supported, and may be removed, if we end up needing to do that for some technical reason, it's probably better to just go that route on both 10.4 and 10.5 instead. This is probably the approach we will end up taking... just have to actually do it :) Oi! That's my code you'd be ripping out! ;o) Terry, Sam _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com On Dec 13, 2007, at 8:41 PM, Sam Vaughan wrote: On 14/12/2007, at 7:05 AM, Terry Lambert <tlambert(a)apple.com> wrote: The reason for the subdirectories in the first place was to allow LUNs to be identified by the port and node WWNs on the host and RAID controller that uniquely described their path on the fibre channel network. The WWNs are too long to include in the one devfs node name, so the only option is to use a hierarchy. Subdirectories do not remove the node name length limit. I just got a chance to try devfs_make_node() again on Leopard and it still allows long path hierarchies just as it used to: $ find /dev/Curiosity -name Leopard -exec ls -l {} \; cr--r----- 1 root operator 17, 0 Dec 20 12:30 /dev/Curiosity/ got/the/better/of/me/so/I/dusted/off/some/old/code/to/try/a/deep/dev/ hierarchy/on/Leopard $ smime.p7s

1 0

Re: [darwin-kernel] devfs_make_node mutilates pathname on Leopard?
by Sam Vaughan 20 Dec '07

20 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On 19/12/2007, at 10:35 AM, Terry Lambert wrote: Given that subdirectories in /dev are not supported, and may be removed, if we end up needing to do that for some technical reason, it's probably better to just go that route on both 10.4 and 10.5 instead. This is probably the approach we will end up taking... just have to actually do it :) Oi! That's my code you'd be ripping out! ;o) I beg to differ, Terry. Sam _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com On Dec 13, 2007, at 8:41 PM, Sam Vaughan wrote: On 14/12/2007, at 7:05 AM, Terry Lambert <tlambert(a)apple.com> wrote: The reason for the subdirectories in the first place was to allow LUNs to be identified by the port and node WWNs on the host and RAID controller that uniquely described their path on the fibre channel network. The WWNs are too long to include in the one devfs node name, so the only option is to use a hierarchy. Subdirectories do not remove the node name length limit. It's been a long time since I was hacking on this stuff, but a quick look at devfs_tree.c suggests to me that a call to devfs_make_node() with a path containing slashes will result in dev_finddir() creating the intermediate directory nodes as needed. Each directory node can be DEVMAXNAMESIZE (32 characters) long, and the total path length can be up to DEVMAXPATHSIZE (128 characters). I may have missed something that's changed since the days of Darwin 6 when I was working on this, but I certainly used to create paths considerably longer than the node name length limit. smime.p7s

1 0

Re: missing driver (AppleMacRiscPCI) at startup on G5
by Al Ciplickas 19 Dec '07

19 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=NeKZhi8lrM0J4Uy/DfGOIBeMAsQsAjBh26/ZJhB68ZoGcOY7MeznfPo6xlEOdWTU; h=Received:In-Reply-To:References:Mime-Version:Content-Type:Message-Id:Cc:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; -Al- On Dec 19, 2007, at 1:31 PM, Terry Lambert wrote: -- Terry -Al- On Dec 18, 2007, at 2:38 PM, Terry Lambert wrote: You need to rebuild the KEXT cache, not the KEXT. man kextcache or http://developer.apple.com - Terry -Al- On Dec 18, 2007, at 1:25 PM, Terry Lambert wrote: Instead of removing the KEXT cache, rebuild it. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… I think what may have happened is that the SATA disk got hit with errors (there are hints of that). And it's possible that the usr/../ bootcache.plist file was unreadable (guessing). The system would never come up after Monday am. So I reinstalled the 10.4 system and hoped it would fix the missing/unreadable files (not really knowing which files were in trouble). It still did not work. So I did a compressed disk image of that partition (only one at that time) on to another drive. After that, I zeroed out the disk (hoping bad blocks would be disabled) and partitioned it into 2: one for a new system; the other for the old partition's restore. I then installed 10.5 on the new partition - everything worked fine. Later I restored the image file to the 2nd partition. It appeared to be fine, but it could never start up. So I asked for help and you were kind enough to point me at a start. And that process lead me to the missing usr/../bootcache.plist file. I tried to copy the 10.5 usr/../ bootcache.plist, but it compained about privileges and I hadn't turn on Root yet. That will be my next attempt this pm. I'll let you know what else I find - maybe it will work.. This is the first time I have ever heard of it. I had assumed that your problem was that you were building your own kernel, so the KEXT cache was out of date relative to the kernel, and the driver could not be loaded by the boot loader from the cache (it didn't match the kernel), and without a PCI driver, you couldn't load the PCI driver off disk. On Dec 18, 2007, at 8:44 PM, Al Ciplickas wrote: Thanks again, Terry. I tried the rebuild and the complaint was that there was not a usr/../bootcache.plist (or something to that effect). Can't imagine how that could have happened, since I was not aware of that file. So I thought doing an 'upgrade' from an Install DVD would solve the problem. No way. The upgrade finished normally, but there was neither the bootcache.plist nor the kextentions.cache (sp?) files. This is confusing, as I expect a system upgrade to make all the necessary files to do a normal startup. I will locate an active bootcache.plist from an existing system partition and copy it to the usr/../ directory to see if it will help me do the kextcache rebuild. Do you think this is an anomaly for me or has this happened many times before and I should file a radar report? On Dec 18, 2007, at 2:09 PM, Al Ciplickas wrote: Thanks, Terry. I'll rebuild the KEXT. But forgot how at the moment. Any hints? On Dec 18, 2007, at 12:00 PM, Al Ciplickas wrote: This is a new one for me: G5 complains about 'com.apple.driver.AppleMacRiscPCI' missing in the startup from 'kld_load_from_memory()'. I got that using <cmd-V> at startup. I used another system partition to look it the file was there (in System/Library/Extensions/) and it was! So I took out the kextensions.cache and its partner and tried again: still got the same complaint. (By the way, it says there are 1310 buffer headers and 1310 cluster IO buffer header, if that matters.) Do anyone know of something else to try? This is under OSX 10.4.10 as well as 10.4.2 (which I reloaded in hopes of clearing up "lost" files). The error is indicating that it's unable to load it from the cache that was loaded into memory by the boot loader. It can't read it off the disk itself because it can't even talk to the PCI bus on which the disk controller lives without this KEXT loaded. -- Terry This email sent to site_archiver(a)lists.apple.com

1 0

Re: missing driver (AppleMacRiscPCI) at startup on G5
by Terry Lambert 19 Dec '07

19 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com -- Terry -Al- On Dec 18, 2007, at 2:38 PM, Terry Lambert wrote: You need to rebuild the KEXT cache, not the KEXT. man kextcache or http://developer.apple.com - Terry -Al- On Dec 18, 2007, at 1:25 PM, Terry Lambert wrote: Instead of removing the KEXT cache, rebuild it. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This is the first time I have ever heard of it. I had assumed that your problem was that you were building your own kernel, so the KEXT cache was out of date relative to the kernel, and the driver could not be loaded by the boot loader from the cache (it didn't match the kernel), and without a PCI driver, you couldn't load the PCI driver off disk. On Dec 18, 2007, at 8:44 PM, Al Ciplickas wrote: Thanks again, Terry. I tried the rebuild and the complaint was that there was not a usr/../bootcache.plist (or something to that effect). Can't imagine how that could have happened, since I was not aware of that file. So I thought doing an 'upgrade' from an Install DVD would solve the problem. No way. The upgrade finished normally, but there was neither the bootcache.plist nor the kextentions.cache (sp?) files. This is confusing, as I expect a system upgrade to make all the necessary files to do a normal startup. I will locate an active bootcache.plist from an existing system partition and copy it to the usr/../ directory to see if it will help me do the kextcache rebuild. Do you think this is an anomaly for me or has this happened many times before and I should file a radar report? On Dec 18, 2007, at 2:09 PM, Al Ciplickas wrote: Thanks, Terry. I'll rebuild the KEXT. But forgot how at the moment. Any hints? On Dec 18, 2007, at 12:00 PM, Al Ciplickas wrote: This is a new one for me: G5 complains about 'com.apple.driver.AppleMacRiscPCI' missing in the startup from 'kld_load_from_memory()'. I got that using <cmd-V> at startup. I used another system partition to look it the file was there (in System/Library/Extensions/) and it was! So I took out the kextensions.cache and its partner and tried again: still got the same complaint. (By the way, it says there are 1310 buffer headers and 1310 cluster IO buffer header, if that matters.) Do anyone know of something else to try? This is under OSX 10.4.10 as well as 10.4.2 (which I reloaded in hopes of clearing up "lost" files). The error is indicating that it's unable to load it from the cache that was loaded into memory by the boot loader. It can't read it off the disk itself because it can't even talk to the PCI bus on which the disk controller lives without this KEXT loaded. -- Terry This email sent to site_archiver(a)lists.apple.com

1 0