Date: Tue, 24 May 2005 22:42:00 -0400 From: "Matt Smith" <ratman6@charter.net> To: <freebsd-stable@freebsd.org> Subject: RE: SSHD timeout Message-ID: <000001c560d3$545e4f80$0401a8c0@laptop> In-Reply-To: <20050413031512.6184B16A51E@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I have a friend that has 5.4 where SSHD keeps timing out before authentification. Box has a hardwired 3com NIC. We=92ve 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=3D"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=3D"us-ascii"; format=3Dflowed 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=20 >>>doesn't want to work with it, I get the following on boot: >>> >>>ichsmb0: <Intel 6300ESB (ICH) SMBus controller> port 0x8c0-0x8df irq 17=20 >>>at device 31.3 on pci0 >>>device_attach: ichsmb0 attach returned 6 >> >>Does it work if you add >> >>debug.acpi.disabled=3D"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?=20 >In which case, if ACPI does attach to it, does that mean I'd get=20 >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=20 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=20 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=3D"sysresource" Also, for xmbmon, it doesnt seem to need the smb device compiled into the=20 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=20 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.=3D 255.0, 240.0, 61.0; Rot.=3D 11250, 1350000, 675000 Vcore =3D 2.08, 3.20; Volt. =3D 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=20 >anyway. Is this because the SMBus has no temperature sensors tied to it?=20 >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=3DISO-8859-1 On Apr 12, 2005 6:28 PM, Jan Sebosik <sebosik@demax.sk> wrote: > Hi >=20 > 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) ? >=20 > 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" >=20 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=3Dus-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 --=20 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=3D"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=20 > responsible > for the problem? > so when this largest process is your production database server for=20 your e-commerce site, what will you change your recommendation to be? basically, there is no "right" choice of process to kill. a machine=20 that is out of resources is just a bad situation, and the right thing=20 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=20 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=20 > > responsible > > for the problem? > > >=20 > so when this largest process is your production database server for=20 > your e-commerce site, what will you change your recommendation to be? >=20 > basically, there is no "right" choice of process to kill. a machine=20 > that is out of resources is just a bad situation, and the right thing=20 > 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=3D"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. >=20 > 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=3D"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=3D"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=20 > RAM server=20 > > running 5.4-STABLE that keeps freezing up. We have=20 > replaced RAM, HD,=20 > > SCSI controller, etc. To no avail. We are running SMP GENERIC=20 > > Kernel. I cannot get the system to panic, leave a core=20 > dump, etc. It=20 > > just always freezes. The server functions as a web server in a=20 > > HSphere Cluster. I am about out of options besides loading 4.11=20 > > (since our 4 series servers never die). Any help, feedback, clues,=20 > > similar experiences, etc would be greatly appreciated. > >=20 > > On SCSI: The onboard Adaptec 7902 gives a dump on bootup=20 > but appears=20 > > to work. I read the archived post about this issue. The=20 > system still=20 > > locked up with an Adaptec 7982B that did not give this message. >=20 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=3D"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. >=20 > The attached program (ich-periodic-smm-disable.c) will fix the problem. > For more information on what it does, see the Intel ICH3 datasheet. >=20 > compile as 'gcc ich-periodic-smm-disable.c; ./a.out' and you will be > good. > Run this on each boot. >=20 > 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=20 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. >=20 > 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=3DUS-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 =3D 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=3D324, type=3D0xc030d780, flags=3D9) > at /usr/src/sys/kern/kern_malloc.c:243 > 243 va =3D kbp->kb_next; > (kgdb) print *kbp > $1 =3D {kb_next =3D 0x20202020 <Address 0x20202020 out of bounds>, > kb_last =3D 0xcc8fa000 "", kb_calls =3D 5704, kb_total =3D 448, kb_elmpercl =3D 8, > kb_totalfree =3D 13, kb_highwat =3D 40, kb_couldfree =3D 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 :) --=20 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=3DUS-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. --=20 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=3Dus-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. --=20 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=3D"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=20 to 1 to see what will happen this week.=20 --=20 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=20 > > Klein's configuration, it's impactful, thanks to Klein.=20 > >=20 > > 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. > >=20 >=20 > I think the real change was usin linuxthreads for SMP honestly. > The BUILD_STATIC & BUILD_OPTIMIZED only increase speed by not setting=20 > shared libs and enables assembly AFAIK. >=20 > --=20 > 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=3Dus-ascii; format=3Dflowed Edwin Groothuis wrote: > The Adaptec 1210 is a serial ATA RAID0/1 controller. >=20 > When the two disks are configured as RAID1, FreeBSD still sees two > harddisks instead of one. >=20 > This is with 5.3. Scary :-) > Will try this weekend with 5.4 >=20 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=3D"us-ascii" On Mon, Apr 11, 2005 at 10:14:14PM -0400, Tim Howe wrote: > Brooks Davis <brooks@one-eyed-alien.net> writes: >=20 > > 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. >=20 > 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: >=20 > [1042] ~ # true > /dev/da0 =20 > [1043] ~ # camcontrol rescan 0 =20 > Re-scan of bus 0 was successful > [1044] ~ # ls -l /dev/da0* =20 > 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=20 > [1046] ~ # umount /mnt/cf=20 > [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=3DUS-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. >=20 > I have not used it, but it claims to support FreeBSD as the host: >=20 > http://www.serenityvirtual.com/ >=20 > 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. --=20 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=3Dus-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. --=20 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=3D"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 > >=20 > > 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) ? > >=20 > > 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" > >=20 > 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. >=20 > 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 --=20 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=20 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=3Dus-ascii; format=3Dflowed David Sze wrote: > At 11:31 PM 10/04/2005 -0600, Scott Long wrote this to All: >=20 >> 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? >=20 >=20 > I had a chance to test 5.4-RC1 (i386) today with GENERIC, SMP, PAE, and=20 > SMP-PAE kernels (the last one is just PAE with "options SMP"). >=20 > To recap, the hardware is an IBM xSeries 346, Dual Xeon 3GHz=20 > (non-E64MT), ServeRAID-7K. >=20 > GENERIC and SMP survived "make buildkernel", but PAE and SMP-PAE paniced=20 > 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. >=20 >=20 Darnit, hard to say if this is an existing bug in 5.4 or if it's a=20 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=3D"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=20 to em (intel) on a PCI card, and have had 100% stable for the last 6=20 days. Normally every night during heavy network backup and database=20 reporting the bge ports would either be reset after watchdog timeout,=20 or the whole system would freeze with nothing logged to console,=20 screen, or BIOS... so going 6 days without any events leads me to point=20 a big hairy finger at bge driver. Even with mpsafenet=3D0, 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=20 disable the onboard bge in your BIOS. I'm on a dual opteron Tyan S2881 motherboard, for what that's worth. =20 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=3Dus-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 >=20 > 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 --=20 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=3Dus-ascii; format=3Dflowed Edwin Groothuis wrote: > On Tue, Apr 12, 2005 at 10:21:27AM -0600, Scott Long wrote: >=20 >>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 >=20 >=20 > Euhm. Oh. Software RAID? A la WinModems? More or less. It's quite common these days, with lots of motherboard=20 makers getting into the game and licensing software raid stacks for their onboard SATA controllers. >=20 > 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=3DISO-8859-1; format=3Dflowed 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 >=20 > Euhm. Oh. Software RAID? A la WinModems? >=20 > 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=20 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=3Dus-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. >=20 > 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=20 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=3Dovercommit&rnum=3D14#4c590978f1001507>= <http://groups-beta.google.com/group/comp.unix.aix/browse_frm/thread/38c 9bb9996d30eb1/e8c30f78c44a3f62?q=3Dovercommit&rnum=3D12#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=3DISO-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=20 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=3Dovercommit&rnum=3D14#4c590978f1001507> > ><http://groups-beta.google.com/group/comp.unix.aix/browse_frm/thread/38 c9bb999 >6d30eb1/e8c30f78c44a3f62?q=3Dovercommit&rnum=3D12#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=3Dus-ascii dear all, I would like to buy SCSI card which must:=20 - support Ultra 320 - support RAID 0,1,5, and 1/0 any recommendation for FreeBSD-5.x ? thanks ! -dikshie- =20 ------------------------------ 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=3D"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 =3D "AuthenticAMD" Id =3D 0xf5a Stepping =3D 10 =20 Features=3D0x78bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE= , MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2> AMD Features=3D0xe0500800<SYSCALL,NX,MMX+,LM,3DNow+,3DNow> real memory =3D 2147418112 (2047 MB) avail memory =3D 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=3D7, 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=3D1) 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=3D0xc800ffc0, gen=3D1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <=3D 0, cable IRM =3D 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=3D0x300> 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=20 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=20 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=20 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 *********************************************** --=20 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 =20 --=20 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 =20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000001c560d3$545e4f80$0401a8c0>