Re: Accessing the tty structure of an opened device
Poul-Henning Kamp wrote: > > In message <[EMAIL PROTECTED]>, Alexa > nder Maret writes: > > >Do I have to write my own serial driver to get what I want or > >is it possible to use functions of the "build in" serial > >device driver? > > You may be able to do it as a "line discipline. I'm not quite sure > if it is possible. If not, a (hardware-) device driver is your only hope. Uh oh. Is it time for 'ttygraph'? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Rijndael status in FreeBSD??
On Wed, Oct 25, 2000 at 08:24:24PM -0500, Jim Bryant wrote: > What are the plans for incorporating Rijndael, the finalist algorithm > for the Advanced Encryption Standard, into FreeBSD? > > jim I believe that there are people working on this. Expect it in current shortly. Joe -- Josef KarthauserFreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: smbfs-1.3.0 released
On Fri, 27 Oct 2000, Terry Lambert wrote: > > So... the case-insensitivity only happens at the root of the mount. > > Should it happen everywhere? It'd be nice if it did. :-) > > Ha! > > The full path is sent over the wire. > > The attempt to be "case sensitive on storage, case insensitive on > lookup" is inhernetly flawed. Actually, smbfs doesn't try to be case insensitive. At this moment it merely passes file names with possible charset translation. If long names is not used (WfWg for example), then file names converted to upper case. nwfs have more complex case management features (see mount_nwfs(4) for '-c' option). > The difference is that if you are iterating and comparing in > user space, you will get a failure, but if you are doing an > explicit VOP_LOOKUP in kernel space, the case folding will work. Hmm, why ? > The problem is that you don't really get a directory handle > object, like you get an inode in NFS, since in a DOS FS, and > thus in the wire externalization of a DOS FS, which is what SMB > gives you, the directory entry itself _is_ the inode, not a > pointer to an independent object which dereferences to the inode. > I think that if you disable the attempted case folding in the > SMBFS VOP_LOOKUP code, your problem will go away. Not exactly so - case sensitivity depends on server, for most servers ls /A and ls /a are the same, but NT have strange behavior for root directory and not all directories are case insensitive. > NB: Another approach would be to fold everything to lower case > in both VOP_LOOKUP and VOP_READDIR; this could be accomplished > using a mount option. If you wanted to be more Windows-like, > you could make the first letter upper case, and subsequent > letters lower case. I'm unsure if this correct, because long file names used on windows platform may have more than one upper case letter (Program Files for example). > NNNB: If you are using a Samba server as the server, and short > names, you are probably screwed, since short names on a Samba > server are synthetic, and indeterminately so. On a Windows > box, if I rename (short:long) "PROGRA~1":"Program Files" to > "PROGRA~7", I get "PROGRA~7":"PROGRA~7"; if I then rename > "PROGRA~7" to "Program Files", I get "PROGRA~7":"Program Files". > Since the Samba short namespace is synthetic even if the UNIX > FS underneath supports both name spaces (since the UNIX name > API is handicapped, compared to the Macintosh or Windows API), > you will get a short name based on the inode number. Correct and it is not recommended to use 8.3 name space with Samba. > As to the df/du problem, I'd suggest hacking VFS_STAT to return > fake data, and then figure out why it's failing so catastrophically, > since the problem is there. I suspect the problem is that it is > an old VFS_STAT call that is being called, and that a new VFS_STAT > struct is being copied out in all cases, instead of making sure it > is old vs. new, and doing the right thing, and the resulting > buffer overrun stomps on something important. No, this is not related. The same things will happen on all SMB requests if server dropped the connection and it seems to be fixed in the upcoming smbfs-1.3.1. On a side note I'm unsure why NT server drops the connection if client doesn't send any request in XX minutes (for example Samba uses NetBIOS keepalive packets). -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinux h
On 28-Oct-00 Matt Dillon wrote: >:> # optional dd if you are paranoid >:> # dd if=/dev/zero of=/dev/da0 bs=32k count=4 >:> fdisk -I da0 >:> disklabel -w -r da0s1 auto >:> >:> That's much preferable to having to use sysinstall if all you want to >:> do is initialize a label on a slice. >: >:Yes, this is definitely the desired behavior. >: >:-- >: >:John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ > > John, can you explain how the MBR bootstraps a slice? Should I make > disklabel zero-out the fdisk partition table area in the slice rather > then installing the dummy fdisk partition table? That is, for the > case where -B is used on a slice (da0s1) verses on the whole-disk (da0)? Just ignore the slice table within a slice. It is only used when boot1 is splatted over top of the MBR for the dangerously dedicated mode. It is unused and ignored otherwise. > -Matt -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: smbfs-1.3.0 released
On Fri, 27 Oct 2000, Shawn Halpenny wrote: > Speaking of smbfs, has anyone else run into an odd bug using it in > 4.1.1-STABLE? Occasionally, if I run 'df' or try to access the > directories (e.g. using 'ls') for an smbfs mount after a period of > time during which there were no accesses across that mount point (e.g. > mount, don't touch it for an hour, then try 'df'), my machine will > reboot after a few seconds. No panic message or anything--it's just > like I pressed the reset button. I think that I've found possible cause of this problem and 1.3.1 will be released at this weekend. > Incidentally, under smbfs-1.2.7, the above scenario only caused 'ls' > to display 'broken pipe' and I could remount that share and things Yes, 'broken pipe' was a bug and now it should work properly. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinux h
:> # optional dd if you are paranoid :> # dd if=/dev/zero of=/dev/da0 bs=32k count=4 :> fdisk -I da0 :> disklabel -w -r da0s1 auto :> :> That's much preferable to having to use sysinstall if all you want to :> do is initialize a label on a slice. : :Yes, this is definitely the desired behavior. : :-- : :John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ John, can you explain how the MBR bootstraps a slice? Should I make disklabel zero-out the fdisk partition table area in the slice rather then installing the dummy fdisk partition table? That is, for the case where -B is used on a slice (da0s1) verses on the whole-disk (da0)? -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinux h
On 28-Oct-00 Matt Dillon wrote: >:> I think you are specifying the wrong arguments to disklabel; I >:> seem to rememebr a -w/-W distinction... >: >:Nope. >: >:> In any case, I'm running with a disklabel inside a DOS partition >:> on all but one box of mine, and always have been. I installed >:> 4.1 on my laptop that way. >: >:Sysinstall can create a disklabel inside of a MBR slice fine. The >:problem is that the disklabel(8) _program_ itself doesn't know how >:to create a virgin disklabel for a MBR slice. >: >:-- >: >:John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ > > The patchset I put on the lists earlier today will allow disklabel > to install a virgin label on a slice. Did it not get out? As matters > currently stand, disklabel can only edit a preexisting label on a slice. If your patch works it looks great to me. I was just referring to our currently checked in code in disklabel(8). :) > I'll post it again... included below (this time without the file > descriptor cruft that snuck into my previous posting of the patch). With > the patch you can do this: I did wonder about the file descriptor patch the first go-round... :) > # optional dd if you are paranoid > # dd if=/dev/zero of=/dev/da0 bs=32k count=4 > fdisk -I da0 > disklabel -w -r da0s1 auto > > That's much preferable to having to use sysinstall if all you want to > do is initialize a label on a slice. Yes, this is definitely the desired behavior. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinux h
:> I think you are specifying the wrong arguments to disklabel; I
:> seem to rememebr a -w/-W distinction...
:
:Nope.
:
:> In any case, I'm running with a disklabel inside a DOS partition
:> on all but one box of mine, and always have been. I installed
:> 4.1 on my laptop that way.
:
:Sysinstall can create a disklabel inside of a MBR slice fine. The
:problem is that the disklabel(8) _program_ itself doesn't know how
:to create a virgin disklabel for a MBR slice.
:
:--
:
:John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
The patchset I put on the lists earlier today will allow disklabel
to install a virgin label on a slice. Did it not get out? As matters
currently stand, disklabel can only edit a preexisting label on a slice.
I'll post it again... included below (this time without the file
descriptor cruft that snuck into my previous posting of the patch). With
the patch you can do this:
# optional dd if you are paranoid
# dd if=/dev/zero of=/dev/da0 bs=32k count=4
fdisk -I da0
disklabel -w -r da0s1 auto
That's much preferable to having to use sysinstall if all you want to
do is initialize a label on a slice.
-Matt
Index: sbin/disklabel/disklabel.c
===
RCS file: /home/ncvs/src/sbin/disklabel/disklabel.c,v
retrieving revision 1.28.2.3
diff -u -r1.28.2.3 disklabel.c
--- sbin/disklabel/disklabel.c 2000/07/01 06:47:46 1.28.2.3
+++ sbin/disklabel/disklabel.c 2000/10/27 19:24:00
@@ -1347,10 +1347,17 @@
warn("cannot open %s", namebuf);
return (NULL);
}
- if (ioctl(f, DIOCGDINFO, &lab) < 0) {
- warn("ioctl DIOCGDINFO");
- close(f);
- return (NULL);
+
+ /*
+* Try to use the new get-virgin-label ioctl. If it fails,
+* fallback to the old get-disdk-info ioctl.
+*/
+ if (ioctl(f, DIOCGDVIRGIN, &lab) < 0) {
+ if (ioctl(f, DIOCGDINFO, &lab) < 0) {
+ warn("ioctl DIOCGDINFO");
+ close(f);
+ return (NULL);
+ }
}
close(f);
lab.d_boot0 = NULL;
Index: sys/kern/subr_diskslice.c
===
RCS file: /home/ncvs/src/sys/kern/subr_diskslice.c,v
retrieving revision 1.82
diff -u -r1.82 subr_diskslice.c
--- sys/kern/subr_diskslice.c 2000/01/28 11:51:08 1.82
+++ sys/kern/subr_diskslice.c 2000/10/27 19:23:28
@@ -366,12 +366,46 @@
int slice;
struct diskslice *sp;
struct diskslices *ssp;
+ struct partition *pp;
slice = dkslice(dev);
ssp = *sspp;
sp = &ssp->dss_slices[slice];
lp = sp->ds_label;
switch (cmd) {
+
+ case DIOCGDVIRGIN:
+ lp = (struct disklabel *)data;
+ if (ssp->dss_slices[WHOLE_DISK_SLICE].ds_label) {
+ *lp = *ssp->dss_slices[WHOLE_DISK_SLICE].ds_label;
+ } else {
+ bzero(lp, sizeof(struct disklabel));
+ }
+
+ lp->d_magic = DISKMAGIC;
+ lp->d_magic2 = DISKMAGIC;
+ pp = &lp->d_partitions[RAW_PART];
+ pp->p_offset = 0;
+ pp->p_size = sp->ds_size;
+
+ lp->d_npartitions = MAXPARTITIONS;
+ if (lp->d_interleave == 0)
+ lp->d_interleave = 1;
+ if (lp->d_rpm == 0)
+ lp->d_rpm = 3600;
+ if (lp->d_nsectors == 0)
+ lp->d_nsectors = 32;
+ if (lp->d_ntracks == 0)
+ lp->d_ntracks = 64;
+
+ lp->d_bbsize = BBSIZE;
+ lp->d_sbsize = SBSIZE;
+ lp->d_secpercyl = lp->d_nsectors * lp->d_ntracks;
+ lp->d_ncylinders = sp->ds_size / lp->d_secpercyl;
+ lp->d_secperunit = sp->ds_size;
+ lp->d_checksum = 0;
+ lp->d_checksum = dkcksum(lp);
+ return (0);
case DIOCGDINFO:
if (lp == NULL)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinux h
On 27-Oct-00 Terry Lambert wrote: >> Thanks for the program. >> >> I think, however, that the proper solution is to make disklabel work >> with slices. We shouldn't need three programs to label a disk... >> if fdisk and disklabel can't do the job then our distribution is broken. >> >> I am going to spend some time researching the problem to see if I can >> come up with a 'disklabel' solution for labeling slices. It would >> also be nice if someone could figure out why our 'dangerously dedicated' >> partition fails with some BIOSes ... it should be possible to fix it if >> someone could track down what exactly is causing the divide-by-0 ! > > I think you are specifying the wrong arguments to disklabel; I > seem to rememebr a -w/-W distinction... Nope. > In any case, I'm running with a disklabel inside a DOS partition > on all but one box of mine, and always have been. I installed > 4.1 on my laptop that way. Sysinstall can create a disklabel inside of a MBR slice fine. The problem is that the disklabel(8) _program_ itself doesn't know how to create a virgin disklabel for a MBR slice. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinux h
> Thanks for the program. > > I think, however, that the proper solution is to make disklabel work > with slices. We shouldn't need three programs to label a disk... > if fdisk and disklabel can't do the job then our distribution is broken. > > I am going to spend some time researching the problem to see if I can > come up with a 'disklabel' solution for labeling slices. It would > also be nice if someone could figure out why our 'dangerously dedicated' > partition fails with some BIOSes ... it should be possible to fix it if > someone could track down what exactly is causing the divide-by-0 ! I think you are specifying the wrong arguments to disklabel; I seem to rememebr a -w/-W distinction... In any case, I'm running with a disklabel inside a DOS partition on all but one box of mine, and always have been. I installed 4.1 on my laptop that way. Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: smbfs-1.3.0 released
> Oh yeah, I've noticed one more thing. When you're at the root of a > mount, you can cd into a directory using any case, but if you get the > case wrong, you don't get a listing. Here's an example: [ ... ] > So... the case-insensitivity only happens at the root of the mount. > Should it happen everywhere? It'd be nice if it did. :-) Ha! The full path is sent over the wire. The attempt to be "case sensitive on storage, case insensitive on lookup" is inhernetly flawed. The way this works on OSs which support it is that the globbing occurs in the kernel. This lets the case folding occur before the data is returned. The difference is that if you are iterating and comparing in user space, you will get a failure, but if you are doing an explicit VOP_LOOKUP in kernel space, the case folding will work. The problem is that you don't really get a directory handle object, like you get an inode in NFS, since in a DOS FS, and thus in the wire externalization of a DOS FS, which is what SMB gives you, the directory entry itself _is_ the inode, not a pointer to an independent object which dereferences to the inode. I suspect that this is at the heart of your lookup problems, given the way that UNIX programs tend to put in what they were given out. I think that if you disable the attempted case folding in the SMBFS VOP_LOOKUP code, your problem will go away. Note: things which reference explicit names use VOP_LOOKUP, while things which iterate directories use VOP_READDIR. I suspect that you will see similar problems on attempts to rename things, because of this. NB: Another approach would be to fold everything to lower case in both VOP_LOOKUP and VOP_READDIR; this could be accomplished using a mount option. If you wanted to be more Windows-like, you could make the first letter upper case, and subsequent letters lower case. NNB: The behaviour will also depend on the server you are using; some servers can return both the short (8.3) and long names over SMB, and others can only return the short names. NNNB: If you are using a Samba server as the server, and short names, you are probably screwed, since short names on a Samba server are synthetic, and indeterminately so. On a Windows box, if I rename (short:long) "PROGRA~1":"Program Files" to "PROGRA~7", I get "PROGRA~7":"PROGRA~7"; if I then rename "PROGRA~7" to "Program Files", I get "PROGRA~7":"Program Files". Since the Samba short namespace is synthetic even if the UNIX FS underneath supports both name spaces (since the UNIX name API is handicapped, compared to the Macintosh or Windows API), you will get a short name based on the inode number. --- As to the df/du problem, I'd suggest hacking VFS_STAT to return fake data, and then figure out why it's failing so catastrophically, since the problem is there. I suspect the problem is that it is an old VFS_STAT call that is being called, and that a new VFS_STAT struct is being copied out in all cases, instead of making sure it is old vs. new, and doing the right thing, and the resulting buffer overrun stomps on something important. Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Accessing the tty structure of an opened device
> > You will need to do this in a device driver, there is no way you > > can reliably measure that from userland. > > > > Trust me on this: I've tried. > > That's what I wanted to do. I wanted to write a character device > which on read() passes the last IR-code. > > Well as Mike Smith told me: "you cannot poll the serial line at > anything like a useful speed to perform IR decoding" my hopes are > all gone to get a simple solution. > > Do I have to write my own serial driver to get what I want or > is it possible to use functions of the "build in" serial > device driver? You will have to modify the serial driver somewhat to be able to externalize the interruptable events. Some of these events are handled internally. My personaly suggestion, since you created this dongle on your own, would be to drop uses of DCD, and use CTS/RTS as the signalling method instead. To do this right, you will need to set your FIFO depth on the UART to nothing, so it doesn't delay delivery of interrupts (some FIFO implementations delay signalling of events intentionally to reduce processing overhead, and only deliver when they would deliver data). You will also effectively be using every character as a wakeup character, to avoid queueuing at the tty pseudo device boundary (or would, last time I looked). I would specifically suggest you implement this as a line discipline, since most of what you would need to do is there. If you are not adamant about clock speed on input, this should work in a non-noisy environment. For a noisy environment, you will want to poke the UART at some multiple of your expected frequency to get it to reinterrupt, and then debounce it in software, based on your expected event boundary crossing frequency vs. the (higher) poking frequency. If you plan to implement this as a line discipline, you should look at the SLIP, PPP, and mouse line disciplines; the first two will tell you about the wakeup code, and the second will tell you about FIFO depth. Looking back over all this, it would be useful to have the ability to generalize all serial port data using a line discipline and externalization of all possible interrupt signals... BUT... it would probably be easier for you, in the short run, to just take the serial and IR driver code, and write a custom driver that takes over the serial port, and disable the standard serial driver from grabbing it using kernel configuration options. If I were doing it, I'd probably want to open up the ports for people to hack on every possible little thing they could hack on, but then I don't have a deadline, and I wouldn't really care how much work it would take, and I don't have a specific hack in mind, like you do. Sort of the current parallel port code, applied to serial ports... Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinux
Robert Nordier <[EMAIL PROTECTED]> writes:
>> > o Don't use dangerously dedicated mode.
>>
>> I'd love to but the tools for automated installs in non-dedicated mode
>> dont really exist in a supported way. One of the things that was pointed
>> out in the thread is that disklabel doesn't work inside an fdisk slice.
>
>Disklabel really needs to be rewritten.
Few truer statements have ever been made...
>> I could use expect to manipulate sysinstall? So, for now, I use
>> dangerously dedicated installs with a hacked fake partition table to work
>> around the broken bioses I use. I just might start using program posted
>> in this thread that lets you do labels right in lieu of anything else, or
>> perhaps I'll fix disklabel to work right as was suggeseted elsewhere.
>
>Don't sysinstall work in a script mode? I've never used it, but I
>thought it did.
It does work in a scripted mode, however the documentation on it is
close to non-existant; arguments are case-sensitive, etc. I was working to
migrate data to disks/partitions of different sizes, and had to read lots
of the sysinstall/disklabel source, and on top of that had to hack
sysinstall in order to get it to work at all for my purpose. Ugh.
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: IDE Questions
On Fri, Oct 27, 2000 at 04:51:55PM -0500, Chris Csanady wrote: > Is there anyone successfully using an IBM 75GXP with an Abit KT7-Raid > motherboard? I am using stable from a couple days ago, and am having > some problems getting it to work. > > [snip] > > When I attach the disk to the Highpoint 370 controller, the > machine wedges after a short while. Is the support for this > chipset in stable up to date? Also, are there any plans to > merge the support for tagged queueing? There appear to be some problems with the IBM disks and some drive controllers. (The HPT366 is one, so I wouldn't be surprised if the 370 has problems as well.) The latest BIOS for the 366 is supposed to fix this problem, but it only partially fixed it for me. (The BIOS detects the disk properly, but any attempt to access causes the machine to hang.) My workaround for my BP6 motherboard was to connect it to one of the standard BX IDE controllers, but this is less than ideal. In short, this is much less likely to be FreeBSD's problem than Highpoint's, IMO. BJ -- Brad Jones -- [EMAIL PROTECTED] "Until you can face up to reality, I'm not sure you can be my imaginary friend anymore." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
IDE Questions
Is there anyone successfully using an IBM 75GXP with an Abit KT7-Raid motherboard? I am using stable from a couple days ago, and am having some problems getting it to work. If the disk is attached to the onboard IDE, the kernel spews a bunch of these ad2: UDMA ICRC WRITE ERROR blk# 1457759 retrying and then falls back to PIO mode, which is unacceptable. (ie. it transforms my Athlon 900 into a turd. For any moderate amount of disk activity, I get 100% CPU utilization, and it is very much non-interactive.) I have the proper cables, and have observed this on two seperate KT7 motherboards. Is the KT7 onboard IDE just busted? (I wouldn't be at all surprised, considering how horribly broken the BIOS boot ordering is, not to mention the soft power issues, etc. For a board that comes so highly recommended, I'm not terribly impressed.) When I attach the disk to the Highpoint 370 controller, the machine wedges after a short while. Is the support for this chipset in stable up to date? Also, are there any plans to merge the support for tagged queueing? Thanks, Chris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinux
Fred Clift wrote: > > > > > > Why not edit the partition table after boot1 gets installed? > > > > Because you can never make it valid. By keeping it the same set of > > illegal values, at least the system can recognise it. > > > What do you mean it can't be made valid? fdisk -u and a few keystrokes > later and I have a valid partition table... Whats wrong with it? Really, > if I'm being dense, sorry -- perhaps I just dont under stand yet -- please > be patient with me :) If the PC partition (slice) includes boot1, it is invalid. A slice should can't include its own MBR. If the BSD partition excludes boot1, it is invalid. A partition can't exclude its own boot blocks. Just because fdisk is happy, doesn't mean it's valid. Just because it works (for you), doesn't mean it's valid, either. :) > > > > A final point: > > > > o Don't use dangerously dedicated mode. > > I'd love to but the tools for automated installs in non-dedicated mode > dont really exist in a supported way. One of the things that was pointed > out in the thread is that disklabel doesn't work inside an fdisk slice. Disklabel really needs to be rewritten. > I could use expect to manipulate sysinstall? So, for now, I use > dangerously dedicated installs with a hacked fake partition table to work > around the broken bioses I use. I just might start using program posted > in this thread that lets you do labels right in lieu of anything else, or > perhaps I'll fix disklabel to work right as was suggeseted elsewhere. Don't sysinstall work in a script mode? I've never used it, but I thought it did. -- Robert Nordier [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinux
> > > > Why not edit the partition table after boot1 gets installed? > > Because you can never make it valid. By keeping it the same set of > illegal values, at least the system can recognise it. What do you mean it can't be made valid? fdisk -u and a few keystrokes later and I have a valid partition table... Whats wrong with it? Really, if I'm being dense, sorry -- perhaps I just dont under stand yet -- please be patient with me :) > > A final point: > > o Don't use dangerously dedicated mode. I'd love to but the tools for automated installs in non-dedicated mode dont really exist in a supported way. One of the things that was pointed out in the thread is that disklabel doesn't work inside an fdisk slice. I could use expect to manipulate sysinstall? So, for now, I use dangerously dedicated installs with a hacked fake partition table to work around the broken bioses I use. I just might start using program posted in this thread that lets you do labels right in lieu of anything else, or perhaps I'll fix disklabel to work right as was suggeseted elsewhere. Fred -- Fred Clift - [EMAIL PROTECTED] -- Remember: If brute force doesn't work, you're just not using enough. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinux
Fred Clift wrote: > On Fri, 27 Oct 2000, Robert Nordier wrote: > > > > > Just doing the disklabel -w -r followed by the disklabel -B is creating > > a dangerously dedicated disk, which your BIOS apparently doesn't like. > > (See the first hex dump you did, where boot1 has ended up in the MBR.) > > > > That's why installing boot blocks is messing with the partition table, > > to answer the question you asked elsewhere. > > > > You need to dd and fdisk before the disklabel commands, which will give > > you a standard partition table (at the cost of 63 sectors of disk > > space). > > > So why not just put a valid partition table inside the boot1 that gets put > on sector zero? When boot1 gets dropped onto sector zero, it does hose > the partition table, but there is no reason why a valid one couln't be put > there insead of this broken one: There seems to be a lot of muddy thinking going around, so let's go over some basics: o Dangerously dedicated mode was created so that boot1 could sit on sector zero, as it does on non-PC implementations of UNIX. (It also saved space, since PC partitions are usually head- aligned and up to 62 sectors could be wasted, though that's hardly an issue now.) o A dangerously dedicated disk can _never_ be a valid PC partition. By even a loose definition, a PC partition always _excludes_ the MBR. By definition, a dangerously dedicated disk explicitly _includes_ the MBR sector. o Given that a dangerously dedicated disk is an invalid PC partition and can't be otherwise, the PC partition table entry is invalid and can't be otherwise. It is therefore better to "limit the damage" and always use the same invalid entry 0x80, 0x00, 0x01, 0x00 0xa5, 0xff, 0xff, 0xff 0x00, 0x00, 0x00, 0x00 0x50, 0xc3, 0x00, 0x00 rather than change it to better fit the disk. > > Information from DOS bootblock is: > The data for partition 1 is: > > The data for partition 2 is: > > The data for partition 3 is: > > The data for partition 4 is: > sysid 165,(FreeBSD/NetBSD/386BSD) > start 0, size 5 (24 Meg), flag 80 (active) > beg: cyl 0/ sector 1/ head 0; > end: cyl 1023/ sector 63/ head 255 > > Why not edit the partition table after boot1 gets installed? Because you can never make it valid. By keeping it the same set of illegal values, at least the system can recognise it. A final point: o Don't use dangerously dedicated mode. -- Robert Nordier [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinux h
On 27-Oct-00 Fred Clift wrote: > On Fri, 27 Oct 2000, Robert Nordier wrote: > >> >> Just doing the disklabel -w -r followed by the disklabel -B is creating >> a dangerously dedicated disk, which your BIOS apparently doesn't like. >> (See the first hex dump you did, where boot1 has ended up in the MBR.) >> >> That's why installing boot blocks is messing with the partition table, >> to answer the question you asked elsewhere. >> >> You need to dd and fdisk before the disklabel commands, which will give >> you a standard partition table (at the cost of 63 sectors of disk >> space). >> > > > So why not just put a valid partition table inside the boot1 that gets put > on sector zero? When boot1 gets dropped onto sector zero, it does hose > the partition table, but there is no reason why a valid one couln't be put > there insead of this broken one: Well, for one thing, 99% of the PC architecture assumes that the first track is reserved for the MBR so to speak, so putting boot1 in the MBR is already bogus. The reason it is bogus is to work around disk geometry pain as I mentioned in my previous e-mail to Matt. The only thing you can change is the size of the last slice, but my guess is that that won't fix the problem that the SCSI BIOS's have, but that instead the hack that we use boot1 as an MBR for (having the slice start at 0/0/1) is what is causing the BIOS to choke. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinux h
On 27-Oct-00 Matt Dillon wrote: >:I have a bunch boxes based on the L440GX+ intel motherboard that get >:confused by 'dangerously dedicated' labels. If you want real fun, dd >:boo0 from 3.4 onto the first block of any hard disk in your system and >:you will be unable to boot _any_ device in your system as the bios gets a >:wedgie somewhere before the bootloader gets invoked. PXE or other network >:boot still works and from there you can 'fix' the disk, or you can just >:yank it from the box too. >: >:At any rate, I've found a workaround in that if I put in valid partition >:info into the boot0 bootblock, the wedgie problem goes away. >: >:Am I confused about something? Perhaps I'm mistaken about how things work >:-- if so, enlighten me, please. >:-- >:Fred Clift - [EMAIL PROTECTED] -- Remember: If brute > > I think that the days of the 'dangerously dedicated partition' are > numbered. It has obviously caused much more havoc then people have > realized. We don't have time to fix it for the current release, but I > took a good hard look at the code and as far as I can tell the only > reason we *have* a dangerously dedicated partition at all is because > the disklabel code is too cheap to create a real one - it is just copying > the skeleton fdisk data from boot0 verbatim and leaving it. Disklabel > could very easily create a real partition - in fact, I think with my > proposed patch for labeling slices all it needs to do is exec > 'fdisk -I disk' to do it, and then generate a virgin label for the slice. No, unfortunately we can't quite kill dedicated mode yet. There are still potential cases where the geometry the BIOS uses and the geometry that sysinstall uses are different, resulting in sysinstall writing a MBR that the BIOS won't handle properly (it won't find boot1 on the FreeBSD slice in the right place). DD mode works around this by sticking boot1 as the second sector on the disk whose geometry can't be screwed up. If you remove DD mode then the workaround in this case is for the user to enter the BIOS setup, write down the geometry the BIOS thinks the disk has, and then use the set geometry command in sysinstall's fdisk editor to set the geometry to the one the BIOS is using so that sysinstall writes out a MBR that the BIOS can properly use. As you can see, the issues involved with PC booting are revolting at best. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinuxhardware
On Fri, 27 Oct 2000, Fred Clift wrote: > > If you do a hexdump on boot0 and the first sector of your disk, you'll see > that boot0 has been copied onto your disk, broken partition table and a typo/thinko -- replace boot0 here with boot1 -- Fred Clift - [EMAIL PROTECTED] -- Remember: If brute force doesn't work, you're just not using enough. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinuxhardware
On Fri, 27 Oct 2000, Robert Nordier wrote: > > Just doing the disklabel -w -r followed by the disklabel -B is creating > a dangerously dedicated disk, which your BIOS apparently doesn't like. > (See the first hex dump you did, where boot1 has ended up in the MBR.) > > That's why installing boot blocks is messing with the partition table, > to answer the question you asked elsewhere. > > You need to dd and fdisk before the disklabel commands, which will give > you a standard partition table (at the cost of 63 sectors of disk > space). > So why not just put a valid partition table inside the boot1 that gets put on sector zero? When boot1 gets dropped onto sector zero, it does hose the partition table, but there is no reason why a valid one couln't be put there insead of this broken one: Information from DOS bootblock is: The data for partition 1 is: The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 0, size 5 (24 Meg), flag 80 (active) beg: cyl 0/ sector 1/ head 0; end: cyl 1023/ sector 63/ head 255 Why not edit the partition table after boot1 gets installed? Fred -- Fred Clift - [EMAIL PROTECTED] -- Remember: If brute force doesn't work, you're just not using enough. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinuxhardware
If you do a hexdump on boot0 and the first sector of your disk, you'll see that boot0 has been copied onto your disk, broken partition table and all. If you then run fdisk on the disk and put in the 'right' number of sectors and let it automatically recalculate everything else, you'll get a decent fdisk table back. disklabel -B, in my opinion should either A) leave the partition table alone (even though it's part of the first sector too) or B) look at the freebsd label and automagically calculate what the values should be and put them in (as does fdisk -u when you 'Supply a decimal value for "size"' and dont explicitly calculate anything else, letting it calculate it for you. > > disklabel -B da0 > disklabel -B da1 > > fdisk da0 ... > The data for partition 4 is: > sysid 165,(FreeBSD/NetBSD/386BSD) > start 0, size 5 (24 Meg), flag 80 (active) > beg: cyl 0/ sector 1/ head 0; > end: cyl 1023/ sector 63/ head 255 Fred -- Fred Clift - [EMAIL PROTECTED] -- Remember: If brute force doesn't work, you're just not using enough. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinux h
:I have a bunch boxes based on the L440GX+ intel motherboard that get :confused by 'dangerously dedicated' labels. If you want real fun, dd :boo0 from 3.4 onto the first block of any hard disk in your system and :you will be unable to boot _any_ device in your system as the bios gets a :wedgie somewhere before the bootloader gets invoked. PXE or other network :boot still works and from there you can 'fix' the disk, or you can just :yank it from the box too. : :At any rate, I've found a workaround in that if I put in valid partition :info into the boot0 bootblock, the wedgie problem goes away. : :Am I confused about something? Perhaps I'm mistaken about how things work :-- if so, enlighten me, please. :-- :Fred Clift - [EMAIL PROTECTED] -- Remember: If brute I think that the days of the 'dangerously dedicated partition' are numbered. It has obviously caused much more havoc then people have realized. We don't have time to fix it for the current release, but I took a good hard look at the code and as far as I can tell the only reason we *have* a dangerously dedicated partition at all is because the disklabel code is too cheap to create a real one - it is just copying the skeleton fdisk data from boot0 verbatim and leaving it. Disklabel could very easily create a real partition - in fact, I think with my proposed patch for labeling slices all it needs to do is exec 'fdisk -I disk' to do it, and then generate a virgin label for the slice. An interim solution would be to get my proposed patch (DIOCGVIRGIN and giving disklabel the ability to label a slice) in for this release, assuming it passes muster. We definitely need something for this release, or everyone running VALinux hardware is going to be real confused if they ever disklabel a disk manually. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinux h
So let me see if I get this -- the recommended way to install is to have fdisk slices, and inside (one of) those slices have FreeBSD lables. However, right now, other than using the program posted in this thread, getting creative with dd is the only way to set up lables like that in an automated way. The only other choice it would seem is to use sysinstall interactively? disklabel -e claims it supports 'leaving the fdisk partition alone' while labling -- would that work? This is interactive too, however. The 'fake' fdisk table that gets put on for dangerously dedicated mode (ie the one inside boot0) has a fake 25 meg partition in it. Wouldn't the problem be solved if we jut put valid info in this 'fake' partition table making this a both 'dedicated' and non-bios confusing 'normal' install at the same time? I have a bunch boxes based on the L440GX+ intel motherboard that get confused by 'dangerously dedicated' labels. If you want real fun, dd boo0 from 3.4 onto the first block of any hard disk in your system and you will be unable to boot _any_ device in your system as the bios gets a wedgie somewhere before the bootloader gets invoked. PXE or other network boot still works and from there you can 'fix' the disk, or you can just yank it from the box too. At any rate, I've found a workaround in that if I put in valid partition info into the boot0 bootblock, the wedgie problem goes away. Am I confused about something? Perhaps I'm mistaken about how things work -- if so, enlighten me, please. -- Fred Clift - [EMAIL PROTECTED] -- Remember: If brute force doesn't work, you're just not using enough. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Proposed patch to fix disklabel for slices. (was re: BTX halted...)
Here is my proposal and a patch.
The patch adds a new iodctl, called DIOCGDVIRGIN. This ioctl
returns a 'virgin disklabel' for a disk or slice.
The other part of the patch is to modify the 'disklabel' program
to use the new ioctl (and to fallback to what it was doing before:
DIOCGINFO if the new ioctl fails).
With this patch you can now use 'fdisk -I da0' to create a real
dos partition, and then use 'disklabel -w -r da0s1 auto' to label it.
Without the patch it is not possible to disklabel a slice without
writing a separate program to do it (as mentioned by others in this
thread).
I am testing it now, but I believe it to be very close to correct
if not completely correct. I would appreciate comment and testing by
others and some input from Jordan in regards to possibly getting it into
the release.
-Matt
Index: sbin/disklabel/disklabel.c
===
RCS file: /home/ncvs/src/sbin/disklabel/disklabel.c,v
retrieving revision 1.28.2.3
diff -u -r1.28.2.3 disklabel.c
--- sbin/disklabel/disklabel.c 2000/07/01 06:47:46 1.28.2.3
+++ sbin/disklabel/disklabel.c 2000/10/27 19:24:00
@@ -1347,10 +1347,17 @@
warn("cannot open %s", namebuf);
return (NULL);
}
- if (ioctl(f, DIOCGDINFO, &lab) < 0) {
- warn("ioctl DIOCGDINFO");
- close(f);
- return (NULL);
+
+ /*
+* Try to use the new get-virgin-label ioctl. If it fails,
+* fallback to the old get-disdk-info ioctl.
+*/
+ if (ioctl(f, DIOCGDVIRGIN, &lab) < 0) {
+ if (ioctl(f, DIOCGDINFO, &lab) < 0) {
+ warn("ioctl DIOCGDINFO");
+ close(f);
+ return (NULL);
+ }
}
close(f);
lab.d_boot0 = NULL;
Index: sys/kern/kern_descrip.c
===
RCS file: /home/ncvs/src/sys/kern/kern_descrip.c,v
retrieving revision 1.81.2.4
diff -u -r1.81.2.4 kern_descrip.c
--- sys/kern/kern_descrip.c 2000/10/24 19:28:26 1.81.2.4
+++ sys/kern/kern_descrip.c 2000/10/26 04:04:25
@@ -125,6 +125,9 @@
/*
* Duplicate a file descriptor to a particular value.
+ *
+ * note: keep in mind that a potential race condition exists when closing
+ * descriptors from a shared descriptor table (via rfork).
*/
#ifndef _SYS_SYSPROTO_H_
struct dup2_args {
@@ -145,8 +148,9 @@
if (old >= fdp->fd_nfiles ||
fdp->fd_ofiles[old] == NULL ||
new >= p->p_rlimit[RLIMIT_NOFILE].rlim_cur ||
- new >= maxfilesperproc)
+ new >= maxfilesperproc) {
return (EBADF);
+ }
if (old == new) {
p->p_retval[0] = new;
return (0);
@@ -157,12 +161,15 @@
if (new != i)
panic("dup2: fdalloc");
} else if (fdp->fd_ofiles[new]) {
+ struct file *fp = fdp->fd_ofiles[new];
+
if (fdp->fd_ofileflags[new] & UF_MAPPED)
(void) munmapfd(p, new);
/*
* dup2() must succeed even if the close has an error.
*/
- (void) closef(fdp->fd_ofiles[new], p);
+ fdp->fd_ofiles[new] = NULL;
+ (void) closef(fp, p);
}
return (finishdup(fdp, (int)old, (int)new, p->p_retval));
}
Index: sys/kern/subr_diskslice.c
===
RCS file: /home/ncvs/src/sys/kern/subr_diskslice.c,v
retrieving revision 1.82
diff -u -r1.82 subr_diskslice.c
--- sys/kern/subr_diskslice.c 2000/01/28 11:51:08 1.82
+++ sys/kern/subr_diskslice.c 2000/10/27 19:23:28
@@ -366,12 +366,46 @@
int slice;
struct diskslice *sp;
struct diskslices *ssp;
+ struct partition *pp;
slice = dkslice(dev);
ssp = *sspp;
sp = &ssp->dss_slices[slice];
lp = sp->ds_label;
switch (cmd) {
+
+ case DIOCGDVIRGIN:
+ lp = (struct disklabel *)data;
+ if (ssp->dss_slices[WHOLE_DISK_SLICE].ds_label) {
+ *lp = *ssp->dss_slices[WHOLE_DISK_SLICE].ds_label;
+ } else {
+ bzero(lp, sizeof(struct disklabel));
+ }
+
+ lp->d_magic = DISKMAGIC;
+ lp->d_magic2 = DISKMAGIC;
+ pp = &lp->d_partitions[RAW_PART];
+ pp->p_offset = 0;
+ pp->p_size = sp->ds_size;
+
+ lp->d_npartitions = MAXPARTITIONS;
+ if (lp->d_interleave == 0)
+ lp->d_interleave = 1;
+ if (lp->d_rpm == 0)
+ lp->d_rpm = 3600;
+ if (lp->d_nsectors == 0)
+ lp->d_nsectors = 32;
+
Re: Really odd "BTX halted" problem booting FreeBSD on VALinux h
:> :> disklabel -w -r da0s1 auto(label it) : :Disklabel can not label slices. For a project I had to work on receently :I hacked up a slicelabel tool that used libdisk (which can handle slices) :to initialize the disklabels in slices. The code for the slicelabel :command is quite short: :.. :John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ Thanks for the program. I think, however, that the proper solution is to make disklabel work with slices. We shouldn't need three programs to label a disk... if fdisk and disklabel can't do the job then our distribution is broken. I am going to spend some time researching the problem to see if I can come up with a 'disklabel' solution for labeling slices. It would also be nice if someone could figure out why our 'dangerously dedicated' partition fails with some BIOSes ... it should be possible to fix it if someone could track down what exactly is causing the divide-by-0 ! -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: RE: Really odd "BTX halted" problem booting FreeBSD on VALin
On 27-Oct-00 Matt Dillon wrote: > The real question is: Ok, so if I can't use dangerously dedicated > mode, then how do I create a disklabel on a normal partition? Everything > I try using fdisk and disklabel fails. fdisk will create a normal > freebsd-dedicated dos partition, but disklabel refuses to label it. See my previous e-mail about my slicelabel utility^Whack. If you use sysinstall you can label the disk as well. :) > Beyond that, our 'dangerously dedicated' disk label should at least > contain reasonable values -- be correct enough to pass BIOS muster. > I don't know enough about the partition format to know where the > BIOS calculation is failing. Errr, the dangerously dedicated label can't contain reasonable values because it violates assumptions made by other pieces of the PC architecture. > -Matt -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: RE: Really odd "BTX halted" problem booting FreeBSD on VALinux h
:> :> I was testing the PXE stuff and booting one of the boxes regularly. :> All of a sudden every time I reboot I get: :> :> ... :> BIOS drive A: is disk0 :> :> int= err= efl=00030246 eip=1d29 :> eax= ebs=0390 ecx= edx= :> esi=8db7 edi=1c09 ebp=0398 esp=038c :> cs=c800 ds=0040 es=8db7 fs= gs= ss=8db7 :> cs:eip= f7 f1 33 d2 8a 4e f6 f7-f1 3d ff 03 76 03 b8 ff :> ss:esp= 00 00 3f 00 00 00 00 00-00 00 02 00 22 0a 00 c8 :> BTX halted : :Int 00 is a divide by zero fault. Note that %eax is zero. :Do you have dangerously dedicated mode on by chance? Some :SCSI BIOS's _will_ crash with this if you use dangerously :dedicated mode. : :-- : :John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ Yup. The real question is: Ok, so if I can't use dangerously dedicated mode, then how do I create a disklabel on a normal partition? Everything I try using fdisk and disklabel fails. fdisk will create a normal freebsd-dedicated dos partition, but disklabel refuses to label it. Beyond that, our 'dangerously dedicated' disk label should at least contain reasonable values -- be correct enough to pass BIOS muster. I don't know enough about the partition format to know where the BIOS calculation is failing. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinux h
On 27-Oct-00 Matt Dillon wrote:
>:Danny Braniss ([EMAIL PROTECTED]) wrote:
>:> In message <[EMAIL PROTECTED]>you write:
>:> }This is really weird. I have two valinux rackmount boxes, duel cpu's.
>:> }
>:> }I was testing the PXE stuff and booting one of the boxes regularly.
>:> }All of a sudden every time I reboot I get:
>:> }
>:>
>:> i've seen the same, i just reboot it, and it works. sometimes, while
>:> the kernel is doing it's init stuff it panics. i haven't seen it fail
>:> more than once in a row, so i was thinking maybe some network error
>:> that was not dealt properly. btw, the boxes are DELL.
>:
>:He was not seeing a PXE bug, it was a loader issue with the BIOS.
>:The PXE bug you are seeing is with anything build 078 or earlier.
>:Intel has a bug in their rom which they fixed back in March of this year.
>:
>:--
>:Paul Saab
>:Technical Yahoo
>
> Right. It isn't PXE. PXE works fine.
>
> I'm starting to figure out what is going on. If I create a
> 'dangerously dedicated' parittion, the BIOS drops dead when the
> loader tries to scan it.
>
> If I create a normal fdisk partition, the BIOS works, but disklabel
> will not let me label the fdisk partition and I have no clue as to why
> not!
>
> fdisk -I da0 (init a real freebsd-dedicated DOS partition)
> reboot(reboot just to be sure)
> (BIOS does NOT crash with a real dos partition
> table)
> fdisk da0 (see output below)
>
> The data for partition 1 is:
> sysid 165,(FreeBSD/NetBSD/386BSD)
> start 63, size 143363997 (70001 Meg), flag 80 (active)
> beg: cyl 0/ sector 1/ head 1;
> end: cyl 731/ sector 63/ head 254
> The data for partition 2 is:
>
> The data for partition 3 is:
>
> The data for partition 4 is:
>
> 10:/root#
>
> disklabel -w -r da0s1 auto(label it)
Disklabel can not label slices. For a project I had to work on receently
I hacked up a slicelabel tool that used libdisk (which can handle slices)
to initialize the disklabels in slices. The code for the slicelabel
command is quite short:
#include
#include
#include
#include
#include
static void usage(void);
static void label_disk(const char *name);
static void
usage(void)
{
fprintf(stderr, "Usage: slicelabel disk [disk ...]\n");
exit(1);
}
static void
label_disk(const char *name)
{
struct disk *disk;
if ((disk = Open_Disk(name)) == NULL)
fprintf(stderr, "Unable to open disk %s.\n", name);
else
Write_Disk(disk);
}
int
main(int argc, char *argv[])
{
int index;
if (argc == 1)
usage();
for(index = 1; index < argc; index++)
label_disk(argv[index]);
return(0);
}
--
John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinux hardware
:Danny Braniss ([EMAIL PROTECTED]) wrote: :> In message <[EMAIL PROTECTED]>you write: :> }This is really weird. I have two valinux rackmount boxes, duel cpu's. :> } :> }I was testing the PXE stuff and booting one of the boxes regularly. :> }All of a sudden every time I reboot I get: :> } :> :> i've seen the same, i just reboot it, and it works. sometimes, while :> the kernel is doing it's init stuff it panics. i haven't seen it fail :> more than once in a row, so i was thinking maybe some network error :> that was not dealt properly. btw, the boxes are DELL. : :He was not seeing a PXE bug, it was a loader issue with the BIOS. :The PXE bug you are seeing is with anything build 078 or earlier. :Intel has a bug in their rom which they fixed back in March of this year. : :-- :Paul Saab :Technical Yahoo Right. It isn't PXE. PXE works fine. I'm starting to figure out what is going on. If I create a 'dangerously dedicated' parittion, the BIOS drops dead when the loader tries to scan it. If I create a normal fdisk partition, the BIOS works, but disklabel will not let me label the fdisk partition and I have no clue as to why not! fdisk -I da0(init a real freebsd-dedicated DOS partition) reboot (reboot just to be sure) (BIOS does NOT crash with a real dos partition table) fdisk da0 (see output below) The data for partition 1 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 63, size 143363997 (70001 Meg), flag 80 (active) beg: cyl 0/ sector 1/ head 1; end: cyl 731/ sector 63/ head 254 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: 10:/root# disklabel -w -r da0s1 auto (label it) 10:/root# disklabel -w -r da0s1 auto Oct 27 11:00:35 10 /kernel: da0: cannot find label (no disk label) Oct 27 11:00:35 10 /kernel: da0s1: cannot find label (no disk label) Oct 27 11:00:35 10 /kernel: da0: cannot find label (no disk label) Oct 27 11:00:35 10 /kernel: da0s1: cannot find label (no disk label) disklabel: ioctl DIOCGDINFO: Invalid argument disklabel: auto: unknown disk type I don't understand why it won't let me label the fdisk partition. If only I could label the real partition 'fdisk -I' created, I think the system will work. The question is, why is disklabel failing above? It shouldn't be failing..it should let me label da0s1. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Really odd "BTX halted" problem booting FreeBSD on VALinux h
On 27-Oct-00 Matt Dillon wrote: > This is really weird. I have two valinux rackmount boxes, duel cpu's. > > I was testing the PXE stuff and booting one of the boxes regularly. > All of a sudden every time I reboot I get: > > ... > BIOS drive A: is disk0 > > int= err= efl=00030246 eip=1d29 > eax= ebs=0390 ecx= edx= > esi=8db7 edi=1c09 ebp=0398 esp=038c > cs=c800 ds=0040 es=8db7 fs= gs= ss=8db7 > cs:eip= f7 f1 33 d2 8a 4e f6 f7-f1 3d ff 03 76 03 b8 ff > ss:esp= 00 00 3f 00 00 00 00 00-00 00 02 00 22 0a 00 c8 > BTX halted Int 00 is a divide by zero fault. Note that %eax is zero. Do you have dangerously dedicated mode on by chance? Some SCSI BIOS's _will_ crash with this if you use dangerously dedicated mode. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: smbfs-1.3.0 released
On Fri, 27 Oct 2000, Shawn Halpenny wrote: > Speaking of smbfs, has anyone else run into an odd bug using it in > 4.1.1-STABLE? Occasionally, if I run 'df' or try to access the > directories (e.g. using 'ls') for an smbfs mount after a period > of time during which there were no accesses across that mount > point (e.g. mount, don't touch it for an hour, then try 'df'), my > machine will reboot after a few seconds. No panic message or > anything--it's just like I pressed the reset button. I've not had it panic on me under those situations, but it does do weird things. I think I'd either get an empty directory listing, or it would say "path too long" or something like that and any relative path stuff like "cd .." wouldn't work. I'd have to give a full path to get where I wanted to go, even if it was the _same_ directory. I've also had cases where I was drilling down through the directories in the Save File dialog in Navigator and I would get incomplete directory listings. Also, it seems, if I try to save a file that way, the file ends up corrupted. If I save it to a local filesystem and then move it over manually, its fine. Other than those small annoyances, it seems to work great. Oh yeah, I've noticed one more thing. When you're at the root of a mount, you can cd into a directory using any case, but if you get the case wrong, you don't get a listing. Here's an example: root@tech43 [/smb/rsisfs1/d]# ls ADMINNOTIFY/REB98/ SECURITY/ SHARES/ tmpacls.bat* CPQIS1/ RECYCLER/ SETACLS.BAT*TEMP/ root@tech43 [/smb/rsisfs1/d]# cd reb98 root@tech43 [/smb/rsisfs1/d/reb98]# ls root@tech43 [/smb/rsisfs1/d/reb98]# cd ../REB98 root@tech43 [/smb/rsisfs1/d/REB98]# ls ARCHIVE/PACKAGES/ AUTOEXEC.BAT* PCRDIST/ BATCH/ REBMIR.LOG* ... and so on ... root@tech43 [/smb/rsisfs1/d/REB98]# cd packages packages: No such file or directory. root@tech43 [/smb/rsisfs1/d/REB98]# cd PACKAGES root@tech43 [/smb/rsisfs1/d/REB98/PACKAGES]# So... the case-insensitivity only happens at the root of the mount. Should it happen everywhere? It'd be nice if it did. :-) -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64 and PowerPC under development. http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: AW: Accessing the tty structure of an opened device
On Fri, 27 Oct 2000, Mike Smith wrote: > Stop trying to do this; you cannot poll the serial line at anything like > a useful speed to perform IR decoding. The entire approach you're trying > to take is unworkable. Hm, it seems like every motherboard made in the last few years has some hookup for an IR port that will act as com 2. Are the parts for those available? (Or would alexander be able to adapt his IR device to that interface somehow?) Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: smbfs-1.3.0 released
Speaking of smbfs, has anyone else run into an odd bug using it in 4.1.1-STABLE? Occasionally, if I run 'df' or try to access the directories (e.g. using 'ls') for an smbfs mount after a period of time during which there were no accesses across that mount point (e.g. mount, don't touch it for an hour, then try 'df'), my machine will reboot after a few seconds. No panic message or anything--it's just like I pressed the reset button. Incidentally, under smbfs-1.2.7, the above scenario only caused 'ls' to display 'broken pipe' and I could remount that share and things would be fine. 'df' would still work without any noticeable difference. Don't have any idea about starting to troubleshoot this one. -- Shawn Halpenny |Maniacal@I Ache, Ohm| "Universal Danger!" +- - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - \ | vi:G3kfM~lxfAPXh~l~2x2FirllpfcxlrifaprmfOX~Xp2hr.lrcelyl2p - - - - - - - -|fU~X~refsPprnlxppri2lxlpr,pFrpprrfaPlpfiprgllxp~3Xlpfndw To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Accessing the tty structure of an opened device
> That's what I wanted to do. I wanted to write a character device > which on read() passes the last IR-code. > > Well as Mike Smith told me: "you cannot poll the serial line at > anything like a useful speed to perform IR decoding" my hopes are > all gone to get a simple solution. > > Do I have to write my own serial driver to get what I want or > is it possible to use functions of the "build in" serial > device driver? You will need to write your own. Even then, polling an inbound signal is not going to be reliable. Use a UART or some other appropriate hardware decoder. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Accessing the tty structure of an opened device
Alexander Maret wrote: > > > -Ursprungliche Nachricht- > > From: Poul-Henning Kamp [mailto:[EMAIL PROTECTED]] > > Subject: Re: Accessing the tty structure of an opened device > > > > You will need to do this in a device driver, there is no way you > > can reliably measure that from userland. > > > > Trust me on this: I've tried. > > That's what I wanted to do. I wanted to write a character device > which on read() passes the last IR-code. > > Well as Mike Smith told me: "you cannot poll the serial line at > anything like a useful speed to perform IR decoding" my hopes are > all gone to get a simple solution. > > Do I have to write my own serial driver to get what I want or > is it possible to use functions of the "build in" serial > device driver? look at the pcaudio driver it uses a 16KHz clock to poll out audio.. You can use a similar method to poll in data with little system load As for the 'build in' serial driver, it depends on wht your data will look like Julian > > Alex > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Accessing the tty structure of an opened device
In message <[EMAIL PROTECTED]>, Alexa nder Maret writes: >Do I have to write my own serial driver to get what I want or >is it possible to use functions of the "build in" serial >device driver? You may be able to do it as a "line discipline. I'm not quite sure if it is possible. If not, a (hardware-) device driver is your only hope. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Accessing the tty structure of an opened device
> -Ursprungliche Nachricht- > From: Poul-Henning Kamp [mailto:[EMAIL PROTECTED]] > Subject: Re: Accessing the tty structure of an opened device > > You will need to do this in a device driver, there is no way you > can reliably measure that from userland. > > Trust me on this: I've tried. That's what I wanted to do. I wanted to write a character device which on read() passes the last IR-code. Well as Mike Smith told me: "you cannot poll the serial line at anything like a useful speed to perform IR decoding" my hopes are all gone to get a simple solution. Do I have to write my own serial driver to get what I want or is it possible to use functions of the "build in" serial device driver? Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: AW: Accessing the tty structure of an opened device
> Thanks for your answer but unfortunately you misunderstood my > intention (probably because of my bad english). > I already saw that I can get the state of the DCD line via > ioctl(). But to really get all pulses and spaces of the IR > device I would have to check DCD continously. What I need > is something to get a signal/intr/wakeup as soon as dcd changes. > > My hope was that I could define a TSA_CARR_OFF and then do > a tsleep to get a wakeup as soon as DCD goes down. On DCD down > do a tsleep untill it gets up again. > > Unfortunately to go tsleep and wait for TSA_CARR_OFF/ON I have to > get access to the tty structure of my serial port. Stop trying to do this; you cannot poll the serial line at anything like a useful speed to perform IR decoding. The entire approach you're trying to take is unworkable. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: AW: AW: Accessing the tty structure of an opened device
In message <[EMAIL PROTECTED]>, Alexa nder Maret writes: >> From: Poul-Henning Kamp [mailto:[EMAIL PROTECTED]] >> Subject: Re: AW: Accessing the tty structure of an opened device >> >> >> How fast do these pulses arrive ? Consider using the >> PPS-API for that: >> > >the time between a pulse and a space often only takes >a few milliseconds. I have to meassure that with >gettimeofday(). You will need to do this in a device driver, there is no way you can reliably measure that from userland. Trust me on this: I've tried. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
AW: AW: Accessing the tty structure of an opened device
> From: Poul-Henning Kamp [mailto:[EMAIL PROTECTED]] > Subject: Re: AW: Accessing the tty structure of an opened device > > > How fast do these pulses arrive ? Consider using the > PPS-API for that: > the time between a pulse and a space often only takes a few milliseconds. I have to meassure that with gettimeofday(). Greetings, Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: AW: Accessing the tty structure of an opened device
In message <[EMAIL PROTECTED]>, Alexa nder Maret writes: >> From: Poul-Henning Kamp [mailto:[EMAIL PROTECTED]] >> Subject: Re: Accessing the tty structure of an opened device >> >> >> >is it possible to access the tty structure of an opened >> >device directly? >> > >> >Background: >> >I'm trying to sense the DCD state of a serial port for >> >getting the pulses and spaces of a simple IR device. >> >> We have some ioctls which allow you to do that, some of them work. >> >> Look in , I belive I have used TIOCMODG() at one >> point in time. > >Thanks for your answer but unfortunately you misunderstood my >intention (probably because of my bad english). >I already saw that I can get the state of the DCD line via >ioctl(). But to really get all pulses and spaces of the IR >device I would have to check DCD continously. What I need >is something to get a signal/intr/wakeup as soon as dcd changes. How fast do these pulses arrive ? Consider using the PPS-API for that: -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
AW: Accessing the tty structure of an opened device
> From: Poul-Henning Kamp [mailto:[EMAIL PROTECTED]] > Subject: Re: Accessing the tty structure of an opened device > > > >is it possible to access the tty structure of an opened > >device directly? > > > >Background: > >I'm trying to sense the DCD state of a serial port for > >getting the pulses and spaces of a simple IR device. > > We have some ioctls which allow you to do that, some of them work. > > Look in , I belive I have used TIOCMODG() at one > point in time. Thanks for your answer but unfortunately you misunderstood my intention (probably because of my bad english). I already saw that I can get the state of the DCD line via ioctl(). But to really get all pulses and spaces of the IR device I would have to check DCD continously. What I need is something to get a signal/intr/wakeup as soon as dcd changes. My hope was that I could define a TSA_CARR_OFF and then do a tsleep to get a wakeup as soon as DCD goes down. On DCD down do a tsleep untill it gets up again. Unfortunately to go tsleep and wait for TSA_CARR_OFF/ON I have to get access to the tty structure of my serial port. Thanks for your help, Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Accessing the tty structure of an opened device
In message <[EMAIL PROTECTED]>, Alexa nder Maret writes: >Hi, > >is it possible to access the tty structure of an opened >device directly? > >Background: >I'm trying to sense the DCD state of a serial port for >getting the pulses and spaces of a simple IR device. We have some ioctls which allow you to do that, some of them work. Look in , I belive I have used TIOCMODG() at one point in time. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Accessing the tty structure of an opened device
Hi, is it possible to access the tty structure of an opened device directly? Background: I'm trying to sense the DCD state of a serial port for getting the pulses and spaces of a simple IR device. I could use ioctl commands to get the current state but then I would have to check the state continously which uses too much cpu time. What I want to do is something like that: - open the serial port - get the tty structure of the opened device - define something like that: #define TSA_CARR_OFF(tp) (!((void *)&(tp)->t_rawq)) and then wait for TSA_CARR_OFF and TSA_CARR_ON for example: - get current DCD state if DCD is up error = tsleep(TSA_CARR_OFF(tp), .) to get a wakeup on DCD down. Is this possible and if yes where do I get access to the tty structure of my opened serial port? Unfortunately I'm no kernel hacker so be patient with me. I tried to find examples within the source code and in "The design and implementation of the 4.4 BSD OS" but couldn't find a good solution. An example code how to access the tty structure would be great. Perhaps you can point me to the right files within the kernel sources. Thanks in advance, Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ipfw security.
On Fri, Oct 27, 2000 at 12:16:18PM +0200, Stop here. Start everywhere. wrote: > I thought I would spread this to the mailing list just in case no one > knew about it, and ask whether ipfw does implement all of the mentioned > requirements: > > ftp://ftp.isi.edu/in-notes/rfc2979.txt > > Well, does ipfw support all of it, and if not, what doesn't it support? Ipfw allows you to specify what action to take on the recept of certain packets. As such it compliance with that RFC depends on your intended security policy and the set of rules you define using ipfw. It is certainly possibly to create complient and noncomplient rule-sets. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinux hardware
Matt Dillon wrote: > > : > :> Raw data on disk after 'disklabel -w -r da0 auto; disklabel -B da0 auto' > : > :If you added "auto" after the "disklabel -B", that may be your problem. > : > :-- > :Robert Nordier > > type-o. No auto for the -B still blows up the dos partition > table. Just doing the disklabel -w -r followed by the disklabel -B is creating a dangerously dedicated disk, which your BIOS apparently doesn't like. (See the first hex dump you did, where boot1 has ended up in the MBR.) That's why installing boot blocks is messing with the partition table, to answer the question you asked elsewhere. You need to dd and fdisk before the disklabel commands, which will give you a standard partition table (at the cost of 63 sectors of disk space). -- Robert Nordier [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinux hardware
: :> Raw data on disk after 'disklabel -w -r da0 auto; disklabel -B da0 auto' : :If you added "auto" after the "disklabel -B", that may be your problem. : :-- :Robert Nordier type-o. No auto for the -B still blows up the dos partition table. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ipfw security.
Hello all, I thought I would spread this to the mailing list just in case no one knew about it, and ask whether ipfw does implement all of the mentioned requirements: ftp://ftp.isi.edu/in-notes/rfc2979.txt Well, does ipfw support all of it, and if not, what doesn't it support? Thanks in advance. /John -- Regards, phpStop.com http://www.phpstop.com/ Stop here. Start everywhere. mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinux hardware
Matt Dillon wrote: > Raw data on disk after 'disklabel -w -r da0 auto; disklabel -B da0 auto' If you added "auto" after the "disklabel -B", that may be your problem. -- Robert Nordier [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinux hardware
On Fri, Oct 27, 2000 at 12:46:05AM -0700, Matt Dillon wrote: > This is really weird. I have two valinux rackmount boxes, duel cpu's. > > I was testing the PXE stuff and booting one of the boxes regularly. > All of a sudden every time I reboot I get: > > ... > BIOS drive A: is disk0 > > int= err= efl=00030246 eip=1d29 > eax= ebs=0390 ecx= edx= > esi=8db7 edi=1c09 ebp=0398 esp=038c > cs=c800 ds=0040 es=8db7 fs= gs= ss=8db7 > cs:eip= f7 f1 33 d2 8a 4e f6 f7-f1 3d ff 03 76 03 b8 ff > ss:esp= 00 00 3f 00 00 00 00 00-00 00 02 00 22 0a 00 c8 > BTX halted > > *All* the time. That is, everything was working fine, then nothing was > working. Powering down doesn't help... now every boot comes up with the > above error. I didn't change the boot image ... in fact, when I stuck > the 4.1 CD in the now non-working machine, *IT's* bootloader also > crashed every time too (and it worked previously). > > I messed around trying to track down where the loader was dying. I > found it was dying in v86int(), called from bd_int13probe() in > libi386/biosdisk.c. It seems to be dying in the BIOS itself. It looks pretty similar to famous BIOS virus protection thingy. Can this be the case? Cheers, %Anton. -- and would be a nice addition to HTML specification. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinux hardware
Raw data on disk after 'disklabel -w -r da0 auto; disklabel -B da0 auto' 00f0 66 8b 46 08 52 66 0f b6 d9 66 31 d2 66 f7 f3 88 |f.F.Rf...f1.f...| 0100 eb 88 d5 43 30 d2 66 f7 f3 88 d7 5a 66 3d ff 03 |...C0.fZf=..| 0110 00 00 fb 77 44 86 c4 c0 c8 02 08 e8 40 91 88 fe |...wD...@...| 0120 28 e0 8a 66 02 38 e0 72 02 88 e0 bf 05 00 c4 5e |(..f.8.r...^| 0130 04 50 b4 02 cd 13 5b 73 0a 4f 74 1c 30 e4 cd 13 |.P[s.Ot.0...| 0140 93 eb eb 0f b6 c3 01 46 08 73 03 ff 46 0a d0 e3 |...F.s..F...| 0150 00 5e 05 28 46 02 77 88 c3 2e f6 06 99 08 80 0f |.^.(F.w.| 0160 84 79 ff bb aa 55 52 b4 41 cd 13 5a 0f 82 6f ff |.y...UR.A..Z..o.| 0170 81 fb 55 aa 0f 85 64 ff f6 c1 01 0f 84 5d ff 89 |..U...d..]..| 0180 ee b4 42 cd 13 c3 52 65 61 64 00 42 6f 6f 74 00 |..B...Read.Boot.| 0190 20 65 72 72 6f 72 0d 0a 00 80 90 90 90 90 90 90 | error..| 01a0 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 || 01b0 90 90 90 90 90 90 90 90 90 90 90 90 90 90 00 00 || 01c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 01e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00 || 01f0 01 00 a5 ff ff ff 00 00 00 00 50 c3 00 00 55 aa |..P...U.| fdisk da0 The data for partition 1 is: The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 0, size 5 (24 Meg), flag 80 (active) beg: cyl 0/ sector 1/ head 0; end: cyl 1023/ sector 63/ head 255 Raw data on disk after 'fdisk -I da0' 00f0 65 6d 00 4d 69 73 73 69 6e 67 20 6f 70 65 72 61 |em.Missing opera| 0100 74 69 6e 67 20 73 79 73 74 65 6d 00 00 00 00 00 |ting system.| 0110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 01 || 01c0 01 00 a5 fe bf db 3f 00 00 00 9d 8f 8b 08 00 00 |..?.| 01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..U.| 0200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || fdisk da0 The data for partition 1 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 63, size 143363997 (70001 Meg), flag 80 (active) beg: cyl 0/ sector 1/ head 1; end: cyl 731/ sector 63/ head 254 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinux hardware
:> :> :I'm just curious. How many disks are in this box? We saw something :> :similar here at work and it turned out that there were multiple disklabels :> :on the other disks and for somereason it was confusing the loader. :> :We dd'd the bad sections off and everything worked. : :Are you sure it's confusing the loader? Matt's fault address puts it in :the BIOS at 0xc800, which is probably the SCSI adapter's BIOS...> I'm confusing something. If I clear the disk by dd'ing it, the machine boots (diskless) fine. If I do this: dd if=/dev/zero of=/dev/da0 bs=32k count=4 dd if=/dev/zero of=/dev/da1 bs=32k count=4 disklabel -w -r da0 auto disklabel -w -r da1 auto reboot The machine will boot diskless just fine. fdisk reports: Information from DOS bootblock is: The data for partition 1 is: The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 63, size 143363997 (70001 Meg), flag 80 (active) beg: cyl 0/ sector 1/ head 1; end: cyl 731/ sector 63/ head 254 * If I install boot blocks it seems to whack the partition info, and if I reboot after this point the machine is fracked -- the boot loader blows up in the BIOS (i.e. the BIOS blows up) trying to scan the disks. disklabel -B da0 disklabel -B da1 fdisk da0 *** Working on device /dev/da0 *** parameters extracted from in-core disklabel are: cylinders=8924 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=8924 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 0, size 5 (24 Meg), flag 80 (active) beg: cyl 0/ sector 1/ head 0; end: cyl 1023/ sector 63/ head 255 reboot... BEWM!!! * HEEELP! Why is the simple installation of boot blocks by disklabel screwing up the partition table? -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinux hardware
> I was testing the PXE stuff and booting one of the boxes regularly. > All of a sudden every time I reboot I get: > > ... > BIOS drive A: is disk0 > > int= err= efl=00030246 eip=1d29 > eax= ebs=0390 ecx= edx= > esi=8db7 edi=1c09 ebp=0398 esp=038c > cs=c800 ds=0040 es=8db7 fs= gs= ss=8db7 > cs:eip= f7 f1 33 d2 8a 4e f6 f7-f1 3d ff 03 76 03 b8 ff > ss:esp= 00 00 3f 00 00 00 00 00-00 00 02 00 22 0a 00 c8 > BTX halted > > *All* the time. That is, everything was working fine, then nothing was > working. Powering down doesn't help... now every boot comes up with the > above error. I didn't change the boot image ... in fact, when I stuck > the 4.1 CD in the now non-working machine, *IT's* bootloader also > crashed every time too (and it worked previously). Too bad you killed your test case, or it might have gotton fixed; you made an image backup before you blew away the labels, or not? I think you might want to consider putting a DELAY after the BIOS call itself; perhaps some device that was poked by the BIOS is latching the bus, and you are doing an INB or OUTB too soon after the fact (but that's just my gut reaction to a crash following a BIOS call... Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rlzdbase port 635
> Scanning for open ports I found that port 635 rlzdbase port open. I've > searched the web, and mailing lists but I could find any info on any deamon > or program that ran on this port. So my question is, what is it used for. Contact: Michael Ginn <[EMAIL PROTECTED]> NB: http://www.isi.edu/in-notes/iana/assignments/port-numbers is your friend. Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinux hardware
Mike Smith ([EMAIL PROTECTED]) wrote: > > > > :I'm just curious. How many disks are in this box? We saw something > > :similar here at work and it turned out that there were multiple disklabels > > :on the other disks and for somereason it was confusing the loader. > > :We dd'd the bad sections off and everything worked. > > Are you sure it's confusing the loader? Matt's fault address puts it in > the BIOS at 0xc800, which is probably the SCSI adapter's BIOS...> I wasn't 100% involved with the problem. Peter looked into and notice the disks had bogus labels (sometimes up to 3 labels on 1 disk) and when he removed them, the machines were happy again. We never looked into further because we just didn't have the time. -- Paul Saab Technical Yahoo [EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED] Do You .. uhh .. Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinux hardware
> > :I'm just curious. How many disks are in this box? We saw something > :similar here at work and it turned out that there were multiple disklabels > :on the other disks and for somereason it was confusing the loader. > :We dd'd the bad sections off and everything worked. Are you sure it's confusing the loader? Matt's fault address puts it in the BIOS at 0xc800, which is probably the SCSI adapter's BIOS...> -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd "BTX halted" problem booting FreeBSD on VALinux hardware
:I'm just curious. How many disks are in this box? We saw something
:similar here at work and it turned out that there were multiple disklabels
:on the other disks and for somereason it was confusing the loader.
:We dd'd the bad sections off and everything worked.
:
:paul
I've got one IDE CDRom and two SCSI disks.
I did play with the labels on those machines. I will try blowing
them away. If I put a 'printf("XXX\n");' in front of every single
v86int() call in libi386/biosdisk.c it doesn't crash on me.
... ( time passes ) ...
ok... I cleared the disk labels using dd. Hoa! That seems to have
fixed it allright!
Very weird. I was sure I zero'd the labels before I populated the disk,
but maybe not.
Thanks much! I was tearing my hair out on this one...
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Really odd "BTX halted" problem booting FreeBSD on VALinux hardware
This is really weird. I have two valinux rackmount boxes, duel cpu's.
I was testing the PXE stuff and booting one of the boxes regularly.
All of a sudden every time I reboot I get:
...
BIOS drive A: is disk0
int= err= efl=00030246 eip=1d29
eax= ebs=0390 ecx= edx=
esi=8db7 edi=1c09 ebp=0398 esp=038c
cs=c800 ds=0040 es=8db7 fs= gs= ss=8db7
cs:eip= f7 f1 33 d2 8a 4e f6 f7-f1 3d ff 03 76 03 b8 ff
ss:esp= 00 00 3f 00 00 00 00 00-00 00 02 00 22 0a 00 c8
BTX halted
*All* the time. That is, everything was working fine, then nothing was
working. Powering down doesn't help... now every boot comes up with the
above error. I didn't change the boot image ... in fact, when I stuck
the 4.1 CD in the now non-working machine, *IT's* bootloader also
crashed every time too (and it worked previously).
I messed around trying to track down where the loader was dying. I
found it was dying in v86int(), called from bd_int13probe() in
libi386/biosdisk.c. It seems to be dying in the BIOS itself.
When I put a 'printf("X\n");' just before the v86int() call, the boot
loader stopped crashing at that point and was able to load the kernel,
but when it tried to run the kernel either it or the kernel crashed
with the same BTX halted message.
This is too weird. I put the second machine on my desk and started playing
with it. After about the 30th reboot (where everything was working up
until the 30th reboot), *IT* started doing the same thing! And it did
the same thing when I stuck the 3.2 CD or the 4.1 CD in the box... both
CD's crunched with the same BTX error.
Anyone have any clue?
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
