I have a friend that has 5.4 where SSHD keeps timing out before
authentification. Box has a hardwired 3com NIC. We?ve tried everything
but can't find the cause of the timeouts. What gives?
-----Original Message-----
From: owner-freebsd-stable@freebsd.org
[mailto:owner-freebsd-stable@freebsd.org] On Behalf Of
freebsd-stable-request@freebsd.org
Sent: Tuesday, April 12, 2005 11:15 PM
To: freebsd-stable@freebsd.org
Subject: freebsd-stable Digest, Vol 105, Issue 28
Send freebsd-stable mailing list submissions to
freebsd-stable@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
or, via email, send a message with subject or body 'help' to
freebsd-stable-request@freebsd.org
You can reach the person managing the list at
freebsd-stable-owner@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-stable digest..."
Today's Topics:
1. Re: virtual machines (MariusN?nnerich)
2. Re: Intel 6300ESB (ICH) SMBus controller not working (Mike Tancsa)
3. Re: Package managment (Robert Backhaus)
4. Adaptec 1210 weird behaviour (Edwin Groothuis)
5. Re: kernel killing processes when out of swap (Vivek Khera)
6. Re: kernel killing processes when out of swap (Nick Barnes)
7. Re: SuperMicro X5DP8-G2MB/(2)XEON 2.4/1GB RAM 5.4-S Freeze
(Marc Olzheim)
8. Re: kernel killing processes when out of swap (Marc Olzheim)
9. RE: SuperMicro X5DP8-G2MB/(2)XEON 2.4/1GB RAM 5.4-S Freeze
(Don Bowman)
10. Re: SuperMicro X5DP8-G2MB/(2)XEON 2.4/1GB RAM 5.4-S Freeze
(Marc Olzheim)
11. Re: kernel killing processes when out of swap (Nick Barnes)
12. Re: 4.11R panics (Doug White)
13. Re: suboptimal handling of accidentally pulled usb devices
(5.4) (Doug White)
14. Re: virtual machines (Scott Lambert)
15. Re: FreeBSD 5.3 SMP freezes with MySQL 4.1 (Young Lee)
16. Re: Adaptec 1210 weird behaviour (Scott Long)
17. Re: Kodak USB flash reader causes freezes, panics (Brooks Davis)
18. Re: virtual machines (Frank Mayhar)
19. Re: kernel killing processes when out of swap (Dan Nelson)
20. Re: Package managment (Brooks Davis)
21. Re: kernel killing processes when out of swap (Matthias Buelow)
22. Re: [PATCH] Stability fixes for IPS driver for 4.x (Scott Long)
23. Re: FreeBSD 5.3 SMP freezes with MySQL 4.1 (Vivek Khera)
24. Re: Adaptec 1210 weird behaviour (Edwin Groothuis)
25. Re: Adaptec 1210 weird behaviour (Scott Long)
26. Re: Adaptec 1210 weird behaviour (Jon Noack)
27. Re: kernel killing processes when out of swap (Don Lewis)
28. Re: kernel killing processes when out of swap (Nick Barnes)
29. strange atacontrol output in 5.4-RC1 and 5.4-RC2
(Rostislav Krasny)
30. Re: kernel killing processes when out of swap (Matthias Buelow)
31. scsi card recommendation (Dikshie)
32. reliable "panic: isa_dmastart: bad bounce buffer"
(Mikhail Teterin)
----------------------------------------------------------------------
Message: 1
Date: Tue, 12 Apr 2005 14:04:43 +0200
From: MariusN?nnerich<marius.nuennerich@gmx.net>
Subject: Re: virtual machines
To: freebsd-stable@freebsd.org
Message-ID: <20050412140443.61f9cc32@olaf>
Content-Type: text/plain; charset="us-ascii"
Hi,
emulators/qemu could do the job for you :)
cheers
Marius
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20050412/c
62edf2f/attachment-0001.bin
------------------------------
Message: 2
Date: Tue, 12 Apr 2005 08:31:00 -0400
From: Mike Tancsa <mike@sentex.net>
Subject: Re: Intel 6300ESB (ICH) SMBus controller not working
To: Philip Murray <pmurray@nevada.net.nz>
Cc: freebsd-stable@freebsd.org
Message-ID: <6.2.1.2.0.20050412082221.04164328@64.7.153.2>
Content-Type: text/plain; charset="us-ascii"; format=flowed
At 01:03 AM 12/04/2005, Philip Murray wrote:>On 12/04/2005, at 2:38 PM, Mike Tancsa wrote:
>
>>At 09:24 PM 11/04/2005, Philip Murray wrote:
>>>Hi,
>>>
>>>I'm running RELENG_5 on a Dell PowerEdge 750 and the ichsmb
driver
>>>doesn't want to work with it, I get the following on boot:
>>>
>>>ichsmb0: <Intel 6300ESB (ICH) SMBus controller> port
0x8c0-0x8df irq
17 >>>at device 31.3 on pci0
>>>device_attach: ichsmb0 attach returned 6
>>
>>Does it work if you add
>>
>>debug.acpi.disabled="sysresource"
>>
>>to /boot/loader.conf
>>
>
>Thanks for that, It kind of worked. Am I correct in thinking that, that
>prevents ACPI attaching to the controller so that the ichsmb driver
can? >In which case, if ACPI does attach to it, does that mean I'd get
>temperature values in the hw.acpi.thermal tree?
Not sure of the full details as to what it disables, but I can still get
it
with it in my loader.conf
sysctl -A hw.acpi.thermal
hw.acpi.thermal.min_runtime: 0
hw.acpi.thermal.polling_rate: 10
hw.acpi.thermal.tz0.temperature: 40.0C
hw.acpi.thermal.tz0.active: -1
hw.acpi.thermal.tz0.thermal_flags: 0
hw.acpi.thermal.tz0._PSV: 73.0C
hw.acpi.thermal.tz0._HOT: -1
hw.acpi.thermal.tz0._CRT: 75.0C
hw.acpi.thermal.tz0._ACx: 73.0C -1 -1 -1 -1 -1 -1 -1 -1 -1
# grep -i smbu /var/run/dmesg.boot
ichsmb0: <Intel 82801EB (ICH5) SMBus controller> port 0x5000-0x501f irq
10
at device 31.3 on pci0
smbus0: <System Management Bus> on ichsmb0
smb0: <SMBus generic I/O> on smbus0
# cat /boot/loader.conf
debug.acpi.disabled="sysresource"
Also, for xmbmon, it doesnt seem to need the smb device compiled into
the
kernel. I think the issue is the ICH6 info has changed and its just not
parsing the information correctly. Try mbmom -D on your machine
[verify1] /home/mdtancsa# mbmon -D
Probe Request: none
>>> Testing Reg's at SMBus <<<
[Intel8XX(ICH/ICH2/ICH3/ICH4/ICH5/ICH6), IO-Base:0x5000]
SMBus slave 0x5E(0x2F) found...
SMBus slave 0x88(0x44) found...
SMBus slave 0xA0(0x50) found...
SMBus slave 0xA4(0x52) found...
Set SMBus slave address: 0x5E
Probing Winbond/Asus/LM78/79 chip:
CR40:0xFF, CR41:0xFF, CR42:0xFF, CR43:0xFF
CR44:0xFF, CR45:0xFF, CR46:0xFF, CR47:0xFF
CR48:0xFF, CR49:0xFF, CR4A:0xFF, CR4B:0xFF
CR4C:0xFF, CR4D:0xFF, CR4E:0xFF, CR4F:0xFF
CR56:0xFF, CR58:0xFF, CR59:0xFF, CR5D:0x19
CR3E:0xFF, CR13:0xFF, CR17:0xFF, CRA1:0xFF
CR20:0xFF, CR22:0xFF, CR23:0xFF, CR24:0xFF
CR27:0xFF, CR29:0xFF, CR2A:0xFF, CR2B:0xFF
Set SMBus slave address: 0x5E
Probing Winbond W83L78x chip:
CR40:0xFF, CR41:0xFF, CR42:0xFF, CR43:0xFF
CR44:0xFF, CR45:0xFF, CR46:0xFF, CR47:0xFF
CR48:0xFF, CR49:0xFF, CR4A:0xFF, CR4B:0xFF
CR4C:0xFF, CR4D:0xFF, CR4E:0xFF, CR4F:0xFF
CR20:0xFF, CR21:0xFF, CR22:0xFF, CR23:0xFF
CR26:0xFF, CR27:0xFF, CR28:0xFF, CR29:0xFF
CR2B:0xFF, CR2C:0xFF, CR2D:0xFF, CR2E:0xFF
SMBus[Intel8XX(ICH/ICH2/ICH3/ICH4/ICH5/ICH6)] found, but No HWM
available
on it!!
>>> Testing Reg's at ISA-IO <<<
[ISA Port IO-Base:0x290]
Probing Winbond/Asus/LM78/79 chip:
CR40:0x01, CR41:0x00, CR42:0x00, CR43:0xFE
CR44:0xFF, CR45:0x00, CR46:0x00, CR47:0xF0
CR48:0x2D, CR49:0x03, CR4A:0x01, CR4B:0xC4
CR4C:0x18, CR4D:0x15, CR4E:0x01, CR4F:0xA3
CR56:0x00, CR58:0xFF, CR59:0xFF, CR5D:0xFF
CR3E:0x00, CR13:0x00, CR17:0x3C, CRA1:0xC7
CR20:0x82, CR22:0xD2, CR23:0xBE, CR24:0x5E
CR27:0x20, CR29:0x3C, CR2A:0xFF, CR2B:0xF0
Probing ITE7805/7812/SIS950 chip:
CR00:0x01, CR01:0xF0, CR02:0x01, CR03:0xF0
CR0A:0x01, CR48:0x2D, CR50:0xFF, CR51:0xFF
CR20:0x82, CR21:0xC7, CR22:0xD2, CR23:0xBE
CR24:0x5E, CR25:0x00, CR26:0x00, CR27:0x20
CR28:0xFF, CR29:0x3C, CR2A:0xFF, CR2B:0xF0
CR0B:0x01, CR0D:0x3C, CR0E:0x01, CR0F:0x01
Using ISA-IO access method!!
* Int.Tec.Exp. Chip IT8705F/IT8712F or SIS950 found.
[verify1] /home/mdtancsa#
On a 915 box I have,
[verify1]% mbmon
Temp.= 255.0, 240.0, 61.0; Rot.= 11250, 1350000, 675000
Vcore = 2.08, 3.20; Volt. = 3.34, 5.08, 5.78, -0.00, -0.00
^C
[verify1]%
However, lmmon does seem to work
[verify1] /home/mdtancsa# lmmon -p
MB temp:
33C / 91F / 306K
Fans:
1 : 0 rpm
2 : 2812 rpm
3 : 0 rpm
Voltages:
Vcore1 : +2.078V
Vcore2 : +3.125V
+ 3.3V : +3.281V
+ 5.0V : +4.932V
+12.0V : +5.875V
-12.0V : -0.000V
- 5.0V : -0.000V
and the thermal info is there
[verify1] /home/mdtancsa# sysctl -A hw.acpi.thermal
hw.acpi.thermal.min_runtime: 0
hw.acpi.thermal.polling_rate: 10
hw.acpi.thermal.tz0.temperature: 33.0C
hw.acpi.thermal.tz0.active: -1
hw.acpi.thermal.tz0.thermal_flags: 0
hw.acpi.thermal.tz0._PSV: 50.0C
hw.acpi.thermal.tz0._HOT: -1
hw.acpi.thermal.tz0._CRT: 100.0C
hw.acpi.thermal.tz0._ACx: 50.0C -1 -1 -1 -1 -1 -1 -1 -1 -1
[verify1] /home/mdtancsa#
>sysutils/xmbmon and sysutils/healthd can't seem to read anything from
it >anyway. Is this because the SMBus has no temperature sensors tied to
it? >It has them in the BIOS, so I assumed I could read them in FreeBSD.
>
>I get ichsmb0: irq 0x04 during -1 in dmesg when trying healthd and
>
>root@alexis:~/ > healthd -S
>ioctl(SMB_WRITEB): Permission denied
>
>Cheers,
>Phil
------------------------------
Message: 3
Date: Tue, 12 Apr 2005 22:45:11 +1000
From: Robert Backhaus <robbak@gmail.com>
Subject: Re: Package managment
To: Jan Sebosik <sebosik@demax.sk>
Cc: freebsd-stable@freebsd.org
Message-ID: <d449958050412054575ec4cbd@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Apr 12, 2005 6:28 PM, Jan Sebosik <sebosik@demax.sk>
wrote:> Hi
>
> I`ve got one simple question: if i`ve built packages on my freebsd
> 5.3-RELEASE system, do I need to rebuilt them again for 5.4-RELEASE
> (after downloading && compiling from sources) ?
>
> Best regards,
> Jan Sebosik
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to
"freebsd-stable-unsubscribe@freebsd.org">
With care, in many situations, you should be able to get away with it.
Problems occur with ports that contain kernel modules (ltmdm,
nvidia-driver). There have also been major changes within ports (new
gtk versions, and a gnome upgrade) which will make partial rebuilding
hazardous.
Most of us would recommend a general rebuild, for safety's sake.
------------------------------
Message: 4
Date: Tue, 12 Apr 2005 23:07:27 +1000
From: Edwin Groothuis <edwin@mavetju.org>
Subject: Adaptec 1210 weird behaviour
To: freebsd-stable@freebsd.org
Message-ID: <20050412130727.GE1209@k7.mavetju>
Content-Type: text/plain; charset=us-ascii
The Adaptec 1210 is a serial ATA RAID0/1 controller.
When the two disks are configured as RAID1, FreeBSD still sees two
harddisks instead of one.
This is with 5.3. Scary :-)
Will try this weekend with 5.4
--
Edwin Groothuis | Personal website:
http://www.mavetju.org
edwin@mavetju.org | Weblog:
http://weblog.barnet.com.au/edwin/
------------------------------
Message: 5
Date: Tue, 12 Apr 2005 09:52:59 -0400
From: Vivek Khera <vivek@khera.org>
Subject: Re: kernel killing processes when out of swap
To: freebsd-stable@freebsd.org
Message-ID: <0c9a92c2eb7461f25aa924322407f950@khera.org>
Content-Type: text/plain; charset="us-ascii"
On Apr 11, 2005, at 12:01 PM, Steven Hartland wrote:
> of swap? Which leads to the question would it not be more sensible to
> kill off the largest process first as its more than likely that it is
> responsible
> for the problem?
>
so when this largest process is your production database server for
your e-commerce site, what will you change your recommendation to be?
basically, there is no "right" choice of process to kill. a machine
that is out of resources is just a bad situation, and the right thing
is to try to avoid getting there with careful monitoring and planning.
Vivek Khera, Ph.D.
+1-301-869-4449 x806
------------------------------
Message: 6
Date: Tue, 12 Apr 2005 15:06:41 +0100
From: Nick Barnes <Nick.Barnes@pobox.com>
Subject: Re: kernel killing processes when out of swap
To: Vivek Khera <vivek@khera.org>
Cc: freebsd-stable@freebsd.org
Message-ID: <51434.1113314801@thrush.ravenbrook.com>
At 2005-04-12 13:52:59+0000, Vivek Khera writes:
> > of swap? Which leads to the question would it not be more sensible
to> > kill off the largest process first as its more than likely that it
is > > responsible
> > for the problem?
> >
>
> so when this largest process is your production database server for
> your e-commerce site, what will you change your recommendation to be?
>
> basically, there is no "right" choice of process to kill. a
machine
> that is out of resources is just a bad situation, and the right thing
> is to try to avoid getting there with careful monitoring and planning.
The right choice is for mmap() to return ENOMEM, and then for malloc()
to return NULL, but almost no operating systems make this choice any
more.
Nick B
------------------------------
Message: 7
Date: Tue, 12 Apr 2005 16:16:04 +0200
From: Marc Olzheim <marcolz@stack.nl>
Subject: Re: SuperMicro X5DP8-G2MB/(2)XEON 2.4/1GB RAM 5.4-S Freeze
To: Aaron Summers <aaronsummers@gmail.com>
Cc: stable@freebsd.org
Message-ID: <20050412141604.GA1570@stack.nl>
Content-Type: text/plain; charset="us-ascii"
On Mon, Apr 11, 2005 at 10:12:32PM -0400, Aaron Summers
wrote:> We have a SuperMicro X5DP8-G2 Motherboard, 2xXEON 2.4, 1GB RAM server
> running 5.4-STABLE that keeps freezing up. We have replaced RAM, HD,
> SCSI controller, etc. To no avail. We are running SMP GENERIC
> Kernel. I cannot get the system to panic, leave a core dump, etc. It
> just always freezes. The server functions as a web server in a
> HSphere Cluster. I am about out of options besides loading 4.11
> (since our 4 series servers never die). Any help, feedback, clues,
> similar experiences, etc would be greatly appreciated.
>
> On SCSI: The onboard Adaptec 7902 gives a dump on bootup but appears
> to work. I read the archived post about this issue. The system still
> locked up with an Adaptec 7982B that did not give this message.
We've got exactly the same, but then with the X5DPR-IG2+/X5DPR-8G2+.
I've got about 25-30 running FreeBSD 4.6 - 4.11 running perfectly
stable, but the 3 that I installed 5.x on, (currently all 5.4-STABLE),
keep on hanging themselves up completely, even with no read load on
them, within a week.
CPUs range from 3.06 to 3.2 GHz, all of them have 4x1GB DIMMs, and
3 SEAGATE ST3146807LC 0007's...
I tried updating the BIOSes as well, with both a standard BIOS and one
given to us bh supermicro preconfigured fro com-console, so I could
flashed them with a remotely booted DOS floppy over com-console. :-)
Another thing I noticed: motherboard versions from before 2005 do not
detect sio0 on the right place: port 0x2f8-0x2ff irq 3 on acpi0 (the
normal place for sio1), resulting in loader/kernel comconsole going to
the right port and the userland comconsole going to the wrong port...
This problem does not occur on newer versions of the servers...
Marc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20050412/6
d433d0c/attachment-0001.bin
------------------------------
Message: 8
Date: Tue, 12 Apr 2005 16:26:40 +0200
From: Marc Olzheim <marcolz@stack.nl>
Subject: Re: kernel killing processes when out of swap
To: Nick Barnes <Nick.Barnes@pobox.com>
Cc: Vivek Khera <vivek@khera.org>
Message-ID: <20050412142640.GB1570@stack.nl>
Content-Type: text/plain; charset="us-ascii"
On Tue, Apr 12, 2005 at 03:06:41PM +0100, Nick Barnes
wrote:> The right choice is for mmap() to return ENOMEM, and then for malloc()
> to return NULL, but almost no operating systems make this choice any
> more.
No, the problem occurs only when previously allocated / mmap()d blocks
are actually used (written) and when the total of virtual memory has
been overcommitted: Physical pages are not allocated to processes at
malloc() time, but at time of first usage (Copy On Write).
A possible solution would be for the kernel to only hand out memory
allocation-time when it's possible to back it up with virtual memory,
but normal memory usage allows for overcommits just fine and many
programs have been programmed in a way that assumes this behaviour, for
instance by sparsely using large allocations instead of adding the
possible extra bookkeeping to allow for smaller allocations. It just
makes a lot of memory allocation / duplication issues a lot easier...
Marc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20050412/3
e207788/attachment-0001.bin
------------------------------
Message: 9
Date: Tue, 12 Apr 2005 10:40:10 -0400
From: "Don Bowman" <don@SANDVINE.com>
Subject: RE: SuperMicro X5DP8-G2MB/(2)XEON 2.4/1GB RAM 5.4-S Freeze
To: "Marc Olzheim" <marcolz@stack.nl>, "Aaron Summers"
<aaronsummers@gmail.com>, <carlos@infodrive.com.ar>
Cc: stable@freebsd.org
Message-ID:
<2BCEB9A37A4D354AA276774EE13FB8C23A6B41@mailserver.sandvine.com>
Content-Type: text/plain; charset="us-ascii"
From: Marc Olzheim> On Mon, Apr 11, 2005 at 10:12:32PM -0400, Aaron Summers wrote:
> > We have a SuperMicro X5DP8-G2 Motherboard, 2xXEON 2.4, 1GB
> RAM server
> > running 5.4-STABLE that keeps freezing up. We have
> replaced RAM, HD,
> > SCSI controller, etc. To no avail. We are running SMP GENERIC
> > Kernel. I cannot get the system to panic, leave a core
> dump, etc. It
> > just always freezes. The server functions as a web server in a
> > HSphere Cluster. I am about out of options besides loading 4.11
> > (since our 4 series servers never die). Any help, feedback, clues,
> > similar experiences, etc would be greatly appreciated.
> >
> > On SCSI: The onboard Adaptec 7902 gives a dump on bootup
> but appears
> > to work. I read the archived post about this issue. The
> system still
> > locked up with an Adaptec 7982B that did not give this message.
>
The problem is with the periodic SMM interrupt and the bios.
The attached program (ich-periodic-smm-disable.c) will fix the problem.
For more information on what it does, see the Intel ICH3 datasheet.
compile as 'gcc ich-periodic-smm-disable.c; ./a.out' and you will be
good.
Run this on each boot.
I think you only need to clear PERIODIC_EN.
--don
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ich-periodic-smm-disable.c
Type: application/octet-stream
Size: 3994 bytes
Desc: ich-periodic-smm-disable.c
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20050412/f
6d714e2/ich-periodic-smm-disable-0001.obj
------------------------------
Message: 10
Date: Tue, 12 Apr 2005 17:01:43 +0200
From: Marc Olzheim <marcolz@stack.nl>
Subject: Re: SuperMicro X5DP8-G2MB/(2)XEON 2.4/1GB RAM 5.4-S Freeze
To: Don Bowman <don@SANDVINE.com>
Cc: Marc Olzheim <marcolz@stack.nl>
Message-ID: <20050412150143.GC1570@stack.nl>
Content-Type: text/plain; charset="us-ascii"
On Tue, Apr 12, 2005 at 10:40:10AM -0400, Don Bowman
wrote:> The problem is with the periodic SMM interrupt and the bios.
>
> The attached program (ich-periodic-smm-disable.c) will fix the
problem.> For more information on what it does, see the Intel ICH3 datasheet.
>
> compile as 'gcc ich-periodic-smm-disable.c; ./a.out' and you will
be
> good.
> Run this on each boot.
>
> I think you only need to clear PERIODIC_EN.
Ok, I'll try it right away, thanks a lot!
Marc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20050412/9
24fd8b5/attachment-0001.bin
------------------------------
Message: 11
Date: Tue, 12 Apr 2005 16:09:21 +0100
From: Nick Barnes <Nick.Barnes@pobox.com>
Subject: Re: kernel killing processes when out of swap
To: Marc Olzheim <marcolz@stack.nl>
Cc: Vivek Khera <vivek@khera.org>
Message-ID: <51621.1113318561@thrush.ravenbrook.com>
At 2005-04-12 14:26:40+0000, Marc Olzheim writes:> On Tue, Apr 12, 2005 at 03:06:41PM +0100, Nick Barnes wrote:
> > The right choice is for mmap() to return ENOMEM, and then for
malloc()> > to return NULL, but almost no operating systems make this choice any
> > more.
>
> No, the problem occurs only when previously allocated / mmap()d blocks
> are actually used (written) and when the total of virtual memory has
> been overcommitted: Physical pages are not allocated to processes at
> malloc() time, but at time of first usage (Copy On Write).
Yes, implicit in my statement is that the OS shouldn't overcommit. I
remember when overcommit was new (maybe 1990), and some Unix (Irix,
perhaps, or AIX?) made it switchable. There was a bit of flurry in
the OS community, as some people (myself included) felt that the OS
shouldn't make promises it couldn't fulfill, and that this "kill a
random process" behaviour was more of a bug than a solution. Consider
a parallel design which allows (say) file descriptors to be
overcommitted. You can open a billion files, but if you touch one of
them, that consumes a finite kernel resource, and if the kernel has
run out then a randomly chosen process gets killed. Great.
> many programs have been programmed in a way that assumes this
> behaviour, for instance by sparsely using large allocations instead
> of adding the possible extra bookkeeping to allow for smaller
> allocations.
This is the well-known problem with my fantasy world in which the OS
doesn't overcommit any resources. All those programs are broken, but
it's too costly to fix them. If overcommit had been resisted more
effectively in the first place, those programs would have been written
properly.
My recollection, quite possibly faulty, is that FreeBSD came quite
late to the overcommit binge party.
Nick B
------------------------------
Message: 12
Date: Tue, 12 Apr 2005 09:04:38 -0700 (PDT)
From: Doug White <dwhite@gumbysoft.com>
Subject: Re: 4.11R panics
To: Kirill Ponomarew <krion@voodoo.oberon.net>
Cc: freebsd-stable@FreeBSD.org
Message-ID: <20050412090310.Q2178@carver.gumbysoft.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 10 Apr 2005, Kirill Ponomarew wrote:
> On Fri, Apr 08, 2005 at 10:14:17AM -0700, Doug White wrote:
> > > Fatal trap 12: page fault while in kernel mode
> > > fault virtual address = 0x20202020
> >
> > Hm, something ran into a bunch of ASCII spaces..
> >
> > Can you jump to frame #6 and print *kbp? It appears the kernel
malloc> > bucket list is corrupted, so I'm curious just how badly that
struct
is> > spammed.
>
> #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
> 487 if (dumping++) {
> (kgdb) up 6
> #6 0xc0193533 in malloc (size=324, type=0xc030d780, flags=9)
> at /usr/src/sys/kern/kern_malloc.c:243
> 243 va = kbp->kb_next;
> (kgdb) print *kbp
> $1 = {kb_next = 0x20202020 <Address 0x20202020 out of bounds>,
> kb_last = 0xcc8fa000 "", kb_calls = 5704, kb_total = 448,
kb_elmpercl = 8,> kb_totalfree = 13, kb_highwat = 40, kb_couldfree = 0}
Not very, apparently.
Dunno what to say ... I'd guess something coughed up a bad address to a
DMA op or something and it just happened to land there. If you can
reproduce this with any sort of regularity there might be a bug,
although
that seems unlikely since that code hasn't changed in years and this is
the first such report I've seen of this :)
--
Doug White | FreeBSD: The Power to Serve
dwhite@gumbysoft.com | www.FreeBSD.org
------------------------------
Message: 13
Date: Tue, 12 Apr 2005 09:07:07 -0700 (PDT)
From: Doug White <dwhite@gumbysoft.com>
Subject: Re: suboptimal handling of accidentally pulled usb devices
(5.4)
To: Matthias Buelow <mkb@incubus.de>
Cc: freebsd-stable@freebsd.org
Message-ID: <20050412090627.S2178@carver.gumbysoft.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sat, 9 Apr 2005, Matthias Buelow wrote:
> every so often, I forget to unmount my ipod (usb2) before pulling it
> from my PC. While this and the mess that ensues is clearly a user
> error, it would be nice if this exceptional situation would get
handled> a bit more gracefully by the OS. What happens now is that I cannot
use> the device anymore ("Resource unavailable") until I reboot.
Trying to
> unmount the still mounted filesystem (no matter if the device is
plugged> back in or not) simply gives:
Please see the archives for a lenghty explanation of why this is not
going
to be fixed in the near-term future.
--
Doug White | FreeBSD: The Power to Serve
dwhite@gumbysoft.com | www.FreeBSD.org
------------------------------
Message: 14
Date: Tue, 12 Apr 2005 11:16:29 -0500
From: Scott Lambert <lambert@lambertfam.org>
Subject: Re: virtual machines
To: freebsd-stable@freebsd.org
Message-ID: <20050412161629.GA12421@sysmon.tcworks.net>
Content-Type: text/plain; charset=us-ascii
On Tue, Apr 12, 2005 at 11:05:00AM +0100, Nick Barnes
wrote:> I run FreeBSD as my main desktop, but occasionally have to develop,
> build, or test software on a variety of other x86 operating systems
> (mainly Windows NT 4, Windows XP Pro, and Red Hat Linux). At the
> moment I have a row of mini-towers and a KVM switch. I'd much rather
> run these other machines as virtual machines under FreeBSD. Can
> anyone recommend virtualizing software for FreeBSD? I don't mind
> having to pay, as long as it really works.
I have not used it, but it claims to support FreeBSD as the host:
http://www.serenityvirtual.com/
I have had a good relationship with the company that is behind the
product. I just haven't used that particular product, especially now
that my primary workstation is a PowerBook.
--
Scott Lambert KC5MLE Unix
SysAdmin
lambert@lambertfam.org
------------------------------
Message: 15
Date: Wed, 13 Apr 2005 00:23:39 +0800
From: Young Lee <ncisoft@163.com>
Subject: Re: FreeBSD 5.3 SMP freezes with MySQL 4.1
To: Uzi Klein <uzi@bmby.com>
Cc: freebsd-stable@freebsd.org
Message-ID: <20050413000852.9F7C.NCISOFT@163.com>
Content-Type: text/plain; charset="US-ASCII"
I had repeated the panic by reset debug.mpsafenet from 0 to 1,
after that, the system automatically reboot after several hours,
and if debug.mpsafenet was set to 0, the system is stable.
so i guess this is a tcp stack or NIC driver SMP thread-safe issue,
normally my server got over 1000 interrupts/s on bge, I have plan
to replace the onboard bge NIC to fxp and set debug.mpsafenet
to 1 to see what will happen this week.
--
Young Lee
On Thu, 31 Mar 2005 18:03:08 +0200
Uzi Klein <uzi@bmby.com> wrote:> Young Lee wrote:
> > Thank you very much. My server's uptime last two days by refer to
> > Klein's configuration, it's impactful, thanks to Klein.
> >
> > My concern of stablility is focus on mysql's build options as
> > BUILD_STATIC & BUILD_OPTIMIZED, but it looks like ridiculous
> > without any logicality, build_static should have not any different
> > between dynamatic lib. I will do some testing after the current
> > configuration to be proven by uptime over one week, and try to
> > find out how to repeat the panic.
> >
>
> I think the real change was usin linuxthreads for SMP honestly.
> The BUILD_STATIC & BUILD_OPTIMIZED only increase speed by not setting
> shared libs and enables assembly AFAIK.
>
> --
> Uzi Klein
> Software Development Manager
> BMBY Software Systems Ltd
> 2 Hataasia St., Yokneam, Israel
> P: +972 4 959 79 89
> F: +972 3 617 93 36
> http://www.bmby.com
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to
"freebsd-stable-unsubscribe@freebsd.org"
------------------------------
Message: 16
Date: Tue, 12 Apr 2005 10:21:27 -0600
From: Scott Long <scottl@samsco.org>
Subject: Re: Adaptec 1210 weird behaviour
To: Edwin Groothuis <edwin@mavetju.org>
Cc: freebsd-stable@freebsd.org
Message-ID: <425BF587.5070904@samsco.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Edwin Groothuis wrote:> The Adaptec 1210 is a serial ATA RAID0/1 controller.
>
> When the two disks are configured as RAID1, FreeBSD still sees two
> harddisks instead of one.
>
> This is with 5.3. Scary :-)
> Will try this weekend with 5.4
>
The 1210 is not a real RAID controller, it's a SATA controller with an
Adaptec BIOS that does RAID 0 and 1 during boot. It's up to the OS to
do the RAID operations after that. The new ATA driver in 6-current
might actually be able to handle this, so it's worth trying. 5.4
definitely will not.
Scott
------------------------------
Message: 17
Date: Tue, 12 Apr 2005 09:41:26 -0700
From: Brooks Davis <brooks@one-eyed-alien.net>
Subject: Re: Kodak USB flash reader causes freezes, panics
To: Tim Howe <tim.howe@celebrityresorts.com>
Cc: freebsd-stable@freebsd.org
Message-ID: <20050412164126.GA18471@odin.ac.hmc.edu>
Content-Type: text/plain; charset="us-ascii"
On Mon, Apr 11, 2005 at 10:14:14PM -0400, Tim Howe
wrote:> Brooks Davis <brooks@one-eyed-alien.net> writes:
>
> > On Mon, Apr 11, 2005 at 05:24:15PM -0400, Tim Howe wrote:
> >
> > > Reproducibly, if I begin copying data to a [...] CF card [...] it
> > > works for a while, then freezes the system.
> >
> > It is quite likely that 5.4 fixed your problem.
>
> Unfortunately not. I was able, having mounted the filesystem with no
> synchronization options, to copy 171MiB of data onto it and unmount.
> However when I re-mounted it with the same options and tried to copy
> 71MiB more, it again froze midway through.
Sounds like you should file a PR about the issue. Are you sure the file
system in question is OK? There were some msdosfs corruption bugs fixed
recently.
> Everything else (X11, sound, printing, input) seems to be working
> perfectly with 5.4, but I did notice something new and strange with
> regard to umass. I still have to run "true > /dev/da0" to get
the
slice> to show up, but now I get the following:
>
> [1042] ~ # true > /dev/da0
> [1043] ~ # camcontrol rescan 0
> Re-scan of bus 0 was successful
> [1044] ~ # ls -l /dev/da0*
> crw-r----- 1 root operator 4, 21 Apr 11 21:45 /dev/da0
> crw-r----- 1 root operator 4, 28 Apr 11 21:45 /dev/da0s1
> crw-r----- 1 root operator 4, 29 Apr 11 21:45 /dev/da0s1s1
> [1045] ~ # mount_msdosfs /dev/da0s1 /mnt/cf
> [1046] ~ # umount /mnt/cf
> [1047] ~ # mount_msdosfs /dev/da0s1s1 /mnt/cf
> [1048] ~ # umount /mnt/cf
I'd highly recommend running the command in the other direction so you
try to read rather than write. It shouldn't matter, but that makes me
nervous (not that I think it has anything to do with your problem.) It
would appear that your da0s1 has data at the front that looks like an
MBR and GEOM is attaching to it. I'm not sure what the best solution to
that problem is. Probably a reformat.
-- Brooks
--
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20050412/6
f3cd312/attachment-0001.bin
------------------------------
Message: 18
Date: Tue, 12 Apr 2005 09:44:39 -0700 (PDT)
From: Frank Mayhar <frank@exit.com>
Subject: Re: virtual machines
To: Scott Lambert <lambert@lambertfam.org>
Cc: freebsd-stable@freebsd.org
Message-ID: <200504121644.j3CGid7i013259@realtime.exit.com>
Content-Type: text/plain; charset=US-ASCII
Scott Lambert wrote:> On Tue, Apr 12, 2005 at 11:05:00AM +0100, Nick Barnes wrote:
> > I run FreeBSD as my main desktop, but occasionally have to develop,
> > build, or test software on a variety of other x86 operating systems
> > (mainly Windows NT 4, Windows XP Pro, and Red Hat Linux). At the
> > moment I have a row of mini-towers and a KVM switch. I'd much
rather> > run these other machines as virtual machines under FreeBSD. Can
> > anyone recommend virtualizing software for FreeBSD? I don't mind
> > having to pay, as long as it really works.
>
> I have not used it, but it claims to support FreeBSD as the host:
>
> http://www.serenityvirtual.com/
>
> I have had a good relationship with the company that is behind the
> product. I just haven't used that particular product, especially now
> that my primary workstation is a PowerBook.
Note that SVISTA doesn't (currently) support 5-stable, or indeed
anything
past 4.x. There have been questions asked about that in the fora but
they
have gone unanswered, last I checked.
I bought it for 4.x and it worked fine. Better in some ways than qemu,
although in other ways it was not as good (qemu seems to have better
display support, while SVISTA's networking is vastly better). Since
I've
gone to 5-stable, though, qemu is my only real alternative.
--
Frank Mayhar frank@exit.com http://www.exit.com/
Exit Consulting http://www.gpsclock.com/
http://www.exit.com/blog/frank/
------------------------------
Message: 19
Date: Tue, 12 Apr 2005 11:45:36 -0500
From: Dan Nelson <dnelson@allantgroup.com>
Subject: Re: kernel killing processes when out of swap
To: Nick Barnes <Nick.Barnes@pobox.com>
Cc: Marc Olzheim <marcolz@stack.nl>
Message-ID: <20050412164536.GB4842@dan.emsphone.com>
Content-Type: text/plain; charset=us-ascii
In the last episode (Apr 12), Nick Barnes said:> This is the well-known problem with my fantasy world in which the OS
> doesn't overcommit any resources. All those programs are broken, but
> it's too costly to fix them. If overcommit had been resisted more
> effectively in the first place, those programs would have been
> written properly.
Another issue is things like shared libraries; without overcommit you
need to reserve the file size * the number of processes mapping it,
since you can't guarantee they won't touch every COW page handed to
them. I think you can design a shlib scheme where you can map the libs
RO; not sure if you would take a performance hit or if there are other
considerations. There's a similar problem when large processes want to
fork+exec something; for a fraction of a second you need to reserve 2x
the process's space until the exec frees it. vfork solves that
problem, at the expense of blocking the parent until the child's
process is loaded.
--
Dan Nelson
dnelson@allantgroup.com
------------------------------
Message: 20
Date: Tue, 12 Apr 2005 09:52:01 -0700
From: Brooks Davis <brooks@one-eyed-alien.net>
Subject: Re: Package managment
To: Robert Backhaus <robbak@gmail.com>
Cc: Jan Sebosik <sebosik@demax.sk>
Message-ID: <20050412165201.GB18471@odin.ac.hmc.edu>
Content-Type: text/plain; charset="us-ascii"
On Tue, Apr 12, 2005 at 10:45:11PM +1000, Robert Backhaus
wrote:> On Apr 12, 2005 6:28 PM, Jan Sebosik <sebosik@demax.sk> wrote:
> > Hi
> >
> > I`ve got one simple question: if i`ve built packages on my freebsd
> > 5.3-RELEASE system, do I need to rebuilt them again for 5.4-RELEASE
> > (after downloading && compiling from sources) ?
> >
> > Best regards,
> > Jan Sebosik
> > _______________________________________________
> > freebsd-stable@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to
"freebsd-stable-unsubscribe@freebsd.org"> >
> With care, in many situations, you should be able to get away with it.
> Problems occur with ports that contain kernel modules (ltmdm,
> nvidia-driver). There have also been major changes within ports (new
> gtk versions, and a gnome upgrade) which will make partial rebuilding
> hazardous.
>
> Most of us would recommend a general rebuild, for safety's sake.
I certaintly would not. Unless you actually need to upgrade, there
is no reason to rebuild between minor OS upgrades. If your programs
stop working in that case, it's usually a bug. For that matter, most
application will work if compiled on an older major version.
-- Brooks
--
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20050412/e
0bfd9ad/attachment-0001.bin
------------------------------
Message: 21
Date: Tue, 12 Apr 2005 20:17:32 +0200
From: Matthias Buelow <mkb@mkbuelow.net>
Subject: Re: kernel killing processes when out of swap
To: Dan Nelson <dnelson@allantgroup.com>
Cc: Marc Olzheim <marcolz@stack.nl>
Message-ID: <200504121817.j3CIHWRT017619@drjekyll.mkbuelow.net>
Dan Nelson <dnelson@allantgroup.com> writes:
>Another issue is things like shared libraries; without overcommit you
>need to reserve the file size * the number of processes mapping it,
>since you can't guarantee they won't touch every COW page handed to
>them. I think you can design a shlib scheme where you can map the libs
>RO; not sure if you would take a performance hit or if there are other
>considerations. There's a similar problem when large processes want to
>fork+exec something; for a fraction of a second you need to reserve 2x
>the process's space until the exec frees it. vfork solves that
>problem, at the expense of blocking the parent until the child's
>process is loaded.
Is that really problematic these days, with huge disk sizes? I mean, a
couple GB swap don't really hurt anyone these days when you've got disk
sizes around 250GB. Especially when you gain a lot more reliable
operation through this. And maybe one could make overcommitting
configurable, so that all scenarios are provided for. I for one would
happily add some more swap space if I could get the behaviour that the
OS doesn't go politician and promise all and everything which it then
cannot deliver. Overcommitting made sense in the early 90ies, when you
had a large address space (4GB) and relatively small disks (~1GB). I'm
not sure it makes much sense anymore, it's a typical kludge.
This stuff has been discussed in the past. It'll probably continue to
be an issue, until it has been resolved satisfactorily (i.e., both the
overcommitters and reliable-VMers can have their way).
mkb.
------------------------------
Message: 22
Date: Tue, 12 Apr 2005 12:26:43 -0600
From: Scott Long <scottl@samsco.org>
Subject: Re: [PATCH] Stability fixes for IPS driver for 4.x
To: David Sze <dsze@alumni.uwaterloo.ca>
Cc: Anthony Downer <Anthony.Downer@reuters.com>
Message-ID: <425C12E3.5050205@samsco.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
David Sze wrote:> At 11:31 PM 10/04/2005 -0600, Scott Long wrote this to All:
>
>> Making a driver PAE-ified means either teaching it to do 64-bit
>> scatter-gather (assuming that the peripheral hardware can do this
>> and that it's documented), or teaching the driver to correctly
handle
>> EINPROGRESS from bus_dmamap_load() along with using the proper busdma
>> tag limits. The strategy I took with 6.x/5.x was the second one
since>> I didn't have good IPS docs in front of me and I wanted it follow
the
>> APIs correctly. I did test it with 8GB of memory and it performed
>> correctly under load. I haven't taken a close enough look at your
>> MFC patch to say for sure if it's correct or not. I'm not sure
if
>> I'll have time to take another look in the next few days,
unfortunately.>> Is there any chance you could test 5.x/6.0 under load with PAE just
to>> validate the assertion that it works correctly there?
>
>
> I had a chance to test 5.4-RC1 (i386) today with GENERIC, SMP, PAE,
and > SMP-PAE kernels (the last one is just PAE with "options SMP").
>
> To recap, the hardware is an IBM xSeries 346, Dual Xeon 3GHz
> (non-E64MT), ServeRAID-7K.
>
> GENERIC and SMP survived "make buildkernel", but PAE and SMP-PAE
paniced > reproducibly doing the same. The DDB stack trace doesn't appear to be
> anywhere near the IPS driver though, so I'm way out of my league.
>
>
Darnit, hard to say if this is an existing bug in 5.4 or if it's a
bug/corruption in ips. Can you re-run with PAE disabled? Would you be
willing to put the Giant lock back on top of the driver? This would
mean modifying the call to bus_intr_config(), adding the D_GIANTNEEDED
flag to the disk structure in disk_create(), and switching the mutex
argument in bus_dma_tag_create() for the sg_dmatag tag.
Scott
------------------------------
Message: 23
Date: Tue, 12 Apr 2005 15:02:42 -0400
From: Vivek Khera <vivek@khera.org>
Subject: Re: FreeBSD 5.3 SMP freezes with MySQL 4.1
To: Young Lee <ncisoft@163.com>
Cc: freebsd-stable@freebsd.org
Message-ID: <ef8c9be3359b96fb4fd8bde8c04218d7@khera.org>
Content-Type: text/plain; charset="us-ascii"
On Apr 12, 2005, at 12:23 PM, Young Lee wrote:
> I had repeated the panic by reset debug.mpsafenet from 0 to 1,
> after that, the system automatically reboot after several hours,
> and if debug.mpsafenet was set to 0, the system is stable.
>
> so i guess this is a tcp stack or NIC driver SMP thread-safe issue,
> normally my server got over 1000 interrupts/s on bge, I have plan
> to replace the onboard bge NIC to fxp and set debug.mpsafenet
> to 1 to see what will happen this week.
>
I just did the exact same thing: disable motherboard bge in preference
to em (intel) on a PCI card, and have had 100% stable for the last 6
days. Normally every night during heavy network backup and database
reporting the bge ports would either be reset after watchdog timeout,
or the whole system would freeze with nothing logged to console,
screen, or BIOS... so going 6 days without any events leads me to point
a big hairy finger at bge driver. Even with mpsafenet=0, I was having
these timeouts and lockups, and bad performance thrown in. :-(
I run with mpsafenet default and the em ethernet driver. Be sure to
disable the onboard bge in your BIOS.
I'm on a dual opteron Tyan S2881 motherboard, for what that's worth.
FreeBSD 5.4-STABLE from April 4 is my OS.
My guess is with the intel NIC you will find yourself much more stable.
On my lesser loaded machines the bge driver holds up ok.
Vivek Khera, Ph.D.
+1-301-869-4449 x806
------------------------------
Message: 24
Date: Wed, 13 Apr 2005 05:18:30 +1000
From: Edwin Groothuis <edwin@mavetju.org>
Subject: Re: Adaptec 1210 weird behaviour
To: Scott Long <scottl@samsco.org>
Cc: freebsd-stable@freebsd.org
Message-ID: <20050412191830.GF1209@k7.mavetju>
Content-Type: text/plain; charset=us-ascii
On Tue, Apr 12, 2005 at 10:21:27AM -0600, Scott Long
wrote:> Edwin Groothuis wrote:
> >The Adaptec 1210 is a serial ATA RAID0/1 controller.
> >
> >When the two disks are configured as RAID1, FreeBSD still sees two
> >harddisks instead of one.
> >
> >This is with 5.3. Scary :-)
> >Will try this weekend with 5.4
>
> The 1210 is not a real RAID controller, it's a SATA controller with an
> Adaptec BIOS that does RAID 0 and 1 during boot. It's up to the OS to
> do the RAID operations after that. The new ATA driver in 6-current
Euhm. Oh. Software RAID? A la WinModems?
But then I don't understand that it gets away with advertising it
as a RAID0/1 controller...
Edwin
--
Edwin Groothuis | Personal website:
http://www.mavetju.org
edwin@mavetju.org | Weblog:
http://weblog.barnet.com.au/edwin/
------------------------------
Message: 25
Date: Tue, 12 Apr 2005 13:18:14 -0600
From: Scott Long <scottl@samsco.org>
Subject: Re: Adaptec 1210 weird behaviour
To: Edwin Groothuis <edwin@mavetju.org>
Cc: freebsd-stable@freebsd.org
Message-ID: <425C1EF6.4000608@samsco.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Edwin Groothuis wrote:> On Tue, Apr 12, 2005 at 10:21:27AM -0600, Scott Long wrote:
>
>>Edwin Groothuis wrote:
>>
>>>The Adaptec 1210 is a serial ATA RAID0/1 controller.
>>>
>>>When the two disks are configured as RAID1, FreeBSD still sees two
>>>harddisks instead of one.
>>>
>>>This is with 5.3. Scary :-)
>>>Will try this weekend with 5.4
>>
>>The 1210 is not a real RAID controller, it's a SATA controller with
an
>>Adaptec BIOS that does RAID 0 and 1 during boot. It's up to the OS
to
>>do the RAID operations after that. The new ATA driver in 6-current
>
>
> Euhm. Oh. Software RAID? A la WinModems?
More or less. It's quite common these days, with lots of motherboard
makers getting into the game and licensing software raid stacks for
their onboard SATA controllers.
>
> But then I don't understand that it gets away with advertising it
> as a RAID0/1 controller...
If you don't understand then you should be glad that you didn't choose
Marketting as a profession ;-)
Scott
------------------------------
Message: 26
Date: Tue, 12 Apr 2005 14:23:21 -0500
From: Jon Noack <noackjr@alumni.rice.edu>
Subject: Re: Adaptec 1210 weird behaviour
To: Edwin Groothuis <edwin@mavetju.org>
Cc: freebsd-stable@freebsd.org
Message-ID: <425C2029.2010109@alumni.rice.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 4/12/2005 2:18 PM, Edwin Groothuis wrote:> On Tue, Apr 12, 2005 at 10:21:27AM -0600, Scott Long wrote:
>>Edwin Groothuis wrote:
>>>The Adaptec 1210 is a serial ATA RAID0/1 controller.
>>>
>>>When the two disks are configured as RAID1, FreeBSD still sees two
>>>harddisks instead of one.
>>>
>>>This is with 5.3. Scary :-)
>>>Will try this weekend with 5.4
>>
>>The 1210 is not a real RAID controller, it's a SATA controller with
an
>>Adaptec BIOS that does RAID 0 and 1 during boot. It's up to the OS
to
>>do the RAID operations after that. The new ATA driver in 6-current
>
> Euhm. Oh. Software RAID? A la WinModems?
>
> But then I don't understand that it gets away with advertising it
> as a RAID0/1 controller...
The RAID functionality is implemented in the driver, so the "product"
as
a whole is a RAID0/1 controller. This is very common; in fact, most
products under $150-200 are like this...
Jon
------------------------------
Message: 27
Date: Tue, 12 Apr 2005 12:36:47 -0700 (PDT)
From: Don Lewis <truckman@FreeBSD.org>
Subject: Re: kernel killing processes when out of swap
To: dnelson@allantgroup.com
Cc: marcolz@stack.nl
Message-ID: <200504121936.j3CJalHc036643@gw.catspoiler.org>
Content-Type: TEXT/plain; charset=us-ascii
On 12 Apr, Dan Nelson wrote:> In the last episode (Apr 12), Nick Barnes said:
>> This is the well-known problem with my fantasy world in which the OS
>> doesn't overcommit any resources. All those programs are broken,
but
>> it's too costly to fix them. If overcommit had been resisted more
>> effectively in the first place, those programs would have been
>> written properly.
>
> Another issue is things like shared libraries; without overcommit you
> need to reserve the file size * the number of processes mapping it,
> since you can't guarantee they won't touch every COW page handed to
> them. I think you can design a shlib scheme where you can map the
libs> RO; not sure if you would take a performance hit or if there are other
> considerations.
The data and bss sizes in most shared libraries are small, so I don't
think that is much of an issue. The text pages are more of a problem
because of the need to do relocation fixups. It would be nice to mark
the text pages read only after relocation and/or prelink the binaries
and shared libraries like recent versions of Linux do. Text page
modifications to set debugger breakpoints would also have to be handled.
A bigger problem is the default stack size of 64 MB per process. That
quickly adds up to a lot of reserved swap space. One way of handling
that might be an ELF header field that could limit the stack size to a
smaller value for most binaries. I don't happen to remember the default
SunOS 4.x stack size, but I suspect that SunOS 4.x overcommited stack
space on the assumption that most processes wouldn't use anything close
to the limit.
> There's a similar problem when large processes want to
> fork+exec something; for a fraction of a second you need to reserve 2x
> the process's space until the exec frees it. vfork solves that
> problem, at the expense of blocking the parent until the child's
> process is loaded.
The fork() case was a common failure mode that I ran into back when
I was using SunOS 4. It was usually a fairly benign problem because the
fork() was triggered by an interactive command, and when it failed I
could usually recover from the problem by exiting some other process or
by freeing up some swap space by removing files from the swap-backed
/tmp directory.
In an earlier life, I had the displeasure of trying to run large
processes (~3x RAM) on a small-memory machine without either COW or
vfork(). Actually, fork() was required in at least some of the cases
because the process wanted to make a snapshot of itself to do processing
on its in-memory data in the background. The machine would page like
crazy and swap other processes in and out for about an hour each time
the large process forked.
------------------------------
Message: 28
Date: Tue, 12 Apr 2005 22:33:37 +0100
From: Nick Barnes <Nick.Barnes@pobox.com>
Subject: Re: kernel killing processes when out of swap
To: Matthias Buelow <mkb@mkbuelow.net>
Cc: Marc Olzheim <marcolz@stack.nl>
Message-ID: <52802.1113341617@thrush.ravenbrook.com>
At 2005-04-12 18:17:32+0000, Matthias Buelow writes:
> This stuff has been discussed in the past.
Indeed. For a couple of examples from the days before BSD systems got
overcommit, see these threads from 1990 and 1991:
<http://groups-beta.google.com/group/comp.unix.aix/browse_frm/thread/915
41dbf6b658465/4c590978f1001507?q=overcommit&rnum=14#4c590978f1001507>
<http://groups-beta.google.com/group/comp.unix.aix/browse_frm/thread/38c
9bb9996d30eb1/e8c30f78c44a3f62?q=overcommit&rnum=12#e8c30f78c44a3f62>
Nick B
------------------------------
Message: 29
Date: Tue, 12 Apr 2005 23:34:07 +0200
From: Rostislav Krasny <rosti.bsd@gmail.com>
Subject: strange atacontrol output in 5.4-RC1 and 5.4-RC2
To: freebsd-stable@freebsd.org
Message-ID: <59e2ee81050412143459b7c679@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi,
I have two i386 computers with close configuration of ATA disks:
mercury# atacontrol list
ATA channel 0:
Master: ad0 <WDC AC14300R/17.01J17> ATA/ATAPI revision 4
Slave: no device present
ATA channel 1:
Master: ad2 <FUJITSU MPB3021ATU/2011> ATA/ATAPI revision 3
Slave: acd0 <TOSHIBA CD-ROM XM-6602B/1017> ATA/ATAPI revision 0
vega# atacontrol list
ATA channel 0:
Master: ad0 <WDC AC28400R/17.01J17> ATA/ATAPI revision 4
Slave: no device present
ATA channel 1:
Master: ad2 <WDC AC22100H/12.07H12> ATA/ATAPI revision 0
Slave: ad3 <Seagate Technology 1275MB - ST31276A/1.37> ATA/ATAPI
revision 2
Mercury is Intel SE440BX-2 motherboard based computer with FreeBSD
5.4-RC2. Vega is Intel 430TX chipset based computer with FreeBSD
5.4-RC1. When I run ' atacontrol cap 0 0' I get the same last part of
the output:
Feature Support Enable Value Vendor
write cache yes yes
read ahead yes yes
dma queued no no 0/0x00
SMART yes yes
microcode download no no
security no yes
power management yes yes
advanced power management no no 0/0x00
automatic acoustic management no no 0/0x00 0/0x00
How could the security feature be not supported and enabled at the same
time?
------------------------------
Message: 30
Date: Wed, 13 Apr 2005 00:07:11 +0200
From: Matthias Buelow <mkb@mkbuelow.net>
Subject: Re: kernel killing processes when out of swap
To: Nick Barnes <Nick.Barnes@pobox.com>
Cc: Marc Olzheim <marcolz@stack.nl>
Message-ID: <200504122207.j3CM7BE7018595@drjekyll.mkbuelow.net>
Nick Barnes <Nick.Barnes@pobox.com> writes:
>> This stuff has been discussed in the past.
>Indeed. For a couple of examples from the days before BSD systems got
>overcommit, see these threads from 1990 and 1991:
>
><http://groups-beta.google.com/group/comp.unix.aix/browse_frm/thread/91
541dbf6>b658465/4c590978f1001507?q=overcommit&rnum=14#4c590978f1001507>
>
><http://groups-beta.google.com/group/comp.unix.aix/browse_frm/thread/38
c9bb999>6d30eb1/e8c30f78c44a3f62?q=overcommit&rnum=12#e8c30f78c44a3f62>
Apparently, it can be turned off on AIX, quoting from
http://tinyurl.com/4epc8:
``If the PSALLOC environment variable is set to early, then every
program started in that environment from that point on, but not
including currently running processes, runs in the early allocation
environment. In the early allocation environment, interfaces such as the
malloc subroutine and the brk subroutine will fail if sufficient paging
space cannot be reserved when the request is made.
Processes run in the early allocation environment mode are not sent the
SIGKILL signal if a low paging space condition occur.''
Googling showed that on Linux 2.6, overcommit can be disabled globally
through the vm.overcommit_memory sysctl.
I hope that some day some mechanism to solve that problem will be
available in FreeBSD aswell.
mkb.
------------------------------
Message: 31
Date: Wed, 13 Apr 2005 09:58:55 +0700
From: Dikshie <dikshie@ppk.itb.ac.id>
Subject: scsi card recommendation
To: freebsd-stable@freebsd.org
Message-ID: <20050413025855.GA25698@ppk.itb.ac.id>
Content-Type: text/plain; charset=us-ascii
dear all,
I would like to buy SCSI card which must:
- support Ultra 320
- support RAID 0,1,5, and 1/0
any recommendation for FreeBSD-5.x ?
thanks !
-dikshie-
------------------------------
Message: 32
Date: Tue, 12 Apr 2005 23:14:45 -0400 (EDT)
From: Mikhail Teterin <mi@corbulon.video-collage.com>
Subject: reliable "panic: isa_dmastart: bad bounce buffer"
To: stable@FreeBSD.org
Message-ID: <200504130314.j3D3EjrT043747@corbulon.video-collage.com>
Content-Type: text/plain; charset="us-ascii"
Hello!
Whenever I try to mount a floppy disk:
mount -t msdosfs /dev/fd0 /mnt
I get:
panic: isa_dmastart: bad bounce buffer
The OS is FreeBSD-5.4-STABLE from last night, amd64. dmesg attached.
DR-DOS boots perfectly fine from this floppy...
Any ideas? Thanks!
-mi
-------------- next part --------------
Copyright (c) 1992-2005 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights
reserved.
FreeBSD 5.4-STABLE #0: Tue Apr 12 22:42:27 EDT 2005
root@blue.virtual-estates.net:/var/obj/var/src/sys/SILVER
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Opteron(tm) Processor 246 (2004.56-MHz K8-class CPU)
Origin = "AuthenticAMD" Id = 0xf5a Stepping = 10
Features=0x78bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,
MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2>
AMD Features=0xe0500800<SYSCALL,NX,MMX+,LM,3DNow+,3DNow>
real memory = 2147418112 (2047 MB)
avail memory = 2057740288 (1962 MB)
ACPI APIC Table: <A M I OEMAPIC >
MADT: Forcing active-low polarity and level trigger for SCI
ioapic0 <Version 1.1> irqs 0-23 on motherboard
ioapic1 <Version 1.1> irqs 24-27 on motherboard
ioapic2 <Version 1.1> irqs 28-31 on motherboard
acpi0: <A M I OEMXSDT> on motherboard
acpi0: Power Button (fixed)
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x5008-0x500b on acpi0
cpu0: <ACPI CPU> on acpi0
acpi_throttle0: <ACPI CPU Throttling> on cpu0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib1: <ACPI PCI-PCI bridge> at device 1.0 on pci0
pci1: <ACPI PCI bus> on pcib1
nvidia0: <Quadro FX 1000> mem
0xe0000000-0xe7ffffff,0xfd000000-0xfdffffff irq 16 at device 0.0 on pci1
pcib2: <ACPI PCI-PCI bridge> at device 6.0 on pci0
pci2: <ACPI PCI bus> on pcib2
ohci0: <OHCI (generic) USB controller> mem 0xfe6fd000-0xfe6fdfff irq 19
at device 0.0 on pci2
usb0: OHCI version 1.0, legacy support
usb0: SMM does not respond, resetting
usb0: <OHCI (generic) USB controller> on ohci0
usb0: USB revision 1.0
uhub0: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 3 ports with 3 removable, self powered
ohci1: <OHCI (generic) USB controller> mem 0xfe6fe000-0xfe6fefff irq 19
at device 0.1 on pci2
usb1: OHCI version 1.0, legacy support
usb1: SMM does not respond, resetting
usb1: <OHCI (generic) USB controller> on ohci1
usb1: USB revision 1.0
uhub1: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 3 ports with 3 removable, self powered
ahc0: <Adaptec 2940 Ultra SCSI adapter> port 0x9800-0x98ff mem
0xfe6ff000-0xfe6fffff irq 16 at device 4.0 on pci2
aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs
fwohci0: <Texas Instruments TSB43AB22/A> mem
0xfe6f8000-0xfe6fbfff,0xfe6fc800-0xfe6fcfff irq 18 at device 6.0 on pci2
fwohci0: OHCI version 1.10 (ROM=1)
fwohci0: No. of Isochronous channels is 4.
fwohci0: EUI64 00:00:00:00:00:00:f0:12
fwohci0: Phy 1394a available S400, 2 ports.
fwohci0: Link S400, max_rec 2048 bytes.
firewire0: <IEEE1394(FireWire) bus> on fwohci0
sbp0: <SBP-2/SCSI over FireWire> on firewire0
fwe0: <Ethernet over FireWire> on firewire0
if_fwe0: Fake Ethernet address: 02:00:00:00:f0:12
fwe0: Ethernet address: 02:00:00:00:f0:12
fwe0: if_start running deferred for Giant
fwohci0: Initiate bus reset
fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode
firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me)
firewire0: bus manager 0 (me)
ohci2: <NEC uPD 9210 USB controller> mem 0xfe6f6000-0xfe6f6fff irq 19 at
device 7.0 on pci2
usb2: OHCI version 1.0
usb2: <NEC uPD 9210 USB controller> on ohci2
usb2: USB revision 1.0
uhub2: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub2: 3 ports with 3 removable, self powered
ohci3: <NEC uPD 9210 USB controller> mem 0xfe6f7000-0xfe6f7fff irq 16 at
device 7.1 on pci2
usb3: OHCI version 1.0
usb3: <NEC uPD 9210 USB controller> on ohci3
usb3: USB revision 1.0
uhub3: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub3: 2 ports with 2 removable, self powered
pci2: <serial bus, USB> at device 7.2 (no driver attached)
isab0: <PCI-ISA bridge> at device 7.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <AMD 8111 UDMA133 controller> port
0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0
ata0: channel #0 on atapci0
ata1: channel #1 on atapci0
pci0: <serial bus, SMBus> at device 7.2 (no driver attached)
pci0: <bridge> at device 7.3 (no driver attached)
pcm0: <AMD-8111> port 0xcc00-0xcc3f,0xc800-0xc8ff irq 17 at device 7.5
on pci0
pcm0: <Avance Logic ALC655 AC97 Codec>
pcib3: <ACPI PCI-PCI bridge> at device 10.0 on pci0
pci3: <ACPI PCI bus> on pcib3
skc0: <Marvell Gigabit Ethernet> port 0xa800-0xa8ff mem
0xfe8fc000-0xfe8fffff irq 27 at device 3.0 on pci3
skc0: Marvell Yukon Lite Gigabit Ethernet rev. A3(0x7)
sk0: <Marvell Semiconductor, Inc. Yukon> on skc0
sk0: Ethernet address: 00:00:00:04:a8:97
miibus0: <MII bus> on sk0
e1000phy0: <Marvell 88E1000 Gigabit PHY> on miibus0
e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,
1000baseTX-FDX, auto
atapci1: <SiI 3114 SATA150 controller> port
0xa000-0xa00f,0xa080-0xa083,0xa400-0xa407,0xa480-0xa483,0xac00-0xac07
mem 0xfe8fbc00-0xfe8fbfff irq 25 at device 5.0 on pci3
ata2: channel #0 on atapci1
ata3: channel #1 on atapci1
ata4: channel #2 on atapci1
ata5: channel #3 on atapci1
pci0: <base peripheral, interrupt controller> at device 10.1 (no driver
attached)
pcib4: <ACPI PCI-PCI bridge> at device 11.0 on pci0
pci4: <ACPI PCI bus> on pcib4
ciss0: <HP Smart Array 642> port 0xb800-0xb8ff mem
0xfea80000-0xfeabffff,0xfeafe000-0xfeafffff irq 29 at device 1.0 on pci4
pci0: <base peripheral, interrupt controller> at device 11.1 (no driver
attached)
acpi_button0: <Power Button> on acpi0
atkbdc0: <Keyboard controller (i8042)> port 0x64,0x60 irq 1 on acpi0
atkbd0: <AT Keyboard> flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: model Generic PS/2 mouse, device ID 0
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on
acpi0
sio0: type 16550A
sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
fdc0: <floppy drive controller (FDE)> port 0x3f7,0x3f0-0x3f5 irq 6 drq 2
on acpi0
isa_dmainit(2, 40960) failed
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
orm0: <ISA Option ROMs> at iomem
0xdb000-0xdefff,0xd6800-0xdafff,0xce800-0xd67ff,0xc0000-0xce7ff on isa0
ppc0: cannot reserve I/O port range
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on
isa0
Timecounter "TSC" frequency 2004556009 Hz quality 800
Timecounters tick every 1.000 msec
acd0: DVDR <MATSHITADVD-RAM SW-9585/B100> at ata1-master PIO4
Waiting 8 seconds for SCSI devices to settle
Interrupt storm detected on "irq17: pcm0"; throttling interrupt source
da0 at ciss0 bus 0 target 0 lun 0
da0: <COMPAQ RAID 0 VOLUME OK> Fixed Direct Access SCSI-0 device
da0: 135.168MB/s transfers
da0: 69419MB (142171680 512 byte sectors: 255H 32S/T 17423C)
cd0 at ahc0 bus 0 target 2 lun 0
cd0: <YAMAHA CRW4416S 1.0g> Removable CD-ROM SCSI-2 device
cd0: 8.333MB/s transfers (8.333MHz, offset 15)
cd0: Attempt to query device size failed: NOT READY, Medium not present
- tray closed
cd1 at ahc0 bus 0 target 5 lun 0
cd1: <NEC CD-ROM DRIVE:465 1.13> Removable CD-ROM SCSI-2 device
cd1: 20.000MB/s transfers (20.000MHz, offset 15)
cd1: Attempt to query device size failed: NOT READY, Medium not present
Mounting root from ufs:/dev/da0s1a
WARNING: /var was not properly dismounted
------------------------------
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to
"freebsd-stable-unsubscribe@freebsd.org"
End of freebsd-stable Digest, Vol 105, Issue 28
***********************************************
--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.9.7 - Release Date: 4/12/2005
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 266.11.16 - Release Date: 5/24/2005