[request-sponsor] Request for sponsor for 6884004
Boris Ostrovsky wrote: Hello, I am going to be working on the following CR: 6884004 ahci driver calls ddi_dma_addr_bind_handle() without specifying permissions My SCA# is OS0248. Thanks. Boris Ostrovsky I'll be sponsoring this for Boris.
[request-sponsor] Request for sponsor for 6884004
Dan Mick wrote: Boris Ostrovsky wrote: Hello, I am going to be working on the following CR: 6884004 ahci driver calls ddi_dma_addr_bind_handle() without specifying permissions My SCA# is OS0248. Thanks. Boris Ostrovsky I'll be sponsoring this for Boris. sorry; I was expecting another request from Boris. Not me for this one.
[request-sponsor] Bug 6341292 cleanup of hsfs warning messages required
Joerg Schilling wrote: Bonnie Corwin Bonnie.Corwin at Sun.COM wrote: Thanks for your interest in this code. I've added this request to the table in the 'awaiting sponsor' category. While waiting for a sponsor, you can get started by reading the instructions about contributing code and the ON development processes found at http://opensolaris.org/os/communities/participation. Be very careful with working on this as at least the lower third of this bug-report in completely incorrect. Specifics, stated in the bug, would be so much better than at least the lower third. An awful lot of this bug is the messages are too vague to be useful, make them more specific, which is hard to see as completely incorrect. I have no idea where the bug report comes from It's easily seen who filed the bug. but hsfs of course implements ISO-9660:1990. I did implement it.. Fiddling with the related tests and messages is dangerous as these tests are implemented in order to make hsfs immune against rotten fsilesystem content. If there are specific things that the bug proposes that should not be done, they should be noted as comments in the bug.
[request-sponsor] Remove 6566789
I've taken over 6566789 myself; please remove it from any sponsor lists.
[request-sponsor] contribution
ashish kataria wrote: Want to work on bug (number 10),*CrNumber =*6291460 http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6291460** *Synopsis=too much pseudo-spelling in solaris (oss-bite-size) for 1 month (approx.)* -- Ashish Kataria Student Apeejay College of Engineering should combine with a lot of other misspellings, some of which are noted in 6566789 more source files misspell relevant which, when it just mentioned 'relevant', I accepted on behalf of John Sonneschein, but then updated with a lot more potential misspellings at eschrock's ... urging ...
[request-sponsor] sponsor request for bug 6363303
John, if you've done the contributor agreement, I can certainly help you with this putback. Bonnie Corwin wrote: Hi John, I assume you mean 6363303. I'll add this to the table. You might want to go ahead and submit a contributor agreement. Then you'll be all set when someone picks this up. Thanks. Bonnie John Sonnenschein wrote On 09/12/06 03:39,: Hello, I've got 2 source trees in one of which bug 63633303 is fixed (yes, it was a search and replace, it took me all of 5 minutes). I just need someone to sign off on the code stick it in the main tree ___ request-sponsor mailing list request-sponsor at opensolaris.org ___ request-sponsor mailing list request-sponsor at opensolaris.org
[request-sponsor] Sponsor Request for 4970570 fsdb_ufs :log_head prints extent list twice
I'll take this one, Shawn...and the next one as well Shawn Walker wrote: Greetings, I would like to request a sponsor to help me integrate my fix for bug 4970570, fsdb_ufs :log_head prints extent list twice. I have a text file giving a short summary here: http://icculus.org/~eviltypeguy/4970570.txt A patch file with only the proposed fix: http://icculus.org/~eviltypeguy/4970570.patch A patch file with the proposed fix and fixes for most of the lint errors: http://icculus.org/~eviltypeguy/4970570_lint.patch These changes were performed using the 20060626 nightly drop. A handful of lint errors remain (that were already there) that I will probably need some help figuring out what to do about, or if they should be ignored for now. Contributor Agreement # OS0004 Thanks,
[request-sponsor] Sponsor Request for 5031435 fsdb dumps a core with :log_otodb command
I'll take this one too, Shawn, along with 4970570 fsdb_ufs :log_head prints extent list twice Shawn Walker wrote: Greetings, I would like to request a sponsor to help me integrate my fix for bug 5031435, fsdb dumps a core with :log_otodb command. I have a text file giving a short summary here: http://icculus.org/~eviltypeguy/5031435.txt A patch file with only the proposed fix: http://icculus.org/~eviltypeguy/5031435.patch These changes were performed using the 20060626 nightly drop. Contributor Agreement # OS0004 Thanks,
[request-sponsor] 6424003 pkginfo -l can't handle long package names properly
Peter Tribble wrote: I would like a sponsor for 6424003. Suggested fix is in the bug report. (Note that the bug report is slightly inaccurate. It's broken on all platforms, but the output sometimes looks plausible.) I'll take this one.
[request-sponsor] 6312400 Ps/2 floppy is not enumerated when acpi is disabled for not supported
Dan Mick wrote: I don't have this saved in my mailbox, for some reason, but I'll sponsor it for Juergen. sorry, I see now that Dana has already taken it.
[request-sponsor] request sponsor for 6311025: build_reserved_irqlist ignores irq15 ...
J?rgen Keil wrote: Fix for this issue is included in the bug's workaround section: in usr/src/uts/i86pc/io/psm/psm_common.c, line 308, the condition for running the code in the loop must be changed from i MAX_ISA_IRQ to i = MAX_ISA_IRQ. This message posted from opensolaris.org ___ request-sponsor mailing list request-sponsor at opensolaris.org I've got this one.
[request-sponsor] Re: 6183481 - pfiles could easily print file offset for files
That is, indeed, the fix that's already in the bug...
Edward Wilson wrote:
Off the top of my head I can't think of anything that changes state on a 0
offset relative seek, so, how about (in context diff format),
*** pfiles.c.prev Sun Dec 11 23:02:37 2005
--- pfiles.cSun Dec 11 23:02:12 2005
***
*** 190,195
--- 190,196
char fname[PATH_MAX];
struct stat64 statb;
struct rlimit rlim;
+ offset_t off;
pid_t pid;
int fd;
char *s;
***
*** 277,282
--- 278,288
(int)statb.st_uid,
(int)statb.st_gid);
+ off = pr_llseek(Pr, fd, (offset_t) 0, SEEK_CUR);
+ if (off != (offset_t) -1) {
+ (void) printf( offset:%lld, (long long) off);
+ }
+
if (rdev == NODEV)
(void) printf( size:%lld\n,
(longlong_t)statb.st_size);
This message posted from opensolaris.org
___
request-sponsor mailing list
request-sponsor at opensolaris.org
[request-sponsor] Round2: Sponsor Proposal
David Robinson wrote: Being a sponsor is not just about typing putback, but it is actually moderately heavyweight in that the sponsor is expected to build, test (maybe DIY test?), and validate the changes. Frankly, in many cases that may take more time than the actual code change. This is definately more than we expect from CRT advocates for normal RTIs. exactly, and therein lies much of the problem, IMO...it's all the grunt work with none of the fun of the thrill of the hunt. I understand it needs doing, but...it's certainly what demotivates me, and I'm guessing others.
[request-sponsor] updated request table
Question: Dan Mick had noted last month that 6323481 (Pci device enumeration for multifunction pci devices is incomplete) may be subsumed by an existing bug. This bug is still in the dispatched state in the database. How do I find out whether this bug really is being addressed by something else so that it can be moved off the 'awaiting sponsor' list? There is no RE assigned. grr. I'll update the bug state; sorry about that. I'll close it as a dup of the See Also, which was put back to snv_25. (There are more changes to that algorithm coming soon.)
[request-sponsor] Requesting sponsor for 4997138 - pn_free() should free pn_bufsize bytes
Just to be clear, I'm working on this one.
Jeremy Teo wrote:
Hello,
as mentioned in the subject above. Trivial patch to fix this is attached.
Regards,
Jeremy
Suggested Fix:
--- usr/src/uts/common/fs/pathname.c Tue Jun 14 15:45:20 2005
+++ usr/src/uts/common/fs/pathname.c Wed Jun 29 14:47:11 2005
@@ -86,7 +86,7 @@
void
pn_free(struct pathname *pnp)
{
- kmem_free(pnp-pn_buf, MAXPATHLEN);
+ kmem_free(pnp-pn_buf, pnp-pn_bufsize);
pnp-pn_path = pnp-pn_buf = NULL;
pnp-pn_pathlen = pnp-pn_bufsize = 0;
}
This message posted from opensolaris.org
___
request-sponsor mailing list
request-sponsor at opensolaris.org
[request-sponsor] How to know whether a bug is being fixed by others?
How to know whether a bug is being fixed by others? As always, if there's a responsible engineer assigned, you can assume that person is working on the bug. Di-Li Victor Hu wrote: And I am Sun employee, do I need to request a sponsor to play with some oss-bit-size tagged bugs? No, but the point of oss-bite-size bugs is for members of the community to work on; Sun employees should not be limited to, nor need the small scope of, oss-bite-size bugs. Followups on opensolaris-bugs, please; let's keep request-sponsor for sponsor traffic only.
[request-sponsor] [PATCH] 4763952 fstyp_ufs misreports cylinder group offsets
Shawn Walker wrote: [PATCH] for bug 4763952 fstyp_ufs misreports cylinder group offsets http://icculus.org/~eviltypeguy/4763952.patch contributor agreement # OS0004 I've got this one
[request-sponsor] request to add Intel D865PERL onboard LAN support
well, it's sorta a minor sponsor request. someone has to add the new ID and test it. I can take this one. Karyn Ritter wrote: I'm still working on the initial email about what processes you all should follow in responding to these messages. Expect to see something by tomorrow at the latest. In the meantime, it doesn't sound to me like this is actually a request for a sponsor. Does anyone want to follow up with Brian on this? Thanks, Karyn Brian Y Wong wrote: i was having trouble getting opensolaris to see my Intel Pro/100 VE device. looked through some forums, and found that i should try adding an entry to /boot/solaris/devicedb/master and /etc/device_aliases. added the following line to /boot/solaris/devicedb/master: pci8086,3020 pci8086,3020 net pci iprb.bef Intel Pro/100 VE Ethernet and the following line to /etc/driver_aliases: iprb pci8086,3020 after doing this ran a devfsadm -C and prtconf was able to associate the probed pci8086,3020 device (the Intel Pro/100 VE Ethernet device) with the iprb driver. This message posted from opensolaris.org ___ request-sponsor mailing list request-sponsor at opensolaris.org ___ request-sponsor mailing list request-sponsor at opensolaris.org
