Re: Device naming on scbus using isp
Dan Nelson wrote: If you're mounting UFS filesystems, you can label them and mount them by label (see the tunefs and glabel manpages for more info). ZFS should find its pool devices automatically, but you can always manually label devices with glabel and refer to the label instead of the da## name. Thanks Dan, I'm using UFS so looks like labeling will be the solution to this issue ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Device naming on scbus using isp
In the last episode (Sep 22), Brent Bloxam said: > Brent Bloxam wrote: > > I'm wondering about how device names are assigned on scbus, specifically > > when using the isp driver. It seems to me that there's potential when > > an HBA has access to multiple LUNs that on boot the scbus will have > > entries in /dev scrambled compared to the previous run (thus messing up > > mounts). My experience so far has been that da0 will be assigned to the > > first target scanned, da1 to the second, etc. Is this generally > > something countered with device.hints? If a LUN were to go away, but a > > device hint pointing to the target:unit remained, would that cause any > > issues on boot? > > Thought I'd follow up with a bit of information I've determined about > this, despite the lack of response from anyone on list. Maybe someone > will find it useful :) > > I can only speak for this applying to use of isp(4) with scbus(4). > > Devices that operate in target mode appear to isp(4) and are assigned a > target ID starting at 0. The order in which they appear depends on their > fcid or what's known to isp(4) as PortID. This order is ascending, so the > lower fcid takes precedence. isp(4) will then check the target to see if > any LUNs are available to it. If not, the target disappears -- and here's > the important thing to note -- but its target ID does not go away. > > Say you have 5 devices with the following fcids, 4 in target mode: > > 0x00 - target > 0x01 - target > 0x02 - another server with an HBA > 0xF0 - target with LUN > 0xF1 - target with LUN > > isp(4) is loaded at boot, and the following occurs: > > 0x00 appears, is assigned target 0, and disappears because there are no LUNs > 0x01 appears, is assigned target 1, and disappears because there are no LUNs > 0x02 appears and simply disappears because it is not a target > 0xF0 appears, is assigned target 2, and is assigned to da0 > 0xF1 appears, is assigned target 3, and is assigned to da1 > > You can see because of this example that maintaining device names using > /boot/device.hints is impossible if targets in the fabric change. If > 0x00 were to disappear, the target IDs would change and render > /boot/device.hints invalid, or worse, the wrong LUN could be given the > wrong device name. > > Ideally, there would be a way to assign target IDs by fcid, but that > does not exist presently. If you're mounting UFS filesystems, you can label them and mount them by label (see the tunefs and glabel manpages for more info). ZFS should find its pool devices automatically, but you can always manually label devices with glabel and refer to the label instead of the da## name. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Device naming on scbus using isp
Brent Bloxam wrote: I'm wondering about how device names are assigned on scbus, specifically when using the isp driver. It seems to me that there's potential when an HBA has access to multiple LUNs that on boot the scbus will have entries in /dev scrambled compared to the previous run (thus messing up mounts). My experience so far has been that da0 will be assigned to the first target scanned, da1 to the second, etc. Is this generally something countered with device.hints? If a LUN were to go away, but a device hint pointing to the target:unit remained, would that cause any issues on boot? Thanks, Brent Thought I'd follow up with a bit of information I've determined about this, despite the lack of response from anyone on list. Maybe someone will find it useful :) I can only speak for this applying to use of isp(4) with scbus(4). Devices that operate in target mode appear to isp(4) and are assigned a target ID starting at 0. The order in which they appear depends on their fcid or what's known to isp(4) as PortID. This order is ascending, so the lower fcid takes precedence. isp(4) will then check the target to see if any LUNs are available to it. If not, the target disappears -- and here's the important thing to note -- but its target ID does not go away. Say you have 5 devices with the following fcids, 4 in target mode: 0x00 - target 0x01 - target 0x02 - another server with an HBA 0xF0 - target with LUN 0xF1 - target with LUN isp(4) is loaded at boot, and the following occurs: 0x00 appears, is assigned target 0, and disappears because there are no LUNs 0x01 appears, is assigned target 1, and disappears because there are no LUNs 0x02 appears and simply disappears because it is not a target 0xF0 appears, is assigned target 2, and is assigned to da0 0xF1 appears, is assigned target 3, and is assigned to da1 You can see because of this example that maintaining device names using /boot/device.hints is impossible if targets in the fabric change. If 0x00 were to disappear, the target IDs would change and render /boot/device.hints invalid, or worse, the wrong LUN could be given the wrong device name. Ideally, there would be a way to assign target IDs by fcid, but that does not exist presently. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Device naming on scbus using isp
I'm wondering about how device names are assigned on scbus, specifically when using the isp driver. It seems to me that there's potential when an HBA has access to multiple LUNs that on boot the scbus will have entries in /dev scrambled compared to the previous run (thus messing up mounts). My experience so far has been that da0 will be assigned to the first target scanned, da1 to the second, etc. Is this generally something countered with device.hints? If a LUN were to go away, but a device hint pointing to the target:unit remained, would that cause any issues on boot? Thanks, Brent ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: 5.4 Generic Kernel - da and scbus...I'm at a loss
Thanks for the response. Did you have a problem with "opt_usbverbose.h"? I replaced the existing "usb_subr.c" with the patched version and have not been able to successfully compile the new kernel using it seemly due to "opt_usbverbose.h" not being found. Thanks, -Clay . . . . . - Original Message - From: "Sebastien" <[EMAIL PROTECTED]> To: Cc: <[EMAIL PROTECTED]> Sent: Sunday, November 06, 2005 3:23 PM Subject: Re: 5.4 Generic Kernel - da and scbus...I'm at a loss > I am a newbie to kernel related things. I'm running 5.4 using the generic > kernel. I am problems with using an iPod via USB, and it seems that I may > not have device support for sa and scbus in my kernel. I have been > searching for a few hours this evening using various criteria and am still > unable to get past this issue. > > It seems like the failure is that a device node /dev/da* for the umass > drive > isn't be created. Any help would be appreciated. I am going to try > booting > the 6.0 kernel off CD next and then go from there. I had the same problem with a "nano". I had many difficulties to find a way to solve it too. Finally this link helped me http://lists.freebsd.org/pipermail/freebsd-usb/2005-September/001534.html I patched /usr/src/sys/dev/usb/usb_subr.c as described, compiled my kernel again and it works... I'm not sure that it's the right way but it works... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.4 Generic Kernel - da and scbus...I'm at a loss
> I am a newbie to kernel related things. I'm running 5.4 using the generic > kernel. I am problems with using an iPod via USB, and it seems that I may > not have device support for sa and scbus in my kernel. I have been > searching for a few hours this evening using various criteria and am still > unable to get past this issue. > > It seems like the failure is that a device node /dev/da* for the umass drive > isn't be created. Any help would be appreciated. I am going to try booting > the 6.0 kernel off CD next and then go from there. I had the same problem with a "nano". I had many difficulties to find a way to solve it too. Finally this link helped me http://lists.freebsd.org/pipermail/freebsd-usb/2005-September/001534.html I patched /usr/src/sys/dev/usb/usb_subr.c as described, compiled my kernel again and it works... I'm not sure that it's the right way but it works... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.4 Generic Kernel - da and scbus...I'm at a loss
All, I am a newbie to kernel related things. I'm running 5.4 using the generic kernel. I am problems with using an iPod via USB, and it seems that I may not have device support for sa and scbus in my kernel. I have been searching for a few hours this evening using various criteria and am still unable to get past this issue. It seems like the failure is that a device node /dev/da* for the umass drive isn't be created. Any help would be appreciated. I am going to try booting the 6.0 kernel off CD next and then go from there. Thanks, -Clay ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.3: scbus & da in kernel config, umass as module: but no /dev/da* ?
On Sat, 12 Mar 2005 00:00:23 -0800 (PST) Rob <[EMAIL PROTECTED]> wrote: > Alejandro Pulver wrote: > > Rob wrote: > >> > >>I'm running FreeBSD 5.3. > >>I have following in my kernel config: > >> > >> device scbus > >> device da > >> device uhci > >> device usb > >> > >>hoping that this provides enough 'basic' usb > >>support for my usb-memory-stick. Indeed, I can > >>load the umass module. > >> > >>If I'm not wrong, I must do following to access the > >>usb-memory-stick: > >> mount -t msdosfs /dev/da0s1 /mnt > >> > >>but there's no /dev/da* device. > > > > Hello, > > > > I have a camera that is detected as an 'umass' > > storage device, and it appears as '/dev/da0' > > (strangely I can use it as a common storage > > device). This is my configuration: > > > > kernel options: > > > > device scbus > > device da > > device pass > > device uhci > > device ohci > > device usb > > device umass > > device ehci > > > > '/etc/rc.conf' options: > > > > usbd_enable="YES" > > > > To test it you can: > > > > 1) Check the devices in '/dev/daX'. > > 2) # camcontrol devlist > > 3) Check the boot messages (umass and da) and > >the messages printed when you plug the device. > > > > To mount it you have to select a slice (if it has > > data stored in): > > > > mount -t msdosfs /dev/da0s1 /mnt > > I do not have the cam device in the kernel config. > Do I have to? I also don't have umass in the > kernel config either, but I load that as a module > later; is that OK? > > Problem is that I do not have any /dev/da* devices, > with or without my memory stick in the usb port. > > I load umass module into the kernel, and then plug > the memory stick into the usb port. The console > gets then: > > umass0: EXATEL , Inc. I-BEAD Multi Player, rev > 1.10/0.01, addr 2 > umass0: Get Max Lun not supported (STALLED) > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Removable Direct Access > SCSI-4 device > da0: 1.000MB/s transfers > da0: 122MB (249856 512 byte sectors: 64H 32S/T 122C) > umass0: BBB reset failed, STALLED > umass0: BBB bulk-in clear stall failed, STALLED > umass0: BBB bulk-out clear stall failed, STALLED > [...last three lines repeated every minute or so...] > > > What does the "STALLED" mean here? > Is that critical? The "usbdevs -v" reports now: > > Controller /dev/usb0: > addr 1: full speed, self powered, config 1, UHCI > root hub(0x), Intel(0x), rev 1.00 > port 1 powered > port 2 addr 2: full speed, self powered, config 1, > i-Bead 100 MP3 Player(0x8008), Sigmatel(0x066f), > rev 0.01 > > But I have no /dev/da0 : > > # ls /dev/da* > ls: No match. > > So, the memory stick is detected at the USB port, > but I don't have the /dev/da* devices to mount the > memory stick (although devices da and scbus are in > my kernel config!). > When I remove the memory stick, I get following in > the console: > > umass0: at uhub0 port 2 (addr 2) disconnected > (da0:umass-sim0:0:0:0): lost device > (da0:umass-sim0:0:0:0): removing device entry > Opened disk da0 -> 5 > umass0: detached > > > What am I doing wrong? > > Thanks, > Rob. > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" Hello, I think your configuration is fine. I guess the problem is with the driver or maybe it needs some extra configuration. Your device is detected: umass0: EXATEL , Inc. I-BEAD Multi Player, rev 1.10/0.01, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-4 device da0: 1.000MB/s transfers da0: 122MB (249856 512 byte sectors: 64H 32S/T 122C) I think the source of the problem are these lines: umass0: Get Max Lun not supported (STALLED) umass0: BBB reset failed, STALLED umass0: BBB bulk-in clear stall failed, STALLED umass0: BBB bulk-out clear stall failed, STALLED [...last three lines repeated every minute or so...] I do not know how to solve this, but perhaps someone will answer you in the '[EMAIL PROTECTED]' list. Do not forget to provide the following information: 1) messages reported when booting/plugging/unplugging/ 2) # camcontrol devlist 3) # usbdevfs -v 4) error messages (STALLED) 5) FreeBSD version and kernel options related to USB Best Regards, Ale ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.3: scbus & da in kernel config, umass as module: but no /dev/da* ?
> Alejandro Pulver wrote: >> Rob wrote: >>> >>>I'm running FreeBSD 5.3. >>>I have following in my kernel config: >>> >>> device scbus >>> device da >>> device uhci >>> device usb >>> >>>hoping that this provides enough 'basic' usb >>>support for my usb-memory-stick. Indeed, I can >>>load the umass module. >>> >>>If I'm not wrong, I must do following to access the >>>usb-memory-stick: >>> mount -t msdosfs /dev/da0s1 /mnt >>> >>>but there's no /dev/da* device. >> >> Hello, >> >> I have a camera that is detected as an 'umass' >> storage device, and it appears as '/dev/da0' >> (strangely I can use it as a common storage >> device). This is my configuration: >> >> kernel options: >> >> device scbus >> device da >> device pass >> device uhci >> device ohci >> device usb >> device umass >> device ehci >> >> '/etc/rc.conf' options: >> >> usbd_enable="YES" >> >> To test it you can: >> >> 1) Check the devices in '/dev/daX'. >> 2) # camcontrol devlist >> 3) Check the boot messages (umass and da) and >>the messages printed when you plug the device. >> >> To mount it you have to select a slice (if it has >> data stored in): >> >> mount -t msdosfs /dev/da0s1 /mnt > > I do not have the cam device in the kernel config. > Do I have to? I also don't have umass in the > kernel config either, but I load that as a module > later; is that OK? > > Problem is that I do not have any /dev/da* devices, > with or without my memory stick in the usb port. > > I load umass module into the kernel, and then plug > the memory stick into the usb port. The console > gets then: > > umass0: EXATEL , Inc. I-BEAD Multi Player, rev > 1.10/0.01, addr 2 > umass0: Get Max Lun not supported (STALLED) > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Removable Direct Access > SCSI-4 device > da0: 1.000MB/s transfers > da0: 122MB (249856 512 byte sectors: 64H 32S/T 122C) > umass0: BBB reset failed, STALLED > umass0: BBB bulk-in clear stall failed, STALLED > umass0: BBB bulk-out clear stall failed, STALLED > [...last three lines repeated every minute or so...] > > > What does the "STALLED" mean here? > Is that critical? The "usbdevs -v" reports now: > > Controller /dev/usb0: > addr 1: full speed, self powered, config 1, UHCI > root hub(0x), Intel(0x), rev 1.00 > port 1 powered > port 2 addr 2: full speed, self powered, config 1, > i-Bead 100 MP3 Player(0x8008), Sigmatel(0x066f), > rev 0.01 > > But I have no /dev/da0 : > > # ls /dev/da* > ls: No match. > > So, the memory stick is detected at the USB port, > but I don't have the /dev/da* devices to mount the > memory stick (although devices da and scbus are in > my kernel config!). > When I remove the memory stick, I get following in > the console: > > umass0: at uhub0 port 2 (addr 2) disconnected > (da0:umass-sim0:0:0:0): lost device > (da0:umass-sim0:0:0:0): removing device entry > Opened disk da0 -> 5 > umass0: detached > > > What am I doing wrong? > > Thanks, > Rob. > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" I don't know about FreeBSD but in linux i used "fdisk -l" (lowercase L) to list the partitions on a device. This helped identify for a start what the device was and also what partition I needed to mount. Also in linux for some reason my USB memory stick appeared as a SCSI device alongside my SATA hard disk and my firewire connected iPod. All a bit odd really :/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.3: scbus & da in kernel config, umass as module: but no /dev/da* ?
Alejandro Pulver wrote: > Rob wrote: >> >>I'm running FreeBSD 5.3. >>I have following in my kernel config: >> >> device scbus >> device da >> device uhci >> device usb >> >>hoping that this provides enough 'basic' usb >>support for my usb-memory-stick. Indeed, I can >>load the umass module. >> >>If I'm not wrong, I must do following to access the >>usb-memory-stick: >> mount -t msdosfs /dev/da0s1 /mnt >> >>but there's no /dev/da* device. > > Hello, > > I have a camera that is detected as an 'umass' > storage device, and it appears as '/dev/da0' > (strangely I can use it as a common storage > device). This is my configuration: > > kernel options: > > device scbus > device da > device pass > device uhci > device ohci > device usb > device umass > device ehci > > '/etc/rc.conf' options: > > usbd_enable="YES" > > To test it you can: > > 1) Check the devices in '/dev/daX'. > 2) # camcontrol devlist > 3) Check the boot messages (umass and da) and >the messages printed when you plug the device. > > To mount it you have to select a slice (if it has > data stored in): > > mount -t msdosfs /dev/da0s1 /mnt I do not have the cam device in the kernel config. Do I have to? I also don't have umass in the kernel config either, but I load that as a module later; is that OK? Problem is that I do not have any /dev/da* devices, with or without my memory stick in the usb port. I load umass module into the kernel, and then plug the memory stick into the usb port. The console gets then: umass0: EXATEL , Inc. I-BEAD Multi Player, rev 1.10/0.01, addr 2 umass0: Get Max Lun not supported (STALLED) da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-4 device da0: 1.000MB/s transfers da0: 122MB (249856 512 byte sectors: 64H 32S/T 122C) umass0: BBB reset failed, STALLED umass0: BBB bulk-in clear stall failed, STALLED umass0: BBB bulk-out clear stall failed, STALLED [...last three lines repeated every minute or so...] What does the "STALLED" mean here? Is that critical? The "usbdevs -v" reports now: Controller /dev/usb0: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 addr 2: full speed, self powered, config 1, i-Bead 100 MP3 Player(0x8008), Sigmatel(0x066f), rev 0.01 But I have no /dev/da0 : # ls /dev/da* ls: No match. So, the memory stick is detected at the USB port, but I don't have the /dev/da* devices to mount the memory stick (although devices da and scbus are in my kernel config!). When I remove the memory stick, I get following in the console: umass0: at uhub0 port 2 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry Opened disk da0 -> 5 umass0: detached What am I doing wrong? Thanks, Rob. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.3: scbus & da in kernel config, umass as module: but no /dev/da* ?
On Thu, 10 Mar 2005 22:41:58 -0800 (PST) Rob <[EMAIL PROTECTED]> wrote: > > Hi, > > I'm running FreeBSD 5.3. > I have following in my kernel config: > > device scbus > device da > device uhci > device usb > > hoping that this provides enough 'basic' usb support > for my usb-memory-stick. Indeed, I can load the > umass module. > > If I'm not wrong, I must do following to access the > usb-memory-stick: >mount -t msdos /dev/da0 /mnt > > but there's no /dev/da* device. > > So what should I do instead? > > Thanks, > Rob. > > > > > __ > Do you Yahoo!? > Make Yahoo! your home page > http://www.yahoo.com/r/hs > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" Hello, I have a camera that is detected as an 'umass' storage device, and it appears as '/dev/da0' (strangely I can use it as a common storage device). This is my configuration: kernel options: device scbus device da device pass device uhci device ohci device usb device umass device ehci '/etc/rc.conf' options: usbd_enable="YES" To test it you can: 1) Check the devices in '/dev/daX'. 2) # camcontrol devlist 3) Check the boot messages (umass and da) and the messages printed when you plug the device. To mount it you have to select a slice (if it has data stored in): mount -t msdosfs /dev/da0s1 /mnt Hope that helps. Best Regards, Ale ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.3: scbus & da in kernel config, umass as module: but no /dev/da* ?
Hi, I'm running FreeBSD 5.3. I have following in my kernel config: device scbus device da device uhci device usb hoping that this provides enough 'basic' usb support for my usb-memory-stick. Indeed, I can load the umass module. If I'm not wrong, I must do following to access the usb-memory-stick: mount -t msdos /dev/da0 /mnt but there's no /dev/da* device. So what should I do instead? Thanks, Rob. __ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: scbus
On Sun, Jul 27, 2003 at 07:30:27PM -0700, Tom Samplonius wrote: > > On Sun, 27 Jul 2003, marlon corleone wrote: > > > device scbus # SCSI bus (required) > > device da > > > > since i have ni scsi device > ... > > I don't think you can remove it, because it is used by a lot of stuff > you wouldn't normally associate with SCSI (ex. USB). It's perfectly possible (and *very* commonly done) to remove it as long as you don't leave in anything else that requires it. These dependencies are clearly labelled in LINT and GENERIC, so they're easy to find if you just read the comments in the file. Kris pgp0.pgp Description: PGP signature
scbus
On Sun, 27 Jul 2003, marlon corleone wrote: > device scbus # SCSI bus (required) > device da > > since i have ni scsi device ... I don't think you can remove it, because it is used by a lot of stuff you wouldn't normally associate with SCSI (ex. USB). Tom ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel config problem with scbus
On Thu, 17 Oct 2002, Ceri Davies wrote: > On Tue, Oct 15, 2002 at 07:26:06PM -0700, Kevin Stevens wrote: > > In the Handbook, it says that if you are compiling for an IDE-only > > system, you can remove the following: > > > > # SCSI peripherals > > device scbus # SCSI bus (required) > > > > However, if I comment this out (along with the various SCSI controllers > > and devices), the make fails. I can take everything else out but that > > one line and have success. > > > > Can anyone duplicate/explain? > > You probably have the umass device enabled - this requires scbus. > > Ceri Thanks Ceri, I'm sure that's the explanation! I've been missing that dependency over and over again reading through the config file. KeS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: Kernel config problem with scbus
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Kevin, Wednesday, October 16, 2002, 5:26:06 AM, you wrote: KS> I'm trying to do "old-style" kernel builds with 4.7 (though I've run KS> into this same issue with earlier releases and other motherboards). KS> In the Handbook, it says that if you are compiling for an IDE-only KS> system, you can remove the following: KS> # SCSI peripherals KS> device scbus # SCSI bus (required) KS> However, if I comment this out (along with the various SCSI controllers KS> and devices), the make fails. I can take everything else out but that KS> one line and have success. KS> Can anyone duplicate/explain? Just compiled new kernel on RELENG_4_7 tree without scbus - no problems. Look again at you kernel config - maybe some SCSI devices still present there. You may also try the following: 1. rm -rf /usr/obj 2. Re-cvsup 3. cd /usr/src; make buildkernel KERNCONF= - -- Best regards, Artemmailto:aokounev@;yahoo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (MingW32) iD8DBQE9rpdNbOuJ0KL1C+MRAquLAJ9SOZdrur4FXQoiUtYWSDp0JvuX+wCgzyCN n5ylQB54xeoHzNcJjRnZBH4= =PDGk -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: Kernel config problem with scbus
On Tue, Oct 15, 2002 at 07:26:06PM -0700, Kevin Stevens wrote: > I'm trying to do "old-style" kernel builds with 4.7 (though I've run > into this same issue with earlier releases and other motherboards). > > In the Handbook, it says that if you are compiling for an IDE-only > system, you can remove the following: > > # SCSI peripherals > device scbus # SCSI bus (required) > > However, if I comment this out (along with the various SCSI controllers > and devices), the make fails. I can take everything else out but that > one line and have success. > > Can anyone duplicate/explain? You probably have the umass device enabled - this requires scbus. Ceri -- you can't see when light's so strong you can't see when light is gone To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Kernel config problem with scbus
I'm trying to do "old-style" kernel builds with 4.7 (though I've run into this same issue with earlier releases and other motherboards). In the Handbook, it says that if you are compiling for an IDE-only system, you can remove the following: # SCSI peripherals device scbus # SCSI bus (required) However, if I comment this out (along with the various SCSI controllers and devices), the make fails. I can take everything else out but that one line and have success. Can anyone duplicate/explain? KeS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
