Re: Unhappy Xorg upgrade
Robert Noland wrote: ... Ok, lets try another test... There is a scanpci util in the libpciaccess port. We don't install it, but it does get built. Build the port and run scanpci -v as root from the console. That should poke all the pci devices on the box and tell you about them. See if that is able to trigger the issue. Well spotted. I saw this tool in locate output and was going to try it the other day, although I saw it didn't get installed, so assumed it was historical. Yes, This immediately triggered the issue without even running X on a fresh boot. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Unhappy Xorg upgrade
Robert, First, thanks for all your dedicated work so far on the Xorg ports. I realize this upgrade has been somewhat fraught with unexpected issues. FWIW, things are not greener on the Linux side of the fence; many Ubuntu and Debian users have reported issues with the newer Xorg and in particular hald. Robert Noland wrote: ... I still see the USB symptoms with xorg-server port as of today -- forced rebuild with libpciaccess also. So amd64 is still regressed -- USB is totally unusable there after X is started. My theory was that somehow Xorg was stomping on the USB controller registers on this machine. The USB controller on this box is ALi, card=0x81561043. Is your usb sharing interrupts with the video card? Yes, it appears so. This is an ASUS Vintage AH-1, uniprocessor amd64 box w/ioapic enabled from devinfo -r (abbreviated): ohci0 17 ohci1 18 ohci2 19 ehci0 23 lspci -v jibes with devinfo -r -- the primary head got IRQ 18, the secondary IRQ 255. It appears msk0 is also sharing IRQ 18, though I haven't seen any problems with networking; mskc0, however, is then configured to use MSI (pseudo IRQ 256, 258), it is a PCI-e device. When the system starts, the drm module has not been loaded, so the Radeon (Sapphire X550) card hasn't been allocated its IRQ by FreeBSD. After X starts, glxinfo and glxgers work fine. kldstat reports drm.ko and radeon.ko got loaded by X as I would expect. I still see no IRQ allocated for the radeon, either in dmesg output or in devinfo -r, however, vmstat -i does show drm0 as sharing IRQ 18. At this point, I rebooted and tried manually resetting the BIOS ESCD table, unfortunately the BIOS on this machine won't let me tie IRQs down to particular devices. Does the issue occur if you aren't using a usb mouse? I see the USB problems regardless of the kind of USB devices plugged in, I continue to use a PS/2 mouse on the desktop as a workaround. I see the bump on devel/libpciaccess re typo of rombase, and forced a rebuild of xorg-server against the patched libpciaccess library (probably not needed, as the .so ABI didn't change). The USB problem is still present, unfortunately. thanks, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Unhappy Xorg upgrade
Robert Noland wrote: ... Ok, that is odd... Once drm is loaded and X opens it, the ddx driver should request that the irq handler be installed. At that point, dmesg should show something resembling the following. vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xc000 256MB info: [drm] Initialized i915 1.6.0 20080730 drm0: [ITHREAD] Yes, I normally see output similar to this when X is started. ... Does the issue still occur if drm is disabled? Just tried disabling DRM w/ 'Options DRI off' in Section Device. DRM is indeed disabled -- no dmesg output and not loaded by X. However the problem is still there. BTW: This Radeon card does have MSI capabilities according to lspci, however they do not appear to be enabled either by FreeBSD or by X. I was about to point the finger at interrupt filters, however that blows that theory out of the water. FWIW the IBM T43 here has an i915GM, and USB is working just fine and dandy. The main data point which sticks out is the fact that the affected machine is amd64. Now that DRM has been disabled on my box, this would point the finger at the X userland. I don't see any obvious nasties in my Section Device, although I do pass a BusID and BusType to prevent X from trying to use the second head with RandR (lots of pain with fubar DVI cables when I first purchased the monitor). I skimmed pci_user.c, thinking libpciaccess just thunks to it via /dev/pci, it appears there's no instrumentation there I can turn on to see what userland is actually frobbing. thanks, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Unhappy Xorg upgrade
Bruce M. Simpson wrote: S.N.Grigoriev wrote: I thank you for your response. I've applied the patch to pci.c from kern/130957. Unfortunately there are no positive results. USB is still unreachable with X. Just following up to confirm that you are seeing exactly the same symptoms with USB and Xorg 7.4 as I see on my amd64 desktop running 7-STABLE from 00:00 UTC on this Wednesday. I still see the USB symptoms with xorg-server port as of today -- forced rebuild with libpciaccess also. So amd64 is still regressed -- USB is totally unusable there after X is started. My theory was that somehow Xorg was stomping on the USB controller registers on this machine. The USB controller on this box is ALi, card=0x81561043. My i386 laptop (IBM/Lenovo T43) is not affected, and USB mice work just fine there. Obviously it's difficult to check what Xorg is actually doing to the registers on the box w/o a PCI bus analyzer, and of course due to normal decoding, those cycles probably won't be seen on the backplane itself as it sits behind a bridge; I haven't fully read what libpciaccess is doing. I skimmed patch-src-freebsd_pci.c. I wonder if this code may be stomping on the USB controller in some way (i.e. how it frobs the BARs). According to src/tools/tools/pciroms, the only PCI devices on this box with ROM BARs are mskc0 and vgapci0. (I also wonder if it's possible to guarantee that the window at 0xC is always going to be available, even in the amd64 case.) cheers BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Replace Cisco IOS/CBOS with freebsd - possible?
Chris H wrote: ... I know Peter Grehan was looking at getting FreeBSD onto the Cisco 827 a while back. That's good news. I'll have to see if I can get more info on that. I just purchased a lot of cisco *DSL/routers on ebay, in an effort to push this project forward (I can experiment on these with less concern). IMHO pfSense beats the pants off OpenWRT from a user/deployment point of view, and often that is ultimately what counts. Thing is, it's only for x86-based PCs. I had the foresight to purchase some relatively quiet 1U boxes, but they're still too noisy to have in a room where people sleep live or socialise -- they belong to the computer nook at the front of the apartment (I have a very odd C-shaped apartment). I believe something that could really make pfSense fly, would be a viable port to mass-market, low-power consumer hardware. Then again, old Ciscos sort of fit the bill. Repurposing old vendor hardware is just as subject to engineering process as anything else, in some cases, the varying Bill-of-Materials may make the economic cost too high to do things on a mass scale. If people would be reasonably expected to use such a system, they should not have to understand the mechanisms, in great detail, of how firmware is loaded onto a device. This is one of the main stumbling blocks behind mass uptake -- we can't just say fire up this tool and click this 1 button to extend/build new network infrastructure. Given the current economic and ecological situation, though, devising systems which allow people to do this might be something worth investigating, and funding to that effect may be available out there. cheers BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Unhappy Xorg upgrade
S.N.Grigoriev wrote: I thank you for your response. I've applied the patch to pci.c from kern/130957. Unfortunately there are no positive results. USB is still unreachable with X. Just following up to confirm that you are seeing exactly the same symptoms with USB and Xorg 7.4 as I see on my amd64 desktop running 7-STABLE from 00:00 UTC on this Wednesday. thanks, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Unhappy Xorg upgrade
Alex Goncharov wrote: I hate to say this, but the new X (as exists in the current FreeBSD ports) sucks and gets in the way of work big time. There are definitely issues with xorg-7.4 at the moment. The root issue seems to be that USB mice simply don't work for me, and running Xorg appears to destabilise the 7-STABLE USB stack in some way which I just don't understand. The condition isn't recoverable without a reboot. I am the only person who's reported these symptoms in any great detail yet. I spent a lot of time yesterday debugging with rnoland@ the USB problem I've been having. He sent me a patch, however, it doesn't solve the problem. My understanding is that a lot has changed in this Xorg release to do with input drivers, specifically mouse -- and that platform specific code got shuffled off out of the server itself, and into the drivers. Good from an academic software engineering point of view, but if this is the cause, not good from a regression point of view. Whilst bisecting all the conditions, and tracing it back to this upgrade is easy to do, I can't readily identify the causal relationship -- I don't know what's going on which has broken Xorg for me in this way, and haven't seen anything like this before. Since upgrading, I've seen stability problems with hald enabled. I have had to turn off hald mode on both my laptop and desktop 7-STABLE machines, as it can totally hang the machine, no DDB break, etc. Scanning SVN, nothing appears to have changed in the 7-STABLE train in terms of USB, moused, the ums driver, or anything else. A ktrace of the moused process bound to ums0 goes dead (no I/O, no syscalls) after X is started. One theory is that somehow the mouse driver ioctls which are passed to ums, are somehow hosing USB, although why that would be, I don't understand. ums currently doesn't have driver instrumentation in that path. I pulled a fairly detailed IRC log of my collaborative debugging session with Robert, please ping me if you need details of this. thanks BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Replace Cisco IOS/CBOS with freebsd - possible?
SDH Support wrote: Seconded for Pfsense -- although I doubt the Cisco hardware would be compatible with FreeBSD, and even if it is , I wouldn't want to use it in a production environment without thorough testing. If someone can provide more detailed hardware specs, including the chipsets and processor details of the cisco hardware , im sure we could realistically evaluate the feasibility. I'm very, very happy with pfSense. It's a case of the folk behind it having followed an software appliance-style model and that's what makes it stable. I know Peter Grehan was looking at getting FreeBSD onto the Cisco 827 a while back. The PowerPC port has gone some way towards this, but I don't see folk installing it on old Cisco hardware yet... unless the knowledge gets out there. cheers BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: panic in destroy_devl: null si_devsw
Andriy Gapon wrote: ... About the code that called destroy_dev(): it created cdev probably too early, failed to allocate some system resource, so it went to destroy the newly created cdev. Non-null cdevsw was definitely provided to make_dev. I saw a very, very similar panic with 7.1 sources and jhb's ppc locking patch yesterday. Could this be related to a difference in unit numbers between 8.x and 8.x? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
A nasty ataraid experience.
Hi there, I had a bit of a nasty experience this week with ataraid(4). I thought I would summarize the issues I ran into so hopefully others can benefit from my nasty experience, should they experience catastophic failure of a Pseudo-RAID. I was surprised that I was unable to find much in the way of similar experience in forums. Luckily, I didn't lose any data, thanks to mr ports/sysutils/scan_ffs. Bog simple setup. Gigabyte VM900M motherboard, Intel Core Duo T4300. JMicron JMB363 controller, two SATA ports, RAID mode. Two Seagate 160GB drives. I'll skip the stuff about the strange loop I got into with having to recreate the MBR and disklabels after they got trashed -- suffice to say, BACK THEM UP... BACK THEM UP... --- 1. atacontrol rebuild. There are a few issues here. I'm partly to blame here for not reading the documentation in the handbook about the rebuild process -- however -- hilarity ensued. Following the rebuild procedure in the Handbook, if you try to run atacontrol rebuild from the FreeBSD 7.1 LiveFS, it'll break. I ran it thinking that it had some kind of magic in it which I couldn't achieve using dd alone, which is partly true, but also partly not true. It has a hardcoded path to /usr/bin/nice, which it runs using the system() libc call, and unfortunately, the LiveFS is rooted at /mnt2. It does this after it issues an ioctl() to tell the ATA driver to copy and rewrite the meta-data to the new spare drive. Ooops. At this point the state of the array is inconsistent. atacontrol status will report the array as REBUILDING, despite the fact that the dd job never kicked off. Because the metadata has now been rewritten, and the ataraid driver has entered a REBUILDING state, you can't stop it, and it won't rebuild. I also found that the default dd block size it uses, 1m, didn't work with my drives -- I had to dd manually with a 64KB block size to get things to work, otherwise I got lots and lots of ATA read/write errors related to trying to write beyond the last part of the disk. The drives themselves are fine, though. HOMEWORK: atacontrol rebuild needs to be taught to play nice when run in a catastrophic recovery situation; the path stuff needs to be fixed, and perhaps some magic should be added to allow the metadata to be zapped when Really Bad Stuff happens. --- 2. raid metadata, and drive sizes. OK, the tradeoff with ataraid is that it is pseudo-raid. That's understood, however, it's easy for the metadata to be downright out of sync with After my bad experience with atacontrol rebuild from the LiveFS, to trick FreeBSD back into understanding that the array was in fact degraded, I had to read the ataraid driver code to figure out which LBA it was expecting to see the metadata at, and then wipe that out with dd. It doesn't help that the drives themselves are of different sizes. So. Imagine the hilarity when I just swap the drives and try to rebuild the array. Ooops. HOMEWORK: Is there a way to use the system partition stuff e.g. ATA SET MAX ADDRESS to get around this? Obviously it would mean losing a few sectors at the end of the drive, but it's a small price to pay for sanity with Pseudo-RAID. --- 2. RAID BIOS. I have been using a JMicron 36x PCI-e controller. Unfortunately, when stuff like the MBR is broken, it says nothing informative -- it will just skip to the next INT 19h handler. This is more something which should be thrown at the BIOS vendors -- I don't believe there isn't enough space in there to print a message which says The drive geometry is invalid. HOMEWORK: Someone needs to throw a wobbly at the vendors. --- 3. fdisk and drive geometry. The root cause of my boot failure, it turned out, was that the drive geometry was wrong for the JMicron SATA RAID BIOS. It turns out sysinstall's guess at the drive geometry is right for LBA mode (C/H/S n/255/63), and thus right for my SATA controller BIOS. fdisk, however, wants to use a C/H/S of n/16/63 by default. Profanity ensues. HOMEWORK: Why does fdisk still assume 16 heads... ? Perhaps we should have a switch to tell it to use the LBA-style C/H/S converted geometry? --- Redux I understand why organisations pay good money for hardware RAID controllers, but given that time has moved on, this is kinda effed up. I shouldn't, in an ideal world, have to bust hours of ninja admin moves just to get a single RAID-ed home server back up and running. I also now understand that I can't rely on RAID alone to keep the integrity of my own data -- there is no substitute for backups, I just wish there were realistic backup solutions for individuals trying to do things with technology right now, without paying over the odds, or being ripped off. A good enough cheap solution is what individuals often end up using, to get things going in life with minimal resources or wastage. I hope others benefit from my experience. cheers BMS P.S. Big thanks to
Re: SATA hotplug and AHCI
Andrey V. Elsukov wrote: ... Linux's libata driver has a quirk for VIA AHCI: /* vt8251 doesn't clear BSY on signature FIS reception, * request follow-up softreset. */ If i right understand it issues softreset for VIA controllers just after hardreset. And after softreset it is trying to read device signature. FreeBSD CURRENT has similar code, but it is disabled by default. You can try install CURRENT and rebuild ata_ahci driver with AHCI_PM option. May be it will help.. I'm glad this came up. When I asked a few weeks ago about SATA Hotplug support, I was asking because of a board with a VIA SATA controller I was planning to add drives too, on a JBOD basis. Perhaps this hack can be backported to 7.x to actually make VIA controllers useful? P.S. VIA's SATA RAID BIOS is a pile of poop, don't bother using VIA for RAID. cheers BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ext2fuse: user-space ext2 implementation
Paul B. Mahol wrote: Can you please relay this feedback to the authors of ext2fuse? As mentioned earlier in the thread, the ext2fuse code could benefit from UBLIO-ization. Are you or any other volunteers happy to help out here? Well, first higher priority would be to fix existing bugs. It would be very little gain with user cache, because it is already too much IMHO slow and adding user cache will not make it faster, but that is not port problem. I'm not aware of bugs with ext2fuse itself; my work on the port was merely to try to raise awareness that a user-space project for ext2 filesystem access existed. Can you elaborate further on your experience with ext2fuse which seems to you to be buggy, i.e. symptoms, root cause analysis etc. ? Have you reported these to the author(s)? Have you measured the performance? Is the performance sufficient for the needs of an occasional desktop user? I realise we are largely involved in content-free argument here, however the trade-off of ext2fuse vs ext2fs in the FreeBSD kernel source tree, is that of a hopefully more actively maintained implementation vs one which is not maintained at all, and any alternatives for FreeBSD users would be welcome. thanks BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ext2fuse: user-space ext2 implementation
I have rolled a port for ext2fuse: http://people.freebsd.org/~bms/dump/fusefs-ext2fs.tar I look forward to your feedback. thanks, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Experience with RDX removable backup drives?
Are these any good? Has anyone tried them with FreeBSD and/or bacula? For small office, these look like where the price point is for backups... 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: ext2 inode size patch - RE: PR kern/124621
FYI:The ext2 IFS driver for Windows v1.11a also appears to have the inode size issue: http://www.fs-driver.org/ I was not able to mount an ext2 filesystem with 256 byte inode size using this driver. Its installer will see that the filesystem exists, that it's ext2, but whenever you try to mount, you get nothing -- a very similar failure mode to the FreeBSD ext2fs driver. Again, it sounds like the author is actively maintaining it, so it might be worth contacting him to pool resources. cheers, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ext2fuse: user-space ext2 implementation
Hi, I just tested the ext2fuse project on FreeBSD 7.1-PRERELEASE as of today and found that it works for read/write on an ext3 filesystem. The inode size was 128 -- I haven't exercised dynamic inode sizes. ext2fuse project:http://sourceforge.net/projects/ext2fuse Required FreeBSD patches: http://people.freebsd.org/~bms/dump/ext2fuse-freebsd.patch Steps: 1. fetch http://ovh.dl.sourceforge.net/sourceforge/ext2fuse/ext2fuse-src-0.8.1.tar.gz 2. tar xvf ext2fuse-src-0.8.1.tar.gz 3. patch -i ext2fuse-0.8.1-freebsd.patch 4. cd ext2fuse-src-0.8.1 5. aclocal ; automake ; autoconf 6. ./configure gmake Performance seems quite slow, it could probably benefit from being ported to use UBLIO as ntfs-3g for FreeBSD has. I'm going to leave this thing for others to play with, this was a 20 minute bunk-off from other work. It shouldn't take much effort to create a port around it. 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: ext2fuse: user-space ext2 implementation
Bruce M. Simpson wrote: ... Performance seems quite slow, it could probably benefit from being ported to use UBLIO as ntfs-3g for FreeBSD has. I'm going to leave this thing for others to play with, this was a 20 minute bunk-off from other work. It shouldn't take much effort to create a port around it. P.S. Ale's patch to use libublio for fusefs-ntfs is here, if anyone picks up on ext2fuse before I do: http://people.freebsd.org/~alepulver/fusefs-ntfs.diff This contains the necessary diffs for UBLIO. cheers BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Issues with mount(8) and FUSE in 7.1-PRERELEASE
Hi all, I noticed when porting ext2fuse to run on 7.1-PRERELEASE, that the port sysutils/fusefs-ntfs needs some additional steps in order to mount user-space FUSE filesystems on startup. These steps weren't necessary in 6.x. It seems mount(8) can't deal with new mount binaries unless it has been explicitly built with support for them; please see /usr/local/share/doc/ntfs-3g/README.FreeBSD for more info where the problem is described in more detail. There is a comment which reads as follows in the mount.c code: /* XXX: We need to get away from implementing external mount * programs for every filesystem, and move towards having * each filesystem properly implement the nmount() system call. */ Unfortunately, this assumption seems to be grounded in a very restricted picture of the filesystem world. FUSE is clearly something which doesn't fit a limited use case of let's only mount stuff which the FreeBSD base system supports, and, to my mind, is applicable to the vast majority of FreeBSD desktop users. This seems like an inflexible approach, and I'm curious why this design choice persists. I understand the technical arguments for nmount() and I do support them, but not at the expense of functional utility. How can we make this work for users out-of-the-box? thanks, BMS P.S. There is a patch by Ale Pulver to change some of this hardcoded logic, however it doesn't seem complete: http://people.freebsd.org/~alepulver/current-7.0-mount.diff ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ext2 inode size patch - RE: PR kern/124621
Kostik Belousov wrote: ... Bruce, feel free to commit the patch. I do not want to spend time on ext2 in any form, and due to our (only partly jokingly) rule of the last committer is the owner, I do not want to analyze ext2 bug reports after. Yes, development resource is limited here too, and any involvement on my part here DOES NOT constitute any commitment, express or implied, to maintaining the ext2fs module beyond the change being considered right now. I find that this often has to be reiterated as people are prone to confusing the concepts open source and free, basic economics dictates infinite demand for free goods, and we've all got lives to live. As per our off-list discussion: It's a damned if we do and damned if we don't situation. Take the patch and it eats someone's lunch, and our reptuation suffers. Don't take the patch and look like patriarchal killjoys, and our reputation siffers. Your specific objection is that the testing is insufficient to exercise the patch, and there could be an area of ext2 which this patch doesn't address. That can never be said with 100% certainty, but I agree with you. Content free argument: Based on my reading of the code, the patch must be considered experimental. Whilst the scope of the patch appears to be small, the symbol space of ext2 is bigger -- a case of feeping creaturism due to ext2 itself, but hey, that's evolution for you. If folk are happy with it going in, let it go in, but remember, you get the system you apply effort to. I myself consider the patch experimental -- but HEAD is an experiment, is it not? Reality is what you can get away with. 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: ext2 inode size patch - RE: PR kern/124621
Hi, The inode size for the ext3 filesystem which Gentoo created for my last install defaulted to 256 bytes, so I got bit by this problem. I can't speak for the write path. but the read path looks just fine to me, and the patch should go in ASAP. Josh Carroll wrote: Ok, I describe my concern once more. I do not object against the checking of the inode size. But, if inode size is changed, then some data is added to the inode, that could (and usually does, otherwise why extend it ?) change intrerpetation of the inode. Thus, we need a verification of the fact that simply ignoring added fields does not damage filesystem or cause user data corruption. Verification != testing. If folk are paranoid, then add a check for dynamic inode size and disable ext2fs writes by downgrading the mount in that case (We can do that, right? Can someone make sure Josh gets the help he needs here?) As Josh points out, the ext2 inode size is stored in the superblock. Whilst it may vary between ext2 filesystems, *the inode size itself does not appear to be something which one can modify in an existing ext2/3 filesystem*. Older ext2 filesystems may not contain the inode size field in the superblock, and the patch appears to default to 128 for that case. The double indirection thus introduced doesn't concern me, our ext2fs is not performance critical code, and the superblock is likely to sit in L2/L3 cache anyway (note: content free argument). Thanks to Josh for fixing this problem. 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: smbmsg(8): slave address confusion?
Gavin Atkinson wrote: I believe this is the case, yes. See for example, PR kern/100513. It appears that some frivers treat the adfdress one way, and others treat it the other. I can confirm this from recent commercial work I had to do involving smb(4). thanks, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Firefox 3 fraks postscript fonts
Hi, I've noticed that with Firefox 3, output on my venerable PostScript printer uses the wrong fonts. A garbled bitmapped font is being substituted. If I revert to Firefox 2, printed output is fine. Haven't seen this with other apps. Seen with a networked cups driven printer, specifically GCC Technologies (ancient LaserWriter II compatible device). The remote printer server is 7.1-PRERELEASE w/cup 1.3.9. Connection is lpt0 (centronics). FreeBSD empiric.lon.incunabulum.net 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Mon Oct 13 09:54:07 BST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/EMPIRIC7 i386 empiric:~ % pkg_info | grep firefox firefox-2.0.0.14,1 Web browser based on the browser portion of Mozilla firefox-3.0.1_1,1 Web browser based on the browser portion of Mozilla empiric:~ % pkg_info | grep cups cups-base-1.3.7_2 Common UNIX Printing System cups-pdf-2.4.7 A virtual printer for CUPS to produce PDF files cups-pstoraster-8.15.4_1 Postscript interpreter for CUPS printing to non-PS printers gutenprint-cups-5.1.7_2 GutenPrint Printer Driver libgnomecups-0.2.3,1 Support library for gnome cups admistration empiric:~ % ldd /usr/local/lib/firefox/firefox-bin /usr/local/lib/firefox/firefox-bin: libmozjs.so = /usr/local/lib/firefox/libmozjs.so (0x2808f000) libxpcom.so = /usr/local/lib/firefox/libxpcom.so (0x28138000) libxpcom_core.so = /usr/local/lib/firefox/libxpcom_core.so (0x2813c000) libplds4.so.1 = /usr/local/lib/libplds4.so.1 (0x281dd000) libplc4.so.1 = /usr/local/lib/libplc4.so.1 (0x28208000) libnspr4.so.1 = /usr/local/lib/libnspr4.so.1 (0x28234000) libgtk-x11-2.0.so.0 = /usr/local/lib/libgtk-x11-2.0.so.0 (0x28265000) libgdk-x11-2.0.so.0 = /usr/local/lib/libgdk-x11-2.0.so.0 (0x285dd000) libatk-1.0.so.0 = /usr/local/lib/libatk-1.0.so.0 (0x28662000) libgdk_pixbuf-2.0.so.0 = /usr/local/lib/libgdk_pixbuf-2.0.so.0 (0x2867b000) libpangocairo-1.0.so.0 = /usr/local/lib/libpangocairo-1.0.so.0 (0x28693000) libXext.so.6 = /usr/local/lib/libXext.so.6 (0x2869d000) libXrender.so.1 = /usr/local/lib/libXrender.so.1 (0x286aa000) libXinerama.so.1 = /usr/local/lib/libXinerama.so.1 (0x286b3000) libXi.so.6 = /usr/local/lib/libXi.so.6 (0x286b6000) libXrandr.so.2 = /usr/local/lib/libXrandr.so.2 (0x286be000) libXcursor.so.1 = /usr/local/lib/libXcursor.so.1 (0x286c4000) libXcomposite.so.1 = /usr/local/lib/libXcomposite.so.1 (0x286cd000) libXdamage.so.1 = /usr/local/lib/libXdamage.so.1 (0x286d) libcairo.so.2 = /usr/local/lib/libcairo.so.2 (0x286d3000) libpangoft2-1.0.so.0 = /usr/local/lib/libpangoft2-1.0.so.0 (0x28738000) libpango-1.0.so.0 = /usr/local/lib/libpango-1.0.so.0 (0x2876) libfreetype.so.9 = /usr/local/lib/libfreetype.so.9 (0x2879c000) libz.so.4 = /lib/libz.so.4 (0x2880a000) libfontconfig.so.1 = /usr/local/lib/libfontconfig.so.1 (0x2881c000) libX11.so.6 = /usr/local/lib/libX11.so.6 (0x28845000) libXfixes.so.3 = /usr/local/lib/libXfixes.so.3 (0x2892a000) libgobject-2.0.so.0 = /usr/local/lib/libgobject-2.0.so.0 (0x2892f000) libgmodule-2.0.so.0 = /usr/local/lib/libgmodule-2.0.so.0 (0x28969000) libglib-2.0.so.0 = /usr/local/lib/libglib-2.0.so.0 (0x2896d000) libiconv.so.3 = /usr/local/lib/libiconv.so.3 (0x28a1c000) libgthread-2.0.so.0 = /usr/local/lib/libgthread-2.0.so.0 (0x28b11000) libm.so.5 = /lib/libm.so.5 (0x28b16000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x28b2b000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x28c2) libthr.so.3 = /lib/libthr.so.3 (0x28c2b000) libc.so.7 = /lib/libc.so.7 (0x28c3e000) libXau.so.6 = /usr/local/lib/libXau.so.6 (0x28d4) libglitz.so.1 = /usr/local/lib/libglitz.so.1 (0x28d43000) libpng.so.5 = /usr/local/lib/libpng.so.5 (0x28d69000) libpixman-1.so.9 = /usr/local/lib/libpixman-1.so.9 (0x28d8e000) libexpat.so.6 = /usr/local/lib/libexpat.so.6 (0x28db6000) libXdmcp.so.6 = /usr/local/lib/libXdmcp.so.6 (0x28dd6000) librpcsvc.so.3 = /usr/lib/librpcsvc.so.3 (0x28ddb000) libintl.so.8 = /usr/local/lib/libintl.so.8 (0x28de3000) libicui18n.so.38 = /usr/local/lib/libicui18n.so.38 (0x28dec000) libpcre.so.0 = /usr/local/lib/libpcre.so.0 (0x28f43000) libm.so.4 = /usr/local/lib/compat/libm.so.4 (0x28f6a000) libicuuc.so.38 = /usr/local/lib/libicuuc.so.38 (0x28f8) libicudata.so.38 = /usr/local/lib/libicudata.so.38 (0x2909e000) empiric:~ % ldd /usr/local/lib/firefox3/firefox-bin /usr/local/lib/firefox3/firefox-bin: libxul.so = not found (0x0) libmozjs.so = not found (0x0) libxpcom.so = not found (0x0) libplds4.so.1 = /usr/local/lib/libplds4.so.1 (0x2807e000) libplc4.so.1 = /usr/local/lib/libplc4.so.1 (0x280a9000) libnspr4.so.1 = /usr/local/lib/libnspr4.so.1
GCC profiling broken with C++ exceptions on FreeBSD 7.1
Hi, I just noticed this in testing over last week, it seems to be specific to FreeBSD 7.1: http://bugzilla.xorp.org/bugzilla/show_bug.cgi?id=811 Does anyone have any information we could use to further track this down? Other platforms don't seem to be affected. cheers BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[Fwd: Profiling on FreeBSD]
I got this response from Robert, the root cause sounds plausible (amd64 vs i386 not preserving ecx). Any chance of an MFC? I see one is pending in the PR. If I can test and verify the change I could MFC. Original Message Subject:Profiling on FreeBSD Date: Wed, 5 Nov 2008 08:47:37 +1100 From: Robert Jenssen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Hi, GCC 4 gprof profiling for i386 has been broken on FreeBSD for quite a while. See PR bin/119709. It appears that the fix has been MFC'd recently: $FreeBSD: src/sys/i386/include/profile.h,v 1.42.2.1 2008/10/13 12:45:18 kib Exp $ (I've been successfully using gprof by patching using the code in the PR but haven't rebuilt my system with the above change) Is there a similar problem for AMD64? Cheers, Rob Jenssen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
7.0-RELEASE panics when loading USB modules x2
Hi, I just had 7.0-RELEASE crash again, whilst kldloading the uplcom.ko module in multi-user mode with X running, and no USB serial devices plugged in. The T43 immediately resets, I don't get a chance to drop into a debugger. This seems like a pretty serious USB regression. Is anyone looking into it? Are these things a thing of the past with the new USB code? thanks BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
USB detach/attach hangs with 7.0-RELEASE and 7.1-PRERELEASE
Hi, I've noticed some general instability with plugging in or removing USB devices with FreeBSD 7.x, even when the devices are not actively in use. I had this happen with umass and ucom devices 3 times today. The machine hangs solid, there are no obvious signs of a panic or trap to DDB. I can't provide backtraces unfortunately -- these hangs happen on both my laptop and desktop, and I usually have X running -- if I had more specific information, I'd open a PR. Again, there seems to be no reason why this should happen, the devices are off-the-shelf consumer items known to work with existing drivers, and have been repeatedly used in other OSes without these hangs happening; consider this an anecdotal report. [For some reason my IBM laptop will often not allow me to break into DDB on a driver related panic, and will just immediately reboot -- I lack free time to track down exactly why this could be. My desktop has a USB keyboard and this appears not to be supported by DDB, I ordered a PS/2 keyboard which hasn't arrived, but that's another story.] thanks BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
fxp multicast forwarding problems
Hi, Whilst doing some QA work on XORP on my desktop, which has fxp0 and msk0, fxp0 got totally hosed. I was running PIM-SM and IGMPv2 router-mode on the box at the time. I wonder if this is related to the problems with fxp multicast transmission I saw back in April. I'm a bit concerned about this as fxp is still a very widespread and useful network chip. I am running 7.0-RELEASE-p4/amd64. sysctls for dev.fxp.0 are set to their default values. I'm not expert on the fxp driver internals, but perhaps someone else has seen this kind of problem before. Multicast-promiscuous mode (aka ALLMULTI) was enabled on the interface. I know some NICs have problems with this, or don't even support it. The errors look like this: fxp0: SCB timeout: 0x10 0x0 0x80 0x0 fxp0: SCB timeout: 0x10 0x0 0x80 0x0 fxp0: DMA timeout ... repeated ... Attempted workarounds which don't work to un-wedge the chip: Reload the fxp0 microcode with ifconfig fxp0 link0 Forcibly unloading the kernel module and reloading it Unpatching and repatching at the switch (a cheap 10/100 one) Enabling and disabling promiscuous mode Twiddling dev.fxp.0.noflow The link status looks fine, but the card will not send or receive traffic. A warm reboot was enough to get things back up again. regards, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: floppy disk controller broken
You could try formatting the floppy in a USB drive. Someone was going to pick this up, finish it off, and commit it, but I haven't heard back from them: http://people.freebsd.org/~bms/dump/tools/ufdformat/ ___ 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
John Baldwin wrote: But surely if alpm(4) were to attach to such a range in this way, it would need to be a child of the acpi bus device, yes? No, the code in acpi_alloc_resources() does _not_ check for that. Any child device with a specific allocation that falls in a system resource range will succeed the allocation. Ah, it is clearer after looking at devinfo output. Allocations will bubble up the bus drivers until they get to nexus. In this case, acpi is a child of nexus, therefore it will satisfy the allocation. It looks like there used to be a means of doing this in the FreeBSD driver but it got nuked. And that ASUS didn't much care about power management support in this machine... If you can re-enable it in such a way that it uses bus_alloc_resource(), then the driver will probably work fine. In that case it sounds like one needs to be able to use a hard-wired hint. It has been over a year since I've been able to do any proper work on mips , which needs a lot of this sort of thing, and I don't have a compelling case to do it now, so hopefully someone with an interest can pick this up. 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: 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. Sure enough, this was my screwup. In short: I found the problem. The active flag wasn't set on any MBR slices. Tried booting from USB on 3 machines, and it all works perfectly. Thanks to kib@ and jhb@ for all their hard work on real mode BTX. For details of the bug bashing, read on. There is a thread here on the SYSLINUX list about USB long boot times: http://syslinux.zytor.com/archives/files/2005-January/004592.html Unrelated, as USB-HDD mode appears OK here. I tried this again with the EDD stuff disabled in mbr and boot1 as per your suggestion. Didn't make any difference. The boot delay (up to a minute) is still present. I note that the access light on the flash device DOES NOT flicker during this period, so I'm not sure that we're seeing sector-by-sector access. Of course without a POST card who can tell -- I didn't get one of those involved yet. After the delay I decided to interrupt loader(8) and do 'lsdev'. According to loader(8), the USB key is seen as BIOS drive C: (number 1) when 'mbr' is used as the mbr bootstrap. Turns out the AMI BIOS v2.58 on the ASUS Vintage AH-1 lets you force the boot mode for attached USB mass storage devices. This option is buried under Advanced-Chipset-SouthBridge Configuration-USB Configuration-USB Mass Storage Device Configuration-Emulation Type. It only appears if a USB mass storage device is plugged in at boot time. Choosing Hard Disk made no difference. Presumably this is because Hard Disk mode is chosen anyway if Auto is selected (the default) as the device is larger than 530MB. I re-examined the MBR on the key and it looks like it is using USB-HDD style geometry. Choosing Forced FDD mode seems to break boot completely, no change after 2m 40s. I'd expect this because there is an MBR on the disk, instead of a huge FAT filesystem. So USB-HDD mode appears to be chosen by the BIOS for this device as a default. So I tried reinstalling boot0 which lets me change packet/setdrv modes, as well as giving me some visual feedback about the boot stage. ...after much tweaking... So it appears the active flag was not being set for the first partition, it seems NanoBSD's fdisk script didn't set it; that should probably get patched, as this was the root cause of the USB booting delay. PS If there are any other drives present, then the boot menu does get displayed, regardless of the mask setting in boot0cfg. 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?
Jeremy Chadwick wrote: I'm trying my best to make things better, doing things purely from a userland perspective and using SMBus exclusively (since the interface is quite reliable, assuming the SMBus driver used on FreeBSD is working correctly). I understand-- Bruce is having problems with ichsmb(4), while on every ICH7 board I have (and I have many), I've had nothing but success. All of bsdhwmon's main development has been done on ICH7 boards I use and have physical access to, for example. I fished out the A/Open MX3S board I have. It seems to have an ICH2 south bridge. An old version of Gentoo I had installed finds the ICH2. mbmon is able to talk to a Winbond chip over ISA; it sees an SMBus slave 0xA0/0x50, I don't know what that is yet. I got this board years ago, I think because it does actually support smbus. I'm just futzing with Gentoo now to get the HWMON and other i2c drivers up. i2c-i801.ko probes and attaches. i2c-dev.ko created /dev/i2c* nodes ok. I then downloaded i2c-tools from http://www.lm-sensors.org/wiki/I2CTools and built it. %%% raisin i2c-tools-3.0.1 # /usr/local/sbin/i2cdetect 3 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c/3. I will probe address range 0x03-0x77. Continue? [Y/n] Y 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: 30 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- 69 -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- %%% %%% raisin i2c-tools-3.0.1 # mbmon -S -D Probe Request: none Testing Reg's at SMBus [Intel8XX(ICH/ICH2/ICH3/ICH4/ICH5/ICH6), IO-Base:0x5000] SMBus slave 0xA0(0x50) found... SMBus[Intel8XX(ICH/ICH2/ICH3/ICH4/ICH5/ICH6)] found, but No HWM available on it!! InitMBInfo: Success %%% Likely these are old versions of the mbmon tools. %%%raisin i2c-tools-3.0.1 # /usr/local/sbin/i2cdump 3 0x50 b 0 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c/3, address 0x50, mode byte Continue? [Y/n] Y 0 1 2 3 4 5 6 7 8 9 a b c d e f0123456789abcdef 00: 80 08 04 0c 0a 01 40 00 01 80 60 00 80 08 00 01[EMAIL PROTECTED] 10: 8f 04 06 01 01 00 0e a0 60 00 00 14 14 14 32 20?.??`..???2 20: 20 10 20 10 00 00 00 00 00 00 00 00 00 00 00 00 ? ? 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 f6..?? 40: 2c ff ff ff ff ff ff ff 08 38 4c 53 44 54 31 36,...?8LSDT16 50: 36 34 41 47 2d 31 30 45 45 31 20 01 00 03 10 6c64AG-10EE1 ?.??l 60: 08 95 7e 00 00 00 00 00 00 00 00 00 00 00 00 00??~. 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 64 af..d? 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff %%% Hey, that looks like a Micron DIMM. I didn't see anything on the other two i2c bus addresses. So I can confirm SMBus works on the MX3S from Linux 2.6.x. I'll blow it away with 7.1-BETA and see what happens next. 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?
Chris Ruiz wrote: Error: attack:~ root# smbmsg -p smbmsg: Cannot open /dev/smb0: No such file or directory Looks like the smb.ko module ain't loaded. 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: I also always use boot0 for my NanoBSDs as I need safe way for remote upgrades, so have two code slices. And I always use these knobs: NANO_BOOTLOADER=boot/boot0 NANO_BOOT0CFG=-o packet -s 1 -m 3 -t 36 ... Good point, it looks like NanoBSD was installing boot0sio by default. I overrode this in my config with boot0 as you do and that works for me. thanks again, 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?
Jeremy Chadwick wrote: I don't consider this a dependency issue at all. These are all literally separate things; you do not meed smbus(4) and smb(4) if you just simply want to tie a driver to a feature/device that's on the PCI bus (e.g. ichsmb(4)). Besides, does kldload or kernel modules in general have *any* sort of dependency tree code? I didn't think they did. Some modules do, some modules don't. One of the issues here is that there is sometimes a diamond-like dependency graph between kernel modules, or there is no way to establish dependency at all. For example, smb(4) has no idea that ichsmb(4) should be loaded, for the very reason you point out that smb(4) isn't needed by ichsmb(4); whilst ichsmb(4) presents an smbus(4) interface in the kernel, which smb(4) will recognise and attach to, it has no idea that it should get loaded. Having said that, I thought your plain language explanation of how things are was excellent and clear. 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: I fished out the A/Open MX3S board I have. ... So I can confirm SMBus works on the MX3S from Linux 2.6.x. I'll blow it away with 7.1-BETA and see what happens next. I can confirm that SMBus appears to work on the A/Open MX3S under FreeBSD 7.1-BETA. After kldload ichsmb and kldload smb: %%% ichsmb0: Intel 82801BA (ICH2) SMBus controller port 0x5000-0x500f at device 31.3 on pci0 ichsmb0: [GIANT-LOCKED] ichsmb0: [ITHREAD] smbus0: System Management Bus on ichsmb0 smb0: SMBus generic I/O on smbus0 %%% smbmsg -p: %%% Probing for devices on /dev/smb0: Device @0x30: rw Device @0x50: rw Device @0xb0: rw Device @0xd0: rw %%% pciconf -a seems to be broken: %%% raisin:~ % s pciconf -a pci0:0:31:3 pciconf: ioctl(PCIOCATTACHED): Inappropriate ioctl for device %%% My theory at the moment is that the working platforms might have had some other bits twiddled in PCI config space. I'm ruling that out for now, based on the fact that when I dump the CSRs for the SMBus function on both the ICH2 (known good, working) and ICH7 (suspect), the HOSTC register contents are the same (SMBus is enabled) and both have interrupt lines routed to them. working system, ICH2: %%% raisin# pciconf -r pci0:0:31:3 0:0x40 24438086 0281 0c050002 5001 244b8086 020c 0001 %%% suspect system, ICH7: %%% foo:~ % s pciconf -r pci0:0:31:3 0:0x40 27da8086 0281 0c050001 0501 27da8086 0213 0001 %%% Both are using SMP-enabled kernels. The working system is running a 7.1-BETA kernel, GENERIC so it has SMP, but it's a uniprocessor 633MHz Celeron; the suspect system has dual-core (I *think* it is Intel Atom). I'm not sure how that could make a difference. The ichsmb(4) driver uses msleep() (now deprecated) to avoid busy-waiting when polling for SMB transaction completion. On the suspect system, msleep() always times out. So both are using ithreads... AHA! After a reboot it looks like I can see a device on the suspect system, interesting. But after the first probe, it doesn't respond. This could well be down to the implementation of that particular SMBus device on the platform, and it tends to move the finger of suspicion away from the smbus drivers themselves. 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
John Baldwin wrote: 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. But surely if alpm(4) were to attach to such a range in this way, it would need to be a child of the acpi bus device, yes? The IPMI driver probes for a specific ACPI ID in the DSDT. PCI ID looks like this: [EMAIL PROTECTED]:0:30:1: class=0x068000 card=0x81561043 chip=0x710110b9 rev=0x00 hdr=0x00 So I grabbed the M1543 datasheet off the web and looked in CSR space. Guess what: the AMI BIOS on the ASUS Vintage AH-1 does NOT set up the PMU. The function is still visible, it just has no active I/O mappings. No wonder alpm(4) does not attach. I tried looking for this device in the DSDT, I don't see anything which obviously resembles it. The equivalent Linux driver has a means of forcing the mapping to be set up if it isn't available: http://www.kernel.org/doc/Documentation/i2c/busses/i2c-ali15x3 It looks like there used to be a means of doing this in the FreeBSD driver but it got nuked. And that ASUS didn't much care about power management support in this machine... Oh well! I know ichsmb works on at least one machine that I have. cheers BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
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]
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: 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]
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]
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: 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]
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: SMBus controller 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]
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: 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: 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: Kingston DataTraveler 2.0 PMAP 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: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED 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: 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]
Intel ICH7 SMBus support, ichsmb(4)
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. * Has anyone seen the same issues with the ICH7? * Does anyone know of any userland code I could use as an alternative to the ichsmb(4) driver? I looked at mbmon, it appears it relies on the smb(4) drivers; its direct ISA access only works for specific hardware monitoring chips which appear on the ISA/LPC bus and does not implement SMBus bit-banging in userland. Many many thanks for any help you can provide. cheers BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic when detaching Vodafone 3G card
Hi, I just acquired one of these cards, it attaches as a USB cardbus device. This is just to say that I can reproduce the problem described here: http://www.rinta-aho.org/docs/option3g/option.html The driver support was originally committed here: http://www.freebsd.org/cgi/query-pr.cgi?pr=112161cat= ...the ubsa driver attaches to the virtual modem port. If I unplug it, the kernel panics. The panic is in kobj_delete() (a null pointer reference) and it's on the usb detach path. Unfortunately I wasn't able to get a backtrace this time around. PS Does anybody know if ubsa will be ported to the new USB driver framework? cheers BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ACPI sleep broken on ASUS Vintage AH-1
Hi, Just noticed that when I try to ACPI-sleep an ASUS Vintage AH-1 based desktop system, that I get the following message: acpiconf: request sleep type (3) failed: Operation not supported Supported sleep states in sysctl: hw.acpi.supported_sleep_state: S1 S3 S4 S5 This is an amd64 uniprocessor system running 7.0-RELEASE. BIOS version is 0303 (last release), it is an AMI BIOS. I've seen S3 sleep work fine in Windows XP on this box. I would really like to be able to sleep this box rather than up/down it, as it's in my home, less noise, less power consumption etc. Any further info needed let me know. 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: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
Jo Rhett wrote: I am suggesting that given that the current bug list for 6.3-RELEASE is both (a) too large and (b) breaks things that work fine in 6.2 ... that I think pushing 6.2 (the real stable release) into EoL is a bit rushed. I sympathize with the development costs of maintaining old versions. Again, I will help in any way I can. I'm sorry to hear about the problems you've been having. It is worth remembering that FreeBSD is an open source project, and it's maintained on a best-effort basis -- it is offered for free and without any warranty. Like any other open source project, risk management and change management becomes a two-way street, because that's the trade-off struck with the open source model. The risks, as well as the benefits, have to be factored in carefully to your company's technology strategy, as I'm sure you're aware. I'm very surprised that the 6.3 train has been a big issue for you, although speaking from the development side of the fence, there are a lot of moving targets, and vendor support of the OS does play a part. It is difficult to offer any more specific advice without knowing in more detail exactly what's causing such problems for you, although I see you've offered general pointers, the folk directly involved need to be pointed at direct information. The FreeBSD Project just doesn't have the resources to do compatibility testing on the scale of e.g. Windows Hardware Quality Labs, as I'm sure you are also aware. I take on board what you say about your organisation holding back on an upgrade because there are PRs filed for the hardware you use, and having worked in an investment banking environment, I understand this level of conservatism is warranted. However, I point out again: it's the open source model, and where hardware compatibility is concerned, it really is a case of suck it and see. Always has been, no different anywhere else. Open source requires user participation. Microsoft run the WHQL because their status as a going concern depends on it. I'm pleased to hear about your offer of hardware resources for developers. However, this is only part of the problem. To my mind, you need to find the right people, with the right skills, to deal with the issues, and quite often, those guys are already in demand, and thus their time can attract a high value. Open source succeeds because money is not the only motivation. The alternative is DIY, and that is the point. If you need firm guarantees about support, consider contracting with someone to do that. Many companies using FreeBSD already outsource this kind of support requirement to 3rd parties. There are also FreeBSD hardware vendors who support FreeBSD as a platform. If you want someone to take responsibility, make 'em an offer. 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: how much memory does increasing max rules for IPFW take up?
Andrey V. Elsukov wrote: Vivek Khera wrote: I had a box run out of dynamic state space yesterday. I found I can increase the number of dynamic rules by increasing the sysctl parameter net.inet.ip.fw.dyn_max. I can't find, however, how this affects memory usage on the system. Is it dyanamically allocated and de-allocated, or is it a static memory buffer? Each dynamic rule allocated dynamically. Be careful, too many dynamic rules will work very slow. Got any figures for this? I took a quick glance and it looks like it just uses a hash over dst/src/dport/sport. If there are a lot of raw IP or ICMP flows then that's going to result in hash collisions. It might be a good project for someone to optimize if it isn't scaling for folk. Bloomier filters are probably worth a look -- bloom filters are a class of probabilistic hash which may return a false positive, bloomier filters are a refinement which tries to limit the false positives. Having said that the default tunable of 256 state entries is probably quite low for use cases other than home/small office NAT gateway. cheers BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Automounting USB sticks - questions
I got this working quite easily with the amd daemon. Thanks to Alfred for your excellent work on this. I wonder what the status of autofs is? It would be great if we could ship FreeBSD out of the box, ready to automount removable media. This would be useful to all users, but particularly for novices and people who just wanna get on and use the beast. Since the move to /media for a place to put removable mount points I'd imagine all of this gets a lot easier. However I can understand there are real issues with this: * /etc/amd.conf. We don't ship one in /etc by default. Maybe we should? * /etc/amd.map. We ship one which contains defaults and nothing more. Perhaps commented out examples? * There doesn't appear to be a tool to tell amd about new maps at runtime. Is there such a beast? UPDATE: I just read code, and it seems SIGHUP can be sent, but this isn't in the man page and I haven't tried it. * devd doesn't have any hooks into GEOM, which makes it difficult to generate mount lines without retroactively parsing dmesg output. devd as I understand it sits on top of NEWBUS. Is there any way I can get a list of the disk devices, from userland, in the default install, which correspond to a given NEWBUS device? * I wonder if there's any way we can get a notification about media being inserted into a CDROM drive, without polling it? I had a brief discussion online with phk@ about doing dynamic mounts, and it seems that there are still problems dealing with blowing away mounts when the device goes away. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fails to build new gcc
R.Mahmatkhanov wrote: cc: Internal error: Killed: 9 (program cc1) Please submit a full bug report. See URL:http://gcc.gnu.org/bugs.html for instructions. *** Error code 1 Others have said this is down to not having enough memory; also it can indicate a problem with the memory you already have. 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: panics on 6.3-RELEASE in IP stack
Bruce M. Simpson wrote: I started to play with RAT application (ports: mbone/rat + an SVN version) and it seems to crash my 6.3-RELEASE-p1 box in rather deterministic way. Crash details are shown below. Has anyone seen a problem like this? Yes, there's an off-by-one reference count bug in the multicast stuff. I concur, this fix should really be MFCed. The problem went away in 7.x due to a total rewrite. I am distracted by other stuff at the moment, so, starter's orders... This just bit me. The fix is in RELENG_6, but it is not present after the -p1 tag. So updating to STABLE should fix the problem for Petr. Whilst 6 is no longer the STABLE branch, I think this really should go onto 6 in case any other releases happen from that branch. 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: panics on 6.3-RELEASE in IP stack
John Baldwin wrote: On Monday 07 April 2008 12:16:53 pm Petr Holub wrote: Hi all, I started to play with RAT application (ports: mbone/rat + an SVN version) and it seems to crash my 6.3-RELEASE-p1 box in rather deterministic way. Crash details are shown below. Has anyone seen a problem like this? Yes, there's an off-by-one reference count bug in the multicast stuff. I concur, this fix should really be MFCed. The problem went away in 7.x due to a total rewrite. I am distracted by other stuff at the moment, so, starter's orders... 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: Missing manual pages (e.g. aio_fsync)
Carlos A. M. dos Santos wrote: Hello, It seems that the manual page of aio_fsync is missing, at least in FreeBSD 7.0-STABLE. I have some questions regarding this: 1. Is there somebody working on a man page for aio_fsync? 2. Is there a list of missing manual pages? 3. What is the current status of POSIX and Unix Specification? Is there any agreement with IEEE or Open Group allowing to cut-and-paste from, say, http://www.opengroup.org/onlinepubs/009695399/functions/aio_fsync.html? The way open source usually works is, it takes longer for someone to write these questions and wait for a response, than it does to just get your sleeves rolled up and run in, guns blazing, and write the man page. Of course then it's easy to waste time doing something someone already did, but that way you get experience doing it, that is after all how open source works. They ain't exactly difficult to write. Doesn't really matter what you do, as long as you do something and I myself do well to remember the How It Works(tm) formula from time to time. I believe there is such an agreement but you need to check with others or use the handy CVSweb commit history(tm) for other pages e.g. clock_gettime to check what you can and cannot lift. 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: lpbb broken in 6.x?
Ian Smith wrote: To finish off completely hijacking your thread :) does anyone know of anything that can run a master/slave interface like pcf(4) which appears to have been an ISA bus only device? I don't have C skills to write one, though 400kHz master and slave routines in AVR asm were fun :) Later: after nearly losing this in a pine crash (don't ask), I've since seen John's reply to your later message. Could it be that smbus or something is also using iicbus rather than something messing with ppbus? Thanks for the hints. I don't have smbus in the kernel, nor do I have any other i2c device drivers loaded in the system. I stopped using smbus when it became pretty clear that it wasn't doing anything useful for me (it could never see CPU fan readouts or anything like that when I tried it on 3 different PIII era systems). I agree a pcf(4) style interface would go some way towards solving the problem, however, solder plus 74LS05 costs next to nothing, plus the leet value of having a circuit schematic in the man page had to be tried out. I think we're losing out there if it's not working, though. PS OpenBSD look like they took NetBSD's i2c and ran with it... cheers BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
lpbb broken in 6.x?
Hi, Just for giggles, I decided to solder up the circuit in lpbb(4) and try to use it to talk to a 24LC64 EEPROM with its i2c address set to 0. (Yes, I am using 74LS05s specifically for this circuit.) Imagine my surprise and dismay, when I try to test out the i2c bus using this tool: http://www.ricin.com/freebsd/kbtv/kbtv-1.1.3/saa/saa/support/scan_i2c.c ...and keep seeing this on the console, presumably whenever scan_i2c issues an iic(4) ioctl: lpbb0: can't allocate ppbus I made sure that no other devices were attached to ppbus0. Voltages on the port and the bus looked sane... SCL and SDA stable below 0.1V, nothing floating, good solid +5V on the supply rail using a 7805 regulator on a 9V battery to avoid any nasty current surprises -- I haven't fried my laptop's LPT port. Initially I had ppi loaded as well, I booted a clean kernel and loaded lpbb from the loader: Mar 24 15:40:39 empiric kernel: lpbb0: Parallel I2C bit-banging interface on ppbus0 Mar 24 15:40:39 empiric kernel: iicbb0: I2C bit-banging driver on lpbb0 Mar 24 15:40:39 empiric kernel: iicbus0: Philips I2C bus on iicbb0 master-only Mar 24 15:41:10 empiric kernel: iic0: I2C generic I/O on iicbus0 Mar 24 15:41:10 empiric kernel: iic1: I2C generic I/O on iicbus0 Not sure why iic attaches twice to the iicbus created by lpbb. However, I still got the same message when I re-ran scan_i2c: Mar 24 15:41:19 empiric kernel: lpbb0: can't allocate ppbus Mar 24 15:41:55 empiric last message repeated 1020 times There are real uses for this code, so I'm wondering, what's wrong with lpbb? Does lpbb explicitly require hints to be told where to attach? IMO it shouldn't, it already seems to attach to the first ppbus instance in the system. If I get free time otherwise, I'll try to investigate further. 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: lpbb broken in 6.x?
John Baldwin wrote: What other devices do you have on your ppbus? Do you have lpt0, etc.? Are your running lpd? The way that ppbus works is that only one child driver (ppi0, lpt0, etc.) can own the actual ppc device at a time, so when a child driver wants to do something, it requests ownership of the bus first. You need to find out which other child driver owns the bus. Hardware is an IBM/Lenovo T43, using the ppc driver. lpt was not in use, nor was lpd. I do use cupsd, however it is only configured to use network printers. I tried this both with ppi(4) loaded (I normally load it to support urjtag), and with no other ppbus devices loaded. I got the same results in both cases. I used devinfo to check if other devices were attached to the ppbus parent. ppc0 always has a single child ppbus0. In the first case ppi0 was attached. In the second case only lpbb appeared to be attached, no other direct children of ppbus0, printing the same message when attempting to use the bus (device not configured). So, still no resolution here. It would be very useful to use lpbb for initial write of a 24LC64 EEPROM. 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: lpbb broken in 6.x?
Bruce M Simpson wrote: I used devinfo to check if other devices were attached to the ppbus parent. ppc0 always has a single child ppbus0. In the first case ppi0 was attached. In the second case only lpbb appeared to be attached, no other direct children of ppbus0, printing the same message when attempting to use the bus (device not configured). Whoops, I meant can't allocate ppbus here, trying to avoid confusion· I can't seem to kldunload lpbb or other ppbus modules (if they are loaded) after they are loaded, this generates a device not configured message. 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: PAUSE support for Ethernet interfaces ?
Tom Samplonius wrote: FreeBSD does not send PAUSE frames, but most of the NICs out there will process received PAUSE frames. However ethernet flow control is mainly useful on the switches anyways. Switches these day (*) have small buffers (sometimes just a shared 3MB buffer for 24 ports). If several ports send too much to a single port at the same time, the switch could run out of buffer space in milliseconds and start dropping frames, so the switch will use flow control to get the transmitting ports to slow down, and let the buffer drain. Slowing down the senders with ethernet flow control results in better performance than letting some frames drop, and force a timeout and retransmit. Of course, deeper buffers would be even better. There are switch ASICs out there which implement upstream bandwidth limiting on ports by sending the PAUSE frame. I believe thompsa@ recently committed a fix to if_bridge to allow it to ignore PAUSE frames for the purposes of forwarding (they should never be forwarded, they are link scope only). It would be interesting to see a patch which implemented rate limiting in the same way as these ASICs do, but in if_bridge. 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: kevent on UDP sockets
Paul wrote: I'm having trouble with kevent() in connection with UDP sockets (6.2-STABLE). Registering an event seems to work, but when UDP packet arrives on the socket, kevent returns with 0. Is there currently a working support for UDP sockets in kqueue/kevent, or does it only apply to TCP sockets ? I can't recall specifics but I had a working routing daemon skeleton using UDP with kqueue around 5 years ago. I didn't use oneshot, and treated it much like select() i.e. the input event is level triggered, every time you call you should get the event. This is unlike WSAEventSelect() in Windows which is edge triggered. later BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kldload: Unsupported file type
John Baldwin wrote: It is printed whenever a kernel module is loaded. The modules load OK. Nothing special or different about them. ... The kernel is a link_elf type object I believe, so you have to have it. That follows (I was reading this the other day 'cause we don't support weak ELF symbols in the kernel for C++) however, why is the message being triggered now? Could it be ET_REL ? There have been no major changes to linking for the 6.3 buildkernel target IIRC. BTW only my amd64 system appears to be affected. later BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
kldload: Unsupported file type
Since updating to 6.3-RELEASE on two machines I see this message a lot. It is printed whenever a kernel module is loaded. The modules load OK. Nothing special or different about them. It seems to be harmless, but any idea why it's started happening since the release? 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: Question regarding Intel ICH7 motherboard and integrated RAID controller
Karl Denninger wrote: Is there something that I can do (e.g. what registers/info would help if I wrote them down?) since it would have to literally be transcribed manually. More of the same. Most likely your RAID BIOS wants to enter protected mode. BTX normlly runs in vm86 mode. Please do transcribe and post here so others may help to debug. kib has real mode BTX code which hasn't gone in to the tree yet. BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2-STABLE panic in network multicast-address related cleanup code
Please try the fix I provided you with last week. BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Static linking and memory usage
Jeremy Chadwick wrote: This reminds me: it sure would be useful if we had something like Solaris's pmap(1) on FreeBSD. In response to the original post: The kernel's ELF linker/loader for executables will share the text and read-only segments for static executables. We already have something similar to pmap in the ports collection, called pmap. However, there is a very detailed and powerful tool for Linux called Exmap, by John Berthels. I used it to profile XORP's shared library memory usage in great detail, i.e. it gave me figures on how much memory was saved by the text page sharing introduced by the use of shared libraries across related executables, enabling me to answer the question, Is the additional work of shared libraries worth the hassle? I don't have free time to port Exmap to FreeBSD, but if someone does, I can put them in touch with John and forward his fairly detailed explanation of how to go about doing that. pmap would be a starting point for such a port. regards, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help! My laptop drive may be dying.
Thanks for everyone's responses. Given that this drive may well be lying in its SMART registers, I've just ordered a new drive. Newer IBM/Lenovo machines appear to complain if you don't use Hitachi GST drives, so I ordered one of those to be on the safe side, as well as to preserve the resale value. I note with keen interest that a number of laptop warranties don't cover the drive. Fingers crossed it'll arrive tommorrow. Thanks again... BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Help! My laptop drive may be dying.
Hi, My laptop drive might be dying. It is a Samsung MP0804H which I have used for around 28 months without issue. Every now and then it will click and sound as though it is thermally recalibrating itself. I ran SMART diagnostics from smartmontools, and Samsung's own diag tools which all report the drive is OK (a full captive surface test). I see nothing untoward in the SMART info pages. Whilst Windows is able to tolerate the retrying of ATA commands which this click appears to be inducing, FreeBSD can easily get sick and just hang, which majorly gets in the way of real work. I am always running X without exception when this happens, so I can't get meaningful ATA error messages. Of course these happen before the buffer cache is flushed, so they don't show up in /var/log/messages, if anything is showing up at all. Many thanks for any help you can provide... regards, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FYI: ULi/ALi SATA fix committed on HEAD
This change has now been MFCed. cheers, BMS Bruce M Simpson wrote: I have just committed a change (with soren's blessing) for the upcoming 7.0 branch which resolves the regression with ALI/ULI sata controllers introduced in 6.2-RELEASE. This affected a number of systems in particular the ASUS Vintage series of barebones boxes. Some folks on stable were affected too. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Have some troubles after deleting group of packages...
Oliver Fromme wrote: After it I've deleted those packages by pkg_delete command. Firstly it seemed all OK, but later I have collided with such problems: $ sudo tcpdump /libexec/ld-elf.so.1: /lib/libpcap.so.4: Shared object has no run-time symbol table That's strange, because /lib/libpcap.so.4 is part of the FreeBSD base system. It doesn't come from any package. Was the PCAP_OVERWRITE_BASE option set in the environment during the port build/install? If so pcap could have been overwritten but I believe it *should not* record such an install in the package manifests, therefore it *should not* delete a file which is not owned by the package system. BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how much beer do I need to get this patch applied?
Jeremy Chadwick wrote: On Wed, Jun 20, 2007 at 12:56:46PM -0700, Kurt Buff wrote: On 6/20/07, Jo Rhett [EMAIL PROTECTED] wrote: If I get a message every day saying No output, how do I know when a failure has occurred? This patch changes nothing about that behavior. Getting no message is equally useless in the situation where no output was generated *AND* the result code is positive. Currently, if you get no message from that box, *something* is broken. Daily Emails with no useful information in them will, by default, get ignored by most SAs. I am playing this game right now with one of my systems. +1 for committing this patch. BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FYI: ULi/ALi SATA fix committed on HEAD
I have just committed a change (with soren's blessing) for the upcoming 7.0 branch which resolves the regression with ALI/ULI sata controllers introduced in 6.2-RELEASE. This affected a number of systems in particular the ASUS Vintage series of barebones boxes. Some folks on stable were affected too. regards, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to install FreeBSD from external USB cdrom
Daniel O'Connor wrote: I believe this is most likely this issue... http://www.nabble.com/BTX-issues-when-booting-from-a-USB-CD-ROM-t3047441.html Alas no solution yet as far as I am aware :( Forgot to Cc: my reply to the list: kib@ has real mode BTX code which appears to work with affected systems of mine, however, the code has not yet made it into CVS. I spliced it into a 6.2 miniboot ISO and it worked. regards, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
AcerLabs/ULi SATA woes (was: Re: Gigabyte GA-VM900M caveats)
The affected Gigabyte motherboard boots fine with a JMicron card -- the hard workaround was to disable the VIA onboard SATA and IDE controllers completely and swap in the spare PCI-e card. However, the machine I swapped this card out of does not boot now: atapci1: AcerLabs M5287 SATA150 controller port 0xec00-0xec0f,0xe880-0xe887,0xe800-0xe80f,0xe480-0xe487,0xe400-0xe41f mem 0xfebff800-0xfebffbff irq 21 at device 31.1 on pci0 atapci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xe400 ioapic0: routing intpin 21 (PCI IRQ 21) to vector 51 atapci1: [MPSAFE] atapci1: Reserved 0x400 bytes for rid 0x24 type 3 at 0xfebff800 atapci1: AHCI controller reset failure device_attach: atapci1 attach returned 6 This is with -CURRENT p4'd with an IFC from around 2-3 weeks ago on branch bms_netdev, which suggests the regression is still present in -CURRENT. 6.2-STABLE from around 1 month ago had the same AHCI controller reset problem. I'm not really sure how best to deal with this -- the machine needs to be working, that's for sure, as it is the machine where I do most of my FreeBSD development. There were no problems with 6.1-RELEASE, it has 4 SATA ports on the motherboard which makes it useful (although, ironically, there are probably not enough drive bays as it is a small ASUS barebones system), and it strikes one as odd that it might be necessary to maintain patches for consumer off-the-shelf hardware. Suggestions? Regards, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AcerLabs/ULi SATA woes
A workaround for this issue posted here works for me with 6.2-STABLE: http://www.mail-archive.com/freebsd-stable@freebsd.org/msg87083.html I plan to commit it on HEAD and RELENG_6 as soon as possible, as it fixes the regression introduced last year. It seems acceptable that the AHCI controller be degraded to legacy mode until such time as AHCI mode may be reliably enabled on this hardware. I don't have time to implement a better fix. It seems there has been some Linux activity from the vendor. The controller on my system is the one described in the patch set for Linux: http://www.ussg.iu.edu/hypermail/linux/kernel/0412.2/0825.html Regards, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AcerLabs/ULi SATA woes
Just for reference:
Soren has gotten back to me about this and has a patch pending. In the
meantime here is the style(9)-ified patch from Sven which I am currently
using (in 6.2-STABLE, CURRENT , and p4 branches).
Regards,
BMS
--- ata-chipset.c.orig Wed May 23 17:59:28 2007
+++ ata-chipset.c Wed May 23 18:00:44 2007
@@ -952,7 +952,7 @@
struct ata_chip_id *idx;
static struct ata_chip_id ids[] =
{{ ATA_ALI_5289, 0x00, 2, ALISATA, ATA_SA150, M5289 },
- { ATA_ALI_5288, 0x00, 4, ALISATA, ATA_SA300, M5288 },
+ { ATA_ALI_5288, 0x00, 4, ALIAHCI, ATA_SA300, M5288 },
{ ATA_ALI_5287, 0x00, 4, ALISATA, ATA_SA150, M5287 },
{ ATA_ALI_5281, 0x00, 2, ALISATA, ATA_SA150, M5281 },
{ ATA_ALI_5229, 0xc5, 0, ALINEW, ATA_UDMA6, M5229 },
@@ -984,16 +984,19 @@
switch (ctlr-chip-cfg2) {
case ALISATA:
+case ALIAHCI:
ctlr-channels = ctlr-chip-cfg1;
ctlr-allocate = ata_ali_sata_allocate;
ctlr-setmode = ata_sata_setmode;
/* if we have a memory resource we can likely do AHCI */
- ctlr-r_type2 = SYS_RES_MEMORY;
- ctlr-r_rid2 = PCIR_BAR(5);
- if ((ctlr-r_res2 = bus_alloc_resource_any(dev, ctlr-r_type2,
- ctlr-r_rid2, RF_ACTIVE)))
- return ata_ahci_chipinit(dev);
+ if (ctlr-chip-cfg2 == ALIAHCI) {
+ ctlr-r_type2 = SYS_RES_MEMORY;
+ ctlr-r_rid2 = PCIR_BAR(5);
+ if ((ctlr-r_res2 = bus_alloc_resource_any(dev,
+ ctlr-r_type2, ctlr-r_rid2, RF_ACTIVE)))
+ return ata_ahci_chipinit(dev);
+ }
/* enable PCI interrupt */
pci_write_config(dev, PCIR_COMMAND,
--- ata-pci.h.orig Wed May 23 18:00:53 2007
+++ ata-pci.h Wed May 23 18:01:02 2007
@@ -360,6 +360,7 @@
#define ALIOLD 0x01
#define ALINEW 0x02
#define ALISATA 0x04
+#define ALIAHCI 0x08
#define HPT366 0
#define HPT370 1
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Strange ACPI messages on Core 2 Duo system
Hi, I noticed the following in dmesg output should I be concerned? this is with 6.2-RELEASE SMP kernel. This is a Gigabyte GA-VM900M with Intel Core 2 Duo E4300 CPU. Copyright (c) 1992-2007 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RELEASE #0: Fri Jan 12 11:05:30 UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz (1808.71-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6f2 Stepping = 2 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,C MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe39dSSE3,RSVD2,MON,DS_CPL,EST,TM2,b9,CX16,b14,b15 AMD Features=0x2010NX,LM AMD Features2=0x1LAHF Cores per package: 2 real memory = 1006567424 (959 MB) avail memory = 975724544 (930 MB) ACPI APIC Table: GBTGBTUACPI FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 Version 0.3 irqs 0-23 on motherboard ioapic1 Version 0.3 irqs 24-47 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: GBT GBTUACPI on motherboard ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.LNK9] in namespace, AE_NOT_FOU ND SearchNode 0xc49c2480 StartNode 0xc49c2480 ReturnNode 0 ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.LNK9] in namespace, AE_NOT_FOU ND SearchNode 0xc49c22c0 StartNode 0xc49c22c0 ReturnNode 0 ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.LNK9] in namespace, AE_NOT_FOU ND SearchNode 0xc49c1ca0 StartNode 0xc49c1ca0 ReturnNode 0 ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.LNK9] in namespace, AE_NOT_FOU ND SearchNode 0xc49c3cc0 StartNode 0xc49c3cc0 ReturnNode 0 ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.LNK9] in namespace, AE_NOT_FOU ND SearchNode 0xc49c3ac0 StartNode 0xc49c3ac0 ReturnNode 0 ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.LNK9] in namespace, AE_NOT_FOU ND SearchNode 0xc49c79a0 StartNode 0xc49c79a0 ReturnNode 0 acpi_bus_number: can't get _ADR (repeated ~30 times) The rest is pretty normal. Regards, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Gigabyte GA-VM900M caveats
Hi, It seems in order to boot the 6.2-RELEASE cdrom on this system I need to disable the USB2/ehci controller in the BIOS, otherwise it panics after umass is detached during probe (I am attempting to boot from USB CDROM). I was surprised that it didn't fail due to the protected mode boot2 issue which kib has resolved, however that real mode boot code is yet to hit CVS. If the VIA V-RAID BIOS is configured with a 'bootable array', raid does not show up as I'd expect; I have to disable booting from the array in order to get ar0 to show up. The array currently shows up as 'degraded'. If there's a Wiki or something where this information may easily be added please point me at it... JFYI, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gigabyte GA-VM900M caveats
Daniel, Thanks for the affirmation that I'm not alone in this. The whole point of RAID being supported by platform firmware is to facilitate booting from it even if disks fail. Daniel O'Connor wrote: On a somewhat related note.. In my experience V-RAID is utter crap - if one of your disks fails in a RAID1 array and you reboot it will give you 2 options - erase the first part of your disk and boot, or sit and do nothing. When I asked my motherboard vendor about this they suggested I switch to SATA mode (to boot off one disk) or to put another disk in and rebuild... Not exactly good for unattended use. Summary: Avoid VIA software RAID like the plague. The BIOS (after latest update from Gigabyte) consistently reports that duplication failed whenever I attempted to [re]create the mirror in the BIOS. Even when I tried to switch the controller to SATA mode, the second disk persisted in being undetected. I removed the primary disk entirely. The secondary disk DID get mirrored, and the BIOS attempted to boot from it; although by the time I did this I had no way of verifying if FreeBSD had mirrored the data, or if the BIOS mirrored the data. FreeBSD never sees the second disk, whether in SATA or RAID mode, and setting the array to 'bootable' in the BIOS does not help in any case. Short of manually nuking the metadata on the disks themselves, I can think of no other clean room tactics, and the supplied documentation is also useless. Yes, utter crap, and a waste of valuable time. What I plan to do tommorrow is swap the JMicron card out of my Athlon64 machine and into the new Core 2 Duo system I began building. In a way this is good because the disks I purchased support SATA-300 as does the JMicron. However, FreeBSD's support for the onboard Acer Labs SATA on that system appeared to have regressed during the 6.1-6.2 lifetime due to an AHCI issue (see thread: 6.2-RC: Problem with SATA on ASUS Vintage AH-3, on this list). [Normally I have been running 7-CURRENT on that machine, with the JMicron card, so up until now this hasn't been an issue, but this is what kicked off the whole shooting match in the first place, and I need to be able to multi-boot Windows Longhorn Server and Gentoo Linux for the work I'm going to be doing.] I wonder if people have had better experiences with JMicron. I am encouraged by the work Scott Long has begun, although that is going to take time to bear fruit. I can't burn too much time on this though, I needed a working server today. Regards, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: carp patch - will this ever be in releng_6?
Stefan Lambrev wrote: Are there any chances for this: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_carp.c.diff?r1=1.46;r2=1.47 to be MFCed to RELENG_6 before 6.3-release ? It fixes quite annoying bug - destroying carpX (when having at least 2 carp interfaces) will panic immediately. This bugfix is from 3+ months ago. Sadly it is unlikely the failure condition you describe will be fixed in -STABLE, as resolving it requires far more work to be merged than the link to the diff you post above. Regards, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: socketpair: No buffer space available
Marc G. Fournier wrote: Mar 20 07:59:26 mars sshd[717]: error: reexec socketpair: No buffer space available If I have a login session on the machine, I can easily do a reboot of the machine, and it seems to come up clean every time (ie. no fsck's need to be run) ... Does anyone have any ideas of what I can look at? How odd. The re-exec feature is not documented in the man page. It appears that it can be turned off with the -r switch according to sshd.c. Can you give that a try and see if that offers symptomatic relief? It would be somewhat less secure as sshd will fork rather than fork..exec. The code does indeed appear to use socketpair. FreeBSD implements socketpair as a system call. Only AF_UNIX, SOCK_STREAM sockets are accepted. A quick look in KScope suggests the first place where this can fail with ENOBUFS is soalloc() from socreate(). Is this machine under heavy memory load in any way? soalloc() uses a zone allocator. I'm not sure how to track that from userland, vmstat -m only deals with kernel malloc() stats. BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Openvpn tap uses 99% cpu time
Emile Coetzee wrote: Okay I finally have a ktrace of the offending process. You can view it here: http://www.clarotech.co.za/dump/openvpn2.txt Thanks for this. If this is the correct trace, of the correct process, then it looks like OpenVPN is hanging immediately on opening the tap device. In a quick look at the code, nothing jumps out at me which is out of the ordinary about the locking during clone and open. It would have been useful to have the ps output to correlate with in case the process was spinning trying to acquire a spin lock, which would show up in the WCHAN field. One thing that does jump out at me is the use of the persist-tun keyword. Can you try removing the use of this keyword? It is something I've never had to use with OpenVPN. To the best of my knowledge there have been no other reports of this problem on FreeBSD. I'm sorry there is just very little hard information to go on here at the moment. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Openvpn tap uses 99% cpu time
Emile Coetzee wrote: I have done some more investigation. Rolling back to RELENG_6_2 solves the problem. I have now had this problem on 3 boxes in 2 days and have been able to reproduce it on a 4th in our lab. Starting openvpn with full debug it stops just before the point where the TAP devices gets initiated. And then the output from top shows openvpn on 99% cpu time (well almost). The recent changes to tap(4) were tested with openvpn and ppp before committing, and this is an isolated report at the moment. Other users on the list have suggested that the problem you are reporting does not affect FreeBSD alone. Please consider doing the following: 1. Use ktrace(8) to extract a kdump of openvpn as it runs into this problem, so that you may determine exactly which syscalls are invoked when you see this problem, and post it on this list. Consider using the ktrace pid mode to attach to openvpn as it blocks, as opposed to running openvpn under ktrace as a child process. 2. Implementing the usleep() fix as discussed by luigi, as the information in point 1 will give clues as to where the code is spinning. Regards, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Openvpn tap uses 99% cpu time
Emile Coetzee wrote: I then ran ktrace -p 1083 -f openvpn2.dump This produced no data at all. Shouldn't. :-) You need to run ktrace then kdump to dump the trace. Correlate the cpu spin with the wallclock time in the kdump output, and paste an excerpt of what you get -- it sounds like it is spinning on a syscall. I can't seem to get the stuff from pastebin, it just times out, so ok to post an excerpt here. 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: tap device at boot time
Willy Offermans wrote: Thank you for your response, but unfortunately adding cloned_interfaces=tap0 to my rc.conf did not solve the issue. The tap0 device only appeared after I started the openvpn daemon. Is there a way to determine the order to start the daemons. Maybe I can solve the problem in that way. cloned_interfaces=tap0 will only work with a version of FreeBSD which has clonable tap support (FreeBSD 7.0-CURRENT or 6.2-STABLE, not 6.2-RELEASE). Regards, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Openvpn tap uses 99% cpu time
Emile Coetzee wrote: No worries below is the last part of the first ktrace. I have dropped a full copy on our webserver: http://www.clarotech.co.za/dump/openvpn.txt Hi, Still no diagnostic info I'm afraid. What is needed is for the problem to be reproduced, with the openvpn process which is spinning under ktrace. You might need to hack your script to do this i.e. run openvpn directly from ktrace. Let it run for a bit, let it spin, then kill it. Check that you have kdump output from the openvpn process itself. Use the -T switch of kdump to get absolute timestamps, watch the wallclock time on your system when the spin happens, and post an excerpt of the kdump output at that time, which should tell us where openvpn is spinning. 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: RT2561 does not work (was: [CALL FOR TESTERS] (was: ral(4) and second/third gen devices))
Jan Henrik Sylvester wrote: Some searching led me to: http://samodelkin.net/~fjoe/if_ral.diff -- which compiles on 6.2-RELEASE and, loaded as module, makes the card available. I was under the impression this code had been merged to -STABLE already. Sorry to hear about the problems you're having. I myself have an rt2661and have not seen such problems. ral is currently not on the critical path for anything I'm doing otherwise I'd look at it just now; I would suggest filing a PR with this information. 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: ALi SATA controller
Søren Schmidt wrote: The problem is that your BIOS registers the resources used for AHCI operation but apparently hasn't really enabled them. Look for an option in the BIOS to turn on/off AHCI mode. There is no such option in the BIOS on this machine, as stated in the original thread. BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ALi SATA controller
Hi, I have experienced the same regression since 6.2 was branched on an ASUS amd64 Vintage-PE1 box. Juraj Lutter wrote: Feb 26 21:45:25 river kernel: atapci0: AcerLabs M5229 UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 31.0 on pci0 Feb 26 21:45:25 river kernel: ata0: ATA channel 0 on atapci0 Feb 26 21:45:25 river kernel: ata1: ATA channel 1 on atapci0 Feb 26 21:45:25 river kernel: atapci1: AcerLabs M5287 SATA150 controller port 0xc400-0xc40f,0xc000-0xc007,0xb800-0xb80f,0xb400-0xb407,0xb000-0xb01f mem 0xfe8ff400-0xfe8ff7ff irq 21 at device 31.1 on pci0 Feb 26 21:45:25 river kernel: atapci1: AHCI controller reset failure Feb 26 21:45:25 river kernel: device_attach: atapci1 attach returned 6 I'm sure I reported this to the list around 4th December 2006. My workaround was to install another SATA controller in the PCI-e slot and use that instead for the root disk. I think CURRENT also suffers from this problem. I think the last release which worked OK was 6.1. Regards, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Pleading for commit
Steve Hodgson wrote: Could you use objcopy --redefine-sym to rename the symbol in the flash library? I've not tried it of course. I just ran into this issue again. I tried this suggestion. It doesn't change the dynamic reference. I see the linuxpluginwrapper port has now been updated to deal with this! Excellent! regards, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Desired behaviour of ifconfig -alias
JoaoBR wrote: The only correct thing you say here is that all IPs are equal - and - nobody EVER said something different. Aliasing does not say anything about priority of the Ip it is simply related to the time the interface was set with the IP so the first IP is the one which was set first and the first alias is the one which was set after. The thing is, source selection policy and IP address scope blow the assumptions in this discussion out of the water, as does the concept of unnumbered IP interfaces. Scoping and selection policy is necessary to support link-local IPv4 (Zeroconf) and IPv6 as we move swiftly into a world where these things are a fact of life, and make deployment of useful IP networks for non computer users a reality. Interface preference is desirable in a stack supporting multipathing. Unnumbered IP, for example, is not dealt with at all well by the BSD stack. There are situations in which it is perfectly valid; a newly booting machine; a router at the end of a PPP link. We deal with something like 30% of the problem space for unnumbered IP. We need to be able to tell the IP stack 'be attached to this interface without a configured IP'. ifconfig syntax currently doesn't capture this requirement; the keywords 'add/delete' are closer to this intent. In the meantime, attachment of an address family to an ifnet in the kernel depends upon having at least one address configured, therefore 'alias/-alias' is the best fit to the current reality of the code. I look forward to seeing patches as a result of this discussion if anybody actually wishes to change anything. Regards, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PXEboot fails at kernel (text) loading
Rob wrote: Is it OK to have a double kernel read at the last two lines? Any idea what's wrong here or what I could do to further test what the actual problem is? Argh. I had this same problem as recently as October, but I can't remember exactly what caused this. When I went back and re-did things according to 'man diskless' (and what Doug White told me in the first place), it all worked. Regards, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pppd crashes, was: kde-freebsd] Question about KPPP on FreeBSD
Michael Nottebrock wrote: And yes, if pppd is broken and won't be fixed, it should disappear. And when that happens, so will kppp (it won't build once the if_ppp.h header is gone). Which of course would solve the problem in a way. In any case: I dragged this issue onto -stable precisely to attract attention to the problem and hopefully motivate someone to get down and write some code, whether for pppd or kppp, I really don't care much. Necessity is the mother of invention - either that, or a big bag of cash for everyone. There's information around PPP that's not been communicated or documented well. The 'performance' way to do PPP on FreeBSD is to go off and run MPD, because it has the right compromise between doing low-level packet shunting in the kernel, whilst using Netgraph hooks to tap the PPP control traffic handling off into userland. MPD is wicked cool, and is a well architected way to do things, but the ultimate utility depends on how useful it is to everyone who might use it. So far so good. The problem is that the BSD magicians and the KDE GUI magicians are not sharing their spell-books, and thus, their models of how the code operates; the communities have to intersect somehow. That could be you, y'know. Human bridges are just as, if not more, important as ISO/OSI Layer 2 devices. :^) The way to converge on solution is communication. This has been my experience in recent successful collaboration with the Avahi developers. Regards, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BTX halted with MegaRaid SCSI 320-2 on 6.2R help
Hi, This isn't the answer, but I'm attempting to provide triage for jhb who will probably look at it. This is a GPF, but it's not being caused by an attempt to enter protected mode, so it isn't the most-often reported BTX issue. [EMAIL PROTECTED] wrote: 6.2R cd boot failed with follow error,and the MegaRAID fw version is FW_1L33 thanks with any info BTX loader 1.00 BTX version 1.01 Console: internal video/keyboard BIOS CD is cd0 BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS 639kB/3668928kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 (root at [EMAIL PROTECTED], Fri Jan 12 06:40:38 UTC 2007) int=000d err= efl=00030086 eip=c3d4 eax=8058 ebx=2000 ecx=0007 edx=fffa esi=f69b edi=00040170 epb=03d8 esp=0358 cs=f000 ds=0040 es=5d18fs=9fc0 gs=f000 ss=9e17 cs:eip=ec 50 e4 61 58 50 e4 61-58 ee 5a c3 01 00 e4 c3 12 00 00 41 d0 0c 02 08-80 00 03 00 79 00 79 00 00 ss:esp=77 01 03 2c a1 00 08 2c-fa 02 00 e0 00 00 c0 9f 00 00 4e 80 f3 ee 00 f0-03 24 00 e0 06 02 00 80 BTX halted It looks like BIOS code at f000:c3d4 is trying to read a word from I/O port 0xfffa, and this is causing a GPF when it tries to write to what looks like the BIOS data area at 0040:0058; cursor position for video page 4. 0: ec in (%dx),%al 1: 50 push %eax 2: e4 61 in $0x61,%al 4: 58 pop%eax 5: 50 push %eax 6: e4 61 in $0x61,%al 8: 58 pop%eax 9: ee out%al,(%dx) a: 5a pop%edx b: c3 ret c: 01 00 add%eax,(%eax) e: e4 c3 in $0xc3,%al 10: 12 00 adc(%eax),%al 12: 00 41 d0add%al,0xffd0(%ecx) 15: 0c 02 or $0x2,%al 17: 08 80 00 03 00 79 or %al,0x79000300(%eax) 1d: 00 79 00add%bh,0x0(%ecx) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Treo 650 not correctly seen by uvisor/ucom
Hi, I've attached udesc_dump output. Scanning uvisor.c and ucom.c I see no obvious reason why this shouldn't work; the Treo 650 has the same ident as the Zire 31. I can hotsync FreeBSD via Bluetooth, so this isn't a major worry, but it would be good to have backup via wires. Any ideas? Regards, BMS Standard Device Descriptor: bLength18 bDescriptorType01 bcdUSB 0100 bDeviceClass 00 bDeviceSubClass00 bDeviceProtocol00 bMaxPacketSize 16 idVendor 0830 idProduct 0061 bcdDevice 0100 iManufacturer 1 iProduct 2 iSerialNumber 5 bNumConfigurations 1 Configuration 0: Standard Configuration Descriptor: bLength 9 bDescriptorType 02 wTotalLength46 bNumInterface 1 bConfigurationValue 1 iConfiguration 0 bmAttributesc0 (self-powered) bMaxPower 1 (2 mA) Standard Interface Descriptor: bLength9 bDescriptorType04 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 4 bInterfaceClassff bInterfaceSubClass 00 bInterfaceProtocol 00 iInterface 0 Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 81 (in) bmAttributes 02 (Bulk) wMaxPacketSize 64 bInterval10 Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 02 (out) bmAttributes 02 (Bulk) wMaxPacketSize 64 bInterval0 Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 86 (in) bmAttributes 02 (Bulk) wMaxPacketSize 64 bInterval0 Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 07 (out) bmAttributes 02 (Bulk) wMaxPacketSize 64 bInterval0 Codes Representing Languages by the Device: bLength 4 bDescriptorType 03 wLANGID[0] 0409 String (index 1): PalmOne, Inc. String (index 2): Palm Handheld String (index 3): Standard String (index 4): Serial Interface String (index 5): PalmSN12345678 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: impossible rc.d ordering problem with stf and pf ?
Pete French wrote: Am trying to solve a little problem with 'pf'. I have a ruleset which has some firewall rules for the IPv6 interface stf0. This works fine, except when I rreboot the machine, as the pf script is run before the network_ipv6 script - so stf0 does not exist. but I cannot work out how to arrange for stf0 to be created before the pf script is run - as network_ipv6 requires 'routing', but the pf script says it must be run before 'routing', if I am reading the 'REQUIRE' and 'BEFORE' lines correctly. Just chiming in to confirm that this problem definitely exists. I don't have a solution, however, my IPv6 tunnels at home have all expired, so I may well get spare cycles to look at this the same time that I get spare cycles to revive the tunnels. BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dummynet and simulating random delay
Luigi Rizzo wrote: On Wed, Jan 24, 2007 at 06:10:21PM +1100, Peter Jeremy wrote: On Tue, 2007-Jan-23 14:22:54 -0500, Andresen, Jason R. wrote: I have a project that requires me to simulate a link with varying but well defined delay. The link is guarenteed to deliver packets in order, so I wish to maintain that behavior with Dummynet. I don't think dummynet can do this in its current form. Based on actually dummynet never does reordering within a single pipe, even if you change the delay on the fly. But this said, you should explain varying but well defined delay, Hitting up Google reveals someone hacked Dummynet to introduce per-flow randomness in a uniform distribution: http://www.cs.unc.edu/~jeffay/dirt/FAQ/dummynet-modifications.html However, they included entire source files against FreeBSD 4.5; forward-porting should hopefully not be too tedious for an interested party. Regards, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
