Re: Laptop suggestions?

On Thu, Jul 31, 2008 at 9:06 AM, Tom Evans <tevans.uk <at> googlemail.com> wrote:
>
> On Wed, 2008-07-30 at 21:45 -0300, Carlos A. M. dos Santos wrote:
>> Please define "comfortable". I've been running FreeBSD 7.0 pretty
>> comfortably on my HP nx6320 for several months now. I never attempted
>> to use neither Bluetooth nor the fingerprint reader, so I don't miss
>> them. The only real drawback I've found was that the memory card
>> reader does not work. I also ran 8.0-CURRENT on a HP 6910p because 7.0
>> did not support the WI-FI card.

> Another happy BSD user on HP - nc6320 this time though. intel(4x)
> graphics, wpi(4) wifi, bge(4) networking, fwochi(4) firewire, serial
> port, plenty of USB ports. Even the fingerprint scanner works
> (security/libfprint).
> I don't use bluetooth or the card reader, so cannot comment on them.
>
> The one down side of my HP laptop is the HP BIOS refuses to start up
> with a different wifi card installed - I'd quite like to use an ath(4)
> based card..

Do you have an up-to-date BIOS? I had some problems booting from USB
that I could solve using the latest BIOS version.

--

-- 
If you think things can't get worse it's probably only
because you lack sufficient imagination.
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"

Re: Laptop suggestions?

> On Thu, Jul 31, 2008 at 11:17:54AM +0200, Achim Patzner wrote:
> > Drivers? Who cares. Serial port? Just plug in an USB-to-serial.
> 
> You've obviously never used a USB-to-serial adapter.  Are you aware of
> the fact that there is no serial device class as part of the USB
> specification?  (Quite a great irony, if you ask me.  Universal SERIAL
> Bus, yet no serial device class...)  AFAIK, there isn't even a draft
> proposal for such.
> 
and even more amazing, that we still have to configure the baudrate!

> You *must* have drivers for a USB-to-serial adapter.  And every adapter
> is different, depending upon the adapter chipset used, many of which are
> not disclosed in product specifications, so there's no way to guarantee
> it'll work with FreeBSD.  On -stable (I believe) some people have
> mentioned which USB-to-serial adapters work great under FreeBSD and
> Windows, while others are horrible (dropping characters, broken flow
> control, interrupt issues, and many other problems).
> 
> > It's a perfect machine for the desktop; I've forbidden FreeBSD to come
> > creeping out the server room some years ago. I need it for keeping the
> > penguins away, it's really good at that (no wonder - pitchforks do  
> > hurt).
> > But it's a pain for desktoppy things - so why shouldn't I use something
> > less useful? And the other way round: Running Mac OS X Server is the
> > most painful thing I've ever been paid for; I've been replacing a lot of
> > them with FreeBSD-based servers.
> 
> The amount of rhetoric in these two paragraphs is amazing; I literally
> cannot tell if you're trolling with anti-FreeBSD propaganda, or if

Re: Laptop suggestions?

On Thu, 2008-07-31 at 20:26 -0300, Carlos A. M. dos Santos wrote:
> On Thu, Jul 31, 2008 at 9:06 AM, Tom Evans <tevans.uk <at> googlemail.com> wrote:
> >
> > On Wed, 2008-07-30 at 21:45 -0300, Carlos A. M. dos Santos wrote:
> >> Please define "comfortable". I've been running FreeBSD 7.0 pretty
> >> comfortably on my HP nx6320 for several months now. I never attempted
> >> to use neither Bluetooth nor the fingerprint reader, so I don't miss
> >> them. The only real drawback I've found was that the memory card
> >> reader does not work. I also ran 8.0-CURRENT on a HP 6910p because 7.0
> >> did not support the WI-FI card.
> 
> > Another happy BSD user on HP - nc6320 this time though. intel(4x)
> > graphics, wpi(4) wifi, bge(4) networking, fwochi(4) firewire, serial
> > port, plenty of USB ports. Even the fingerprint scanner works
> > (security/libfprint).
> > I don't use bluetooth or the card reader, so cannot comment on them.
> >
> > The one down side of my HP laptop is the HP BIOS refuses to start up
> > with a different wifi card installed - I'd quite like to use an ath(4)
> > based card..
> 
> Do you have an up-to-date BIOS? I had some problems booting from USB
> that I could solve using the latest BIOS version.
> 

Yes, latest BIOS. If you search through the BIOS file, it is fairly easy
to find the list of 'approved' HP vendor/device ids that it will allow
to be put in the mini pci-e slot and still boot up (there are only 4
distinct device ids defined in the BIOS). I've considered just manually

Re: Laptop suggestions?

On 2008-Jul-27 17:23:46 -0400, Zaphod Beeblebrox <zbeeble <at> gmail.com> wrote:
> we'd need a method of remembering what file handles were
>connected to so that they could be "reopened" (in this, I envision some type
>of text string... maybe a URI/URL).  As a bonus, this would give us process
>migration between systems, too (assuming the URI were portable between self
>same systems --- which isn't horribly hard with nfs mounts and whatnot).

What you are describing here sounds more like the process
checkpointing functionality that Softway (I think it was) developed
sometime last century.  There should be a paper on it in an AUUG
Conference Proceedings somewhere.  Process checkpointing is somewhat
different to suspend/resume: With suspend/resume, you are saving the
entire system state - which is basically a matter of dumping physical
RAM to disk and being able to restore it later.  You don't need to be
able to isolate individual processes and there's no need to 'reopen'
file handles because they will automatically re-instantiate when you
restore the kernel state that included them being open.

--

-- 
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.

Re: Laptop suggestions?

> And if you go with Lenovo, be aware that their T60/T60p/T61/T61p series
> (and possibly the X-series) are known to sport very high temperatures.
> Some people have reported temperatures of nearly 90C on their GPU (when
> idling), which has a direct effect on the overall temperature of the CPU
> (due to close proximity) and so on.  This requires the fan to be on at
> almost all times (usually low-speed mode).  Others have it worse (the
> laptop literally shutting off in the middle of operation):
>

I bought Lenovo T61 recently and dont see any hight GPU temperatures. GPU
temperature is about 55C when idling. I never notice (so far) temperature
above
65C. More annoying is (subjectively) hot HDD under right wrist.

Cheers Aleš

_______________________________________________
freebsd-mobile <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
To unsubscribe, send any mail to "freebsd-mobile-unsubscribe <at> freebsd.org"

Re: consolekit on 7.0-STABLE i386

Nate Eldredge wrote:
> On Wed, 30 Jul 2008, sam wrote:
>
>>
>> 0 19 0   1113M    29M   112   0   0   0    32   0   0   1  100 5549 
>> 1682 11 1 88
>> 0 19 0   1113M    29M   297   0   0   0   136   0   0   2  122 78880 
>> 1749  6 7 87
>> |--------------------------------------------------------------------
>>
>> consolekit in |waitvt state, influencing on high volumes in procs-b
>
> I don't understand what the problem is.  It looks like consolekit is 
> sleeping and not using any CPU.  "waitvt" just indicates where in the 
> kernel it's sleeping.  I don't understand what you mean by "high 
> volumes in procs-b".
>
How-To-Repeat:
--------------------------------------------------------------
# (|cd /usr/ports/sysutils/consolekit/ && make install clean)

# /usr/local/etc/rc.d/dbus forcestart

# vmstat -w 1
 procs      memory      page                   disk   faults         cpu
 r b w     avm    fre   flt  re  pi  po    fr  sr ad0   in   sy   cs us 
sy id
 2 1 0  62252K   644M    88   0   0   0    80   0   0    2   83  279  1  
1 98
 0 1 0  62252K   644M     0   0   0   0     0   0   0    4  134  292  0  

Re: consolekit on 7.0-STABLE i386

On Fri, Aug 01, 2008 at 06:16:49PM +0400, sam wrote:
> Nate Eldredge wrote:
> >On Wed, 30 Jul 2008, sam wrote:
> >
> >>
> >>0 19 0   1113M    29M   112   0   0   0    32   0   0   1  100 5549 
> >>1682 11 1 88
> >>0 19 0   1113M    29M   297   0   0   0   136   0   0   2  122 78880 
> >>1749  6 7 87
> >>|--------------------------------------------------------------------
> >>
> >>consolekit in |waitvt state, influencing on high volumes in procs-b
> >
> >I don't understand what the problem is.  It looks like consolekit is 
> >sleeping and not using any CPU.  "waitvt" just indicates where in the 
> >kernel it's sleeping.  I don't understand what you mean by "high 
> >volumes in procs-b".
> >
> How-To-Repeat:
> --------------------------------------------------------------
> # (|cd /usr/ports/sysutils/consolekit/ && make install clean)
> 
> # /usr/local/etc/rc.d/dbus forcestart
> 
> # vmstat -w 1
> procs      memory      page                   disk   faults         cpu
> r b w     avm    fre   flt  re  pi  po    fr  sr ad0   in   sy   cs us 
> sy id
> 2 1 0  62252K   644M    88   0   0   0    80   0   0    2   83  279  1  
> 1 98

Re: consolekit on 7.0-STABLE i386

Kostik Belousov wrote:
> On Fri, Aug 01, 2008 at 06:16:49PM +0400, sam wrote:
>   
>> Nate Eldredge wrote:
>>     
>>> On Wed, 30 Jul 2008, sam wrote:
>>>
>>>       
>>>> 0 19 0   1113M    29M   112   0   0   0    32   0   0   1  100 5549 
>>>> 1682 11 1 88
>>>> 0 19 0   1113M    29M   297   0   0   0   136   0   0   2  122 78880 
>>>> 1749  6 7 87
>>>> |--------------------------------------------------------------------
>>>>
>>>> consolekit in |waitvt state, influencing on high volumes in procs-b
>>>>         
>>> I don't understand what the problem is.  It looks like consolekit is 
>>> sleeping and not using any CPU.  "waitvt" just indicates where in the 
>>> kernel it's sleeping.  I don't understand what you mean by "high 
>>> volumes in procs-b".
>>>
>>>       
>> How-To-Repeat:
>> --------------------------------------------------------------
>> # (|cd /usr/ports/sysutils/consolekit/ && make install clean)
>>
>> # /usr/local/etc/rc.d/dbus forcestart
>>
>> # vmstat -w 1
>> procs      memory      page                   disk   faults         cpu

Re: consolekit on 7.0-STABLE i386

On Fri, Aug 01, 2008 at 06:38:13PM +0400, sam wrote:
> Kostik Belousov wrote:
> >On Fri, Aug 01, 2008 at 06:16:49PM +0400, sam wrote:
> >  
> >>Nate Eldredge wrote:
> >>    
> >>>On Wed, 30 Jul 2008, sam wrote:
> >>>
> >>>      
> >>>>0 19 0   1113M    29M   112   0   0   0    32   0   0   1  100 5549 
> >>>>1682 11 1 88
> >>>>0 19 0   1113M    29M   297   0   0   0   136   0   0   2  122 78880 
> >>>>1749  6 7 87
> >>>>|--------------------------------------------------------------------
> >>>>
> >>>>consolekit in |waitvt state, influencing on high volumes in procs-b
> >>>>        
> >>>I don't understand what the problem is.  It looks like consolekit is 
> >>>sleeping and not using any CPU.  "waitvt" just indicates where in the 
> >>>kernel it's sleeping.  I don't understand what you mean by "high 
> >>>volumes in procs-b".
> >>>
> >>>      
> >>How-To-Repeat:
> >>--------------------------------------------------------------
> >># (|cd /usr/ports/sysutils/consolekit/ && make install clean)
> >>
> >># /usr/local/etc/rc.d/dbus forcestart
> >>
> >># vmstat -w 1

[Call for testers] New cvsmode for csup patch

Hello again,

Even in these new subversion days, I'm not giving up :) Thanks for the feedback
I got on the previous patches. It brought some issues with the patch that should
now be fixed. It took some time, but I've been priotitizing other projects.
However, here are a list of the changes:

- Someone experienced segfaults when doing an update. This was because using
  wrong format specifier to proto_printf.
- Some parts of the protocol was missing, such as support for the Z command, and
  supporting U in cvsmode. This is now implemented.
- The rcsfile implementation would use huge amounts of memory when running
  diffs. Lately, it was easier to pinpoint where this happened due to huge diff
  chains, showing clearly where the memory was lost. This is now fixed, and csup
  seems to have a stable memory usage. Please report if you see otherwise.
- Some simplifications and removal of code that is not needed.
- Added an update of the usr.bin/csup Makefile. Thanks to kris <at>  for pointing
  this out.

I hope all of you that tried the previous patch will try this one. Your previous
feedback was valuable in finding out where I should look to fix these problems.

Patches can be found for CURRENT:
http://people.freebsd.org/~lulf/patches/csup/csup_2008-08-01_CURRENT.diff

and 7-STABLE:
http://people.freebsd.org/~lulf/patches/csup/csup_2008-08-01_RELENG_7.diff

Any feedback welcome!