Re: alpm(4) I/O range is claimed by ACPI
On Thu, Sep 11, 2008 at 03:14:46PM +0100, Bruce M Simpson wrote: > Jeremy Chadwick wrote: >> ... >> Might mention this to jhb@ to see if it's related to the SMBus changes >> made 1.5 years ago: >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/alpm.c >> > > Thanks for the pointers. The other reports sound like duplicate reports > of the same issue. > > I'm not sure that backing out the last change is going to help. The BIOS > has generally set up the I/O resource before FreeBSD boots; the > bus_set_resource() call might only be useful in those cases where that > hasn't happened. > In any event, in alpm_attach(), the rman is going to notice that the bus > space is already allocated by acpi(4), and will balk. > > I'm sure there has been some kind of override mechanism in place for > certain other drivers; but they seem to boil down to using an ACPI > attachment of some kind, which won't work here as alpm(4) is a PCI > function and needs to attach to the pcib parent. > > It would be really, really useful to have working SMBus drivers right > now on a machine I can actually touch... Interesting timing -- Toshikazu Kaho just reported the same issue with alpm(4) today: http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/044989.html I've CC'd him, as he's probably unaware of this already-existing thread. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel ICH7 SMBus support, ichsmb(4)
On Thu, Sep 11, 2008 at 10:40:24AM -0400, Michael Butler wrote: > Bruce M. Simpson wrote: > > Miroslav Lachman wrote: > >> Jeremy Chadwick wrote: > >> > >>> I suppose a lot of these could be addressed if I released the code in a > >>> preliminary fashion (providing folks the ability to help me with > >>> documentation, etc.). Hmm... Yeah, I should really get a beta tarball > >>> up, and/or make a FreeBSD port for it already (since I am a ports > >>> committer). > > > > My suggestion would be to make the code available using a Mercurial > > repository. People are then free to participate and send diffs as they > > see fit, and they can do so very easily. The learning curve for the > > tool is reasonable. > > > > I'd also recommend http://freehg.org/ if you need some hosting for a > > public repo. > What would prevent this being accepted as a loadable module built (by > user request) out of the ports tree in much the same manner as kqemu et al.? > > Michael I'm confused by this question and its relevancy to what Bruce said. :-) Can you explain? -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Long delays for USB realbtx boot
Bruce M Simpson wrote: > > Eugene Grosbein wrote: > > For me, it helps to include these knobs to Nano config file: > > > > CONF_WORLD=' > > BOOT_MBR_FLAGS=0x0 > > BOOT_BOOT1_FLAGS=0x0 > > ... > > ' > > > > I added this to the CONF_WORLD in my config file. Unfortunately this > seems to break USB boot completely for me. Sorry, I missed that you are using USB flash. I use IDE flash only. Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7.1 Content
Under linux: install pci-tools or something, then "lspci". Adrian 2008/9/4 Dan Allen <[EMAIL PROTECTED]>: > > On 3 Sep 2008, at 1:58 PM, Wesley Shields wrote: > >> I installed the June snapshot of -current on my laptop and it supports >> my Intel 4965 just fine. Support for this card is out there and does >> work, just not in RELENG_7. > > On 3 Sep 2008, at 2:45 PM, Gavin Atkinson wrote: > >> There is support for the Intel 4965 in HEAD, with the iwn(4) driver. > > Thanks guys for the info. > > Not having ANY wired or wireless support in FreeBSD for a very decent Dell > laptop that is flying off of the shelves at $500, I deleted FreeBSD from the > machine and installed Ubuntu 8.04. I therefore cannot run "pciconf -l" at > this moment in time, but I may get back around to it. > > Stay tuned... maybe for 7.2. > > Dan > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: alpm(4) I/O range is claimed by ACPI
Hello. I have same error message on Sharp PC-CV50.
Is it a hardware or BIOS problem ?
The device dosen't have PCIM_CMD_PORTEN bit on PCIR_COMMAND
(address 0x04, bit 0), and dosen't have any valid address on PCIR_BAR(x).
pciconf can't write PCIR_BAR(x).
`pciconf -lv` shows:
[EMAIL PROTECTED]:3:1: class=0x068000 card=0x104313bd chip=0x710110b9 rev=0x00
hdr=0x00
vendor = 'Acer Labs Incorporated (ALi/ULi)'
device = 'ALI M7101 Power Management Controller'
class = bridge
and `pciconf -r pci0:3:1 0:0x1f` shows:
710110b9 0200 0680 0080
--
KAHO Toshikazu
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Long delays for USB realbtx boot
Woops, I noticed right after I sent this message, that there was an I/O error writing to the USB key from dd in my shell -- I think I was using a 32768 block size instead of 16384 which might account for the problem. I'll be sure to try this all again after I've had some sleep. cheers BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Long delays for USB realbtx boot
Eugene Grosbein wrote: For me, it helps to include these knobs to Nano config file: CONF_WORLD=' BOOT_MBR_FLAGS=0x0 BOOT_BOOT1_FLAGS=0x0 ... ' I added this to the CONF_WORLD in my config file. Unfortunately this seems to break USB boot completely for me. When I attempt to boot the USB flash device on the AH-1, the 1 minute delay still exists. The messages "No /boot/loader" and "No /boot/kernel/kernel" are printed, and the image does not boot -- it sits at the "FreeBSD/i386 boot" prompt. It does however see the files at the top of the root filesystem, it just refuses to boot further. The device has less than 1023 cylinders, so the restrictions which would make EDD/packet mode necessary should not apply, and I would have thought that your workaround would work. I am using "USB-HDD" style geometry at the moment (255/63/cc), not "USB-ZIP" (64/32/cc). Would that make a difference? What's interesting is that "camcontrol modepage da0 -m 0x05" returns a different geometry from that reported by the BIOS: %%% Transfer rate: 61440 Number of heads: 16 Sectors per track: 32 Data bytes per sector: 512 Number of cylinders: 3816 Starting cylinder-write precompensation: 0 Starting cylinder-reduced write current: 0 Drive step rate: 0 Drive step pulse width: 0 Head settle delay: 0 Motor on delay: 0 Motor off delay: 0 TRDY: 0 SSN: 0 MO: 0 SPC: 0 Write Compensation: 0 Head load delay: 0 Head unload delay: 0 Pin 34: 0 Pin 2: 0 Pin 4: 0 Pin 1: 0 Medium rotation rate: 0 %%% cheers BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Audio CD problem on laptop VGN-SZ61MN
On Sun, Aug 10, 2008 at 08:54:17AM +0200, Harald Weis wrote: > On Sat, Aug 09, 2008 at 11:56:23AM -0300, Carlos A. M. dos Santos wrote: > > > 1. Try to insert the CD and wait until it stops pinning before > > starting mplayer. Some drives are a bit lazy on media recognition. Doesn't make a difference. > > 2. Run "truss mplayer ..." and look for error messages. The output file does not mention the "Invalid argument" message or, as far as I can understand, any other fatal stuff. > > 3. Attempt to use a different player. Xine and/or one of its alternate > > front-ends like GXine or Kaffeine are good choices. > > I'll be away from keyboard for two weeks or so. > I shall reply then as soon as possible. Xine: ``xine cdda://dev/acd0/n'' works fine despite of six lines ``Cannot find address for OpenGl extension function ... which should be available according to extension specs.''. But the GUI does not work properly. For example, the CD button generates ``CDIOCREADAUDIO: Invalid argument'' messages. No wonder that gxine and kaffeine which use the xine engine don't work either. Finally, the only (audioCD) command which does work on this laptop is ``vlc cdda:///dev/[EMAIL PROTECTED]''. Disappointing, but better than nothing. Thank you again for your comments. Harald ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: installkernel and nvram.ko on RELENG_6 broken?
I have removed /usr/obj and am going through the whole buildworld/ buildkernel/installkernel process again. There were a bunch of stale files under /usr/obj/usr/src/sys/i386/compile that may be the issue. Dan On Sep 11, 2008, at 2:55 PM, Dan Mack wrote: I have a custom kernel without nvram defined anywhere, however, make installkernel still attempts to install the module. About 45 days ago, I didn't have this issue. I didn't see anything about this in UPDATING so I thought I would check here. This system is currently running stable from 45 days ago built from source. I cvsuped 4 hours ago. # make installkernel KERNCONF=SMP-COCO ===> nullfs (install) install -o root -g wheel -m 555 nullfs.ko /boot/kernel ===> nve (install) install -o root -g wheel -m 555 if_nve.ko /boot/kernel ===> nvram (install) install -o root -g wheel -m 555 nvram.ko /boot/kernel install: nvram.ko: No such file or directory *** Error code 71 Stop in /usr/src/sys/modules/nvram. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/SMP-COCO. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED] " ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
installkernel and nvram.ko on RELENG_6 broken?
I have a custom kernel without nvram defined anywhere, however, make installkernel still attempts to install the module. About 45 days ago, I didn't have this issue. I didn't see anything about this in UPDATING so I thought I would check here. This system is currently running stable from 45 days ago built from source. I cvsuped 4 hours ago. # make installkernel KERNCONF=SMP-COCO ===> nullfs (install) install -o root -g wheel -m 555 nullfs.ko /boot/kernel ===> nve (install) install -o root -g wheel -m 555 if_nve.ko /boot/kernel ===> nvram (install) install -o root -g wheel -m 555 nvram.ko /boot/kernel install: nvram.ko: No such file or directory *** Error code 71 Stop in /usr/src/sys/modules/nvram. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/SMP-COCO. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: alpm(4) I/O range is claimed by ACPI
On Thursday 11 September 2008 10:14:46 am Bruce M Simpson wrote: > Jeremy Chadwick wrote: > > ... > > Might mention this to jhb@ to see if it's related to the SMBus changes > > made 1.5 years ago: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/alpm.c > > > > Thanks for the pointers. The other reports sound like duplicate reports > of the same issue. > > I'm not sure that backing out the last change is going to help. The BIOS > has generally set up the I/O resource before FreeBSD boots; the > bus_set_resource() call might only be useful in those cases where that > hasn't happened. > In any event, in alpm_attach(), the rman is going to notice that the bus > space is already allocated by acpi(4), and will balk. > > I'm sure there has been some kind of override mechanism in place for > certain other drivers; but they seem to boil down to using an ACPI > attachment of some kind, which won't work here as alpm(4) is a PCI > function and needs to attach to the pcib parent. > > It would be really, really useful to have working SMBus drivers right > now on a machine I can actually touch... Umm, ACPI will allow children devices to allocate their resources out of the "sysresource" pool. IPMI has to do this on some systems where ACPI claims the IPMI I/O ports as a system resource. That's what this chunk of code in acpi_alloc_resource() does: /* * If this is an allocation of a specific range, see if we can satisfy * the request from our system resource regions. If we can't, pass the * request up to the parent. */ if (start + count - 1 == end && rm != NULL) res = rman_reserve_resource(rm, start, end, count, flags & ~RF_ACTIVE, child); I'm not sure why you are having issues with SMBus. I know I've been able to use IPMI over SSIF (IPMI over SMBus) using ichsmb0 on some Intel boxes that were new about 2 years ago. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Long delays for USB realbtx boot
On Thu, 11 Sep 2008 16:49:56 BST, Bruce M Simpson wrote: > Interesting, that's classic USB-HDD geometry (255H, 63S). Can you > tell me what make, model of stick this is? It's Kingston DTI/512 # diskinfo -v da0 da0 512 # sectorsize 512753664 # mediasize in bytes (489M) 1001472 # mediasize in sectors 489 # Cylinders according to firmware. 64 # Heads according to firmware. 32 # Sectors according to firmware. # camcontrol inquiry da0 pass1: Removable Direct Access SCSI-2 device pass1: Serial Number 40.000MB/s transfers cheers, doug ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Long delays for USB realbtx boot
On Thu, Sep 11, 2008 at 01:55:01PM +0100, Bruce M Simpson wrote: > I have hacked NanoBSD locally to deal with generation of images for > booting off USB keys. I am using the RELENG_7 branch as real-mode BTX > support is necessary to support USB boot. > > During testing I noticed that whilst the images eventually boot, there > is an extremely long delay before doing so, between when the BIOS reads > the boot sector and when the BTX loader messages appear. > > Test system Time > > Thinkpad T43 1m 40s > ASUS Vintage AH-1 1m 7s > > Any ideas why this long delay is occuring? For me, it helps to include these knobs to Nano config file: CONF_WORLD=' BOOT_MBR_FLAGS=0x0 BOOT_BOOT1_FLAGS=0x0 ... ' Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Long delays for USB realbtx boot
[Ccing to list to track up thread] Douglas Berry wrote: Perhaps this doesn't help... I do RELENG_7 based images for USB keys/CDROM using the FreesBIE toolkit, and haven't noticed such delays. I do fill the stick 'tho. Here's fdisk output... *** Working on device /dev/md4 *** parameters extracted from in-core disklabel are: cylinders=62 heads=255 sectors/track=63 (16065 blks/cyl) Interesting, that's classic USB-HDD geometry (255H, 63S). Can you tell me what make, model of stick this is? It could be that the cylinder change is what's confusing the BIOS. I will need to do some tweak to make sure the cylinder calculation is right for the stick's capacity. The A/Open MX3S has no USB-HDD mode. It appears to have the same delay issue, however, it didn't see any difference between the USB-HDD geometry image and the USB-ZIP geometry image. %%% empiric:~/shelf/chipdocs/aopen % camcontrol inquiry da0 pass1: Removable Direct Access SCSI-0 device pass1: Serial Number 40.000MB/s transfers empiric:~/shelf/chipdocs/aopen % camcontrol readcap da0 Last Block: 1953791, Block Length: 512 bytes %%% That device uses USB-ZIP style geometry (64H, 32S), and based on the "last block", 1953792 / 2048 is 954 cylinders exactly, which is how it came factory formatted. So I should probably give it a shot based on this. To get something up and running I've been using generic methods in the NanoBSD patch, I haven't sized the MBR geometry specifically to the device. By my reckoning your stick is just under 512MiB, based on the geometry you provided: parameters to be used for BIOS calculations are: cylinders=62 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 32, size 1001440 (488 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 488/ head 63/ sector 32 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: cheers BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Long delays for USB realbtx boot
Bruce M. Simpson wrote: Bruce M Simpson wrote: ... During testing I noticed that whilst the images eventually boot, there is an extremely long delay before doing so, between when the BIOS reads the boot sector and when the BTX loader messages appear. I can reproduce the boot delay condition on a crusty old A/Open MX3S based, socket 370 Celeron that I keep around for testing stuff like this. [...in another thread, it's documented to have working SMBus-based mbmon support... but I don't have any boot media for it. grrr.] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Any working ichsmb(4) platforms out there?
Richard Tector wrote: > Bruce M Simpson wrote: >> Richard, >> >> Thanks for this. >> >> Richard Tector wrote: >>> >>> I have an ICH9 machine, Tyan motherboard: >>> FreeBSD 7.0-STABLE #0: Fri Aug 1 14:57:33 BST 2008 >>> ichsmb0: port 0x18e0-0x18ff mem >>> 0xf4a03000-0xf4a030ff irq 17 at device 31.3 on pci0 >>> ichsmb0: [GIANT-LOCKED] >>> ichsmb0: [ITHREAD] >>> >>> daffy# smbmsg -p >>> Probing for devices on /dev/smb0: >>> Device @0x2e: rw >> ... >> So it looks like yours works! I see no differences to RELENG_7_0. >> >> Are you using any hardware monitoring devices? >> Can you give bsdhwmon a shot? >> >> cheers >> BMS > > Sure. If yourself or Jeremy could send over the tarball? > I don't use any hardware monitoring on it currently. I'd also appreciate the opportunity to try it .. old hardware but .. [EMAIL PROTECTED]:/home/imb> devinfo -v | grep smb intsmb0 pnpinfo vendor=0x8086 device=0x7113 subvendor=0x subdevice=0x class=0x068000 at slot=7 function=3 handle=\_SB_.PCI0.PMU_ smbus0 smb0 [EMAIL PROTECTED]:/home/imb> kenv | grep smbios smbios.bios.reldate="07/20/2001" smbios.bios.vendor="Intel Corp." smbios.bios.version="TR440BXA.86B.0042.P15.0107200951" smbios.chassis.maker="Dell Computer Corp." smbios.chassis.serial="YC571 " smbios.chassis.tag=" " smbios.chassis.version="SPAW70W PA[CA] " smbios.planar.maker="Intel Corporation " smbios.planar.product="TR440BXA " smbios.planar.serial="IMTR02702003 " smbios.planar.version="A16643-305 " smbios.socket.enabled="1" smbios.socket.populated="1" smbios.system.maker="Dell Computer Corp." smbios.system.product="PowerApp.web 100 W " smbios.system.serial="YC571 " smbios.system.uuid="44454c4c-00ca-1059-8043-80c04f353731" smbios.system.version="SPAW70W" [EMAIL PROTECTED]:/home/imb> sudo smbmsg -p Probing for devices on /dev/smb0: Device @0x5a: rw Device @0x60: rw Device @0x62: rw Device @0x64: rw Device @0x66: rw Device @0xa0: rw Device @0xa2: rw Device @0xa4: rw Device @0xa6: rw [EMAIL PROTECTED]:/home/imb> sudo mbmon -d Using SMBus-ioctl access method[IntelPIIX4(440BX/MX)]!! * Analog Dev. Chip ADM9240 found. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Any working ichsmb(4) platforms out there?
Richard Tector wrote: Interestingly, I just tried on a couple of our webservers. Dell PowerEdge 860's with ICH7 running 7.0-STABLE, amd64. Loading the ichsmb module gives: ichsmb0: port 0x8c0-0x8df at device 31.3 on pci0 pcib0: no PRT entry for 0.31.INTB ichsmb0: can't get IRQ device_attach: ichsmb0 attach returned 6 I found one another ICH7 machine. 6.3-STABLE, i386. It exhibits the same problems you were having. An unkillable smbmsg, and several ichsmb0: device timeout, status=0x41 Regards, Richard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Any working ichsmb(4) platforms out there?
Bruce M Simpson wrote: Richard, Thanks for this. Richard Tector wrote: I have an ICH9 machine, Tyan motherboard: FreeBSD 7.0-STABLE #0: Fri Aug 1 14:57:33 BST 2008 ichsmb0: port 0x18e0-0x18ff mem 0xf4a03000-0xf4a030ff irq 17 at device 31.3 on pci0 ichsmb0: [GIANT-LOCKED] ichsmb0: [ITHREAD] daffy# smbmsg -p Probing for devices on /dev/smb0: Device @0x2e: rw ... So it looks like yours works! I see no differences to RELENG_7_0. Are you using any hardware monitoring devices? Can you give bsdhwmon a shot? cheers BMS Sure. If yourself or Jeremy could send over the tarball? I don't use any hardware monitoring on it currently. Interestingly, I just tried on a couple of our webservers. Dell PowerEdge 860's with ICH7 running 7.0-STABLE, amd64. Loading the ichsmb module gives: ichsmb0: port 0x8c0-0x8df at device 31.3 on pci0 pcib0: no PRT entry for 0.31.INTB ichsmb0: can't get IRQ device_attach: ichsmb0 attach returned 6 Richard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
viapm(4) does not see VT8237A on Gigabyte GA-VM900M
Bruce M Simpson wrote: Does anyone have ichsmb(4) actually seeing SMBus devices? e.g. you run "smbmsg -p" on your FreeBSD-STABLE system and see something. I just tried to port over some of the hardware IDs from OpenBSD 4.3's viapm(4) driver to the driver in 6.3-RELEASE, as I really need to see what working SMBus support looks like in a FreeBSD system. Unfortunately the driver wouldn't attach. It looks like isab already claims the ISA bridge. Is there any trick I can use to get viapm to attach to the ISA bridge controller, without breaking the ISA bus bridge attachment? I am using a Gigabyte GA-VM900M board. thanks, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Any working ichsmb(4) platforms out there?
Richard, Thanks for this. Richard Tector wrote: I have an ICH9 machine, Tyan motherboard: FreeBSD 7.0-STABLE #0: Fri Aug 1 14:57:33 BST 2008 ichsmb0: port 0x18e0-0x18ff mem 0xf4a03000-0xf4a030ff irq 17 at device 31.3 on pci0 ichsmb0: [GIANT-LOCKED] ichsmb0: [ITHREAD] daffy# smbmsg -p Probing for devices on /dev/smb0: Device @0x2e: rw ... So it looks like yours works! I see no differences to RELENG_7_0. Are you using any hardware monitoring devices? Can you give bsdhwmon a shot? cheers BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Any working ichsmb(4) platforms out there?
Bruce M Simpson wrote: Does anyone have ichsmb(4) actually seeing SMBus devices? e.g. you run "smbmsg -p" on your FreeBSD-STABLE system and see something. I just tried it again on my IBM ThinkPad T43 and saw nothing, all I get is: ichsmb0: device timeout, status=0x41 ...in dmesg. I have an ICH9 machine, Tyan motherboard: FreeBSD 7.0-STABLE #0: Fri Aug 1 14:57:33 BST 2008 ichsmb0: port 0x18e0-0x18ff mem 0xf4a03000-0xf4a030ff irq 17 at device 31.3 on pci0 ichsmb0: [GIANT-LOCKED] ichsmb0: [ITHREAD] daffy# smbmsg -p Probing for devices on /dev/smb0: Device @0x2e: rw Device @0x44: rw Device @0x60: rw Device @0x88: w Device @0xae: rw Device @0xc4: rw Device @0xe0: rw daffy# Any use? Richard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel ICH7 SMBus support, ichsmb(4)
Bruce M. Simpson wrote: > Miroslav Lachman wrote: >> Jeremy Chadwick wrote: >> >>> I suppose a lot of these could be addressed if I released the code in a >>> preliminary fashion (providing folks the ability to help me with >>> documentation, etc.). Hmm... Yeah, I should really get a beta tarball >>> up, and/or make a FreeBSD port for it already (since I am a ports >>> committer). > > My suggestion would be to make the code available using a Mercurial > repository. People are then free to participate and send diffs as they > see fit, and they can do so very easily. The learning curve for the > tool is reasonable. > > I'd also recommend http://freehg.org/ if you need some hosting for a > public repo. What would prevent this being accepted as a loadable module built (by user request) out of the ports tree in much the same manner as kqemu et al.? Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel ICH7 SMBus support, ichsmb(4)
Miroslav Lachman wrote: Jeremy Chadwick wrote: I suppose a lot of these could be addressed if I released the code in a preliminary fashion (providing folks the ability to help me with documentation, etc.). Hmm... Yeah, I should really get a beta tarball up, and/or make a FreeBSD port for it already (since I am a ports committer). My suggestion would be to make the code available using a Mercurial repository. People are then free to participate and send diffs as they see fit, and they can do so very easily. The learning curve for the tool is reasonable. I'd also recommend http://freehg.org/ if you need some hosting for a public repo. cheers BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Any working ichsmb(4) platforms out there?
Does anyone have ichsmb(4) actually seeing SMBus devices? e.g. you run "smbmsg -p" on your FreeBSD-STABLE system and see something. I just tried it again on my IBM ThinkPad T43 and saw nothing, all I get is: ichsmb0: device timeout, status=0x41 ...in dmesg. cheers BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: alpm(4) I/O range is claimed by ACPI
Jeremy Chadwick wrote: ... Might mention this to jhb@ to see if it's related to the SMBus changes made 1.5 years ago: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/alpm.c Thanks for the pointers. The other reports sound like duplicate reports of the same issue. I'm not sure that backing out the last change is going to help. The BIOS has generally set up the I/O resource before FreeBSD boots; the bus_set_resource() call might only be useful in those cases where that hasn't happened. In any event, in alpm_attach(), the rman is going to notice that the bus space is already allocated by acpi(4), and will balk. I'm sure there has been some kind of override mechanism in place for certain other drivers; but they seem to boil down to using an ACPI attachment of some kind, which won't work here as alpm(4) is a PCI function and needs to attach to the pcib parent. It would be really, really useful to have working SMBus drivers right now on a machine I can actually touch... cheers BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Long delays for USB realbtx boot
Bruce M Simpson wrote: ... During testing I noticed that whilst the images eventually boot, there is an extremely long delay before doing so, between when the BIOS reads the boot sector and when the BTX loader messages appear. P.S. It appears none of QEMU, VMware 3.0, or VirtualBox 1.6.6 are able to emulate booting from a USB key in their BIOS, and only QEMU seems to support attaching a disk image on USB, making testing this a bit of a pain (real hardware is always needed). cheers BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Long delays for USB realbtx boot
Hi, I have hacked NanoBSD locally to deal with generation of images for booting off USB keys. I am using the RELENG_7 branch as real-mode BTX support is necessary to support USB boot. During testing I noticed that whilst the images eventually boot, there is an extremely long delay before doing so, between when the BIOS reads the boot sector and when the BTX loader messages appear. Test system Time Thinkpad T43 1m 40s ASUS Vintage AH-1 1m 7s Any ideas why this long delay is occuring? I see this with MBR geometries prepared for both USB-HDD (255H/63S/xxC) and USB-ZIP (64H/32S/xxC) modes. I am not using the strict USB-ZIP mode where everything resides on the 4th slice (da0s4) at the moment, as it requires further NanoBSD patches. I am not currently generating images sized to the entire USB key to save space and time, so the cylinder size is smaller than the physical media, this might also be a factor. Thanks for any light you can shed on this. cheers, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fwd: FreeBSD 7.1 Content
Ian Smith wrote: > % man sysinstall | tail says it all. However sysinstall has enough bits > (modules, really) that don't suck to make its presence still worthy. > > The wrappers around fdisk and bsdlabel alone are worth a lot, despite a > notion that 'real men' figure out cylinder and slice offsets themselves. It's not that bad. I agree that fdisk's "user interface" is not pretty. But the most common usage is simply "fdisk -BI" to initialize a new disk to be used by FreeBSD. This is a simple, non-interactive command, so there's no reason to use sysinstall for that. And bsdlabel (formerly disklabel) is actually quite user-friendly. In the most common cases (preparing a fresh disk or slice), you don't have to calculate anything at all. When "bsdlabel -e" drops you into your favourite editor (assuming you have set $EDITOR to something you're familiar with), just enter the partition letters that you need, and their respective sizes. Note you can use "M" and "G" suffixes for MBytes and GBytes; you don't have to calculate sector counts. You can even use percent values, so entering "50%" for the size will use half of the free space on that slice (after subtracting all fixed-size partitions), and "100%" will use all the remaining space, as does "*". Just enter "*" for all the offsets, and they will automatically allocated sequentially. Again, you don't have to calculate anything, unless you really want to. The bsdlabel tool is pretty fool-proof, it checks all data and will warn you if partitons overlap or extend beyond the end of the slice, or if the "c" partition doesn't cover the whole slice. In that case it will refuse to continue, and offer to go back to the editor. Certainly there could be a "nicer" interface for all of that (I'm not saying sade(8) is useless), but I think bsdlabel does its job pretty well, and it is _not_ difficult to use, contrary to what many people seem to believe. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind." -- Alan Kay, OOPSLA '97 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel ICH7 SMBus support, ichsmb(4)
Jeremy Chadwick wrote: On Thu, Sep 11, 2008 at 11:51:52AM +0200, Miroslav Lachman wrote: Are you still actively working on bsdhwmon and do you plan to support non-Supermicro servers? Yes, I'm still actively working on it -- it is in no way shape or form a dead project. Most of the delays of releasing the software are caused by the following: * No man page or decent documentation -- this is a big show-stopper for me. I hate writing man pages (I write them by hand; I do not believe in using irritating tools to try and do the work for me), and writing one takes quite a bit of time to continually look up troff syntax and what not, * Code comments need to be added and cleaned up -- I need to document my functions better so anyone examining the source can understand it, * Badly-written Makefile with lots of hard-coded settings and options -- I need someone with better familiarity with Make to assist in cleaning this up, * Supermicro not providing me some necessary details (such as how to deal with the 5VCC/5VDD bug on some motherboards), resulting in that specific voltage being calculated wrong -- I've looked at the Linux lm-sensors project to try and get answers, but their code is absolute spaghetti and heavily abstracted, * Many testers not getting back to me with results of their tests -- I've mailed many of the ones who wanted to test, but got no response from them, indicating they lack time or lost interest in helping, * Some users requesting additional features too soon, such as: support for a configuration file, customisable output, and ISA I/O port support. I suppose a lot of these could be addressed if I released the code in a preliminary fashion (providing folks the ability to help me with documentation, etc.). Hmm... Yeah, I should really get a beta tarball up, and/or make a FreeBSD port for it already (since I am a ports committer). Also, I recently discovered that at EuroBSDCon, Constantine Murenin will be giving a talk about the OpenBSD Hardware Sensors Framework: http://2008.eurobsdcon.org/talks.html. This makes me makes me wonder if the project is being re-considered for FreeBSD (it was committed to CURRENT in October 2007 and then backed out after being referred to as a "festering junkpile that does not belong in the kernel", reference: http://lists.freebsd.org/pipermail/cvs-src/2007-October/082398.html). If it is being reconsidered, I think it would make *much* more sense for me to spend my time getting ICHx SMBus support working under that, since the framework provides an interface for me to work with. To answer your 2nd question: yes, I plan on supporting other motherboards and products. The reason that is on hold/back-burner is: * I have contacts at Supermicro who can provide me full register details and provide overall support/help when I need it. I have none of this with Sun, nVidia, IBM, nor Intel. I can assure you that if I mail the general "Technical Support" lists these companies have, the support folks will /dev/null my mails, or simply go "What is this? SMBus slave hardware chip what? What the hell is that? Whatever..." and ignore the mail because it's outside of the norm. I do not believe in "randomly probing the SMBus" to try and find things by trial and error -- the risks are huge! People don't realise that reading registers can cause interrupts or features to be reset or disabled on the chip, which could cause the entire machine (or maybe just the SMBus layer) to lock up. I can assure you none of the bsdhwmon testers will put up with those risks, as most of them are doing testing on actual production servers and are trusting my "play it safe" judgement... * I want to get a good, solid list of Supermicro servers officially supported before moving on to a mix-match of other hardware. I do have very basic support for an AMD-based H/W monitoring chip used in a Supermicro board, but there's no SMBus driver available on FreeBSD for that chipset, so bsdhwmon can't work with it. I wrote you an e-mail in June about my interest in testing thist project on my servers, but got no reply. Hmm... I've looked through my mail archives for all of 2008, and I don't see any mail from you pertaining to bsdhwmon. I do see other mails (discussing GRUB, ATA problems, etc.) but nothing about bsdhwmon. I was grepping for 'Miroslav', looking specifically in my mailbox dedicated for [EMAIL PROTECTED] Could you resend it? re-sent with subject "[Fwd: bsdhwmon [was: Re: cpufreq broken on core2duo]]" I have some Sun Fire X2100 M2 (nVidia chips), IBM x335 (Intel), IBM x336 (Intel) servers and one Supermicro X6DHP-8G (Intel) server. Thanks. I'll add these to my list of servers that I should try to focus on in the near future (since you have hardware available for testing), and mark you down as the contact I should refer to for help/testing. Thank you for your time and for informations! As I have mostly Sun Fire X2100 M2 servers, I have one as spare / testin
Re: alpm(4) I/O range is claimed by ACPI
On Thu, Sep 11, 2008 at 11:44:20AM +0100, Bruce M Simpson wrote: > How can I load the alpm(4) module for SMBus support on my ASUS Vintage > AH-1 system? > > It appears the I/O range it uses is claimed by the acpi(4) driver. Can I > override the mapping in some way i.e. tell ACPI not to claim the range? > I don't see anything obvious about this in the acpi(4) man page. Might mention this to jhb@ to see if it's related to the SMBus changes made 1.5 years ago: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/alpm.c I found this thread, which despite being USB-centric, shows someone trying to load alpm(4) on RELENG_6 and getting a map allocation error back in 2003. Not sure if this is of any help: http://lists.freebsd.org/pipermail/freebsd-mobile/2003-April/000190.html http://lists.freebsd.org/pipermail/freebsd-mobile/2003-April/000192.html -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fresh 7.0 Install: Fatal Trap 12 panic when put under load
On Thu, Sep 11, 2008 at 12:08:47PM +0200, Michael Grant wrote: > On Thu, Sep 11, 2008 at 11:20 AM, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > > On Thu, Sep 11, 2008 at 10:38:36AM +0200, Michael Grant wrote: > >> My box crashed again: > >> > >> panic: kmem_malloc(4096): kmem_map too small: 1073741824 total allocated > >> cpuid = 0 > >> Uptime: 33d11h12m58s > >> Dumping 3327 MB (2 chunks) > >> chunk 0: 1MB (151 pages) ... ok > >> chunk 1: 3327MB (851568 pages) <---hung here > >> > >> Still no valid dump. > >> > >> There is 4gig of physical memory in the machine. > >> > >> In /boot/loader.conf, I currently have the following: > >> > >> vm.kmem_size=1G > >> vm.kmem_size_max=1G > >> vm.kmem_size_scale=2 > >> > >> and in my kernel conf file I have: > >> > >> options KVA_PAGES=512 > >> > >> It stayed up for 33 days this time. Is there anything else I can do? > > > > First and foremost: are you using ZFS on this machine? If so, there are > > many tunables you can apply to try and limit this; I'm willing to bet > > it's ARC which is doing it. See below. > > > > In general, it appears that you need to increase the maximum range of > > kmem. The kernel attempted to utilise more than 1GB, and your limit is > > 1G. My machines running RELENG_7 on amd64, with only 2GB of RAM > > installed, use the following tunables in loader.conf: > > > > vm.kmem_size="1536M" > > vm.kmem_size_max="1536M" > > > > If ZFS is in use, I recommend these as well: > > > > vfs.zfs.arc_min="16M" > > vfs.zfs.arc_max="64M" > > vfs.zfs.prefetch_disable="1" > > > > Do not increase kmem_size any larger than 1.5GB; the amount of RAM you > > have in the machine, with regards to RELENG_7, will not help. This is a > > known limitation which has been fixed in HEAD/CURRENT (where the limit > > has been increased to 512GB). See the "Kernel" section below; you'll > > see the applicable item. > > > > http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues > > > > Your only solution may be to run HEAD/CURRENT. > > I am not running ZFS. My file systems are ufs. > > This feels like some sort of memory leak in the kernel. Giving it > more and more memory just seems to delay the crash. Are you saying > the crash is fixed in HEAD/CURRENT? It's an intentional crash, not "the program tried to access NULL, which crashed the machine" crash. The kernel wants more memory to accomplish a certain thing, and it's not available. kris@ can explain this in better terms than I can. First and foremost, it would be good to find out what all you are running on this machine (process-wise). A process could be tickling something in the kernel which requires a large amount of memory to be required. I can imagine something like MySQL would require this. Ideally what needs to happen is to debug the kernel or get a full map of kmem to find out what's using what. I believe vmstat -m or vmstat -z output might help. Obviously since the machine panics, you won't be able to run those commands after the fact. I would recommend you set up a cronjob that runs every 1-2 minutes and logs the output of both of those commands to a file. When the panic happens, restart the system and look at the logfile to see if you can figure out if anything suddenly starts taking up a large amount of memory, or if it's a gradual thing (indicating a memory leak). If you can figure out what might be tickling the problem, you can ultimately figure out if increasing kmem is the right thing to do, or if there's a greater problem here. > I'm running 6.3 by the way. > > I have put your changes into my loader.conf, we'll see how long it > goes this time. I'm not qute in position to update everything to 7.x > at the moment. Our production webservers run RELENG_6 and RELENG_7, and we don't encounter this kind of problem. I'm not saying what you're experiencing is indicative of hardware issues or something like that -- I'm simply saying I have loaded systems which don't ever hit that condition. So figuring out what's causing it in your case would be good. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel ICH7 SMBus support, ichsmb(4)
On Thu, Sep 11, 2008 at 11:51:52AM +0200, Miroslav Lachman wrote: > Are you still actively working on bsdhwmon and do you plan to support > non-Supermicro servers? Yes, I'm still actively working on it -- it is in no way shape or form a dead project. Most of the delays of releasing the software are caused by the following: * No man page or decent documentation -- this is a big show-stopper for me. I hate writing man pages (I write them by hand; I do not believe in using irritating tools to try and do the work for me), and writing one takes quite a bit of time to continually look up troff syntax and what not, * Code comments need to be added and cleaned up -- I need to document my functions better so anyone examining the source can understand it, * Badly-written Makefile with lots of hard-coded settings and options -- I need someone with better familiarity with Make to assist in cleaning this up, * Supermicro not providing me some necessary details (such as how to deal with the 5VCC/5VDD bug on some motherboards), resulting in that specific voltage being calculated wrong -- I've looked at the Linux lm-sensors project to try and get answers, but their code is absolute spaghetti and heavily abstracted, * Many testers not getting back to me with results of their tests -- I've mailed many of the ones who wanted to test, but got no response from them, indicating they lack time or lost interest in helping, * Some users requesting additional features too soon, such as: support for a configuration file, customisable output, and ISA I/O port support. I suppose a lot of these could be addressed if I released the code in a preliminary fashion (providing folks the ability to help me with documentation, etc.). Hmm... Yeah, I should really get a beta tarball up, and/or make a FreeBSD port for it already (since I am a ports committer). Also, I recently discovered that at EuroBSDCon, Constantine Murenin will be giving a talk about the OpenBSD Hardware Sensors Framework: http://2008.eurobsdcon.org/talks.html. This makes me makes me wonder if the project is being re-considered for FreeBSD (it was committed to CURRENT in October 2007 and then backed out after being referred to as a "festering junkpile that does not belong in the kernel", reference: http://lists.freebsd.org/pipermail/cvs-src/2007-October/082398.html). If it is being reconsidered, I think it would make *much* more sense for me to spend my time getting ICHx SMBus support working under that, since the framework provides an interface for me to work with. To answer your 2nd question: yes, I plan on supporting other motherboards and products. The reason that is on hold/back-burner is: * I have contacts at Supermicro who can provide me full register details and provide overall support/help when I need it. I have none of this with Sun, nVidia, IBM, nor Intel. I can assure you that if I mail the general "Technical Support" lists these companies have, the support folks will /dev/null my mails, or simply go "What is this? SMBus slave hardware chip what? What the hell is that? Whatever..." and ignore the mail because it's outside of the norm. I do not believe in "randomly probing the SMBus" to try and find things by trial and error -- the risks are huge! People don't realise that reading registers can cause interrupts or features to be reset or disabled on the chip, which could cause the entire machine (or maybe just the SMBus layer) to lock up. I can assure you none of the bsdhwmon testers will put up with those risks, as most of them are doing testing on actual production servers and are trusting my "play it safe" judgement... * I want to get a good, solid list of Supermicro servers officially supported before moving on to a mix-match of other hardware. I do have very basic support for an AMD-based H/W monitoring chip used in a Supermicro board, but there's no SMBus driver available on FreeBSD for that chipset, so bsdhwmon can't work with it. > I wrote you an e-mail in June about my interest in testing thist > project on my servers, but got no reply. Hmm... I've looked through my mail archives for all of 2008, and I don't see any mail from you pertaining to bsdhwmon. I do see other mails (discussing GRUB, ATA problems, etc.) but nothing about bsdhwmon. I was grepping for 'Miroslav', looking specifically in my mailbox dedicated for [EMAIL PROTECTED] Could you resend it? > I have some Sun Fire X2100 M2 (nVidia chips), IBM x335 (Intel), IBM x336 > (Intel) servers and one Supermicro X6DHP-8G (Intel) server. Thanks. I'll add these to my list of servers that I should try to focus on in the near future (since you have hardware available for testing), and mark you down as the contact I should refer to for help/testing. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Maki
alpm(4) I/O range is claimed by ACPI
Hi, How can I load the alpm(4) module for SMBus support on my ASUS Vintage AH-1 system? It appears the I/O range it uses is claimed by the acpi(4) driver. Can I override the mapping in some way i.e. tell ACPI not to claim the range? I don't see anything obvious about this in the acpi(4) man page. thanks, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fwd: FreeBSD 7.1 Content
On Thu, 11 Sep 2008, Vincent Hoffman wrote: > Ian Smith wrote: > > > > The wrappers around fdisk and bsdlabel alone are worth a lot, despite a > > notion that 'real men' figure out cylinder and slice offsets themselves. > > If even those sections were broken out to separate tools, I'd rarely > > need to fire up sysinstall to, for example, partition a new disk/slice. > > man 8 sade > someone kindly pointed this out to me not long ago, very handy. Magic .. thanks Vince. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fwd: FreeBSD 7.1 Content
Ian Smith wrote: > The wrappers around fdisk and bsdlabel alone are worth a lot, despite a > notion that 'real men' figure out cylinder and slice offsets themselves. > If even those sections were broken out to separate tools, I'd rarely > need to fire up sysinstall to, for example, partition a new disk/slice. > man 8 sade someone kindly pointed this out to me not long ago, very handy. Vince ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fresh 7.0 Install: Fatal Trap 12 panic when put under load
On Thu, Sep 11, 2008 at 11:20 AM, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > On Thu, Sep 11, 2008 at 10:38:36AM +0200, Michael Grant wrote: >> My box crashed again: >> >> panic: kmem_malloc(4096): kmem_map too small: 1073741824 total allocated >> cpuid = 0 >> Uptime: 33d11h12m58s >> Dumping 3327 MB (2 chunks) >> chunk 0: 1MB (151 pages) ... ok >> chunk 1: 3327MB (851568 pages) <---hung here >> >> Still no valid dump. >> >> There is 4gig of physical memory in the machine. >> >> In /boot/loader.conf, I currently have the following: >> >> vm.kmem_size=1G >> vm.kmem_size_max=1G >> vm.kmem_size_scale=2 >> >> and in my kernel conf file I have: >> >> options KVA_PAGES=512 >> >> It stayed up for 33 days this time. Is there anything else I can do? > > First and foremost: are you using ZFS on this machine? If so, there are > many tunables you can apply to try and limit this; I'm willing to bet > it's ARC which is doing it. See below. > > In general, it appears that you need to increase the maximum range of > kmem. The kernel attempted to utilise more than 1GB, and your limit is > 1G. My machines running RELENG_7 on amd64, with only 2GB of RAM > installed, use the following tunables in loader.conf: > > vm.kmem_size="1536M" > vm.kmem_size_max="1536M" > > If ZFS is in use, I recommend these as well: > > vfs.zfs.arc_min="16M" > vfs.zfs.arc_max="64M" > vfs.zfs.prefetch_disable="1" > > Do not increase kmem_size any larger than 1.5GB; the amount of RAM you > have in the machine, with regards to RELENG_7, will not help. This is a > known limitation which has been fixed in HEAD/CURRENT (where the limit > has been increased to 512GB). See the "Kernel" section below; you'll > see the applicable item. > > http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues > > Your only solution may be to run HEAD/CURRENT. I am not running ZFS. My file systems are ufs. This feels like some sort of memory leak in the kernel. Giving it more and more memory just seems to delay the crash. Are you saying the crash is fixed in HEAD/CURRENT? I'm running 6.3 by the way. I have put your changes into my loader.conf, we'll see how long it goes this time. I'm not qute in position to update everything to 7.x at the moment. Michael Grant ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel ICH7 SMBus support, ichsmb(4)
Jeremy Chadwick wrote: On Wed, Sep 10, 2008 at 11:19:10PM +0100, Bruce M Simpson wrote: Hi there, I have been looking at a system which has the Intel ICH7 south bridge. Whenever I try to probe the SMBus on this system with 'smbmsg -p', I get a lot of status=41 timeout messages in dmesg from the ichsmb(4) driver. I have been given the addresses of the SMBus peripherals and have tried initiating reads to their register space directly using 'smbmsg', with the same result. Yes, I have seen this behaviour but *only* when querying a slave address which was incorrect or had no device tied to it. You should not be using the "8-bit data address". * Has anyone seen the same issues with the ICH7? All of my development on bsdhwmon has been done exclusively on ICH7 chipsets, except for the hardware I don't have access to (which use other chipsets, but still use ichsmb(4)): http://bsdhwmon.parodius.com/ During early development of bsdhwmon, I used smbmsg exclusively for testing. So in that respect, no, I've never seen the problem you report. Are you still actively working on bsdhwmon and do you plan to support non-Supermicro servers? I wrote you an e-mail in June about my interest in testing thist project on my servers, but got no reply. I have some Sun Fire X2100 M2 (nVidia chips), IBM x335 (Intel), IBM x336 (Intel) servers and one Supermicro X6DHP-8G (Intel) server. Miroslav Lachman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fresh 7.0 Install: Fatal Trap 12 panic when put under load
On Thu, Sep 11, 2008 at 10:38:36AM +0200, Michael Grant wrote: > My box crashed again: > > panic: kmem_malloc(4096): kmem_map too small: 1073741824 total allocated > cpuid = 0 > Uptime: 33d11h12m58s > Dumping 3327 MB (2 chunks) > chunk 0: 1MB (151 pages) ... ok > chunk 1: 3327MB (851568 pages) <---hung here > > Still no valid dump. > > There is 4gig of physical memory in the machine. > > In /boot/loader.conf, I currently have the following: > > vm.kmem_size=1G > vm.kmem_size_max=1G > vm.kmem_size_scale=2 > > and in my kernel conf file I have: > > options KVA_PAGES=512 > > It stayed up for 33 days this time. Is there anything else I can do? First and foremost: are you using ZFS on this machine? If so, there are many tunables you can apply to try and limit this; I'm willing to bet it's ARC which is doing it. See below. In general, it appears that you need to increase the maximum range of kmem. The kernel attempted to utilise more than 1GB, and your limit is 1G. My machines running RELENG_7 on amd64, with only 2GB of RAM installed, use the following tunables in loader.conf: vm.kmem_size="1536M" vm.kmem_size_max="1536M" If ZFS is in use, I recommend these as well: vfs.zfs.arc_min="16M" vfs.zfs.arc_max="64M" vfs.zfs.prefetch_disable="1" Do not increase kmem_size any larger than 1.5GB; the amount of RAM you have in the machine, with regards to RELENG_7, will not help. This is a known limitation which has been fixed in HEAD/CURRENT (where the limit has been increased to 512GB). See the "Kernel" section below; you'll see the applicable item. http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues Your only solution may be to run HEAD/CURRENT. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fresh 7.0 Install: Fatal Trap 12 panic when put under load
My box crashed again: panic: kmem_malloc(4096): kmem_map too small: 1073741824 total allocated cpuid = 0 Uptime: 33d11h12m58s Dumping 3327 MB (2 chunks) chunk 0: 1MB (151 pages) ... ok chunk 1: 3327MB (851568 pages) <---hung here Still no valid dump. There is 4gig of physical memory in the machine. In /boot/loader.conf, I currently have the following: vm.kmem_size=1G vm.kmem_size_max=1G vm.kmem_size_scale=2 and in my kernel conf file I have: options KVA_PAGES=512 It stayed up for 33 days this time. Is there anything else I can do? Michael Grant ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fwd: FreeBSD 7.1 Content
On Sun, 7 Sep 2008, Ken Smith wrote: > On Sat, 2008-09-06 at 14:51 +1000, Ian Smith wrote: > > I just booted off the 7.0 disc1 to check, and /usr/local/bin/links is > > still the default browser in Options, available during installation from > > another vty. So I was a bit surprised, on rebooting into my so far not > > much configured 7.0, to find that it hadn't actually been installed. > > > > It's a pretty small package, useful enough to at least read local docs, > > and would be handy installed from disc1 .. and maybe even by bootonly? > > I'm actually planning to go in the opposite direction so to speak as far > as sysinstall is concerned. There are a couple projects in the works to > replace sysinstall, along with the other nifty projects that roll > FreeBSD into "another distro" in Linux-speak. [Please in FreeBSD-speak, to avoid getting called that? 'derivative'? (deriv for short? :) Anything but what world plus dog will inevitably equate to a linux 'distro'. Sorry, bikeshed topic but it tweaked me ..] Yes derivative releases (Freesbie, PC-BSD, Desktop BSD) are Good Things, and your New Direction below sounds like it should faciliate more such. > Basically this is something where one thing can't cater to everyones' > needs/tastes/bikeshed-color. All you need to do is tolerate this thread > long enough to reach this message to see that... :-) Hope you can handle just one more :) > I'm with Scott in that I like the "other distros" being around. I don't > think that necessarily means we shouldn't try harder. But IMHO trying > harder needs to be reflected in a new installer. Lets face it, > sysinstall s*cks... For the type of folks who want the installer to do > more than sysinstall does now sysinstall simply isn't the right tool (no > offense intended). % man sysinstall | tail says it all. However sysinstall has enough bits (modules, really) that don't suck to make its presence still worthy. The wrappers around fdisk and bsdlabel alone are worth a lot, despite a notion that 'real men' figure out cylinder and slice offsets themselves. If even those sections were broken out to separate tools, I'd rarely need to fire up sysinstall to, for example, partition a new disk/slice. And sysinstall's frontend to pkg_add is pretty handy, especially for noobs, though by the time you're doing an FTP install you have to wade through all x,000 packages .. a bit more on this aspect later .. > That said I think "I" (as RE) am stuck with sysinstall being around for > the forseeable future, even after we get a new installer, because some > people are so accustomed to it and it fits their needs (again witness > this thread...). So I do have some plans for sysinstall but as I said > above it'll be more towards a different direction than mentioned above. > > The path I'm planning is based on these observations: > > - Many people believe you should just use sysinstall to install >the baseline system, and any packages/ports installs should >be done post-install. Its hard to say that point of view is >wrong. Indeed, perhaps it should be enforced by some sort of 'yes we have a functioning basic install aboard' flag before allowing postinstall stuff at all? The only times I've ever had problems with sysinstall were when trying to do too much - like selecting lots of assorted packages before having committing the base install, which can be tempting as it is. > - The baseline system and the ports are fundamentally different. >People should be aware of that from the beginning. Yes, though any other installer than sysinstall, unless part of the base system - and therefore not relying on other languages like ruby, python, whatever - might need to install some bits to run? That is, such a separation may sometimes need to be less than religiously enforced? > - At least some of the packages on the ISOs are stale within a >week of release at times; a bit longer than a week in most >cases but ... This is really a separate issue. While many well-connected folks with fast machines tend to advocate updating the ports tree and installing all from source, quite validly, at the other end of the spectrum - those with older, slower and/or smaller kit and/or those still stuck with dialup connections (still very common in other-than-urban Australia, let alone 'developing' countries) it should still be possible to do what I did over 10 years ago; install from CDs, spend some weeks learning and configuring the system and tools before even first putting it online. > - My plans for DVD sized media (still uncertain how that will >factor into 6.4/7.1) are to provide CDROM sized ISOs that have >no packages on them at all (giving people who don't have DVD >drives something they can still install from) and one DVD >sized ISO that has packages. Downloading
