Re: [PATCH] ifconfig(8) flag to display IPv4 netmasks in dot-decimal format
On 11.04.2011 19:17, Gary Jennejohn wrote: On Mon, 11 Apr 2011 16:11:27 +0400 Sergey Vinogradov wrote: I've written a tiny-tiny patch, which adds the '-t' flag to ifconfig(8). It modifies the output to display IPv4 netmasks in dotted decimal notation: % ifconfig msk0 msk0: flags=8843 metric 0 mtu 1500 options=c011a ether 00:16:e6:88:0f:89 inet 10.10.0.1 netmask 0xff00 broadcast 10.10.0.255 media: Ethernet autoselect (none) status: no carrier % ifconfig -t msk0 msk0: flags=8843 metric 0 mtu 1500 options=c011a ether 00:16:e6:88:0f:89 inet 10.10.0.1 netmask 255.255.255.0 broadcast 10.10.0.255 media: Ethernet autoselect (none) status: no carrier There was a discussion [1] in freebsd-hackers@ about adding such functionality to ifconfig(8), which urged me write this patch. The default behavior of ifconfig(8) is kept unmodified, so there shouldn't be any compatibility breakages. At least, it works fine for me :) [1] http://lists.freebsd.org/pipermail/freebsd-hackers/2011-April/034997.html Looks good, except I'd change this line to read like this: +The +.Fl t +flag makes IPv4 netmasks being displayed in dotted decimal notation. ^ results in Note taken, fix will appear in the next patch version (if any). -- wbr, Boo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: use_generic and usb probing
on 13/04/2011 00:48 Nick Hibma said the following: >> Well, I think that that's what probe priorities actually for. I also think >> that typically ivars should be set by a bus driver. So maybe it's not such a >> good idea to pass data from probe to attach via ivars in child drivers. But I >> could be mistaken about that. >> >> Practically speaking, you most likely don't have to worry about that for >> drivers that return BUS_PROBE_SPECIFIC (=0) from their probe methods. And >> there is only a few "generic" drivers that can be handled on a case by case >> basis. > > Newbus priorities where specifically implemented on my request by Doug Rabson > to cater for fallback attachments: usb.h (the old code) contained a list of > priorities. ugen had the lowest priority and attached if no one else did. An > example was a keyboard with a built-in mouse on one interface. It would be > attached by either mouse or keyboard but not both. An additional driver could > probide both devices. We ended up implementing that differently though: > attachment to interfaces instead of devices. OK. Though I don't see how that is related to the question that I raised. > A probe should not pass any information to the attach phase if it can at all > avoid it. Or at least that is the assumption. If a driver needs info in both > phases, it needs to regenerate it again. The fact that usb_probe is called > again is a kludge, specifically for the description. I am not sure that I understood this part. > I guess that documenting this kludge and updating the comment to state this > fact would be sufficient to solve the problem. I don't see how this follows from what you've written above. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Sense fetching [Was: cdrtools /devel ...]
does r22056{3,5,6,9} supercede these patches ?
my dvd burning with ahci seems to be fixed by those commits,
without these patches.
I've just burned a DVD successful, and it's readable.
Thanks,
Buganini
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Sense fetching [Was: cdrtools /devel ...]
Buganini wrote:
> does r22056{3,5,6,9} supercede these patches ?
Yes. They solve problem from different side.
> my dvd burning with ahci seems to be fixed by those commits,
> without these patches.
>
> I've just burned a DVD successful, and it's readable.
Yea, I've also burned few DVDs with cdrecord-devel for testing.
--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [regression] unable to boot: no GEOM devices found.
On Tuesday 12 April 2011 22:12:55 Alexander Motin wrote: > David Naylor wrote: > > On Tuesday 12 April 2011 08:17:51 Alexander Motin wrote: > >> David Naylor wrote: > >>> I am running -current and since a few days ago (at least 2011/04/11) I > >>> am unable to boot. > >>> > >>> The boot process stops when it looks to find a bootable device. The > >>> prompt (when pressing '?') does not display any device and yielding one > >>> second (or more) to the kernel (by pressing '.') does not improve the > >>> situation. > >>> > >>> A known working date is 2011/02/20. > >>> > >>> I am running amd64 on a nVidia MCP51 chipset. > >> > >> MCP51... again... > > +ata2: reiniting channel .. > +ata2: SATA connect time=0ms status=0113 > +ata2: reset tp1 mask=01 ostat0=58 ostat1=00 > +ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 > +ata2: reset tp2 stat0=50 stat1=00 devices=0x1 > +ata2: reinit done .. > +unknown: FAILURE - ATA_IDENTIFY timed out LBA=0 > > As soon as all devices detected but not responding to commands, I would > suppose that there is something wrong with ATA interrupts. There is a > long chain of interrupt problems in this chipset. I have already tried > to debug one case where ATA wasn't generating interrupts at all. > Unfortunately, without success -- requests were executing, but not > generating interrupts, it wasn't looked like ATA driver problem. > > What's about possible candidate to revision triggering your problem, I > would look on this message: > +pcib0: Enabling MSI window for HyperTransport slave at pci0:0:9:0 > > At least it is recent (SVN revs 219737,219740 on 2011-03-18 by jhb) and > it is interrupt related. I reverted those two revs and everything works again. signature.asc Description: This is a digitally signed message part.
