EEEPC and FreeBSD 7.2
hi! I am trying to use an EEEPC 701 as a diskless station, running FreeBSD 7.2. The EEPC station boots well with PXE then runs the kernel, but the only network card that is recognized is the wireless one (ath0). I read that the wired NIC ( ae? ) has been committed to HEAD; is there any way to make it work on 7-STABLE ? -- http://david.marec.free.fr/ http://www.freebsd.org/fr/ http://www.diablotins.org/ ___ 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: EEEPC and FreeBSD 7.2
В Fri, 8 May 2009 11:47:46 +0200 David Marec пишет: > hi! > > I am trying to use an EEEPC 701 as a diskless station, running > FreeBSD 7.2. > > The EEPC station boots well with PXE then runs the kernel, but the > only network card that is recognized is the wireless one (ath0). > > I read that the wired NIC ( ae? ) has been committed to HEAD; is > there any way to make it work on 7-STABLE ? > > > http://wiki.freebsd.org/AsusEee -- ___ 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: Freebsd 7.2-RC boot problem
On Wed, Apr 29, 2009 at 11:01:50AM -0400, Ken Smith wrote: > On Wed, 2009-04-29 at 11:33 -0300, Paulo Fragoso wrote: > > Hardware: > > MB: Gigabyte GA-M61PME-S2 > > acd0: DVDR at ata3-master SATA150 > > > > ISO MEDIA BOOT > > 7.2-RC2-i386-dvd1.isoDVD-RW OK > > 7.2-RC2-i386-livefs.iso CD-RWOK! > > 7.2-RC2-amd64-disc1.iso CD-RWOK > > 7.2-RC2-i386-disc1.iso CD-RW,CD-R FAILS > > Thanks, greatly appreciate all the testing. > > As part of looking into this I went looking for another Gigabyte > motherboard and through the past 2 days was able to test the same set of > things with the same results. So far I haven't been able to reproduce > this on anything but Gigabyte. This is such a bizarre problem I really > needed someone else to confirm so thank you very much. Since there is a > workaround I don't think I'll hold the release for this problem but we > will need to mention this in the Errata (and possibly the announcement > itself). > I just got bitten by this on a VIA EPIA-M system. 7.2-RELEASE-i386-disc1.iso doesn't work 7.2-RELEASE-i386-bootonly.iso works - Christian -- Christian Brueffer ch...@unixpages.org bruef...@freebsd.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgpVwY8SAksib.pgp Description: PGP signature
"maxproc limit exceeded" making no sense
Hello, I have a problem which makes no sense to me, at least not the way I understand. My mail server is compaining about maxproc limit: # tail /var/log/messages May 8 10:34:15 mx kernel: maxproc limit exceeded by uid 82, please see tuning(7) and login.conf(5). May 8 10:34:38 mx last message repeated 12 times May 8 10:35:14 mx last message repeated 18 times May 8 10:36:32 mx last message repeated 41 times May 8 10:36:35 mx kernel: maxproc limit exceeded by uid 82, please see tuning(7) and login.conf(5). My maxproc as well as maxfiles are artificially raised (a lot raised): # sysctl kern.maxfiles kern.maxfiles: 8 # sysctl kern.maxfilesperproc kern.maxfilesperproc: 8 # sysctl kern.maxproc kern.maxproc: 9000 # sysctl kern.maxprocperuid kern.maxprocperuid: 8 However what I see regarding proc usage is by uid 82 is: # ps -U 82 | wc -l 723 Proccess count for UID 82 is never highter than 913 (monitored the last whole hour, while log messages were still showing, complaining about maxproc limit beeing exceeded). I would like to understand and figure out what I need to tune in order to raise the current limit, and also find what the current limit is. Thank you a lot and in advance. -- === Eduardo Meyer pessoal: dudu.me...@gmail.com profissional: ddm.farmac...@saude.gov.br ___ 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: Xorg hangs with drmwtq in 7.2-RELEASE
On Thu, 2009-05-07 at 22:29 -0700, David Johnson wrote: > On Tuesday 05 May 2009 08:41:48 pm David Johnson wrote: > > On Monday 04 May 2009 11:20:17 pm Robert Noland wrote: > > > This generally suggests that the GPU is locked up... Given that you say > > > sometimes it locks up hard (usually a panic, that you can't see since X > > > is running) and other times only X is stalled it might be related to > > > this patch, if you haven't tried this on already. > > > > > > http://people.freebsd.org/~rnoland/drm_radeon-copyin-fix-try2.patch > > > > Nope, that didn't help. Still froze when I tried opening multiple windows > > at once. I'm backing out the patch to get back to a clean state. > > > > I also edited my xorg.conf to be closer to yours. No difference. > > > > What information do you need to go forward, and how do I collect it? > > > > p.s. I didn't have a problem with sources from RELENG_7 date=2009.03.13, if > > that helps any. > > I just upgraded graphics/libdrm. It didn't help any. I'm just shooting blanks > in the dark. Any help would be greatly appreciated. Please let me know what > information is needed and how I collect it. I still can't reproduce this... I updated the Xserver, libGL and dri ports yesterday, all of which could be related to locking up the GPU and worth a shot. Failing that, I need you to enabled drm debugging. Start the system without X, kldload radeon.ko, set sysctl hw.dri.0.debug=1 then startx. robert. > Thank you, > -- Robert Noland FreeBSD signature.asc Description: This is a digitally signed message part
Re: problems with sata disks (taskqueue timeout)
On Sun, 29 Mar 2009 11:01:53 +0200 Marc "UBM" Bocklet wrote: > On Tue, 20 Jan 2009 08:08:29 +0100 > Marc "UBM" Bocklet wrote: > > > On Tue, 20 Jan 2009 09:39:51 +1100 > > Andrew Snow wrote: > > > > > > > > I think that if you use eSATA you probably need dedicated eSATA > > > controller ports. eSATA standard specifies a higher voltage for > > > the longer cable distances. > > > > > > Judging from the sporadic problem reports, Promise TX4 is probably > > > not the best at signal purity to begin with so using it for eSATA > > > pushes it over the edge. > > > > > > > > > Hope that helps, > > > > Thanks for the fast answer! :-) > > > > Although my version of the TX4 has two dedicated e-sata ports, the > > other posts seem to indicate that it got something to do with the > > controller (maybe signal purity, like you said). I'll try upgrading > > next and will report back after that. > > A very late followup here: > > I upgraded to the latest stable, but things did not improve: > > Mar 29 10:57:29 hamstor kernel: ad10: WARNING - WRITE_DMA48 UDMA ICRC > error (retrying request) LBA=1087300992 Mar 29 10:57:34 hamstor > kernel: ad10: FAILURE - SET_MULTI status=51 > error=4 > > Mar 29 10:57:34 hamstor kernel: ad10: TIMEOUT - WRITE_DMA48 retrying > (0 retries left) LBA=1087300992 > > Mar 29 10:57:34 hamstor kernel: ad10: FAILURE - WRITE_DMA48 > status=ff > error=ff > LBA=1087300992 > > Mar 29 10:57:34 hamstor root: ZFS: vdev I/O failure, > zpool=gedaerm path=/dev/ad10 offset=556698042368 size=131072 error=5 > > Mar 29 10:57:43 hamstor kernel: ad10: WARNING - SETFEATURES SET > TRANSFER MODE taskqueue timeout - completing request directly > > Mar 29 10:57:47 hamstor kernel: ad10: WARNING - SETFEATURES SET > TRANSFER MODE taskqueue timeout - completing request directly > > Mar 29 10:57:51 hamstor kernel: ad10: WARNING - SETFEATURES ENABLE > WCACHE taskqueue timeout - completing request directly > > Mar 29 10:57:55 hamstor kernel: ad10: WARNING - SET_MULTI taskqueue > timeout - completing request directly > > Mar 29 10:57:55 hamstor kernel: ad10: TIMEOUT - WRITE_DMA48 retrying > (1 retry left) LBA=1087301248 > > Mar 29 10:57:55 hamstor kernel: ad10: WARNING - WRITE_DMA48 UDMA ICRC > error (retrying request) LBA=1087301248 > > Mar 29 10:58:00 hamstor kernel: ad10: FAILURE - SET_MULTI > status=51 error=4 > > Mar 29 10:58:00 hamstor kernel: ad10: FAILURE - WRITE_DMA48 timed out > LBA=1087301248 > > Mar 29 10:58:00 hamstor root: ZFS: vdev I/O failure, zpool=gedaerm > path=/dev/ad10 offset=556698173440 size=131072 error=5 > > > > Any further ideas anybody? :-) Another update, upgrading to -current dating from April 25th 2009 seems to have "fixed" the problem, I've encountered no errors as of yet and I've copied about 250GB in large chunks, something that was sure to provoke the errors with -stable. FreeBSD xxx 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Sat Apr 25 13:33:18 CEST 2009 xxx:/usr/obj/usr/src/sys/xxx amd64 Bye Marc -- "And what rough beast, its hour come round at last, Slouches towards Bethlehem to be born?" W.B. Yeats, The Second Coming ___ 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: Jails and IPv6
On Thu, 7 May 2009, Steve Bertrand wrote: Hi Steve, I just want to throw out a heart-felt thank you, congratulations and excellent work to all those who had their hand in making the jail framework so completely flexible (particularly on the IP side of things). Kudos, and thank you all. IPv6 works flawlessly! Happy to see things work fine for you as well:) It's really great to get feedback like that! Obviously, if you find any problem we'll also like to hear about that. In that case you may probably want to post to the freebsd-jail mailing list to get help. The same obviously applies to anyone going to give it a try;-) /bz PS: saying what I have said before: if you are using jails and like the new features and they work out for you or you may make money by using them and want to give something back, consider a donation to the FreeBSD Foundation: see http://www.freebsdfoundation.org/donate/ -- Bjoern A. Zeeb The greatest risk is not taking one. ___ 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: Xorg hangs with drmwtq in 7.2-RELEASE
On Friday 08 May 2009 07:35:45 am Robert Noland wrote: > I still can't reproduce this... I updated the Xserver, libGL and dri > ports yesterday, all of which could be related to locking up the GPU and > worth a shot. Failing that, I need you to enabled drm debugging. Start > the system without X, kldload radeon.ko, set sysctl hw.dri.0.debug=1 > then startx. I've got all the updated ports as of last night, so that wasn't it. I turned AIGLX back on, and it promptly locked up again. This time, however, the screen went black instead of freezing, but otherwise the same as always. I then turned on hw.dri.0.debug, and messages quickly filled up with the following repeated message: [drm:pid1195:drm_ioctl] returning 4 [drm:pid1195:drm_ioctl] pid=1195, cmd=0x80046457, nr=0x57, dev 0xc615fa00, auth=1 -- David Johnson ___ 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: Xorg hangs with drmwtq in 7.2-RELEASE
On Fri, 2009-05-08 at 14:58 -0700, David Johnson wrote:
> On Friday 08 May 2009 07:35:45 am Robert Noland wrote:
> > I still can't reproduce this... I updated the Xserver, libGL and dri
> > ports yesterday, all of which could be related to locking up the GPU and
> > worth a shot. Failing that, I need you to enabled drm debugging. Start
> > the system without X, kldload radeon.ko, set sysctl hw.dri.0.debug=1
> > then startx.
>
> I've got all the updated ports as of last night, so that wasn't it.
>
> I turned AIGLX back on, and it promptly locked up again. This time, however,
> the screen went black instead of freezing, but otherwise the same as always.
> I then turned on hw.dri.0.debug, and messages quickly filled up with the
> following repeated message:
>
> [drm:pid1195:drm_ioctl] returning 4
> [drm:pid1195:drm_ioctl] pid=1195, cmd=0x80046457, nr=0x57, dev 0xc615fa00,
> auth=1
>
This is too late to really see anything... This still just suggests that
the GPU is locked up. What is happening below is that we have emitted
an "irq" to the card and we are waiting on it to parse that. The return
value 4 is EINTR which says that we were interrupted while we were
waiting. When we return EINTR, libdrm just performs the ioctl over
again. We first read the register from the card to see if it has parsed
at least up to what we are looking for, if so we just return success and
don't sleep. If the register says that we haven't parsed the command,
then we sleep for a max of 3 seconds waiting on the card to catch up.
In your case, the card is never catching up, which suggests that the
card is hung and not processing the command stream anymore.
static int radeon_wait_irq(struct drm_device * dev, int swi_nr)
{
drm_radeon_private_t *dev_priv =
(drm_radeon_private_t *) dev->dev_private;
int ret = 0;
if (RADEON_READ(RADEON_LAST_SWI_REG) >= swi_nr)
return 0;
dev_priv->stats.boxes |= RADEON_BOX_WAIT_IDLE;
DRM_WAIT_ON(ret, dev_priv->swi_queue, 3 * DRM_HZ,
RADEON_READ(RADEON_LAST_SWI_REG) >= swi_nr);
if (ret == -ERESTART)
DRM_DEBUG("restarting syscall");
return ret;
}
In order to guess what might be causing this, drm debugging needs to be
enabled before the hang, so that we can hopefully figure out what leads
up to the hung GPU.
robert.
--
Robert Noland
FreeBSD
signature.asc
Description: This is a digitally signed message part
