setting quotas _inside_ a jail for users _inside_ a jail
Hello, I realize the difficulties in trying to use quotas on the _host_ system to limit the size of jails on the host system - userid mapping, etc. This is not what I am asking. I wonder, is it possible for the root user of a jail to set quotas _inside_ her jail for users _inside_ her jail ? Can anyone simply confirm or deny that this is possible ? Simply following normal protocol does not work, because if you place filesystem entries into /etc/fstab inside the jail, the jail will no longer start, as it does not have permission to mount or otherwise manipulate those filesystems. Comments ? Thoughts ? Confirmations or denials ? thnaks! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: setting quotas _inside_ a jail for users _inside_ a jail
On Fri, 30 Aug 2002, Patrick Thomas wrote: > I wonder, is it possible for the root user of a jail to set quotas > _inside_ her jail for users _inside_ her jail ? Can anyone simply confirm > or deny that this is possible ? You can't. You have to set quota from the host machine over something like ssh and customized tool. *** WBR, Alexey Zakirov ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VMware 3 on FreeBSD?
You might get it to run under Linux emulation... I've never tried it though. The VMWare documentation for even version 3.1 indicates FreeBSD support as a client OS only. I assume you knew that, but I wanted to save you the trouble of a possible "wild-goose-chase" id you didn't. Good luck! -Richard On Tue, Aug 27, 2002 at 02:30:54PM +0200, Stijn Hoop wrote: > Hi, > > sent this to -questions a week ago, got no response, so I'm asking > again here: is it possible to run VMware 3 on -STABLE? If so, how? > I noticed there is no port like there is for VMware 2, so that's > why I'm asking. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VMware 3 on FreeBSD?
On Wed, Aug 28, 2002 at 11:09:57AM -0400, Richard Stanaford wrote: > The VMWare documentation for even version 3.1 indicates FreeBSD support > as a client OS only. If you check the small print, that's what it says. Having said that though, I have had 3.0 running as well as 2.0, under -STABLE, using COMPAT_LINUX. BMS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VMware 3 on FreeBSD?
Of course we run Vmware 2 under emulation. So vmware 3 MUST be run under emulation. As has been said before, it probably runs but the setup program looks for too many linux specifics and doesn't generate a good config file. It just takes someone to figure out what it needs. On Wed, 28 Aug 2002, Richard Stanaford wrote: > > You might get it to run under Linux emulation... I've never tried it > though. > > The VMWare documentation for even version 3.1 indicates FreeBSD support > as a client OS only. > > I assume you knew that, but I wanted to save you the trouble of a > possible "wild-goose-chase" id you didn't. > > Good luck! > -Richard > > > On Tue, Aug 27, 2002 at 02:30:54PM +0200, Stijn Hoop wrote: > > > Hi, > > > > sent this to -questions a week ago, got no response, so I'm asking > > again here: is it possible to run VMware 3 on -STABLE? If so, how? > > I noticed there is no port like there is for VMware 2, so that's > > why I'm asking. > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: More dynamic KVA_SPACE
Terry Lambert writes: > Wilko Bulte wrote: > > > I knew not to recommend the Alpha because it is limited to 2G > > > of physical memory. > > > > ? > > > > FreeBSD is limited to using 2G of whatever you have in the Alpha. > > Which is a deficiency that has been debated a number of times, > > IIRC it needs bus space work etc. See the archives.. > > I know... which is why I didn't recommend it. 8-). Not bus space, busdma! The 2GB limit is due to the lack of MI PCI device driver support for busdma. Especially network drivers, most scsi drivers already do busdma. So as soon as other platforms work with more than the size of their direct map (whatever it happens to be), alpha will too. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: top shows all zeroes.
In message <[EMAIL PROTECTED]>, Patrick Thomas writes: > > And more important;y, does anyone know _why_ it is happening and what it > means for a system affected ? I had this occur once. As it turned out, one of the clocks in the clock chip was hooped. Replacing the motherboard fixed the problem. -- Cheers, Phone: 250-387-8437 Cy SchubertFax: 250-387-5766 Team Leader, Sun/Alpha Team Email: [EMAIL PROTECTED] Open Systems Group, CITS Ministry of Management Services Province of BC FreeBSD UNIX: [EMAIL PROTECTED] > > > > On Sat, 24 Aug 2002, Bruce M Simpson wrote: > > > On Sat, Aug 24, 2002 at 12:23:45AM -0700, Patrick Thomas wrote: > > > I have seen this twice on 4.6.1-RC2: > > [..] > > > CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% > > > idle > > [..] > > > > This is happening on my Vaio also; has anyone filed a PR? > > > > FreeBSD triage.dollah.com 4.6-STABLE FreeBSD 4.6-STABLE #0: Tue Aug 20 13:0 > 0:06 BST 2002 [EMAIL PROTECTED]:/usr/src/sys/compile/TRIAGE i386 > > > > BMS > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: More dynamic KVA_SPACE
Another interesting processor family is the AMD x86-64 ClawHammer. I do not know the progress the FreeBSD/x86-64 project. I would imagine the major difficulty will be getting a running compiler. I just wish AMD added an 8K page size so the Page Table Maps did not eat so much memory. --mark tinguely To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: More dynamic KVA_SPACE
Ut-oh. Time for a rant...
mark tinguely wrote:
> Another interesting processor family is the AMD x86-64 ClawHammer.
> I do not know the progress the FreeBSD/x86-64 project. I would imagine
> the major difficulty will be getting a running compiler.
Actually, the major difficulty is getting a box, given that these
things were originally supposed to been out a while ago, and AMD
keeps not selling the damn things. Running simulated hardware on
hardware you can already buy off the street really doesn't have a
very big thrill factor, since you might as well run not simulated,
get the same boot messages and programs running, only much, much
faster.
For all we know, AMD has gotten out of the new Silicon business all
together, and will simply be shipping upgraded simulators of things
which would be cool if they were ever taped out, plactic'ed, and
slotted in a ZIF in non-existant motherboards, but which, in reality,
never make it to glass. Sort of the chip equivalent of the .COM
business model ("Here's my impression of an eyeball").
> I just wish AMD added an 8K page size so the Page Table Maps did not
> eat so much memory.
More proof that hardware people don't ask software people how they
expect to use the hardware after it's built. Same class of problem
that the Diamond video cards had ...i.e. BIOS written by a hardware
person that didn't have a data table at a findable offset with a version
number, so you could only INT 10 the thing to guarantee that you would
not cook the card and/or your monitor. They just didn't believe
software people would ever want or need to use an interface that did
not disable hardware interrupts for the whole system in order to avoid
vertical blanking, since the most important component of any computer
is the sparklie-free Diamond video card lacking dual ported RAM.
Any hardware vendor who creates a polled interface for their chips
is doing the same thing ...i.e. the most important thing any computer
can be doing at any point in time is asking our chip if it has more
data available for processing, because it's not like the CPU has any
other work to do, and even if it did, it's nowhere near as important
as talking to our hardware.
Hardware is so annoying. So unlike software... 8-) 8-) 8-).
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
[no subject]
Has anyone got this to work yet? Is it something that will get fixed with fbsd, or will it tack a bios upgrade from intel? I was wondering if there is a way to just hardcode this value for the time being, I know that my box has two Intel SE7500CW2 CPUs in it. Could this whole problem be replaced by a: #define NUM_CPUS 2 ... return NUM_CPUS; Maybe I am being naive in thinking this would even work? Thanks for your help, Jonathan Feldkamp >Hello, > >I tried the changes outlined on the list, but SMP still fails >at the same >point. Any further suggestions? There's quite a few users >with >this issue. >A friend of mine went through the lists and counted 18 the >other day. > >Thanks, >Craig To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Intel SE7500CW2
Has anyone got this to work yet? Is it something that will get fixed with fbsd, or will it tack a bios upgrade from intel? I was wondering if there is a way to just hardcode this value for the time being, I know that my box has two Intel SE7500CW2 CPUs in it. Could this whole problem be replaced by a: #define NUM_CPUS 2 ... return NUM_CPUS; Maybe I am being naive in thinking this would even work? Thanks for your help, Jonathan Feldkamp >Hello, > >I tried the changes outlined on the list, but SMP still fails >at the same >point. Any further suggestions? There's quite a few users >with >this issue. >A friend of mine went through the lists and counted 18 the >other day. > >Thanks, >Craig To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: setting quotas _inside_ a jail for users _inside_ a jail
On Fri, Aug 30, 2002 at 12:41:54AM -0700, Patrick Thomas wrote: > > I wonder, is it possible for the root user of a jail to set quotas > _inside_ her jail for users _inside_ her jail ? Can anyone simply confirm > or deny that this is possible ? Yes, it is possible. The following procedure (assuming I documented it properly here) works fine. We make the following assumptions: We want quotas within the jail. We don't care about matching userids from the jail to the server This is not undoable but it means synccing the password file which we consider pointless. We do not try to apply quotas to the jailed server by running any quota tools on the main server. To administer quotas on the jail, we log into the jail to do it. If you find something wrong in here, please let me know. Now that I've taken the time to write it all down, I will make some noise about getting it into the documentation. This REALLY, REALLY should be in the handbook. Was a bear to figure out the first time. For this example server (S) runs a jail (J) with a mount point of /J. So J:/foo is the same file as S:/J/foo. In S:/etc/fstab, for the filesystems to be quotaed, you must specify a location which will be available to the jail. Assuming we will start J with a mount point of /J, this example will work for user home directories within the jail (the nosuid,nodev is optional) /dev/da0s1d /J/home ufs rw,nosuid,nodev,userquota=/J/usr/quotas/J.home 2 2 Copy only the lines that have quotas from S:/etc/fstab to J:/etc/fstab On each of these lines, add the option noauoto and remove the original mount point. So, the example would put into J:/etc/fstab: /dev/da0s1d /home ufs rw,nosuid,nodev,userquota=/usr/quotas/J.home,noauto 2 2 ^ ^ ^^ | | |-MUST have no auto here! | | Removed the jail mount point|-Removed the jail mount point in S:/etc/rc.conf: enable_quotas="YES" # turn on quotas on startup Now there are some problems in /etc/rc. The following patch deals with these, if in a somewhat inelegant way. Ideally, /etc/rc would use "if jail" around these, making /etc/rc usable inside as well as outside of jails. Note that the instructions continue FOLLOWING the patch! *** rc.ORIG Fri Aug 30 12:56:34 2002 --- rc Fri Aug 30 12:56:59 2002 *** *** 38,44 # first before contemplating any changes here. If you do need to change # this file for some reason, we would like to know about it. ! # Msen off for jails stty status '^T' # Set shell to ignore SIGINT (2), but not children; # shell catches SIGQUIT (3) and returns to single user after fsck. --- 38,44 # first before contemplating any changes here. If you do need to change # this file for some reason, we would like to know about it. ! stty status '^T' # Set shell to ignore SIGINT (2), but not children; # shell catches SIGQUIT (3) and returns to single user after fsck. *** *** 179,185 set -T trap "echo 'Reboot interrupted'; exit 1" 3 - if [ "" ]; then # Msen shuts off ALL mount/umount activity for jails # root normally must be read/write, but if this is a BOOTP NFS # diskless boot it does not have to be. # --- 179,184 *** *** 214,220 ;; esac - fi# Msen shuts off ALL mount/umount activity for jails adjkerntz -i --- 213,218 Insure you have quotas in your kernel. Reboot S. Log into J and ues edquota to apply one quota to one account. Reboot S again. At this point, you should be able to log into J and use all the normal quota tools as desired. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ultra320 drivers?
Peter Wemm wrote: > Lars Eggert wrote: >> >>We just got a bunch of Dell machines that have this controller as well. >>Any news about support in sym? > > No, you want the 'mpt' driver that Matt Jacob recently committed. The 1030 > has nothing in common with sym. I backported the mpt driver from -STABLE to 4.6-RELEASE, and it is recognized correctly: mpt0: port 0xdc00-0xdcff mem 0xff6a-0xff6b,0xff6c-0xff6d irq 18 at device 12.0 on pci3 mpt1: port 0xd800-0xd8ff mem 0xff66-0xff67,0xff68-0xff69 irq 19 at device 12.1 on pci3 However, my drives aren't attached as Ultra-320 but at much lower speeds: da0 at mpt1 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 62.500MB/s transfers (31.250MHz, offset 31, 16bit), Tagged Queueing Enabled da0: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) da1 at mpt1 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 62.500MB/s transfers (31.250MHz, offset 31, 16bit), Tagged Queueing Enabled da1: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) When I hook them up to the Ultra-160 onboard Adaptec chip, things look better: ahc0: port 0xd400-0xd4ff mem 0xff6fe000-0xff6fefff irq 14 at device 14.0 on pci3 aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs ... da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled da1: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) Any ideas on how to make mpt use Ultra-320 to talk to the drives? Thanks, Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Ultra320 drivers?
On Fri, Aug 30, 2002 at 12:11:12 -0700, Lars Eggert wrote: > Peter Wemm wrote: > > Lars Eggert wrote: > >> > >>We just got a bunch of Dell machines that have this controller as well. > >>Any news about support in sym? > > > > No, you want the 'mpt' driver that Matt Jacob recently committed. The 1030 > > has nothing in common with sym. > > I backported the mpt driver from -STABLE to 4.6-RELEASE, and it is > recognized correctly: > > mpt0: port 0xdc00-0xdcff mem > 0xff6a-0xff6b,0xff6c-0xff6d irq 18 at device 12.0 on pci3 > mpt1: port 0xd800-0xd8ff mem > 0xff66-0xff67,0xff68-0xff69 irq 19 at device 12.1 on pci3 > > However, my drives aren't attached as Ultra-320 but at much lower speeds: > > da0 at mpt1 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-3 device > da0: 62.500MB/s transfers (31.250MHz, offset 31, 16bit), Tagged Queueing > Enabled > da0: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da1 at mpt1 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-3 device > da1: 62.500MB/s transfers (31.250MHz, offset 31, 16bit), Tagged Queueing > Enabled > da1: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > > When I hook them up to the Ultra-160 onboard Adaptec chip, things look > better: > > ahc0: port 0xd400-0xd4ff mem > 0xff6fe000-0xff6fefff irq 14 at device 14.0 on pci3 > aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs > ... > da0 at ahc0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-3 device > da0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged > Queueing Enabled > da0: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da1 at ahc0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-3 device > da1: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged > Queueing Enabled > da1: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > > Any ideas on how to make mpt use Ultra-320 to talk to the drives? Did you also backport rev 1.35 and 1.36 of scsi_all.c? You may need that as well. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Copying from Virtual Address Space to Physical Address
Hi, Is there some function using which I can copy data from the Kernel Virtual Space to a pinned Physical Address Page. Thanx, Pavan Balaji, Intel Corporation Email: [EMAIL PROTECTED] "Only the Paranoid Survive" -- Andy Grove To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ultra320 drivers?
Kenneth D. Merry wrote: > > Did you also backport rev 1.35 and 1.36 of scsi_all.c? > You may need that as well. Good catch, I missed that file. After applying that patch, they now seem to be detected correctly: da0 at mpt1 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers (160.000MHz, offset 31, 16bit), Tagged Queueing Enabled da0: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) da1 at mpt1 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 320.000MB/s transfers (160.000MHz, offset 31, 16bit), Tagged Queueing Enabled da1: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) The bad news is that any kind of extended disk activity (e.g. kernel building), results in a ton of unhealthy messages like this: mpt1: time out on request index = 0xe4 sequence = 0x0cad mpt1: Status 0001; Mask 0001; Doorbell 2400 request state On Chip SCSI IO Request @ 0xff807f34 Chain Offset 0x00 MsgFlags 0x00 MsgContext0x00e4 Bus:0 TargetID1 SenseBufferLength 32 LUN: 0x0 Control 0x0100 WRITE SIMPLEQ DataLength 0x4000 SenseBufAddr0x0005d9e0 CDB[0:10] 2a 00 01 3f e1 9f 00 00 20 00 SE32 0xdc3c2830: Addr=0xd0f3000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xdc3c2838: Addr=0xd034000 FlagsLength=0x14002000 HOST_TO_IOC SE32 0xdc3c2840: Addr=0xd136000 FlagsLength=0xd5001000 HOST_TO_IOC LAST_ELEMENT END_OF_BUFFER END_OF_LIST mpt1: mpt_done: corrupted ccb, index = 0xe4 seq = 0x0cad request state Timeout mpt_request: SCSI IO Request @ 0xff807e88 Chain Offset 0x00 MsgFlags 0x00 MsgContext0x00e4 Bus:0 TargetID1 SenseBufferLength 32 LUN: 0x0 Control 0x0100 WRITE SIMPLEQ DataLength 0x4000 SenseBufAddr0x0005d9e0 CDB[0:10] 2a 00 01 3f e1 9f 00 00 20 00 SE32 0xdc3c2830: Addr=0xd0f3000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xdc3c2838: Addr=0xd034000 FlagsLength=0x14002000 HOST_TO_IOC SE32 0xdc3c2840: Addr=0xd136000 FlagsLength=0xd5001000 HOST_TO_IOC LAST_ELEMENT END_OF_BUFFER END_OF_LIST mpt_done: context reply: 0x00e4 Did I miss any more pieces? Nothing under sys/cam seemed recent enough. Thanks, Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Copying from Virtual Address Space to Physical Address
On Fri, 30 Aug 2002, Balaji, Pavan wrote: > Hi, > > Is there some function using which I can copy data from the Kernel Virtual > Space to a pinned Physical Address Page. Not as such, though there are plenty of places that do such a thing. The answer is always to map the physical page somewhere into kernel space. This is true because the processer can not access pages by their physical address once it is in virtual address mode. Physio() does this.. first it finds the physical addresses of the user pages targetted, then it maps those pages into kernel space, and then it initiates IO to them. (this actually needs to change but for now it's true. > > Thanx, > > Pavan Balaji, > Intel Corporation > Email: [EMAIL PROTECTED] > > "Only the Paranoid Survive" -- Andy Grove "until they die of ulcers" :-) > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ultra320 drivers?
On Fri, Aug 30, 2002 at 12:50:14 -0700, Lars Eggert wrote: > Kenneth D. Merry wrote: > > > > Did you also backport rev 1.35 and 1.36 of scsi_all.c? > > You may need that as well. > > Good catch, I missed that file. After applying that patch, they now seem > to be detected correctly: > > da0 at mpt1 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-3 device > da0: 320.000MB/s transfers (160.000MHz, offset 31, 16bit), Tagged > Queueing Enabled > da0: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > da1 at mpt1 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-3 device > da1: 320.000MB/s transfers (160.000MHz, offset 31, 16bit), Tagged > Queueing Enabled > da1: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) > > The bad news is that any kind of extended disk activity (e.g. kernel > building), results in a ton of unhealthy messages like this: > > mpt1: time out on request index = 0xe4 sequence = 0x0cad > mpt1: Status 0001; Mask 0001; Doorbell 2400 > request state On Chip > SCSI IO Request @ 0xff807f34 > Chain Offset 0x00 > MsgFlags 0x00 > MsgContext0x00e4 > Bus:0 > TargetID1 > SenseBufferLength 32 > LUN: 0x0 > Control 0x0100 WRITE SIMPLEQ > DataLength0x4000 > SenseBufAddr 0x0005d9e0 > CDB[0:10] 2a 00 01 3f e1 9f 00 00 20 00 > SE32 0xdc3c2830: Addr=0xd0f3000 FlagsLength=0x14001000 > HOST_TO_IOC > SE32 0xdc3c2838: Addr=0xd034000 FlagsLength=0x14002000 > HOST_TO_IOC > SE32 0xdc3c2840: Addr=0xd136000 FlagsLength=0xd5001000 > HOST_TO_IOC LAST_ELEMENT END_OF_BUFFER END_OF_LIST > mpt1: mpt_done: corrupted ccb, index = 0xe4 seq = 0x0cad request > state Timeout > mpt_request: > SCSI IO Request @ 0xff807e88 > Chain Offset 0x00 > MsgFlags 0x00 > MsgContext0x00e4 > Bus:0 > TargetID1 > SenseBufferLength 32 > LUN: 0x0 > Control 0x0100 WRITE SIMPLEQ > DataLength0x4000 > SenseBufAddr 0x0005d9e0 > CDB[0:10] 2a 00 01 3f e1 9f 00 00 20 00 > SE32 0xdc3c2830: Addr=0xd0f3000 FlagsLength=0x14001000 > HOST_TO_IOC > SE32 0xdc3c2838: Addr=0xd034000 FlagsLength=0x14002000 > HOST_TO_IOC > SE32 0xdc3c2840: Addr=0xd136000 FlagsLength=0xd5001000 > HOST_TO_IOC LAST_ELEMENT END_OF_BUFFER END_OF_LIST > mpt_done: context reply: 0x00e4 > > Did I miss any more pieces? Nothing under sys/cam seemed recent enough. I don't think there are any other missing pieces. Does this work under a stock version of -stable? That could help you figure out whether this is a problem with your backport. Make sure you get an up-to-date -stable, including version 1.14.2.8 of scsi_all.c. You might also want to talk to Matt Jacob <[EMAIL PROTECTED]> and see if he can help you out. (dunno if he reads -hackers, thus the reason you might want to send mail directly) Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Copying from Virtual Address Space to Physical Address
On Fri, 30 Aug 2002, Julian Elischer wrote: > Physio() does this.. first it finds the physical addresses of the user > pages targetted, then it maps those pages into kernel space, and then it > initiates IO to them. (this actually needs to change but for now it's > true. to correct myself.. physio() calls vmapbuf(bp) in order to do it.. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Copying from Virtual Address Space to Physical Address
I'm a little bit confused about this vmapbuf() thing. This is what I think, correct me if I'm wrong. I have this User Virtual address, userbuf --> associated to physadd Now, I do vmapbuf(physadd), and I get a Kernel Virtual Address associated to this "physadd". Now, I write to this Kernel Virtual Address and it reflects in userbuf? OhmyGod!!! Is that what it's supposed to do? Hope it doesn't oops my machine.. Also, if this is right, how do I get the kernel virtual address it's associated to? The function returns a void. Thanx. Pavan Balaji, Intel Corporation Email: [EMAIL PROTECTED] "Only the Paranoid Survive" -- Andy Grove > -Original Message- > From: Julian Elischer [mailto:[EMAIL PROTECTED]] > Sent: Friday, August 30, 2002 3:20 PM > To: Balaji, Pavan > Cc: '[EMAIL PROTECTED]' > Subject: Re: Copying from Virtual Address Space to Physical Address > > > > > On Fri, 30 Aug 2002, Julian Elischer wrote: > > > Physio() does this.. first it finds the physical addresses > of the user > > pages targetted, then it maps those pages into kernel > space, and then it > > initiates IO to them. (this actually needs to change but > for now it's > > true. > > > to correct myself.. > physio() calls vmapbuf(bp) in order to do it.. > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Copying from Virtual Address Space to Physical Address
On Fri, 30 Aug 2002, Balaji, Pavan wrote: > > I'm a little bit confused about this vmapbuf() thing. This is what I think, > correct me if I'm wrong. > > I have this User Virtual address, userbuf --> associated to physadd > > Now, I do vmapbuf(physadd), and I get a Kernel Virtual Address associated to > this "physadd". Now, I write to this Kernel Virtual Address and it reflects > in userbuf? OhmyGod!!! Is that what it's supposed to do? Hope it doesn't > oops my machine.. no that is correct. this function is for making user space buffers map into kernel space.. you just want the second half of this.. Now I have a question for you how do you know what pages you want to map into kernel virtual space? > > Also, if this is right, how do I get the kernel virtual address it's > associated to? The function returns a void. The buf steucture is updated to hold KV addresses for the region. 'bp' is a pointer to a complicated struct that defines the buffer, not to the address of the buffer itself. > > Thanx. > > Pavan Balaji, > Intel Corporation > Email: [EMAIL PROTECTED] > > "Only the Paranoid Survive" -- Andy Grove > > > > -Original Message- > > From: Julian Elischer [mailto:[EMAIL PROTECTED]] > > Sent: Friday, August 30, 2002 3:20 PM > > To: Balaji, Pavan > > Cc: '[EMAIL PROTECTED]' > > Subject: Re: Copying from Virtual Address Space to Physical Address > > > > > > > > > > On Fri, 30 Aug 2002, Julian Elischer wrote: > > > > > Physio() does this.. first it finds the physical addresses > > of the user > > > pages targetted, then it maps those pages into kernel > > space, and then it > > > initiates IO to them. (this actually needs to change but > > for now it's > > > true. > > > > > > to correct myself.. > > physio() calls vmapbuf(bp) in order to do it.. > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Copying from Virtual Address Space to Physical Address
On Fri, 30 Aug 2002, Balaji, Pavan wrote: > > I'm a little bit confused about this vmapbuf() thing. This is what I think, > correct me if I'm wrong. > > I have this User Virtual address, userbuf --> associated to physadd > > Now, I do vmapbuf(physadd), and I get a Kernel Virtual Address associated to > this "physadd". Now, I write to this Kernel Virtual Address and it reflects > in userbuf? OhmyGod!!! Is that what it's supposed to do? Hope it doesn't > oops my machine.. > > Also, if this is right, how do I get the kernel virtual address it's > associated to? The function returns a void. The initial input to physio is a uio. A uio is a structure that points to a range of memory, (or several ranges of memeory that are to betreated as a set of buffers) in user space or in kernel space.. (it has a flag to say which). For now just talk about the userland case. For each range of addresses, a 'buf' is assigned that can point to a range of memory. The pointers in the buf are set to be the same as the first region of the uio. Then vmapbuf() is called, that iterates thtough all teh pages in the userland memory buffer, and one by one, finds the physical address of those pages, and maps them into a contiguous region in kernel space. Now those pages are mapped in 2 places. The user space and the kernel. if you wrote to them in the kernel, the data will appear in the userspace buffer.. of course it will also be on the PHYSICAL pages involved as well. You want to do just the 2nd part of this.. you want tostart with a list of physical pages, and map them into the kernel space somewhere. That way you can write to them. WHen you are finished, you then unmap them.. > > Thanx. > > Pavan Balaji, > Intel Corporation > Email: [EMAIL PROTECTED] > > "Only the Paranoid Survive" -- Andy Grove > > > > -Original Message- > > From: Julian Elischer [mailto:[EMAIL PROTECTED]] > > Sent: Friday, August 30, 2002 3:20 PM > > To: Balaji, Pavan > > Cc: '[EMAIL PROTECTED]' > > Subject: Re: Copying from Virtual Address Space to Physical Address > > > > > > > > > > On Fri, 30 Aug 2002, Julian Elischer wrote: > > > > > Physio() does this.. first it finds the physical addresses > > of the user > > > pages targetted, then it maps those pages into kernel > > space, and then it > > > initiates IO to them. (this actually needs to change but > > for now it's > > > true. > > > > > > to correct myself.. > > physio() calls vmapbuf(bp) in order to do it.. > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Copying from Virtual Address Space to Physical Address
Thanx. It's nearly done. I just need to know two more small things. physio() requires a dev_t as a parameter. What do I give in over here? I can't give NULL, cause it does use it for some stuff in the function definition. Also, the only other parameters to physio() are the uio and the ioflag (which is not used at all). So, where is the kernel virtual address mapping? Do I have to do something this this dev_t thing to open a virtual device which maps to the kernel virtual address. If yes, how do I do this? Thanx. Pavan Balaji, Intel Corporation Email: [EMAIL PROTECTED] "Only the Paranoid Survive" -- Andy Grove > -Original Message- > From: Julian Elischer [mailto:[EMAIL PROTECTED]] > Sent: Friday, August 30, 2002 3:49 PM > To: Balaji, Pavan > Cc: '[EMAIL PROTECTED]' > Subject: RE: Copying from Virtual Address Space to Physical Address > > > > > On Fri, 30 Aug 2002, Balaji, Pavan wrote: > > > > > I'm a little bit confused about this vmapbuf() thing. This > is what I think, > > correct me if I'm wrong. > > > > I have this User Virtual address, userbuf --> associated to physadd > > > > Now, I do vmapbuf(physadd), and I get a Kernel Virtual > Address associated to > > this "physadd". Now, I write to this Kernel Virtual Address > and it reflects > > in userbuf? OhmyGod!!! Is that what it's supposed to do? > Hope it doesn't > > oops my machine.. > > > > Also, if this is right, how do I get the kernel virtual address it's > > associated to? The function returns a void. > > The initial input to physio is a uio. > A uio is a structure that points to a range of memory, (or > several ranges > of memeory that are to betreated as a set of buffers) in user space > or in kernel space.. (it has a flag to say which). > > For now just talk about the userland case. > For each range of addresses, a 'buf' is assigned that can > point to a range > of memory. The pointers in the buf are set to be the same as the first > region of the uio. Then vmapbuf() is called, that iterates > thtough all teh > pages in the userland memory buffer, and one by one, finds > the physical > address of those pages, and maps them into a contiguous region in > kernel space. Now those pages are mapped in 2 places. > The user space and the kernel. if you wrote to them in the kernel, > the data will appear in the userspace buffer.. of course > it will also be on the PHYSICAL pages involved as well. > > You want to do just the 2nd part of this.. > you want tostart with a list of physical pages, and map them into the > kernel space somewhere. That way you can write to them. > WHen you are finished, you then unmap them.. > > > > > > > Thanx. > > > > Pavan Balaji, > > Intel Corporation > > Email: [EMAIL PROTECTED] > > > > "Only the Paranoid Survive" -- Andy Grove > > > > > > > -Original Message- > > > From: Julian Elischer [mailto:[EMAIL PROTECTED]] > > > Sent: Friday, August 30, 2002 3:20 PM > > > To: Balaji, Pavan > > > Cc: '[EMAIL PROTECTED]' > > > Subject: Re: Copying from Virtual Address Space to > Physical Address > > > > > > > > > > > > > > > On Fri, 30 Aug 2002, Julian Elischer wrote: > > > > > > > Physio() does this.. first it finds the physical addresses > > > of the user > > > > pages targetted, then it maps those pages into kernel > > > space, and then it > > > > initiates IO to them. (this actually needs to change but > > > for now it's > > > > true. > > > > > > > > > to correct myself.. > > > physio() calls vmapbuf(bp) in order to do it.. > > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-hackers" in the body of the message > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Copying from Virtual Address Space to Physical Address
On Fri, 30 Aug 2002, Balaji, Pavan wrote: > > Thanx. It's nearly done. I just need to know two more small things. > > physio() requires a dev_t as a parameter. What do I give in over here? I > can't give NULL, cause it does use it for some stuff in the function > definition. I wasn't suggesting that you use physio() but that you use it and it's friend as a prototype for yourself when you write a function to do what you want. The dev_t is associated with the device this is doing IO from so it's not necessarily relelvant to you. you haven't told us enough about what you want to do to allow us to really understand your problem. > > Also, the only other parameters to physio() are the uio and the ioflag > (which is not used at all). So, where is the kernel virtual address mapping? > Do I have to do something this this dev_t thing to open a virtual device > which maps to the kernel virtual address. If yes, how do I do this? > > Thanx. > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Copying from Virtual Address Space to Physical Address
While we're on the topic of vmapbuf: I have a kernel module that maps two 64k chunks of user memory into the kernel using the same set of steps that cam_periph_mapmem uses. However, I inevitably get the following panic after running the code for a bit: Aug 30 14:55:26 testhost /kernel: panic: worklist_remove: not on list Aug 30 14:55:26 testhost /kernel: Aug 30 14:55:26 testhost /kernel: syncing disks... 8 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 Aug 30 14:55:26 testhost /kernel: giving up on 1 buffers This is a panic in ffs_softdep.c, it implies to me that either the FFS code isn't recognizing that not all buffers belong to it or getpbuf isn't doing all the needed accounting. I notice that I am calling getpbuf(NULL), just as cam_periph_mapmem does. But above its definition in the comment is: * NOTE: pfreecnt can be NULL, but this 'feature' will be removed * relatively soon when the rest of the subsystems get smart about it. XXX Also worthy of note is that my kernel module has a lot of printfs which obviously translate to a lot of synchronous writes by syslog, presumably putting memory pressure on the file system. When guessing whether Kirk is at fault or I am fault, it is usually a safe bet that I am at fault ;-). Any insights? -Kip On Fri, 30 Aug 2002, Julian Elischer wrote: > > > On Fri, 30 Aug 2002, Balaji, Pavan wrote: > > > > > Thanx. It's nearly done. I just need to know two more small things. > > > > physio() requires a dev_t as a parameter. What do I give in over here? I > > can't give NULL, cause it does use it for some stuff in the function > > definition. > > I wasn't suggesting that you use physio() but that you use it and it's > friend as a prototype for yourself when you write a function to do what > you want. The dev_t is associated with the device this is doing > IO from so it's not necessarily relelvant to you. > > you haven't told us enough about what you want to do to allow us to > really understand your problem. > > > > > > > > > > Also, the only other parameters to physio() are the uio and the ioflag > > (which is not used at all). So, where is the kernel virtual address mapping? > > Do I have to do something this this dev_t thing to open a virtual device > > which maps to the kernel virtual address. If yes, how do I do this? > > > > Thanx. > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ultra320 drivers?
[ cc list trimmed ] [ I guess I got unsubscribed from hackers, so I missed the front end of this. Every time I try and sort out majordomo at FreeBSD, it fails for me (like trying ask "what am I subscribed to") and all requests to postmaster seem to bitbucket. Oh well. ] This isn't good. Part of it just the chip later presenting the completion for a command that I had already timed out. But basically, we never got a response to a command, so we timed it out. Later, the chip presented us with the comamnd as being done- and being done with no errors (hence the 'context reply'). Can you say if there was a perceptible period of time between the first and second barfings? -matt > >>The bad news is that any kind of extended disk activity (e.g. kernel > >>building), results in a ton of unhealthy messages like this: > >> > >>mpt1: time out on request index = 0xe4 sequence = 0x0cad > >>mpt1: Status 0001; Mask 0001; Doorbell 2400 > >>request state On Chip > >>SCSI IO Request @ 0xff807f34 > >>Chain Offset 0x00 > >>MsgFlags 0x00 > >>MsgContext0x00e4 > >>Bus:0 > >>TargetID1 > >>SenseBufferLength 32 > >>LUN: 0x0 > >>Control 0x0100 WRITE SIMPLEQ > >>DataLength 0x4000 > >>SenseBufAddr0x0005d9e0 > >>CDB[0:10] 2a 00 01 3f e1 9f 00 00 20 00 > >>SE32 0xdc3c2830: Addr=0xd0f3000 FlagsLength=0x14001000 > >>HOST_TO_IOC > >>SE32 0xdc3c2838: Addr=0xd034000 FlagsLength=0x14002000 > >>HOST_TO_IOC > >>SE32 0xdc3c2840: Addr=0xd136000 FlagsLength=0xd5001000 > >>HOST_TO_IOC LAST_ELEMENT END_OF_BUFFER END_OF_LIST > >>mpt1: mpt_done: corrupted ccb, index = 0xe4 seq = 0x0cad request > >>state Timeout > >>mpt_request: > >>SCSI IO Request @ 0xff807e88 > >>Chain Offset 0x00 > >>MsgFlags 0x00 > >>MsgContext0x00e4 > >>Bus:0 > >>TargetID1 > >>SenseBufferLength 32 > >>LUN: 0x0 > >>Control 0x0100 WRITE SIMPLEQ > >>DataLength 0x4000 > >>SenseBufAddr0x0005d9e0 > >>CDB[0:10] 2a 00 01 3f e1 9f 00 00 20 00 > >>SE32 0xdc3c2830: Addr=0xd0f3000 FlagsLength=0x14001000 > >>HOST_TO_IOC > >>SE32 0xdc3c2838: Addr=0xd034000 FlagsLength=0x14002000 > >>HOST_TO_IOC > >>SE32 0xdc3c2840: Addr=0xd136000 FlagsLength=0xd5001000 > >>HOST_TO_IOC LAST_ELEMENT END_OF_BUFFER END_OF_LIST > >>mpt_done: context reply: 0x00e4 > >> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ultra320 drivers?
Oh, yes- let me know if you've upgraded to the latest LSI 53c1030 f/w (that'd 1.0.12). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ultra320 drivers?
Matthew, Matthew Jacob wrote: > This isn't good. Part of it just the chip later presenting the > completion for a command that I had already timed out. But basically, > we never got a response to a command, so we timed it out. Later, the > chip presented us with the comamnd as being done- and being done with no > errors (hence the 'context reply'). > > Can you say if there was a perceptible period of time between the first > and second barfings? there is a longish (30 seconds?) pause before the first message, then I get them all in one swoop. E.g. I type "make buildworld", make seems to hang, and then I get these messages 30 seconds later. > Oh, yes- let me know if you've upgraded to the latest LSI 53c1030 f/w > (that'd 1.0.12). No, I was running a Dell-branded 1.0.0. I grabbed the update from LSI and installed it, but now none of my partitions likes to boot anymore (FreeBSD and Windows XP). Also, the LSI firmware prompt used to show all drives as Ultra-320, now it shows them as Ultra-80 with a note saying "should support Ultra-320 when the OS is loaded". Is this to be expected, i.e. do I need to reinstall everything with the new firmware? I'm trying to find the original Dell-branded firmware somewhere, but so far, no luck. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Syscalls numbers in -CURRENT.
Hello hackers... Syscall number (when catching syscall) in -STABLE in placed in: p->p_md.md_regs->tf_eax (for i386) p->p_md.md_tf[FRAME_V0] (for alpha) But as I see, in -CURRENT even p_md has diffrent type. Could someone can give me equivalent place (where syscall number is stored) for i386, alpha, ia64, sparc64 and powerpc in -CURRENT? Thanks. -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. msg36646/pgp0.pgp Description: PGP signature
Re: More dynamic KVA_SPACE
mark tinguely wrote: > > Another interesting processor family is the AMD x86-64 ClawHammer. > I do not know the progress the FreeBSD/x86-64 project. I would imagine > the major difficulty will be getting a running compiler. Nope, the compiler is already pretty robust. > I just wish AMD added an 8K page size so the Page Table Maps did not > eat so much memory. It would have been nice, yes. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ultra320 drivers?
On Fri, 30 Aug 2002, Lars Eggert wrote: > Matthew, > > Matthew Jacob wrote: > > This isn't good. Part of it just the chip later presenting the > > completion for a command that I had already timed out. But basically, > > we never got a response to a command, so we timed it out. Later, the > > chip presented us with the comamnd as being done- and being done with no > > errors (hence the 'context reply'). > > > > Can you say if there was a perceptible period of time between the first > > and second barfings? > > there is a longish (30 seconds?) pause before the first message, then I > get them all in one swoop. E.g. I type "make buildworld", make seems to > hang, and then I get these messages 30 seconds later. In some sense this sounds like an interrupt issue. The timeout is 30 seconds, and it looks like we give up on the command but it's done instantaneously afterwards. > > Oh, yes- let me know if you've upgraded to the latest LSI 53c1030 f/w > > (that'd 1.0.12). > > No, I was running a Dell-branded 1.0.0. I grabbed the update from LSI > and installed it, but now none of my partitions likes to boot anymore > (FreeBSD and Windows XP). Also, the LSI firmware prompt used to show all > drives as Ultra-320, now it shows them as Ultra-80 with a note saying > "should support Ultra-320 when the OS is loaded". Is this to be > expected, i.e. do I need to reinstall everything with the new firmware? *sputter* That's damned odd. Can you get into the configuration menu and make sure it has 'large BIOS' or whatever the LSI term is enabled? > I'm trying to find the original Dell-branded firmware somewhere, but so > far, no luck. *groan* I might have an image somewhere around... hang on... check my directory on hub- there's 1.0.6 there... -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ultra320 drivers?
Matthew Jacob wrote: > In some sense this sounds like an interrupt issue. The timeout is 30 > seconds, and it looks like we give up on the command but it's done > instantaneously afterwards. Hm. I don't know much about the PCI code, so maybe what follows won't make any sense and may not be related: The card is PCI64, and there's an "unknown" device in the dmesg that is an "Intel 82806AA I/O APIC Device" according to its device ID. Would that matter at all? >>No, I was running a Dell-branded 1.0.0. I grabbed the update from LSI >>and installed it, but now none of my partitions likes to boot anymore >>(FreeBSD and Windows XP). Also, the LSI firmware prompt used to show all >>drives as Ultra-320, now it shows them as Ultra-80 with a note saying >>"should support Ultra-320 when the OS is loaded". Is this to be >>expected, i.e. do I need to reinstall everything with the new firmware? > > *sputter* > > That's damned odd. Can you get into the configuration menu and make sure > it has 'large BIOS' or whatever the LSI term is enabled? The Dell BIOS, or the LSI config menu? I don't think either has a setting that sounds similar, but I'll double-check tomorrow. >>I'm trying to find the original Dell-branded firmware somewhere, but so >>far, no luck. > > *groan* I might have an image somewhere around... hang on... > check my directory on hub- there's 1.0.6 there... That'd be great. I also emailed Dell and LSI. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Ultra320 drivers?
> > In some sense this sounds like an interrupt issue. The timeout is 30 > > seconds, and it looks like we give up on the command but it's done > > instantaneously afterwards. > > Hm. I don't know much about the PCI code, so maybe what follows won't > make any sense and may not be related: The card is PCI64, and there's an > "unknown" device in the dmesg that is an "Intel 82806AA I/O APIC Device" > according to its device ID. Would that matter at all? Haven't a clue. The 53c1030 is a single chip - two instances showing up multifunctioned. I have to say that Peter has had some problems that look interrupt related also. But I haven't. I just more or less finished some non-FreeBSD work with a 1030 so I can plop the card into a FreeBSD machine again and check. > > >>No, I was running a Dell-branded 1.0.0. I grabbed the update from LSI > >>and installed it, but now none of my partitions likes to boot anymore > >>(FreeBSD and Windows XP). Also, the LSI firmware prompt used to show all > >>drives as Ultra-320, now it shows them as Ultra-80 with a note saying > >>"should support Ultra-320 when the OS is loaded". Is this to be > >>expected, i.e. do I need to reinstall everything with the new firmware? > > > > *sputter* > > > > That's damned odd. Can you get into the configuration menu and make sure > > it has 'large BIOS' or whatever the LSI term is enabled? > > The Dell BIOS, or the LSI config menu? I don't think either has a LSI Config - ^C. > setting that sounds similar, but I'll double-check tomorrow. > > >>I'm trying to find the original Dell-branded firmware somewhere, but so > >>far, no luck. > > > > *groan* I might have an image somewhere around... hang on... > > check my directory on hub- there's 1.0.6 there... > > That'd be great. I also emailed Dell and LSI. > > Lars > -- > Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
