Re: Thinkpad won't boot ISO image

2000-02-16 Thread Tom Bartol



On Wed, 16 Feb 2000, Mike Smith wrote:

   The problem with the Thinkpad BIOS is where it puts the emulated floppy 
   image's disk number - it's not in the 'normal' place, and I don't exactly 
   know how to deal with it cleanly.  If someone were to lend me a thinkpad 
   or look at this it would be easy to fix.
  
  I'd like to help look at this.  I have a ThinkPad 770 and it too exhibits
  this behavior.  Unfortunately it's my only laptop so I can't loan it out
  but I certainly would like to help out if I can.  I've got an
  up-to-date -current running.  What code should I look at in sys/boot and
  how do I figure out where the Thinkpad BIOS puts the emulated floppy
  image's disk number?
 
 You'll need a CD burner and the time  patience to produce a small number 
 of coasters for this.

O.K. I've got a burner and boat loads of cheap media so no problem there.
One question though -- Once I've modified the sources as you've outlined
below, how do I make the bootable floppy image that gets written to the
CDR?  

 
 In sys/boot/i386/loader/main.c:main() you will need to print the value of 
 initial_bootdev, sometime after the console is initialised.  From what 
 I've seen, I get the impression that it will be something like 0x87.  
 This is the root of the problem; floppy disks are typically numbered 0,1 
 and hard disks are numbered 0x80,0x81, etc.  Normally all the unit 
 numbers are contiguous.

Understood (I think) :-)
On my Thinkpad I believe I've seen things like 0x8b or some such.  This
will be the first CD to burn...

 
 If this is the case, you will need to modify 
 sys/boot/i386/libi386/biosdisk.c:bd_init() to check whether it's scanned 
 the BIOS unit number from initial_bootdev, and if not (and it's legal) 
 scan it as well.  Once we've 'probed' the BIOS unit, everything else 
 should work correctly.

O.K. this makes a lot of sense and sounds easy.

 
 If you decide to take this on, please let me know how you go.

Will do!

 
 Thanks!
 

And thank you too!!!

Tom




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Thinkpad won't boot ISO image

2000-02-16 Thread Tom Bartol



On Wed, 16 Feb 2000, Mike Smith wrote:

  This is a problem with the thinkpad BIOS that I have not had the time to be
  able to track down.  It would *appear* to be that the BIOS does not do 
  int 13 handling on boot cdroms, and the boot/loader makes much use of that 
  for loading the kernel and drivers.
 
 The problem with the Thinkpad BIOS is where it puts the emulated floppy 
 image's disk number - it's not in the 'normal' place, and I don't exactly 
 know how to deal with it cleanly.  If someone were to lend me a thinkpad 
 or look at this it would be easy to fix.
 

I'd like to help look at this.  I have a ThinkPad 770 and it too exhibits
this behavior.  Unfortunately it's my only laptop so I can't loan it out
but I certainly would like to help out if I can.  I've got an
up-to-date -current running.  What code should I look at in sys/boot and
how do I figure out where the Thinkpad BIOS puts the emulated floppy
image's disk number?

Tom




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: 4.0 code freeze scheduled for Jan 15th

2000-01-06 Thread Tom Bartol



On Thu, 6 Jan 2000, Josef Karthauser wrote:

 On Fri, Jan 07, 2000 at 08:00:46AM +1100, Darren Reed wrote:
  
  btw, I completely agree with the need to have good pccard/pcmcia support.
  For the first time there was a real reason for me to ditch FreeBSD on an
  Intel platform box (my laptop) and go with NetBSD where my 3c589d works
  just fine.
  
 
 My 3c589d works just fine now, along with suspend/resume :)  (under 4.0).
 

  And these are also working perfectly for me as well under -current on a
ThinkPad 770.

Tom




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Serious server-side NFS problem

1999-12-16 Thread Tom Bartol



On Thu, 16 Dec 1999, Warner Losh wrote:

 In message [EMAIL PROTECTED] Tom Bartol 
writes:
 : IIRC it does update uptime properly after a suspend in 2.2.8 but does not
 : do so in 3.X and -current on my ThinkPad 770.
 
 define correctly.  Eg, if I suspend for an hour it adds an hour?
 
 Warner
 

Yeah, that's what I meant by "correctly".  I don't recall seeing a
"thundering herd" effect afterwards.  Hmmm... which reminds me, I believe
this was not stock 2.2.8 but rather 2.2.8-PAO.  I had thought that the
lion's share of PAO code got merged into 3.0-current at some point.  When
I tried 3.0-current after this merge, suspend and resume worked fine on my
770 with the exception of uptime.

Tom




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Serious server-side NFS problem

1999-12-16 Thread Tom Bartol



On Thu, 16 Dec 1999, Warner Losh wrote:

 In message [EMAIL PROTECTED] Tom Bartol 
writes:
 : I tried 3.0-current after this merge, suspend and resume worked fine on my
 : 770 with the exception of uptime.
 
 I can confirm that uptime, at least as reported by uptime(1), isn't
 increased in the latest -current.
 
 Warner
 

I confirm this as well.  Perhaps after suspend we need:

Allow ntp to update time and adjust boottime as necessary.
Then set uptime = time-boottime

Tom




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: sysinstall: is it really at the end of its lifecycle?

1999-12-15 Thread Tom Bartol




On Wed, 15 Dec 1999, Donn Miller wrote:

 "Jordan K. Hubbard" wrote:
  
   I was under the impression that Polar Bears are native to the
   North Pole and penguins are from the South Pole.
  
  Really?  What eats penguins then?  Maybe walrus?
 
 Arctic Foxes.
 
 
 - Donn


I doubt it.  No peguins in the arctic.  But Sea Lions definitely do.

Tom




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: yet more TP 600E fun...

1999-08-13 Thread Tom Bartol


I see the same problem when trying to boot FreeBSD-3.0-RELEASE (or there
abouts) and later cdroms on my TP770.
I can boot FreeBSD-2.2.8 and earlier FreeBSD-3.0-SNAP cdroms just fine.  I
think it has something to do with the new boot loader that went in just
before 3.0-RELEASE.

Tom


On Fri, 13 Aug 1999, David E. Cross wrote:

 I attempt to boot a CD off of the TP600E and I get the following errors:
 
 "Can't work out which disk we are booting from."
 "Guessed BIOS device 0x8b not found by probes, defaulting to disk0:"
 
 Then whenever it attmpts to access "disk0:" it goes to the floppy drive.
 
 Suggestions?
 
 --
 David Cross   | email: [EMAIL PROTECTED] 
 Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
 Rensselaer Polytechnic Institute, | Ph: 518.276.2860
 Department of Computer Science| Fax: 518.276.4033
 I speak only for myself.  | WinNT:Linux::Linux:FreeBSD
 
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-current" in the body of the message
 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: yet more TP 600E fun...

1999-08-13 Thread Tom Bartol


I'd be more than happy to do the pestering if some one could write down
a detailed description of exactly how the TP's BIOS is non-compliant.
I don't know enough about the boot process and BIOS to write such a
description.

Tom


On Fri, 13 Aug 1999, Mike Smith wrote:

  I attempt to boot a CD off of the TP600E and I get the following errors:
  
  "Can't work out which disk we are booting from."
  "Guessed BIOS device 0x8b not found by probes, defaulting to disk0:"
  
  Then whenever it attmpts to access "disk0:" it goes to the floppy drive.
  
  Suggestions?
 
 Known weirdness in the TP's BIOS not handled properly by the 
 bootloader.  I don't have immediate plans to do anything about this; 
 you could try hacking the loader to accept the 0x8b value and see if 
 that actually works.  Or you could pester IBM to DTRT.
 
 -- 
 \\  The mind's the standard   \\  Mike Smith
 \\  of the man.   \\  [EMAIL PROTECTED]
 \\-- Joseph Merrick   \\  [EMAIL PROTECTED]
 
 
 
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-current" in the body of the message
 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: solid NFS patch #6 avail for -current - need testers files)

1999-04-21 Thread Tom Bartol


On Thu, 22 Apr 1999, Peter Wemm wrote:

 Matthew Reimer wrote:
  Great work guys! It almost seems that -current is more stable than
  -stable!
  
  Matt
 
 Funny you should mention it.  I've heard this from a number of people over
 the last week..  One has even suggested using a particular known-good 4.0
 snapshot in preference to a 3.1-stable for a production system..
 
 Cheers,
 -Peter

And on this note -- is it planned to merge or backport these patches to
-stable?  We make very heavy use of NFS (udp, 100mb fxp0 fullduplex). 
We're using FreeBSD-3.1-STABLE as NFS clients to a big Auspex NS7000 NFS
file server.  We're in production mode in our lab and can't risk running
-current on many of our machines so we've decided to run -stable on ALL of
them (except perhaps MY machine but don't tell anyone ;-)

Tom





To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: /sys/boot, egcs vs. gcc, -Os

1999-04-08 Thread Tom Bartol


On Thu, 8 Apr 1999, John Polstra wrote:

 
 I am not saying the dependencies are broken.  I'm just lamenting the
 general problem that it's difficult to upgrade a port that depends on
 a lot of things.  It's a general structural problem, and I don't know
 how to fix it.
 
 Say you've got a bunch of ports that all depend on the same shared
 library -- maybe libjpeg or libXpm.  You've had them installed for
 a few months, and they all work fine.  Now you decide to upgrade
 one of them, the foo port.  Oops, it requires a newer version of
 libjpeg.  You have to remove the old libjpeg so that the newer one
 can be installed without a lot of complaints.  Oops, a bunch of other
 ports used the old libjpeg.  Now you have to upgrade those ports too.
 Oops, some of those ports depend on libXpm, and a new version of it is
 needed now.  Oops, now some other ports that used the old libXpm need
 to be upgraded.
 
 At this point, you throw up your hands, pkg_delete -f everything,
 and reinstall all your ports from scratch.  And the next time you're
 tempted to upgrade a port, you decide it would be easier to just buy
 a new machine. :-)
 
 John

I agree completely.  I had just recently run into this problem in a big
way over gnome.  I am not familiar at all with the inner workings of the
ports/package database system but it occurred to me that perhaps the
database is currently only storing which packages a given package depends
upon and is NOT storing which packages depend upon a given
package -- i.e. the leaves know which branch they are on but the branches
don't know which leaves they bear.  If this is in fact the case then it
seems to me that a first step in improving the behaviour of the
port/package system is to make the database be a leaf-to-branch and
branch-to-leaf linked relationship tree that can be traversed as needed.
I'm not sure of the standard Computer Science jargon to describe such a
tree.

Tom




To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: port dependencies (was Re: /sys/boot, egcs vs. gcc, -Os)

1999-04-08 Thread Tom Bartol


On Thu, 8 Apr 1999, Jacques Vidrine wrote:

 On 8 April 1999 at 12:24, John Polstra j...@polstra.com wrote:
 [snip]
  Say you've got a bunch of ports that all depend on the same shared
  library -- maybe libjpeg or libXpm.  You've had them installed for
  a few months, and they all work fine.  Now you decide to upgrade
  one of them, the foo port.  Oops, it requires a newer version of
  libjpeg.  You have to remove the old libjpeg so that the newer one
  can be installed without a lot of complaints.  Oops, a bunch of other
  ports used the old libjpeg.  Now you have to upgrade those ports too.
  Oops, some of those ports depend on libXpm, and a new version of it is
  needed now.  Oops, now some other ports that used the old libXpm need
  to be upgraded.
 
 Now I understand what you are saying.  The current ports structure
 only goes one way through the dependency graph.  Maybe when building a
 particular port, not only should dependencies be checked, but anything
 that depends on the port needs to be rebuilt.
 
 Jacques Vidrine / n...@nectar.com / nec...@freebsd.org

Exactly correct.

Tom




To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



4GB of RAM?!

1999-02-02 Thread Tom Bartol


Hi all,

Has anyone yet tried running -current on a Xeon with 4GB RAM installed? 
We're about to place an order for a Quad Xeon and would like to have 4GB
of RAM installed if it is feasible and/or possible to make this work with
-current. 

Thanks for the help,

Tom



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message